Real-Time Physics Simulation Forum

Re: Bullet Vs PhysX Vs ODE Restitution question

2010-08-12T16:28:59+00:00

OK,

I have performed some more tests and its quite revealing!

I have re-done the tests from the uploaded frameworks in order to make everything fair and equal. So I have ensured that for all tests I am using a SaP broadphase (set to single rather than multi in PhysX).

The first graph is as before, so this is just a sphere falling due to Gravity, nothing for it to impact. As before, all plotted points are an average of 3 runs on the same machine (T7700, 4GB 667Mhz DDR2 RAM):

The second graph really highlights what DannyChapman says though. In this test there is now a ground plane defined and 625 of the spheres from test 1 are arranged in 5 planes of 5x5, with each "plane" of spheres raised above the other by 2 units, just to ensure that there is movement through the system due to gravity, rather than them all starting in contact. Now we see PhysX and Bullet really steam ahead of ODE:

Quite an interesting set of comparisons for me.

Statistics: Posted by TriplVing — Thu Aug 12, 2010 4:28 pm

Re: Bullet Vs PhysX Vs ODE Restitution question

2010-08-12T12:01:19+00:00

I'm not sure that this is a very fair performance test for the engines! Engines will be optimised for more than one body, and also probably for bodies in contact rather than unconstrained.

For example, when I run the PhysX test case I get timings of around 0.07ms, for one sphere falling.

However, the total time for 100 spheres falling is 0.17ms - i.e. only 0.0017ms per sphere. Obviously that's a huge speedup per sphere, even though there's now lots of collision detection to be done!

Obviously there's an overhead in updating the engine, and whilst that overhead may be much more than the cost of updating a single object in the scene, it would normally be pretty small compared to the overall physics budget in most real simulations.

Agreed, I understand that. I was just quite interested to see the difference between the engines in such a pared down case. I agree it's more likely that rather than the actual coding standard being better in ODE, it is just structured in such a way that for smaller tests, its better.

What I might do in a minute is run some larger tests as you suggest, maybe 1000 spheres aligned cubically with each row slightly above each other so that everything falls to begin with, and a plane at zero. That might offer an interesting alternative insight and provide a more fair comparison.

I'm not really bashing any engine per se, i'm just trying to do an objective black-box test of them all.

I'll post up the results of said larger tests in a bit.

Statistics: Posted by TriplVing — Thu Aug 12, 2010 12:01 pm

Re: Bullet Vs PhysX Vs ODE Restitution question

2010-08-12T10:34:47+00:00

I'm not sure that this is a very fair performance test for the engines! Engines will be optimised for more than one body, and also probably for bodies in contact rather than unconstrained.

For example, when I run the PhysX test case I get timings of around 0.07ms, for one sphere falling.

However, the total time for 100 spheres falling is 0.17ms - i.e. only 0.0017ms per sphere. Obviously that's a huge speedup per sphere, even though there's now lots of collision detection to be done!

Obviously there's an overhead in updating the engine, and whilst that overhead may be much more than the cost of updating a single object in the scene, it would normally be pretty small compared to the overall physics budget in most real simulations.

Statistics: Posted by DannyChapman — Thu Aug 12, 2010 10:34 am

Re: Bullet Vs PhysX Vs ODE Restitution question

2010-08-11T17:51:10+00:00

In case anybody is interested to see the graph of my results, I thought i'd attach it to this post.

This was produced using the three test frameworks included 2 posts up, with a fourth added created using a very simple little RK4 integrator I wrote purely to get some baseline figures (it calculates position and rotation only, no collision response etc, but I thought it would be interesting purely as a baseline addition).

500 iterations were performed 3 times for each engine and the results plotted are the average of those 3 values.

ODE really does seem to whip along!

Statistics: Posted by TriplVing — Wed Aug 11, 2010 5:51 pm

Re: Bullet Vs PhysX Vs ODE Restitution question

2010-08-11T09:07:33+00:00

You might be correct since I remember now that the contact constraints are not persistent. I cannot say 100%. Anyway I was refering to this line from the code which gave me the impression that they use warmstarting also for contacts:

//***************************************************************************
// configuration

// for the SOR and CG methods:
// uncomment the following line to use warm starting. this definitely
// help for motor-driven joints. unfortunately it appears to hurt
// with high-friction contacts using the SOR method. use with care

#define WARM_STARTING 1

Statistics: Posted by Dirk Gregorius — Wed Aug 11, 2010 9:07 am

Bullet Vs PhysX Vs ODE performance comparison

2010-08-10T21:45:16+00:00

Ok, have attached the three frameworks, apologies that the timing code uses a windows header. It was given to me by a colleague and I have used it elsewhere in my work, so I just keep using it to be consistent. I know its not the best way to take critical timings, but it should at least produce comparative results, even if not entirely accurate.

They are all Visual Studio 2008 projects (earliest version of VS I had). In the case of Bullet and ODE, I have included the libraries that I have compiled for x64, for PhysX, it will be necessary to alter system paths from my system to make it compile as well as having the latest SDK (2.8.3 build 21) and the latest system software.

In all cases, only the "x64: Release" profile is properly setup.

I'm very open to the possibility I am doing something quite stupid I am a researcher, not software developer and while I like to think I am OK at it, it is not my main trade, rather a tool that lets me do my research.

So I would be very interested to hear any feedback anyone has to offer.

Thanks again.

ODEFramework.zip

PhysXFramework.zip

BulletFramework.zip

Statistics: Posted by TriplVing — Tue Aug 10, 2010 9:45 pm

Re: Bullet Vs PhysX Vs ODE Restitution question

2010-08-10T21:41:44+00:00

This warmstarting option in ODE is only for non-contact joints, not for contact constraints. ODE doesn't provide persistent contact point management to store warm starting information, as far as I know.

Thanks,
Erwin

Statistics: Posted by Erwin Coumans — Tue Aug 10, 2010 9:41 pm

Re: Bullet Vs PhysX Vs ODE Restitution question

2010-08-10T21:26:13+00:00

IIRC there is a define in ODE that let's you activate warmstarting. Anyway, the lack of tools and general convex collision detection in the ODE are show stoppers in my opinion.

Statistics: Posted by Dirk Gregorius — Tue Aug 10, 2010 9:26 pm

Re: Bullet Vs PhysX Vs ODE Restitution question

2010-08-10T20:27:21+00:00

Yes, please upload that framework somewhere, or attach it as a zipfile to this forum topic.

As I understand it, ODE is generally a more lightweight library than Bullet or PhysX, but with less features.

The core ODE library isn't necessarily more lightweight: its collision detection and rigid body dynamics code size should be similar to Bullet.

Here are some lacking features of ODE from my perspective:

1) ODE lacks warmstarting of contact constraints, so ODE should have inferior contact/stacking stability than Bullet or PhysX
2) ODE doesn't have proper convex hull collision detection, which is a desired feature
3) ODE, Bullet and PhysX use the same algorithm for the constaint solver (PGS iterative LCP solver) but Bullet's constraint solver is SIMD optimized so it should be faster
4) ODE doesn't have a PlayStation 3 Cell SPU optimized version, Bullet and PhysX do
5) Bullet is written in a more modular fashion than ODE, so it is easier to replace or customize parts of the engine
6) ODE doesn't provide physics authoring plugins for Maya, 3ds Max , Blender etc. Bullet and PhysX do

On the good side for ODE, it has an additional direct constraint solver (dWorldStep based on a Dantzig LCP solver) that Bullet or PhysX doesn't have yet, and its simple C API is attractive to many and makes scripting language bindings easier.

It would be interesting to figure out why your test shows those timings for integration, there might be some issue that can be fixed.

If you want to share more findings, please let us know.
Thanks,
Erwin

Statistics: Posted by Erwin Coumans — Tue Aug 10, 2010 8:27 pm

Re: Bullet Vs PhysX Vs ODE Restitution question

2010-08-10T19:07:32+00:00

Ok, I made sure that I hadn't compiled Bullet with debug info enabled, and although I was positive i had disabled it, the libs I produced this time round were half the size.

ODE and Bullet are now more comparable, with ODE mostly producing figures in the region of low e-06 and high e-07 and bullet mid to high e-06, certainly closer than before.

I also totally nuked my PhysX SDK and re-installed everything just to make sure I hadn't compiled a dodgy lib or DLL at some point and forgotten about it. Anyway I am now seeing PhysX produce results in the mid to high e-05. So faster than before, but still significantly slower than Bullet or ODE!

I can upload the frameworks if anybody wants me to, but really I suppose my "problem" with Bullet is resolved, the difference between them is now small enough that it can be explained away simply through implementation. As I understand it, ODE is generally a more lightweight library than Bullet or PhysX, but with less features.

I was wondering though, can anybody explain the difference for PhysX? I know its a black box library so anything anyone can offer would be speculation, but I'd be interested to hear peoples thoughts.

Also, let me know if anybody wants me to upload the frameworks.

Thanks again.

Statistics: Posted by TriplVing — Tue Aug 10, 2010 7:07 pm