From comments received in response to my "Bullet Todo List" post last week, there were several main themes coming through:
1) Baking, especially via Alembic support, is a very desirable prospect.
2) Phymec's work on fracturing, etc. would be nice to integrate with this (and also BGE) at some point. This fits in the "fancy stuff" basket
3) Interactions between animated objects and physics sims (and also animating when physics sims work) is an issue that many people care about. IIRC, there is some support for this already, though your mileage with overriding simulated objects mid-sim may vary.
4) Many are just dying to get their hands on this functionality.
This last point I'll address here and now :)
For the impatient or those familiar with the Git drill already, head on down to:
https://gitorious.org/~aligorith/blenderprojects/aligoriths-blender.git and grab the "BulletDev" branch
or checkout the links on:
After several failed attempts (ranging from using the wrong-style of repository paths, to GUI's that would silently stall but without any direct way of killing them, and topped off with Git trying to compress down the entire 300mb of repository and send that down the interwebs), I've finally managed to upload the Blender-Bullet integration code as a branch on Gitorious.
We won't get into the debates of Git vs Mercurial, or GitHub vs Gitorious here (for the record, a "strongly compelling factor" here was the jesterKing had set up a mirror repository of SVN trunk on Gitorious, and number of other prominent Blender coders also kept stuff there too). The key thing is that it's not SVN and subject its pathetic excuse for a "merge" capability that we're dealing with here! While this may make a bit harder for a few of you out there to get your hands on this, at least it should be easier to keep it in sync with trunk (I've been doing this locally for a few days, and it really has been pain-free so far).
Getting the sources
AFAIK, this step is best performed from the command-line for now, unless you manage to get hold of an awesome Git-client, in which case, let me know ;)
1) Apparently, it should be possible to just grab yourself a copy of the code by doing:
git clone user@git-server:project_name.git -b branch_name /some/folder
So, you'd end up doing something like:
git clone firstname.lastname@example.org:~aligorith/blenderprojects/aligoriths-blender.git -b BulletDev bulletBlender
2) Alternatively, you could also just "clone" (*) the entire repository I've posted (which may come in handy for playing with some other stuff later).
(*) In terms of DVCS (distributed version control systems, of which Git is one), each local "working copy" has a full copy of the "repository" (i.e. all the commits/history, source code/etc., of the project). This means that you can do a lot of version-control stuff locally without an internet connection (e.g. make commits, check on who make a change or when that occurred, but also load up the code for other branches and/or create a few yourself and merge stuff between them very cheaply).
In other words, DVCS are what version control systems should have been from the beginning. However, be warned that most of us already have "brain damage" (to paraphase the Mercurial tutorial) from years of CVS/SVN exposure, so at times, these tools will end up doing your head in.
To grab any updates to the code that I make, perform a "git pull".
1) Command-line version:
2) Git GUI version:
The first time, do...
- Tools -> Add
- Name = "Get Bullet Updates", Command = "git pull"
Then, having done this
- Tools -> Get Bullet Updates
For now, only the Scons build system is officially supported for this. I personally can't stand CMake or the buildsystems that it outputs to, so you're on your on when it comes to using that vile POS.
The only really important thing to note is to remember that WITH_BF_BULLET should be enabled ;) But, that should really be obvious!
Now, for a few cautionary words:
1) The code as it stands is very unstable in places. In fact, I'm sure you'll find a way to crash it or get it to do some very weird things after just a few minutes
2) The "wall" RigidBody template is currently broken. Well, it might work, but it's just not registering properly anymore, and as a result of too many rounds of tinkering there in the past 2 years, I've lost track of what the latest method should be. Perhaps some updates to come in this area in future...
3) A few of my old SoC test files do not load up correctly anymore. So if you have some of your own, beware that they may not work. I do not know for certain why though.
4) Some of the Todo items may well mean that some parts of the implementation may have to change, taking whatever stuff you do with the current version with it. There will be no version-patching support for fixing up such changes in the interim. You have been warned. This is pre-alpha code!
Ok, enough of the serious stuff for now...