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.
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