By Steve Pitzel
So you've built your Gothic castle-it's time for your hero to dash into play and defend the battlements. Your gaming engine supports skeletons, an animation system called Inverse Kinematics (IK), and complex hierarchical setups for control. You're eager to try them all. Great! But if you've never used a skeleton before, or even applied IK to a jointed model, you're in for some surprises. Some of them you'll love, some you may not…at least not at first.
This paper introduces some basic and intermediate principles for using skeletons with both Inverse Kinematics and a top-down rotation system to move animated characters called Forward Kinematics. Along the way, it may answer some of your burning questions. When you're done reading, hopefully you'll feel energized enough to leap over any current roadblocks.
Forward Kinematics vs. Inverse Kinematics
Not long ago, game characters were a lot like shellfish: they were basically piles of rock-hard segments. The best animators could hope for was a platform that could handle basic hierarchies, allowing them to position and keyframe all those segments at once. Forget realistically bending an elbow or flexing a muscle-it just wasn't going to happen. Without the processing power available today to handle real-time surface deformations, games featured a lot of robots and armor.
Advanced Processor Performance Enables Computer-generated Skeletons Animated with Inverse Kinematics
For a while, game developers suffered in silence. Then PCs became faster and smarter, which allowed game engines to grow faster and smarter too. Advanced processing performance enabled animators to use computer-generated skeletons not only to hold segmented characters together, but to actually deform the skins of those characters. IK became the control system of choice.
The Scoop on Hierarchies
To understand Inverse Kinematics, it's important to understand basic hierarchies and Forward Kinematics. Outside of straight target-to-target morphing, animators almost always use hierarchies of one sort or another to animate their characters. A hierarchy is a parent-child-sibling relationship. The process for assigning one object as the parent or child of another is often called "parenting" and sometimes "grouping." In the case of a human leg, the parent of the upper leg would be the hip, the lower leg would be a child of the upper leg, and the foot would be the child of the lower leg. The right upper leg would share a sibling relationship with the left, and both would be children of the hips. (See Figure 1.)
Figure 1. Basic lower body setup and hierarchy for Forward Kinematics
Another school of thought on hierarchies uses the "inverted tree" model, where the parent (the hip or pelvis) is referred to as the "root." While no part of a hierarchy is ever really referred to as the "trunk," the children, and their children, become "branches." (See Figure 1.)
The Trouble with Forward Kinematics
If you want to move a character's hand under a basic hierarchy, you would first rotate the upper arm, then the forearm, and finally the hand itself until the entire limb is in place. This "top-down" system of rotation is called Forward Kinematics, and it's great for basic animation.
Animation seems simple with Forward Kinematics and basic hierarchies-until your character has to do something like walk without her feet sliding across the floor, or stay in place while turning her body to look behind her. In those cases, you have two choices, neither of which is aesthetically pleasing:
- Rotate the entire hierarchy (making the feet slide uselessly).
- Rotate only the top of the hierarchy (the hip) leaving the other pieces behind (very painful to watch).
At that point, Forward Kinematics (and your character) falls apart. Planting a walking character's foot is almost impossible, because the single most difficult thing for an object at the bottom of a hierarchy to do is to stay in one place while the objects above it move. The illusion of stability actually takes constant readjustment. (See Figure 2.)
Figure 2. The difficulty with basic hierarchies and Forward Kinematics is when you turn the entire hierarchy, the feet slide. Keep the feet planted and the result can be painful.
The Advent of Computer-generated Skeletons using Inverse Kinematics
Luckily, today game animators are able to use many of the same animation techniques once reserved only for feature film. In the feature film world, constantly readjusting a dinosaur's toes to compensate for even slight movements in the ankle, knees, thighs and hips above them led to slips and slides on the movie screen, which measured in feet rather than in pixels. It became clear that something other than Forward Kinematics was needed to realistically animate a character. Another cinematic problem-believable depiction of the creasing and bulging of joints as a character moves-could only be solved using a model made from a continuous mesh. But how do you make something solid bend and walk? Turning to an earlier staple of film special effects, Stop Motion* software developers incorporated an armature system, or skeleton, into their computer-generated (CG) models and developed a system called Inverse Kinematics to control the skeletons. (See Figure 3.)
Figure 3. Computer-generated skeleton
Conceptually, the CG skeleton is easy to understand. It mimics our own physical skeleton-a rigid structure with tendons at each joint to hold it all together. It is the inverted tree hierarchy, in fact, with the parent often called the "root" of the skeleton. The root is usually located at the character's natural center of gravity; this is often the base of the spine for bipeds. What makes this system better than a basic (non-skeletal) hierarchy, are the tendons, implied but unseen in computer 3D programs. As in a hierarchy built from non-skeletal objects, a skeleton can be manipulated top-down through Forward Kinematics. But perhaps the biggest benefit of the skeleton is its ability to transfer control from the top of the hierarchy to the bottom. Since it works or "solves" from the bottom up (the inverse of Forward Kinematics) the process is called "Inverse Kinematics," or IK. This is a much more intuitive and much less time-consuming process than dealing with top-down rotations.
NOTE: Some animation packages allow the application of Inverse Kinematics to "non-skeletal" objects such as cubes, spheres and null objects, although creating and operating IK chains built this way is usually much more complex.
Figure 4. Simple bone setup with IK handle. Bones are often depicted wider near the root end and narrower toward the effector. The green triangle formed by the bend of the "elbow," the top of the shoulder, and the wrist, indicates the elbow's rotation plane. This plane is adjusted to allow the elbow to swing outward.
The bottommost link of a skeletal chain is often called a goal, or end-effector. (See Figure 4.) (Be aware that these names can mean different things in different programs.) In the case of segmented models, the "flesh" of your character, the actual limbs, torso, head, etc., are then parented to the nearest bone (or joint) of the skeleton. In the case of single-mesh polygonal or seamless NURBS models, you "skin" or "envelope" your model over the underlying skeleton.
NOTE: A character's limbs, head, skin, or clothing are often referred to as its "geometry." Geometry can be rendered, while skeletons are usually invisible to the renderer.
With skeletons, instead of animating the geometry, the skeleton itself is animated, and the geometry follows suit. Since the bones have invisible tendons between them, the joints won't separate when only part of the hierarchy is rotated. What's more, you can apply IK to the skeletal chain.
Advantages of Inverse Kinematics
So what does all this mean to an animator? It means you can yank the bottom of the chain-the hand, for instance-and all of the bones above the hand automatically rotate into position. It's a real plus when a character has to reach for something, as in picking an apple from a tree, for example. Rather than mentally computing how far to rotate the shoulder, upper arm, elbow and wrist to get that hand into position, the animator simply places the hand on the apple and the rest of the arm follows.
An additional bonus to using an underlying skeleton is that the bones and joints provide a natural control structure for deforming the surface. With deformation, individual control points on the geometry are moved in relation to the bones and joints. This is a marked improvement over moving an entire piece of geometry at once.
When a model is "skinned" or "enveloped" over a skeleton, eit her Inverse or Forward Kinematics can be used to animate it. There are still benefits to using Forward Kinematics on some parts of your skeleton. Some packages allow the use of both Forward and Inverse Kinematics on the same skeletal chain and even allow you to switch between them on the fly. Others allow you to switch only with great effort on your part. To do this, you usually have to employ constraints (think of constraints as magnetic forces that can be keyframed on and off), expressions (mathematical formulas), or a combination of both.
First let's take a look at software packages, then at our own bones and joints, then we'll look at how they're controlled.
Skeletons are neither represented nor controlled the same way in every application. Some packages, such as IZWare Mirai*, Alias Wavefront Maya* and PowerAnimator*, allow you to create complete, fully attached skeletons with branching limbs. At the time of this paper's publishing, Softimage 3D* and XSI* do not, but they give you the means to glue together your arm chains, leg chains and neck chains through parenting and a separate control system called "constraints."
Figure 5. When geometry is "skinned" or "enveloped," surface control points are controlled by the bone(s) nearest them. When bones share control over a surface, very smooth tucks and bends are possible. But even if surface deformation isn't your desired result, skeletons are great for holding segmented models together, their joints providing natural pivot points for all those pieces.
Some packages, while offering an Inverse Kinematics system, do not provide bones at all. Instead, you build your own skeleton out of primitive objects or assign skeletal properties to individual parts of each character. Others, like Softimage 3D, Hash Animation: Master*, and Discreet 3d Studio Max*, provide the option of doing both, allowing you to incorporate other objects, such as nulls (usually a center or pivot with no renderable geometry) or dummy objects, into their normal skeletal hierarchies. We'll call all of these objects "nulls" here for sake of brevity. These nulls can be scaled, rotated, or translated, moving the control points of your character's mesh right along with them. This technique is commonly used in Softimage 3D for things like muscle bulges and chest expansion. (See Figure 6.)
Figure 6. Simple Softimage 3D* muscle bulge setup using a "null" object parented directly into the skeletal hierarchy (purple object and box). Translation, rotation and scaling of the null will affect the position and bulging of the muscle and can easily be tied to elbow rotation through expressions. The black box in the schematic to the left shows the arm geometry as the parent of this family. The blue boxes are the root joint, elbow and wrist joints, which rotate the "bones" between them. Note that in Softimage 3D, joints are selectable objects, and bones are not. In Softimage XSI*, both are selectable.
Individual bones are built with their own set of local axes, usually (but not always) X, Y and Z. As with geometry, the placement and orientation of these axes determine the pivot point of the bone as well as its rotation direction. Generally bones can be thought of as two pieces welded together-the bone itself and the joint that allows the bone to rotate. It's important to note, however, that not all packages make this distinction. Softimage XSI and 3D, for example, refer to the entire bone segment as a joint. In Maya and in IZWare Mirai, the joint is an attached, but separately selectable object. This allows deforming objects such as "flexors" to be placed either at the joint itself or along the length of a bone. Flexors can facilitate realistic creasing, such as on the inside the elbow (a good candidate for joint positioning), and muscle bulging (the flexor positioned along the bone).
In some cases, axes are fixed-the user is not allowed to change the orientation of the bone's center. In Softimage 3D, the X-axis always faces down the length of the bone. Other packages, like Maya, allow you to choose the orientation of your center. These packages even let you rotate that center freely, regardless of the bone's orientation, although doing so haphazardly can lead to unpredictable results.
Why does it matter which way the pivots are oriented? Professional animation isn't only about doing things correctly-it's also about doing them quickly. If all of your bones are oriented the same way (we'll go with positive X running down the length of each), it means all of your fingers, knees, elbows and vertebrae bend forward or backward around the same axis. With most setups, that axis is Z. This makes creating expressions a snap. You don't have to guess or use trial and error to know which way your character is going to move.
An Example of Surface Deformation using Bones
Hold your hand out in front of you with your palm facing up. Watch your forearm. Now, without moving your shoulder, rotate your hand until your thumb points at the ceiling. That not-so-subtle twist you see between wrist and elbow would be impossible (or at least very painful) if your forearm rotated as one solid piece. Notice that the flesh closer to your hand rotates right along with your wrist joint, but that the effect falls off toward your elbow. With surface deformation, each control point on the overlaid geometry is controlled by the nearest joint(s) or bone(s).
This means that characters no longer need be loose piles of rock-hard segments. Elbows can bend naturally; the biceps can even bulge and flatten. (See Figure 5.)
All right, so we're back where we started: you've purchased an application with a complete skeletal and IK system. Your problems are over, right? Well, not exactly. The bad news is that an IK system is not always more intuitive than Forward Kinematics. For things like picking an apple or planting feet on a floor during a walk cycle, IK is intuitive and easy to use, provided you've set it up properly. That "setup" is where working with bones and IK can be trying. The setup takes some time to understand.
Where to Begin
Look at your own joints. Before you're in too deep, consider how your body works and then remember that a computer-generated (CG) skeleton is not exactly a human skeleton-it's a representation of one. Although animation tools are getting closer and closer in their ability to reflect reality, it's still up to you, the animator, to make your animations believable.
Think of the various ways your joints work. Your elbows and knees move differently than the joints in your shoulders and hips, which work a little differently from each other, and all are different from the vertebrae in your back and neck. Generally, animation packages give you one or two types of bones with which to work. They also provide a few different options for controlling the bones. Although we humans have several hundred bones supporting our feet, legs, hands and organs, there is rarely a need to match our internal skeleton bone for bone when building a CG skeleton. That method is often counterproductive from an animation standpoint: having too many bones fighting for control of your surface is like having too many cooks in the kitchen. Compromise. Use the fewest number of bones possible. Again, this is meant to be believable, not real.
Joint Types and Control
To be convincing, you need two kinds of joints: ones that can swing all the way around in the socket (which is really more than any of yours do without excruciating pain), and joints that only bend in one direction, like your elbow. Softimage 3D handles this by giving the first (root) joint of every skeletal chain the ability to spin freely on all axes, more or less imitating a ball-and-socket joint. After that, you have the choice of building either a "3D" skeleton, which treats every joint like the first one, or a "2D" skeleton which, after the ball-like root, only bends in one direction along one plane, more like your elbow. The "3D" skeleton is useful for long-necked creatures or things like seaweed and chains. The "2D" skeleton, which starts off with a ball-and-socket joint and ends up with elbow-like joints, is really best for arms and legs. It's also best when you're using no more than two links at a time.
Dealing with Challenges
What if you have to use more than two links at a time? Let's talk about some common challenges, like adding a third link for things like feet or using IK to animate a character picking an apple.
The Third Link Dilemma: What About Adding Feet?
Two links are fairly straightforward in a chain controlled by IK, but the foot represents a third link. How do you deal with adding feet? In Softimage 3D, the ankle is really two things: the end of the leg chain and the start of the foot chain. To put these two together you'll need to parent the foot chain beneath the end-effector of the leg chain or use a "constraint." We'll be discussing constraints later. Let's talk about why a chain is difficult to control with IK after two links.
Strictly speaking, a chain controlled by IK is controlled by the bottommost link or joint of the chain. Any movement of that bottom joint, or end-effector, rotates every bone to some degree all the way up to the top of the hierarchy.
Consider a chain with two leg bones (thigh and calf) where the ankle is t he bottom joint and end-effector. Pushing the ankle straight up results in a bending of the knee and a rotation of the thigh at the hip, a fairly straightforward motion. Let's add another link: a bone for the foot. That same push, this time with the end-effector on the ball of the foot, now results in an ankle bend, a knee bend and a rotation of the thigh at the hip. But the order in which each joint bends and the amount each rotates will vary greatly with only slight adjustments, making this setup difficult to control. (See Figure 7.)
Figure 7. Even though deformation is smoother if more bones are present, it's best to break up the actual IK control of those bones to chains of no more than two links. The leftmost setup (purple arrow) has a one-link foot chain parented to a two-link leg chain in Softimage 3D*. This setup gives you an end-effector on the ankle and another on the toe. This is preferable to using only one end-effector on a three-link chain. Generally in IK, using more bones means less control.
What was an intuitive, easily controlled motion with two bones goes completely haywire with three or more. This is one reason you'll see many chains parented or constrained together in a typical Softimage 3D skeletal setup. Here's where you look to the IK solutions in your software. Despite the creative use of constraints and parenting it requires, Softimage 3D offers a solid IK solution for 3D figure animation.
Other packages provide different solutions. Maya and Mirai offer the ability to create complete skeletons from pelvis to toe. (See Figure 8.) Maya handles the unpredictability of long chains through the use of separate "solvers" placed onto the chains themselves. The animator declares the start and end of a solver's influence simply by placing them where they're needed. To easily control an arm, the solver could be stretched from shoulder to wrist. Another solver might be placed from the wrist to the base of the middle finger. Animation of the hand and arm involves manipulating each solver separately.
Maya also offers a special "spline" solver for animating long-necked creatures. With this solver, a curve (spline) is drawn through the vertebrae of the neck. As the curve is manipulated, the vertebrae rotate to take on the shape of the curve-a tremendous solution for sea creatures!
IZWare (formerly Nichimen) animation software has worked behind the scenes since Walt Disney's Tron* and is famous for its polygonal modeling packages. IZWare Mirai, a newcomer on the "off-the-shelf" animation package scene, helps beginning character animators get up and animating in no time. This is because IZWare Technologies has done so much work up front. Mirai not only allows the creation of complete branching skeletons as in Maya, it also provides ready-made skeletons that are perfectly suitable for many character situations (including humans, dogs and even ticks).
Figure 8. Ready-made models and skeletons from Mirai. A boy, his dog, and one really huge tick!
Solving Automatic Mirroring and Negative-rotation Problems
IZWare has also solved some of the technical director's headaches by adding in a lot of expressions and character controls for automatically mirroring (or even opposing) limb movements. Examples of these movements include the opposing arm and leg swings of a walk or run cycle (one limb forward, one back) and a conductor raising his arms. You only need to animate one arm or leg and then choose whether you wish to animate the opposing limb automatically or not. This also corrects the negative-rotation problem that comes up when skeletons are built in halves and then mirror-copied in other programs. (For example, since the center of each mirror-copied joint has also been "mirrored," the joints naturally rotate in opposite directions.)
Dealing with IK Constraints
Okay, you built your skeleton, and you're using IK to control his feet and keep them planted on the floor. You've also used IK on his hands. He takes a step forward, and notice what happens to his arms. (See Figure 9.)
Figure 9. Positions for end-effectors in IK are keyframed in world space, not in reference to the parent's location (as in a simple hierarchy). That's actually what makes planting a foot with IK so easy-but it doesn't work well for wrist positions, which need to relate back to the skeleton. The easy fix is to constrain the wrist end-effectors to null objects or locators (crosshairs in the picture to the right) and then parent those locators back into the hierarchy.
This is where constraints come in. It turns out that it's rarely a good idea to keyframe an end-effector directly. Doing so actually causes most of the problems you'll find with IK and can prevent your character from accomplishing many of those nifty moves you've so carefully plotted on your storyboard.
Constraints can best be described as powerful magnetic forces that can be turned off and on at will. They allow one object (even null objects) to affect other objects. Different constraints can do different things. Constraints almost always act with, and upon, the centers or pivots of objects, which makes the placement of an object's center or pivot point extremely important. Although some packages have more types of constraints than others, three basic constraints are staples:
- Aim or directional
- Point or positional
Aim or Directional
An aim or directional constraint causes the "affected" object to constantly aim an axis (some packages let you choose which) at the center or pivot of a "target" object. Think of a crowd at Wimbledon: faces always following the tennis ball as it bounds over the net and back.
An orientation constraint is a little more like synchronized swimmers. As one swimmer turns, so does the other. The center orientation of the affected object matches that of the target object.
Point or Positional
A point or positional constr aint is the one most often used with IK. This constraint cements one object directly over another, based on the center position of each. As one object moves, the other is forced to go along.
Objects used as constraint targets can be parented to other objects, which means they are subject to the rules of a basic hierarchy. In a hierarchy, their position and movement is relative to the parent.
The Apple-picking Problem
Constraints are why my skeleton's hands are pinned back in Figure 9. This is because of one of the major differences between a skeletal hierarchy and a basic object or geometry hierarchy. It's also why successful IK animation usually involves both types. As an example of several objects in a hierarchy, consider the case of planes flying in formation with the lead plane as the parent. If we decide to have one of the planes drift higher or lower than the group, we can keyframe that movement and it'll continue flying along with the group as it maneuvers around them. That's because its movement is relative to the movement of its parent object-the lead plane.
In a basic hierarchy, the position of a child is relative to the position of that child's parent. That's why the feet slide when a character held together solely by hierarchies (without bones) rotates his or her hips.
Not so on an Inverse Kinematics chain. The position of an end-effector (the bottommost child in an IK hierarchy) is relative to world space. That's why a foot animated with IK stays put. Unfortunately, it's also why hands animated with IK naturally try to reach out to the point in space where they were keyframed.
IK is a natural for foot placement. But what about that character picking an apple? Isn't that action more easily done with IK? Yes. It's also best done with the help of a basic hierarchy and constraints.
We want to use IK because it's much easier to place the hand on the apple than it is to rotate the shoulders, then the upper arm, the lower arm, etc. But we also want our character to walk up to the apple tree without his hands trailing back in space behind him. How do we do it?
The Apple-picking Solution
We use IK point constraints along with a basic hierarchy:
- Take two objects-squares and circles are good since they are only splines and won't render, so you don't have to remember to hide them later. We'll use circles.
- Place one circle on one wrist (end-effector of the arm chain) and the other circle on the other wrist. If you're really into it, use point constraints to put the circles directly on the wrists and then turn those constraints off.
- Make those circles children of your character's torso (group or parent them to the torso). This means they will go wherever the torso goes and any move they make will be relative to the torso. Now constrain the wrist end-effectors to their respective circles. The idea is to keyframe the constraint objects, not the end-effectors.
The end result is the best of both worlds: the hands move along with the torso as your character walks, and when you place the constraining circle onto the apple, the hand reaches right along with it, giving you the animation benefits of IK.
Using hierarchies of constraint objects to power your IK-driven skeletons can solve about 95 percent of your character animation problems. Everything from two characters playing catch to a rider falling from or jumping up onto a horse can be done with some form of animated constraint hierarchies and IK. With the addition of a little math in the form of expressions to control complex behaviors like foot rotation, you'll have the tools you need to handle just about anything.
So power-down the robots and hang up the armor-single-mesh characters and surface deformation are the way to go now. We've covered hierarchies, Inverse Kinematics versus Forward Kinematics, and many of the major animation software packages that offer them. We've also solved some fairly common (and nasty) animation problems using IK and constraints.
Now it's up to you to experiment on your own. First make sure your engine supports IK and constraint hierarchies, and then have at it. Remember, even if your 3D-software package isn't mentioned in this paper, most have IK systems, hierarchies, and constraints or links of some sort, and price isn't always a factor. Explore what you've got and get out and animate!
For More Information
Listed below, you'll find the URLs for the tools and software packages discussed in this primer. You'll also want to check out the Intel® Software Directory and Software Download Store for an extensive list of tools and solutions.
- Maya* evolved from Alias Power Animator* and Wavefront Explorer*, and is now owned by AutoDesk*, along with Discreet's 3d Studio Max*
- Hash Animation: Master*
- Smoother Animation with Intel® Pentium® III Processors (NURBS models)
- Softimage 3D and XSI*
About the Author
A professional animator and technical marketing engineer for Intel Corporation, Steve Pitzel has been a computer graphics instructor and animator for six years. He began his graphic arts career in college as an editorial cartoonist and courtroom sketch artist. After converting from pencil to mouse, he went on to convert others, teaching 3D applications such as Softimage, PowerAnimator, and Maya to traditional cell animators and computer graphic artists for Disney Feature Animation, Sony Pictures Imageworks, VIFX/Rhythm & Hues and UCLA. He was a lead animator for the CBS feature, The Nuttiest Nutcracker*, and a senior artist for Mattel.
When he isn't animating, he's usually writing. His first novel, Wizrd, was published by St. Martin's Press in 1994 under his pen name, Steve Zell. He is currently working on his second novel.