- Setting Up a Character for Animation
- Creating Clean Joint Hierarchies for Animation
- Rigging a Simple Quadruped Character: The Dog
- Creating Advanced Bipedal Character Controls
- Advanced Stretchy IK Legs and Classic Reverse Foot
- Advanced IK Arms and Clavicular Triangle
- Hooking Up the Head Skeletal Hierarchy
- The Hair of the Jerk
- Summary
Creating Advanced Bipedal Character Controls
This section covers several more advanced approaches, some that lend themselves very nicely to the stretching characters into any pose needed by the animators. We know that our human character will need to stand on two feet, sit down and drive a car, get sprayed by a fire hydrant, get knocked down, and interact with several objects and props in his environment. The fact that the character might need to be animated with a touch of cartooned style, per his character design, is also a consideration for the design of the controls. A special type of rig involving a stretchy spline IK setup that reacts with the intuitive controls of an FK hierarchy will be used for the back (spine) of The Jerk. It will give him the ability to stretch his back evenly, similar to the real stretching ability of a spine. It will also allow normal, traditional FK-style rotations of the controls for certain poses that should not be controlled by an IK rotational element. The ability to stretch more than would be anatomically correct will exist, and it will be the animator's job to decide how much the back will stretch, bend, and so on.
The legs of the character will be rigged using IK because The Jerk will need to stick mostly to the ground for walking. The arms will also be rigged using IK, but a simple IK parenting technique will be used to allow for FK-style rotation of the shoulders, as well as IK-style translation placement for The Jerk's clavicle and hand. This will give the character animator full control to pose the characters. Both the arms and the legs of The Jerk will have automatic stretching built into their IK rigs as well. This adds another level of control for the animators, especially when sticking the feet or hands onto objects, because the legs and arms will actually stretch to any length to meet the placement of the hands or feet.
The Advanced Biped Spine
Let's start the first advanced character setup exercise with creating what I have coined "the Divine Spine." There has been much talk about spine controls over the years, and several techniques in Maya lend themselves to achieving promising results, but these techniques are missing key elements from other styles of rigging that many animators and riggers prefer. Thus arises the basic dilemma of character rigging: How do you really manipulate the transformation space to achieve the ultimate combination of motion capabilities, while still successfully maintaining straightforward ease of use and production-level stability?
This advanced spine setup solves many, if not all, of the problems that certain pre-existing techniques for spine setups contain. It also combines the best of both FK controls and IK controls, which enabling the animator to operate in both FK and IK seamlessly at the same time while animating the character. No uncomfortable or unintuitive switching on and off of weighted attributes is required. I designed the Divine Spine setup with these requirements:
Be able to move the hips of the character without changing the location or moving the shoulders, and be able to move the shoulders without changing the position of the hips.
Still be able to grab a control and rotate it in any direction. It should intuitively rotate the character's back hierarchically as if it were a simple FK joint hierarchy.
Be able to grab the same character control and translate it, and intuitively translate the character's spine like a spline IK setup.
Be able to compress and stretch uniformly between vertebrae when the controls are animated.
Be controlled by a minimal number of control joints, yet still allow for a large number of actual spine joints.
Be stable, predictable, and production-worthy. It should not use some forced mathematical function to compute secondary motion that will make the animator "fight" with the motion.
This spine setup is a versatile approach and can be used effectively to rig extremely realistic spine controls as well as cartooney ones.
Without further ado, let's begin.
Exercise 17.4 The Divine Spine Setup
-
First, create your joint hierarchy and orient the joints. I usually use a total of 12 to 18 joints for the base hierarchy of the spinal column, but you can use more or less, depending on your character's requirements. For this setup to work properly, you must be sure of the following things:
-
Scale Compensate is turned on in the Joint tool options before you draw your joints.
-
All your joints have been properly oriented before proceeding, with the Scale option checked on in the Orient Joint options window before you perform the Orient Joint operation (see Figure 17.18).
-
Create a spline IK handle from the first to the last joints in the hierarchy using the Skeleton IK Spline Handle Tool options. Make sure that Auto Simplify Curve is turned off in the spline IK options (see Figure 17.19).
-
Select the spline IK curve that the IK Spline Handle Tool created for you automatically. Then create a curve info node by executing the following MEL command in the command line (by all probability, your curve might actually be named curve1):
-
Select the Spline IK curve, open the Hypergraph, and select the menu item Graph, Input and Output Connections to view upstream in the Hypergraph.
-
From the Utilities tab of the createRenderNode window (accessible from the menu path Create, Create New Node in the Hypershade), create a multiplyDivide node.
-
Double-click the multiplyDivide node to display the Attribute Editor and set Operation to Divide. Open the Hypergraph and display the input and output connections along with the spline IK's NURBS curve (see Figure 17.21).
-
Next, open the Connection Editor, load the curveInfo node in the left side, and load the multiplyDivide node on the right.
-
Figure out which axis is pointing down your joint hierarchy so that when you scale your joints, they scale along the axis that is pointing toward the next child joint. This determines which attributes you connect in the next step. For this example, if you used the default xyz for the Orient Joint command, the axis you need to use to connect will be the X axis (see Figure 17.22).
-
Connect the arcLength attribute of the curveInfo node to the multiplyDivide node's input1 attribute. Be sure to use the axis (X, Y, or Z) that your joint should scale alongyou took note of this in the last step. For this example, use input1X.
-
Now look at the number that is in the multiplyDivide node's input1 attribute (by looking at the yellowed number in the Attribute Editor). In this case, it is 66.637. This is the output value of the arcLength, which returns the current length of your spline IK curve's length. If the spline's curve length changes (by pulling CVs or deforming it in some way), this arclen node will continue to update the curve length and feed the current new distance into the multiplyDivide node.
-
Copy/paste the attributes from the yellow input attribute of your multiplyDivide node (the curve's current length) into the corresponding input2 channel directly below in the Attribute Editor for the correct division action to take place.
-
Open the Connection Editor again, load the multiplyDivide node on the left and the joints on the right, and then connect the multiplyDivide node's division outputX attribute into each joint's scaleX. Skip the very last joint in the hierarchy (the bottommost child at the tip). Because it is the very last end joint, it doesn't need to have any scale attached (see Figure 17.24).
-
Create the joints, and make sure they are spaced evenly and are placed in the locations that you want the back to pivot and bend from. Also make sure that they are placed directly on top of the spline IK curve by using the Joint tool with holding down the c key; this activates Curve Snapping mode while drawing your joints directly on top of the spline IK curve. Make sure that the new low joint count hierarchy that you just built has the same start position as the spline IK's root and has a similar end position as the very last child joint in the spline IK hierarchy.
-
Make sure you are happy with the orientation and placement of your new low-res joint hierarchy; reorient these new low-res spine joints, if necessary. Click Modify, Prefix Hierarchy Names to rename this new joint hierarchy with the prefix lowRes_Control_ (see Figure 17.25).
-
Now select the spline curve and Shift+select the lowRes joint hierarchy's root. Smooth-bind the curve to the lowRes joint hierarchy.
-
Test how the low-res joint hierarchy bends your spline IK setup so far. If you are unhappy with the arc or curve of the bend, hit Undo (the z key) a few times until you are back to the point where you can start rebuilding your low-res joint hierarchy. Do this test a few times until you get the right placement and number of joints for your low-res joint hierarchy (see Figure 17.26).
-
Next, even out the weighting of your smooth bound curve by distributing the curve's CV weights more evenly across the joints. Do this by selecting the CVs of the curve and using the Smooth Skins tab under General Editors, Component Editor. Modify the weights by changing some of the values at 1 to .5, or .75, depending on how close they are to the neighboring joint (see Figure 17.27).
-
Select the root joint of the original spine's spline IK joint hierarchy and duplicate it using the default duplicate options. Delete the unused effector node in the new duplicated hierarchy, which got duplicated from the other spline hierarchy. (Make sure you delete only the effectors of the duplicated hierarchy, not the effector that the IK spline solver is connected to.)
-
Click Modify, Prefix Hierarchy Names to rename this duplicated hierarchy to have a new prefix of Ik_Bind_Spine_. This is the spine that the character mesh eventually will be bound onto (see Figure 17.28).
-
Translate this duplicated Ik_Bind_Spine_ hierarchy's root node away from the spline IK hierarchy so that this whole situation isn't completely confusing when you try to select and rig up your joints in the 3D view window.
-
Select the first joint and then the very next joint in the hierarchy going up the spine. Then start the next IK handle's base at the end location of the previous IK handle that was just created; continue this process until the end of the spine hierarchy is reached (see Figure 17.29). This procedure should exactly result in the same number of IK handles as there are joints in your hierarchy, minus onethe only joint that does not have an IK handle stuck directly on top of it should be the root (which will later be point-constrained).
-
First, point-constrain each one of the rpIk handles to the corresponding joint that is part of the spline IK hierarchy. Then point-constrain the root of the Ik_Bind_Spine_ rpIk hierarchy directly to the root of the spline IK hierarchy (see Figures 17.30 and 17.31).
-
Next, connect the scale attributes from each original joint in the spline IK hierarchy to the scale attributes of the corresponding duplicate joint in the Ik_Bind_Spine_ rpIk joint hierarchy.
-
Next, group all the rpIk handles under one node by selecting them all and hitting Ctrl+g (see Figure 17.32).
-
Before beginning, hide the lowRes control hierarchy temporarily so that it doesn't confuse things in the 3D view. Do this by selecting the root of the lowRes hierarchy and hitting Ctrl+h.
-
Start by creating a single locator, and name it poleVector1. Next, activate the Move tool, and with the middle mouse button on your mouse, and the v key on your keyboard depressed, drag your mouse to snap the locator directly on top of the root joint of the high-res hierarchies. When the locator is directly on top of the root joint, translate it along the Z-axis direction that moves it backward so that it is directly behind the character's back. Be sure that it is moving only on a single axis and that you are moving it behind the character.
-
Next, hit Ctrl+d to duplicate the locator and snap this new duplicated locator to the next joint, which should also have an IK handle right on top of it. Perform the exact same step, moving the locator backward about the same distance on the same axis as the first locator that you just moved behind the character. Repeat this step for each joint in the hierarchy except for the very last one.
-
When you are finished duplicating, snapping, and moving all the locators behind the character, check that you have the correct number of locators. You should have a single locator for each rpIk handle, and each locator should be located directly behind each one of the character's spine joints, with a single IK handle for each joint except the root. Your locators should be situated something like the ones shown in Figure 17.33.
-
Next, unhide the low-res control joints by setting the root node's visibility attribute to on. Parent each one of the poleVector# locators to the nearest low-res control joint (see Figure 17.34).
-
Now pole vectorconstrain each rpIk handle so that it is constrained to all of the locators. Do this by first selecting all the locators that you have situated and parented behind your character's back; then add to the last selection the rpik handle and perform the command Constrain, Pole Vector.
-
Perform Step 31 for each IK handle on your character's back: Select all the locators and then select a single IK handle, and perform Constrain, Pole Vector. When you are finished, you should have each one of your IK handles pole vectorconstrained to all of the locators behind your character, as in Figure 17.35.
-
To do this, select each IK handle and click the pole vector constraint in the Channel box to modify the pole vector constraint weight attributes (or, just select the pole vector constraint that is a child of your IK handle).
-
Set each weight value to a number that will distribute the rotation of the pole vector to be controlled evenly by two to four of the locators.
-
Next, group all of your IK handles and curves together. Then group both of your high-res IK hierarchies under the same group and name it spineRigIkNodes. Keep your low-res hierarchy outside of this spineRigIkNodes group because this group will never be moved or translated. The lowRes hierarchy will be the joints that are hooked up to control boxes and that are used to animate the character.
-
Point-constrain the root of the lowRes hierarchy to the root of the character, and group and constrain the rest of the lowRes hierarchy to control boxes so that it is kept free from the translations of the root.
Figure 17.18 Make sure Scale Compensate is turned on and that you properly orient all your joints before proceeding.
NOTE
If you prefer to start with a precreated joint hierarchy, you can open the file Jerk_DivineSpine_Begin.mb on the CD that comes with this book.
You should see a node attached to your curve called curveInfo. This node contains the length of your curve (see Figure 17.20).
Figure 17.19 Make sure that Auto Simplify Curve is turned off in the spline IK options.
Figure 17.20 The curveInfo node contains the length of your curve.
Figure 17.21 Switching the multiplyDivide node's Operation attribute to Divide mode in the Attribute Editor.
NOTE
If at any time you lose sight of your utility node (such as multiplyDivide) and you can't seem to find it for selection, you can usually find it in the Hypershade window's Utilities tab. If this fails (because the node isn't connected to the defaultRenderUtilityList), you can always select all the nodes of that type or with that name, and then find the one you want by using MEL and either node type or wildcard name using the select command.
To select by node type, execute this MEL command:
select Ðadd `ls Ðtype multiplyDivide`;
To select by wildcard name, execute this MEL command:
select Ðadd Ò*multiplyDivide*Ó;
You can then click Graph, Input and Output Connections and see all the nodes you are looking for. This easy technique works for any node type or node name in your Maya scene, by the way.
Figure 17.22 Connecting the curveInfo node with the Orient Joint command.
Now you want to create a normalized ratio that represents the amount that the curve length is scaling (if a CV of the curve gets moved) to drive the scale attribute of each joint in the hierarchy. This is easily achieved by dividing the current distance (the yellow one) by the initial distance before the deforming took place. So, as common sense would dictate, the output at the default state always equals a scale of 1. The curve has not yet been deformed, so the current distance just happens to also be exactly what you need for the initial distance.
This results in a value that will represent the amount by which the joint's length should be changed to approximate the curve's current length. You can then simply use this to drive the scaleX attribute of each joint (see Figure 17.23).
Figure 17.23 Resulting value that represents the length that the joints will be changed to.
Figure 17.24 In the Connection Editor, connect the multiplyDivide node's division outputX attribute into each joint's scaleX.
Now you will create a second skeleton hierarchy. This will be the low-res, control joint hierarchy that controls all the high-res spine's motion through a series of binding and weighted pole vector constraints. Usually about four to six joints will do just fine for this low-res hierarchy.
Figure 17.25 Rename the low-res joint hierarchy.
Figure 17.26 Testing the low-res joint hierarchy on the spline IK setup.
Figure 17.27 Using the Component Editor to modify the weights.
Now the problem you have is that the spline IK hierarchy bends and compresses really nicely, but it doesn't twist (due to the nature of the spline IK solver's pole vector ). Although the spline IK solver has a rotation plane implemented and is controllable by using the twist attribute, you don't want to use this attribute to drive the twisting of the spineit will violate the intuitive control that an animator expects to have when he rotates one of the single joint controls of the low-res skeleton. At this point you really need a rotate plane at every single joint, which has a weighted average to control the twisting of the spine based on the twisting of the low-res control joints. Unfortunately, the spline IK allows only a single rotate plane that is distributed evenly over the entire hierarchy.
So, in the following steps you will create yet one more hierarchy of joints. This time it will be an exact duplicate of the spline IK hierarchybut without the spline IK and with a weighted pole vectorconstrained ikRPsolver IK handle at every single joint.
Figure 17.28 This is the spine that the character mesh eventually will be bound onto.
NOTE
This situation will result in the creation of three hierarchies in the end. One of them (the one you just duplicated) will have the character's skin bound to it and will be partially controlled by the original stretchy spine splineIk hierarchy. These two hierarchies will need to stay unparented from any group that will transform with the character because these two hierarchies will be entirely controlled by the lowRes spine that is currently smooth-skinned to the spine's spline curve. If you transform the bound IK spline hierarchy as well as the low-res control spine, you get double transforms. I discuss this later, but hopefully this helps enlighten things a little bit more for now.
You now want to create rotate plane IK handles at each joint of the new Ik_Bind_Spine_ hierarchy by starting with the root and then making an IK handle that is a single joint long using the IK Handle tool.
Figure 17.29 Creating rotate plane IK handles at each joint of the new Ik_Bind_Spine_ hierarchy.
Now you will perform a few steps to perfectly line up the rpIk spine with the spline IK spine.
Figure 17.30 This image shows half of the IK handles as they are being point-constrained to the corresponding splineIk spine joints.
Figure 17.31 This image shows all of the IK handles after they have been point-constrained to the corresponding splineIk spine joints. The root of the Ik_Bind_Spine_ has been point-constrained to the root of the splineIk's spine joint root.
Because these two hierarchies are right on top of each other in the 3D view, the easiest way to select them is by looking at the two hierarchies side by side in the Hypergraph's Graph, Scene Graph mode. Then hit the Toggle Free Form Layout button and move the hierarchies side by side. By doing this, you can see exactly which nodes you need to connect to each other because each node in the hierarchy is right next to the corresponding one. Because the hierarchies are exactly the same, you simply need to open the Connection Editor, select a single spine joint first, and load it into the left side. Select the corresponding duplicate Ik_Bind_Spine_ joint second, and load it into the right side. Then quickly connect the scale attribute of the spine to the scale attribute of the corresponding IK_Bind_Spine.
Figure 17.32 Group all the rpIk handles under one node.
You should now have three joint hierarchies that, for the most part, all move together and are controlled by the low-res control hierarchy. They have the capability of stretching and compressing, as well as rotating using an FK approach and translating using an IK approach. The only part missing is the FK capability to actually twist the low-res joint hierarchy and have the joints in the high-res joint hierarchy get the separate portions driven by the twist.
To achieve the desired twisting capability, you will create locators to serve as weighed poleVector constraints for each rotate plane IK handle in the rpIk Ik_Bind_Spine_ hierarchy.
Figure 17.33 Your locators should be situated something like this.
Figure 17.34 Parenting each poleVector locator to the nearest low-res control joint.
This creates a single weighted pole vector constraint with weight attributes for each locator, which constrains the IK handle onto all the locators situated behind your character.
Figure 17.35 Each rotate plane IK handle pole vector is constrained to all the locators that have been placed behind the back.
Now it's time to manually change each of the pole vector constraint weights to weight them with a nice fall-off toward the corresponding low-res joints that the locators are parented onto.
Now look at the weight values that show up in the Channel box. Each weight represents how much the current IK handle's twisting is controlled by each locator that it is constrained to (the locators are children of the low-res back).
Rotating a low-res joint causes the pole vector constraint locator that is a child to orbit around the pivot of the low-res joint you are rotating. This, in turn, causes any of the IK handles that are constrained to the locator to twist or rotate along the IK handle's rotate plane. The idea is to determine which low-res joint's rotations you want to have affect the twisting of the high-res joints.
Determining which joints should receive weighting is quite simple: If the joint is at the top of the hierarchy, weight it toward the locators that are children of the top low-res joint. The best part about all this is that the poleVector constraint has weights, so it can have weights that are falling off from one locator to the next, across multiple joints. If one of your rpIk handles is in between the top low-res joint and one of the middle low-res joints, give it weights that are averaged between locators that are children of these two hierarchies. For example, if you are distributing the weights across four locators, choose weights that are falling off from low values to higher values, such as .1, .35, .75, and 1; the rest of the weights should be set to 0. The only rule for which constraint weights you should give higher weights to is this: Set the weights of the pole vector constraints so that when you twist the low-res hierarchy, the high-res joints rotate with an appealing and desirable fall-off between them.
Figure 17.36 shows what your pole vector constraints should look like when you are finished changing their weights.
Figure 17.36 When you are finished changing their weights, your pole vector constraints should look like this.
This keeps the hips free from moving with the shoulders, and vice versa. An additional parent of both hierarchies should eventually also be used when the rest of the character controls are built, to move both the root and the upper spine together.
You can find a completed file, titled Jerk_DivineSpine_Finished.mb, on the accompanying CD for this chapter.