The evolution of PhysX (12/12) - Final test and conclusion

This last test (“SeaOfStaticBoxes3”) didn’t fit in any category, so I kept it for the end. It does not actually do anything, it only creates a massive amount of static boxes (255*255). There is otherwise no dynamic objects in the scene, nothing to simulate at all.

There are 2 things to notice here. The first one is memory usage. We went from 94Mb to 54Mb to 39Mb, from one PhysX version to another. That’s the right direction here!

The other thing is the time it takes to simulate an empty scene. As you can see, it doesn’t take much time with PhysX – as it should. Bullet however, for some reason, takes a massive amount of time here. On my home PC, Bullet takes about 34ms (!?) to simulate this empty scene. I double-checked everything, looking for something I did wrong, but it turns out the problem has already been reported on the Bullet forums. I think this should be fixed and work out-of-the-box.

In any case, I am not here to fix Bullet issues. The point is simply, again, that contrary to what people may still believe, PhysX is actually very optimized and a perfectly fine CPU physics engine. In fact, if some competitors would not prevent me from publishing the results, I would happily show you that it often beats everybody else. I invite curious readers to create their own benchmarks and see for themselves.

—-

This report is currently incomplete: it did not talk about CCD, or multithreaded simulations, or overlap tests. It also barely scratched the surface of what these physics engines have to offer: I did not talk about character controllers, vehicles, the performance of binary deserialization, or any of those more advanced topics.

As you can easily imagine, I’d need to write a book to cover all this, not just some blog posts.

However I think these posts may reach their limited goal, which is simply to show with very basic tests that:

  • PhysX is getting faster all the time
  • PhysX is very well optimized, thank you very much

7 Responses to “The evolution of PhysX (12/12) - Final test and conclusion”



  1. Bram Stolk Says:

    Did you run any OpenDE tests?

  2. admin Says:

    No. It would be nice to add ODE, Newton, etc, but I just don’t have time. It takes forever to support just the ones I listed. It’s on my TODO list though, but very low priority so far.

  3. mareknr Says:

    Hi. Thanks for interesting test. I have out of topic question and hope you give me some hint here. I would like to know if you can recommend me a good book which covers a topic of game physics. For the best a good PhysX book. I already ordered one for CUDA and PhysX is the next topic which I want to try to learn something interesting (from programming site). It can be advanced book. Thanks for answer.

  4. el0j Says:

    I’m probably just blind, but is PEEL available for download somewhere?

  5. vr Says:

    Great work. Two questions:

    Will you release the PEEL code? Sounds like a marvelous tool for comparing physics engines.

    Curious, will you do any quality tests? Energy conservation, constraint errors (residuals) etc.?

  6. Erwin Coumans Says:

    Wait for Bullet 3.x, there will be a multi-threaded CPU version too :)

    http://www.youtube.com/v/ZkF4yMmP0R8

  7. Erwin Coumans Says:

    Hi Pierre,

    I double checked the 34ms Bullet issue for 255*255 static boxes.
    It is not really bug, but a feature :)

    Can you make the following call to Bullet after initializing the world?

    world->setForceUpdateAllAabbs(false);

    Also make sure to add the static boxes using world->addRigidBody. That way, the collision filter group & mask == 0, so no pairs are added.

    That should solve the performance issue. I agree that the default settings are not optimal, and it is too easy to shoot yourself in the foot with Bullet.

    Thanks for sharing the tests. There might be some easy things to improve the Bullet performance a bit, I’m offering some free consultancy if you send me the test by email :)

shopfr.org cialis