BlenderPeople Development

Tracking the development of the BlenderPeople script suite.

Wednesday, January 25, 2006

One man development team + buying a house and moving = suspended development

I'll probably start working on it again in late March.

Thanks to everyone who's keeping tabs on this project. The number of hits the XML feed and main gets every month is one of the things that encourages me to keep working on this. (In the last two months, my personal and political blogs got linked from Instapundit twice and Michelle Malkin once, and the unusually high traffic from those avalanches still didn't top the monthly traffic totals for people checking out BlenderPeople!)

posted by Roland  # 5:55 AM (0) comments

Thursday, January 12, 2006

So, Matchbone is coded... whether it will ever see the light of day in an official release remains to be seen. Action Baking is coded also. Apparently the Orange studio has been using binaries provided by myself and others to use the feature, though actual patch languishes in the patch tracker, awaiting review by the main Blender coding team. I'm guessing that feature will make it into official release, although it may be heavily recoded by people more skilled and knowledgable by myself.

As I've considered the character animation challenges of BlenderPeople over the last few weeks, I've come to see the need for one more addition to Blender itself: stride support. Yes, Blender has limited stride support for walking along regular surfaces when using Path animation. But that is very restrictive, and not the most intuitive method of producing walking animation. It also requires tweaking (impossible without Action Baking) to make it look less repetitive. It's less than an ideal solution.

The other way to do something like BlenderPeople, and my original plan, is to simply use fractional repeats in NLA in conjunction with preset walkcycle Actions. This would work to a certain degree, but would call for extremely careful and restrictive creation of the initial Action, as feet would have to move at a constant rate, which is almost impossible to achieve. Even if that were done, Actors sometimes move sideways or even backwards to their orientation, which would be entirely unsupported by either StrideBones or simple NLA work.

Here's my proposal: a new kind of Action Strip, called a Walk Strip. Walk Strips are not associated with an Action, though. They create one. You add a Walk Strip, fill out the parameter panel with the appropriate bone names and values (heel and toe controllers for L and R, maximum heel heights, max forward reach, max backward reach, and max outside reach). You hit the "Walk" button on the panel and an Action is generated that has your rig walking to follow your keyframed object-level animation.

As you can set different values for left and right sides, you can make the walkcycle non-uniform. The system, as I'm designing it, is footstep-based, meaning that you could (potentially) show a visualization of the footprints and even move them around, causing the walk Action to recalculate. And in the end, you can bake the automated walkcycle Action just any other, allowing the careful refinement of the animation.

So, not like I needed it, but this my new quest. Advanced character walking tools for Blender.

posted by Roland  # 7:40 AM (0) comments

Monday, January 09, 2006

The Mac testing was a big fat failure. I managed to get Blender running with Python 2.4 on the Dual-G4, OS X 10.3.9 machine, as well as MySQLdb and MySQL 5. Tried BlenderPeople with a little test file, and it seemed a bit slow. Tried it with my 2,000 Actor test (which took 90 seconds per round on my Athlon XP 1800), and it took 341 seconds to process the round! Is the bottleneck in Blender, MacPython, MySQL, or MySQLdb? Don't know. And with that horrific performance, I don't even know if it's worth tracking down.


posted by Roland  # 12:07 PM (0) comments

Wednesday, January 04, 2006

I just finished working on a MySQL connection tester and configurator for BlenderPeople. The way it works is this: when you run BP, it checks to see if it has MySQL connection info stored. If not, it launches a little GUI that lets you put in host IP addresses, usernames and passwords, then tests the connection for you. Most of the people who had MySQL issues were having simple connectivity problems. This should make that easier to correct.

Anyway, after you get a successful connection, BP stores that particular info and uses it the next time you have a session.

I also added support for the Blender progress bar when running turns. I had done this originally, but something (I suspect a bPython bug) made things run significantly slower when using the progress bar. Not anymore. It updates on every hundredth actor, which seems to give nice feedback on both shorter and longer simulations.

Tomorrow, I'll be trying out the current BlenderPeople codebase on a Mac Dual G5 with 1GB of RAM. It'll be a great test of several things:

1. Easy of use regarding MySQL on different platforms. I don't have MySQL or MySQLdb installed on the Mac.

2. Good test for the new configurator.

3. I'm really eager to see what a modern machine does speedwise, especially a dual-processor one like this. I know that Blender itself is not multi-threaded, but I'm hoping that the system is smart enough to do the Blender/Py stuff on one proc, and leave the MySQL stuff to the other. If so, I would expect to see some dramatically low turn times.

I was doing a simple test tonight (Athlon XP1800, 0.5GB RAM) with 650 Actors, calculating a full second (24 frames) of motion in twenty-eight seconds. Not bad. It was taking three minutes, though, to make one second of motion for a 2,000 Actor sim, which is getting a little bit high for my tastes. I'm hoping the modern hardware will turn those times into cinders.

If I have time, I might throw the MySQL work onto a completely seperate Dual Xeon machine that's connected to the Mac via Gigabit Ethernet. In the past, running the db on a separate machine more than made up for the network downtime on 100BaseT, so this might be even better.

posted by Roland  # 8:21 PM (0) comments


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  

This page is powered by Blogger. Isn't yours?