Bullet SoC - Coding begins

Over the past few days, I've started implementing the plans described. So far, it's more as a proof of concept/fleshing out of the design in practice to get a better handle of some of unforeseen problems (i.e. "how can I get Bullet to do this?!"). Or in other words, laying out the framework...

Photo: complex scaffolding at a building site in Hong Kong (near the "Avenue of Stars"). Crop of photo taken during vacations there in April this year.



Currently, my plan is to try and get a working prototype working and committed by Wednesday, with many rough edges still to be polished. So far, I've run up against the following issues:

• Can Bullet be told to back-step (instead of just doing the forward simulationStep() that is described everywhere)?  
• Surprisingly/thankfully yes! Albiet, I've found that numerical error appears to eventually get the better of it, and it seems to go back a few too many steps at first (test code based on the HelloWorld demo in Bullet sources is available on request). At least we can still be able to scrub sims for a result of sorts without resorting to complex caches :D
• How to leverage Blender's duplis system to allow instancing (aka act as a "cloner")?
• At this point, I'm starting to conclude that this idea may have to be dropped. The fact that the list of them dynamically created/destroyed as needed means that it is near impossible to get Bullet sims to affect them at all, since the matrices we can get out of Bullet will not be stored until render/viewport-drawing need them. While we could work around this a bit, it does add another layer of referential integrity hell that I'd like to avoid...

However, firstly, I'll be updating Blender's copy of Bullet to 2.76. Originally I was going to commit this in my own branch in case it causes too much breakage for Durian (though their separate branch should provide an adequate safety buffer), though I might commit into trunk instead for Moguri (also working on a SoC project) to use too.

If I was going to commit this upgrade to my branch, then this would have to wait till the prototype is working (to minimise the number of revisions I'd need to merge - see my post about why). However, if not, this might see the light of day in trunk as early as tomorrow (compiling/linking problems permitting).