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...
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).
Post a Comment