Wednesday, November 27, 2013

OpenDE and Bullet

I would like my simulation of tracked vehicles to be faster, so it could possible run on mobile hardware. Currently, you need a modern desktop to do it, at the bare minimum my mid 2011 MacBook Air is even struggling. The 1.7 GHz Intel Core i5 struggles to run the physics simulation when a lot of dirt is active. Additionally, the integrated graphics HD 3000 struggles to render it at full screen resolution.

OpenDE lacks support for SIMD processing. However, there is another physics library, Bullet, which is streamlined for things like Neon, Cell SPU, multithreading, etc. And there is even an OpenCL version. Here I try to summarize the implications of a potential switch:

✪ Bullet builds out of box for all platforms with minimal dependencies. The dependencies it has, come included.
✪ Bullet supports cylinders, capsule, boxes, meshes: all the shapes I use with OpenDE.
✪ Bullet supports (even though it is missing from the manual) the OpenDE style hinge2 joint, crucial for my vehicle simulations.
✪ Bullet uses OpenDE's ERP (Error Reduction Parameter) and CFM (Constraint Force Mixing).
✪ Bullet comes with SIMD implementations, so should be faster in theory. It's probably still AoS though, and not SoA.
☹ Bullet has a C++ API, not a C API.
☹ Bullet lacks the concept of collision spaces to quickly ignore collisions within spaces.
☹ Bullet advices against differences in mass. OpenDE does this too, but at least I know OpenDE handles it well. You can never create a realistic vehicle simulation if your wheels have weigh the same as the chassis, no matter what you do.
☹ The bulk of my game development comes down to endless tuning of the physics parameters. Switching physics library means retuning pretty much everything.

I am still on the fence about this, and will probably hold off on a port. Maybe it would be better to use it in case I start a project from scratch.


Here is How Wolfire switched from OpenDE to Bullet. Also, Bullet3 seems yet to be released, and its development branch seems to still lack the C-API unfortunately.


I switched! Colliding and solving are both multi-threaded, which is great. Unlike ODE, Bullet does proper collision detection on convex-versus-convex. Something that tripped me up: Bullet's transformation matrices have the axes stored as columns, not as rows which I am used to.


  1. - large mass ratio: would guess that's the case for all phys engine (being a floating point inaccurracy thing )

    - Endless tuning: no easy way out... Note that bullet debugging is very slick, once you implemented the "debugDrawer" interface and that you can use/test blender bullet edition capabilities as well as Best would be having which is a real life saver, especially on mobile.

  2. Thanks Tuan, for all the pointers, here and on bullet forum.

    I'm not sure the mass-ratio is strictly a FP precision thing.
    If it was, then using doubles instead of floats would solve it.

    Yeah, I never made my sims tuneable on the fly, but I did fantasize about hooking up a MIDI device for real time tweaks. Can you imagine turning a knob on this to change tyre/road friction, e.g.?
    Never got around to doing this, but I should.

    1. I thought the Mass ratio thing was inherent to all solvers, about precision error accumulation, and all, and float/double imprecision weren't helping there, as simulation equation imprecisions cannot counter its bad effects. But It's 2-3 yrs without doing physics coding some it's from memory... You could try to revive that old thread and check if anything new solved that.

      Love the midi physical knob idea, steampunk retro style tweaking, would make it really nice and fun.
      Note that you could also hookup a http server and drive that from a web broswser (some code around about debug visu for that here
      And there, in the web interface, you could put knobs ;)

  3. Hi Bram, thanks for sharing.

    As Bullet author, I like to improve the library to help users. There is some work-in-progress that will hopefully address your concerns:

    0) The Bullet 2.x default constraint solver is the same as the OpenDE quickstep solver, but has several improvements. So if you use quickstep, the transition should be smooth. The OpenDE 'worldstep' Dantzig solver is also in Bullet 2.82.

    1) Bullet 2.82 has Featherstone articulated bodies. Although new and experimental, they can become useful for vehicles, tanks and ragdolls. It also helps the mass ration issue for bodies within the same multi-body.

    2) Bullet 2.x trunk has improved (MLCP) constraint solvers that address the mass ratio issue. The NNCG solver, based on PGS/SI, like OpenDE quickstep, is promising, it has better convergence which helps mass ratio support. There is also a Lemke solver work-in-progress, but it is currently even slower than Dantzig (OpenDE worldstep)

    3) Bullet 3.x will get a C API

    4) Bullet 3.x OpenCL is not useful in gaming at the moment, but its parallel/AoS optimization will help the upcoming CPU version

    Thanks for helping the Bullet project with feedback,