Rig Preferences

(click pic to download sample rig)
_________________________________________________________

Every animator has his/ her own set of preferences when it comes to animation rigs. While it is true every animator can adapt to a given rig and produce good animation with it, I believe that a well laid out rig allows for a more streamlined workflow, thus creating the potential for more polish time.

Creating a rig that has enough control for the animator while not being overly complicated is definitely a balancing act. Here are three main categories I like to use as a checklist.

• EASY TO SELECT CONTROLLERS
• MINIMIZE COUNTER-ANIMATION
• PERFORMANCE / REAL-TIME PLAYBACK

_________________________________________________________

So to start, at the top of my list has to be…

EASY TO SELECT CONTROLLERS

• Try to separate controllers as much as possible. In other words, minimize the overlapping of controllers so you’re not constantly selecting the wrong controller. When there’s too much overlap, you’re wasting time by constantly bobbin’ and weavin’ and tumblin’ around just to select a specific controller.
• Controller shapes don’t need to be exactly centered to the joints they are driving. I’d move them (the cv’s) if it helps with separation.
• Take the time to resize the controller to fit the body part of the character, esp. when using automated rigging scripts. (ie. Don’t create hand controllers that are the size of the torso or controllers that are imbedded in the geo.)
• Color code controllers. I probably won’t remember that red means right side and blue means left, but colored controllers will further help with separation.
• The standard yellow/red/blue scheme seems to work well for a wide range of textures.
• I like fingers controllers a bit brighter (yellow) since they’re smaller and harder to see. Other “secondary” controllers could be light blue. Whatever you choose, keeping a little bit of consistency helps when you’re jumping from character to character in a pipeline.
• I’d also stay away from bright green and white controllers. These just confuse me as to what’s currently selected.
• Create controller shapes that are selectable from wide angles. In other words, try not to have controllers that can only be selected from the front or the back. Spine, neck, and shoulder controllers seems to be repeat-offenders.
• A character GUI/ picker is good for selection “backup” (when a controller is hard to select in a specific pose). Also good for selection sets.
• Picker could also be used for frequently used tools and matching scripts.
• Picker to help with scenes containing multiple characters.

CONTROLLER SPECIFIC PREFERENCES

• Boxes for the spine. I like fin-shaped boxes because I can quickly judge the rotation of one spine controller in relationship to the others. This makes it easier to keep the torso rotations clean. If circles are used for the spine, then a direction indicator for each controller would help. Speaking of spines, I’m plenty fine with only 2 spine controllers (in addition to the Root and the hip). 3 spines controllers are ok, but any more than that feels to cumbersome to animate. If deformation is a concern, have fewer controllers drive more joints.
• For the neck, I’m fine with one controller.
• A "halo" controller above the head feels nice and clean and is definitely separated from the neck controller.
• I prefer the head controller to never follow the rotation of the neck. Local/global switching of the head could be connected to the spine instead.
• Likewise, I like the arms controllers to never follow the rotation of the shoulders (clavicles). Have it follow the world or the spine.
• The main pivot of foot controllers should be at the ankle imo. Pivoting on the heel could be handled as an attribute in the channel box. When the main pivot is at the heel, I feel like I’m constantly readjusting the translation of the feet everytime I rotate it (too much counter-animation).
• IK’s oriented to the world-->meaning that if I translate an IK controller using “world” mode, only one channel should be affected. If this is not so, it’s a lot harder to make translation adjustments in the graphEditor.
• I prefer elbows to not follow the clavicles (again too much counter-animation). It can follow the world or the spine instead.
• For knees I always preferred to have them follow the feet when the feet are translated but now when they are rotated. I haven't really used the knee twist attribute in the past, but I’ve recently been seeing a lot of noFlip knee solutions. I’m actually pretty intrigued by it as I think it might be the way to go for knees from now on. I'll be experimenting with this.
  

OTHER PREFERENCES

• Long attribute lists in the channel box should be grouped and separated with “empty” channels.
• Rotation behavior of mirrored controllers should be checked. (ie. Rotating both clavicles in one channel should rotate them both up)
• Rotation orders should be checked and be allowed for change, so that FKIK switching would still works.
• Controlling fingers is always going to be somewhat tricky. A controller for every finger segment can get bit cumbersome to select. On the other hand, a long list of attributes in the channels box can also get a bit confusing. The method I find to be the best balance between control and speed is to have one controller at the base of each finger. Each finger controller would then have 2 attributes to curl the remaining segments. Sure you can’t bend every finger segment every which way for “smear” frames, but for games (where you have to turn anims around quicker), I think it’s plenty of control. Joel Ku introduced this to me a few years back and I’ve been loving this method ever since.
  

_________________________________________________________

Next category...

MINIMIZE COUNTER-ANIMATION

• Since different situations may call for different approaches, I think the key here is a quick and intuitive way for FKIK and space switching on the fly.
• I prefer all local and global switches as keyable attributes on the controller itself. That way, I’m not wasting time trying to track the switch from a list of 50 attributes on a separate controller.
• I also prefer only one controller per body part. I’d rather have one IK controller be switchable between local/ global space as opposed to multiple IK controllers for each space. Again it’s so I don’t have to track down that other controller when switching, not to mention the added clutter and worry about more visibility toggles.

_________________________________________________________

Lastly, but just as important is…

PERFORMANCE / REAL-TIME PLAYBACK

• A rig could have a gazillion controls to cover every possible situation, but if it’s too complicated and heavy and runs at a very low framerate, then polish time could still be compromised because accurately judging your animation in real-time is too difficult.
• The balancing act here, I guess, is to know your production goals. (What’s the target, what’s the budget and timeline?) Controllers for uber-subtly may not be used if the budget doesn’t doesn’t allow time for them.
• Proxy meshes, in addition to how connections are hooked up in a rig, can make dramatic impacts on how it runs in Maya when I hit that “play” button. Of course some characters will be more complex than others, but if I’m constantly making playblasts for every little change because my scene is running at 5 fps, even during the blocking stage, then two things will probably happen. I’ll have to spend more time on this anim to get the level of polish I’d like, or this anim will get done on time, but with less polish that I’d like.
• Playblasts are definitely important for final polish. But if I have to playblast from the get-go, then there will ultimately be less polish time.

______________________________________________________________

As for the face, I’ll just quickly mention that I am a fan of the Osipa-type interface—one that lets you quickly get the shapes you want but at the same time allows for layering in detail with “on-the-face” controllers if needed.

So to hopefully better illustrate some of the things I’ve been rambling about, I made a simple rig for everyone to play around with. If you're interested, download it here. I know no one really reads the “readme” files but try to at least glance through this one, there are features in the rig that may not be obvious.

And remember, in no way is the rig meant to be the super-rig (it’s not even fully complete). I’m sure any TD out there could look at the rig and find many ways to build it better. But there you have it. Again, these are just my own preferences. Feel free to add to this list or bring up counter arguments. I’m always looking for more efficient ways of doing things:)