Tracking the development of the BlenderPeople script suite.
Saturday, April 29, 2006
Okay -- I couldn't wait for next week. Here's a video...
1.5MB Xvid video -- 20 seconds
I made the walkcycle a bit goofy, with a lot of back and forth sway, as well as the right arm held up and in, as though injured, just to show off how this thing uses YOUR walkcycle, with all of your nice secondary motion, with footsteps that lock down to the ground with absolutely zero slipping.
I'm really excited. This is the solution I needed to the killer problem that vexed me for months.
As for implementation within BlenderPeople, each activity (walk, run, attack, flee, etc.) can be associated with an arbitrary number of Actions. So, you could have, say, four different style walkcycles for a single class of Actor. When it autowalks, each half-step could draw from a different random Action, chosen from it's list of availables, giving you great non-repetitive motion.
Of course, the Action Noise bit I'm working on will do something similar, so...
Friday, April 28, 2006
Success. The hybrid method works. You make a nice walkcycle. You set your parameters (foot bone names, step length/height, l/r foot locked-on-ground frames with action) and hit Go. It's that simple.
Right now I'm working on tweaking the timing, as I think the whole thing is off by 1/4 of a cycle. Other than that, though it works.
If I don't get to make a demo video this weekend (which I probably won't as I have carpentry, plumbing and electrical work ahead of me), I'll make one early next week.
Thursday, April 27, 2006
People interested in using Match Bone, Action Baking and/or the new Multiply NLA mode can get a testing build from here (Windows only):http://www.blender.org/forum/viewtopic.php?t=8184
The non-windows world will have to get the patch and build their own:http://projects.blender.org/tracker/?func=detail&aid=3634&group_id=9&atid=127
If you do try it and find it useful, make some noise about it so the patch gets reviewed and added to the main release!
Answer to question from comments: the strips will be seperate for your convenience. The final solution to character anim in BlenderPeople, though will give an option to burn each Actor's NLA into a single Action for quicker evaluation once you're happy.
Finally decided on a hybrid workflow for automated walking. The reason I went with completely generated walking in the first place was that just using a walkcycle and repeating it appropriately along the length of the animation didn't allow your Actors to drift to the side as they walked, or to stop then start, or to walk backwards.
A system that generates everything itself, though, will be necessarily restrictive, as it will only function properly for a specifically designed rig, and will most likely lack the niceties of hero-level animation.
So here's the final (I think) workflow:
1. Create in-place walkcycle as an Action.
2. To the script, you provide:
..a. step length
..b. step height
..c. names of left and right foot controller bones
..d. frame ranges, within the action for:
....1. left foot on ground
....2. right foot on ground
....3. left foot proceeding
....4. right foot proceeding
3. Keyframe object-level motion of your Armature
4. Run script
5. Goggle in amazement!
When the script runs, it will ignore the keys you set for the l/r foot controller bones, and create new keys for them, per the previous method demonstrated a couple of weeks ago. As it does this, it will create a list of frames for l/r foot on ground and l/r foot proceeding. Then, it creates another action, in Multiply mode, which contains snippets of the walkcycle action, matching frame ranges between the user's definitions from step 2. above, and it's own generated list.
The end result will be two actions in NLA, one that contains overall translation in space for the whole armature, as well as keyframed foot motion. The second contains properly timed clips of the full walkcycle action. When put together with Multiply NLA mode, the effect will be of automated walking, using a combination of generated foot keyframes, and arm and secondary motion keys from the Action.
It sounds more complicated than it will be in practice, simply because I'm describing the process in detail here to help solidify my thinking.
User makes a walkcycle, points to foot bones, and defines four frame ranges. That's it. I'll probably start coding on this tomorrow.
Saturday, April 22, 2006
(That sounds a lot dumber in print than if you'd been here a few minutes ago and actually heard me say it.)
The Multiply mode that I added to NLA compositing may have saved the day for autowalking. It turns out that it lets you do something that didn't work before: design an in-place walk (or run or hop) cycle, at an arbitrary level of complexity, and then have that cycle executed along the motion path generated by another NLA strip. If you did this with the already existing Add mode (or the regular one), it wouldn't work at all. But it does with Multiply.
No videos, because it's not ready yet, and it'll require a bit of poking around in the sources. But I'm much better armed these days than when I ventured that direction a year and a half ago.
I would LOOOOOVE to get this problem solved by the end of May, so I can put together a great demo for SIGGRAPH at the end of July. It may not be feasible with everything else I have going on right now, but it's a goal, and goals are good.
Wednesday, April 19, 2006
1. Although I've had a certain degree of success with automated walking, I'm abandoning this particular approach. First, key generation for quaternions in Blender can give inconsistent results, leading to armature flipping, as many people who've done character animation can attest. This makes the Action Baking portion of this a bit problematic. Blender simply needs better locomotion tools, and a half-assed python script isn't going to cut it. I came to this conclusion after realizing that my solution became narrower and narrower in scope with each revision. New direction for better locomotion:
Designation in Action-based walk-cycle of which bones contact the ground and frame ranges during which they should be slip-less. I'm going to try to use that info in conjuction with the Repeat function of NLA strips to generate good, non-slipping animation. The benefit of this method is that you can make your walkcycle arbitrarily complex (or simple), including all kinds of nice, keyframed secondary motion for realism. The downside is that stride lengths that vary with velocity will mostly be out. Or maybe not. I'm still trying to figure that one out.
2. I'm enabling comments from here on out in this blog. If you're following the production of BlenderPeople, please
leave me a note! The emails and messages I've received from people who follow this have been all that has kept me interested in the project at times. Giving out love is free, people!
Wednesday, April 12, 2006
Hits have gone way up on the blog since I've started working on autowalking again...
So, just to let you know, the walking is great... variable stride length at speed extremes is in, "max air time" is in for very short distances, so feet don't hover in the air forever, the rig keeps getting better/more optimized.
What I've been working on for the past week and a half is running. When Actor velocity exceeds a threshold, run animation is generated instead of walk. There is significantly more secondary motion generated when running, which means more keys, which means harder to automate. Actually, I'm finding the primary running motion harder to automate. But it's coming along.
When I have something that doesn't look like crap, I'll post it.
Tuesday, April 04, 2006
This is the final mesh and textures that will "ship" with BlenderPeople when it's ready.
I designed it to look nice at long distances with all subsurfing turned off, but be good enough for decent closeups, as long as motion blur is involved. Non-instanced vert count of around 5000.Click here for 5.5MB Divx Spin of the model
Gosh I'd like it if someone (cessen!) implemented the MakeHuman subsurface scattering directly into a node for materials.
I'd reached the limit at which I was able to evaluate character motion based on bones alone. What looks good on bones-only to me looked anywhere from okay to laughably bad when paired with a mesh. So, I had to get a good mesh before I proceed.
And now, I will... proceed.
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