In a visual arts-specific article for Intel's Visual Computing microsite and originally published in Game Developer magazine, Bungie's Steve Theodore discusses skeletal construction and animation for game characters, looking at "strategies for taming the skeletal hordes without ending up in the graveyard."
[In a visual arts-specific article republished on Intel's Visual Computing microsite and originally published in Game Developer magazine, Bungie's Steve Theodore discusses skeletal construction and animation for game characters, looking at "strategies for taming the skeletal hordes without ending up in the graveyard."]
You hear the eerie rustle of dry bones as they close in around you, the hideous clacking as they shimmy through your pipeline. They are the remorseless bearers of doom. Neither fully alive nor safely dead, they will not rest -- nor will you! For they are...
...the skeletons!
And they're here to make you miserable!
The animation skeleton, like the biological one, is absolutely necessary. We're pretty much stuck with the skeletons we were born with, but for many of our digital creations, the right set of bones takes a long time to develop. The process is often slow and iterative, and if it's handled incorrectly, it can also be very painful.
If you want to exorcise (or exercise) the restless bones in your own characters, you need to start by repeating to yourself this important, but frequently forgotten fact: The skeleton is, bar none, the most important component of any animated character.
The fact that it's invisible doesn't make it some kind of afterthought that can be elbowed off the schedule in favor of more graphically satisfying tasks, like creating concept art or modeling. You must get the skeleton right if the character is going to succeed aesthetically. And just as importantly, you have to get the skeleton assembled safely if the character is to come in on time.
Let's look at some strategies for taming the skeletal hordes without ending up in the graveyard.
If bitter experience hasn't left you convinced that the skeleton is critical, stop and do a little math.
A high quality character mesh represents several weeks of an artist's time. A skeleton, of course, can be assembled in a couple of days. Although the cost of laying down bones may be trivial, the problems that arise when the skeleton has to be changed mid-stream are truly epic.
When you change a character's skeleton, you've invalidated every bit of existing data that depends on the skeleton. This means you may have to reweight its mesh and rebuild every one of its animations. This can be nearly as expensive as redoing them from scratch.
It might require weeks or months of work by a whole team of animators, supported by a character rigger. And if the alteration in the skeleton involves a change in the overall proportions of the model, you may need to rework the game mesh as well, which can also result in creating new UVs and thus new textures.
Most teams recognize the costs of skeleton changes and treat them with the kind of enthusiasm usually reserved for a dinner invitation at Castle Dracula. Locking down your skeletons as early as possible is a natural and sensible precaution, given the time costs and potential for chaos that comes with changing them.
Locking down that skeleton is easier said than done, however. The key to making it stick is planning early. Sending out emails about "discipline" isn't going to cut it. Ensure that your concept process includes the design of the core animations and the skeleton as well as the mesh and textures (we devoted an entire column to this very topic; see "Raw Crude," Game Developer magazine, May 2008). At the very least, you'll need to devise a tough set of standard test animations that a character needs to perform successfully before his skeleton is released to animators and riggers.
Even with planning and tests, you're bound to miss something. For this reason it's good practice to push to the front of the production queue the moves that typically reveal the flaws in a skeleton. That way any changes that become necessary can be caught when only a few animations are in the can.
The worst offenders are often crouching or kneeling poses, which expose poor placement of knee and ankle joints ruthlessly (see "Anatomy for Animators: A Leg to Stand On," Game Developer magazine, November 2005). Gun aiming poses are another good candidate for early testing, as they reveal flaws in the neck and shoulder anatomy as well as the tricky matter of clavicle placement.
Once you've got a skeleton you can believe in, it's still important to distribute it to the animators and communicate that it has been distributed. If you crave ghoulish thrills, watch the eyes of an animator as she realizes she's spent a week perfecting a move on an out-of-date version of the character that won't export anymore. Sending emails or leaving sticky notes on the monitors of harried production folks isn't enough. The tools in your pipeline must make it so that starting new animations is as simple and error-proof as possible.
Opinions are split on how to ensure your animators are always working with the authorized skeleton. Some teams like file referencing, while others recoil from it as if it were a necklace of garlic. Referencing proponents point out (correctly) that using references provides free automatic updates and keeps the animation staff current with no extra effort.
Detractors counter that referencing breaks too many animation features, makes it hard to apply special-purpose rigs, and has a tendency to break animations when changes do come through. Since referencing tends to arouse a lot of theological passion (see "Clone Wars," Game Developer magazine, October 2008) it's important to focus on the animators' needs rather than fixed ideas about the technology.
Unfortunately, no amount of discipline and planning can keep those restless skeletons locked in the boneyard forever. A good process limits your liability, but it's almost certain that some accident of production or technical glitch will eventually force you to go for a root and branch rework of a character that already has dozens, or even hundreds of completed animations.
When that dark day dawns, you're in for some serious pain. However, a little planning and some tools can transform the experience from one of soul-crushing despair into nothing worse than a bad case of indigestion.
The first and most important line of defense is simply to know when things have gone wrong. It's a great idea to check every animation against the "skeleton of record" when you export it. That's a good way to keep people from walking down blind alleys for too long, and it means that minor problems (like bones that accidentally get renamed) can be fixed right when they occur, instead of showing up as subtle bugs or mysteriously failed imports.
The real horrors, of course, are serious changes to the layout or proportions of the skeleton. These happen for a lot of reasons: a change in the game design, a fatal flaw in the existing skeleton (like an unavoidable gimbal lock that snuck through testing), or an anatomical problem that has to be fixed. When these sorts of situations arise, fixing them is going to be costly. The only question is how much.
The basic strategy for coping with serious skeleton changes is to retarget your existing animations onto the new skeleton, in much the same way that you might apply animations from a mo-cap actor onto a monster. If you already have in-house expertise in motion retargeting, you've got a huge leg up on the problem. Experienced MotionBuilder jockeys can be particularly useful when the bones start going haywire.
Of course, as those old MotionBuilder pros can tell you, retargeting isn't free. It's better than fixing animations by hand, but it's hardly free.
The primary goal of retargeting animation is to get something that looks like the original motion transferred onto a new skeleton. But looking alike is not the same as sharing animation curves and keyframe data, or fancy control rigs.
If you have to do major surgery on your skeleton during production, retargeting will help you preserve the look of your animations. But the odds are high that you'll end up with files that look like they were produced using motion-capture: dense, keyframe-by-keyframe data on every channel of every bone in the skeleton, whether you need it or not.
If your animators have spent days carefully tweaking the tangents on their f-curves, they're not going to be happy when they open a retargeted file and see a graph view that looks like the army ant horde from Indiana Jones and the Kingdom of the Crystal Skull. The only consolation is that without retargeting, they'd have to open an empty file and start all over from scratch.
If you don't have an in-house expert who knows mocap retargeting, you can build your own retargeting system in MaxScript, Mel, or Python. It would take years to build a homebrew system that can match the sophistication of dedicated motion-editing software, but a basic version should be well within the capability of any good rigger or technical animator. A good suite of retargeting tools is one of the best investments you can make for your character department.
Figure 1: A Basic retargeting setup. The original skeleton (blue) drives a set of world space constraint objects (green). These, in turn, drive the new skeleton (brown) even if it has different orientations or proportions.
The essence of all retargeting systems is the old rigger's trick known as "faking and baking." (See Figure 1, above.) The "faking" step involves creating a world space recording of the original animation. You create dummy nodes for every bone in the skeleton and glue them to the original animation using parent constraints.
The "baking" step consists of baking the transforms of the constrained dummies so they're independent of the original bones (that's "collapsing controllers" for Max folks, just as capable, though it doesn't sound as snappy). Baked dummies in hand, you can load up the new skeleton and reverse the process, constraining the new bones to the existing dummies and then baking the constraints down to keys. (See Figure 2, below.)
Figure 2: The animation from the original skeleton is captured on the world space locators. First they are constrained to the original bones, and then the results of those constraints are "baked" or "collapsed" into ordinary keys.
The system automatically accounts for the kinds of changes that make it impossible to simply transplant animation curves. Different rotation orders or re-oriented parents don't affect the outcome, and the results are as close as the differing skeletons will allow. With the constraint's ability to maintain initial offsets, you can even compensate for minor changes in position and orientation of the new bones.
Although the results of a fake-and-bake retarget are a bit oversupplied with keyframes, they should at least resemble the original animation pretty closely. (See Figure 3, below.) It's not MotionBuilder, but it's a handy hack that doesn't require a PhD in animation.
Figure 3: The world space dummies now constrain the new skeleton. If the new skeleton is physically similar (say the rotation orders or joint orientations are the only difference) the animation transfers exactly (top). If the proportions are different, the animation will be similar but not identical to the original -- in the bottom example, the third bone’s animation is constrained by the locator from the fourth bone in the original skeleton -- this ensures the two chains are parallel, but the three-bone chains is slightly displaced from the original.
As you experiment with retargeting, you'll quickly find that there are several common cases that the fake-and-bake technique doesn't cover.
One common problem is that the animator needs to decide which bones need to mimic the position of their opposite numbers in the old file, and which ones only need rotations. Positional matches are only needed by character roots or IK targets. Most other bones can be retargeted using just rotations.
You'll need to hone reliable, automatic ways of knowing when to use positional retargets and when not to. You don't want to doom some poor animator to opening hundreds of animations just to select a particular bone and press the "retarget my positions" button by hand.
Another important issue is pose matching. To get good results, you need to get the new skeleton into the right start pose before constraining it to retargeting dummies. Without matching the pose, you can't leverage the power of the constraint offsets. Again, the key is to find reliable ways to automate that.
Once you're comfortable with the basics, you can start expanding your repertoire to handle more puzzling situations. For example, once you have a basic set of retargeting scripts, you can extend them to handle trickier situations.
You could apply a global scale by grouping all your retargeting dummies together and scaling them up or down. You could reorient animations by grouping and rotating retargeting dummies. One of the nice things about the dummies is that they are not hierarchical, so your adjustments are applied in a comprehensible way.
If this sounds pretty easy, it is -- up to a point. Building your own retargeting system, especially if you have no mocap experts in-house, is an important investment in protecting your data and keeping your animators from endless do-overs.
It's important to be realistic, though. Few studios have the technical art chops (or the unscheduled time) to put together a truly bulletproof retargeting system. A successful retarget can involve a serious amount of trial and error. In most cases, there is no truly right way to move motion between skeletons with more than trivial differences, and so you'll have to rely on the instincts of your retargeting specialist and a lot of very tweaky, case-by-case scripts.
Once animators get over the novelty of your retargeting tools, they'll be less grateful for their saved work than resentful of all those dense mo-cap-like keys (it's not fair, but it is human nature). And soon they'll start demanding the ability to retarget between animation rigs as well as skeletons, a vastly trickier proposition.
If you set out to design the perfect system that will survive all skeletal changes without human intervention, you are going to be very frustrated. If, on the other hand, you can cheerfully stick to a glass-half-full outlook, you can get a lot of value from the simple tricks outlined here.
The key is never to forget the terrible curse that is placed on those who trifle with skeletons! Those undead hordes may never be truly laid to rest, but they can certainly be forced back into the shadows where they belong, as long as you are bold enough to grasp the weapons at your disposal.
[EDITOR'S NOTE: This article was independently published by Gamasutra's editors, since it was deemed of value to the community. Its publishing has been made possible by Intel, as a platform and vendor-agnostic part of Intel's Visual Computing microsite.]
Read more about:
FeaturesYou May Also Like
