Using mocap data driven skeletons to drive character controls
Eugene Lam
The goal of this guide is to help you bring motion capture data into traditional character rigs. The motivation behind this is the following. Mocap data is not directly usable for some situations. In these situations, mocap data must be edited. However, editing motion via FK skeleton is both tedious and counterintuitive compared to the controls available in traditional character rigs. This calls for a transfer between mocap skeletons and character rigs.
This guide assumes that the motion capture data used is process by the Vicon system and that the character rigs exist in the Maya animation environment. It also assumes that the reader is familiar with Maya basics and has access to references about additional concepts.
1. Importing mocap data
With the Maya V-file Reader loaded, import a V-file. This generates a group of animated locators, each corresponding to a joint in the subject skeleton. The locators represent both the subject’s dimensions and motion over time. However, the locators are all parented under one group, so their arrangement does not resemble the mocap subject.
2. Driving a skeleton with mocap data
To address this, create a skeleton with dimensions and joint rotations that match those of the locators imported via the V-file. This can be done by using the guide and the scripts by Kolliopoulos[1]. In essence, you (or a script) create a joint for each locator and connect the joint translation and rotation attributes from those on the corresponding locator. This skeleton will be referred to as the mocap skeleton.
3. Driving character controls with a skeleton
3a. Repositioning Joints
The mocap skeleton has the proportions and motion of the mocap subject. Most likely, these proportions are different than those of the target character. If all we needed from the mocap skeleton were the joint angles, this would be fine. However, character controls do not usually share the same structure as mocap skeletons. Moreover, a good majority of the controls require translational information which cannot be determined solely by joint angles. We can approximate this translational information by changing the proportions of the mocap skeleton to match that of the target character.
To change the proportions of the mocap skeleton, reposition its joints. Because most joints in the mocap skeleton lie on one of its parent’s local axes, this is easy to do.
Repositioning the mocap skeleton joints has the effect of distorting the motion of the skeleton, particularly the feet and the hands. To eliminate feet sliding, the translate channels of the locator corresponding to the pelvis joint (the mocap skeleton root) can be scaled in proportion to the changes made to the leg joints. Penetration of the hands is more difficult to eliminate because the hands often interact with other objects in the scene which may be impossible to reposition.
While repositioning the mocap skeleton joints, be sure that the position of the back joint matches the pivot of the character’s back. This way, when the mocap back bends, it will be possible to match the back of the character with it.
3b. Creating constraints
Once the mocap skeleton proportions have been changed to match those of the target character, its joints can then be used to provide the translational information required by the controls of the character rig. To use the mocap skeleton to drive the controls, constrain each control to a corresponding joint on the mocap skeleton.
Driving the translation of translate controls (shown above as diamonds, squares and trapezoids) is straight forward in Maya. Simply point-constrain each translate control to the corresponding mocap skeleton joint. In MEL script:
select
-r rhumerus ;
select
-tgl shoulderR_con ;
pointConstraint
-offset 0 0 0 -weight 1;
One requirement is that the pivots of the controls must line up with the joints. There are tricks one can do to get around this. For example, to avoid having the knee control move between the hip joint and the ankle joint (which would flip the leg), one can first create an empty group node under the tibia joint, position the node in front of that joint, then point constrain the knee control to that node. In MEL script:
select
-cl ;
group
-em; xform -os -piv 0 0 0;
rename
"lknee" ;
select
-tgl ltibia ;
Parent;
setAttr
"lknee.translateX" 20;
setAttr
"lknee.translateY" 0;
setAttr
"lknee.translateZ" 0;
setAttr
"lknee.rotateX" 0;
setAttr
"lknee.rotateY" 0;
setAttr
"lknee.rotateZ" 0;
select
-tgl kneeL_cons ;
pointConstraint
-offset 0 0 0 -weight 1;
Driving the rotation of rotate controls (shown above as circles and diamonds) is trickier. There are many ways to drive the rotation of controls. They differ in what’s required from the rig and the amount of additional work need.
- Method:
Orient-constrain the rotate control to the corresponding mocap skeleton
joint. This is the most straight
forward approach, but it has two requirements. First, the local axes of the control must
line up exactly with those of the mocap skeleton joint (X => X, Y =>
Y, Z => Z). Second, the rotation
order of the control and its corresponding mocap skeleton should also be
equivalent (XYZ => XYZ). With axes
that are not equivalent (i.e. they are 90 degrees off in one or two axes)
you may try at first to specify the offset for the constraint, but you will
likely discover Gimbal lock into your controls in the end, after you bake
their rotate channels.
How rotation order of controls and joints affect
gimbal lock in their animation curves (after the baking step): controls
with rotation order that matches rotation order of joints (left) vs. controls
with rotation order that does not match (right)
- Method: Connect the rotation attributes of the rotation control from those of the corresponding mocap skeleton joint. Where as the orient constraint method requires that axes line up exactly, the attributes-connecting method is more lenient. This method allows the axes of a control to line up with different axes on the joint (i.e. X => Z, Y => X, Z => Y). Consequently, the rotation order must be analogous (i.e. XYZ => ZXY).
|
|
|
|
|
|
mocap skel pelvis joint |
character root control |
|
Up-axis |
Z-up |
Y-up |
|
Rotation Order |
XYZ |
ZXY |
Assuming that the character is not already being use in production, it is easy to change the rotation order of a control. As mentioned above, matching the rotation order of the control with that of their corresponding joint minimizes Gimbal lock. But why does it make sense in this case to change the rotation order of the control? Regardless of the particulars, the rotation order of an object reflects how freely that object can rotate about each of its axes. Here’s one way to read rotation order. Rotation about an axis listed to the left is applied first and does not influence rotation about an axis listed to the right, which is applied after. So the rightmost letter denotes the axis about which rotation is the most unrestrained, while the leftmost letter denotes the axis about which rotation is the least free.
For the root and foot controls and their corresponding joints, it makes sense that rotation is most free about the up-axis—characters should be able to freely change the direction that they face in the scene. On the other hand, the rotation order for the hand joints and controls is less obvious—hands can have a wide range of motion in all directions.
Once you know how the axes match up, connecting the attributes is easy. To connect attributes, use either the Hypergraph, Connection Editor, or the Script Editor. Since the pelvis joint in the mocap skeleton does not have any rotational information of its own (it is set to that of a locator named pelvis_local), be sure to connect the attribute from the appropriate node. In MEL script:
connectAttr
-f pelvis_local.rotateY root_con.rotateX;
connectAttr
-f pelvis_local.rotateZ root_con.rotateY;
connectAttr
-f pelvis_local.rotateX root_con.rotateZ;
- Method: Aim-constrain the rotate control to some other object(s). This method allows the axes to be semi-lined up. However, like the attribute connection method, the rotation order of the control must still be similar to the rotation order of the corresponding joint.
Creating aim-constraints may require additional objects, which can be created in the same way as the example for point-constraining the knee above, but you may be able to use other joints for the same purpose. For example, the foot control is oriented forward while the foot joint is oriented towards the toe. To resolve this, aim-constrain the foot control to point horizontal by specifying a slightly-downward-pointing aim vector (to match the position of the toe) and specifying the tibia joint as the up vector. In MEL script:
select
-r rtoes ;
select
-tgl footR_con ;
aimConstraint
-offset 0 0 0 -weight 1 -aimVector 0 -6 14 -upVector 0 1 0 -worldUpType
"object" -worldUpObject rtibia;