Bullet SoC - From the trenches

I've spent most of yesterday trying to track down some of the various problems afflicting the simulation system to little avail (as mentioned in an earlier post).

What is becoming apparent is that navigating (and trying to understand) Bullet's API is becoming quite an exercise in itself at times. Through this process, I'm really starting to appreciate the extent that C++ can be used to obfuscate the meaning of or the ability to easily find code to understand it. Furthermore, I still don't think that doxygen/javadoc-like tools are totally up to the task of improving this situation a lot of the time, but serve to introduce their own layers of complexity into the situation (* details to come in a future post when I get around to it).




While I haven't really run into templates much here (thus avoiding a bit more head banging agony that that would have induced), I have wasted time jumping between .h and .cpp files (headers and actual code) trying to find the actual code for a lot of things. Also, there are some confusing lacks of symmetry in the API design (e.g. there are separate getLinear*() and getAngular*() methods, where * is Damping or SleepingThreshold, but there are only setDamping() and setSleepingThreshold() calls to set both of these at once), which is not helped by the lack of some logical organisation of method calls in the class definitions.This has meant that trying to find my way around the API looking for things is a bit more difficult.

To be fair, Bullet does have Doxygen-created API reference pages, and these do tell which file the code is actually in at times. However, in places, just a few comments on what to expect from some of the API methods would be helpful. Also, these docs generally don't list the inherited methods too, so finding out what can be used is a bit tricky...

On to today's news then...
To avoid wasting another day slogging through API references and trying to fix these annoying bugs, I've decided to spend a bit more time actually working on the Blender side today.

First off, I spent time working on the RNA wrapping for Rigid Body settings, refining this so that more settings are exposed. Also, another goal was to get these hooked up to the relevant API calls so that changes can get flushed accordingly, allowing these settings to be animated (by the standard Animation System, through RNA) without having to specifically have a syncing step as part of the Rigid Body sim eval.

Leading on from this, I've started to do a cleanup of some of the code so far to ready it for the next steps. This should make it possible to get some of the other settings hooked up too (namely collision shapes being able to be changed). Also, attempts at fixing debugging the playback issue were starting to leave things getting a bit murky...

Addendum
While writing this post, I've come to the conclusion that maybe Bullet simply can't be relied on to do handle the backward simulation cases I've been hoping it could take care of.

During a quick test this afternoon, I accidentally found that backwards playback was actually working now, but only worked when nothing needed to collide. This means that it's practically useless, since most situations DO need collisions (that would probably need to be scrubbed to double-check finer details) or else users would likely just hand-animate the whole thing. Also, the reliability of the results there were hugely dependent on how you scrubbed/change the frame. Jumping by certain intervals often affected the results in quite a bad way (i.e. completely unpredictable results).

So, as part of the code cleanup (or afterwards, whichever is more convenient), it looks like I'm going to have to take into account setting up motion-caches too. In my original plans, I was going to do this as a later stage as a bit of an accessory for complex sims for performance reasons, but it looks like it might be needed for even simple ones now to get meet some usability criteria I set for tools in Blender (despite playback so far being fast enough to be acceptable). Hopefully I can leverage Blender's existing PointCache system to bake out transform matrices to do this.

Unfortunately, I'm fairly sure that going down this route means that I'm also going to have to also tackle some of the major shabbiness in this area too which makes it feel less quite flaky in practical usage a bit. We'll see how things go :)