iDevGames Forums
ode - speed with composite objects - Printable Version

+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Game Programming Fundamentals (/forum-7.html)
+--- Thread: ode - speed with composite objects (/thread-4897.html)



ode - speed with composite objects - reubert - Oct 20, 2005 01:01 AM

Has anyone found a secret to getting good speed with ODE and quite a few composite objects?

I've got a fairly large trimesh, and 4 cars (box and 4 spheres each) which runs at full frame rate, but adding 10 cones to my level makes it run at 2fps on a G4 1ghz. Shark shows 15% at SOR_LCP and another 50% or so in other ODE functions. I'm using dWorldQuickStep with only 2 iterations, I have a single space using dQuadTreeSpaceCreate, My cones are using a box and two spheres, tied together with slider joints.

I'm thinking maybe I need to split up my space, but before I go down that path I'm wondering if anyone has already figured out how to make ODE run about 30x faster with many objects Rasp

Cheers,
David


ode - speed with composite objects - TomorrowPlusX - Oct 20, 2005 10:02 AM

I'm using *far* more complex scenarios with ODE and am not seeing this. Perhaps you've got some sort of algorithmic design issues in your nearCallback? I had some trouble there at one point, as I was looking up info for potential colliders with a very poorly designed algorithm.

Also, you might see a performance improvement using a quadtree space.

Fact is, though, that ODE is not anywhere near as fast or, honestly, good as newton or some of the other commercial physics engines. I use ODE because it's open source, and because I'm familiar with it, but you might want to consider a better engine.


ode - speed with composite objects - TomorrowPlusX - Oct 20, 2005 12:09 PM

I thought for a bit about how you might get good performance out of ODE, and something which strikes me as a best bet -- and something which I intend to pursue -- is having your objects be *without* bodies until bodies are needed. E.g., they're just geoms, and bodies are created and destroyed only when collisions occur or when an object is moving.

My feeling is that your nearCallback would see if an object in a collision has no body and if the object colliding with it is bodied and moving. If so, you'd create a body for that geom and let ODE do its thing.

Then, in your physics update, for each bodied object you'd apply a dampening force to each ( a good idea in ODE, anyway, since ODE can be a little unstable ) and when an object's linear and angular velocity approach zero, you'd delete its body. Then it'd become a static geom until a new collision forced it to become bodied again.


ode - speed with composite objects - reubert - Oct 20, 2005 01:51 PM

I'd love to use Newton, but unfortunately, like yourself I have been wrestling with ODE for far too long now to throw it all away and risk another engine.

Still, I must be doing something wrong here... like you said, 10 cones shouldn't kill it. All up I have 4x4 spheres, 4 boxes, another 2x10 spheres and 1x10 boxes and a 900 triangle mesh. Thats 51 bodies.

I wonder if you could tell me the performance you are getting and with what number of bodies in the world?

I'm thinking something like what you have described would be a good idea. If I drop the cones then while they are falling the simulation runs quite quickly, but when they are settled on the trimesh it runs like a dog. It seems there must be an optimization available there.


ode - speed with composite objects - reubert - Oct 20, 2005 11:30 PM

I knew there'd be a magic button somewhere... When I decreased the number of physics frames per second from 200 to 50 I got about a 30x increase in speed. I also discovered that something in my car driving code is not time based.... doh!

*is happy again*Smile


ode - speed with composite objects - TomorrowPlusX - Oct 21, 2005 06:25 AM

My god, 200 steps per second! Criminy!

In my work, I've settled on 80, it's fast enough to prevent most problems, and slow enough not to kill my performance. But, yes, you *need* to be time based.

Remember, though, that ODE doesn't take well to variable time steps. You have to settle on a number, and in your update make certain that if you're running behind, favor physics updates over rendering updates. They have to run separately, even if it's in the same thread.


ode - speed with composite objects - reubert - Oct 21, 2005 02:02 PM

Yes, I think what was happening was that after the nth cone I started dropping physics frames, and that was much worse than aiming for a lower number to start off with. I've settled with 75 now.

It appears that joint stops are far more spongy at larger time steps, so that is where the non-time-based thing was. I was able to get it back to normality by setting the CFM and ERP on the joints to 0.

Interestingly enough setting the global ERP to 0 is a bad idea. You know something is wrong when Inanimate objects start to jump off the world.