speed comparison(cloth fps drop)

dcyuri

05-01-2011 15:17:41

Hi I wanted to see what everyone's framerate runs around when operating a cloth tutorial or similair usage of?

I am getting a drop from 150fps to 10, whenever nxogre has control of the animable item(even gravity simulation, as well as force applications).
I have it(tutorial 1001 sample app) under release mode for all resources, and removed shadows & extra lighting, and decreased LOD. Seems to be an animation issue.
Even tried running the world->advance stepper from within it's own thread; using a fifo for the FrameEvent timing per each queue'd frame(to ensure it wasn't slowing down ogre) -- seemed to have no effect, aside choppy/jittery animations gaps - as opposed to persistent lag at 10fps; same fps remained.
So it must be something deep within the nxogre core causing the lag and/or my system is too slow(NxOgre::ResourceSystem binding?). I was certain that running the stepper in a thread would solve it. Not sure how it's possible for that framerate to stick like that, when mouse isn't being used(the only other math op under frameQRend;skipped when not used), since assigning the data into the fifo is extremely low overhead. It's as if nxOgre is doing some serious CPU/mem stuff(which makes sense i suppose), stealing resources from ogre runtime.

is this framerate drop typical for the amount of detail involved in cloth tutorials for Detritus+PhysX under Direct3D9(Ogre 1.7)?

dcyuri

06-01-2011 01:02:37

To add to this... I'm getting insane lag on every single demo I try. The heighmap example drops below 5fps.
I'm not understanding how that's possible. I'm not a fan of Bullet but, it definitely doesn't have any issues like this. Will sadden me if I have to leave nxogre :(
Anyone know why Bullet can operate above 150fps with over 200,000 triangles and physics combined, while I can hardly run the box demo on Nxogre?
Guess I'm gonna have to dive into the nxogre source code and recompile in debug mode

betajaen

06-01-2011 09:48:37

I was working with cloth yesterday and I was running it around 600 FPS.

What is your setup?

dcyuri

06-01-2011 22:41:30

Interesting, I'm not sure why I'm running so slow. I do have an old system though... as follows:
Ram: 2gb
CPU: 3.0ghz HTT p4, 12mb bus
Vid: ati radeon HD 5400, 512mb onboard
o/s: WinXP (lite vers, stripped down to 80mb pfile usage on boot)

I went ahead and rebuilt Ogre from source, as well as dependencies. Still having the same problem. I found that my cpu and ram is maxed in usage during the demo, so it must be hardware related.
Of course if I remove the stepper for ogre's mWorld-advance, they lag goes away, but so does animation obviously.
I was able to get ogre to run 300 instances of Sinbad animating the dance procedure(no physics), which brought me to 20fps.
If i reduce the size of the flag for cloth demo down to 4,2(WxH), fps was doubled(35fps). Sounds like hardware to me now.

bummer :( time to upgrade it seems.
thanks for the help betajaen

betajaen

06-01-2011 22:51:52

Still. I used to develop NxOgre on those specifications and I had high frame rates. Your not using it in debug mode aren't you?

dcyuri

07-01-2011 01:34:50

That was my understanding as well, I mean it's not a terribly awful setup, just alittle old.
And yes that's correct, am using in all in release mode; not running a debug JIT either - operating straight from folder.
I haven't tried openGL stub, but I assume it would yield the same results as d3d9.

I'm thinking something else is the problem - since the heightmap demo is beyond usable (lower than 5fps). Would you recommend, at this point, that I try commenting out blocks of runtime code?
Since the lag completely dissipates when mWorld->advance is removed - it must be something within that block of code.
I'll go ahead and try diving into it and see what I can find, and report back.

betajaen

07-01-2011 08:56:34

The terrain example has always been ridiculously slow. I shall be removing it from Critter and the Tutorials in later commits anyway. It isn't a fault of Ogre, PhysX or NxOgre individually. I think it's a combination of the three.

dcyuri

07-01-2011 17:10:14

Thanks for the feedback, that makes alot of sense.
Was curious what your opinion is on the following code? I know it's a terribly, unsophisticated, hack, but it seems to do the trick well.

I attempted modifying nxogre dll code to reduce the lag, but nxogre is well constructed - so many calculations go into the physics of a cloth simulation; removing lines of code simply isn't a debugging option. And there's ALOT of code to sift through for each of the three buffers.

Here's my .... crud code lol (frameQueued) :
Ogre::Real t=e.timeSinceLastFrame;
Ogre::Real minFPS=0.5f; // aim for 50fps (ranges 30-60 actually)
if (t<minFPS) {
mWorld->advance(t+step);
step=0.0f;
} else step+=t;

Where 'step' is a class var of type Ogre::Real

The animation is only slightly jump - but the lag completely dissipates (in relation to the minFPS setting). Sortof a throttle for nxOgre on slower pc's i suppose. I'm gonna use this for now under the assumption it's just a pc issue . I can atleast experience near real-time physics with it. :D
If you disagree with it though, I'll need to ensure I remove it for distributions outside of my pc.

betajaen

07-01-2011 17:27:57

Your basically doing "VSync", but it's not a bad idea.

Have a look at the NxOgreFixedTimeStep::calculate function (posted here). It'll be more accurate than yours, and the timestep I get from it is really close to PhysX's timestep value.

void FixedTimeStep::calculate(float deltaTime)
{

mActual = deltaTime;
mAccumulator += deltaTime;
mModified = 0;

while(mAccumulator >= mMaxTimeStep)
{
mModified += mMaxTimeStep;
mAccumulator -= mMaxTimeStep;
}

mAlpha = mAccumulator / mMaxTimeStep;

}


I wonder if we could incorporate the idea into NxOgre somehow.

cdreid

12-01-2011 19:56:18

I'm certain betajaen is correct as usual.

But i think your system is the problem.. more specifically mostly your ram and a little your cpu. If youre using vista well theres your cuplrit. XP is better and 7 even better. Windows gui is a nightmare in how it uses ram and threads. Its positively moronic. Try switching resolutions etc.. some part of your system software/hardware might not like the resolution, speed etc youre running your system. I had a system that would fly with games at 1280x resolution and slow to a CRAWL at 800x