Mapping Motion Capture

Now that you have your motion data recorded, the real work begins. Good motion capture is made or broken once you get the data.

Motion capture, until recently, required you to build your skeleton and character around your captured performer. Thanks to re-scaling and mapping tools such as House of Move's Dominatrix, artists now have the capability to adjust the proportions of a captured performer to that of a pre-defined skeleton. Obviously, picking a performer that is close to your characters proportions will help add credibility to your motion.

Layered node systems such as Dominatrix also allow for the ability to edit motion capture in a non-destructive fashion but the additional transform nodes, as well as the data density of the original mocap makes using this hierarchy as your final in-game skeleton difficult. Also, the joint orientations of your previously constructed character's skeleton may not align with the capture skeleton. For instance, the bending of the elbow may be the +X channel on the capture skeleton, and -Z on the character's skeleton. On top of that, due to the realities of Euler math, what appears to be one axis of motion may be two or all three.

Using some basic math and scripting, you can determine the difference between the axis's of each joint, both the XYZ orientation and any angular variations. You can then, frame by frame, get the rotational values of the captured data, apply the difference to it, and write that to the target character's skeleton.

The Animation Workflow

On top of all the concerns an artist has getting characters to move the way you want, game animation has special concerns. Among these, memory footprint and cyclic motion are perhaps the two most significant. Unfortunately, the data provided by motion capture is anathema to both of these qualities.

Motion capture provides a keyframe for every joint, at every frame. This data density hampers editing of motion in any form. If at any frame you need to alter the motion, that keyframe is sandwiched between other keys. This creates a spike in the motion curve, which leads to a twitch in the motion.

	Figure 1: Animation spike caused by setting new key directly on motion capture skeleton.

Deleting the keyframes on either side of the frame we need to alter, smoothes out the spike, but still provides a noticeable twitch. While these alterations and twitches are problematic in the middle of an animation curve, the can be devastating to a cyclic motion. In order to provide a cleanly looping motion, the start and end pose have to align, as well as the in and out tangency of those poses. While we can continue to delete and tweak keys, this can be a laborious, time consuming process. While some off-the-shelf software provide tolerance based curve simplification, this often provides even more convoluted results, removes all the subtleties motion capture provides, or simply doesn't work.

The other major problem presented by this data density is the memory footprint of animations. For example, a simple skeleton with only 24 joints would require 4320 rotational keys per second at a frame rate of 60. Extrapolate that across the amount of animation a character requires, and suddenly a whole lot of data needs to be held in memory. Dedicating 40% of your available RAM for one characters motion wouldn't be acceptable in any game, even a character centric genre like fighting.

Animations created in the traditional method obviously do not suffer from this data density. Keyframes are added only where they are needed. Skilled animators can tweak and adjust the in and out tangency of the keys to optimum effect.

The question then arises, why do we insist on chiseling away at motion capture data until it's usable, when we could just add what we need?