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.

UPDATE

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.

UPDATE

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.

Making a mess

I call this composition "Making a mess." It takes a bit of manoeuvring, but after 15 minutes of playing in the sand, the landscape looks considerably changed.

But the sad news is, I am still having a hard time finding a game play design for it. I've got this incredibly advanced simulation technology, but that does not make a game in its self. Should I just hide some treasure in the mud, and have the player dig it up? Maybe with a "warmer" "colder" hint system? Do I create a fancier version of the "Yukon Gold" level in The Little Crane That Could? I don't know at this moment.

Then there is the problem of hardware platform. Mobile is far too underpowered to do this. Even my second generation Mac Book Air is struggling to get fluid frame rates. So PC then? Well, steam greenlighting is not working out for me. And Amazon's app store keeps rejecting my PC build of Little Crane v1. Should I shelf it for a few years, and release it for iOS9 when cpu performance has increased another order of magnitude?

Lean Code

I guess my code is pretty lean.
$ find ~/apps/LittleCrane -name \*.cpp -exec wc -l {} \; | awk '{total = total + $1}END{print total}'
19653

Compared to these monstrous code bases. This would designate my game as a 'simple iPhone game app' according to their classification. Also, I do not believe their assessment of the code size of a modern car.