Tracking the development of the BlenderPeople script suite.
Friday, December 23, 2005
Since the videos for the previous MatchMove demo are broken, I'll put up the latest demos...
This video shows what happens without MatchMoving between NLA strips. Notice after the walkcycle finishes how both feet slide along the ground into the first position of the next strip. And, more obviously, how the actor slides back to do the second backflip. To get it to work properly, you'd have to do some heavy duty and time-consuming keyframing at the object-level to get it to look at least close to correct:http://home.comcast.net/~harkyman/NLAtestnoMB.mov
The only difference from a user standpoint between this clip and the last one is that MatchMove was enabled and a match bone set for each NLA strip. Total time to set, about thirty seconds.http://home.comcast.net/~harkyman/NLAtest.mov
Please excuse the completely crappy animation in the actions.
Also, thanks to Orange for letting me play with this butt-kicking rig for MatchMove testing.
Thursday, December 22, 2005
Good News on Blender Animation
Someone has finally stepped up to the Blender character animation plate and written the two features that BlenderPeople deperately needed in order to proceed: MatchMove and Action Baking.
As I've explained before in this blog, MatchMove is a feature that allows animators to put together disparate clips of character animation and have them transition seamlessly. This isn't a huge deal for high-quality front row feature character animation, because all of that stuff is lovingly crafted and tweaked by hand. What it's needed for is "generated" animation. For example, if a script was using a "Walk" action to make a character walk around, and wanted to make it flow into a "Fight" action and then a "Die" action, all automatically, this would be very useful. Using MatchMove between the "Walk" and "Fight" actions moves the character smoothly between the last position in "Walk" and the first one in "Fight" without it's feet sliding on the ground.
One consequence of generating animation like this is that you might have forty, fifty, or even a hundred different actions stacked and layered for a single character. There might be a thousand different characters. Every time Blender moves to a new frame then, it has to calculate the results of (in this case) a hundred thousand actions. That might take a while. Action Baking allows you to "Bake" the hundred different layered actions that have been built up by the generative animation process into a single master action that is simple and quick to evaluate. You just sped yourself up by two orders of magnitude.
So, cheers go out to the developer who wrote these new tools for Blender users around the world... oh... it was me. Yeah. I'd been working on MatchMove for a while, and had begun thinking about Action Baking when I noticed that the Orange project's
technical director was thinking about the same thing. Apparently the animators at the Orange studio had a bunch of layered animation built, and they wanted to start refining it. But it's tough to refine iterative walk cycles and character motion in layers. It's much easier to do it in a single action. So, I took several hours, taught myself a little bit more about matrix math, bone v. world v. object spaces, and double linked lists, and made the feature. It hasn't been combat tested, but I think it works. I'm sure the code is crap and Ton will probably have to rewrite half of it anyway...
So thanks to Toni Alatalo (technical director) for giving me the opportunity to add such cool functionality to Blender. And good news for BlenderPeople!
SQLite/Python Version Down The Toilet
I've finished the prototype version of BlenderPeople that uses SQLite in combination with local Python lists and dictionaries to mimic the functionality formerly achieved with MySQL. The advantage is that it is almost zero configuration. Download and install Python 2.4, if you haven't already. DLaI SQLite for Python. Run BlenderPeople. It works.
The problem is that it's really slow. SQLite lacks "advanced" math functions like square root, but more importantly, it does not have trig functions. Trig is an absolute necessity for BlenderPeople, because you often want to select, for example, "the nearest opponent to my current Actor, within his field of view." That requires both square root and trig (BTW, I know you can distance search on just the square, and I do, but there are other times when you don't want to pre- or post-process your query results). One nice thing about the SQLite Python implementation is that it's a piece of cake to add those functions. So I did. You simply send a query to SQLite defining the function name and it's reference in your Python code. Then make a Python function that does what you want.
I did all of that for the necessary math and ran it. It was slow like a two-legged dog. Rounds of calculation that were taking around one second in the MySQL implementation were taking as long as fifteen seconds with SQLite. Actually, it was taking almost ninety seconds per round when I first implemented, but that was due to the way SQLite writes every transaction to disk immediately, and you have to manage your connection commits more carefully than with MySQL.
So, I moved on to step 2 of the project, which was using straight Python to do a lot of the searching and sorting work. If going from Blender->Python->SQLite->PythonMath was too slow, I figured I'd just do all the math right in Python and skip the superfluous connections. Where before, I would access the database several times for each Actor in a turn, writing changes back immediately, I would now access the DB only once per turn, do all searching/sorting/filtering on lists directly in Python, then write the result back at the end of the turn. That should remove almost all bottlenecks thrown up by SQLite.
It turns out, though, that SQLite wasn't the problem. It was Python. Round times using the pure Python method were comparable to the previous SQLite times. Using lists in Python only shaved about 10% off the slow SQLite implementation.
Unfortunately, I'm going to have to abandon this project. For a 1,000 Actor simulation, I can get times of around thirty seconds per round on my system (Athlon XP 1800 w/512MB RAM), which is pretty outdated by today's standards. That means the Python/SQLite combo version would give me times of around five minutes per turn. That's way to slow to be useful. One of the cool things about BlenderPeople is that it's fast enough that you can sit there, watch it develop, adjust some settings, etc., and continue the simulation. With five minutes rounds, that becomes impractical and significantly less useful.
My next step is in trying to streamline the MySQL installation and configuration process, which has gone from fairly simple when I started BlenderPeople, to a laborious hulking nightmare these days.
Friday, December 02, 2005
I said I'd post a video today, so here it is. A little explanation first.
This video shows what happens when you have two actions, a forward leap, and the world's worst side kick, put together in NLA. In this example, I actually made the whole rig move forward within the leap action, instead of doing the thing where you keyframe the whole deal over a non-moving point. I find it very difficult to visualize the proper forward motion that way. Not that this is the greatest forward motion ever made - my new rig is still crap, etc. Anyway, here is what you get:Without MatchBone; Quicktime 3 MB
Yeah. That shows why something like this is needed.
Here is it with Matchbones set for the right foot base, both times:With MatchBone - hurray! Quicktime 3 MB
A couple of things to note - the B-Bones go kind of crazy in the MatchBone example, and you'll notice that the dashed guidelines for parent relationships are out of place as well. From old mailing list stuff, I recall that both B-Bones and the guidelines have their own drawing routines, so I'll just have to put my code in them like I did with the main object routine.
So, I've added a GUI to the feature (it's ridiculously simple), and seem to have solved the mode problem I was having with the NLA window. The only things left to do are to fix the aforementioned drawing issues, and cause the MatchBone calcs to autoupdate when you fiddle with the NLA, as opposed to activating it manually, which is what I'm doing now.
I'd have to declare success!
Thursday, December 01, 2005
Started back into the BlenderPeople code tonight. I'm seeing how quickly I can revamp the code for using SQLite, as opposed to MySQL. It's not really that different, as it uses the same DB API 2 calls that MySQLdb used. Almost of the SQL in BP should work as is, but I've found that my DB initialization code was MySQL-specific. So, it seems that writing it for the simplest case (SQLite) will work very well on the step to generalization for all databases. In the end, I'd like to have it look for SQLite first, and failing that, simply asking the user for a connection string to their DB of choice. That would be great.
The other good news is that I'm running Python 2.4 on my system, alongside Blender 2.40 RC2, and BlenderPeople worked only after the simplest of tweaks. Nothing was broken, and I didn't even get any deprecation warnings. I think there are some new, faster and more reliable ways to read meshes (which will help with generating the Ground Tree) and to set keyframes into IPOs, which I hope to look into and incorporate into the code.
I'll be doing a lot of speed testing, as I'm considering this a "code cleanup" time. It'll help me get familiar with the code again, as lately, my brain's been riddled with c and php.
Right now, I can't say when I'm going to have a working release available. There are too many variables that affect my time at the moment. But instead of generating a time table, I'll just mention what I have to do: SQLite conversion (with accompanying installation instructions); finish DB abstraction; code updates for new Blender Python API; performance testing.
Also, the MatchBone feature of which I spoke the other day is smoking right along. Today, I added support for BlendIn. It compiled and worked on the first try, and I have to say that seeing the armatures whip around and smoothly align themselves due to the new feature completely made my day. I've wanted to see that happen for soooo long, and now it finally works. IMO, the biggest obstacle to this becoming a great feature now is the acceptance of the code into the main Blender release tree. I just don't know it it's of good enough quality. For anyone interested in seeing it, I'll make a demo video tomorrow and post a link.
02/01/2004 - 02/29/2004
04/01/2004 - 04/30/2004
05/01/2004 - 05/31/2004
06/01/2004 - 06/30/2004
07/01/2004 - 07/31/2004
08/01/2004 - 08/31/2004
09/01/2004 - 09/30/2004
11/01/2004 - 11/30/2004
12/01/2004 - 12/31/2004
01/01/2005 - 01/31/2005
02/01/2005 - 02/28/2005
06/01/2005 - 06/30/2005
09/01/2005 - 09/30/2005
10/01/2005 - 10/31/2005
11/01/2005 - 11/30/2005
12/01/2005 - 12/31/2005
01/01/2006 - 01/31/2006
03/01/2006 - 03/31/2006
04/01/2006 - 04/30/2006
05/01/2006 - 05/31/2006
06/01/2006 - 06/30/2006
07/01/2006 - 07/31/2006
08/01/2006 - 08/31/2006
09/01/2006 - 09/30/2006
10/01/2006 - 10/31/2006
11/01/2006 - 11/30/2006