performance question

hello betajen

during playing with the physx demos and with my demo it seems for me that the demos from ageia are noticeable faster then the nxogre demos.

for example if i take the tearable cloth demo: taking the same parameter in my cloth demo it makes only 7 frames in physx lesson 1006 it makes 42.
i check if it could be the draw routine but the framerate doesn't change at all if i do not call it. it seems that physx engine takes the time. i also do not think that nxogre wrapper cause that slowdwon becaus in the cloth demo of me nxogre doesn't have to do much.


i also checked it with cubes. the demo from aegea can take 1500 cubes an even makes 60 frames nxogre slows down to 30 frames with around 500 cubes.

pherhaps a global initial value which is suboptimal cause this large differnce in performance or the ageia demos call the simulation routine less frequently.

what do you suggest could cause this difference. i think nxogre could get a big performce boost if you/we find the reson for that slow down.


Because i'm to new to physx and nxogre i can not really make a good guess where the performs difference comes from or even if there is really is such a big performance differnce my short tests makes me believe. I hope you can clear the fog for me.



greetings
martin

Well the difference between the tutorials and the PhysX lessons, is because of content. The PhysX lessons are basically simple un-textured cubes.

Where as the NxOgre tutorials are textured (in some cases), cubes, with a textured floor, light and so on. It does take up a bit of "room", i.e. don't show the floor and you'll get a performance boost.

However with NxOgre itself, I have tried to make it as fast as possible. Thing such as states, particles, and so to be cloth are rendered/calculated every other frame, some others even less than that.

I do want to implement "instancing" for common bodies, as I understand it a form of dynamic static-geometry, perhaps rendered via shaders.

However at the heart of things, NxOgre and Ogre are more so more complicated than OpenGL and PhysX.

ok i will try a little bit in this direction and make a scene which is more simple so that i can compare the demos better.

Basically if you don't setup the NxOgre grid, lights and so on and don't render any GUI or mouse picking.

Use proper 6 sided cubes, rather than my 20 polygoned versions (the shiny corners). It should be comparable.

However remember Ogre is still doing a lot more than their simple OpenGL is.

the influnece of ogre i could easily check if i simply create 500 meshes without physics.
then we will see.

Or you could just profile the Ogre based app, as long as its running the same scene set as physics objects as in the standard PhysX demo. After that is setup one or to runs and you will find out where most of the time it spent. No need to spend any time guessing or tweaking factors which you think should put more or less load on one component.

You also want to make sure you aren't running Ogre in debug mode.

so i found the solution. i think for betajaen and other experienced users it doesn't came as suprise. so the rest it probably for the newbees.

there are one sdk parameters and one scene parameter which mainly influence the performance:

the most import parameter is the scene parameter maxiter. nxogre leaves it at default = 8. you can set it (second paremeter) e.g.

mScene->mScene->setTiming(1.0/60.0, 1 );

a value from 1 give you more speed but certainly with the tradeoff of less precision so choose it how your program needs it.

the sdk parameter which has significant influence on the speed is NX_SKIN_WIDTH . it describes how much shapes can interpenetrade.

mWorld->mPhysicsSDK->setParameter(NX_SKIN_WIDTH,0.001f)

i find it intresting that smaller values result in more simulation speed. the tradeoff seems to be more jitter and instability (i read it in the documentation).

so for me this matter is cleared.


greetings
martin

here one example of the efffect:
my cloth example with a cloth exactly matching the tearable cloth demo of the physx sdk brings it to 47 frames/s if maxiter is set to 1 instead of 7 frames/s if maxiter is set to 8

See.

Perhaps it's time for a blueprint<world>