One nice thing about motion capture is how fast you can turn around animations, or you'd think. The idea is that you start your animation past the blocking stage; mocap sort of gives that to you. There is a lot of work involved in making it loop properly, but the cleanup stage feels an awful like blocking, just with a whole lot of keys. But occasionally you'll come across an animation that needs heavier keying. This is an example where mocap didn't give me what I wanted.
To start off, I was never really happy with the original data we recorded. The actor didn't quite embody the character I was going for, and I didn't actively realize it until late in the process. We eventually re-recorded the data, this time with myself as the actor, and got a better performance for the character, which helped. But then there was the problem with movement speed. We chose to use root motion on the project, instead of having motion controlled programatically. This means the way the character feels is controlled by the animators, not the designers; that means animation cycles are spent exporting over and over for the design team. Mistake number two.
I ended up spending a week tweaking all of the 4 run cycles (each direction) to increase the speed as much as possible without breaking the rig. And in-between all of that, I was constantly checking it in UDK to see how it worked out. By the end of it, I essentially doubled the move-speed in each direction by dropping the character's hips and increasing stride length across the board.
After all of that, I can't tell what would have taken longer, motion capture or keyframe animation. I'd like to think that mocap was still a bit quicker, because we may have run into the same problems with in-game speed; though it would have been really easy to check early on with keyframe animation.
For good measure, here are a few more mixed animations. The first video is completely keyed, except for the idle. The second video uses mocap data at the beginning and end.
No comments:
Post a Comment