I’ve played nearly all the parts in the giant space opera that is 3D animation. Lots of it is lots of fun, and some of it is genuinely rewarding. But by far the most difficult, arcane, and thankless part of the process is the rigging of 3D characters in preparation for animation.
I did all the rigging for Space Bunnies myself. This included seven full character rigs, some with unusual structures and dynamics simulations. Some of these rigs worked as expected, but some fought me all the way to the comp, taking my attention from basic functionality, getting in the way of the animation, and even causing trouble at rendertime.
Now that I’ve stopped crying, I’m ready to talk about it.
Most 3D models make little distinction between a figure and its clothing, either in function or appearance, for practical reasons. The simplest rigs to build and maintain are made of rigid pieces, like toys, bugs, robots, or cars. Consequently, most 3D characters look like they’re made of stiff, rigid pieces.
For Space Bunnies, I wanted to avoid stiff-looking characters. I designed bloopy, squashy, stretchy figures, with floppy, bouncy bits including kimono sleeves, chinese opera hats, and facial hair. I used deformers in my rigs to squash and stretch the characters in various ways, and sometimes stretched bones directly.
However, as you may know, objects such as funny hats and facial hair have no motive force of their own, unless they’re enchanted. They just ride along on other objects, reacting to forces like momentum, gravity, and wind. To simulate the motion of these sorts of objects, I relied on three rather naughty-sounding components of Maya: rigid bodies, jiggle deformers, and hair systems.
I’m also a client
Maya’s hair systems are ostensibly designed to simulate realistic fur and hair follicles. In theory, a system with a whole lot of these follicles may be attached to objects such as heads and monsters. When the objects move, the motion of the hair is calculated based on variables such as hair length, stiffness, elasticity, and clumping. In the hands of 200 animators at Pixar with the latest tech, it can come out looking pretty okay. When the rest of the world tries it, it takes forever and comes out looking like koosh ball hair plugs.
However — individual hair follicles can play a much easier role as a spline IK curve, to add life to long, flexible objects attached to something by one end. The classic application of this technique is a floppy monster tail, as seen on the orca in my Tlingit vs. Haida piece.
In Space Bunnies I used this trick all over the place: the monk’s robes, hat, and moustache, the chinese opera singer’s beard and hat, the geisha’s sleeves and hair, the soda jerk’s apron, the bunny’s ears, and in trees and grass. In general it worked fine, but I had occasional trouble with objects accidentally intersecting, especially in the soda jerk’s flight.
These setups can be tamed to some degree, but it’s often easier to fix those issues in the comp. For the soda jerk, I rendered his apron separately (with a one-sided material so the back wouldn’t show) and comped it in on top of him.
For other squishy objects, I used jiggle deformers. These convert an object into a “soft body”, in which all of the vertices of the object are treated as though connected by springs. When the object moves, the springs pull on each other to different degrees. I used these for the geisha’s hair, in the hats of the monk and the opera singer, and a few other places. With certain complex objects, the spring calculations became prohibitively bulky, and I generally animated with these objects hidden.
In a few other situations, such as the baby’s camera, I used rigid body simulations — I treated the camera like a cube, tied it to the strings of the camera strap, and allowed it to bounce freely in response to the baby’s motion. These simulations can be especially difficult to control, and ultimately I decided that such control wasn’t worth the extra time I was spending on the problem. So I let the camera flap freely, as it seemed to fit the scene, and I was burnt out on dynamics troubleshooting anyway.
Cache is king
These components I’ve described are all simple dynamics simulations, which model the motion of an object through time in various ways. As time-based simulations, the state of the simulation at any given time depends on its state just prior. So if you want to know what your chinese opera hat looks like on frame 800, you must simulate its motion through the previous 799 frames. Multiple characters with many dynamics simulations require extra calculation, and this can seriously bog down your workflow.
The key is to record the states of the simulations for future reference, a process known as caching. When the simulation is cached, the program references the recorded state of the simulation rather than running the simulation through to the current time. These states can also be used by the renderer at rendertime.
However, to take full advantage of caches, you must cache everything cacheable at once. If you have 25 separate dynamics simulations in a scene and cache all but one, you will still wind up stepping through your shot every time you or your renderer wants to look at a new frame.
The tricky bit
In Maya, it isn’t immediately obvious which simulations are cacheable, how to cache them, which are cached, and which are referencing their caches. If one simulation depends on the position of another (such as a jiggle deformer parented to a hair follicle, or two follicles chained together) it may not cache when it says it has, or have successfully cached the data but be unable to use it.
I eventually made scripts to detect and select all the cacheable attributes of my rigs to ensure they were all being cached when necessary, but it took me awhile to determine the cause of my woes. Certain combinations of spline ik setups turned out to be essentially uncacheable under certain conditions, and I was forced to bake the rotations of all the joints in the chain to achieve reasonable render speeds.
The primary expressiveness of any character must be conveyed in the face and hands. That’s where the viewer will look first to see what’s happening, and where flaws will be most visible. Dynamic simulations can be nice additions to a character, but shouldn’t be added at the expense of basic functionality.
This seems like a no-brainer now, but when you’re in the middle of production, on a deadline, and excited about moving past basic techniques, it’s easy to assume that things you’ve done many times before will just work out. Overall, the dynamics I used behaved as expected, but far too much time was sucked into tweaking and troubleshooting their performance.
More time on the basics would have more than paid off in time saved during animation. More time working on squash and stretch would have made my rigs more expressive. As it was, I wound up fighting simple things like eye and hand position, and the characters suffered, and then you suffered.
And I’m so, so sorry.« previously: Song of Civil Revolution | Home | next: Seadragon and Photosynth demos »