Animation Rig: Categorization
Up until now we have been working with the Minotaur’s pose rig in order to test how the geometry deforms during weight painting and skinning. Pose rigs are not intended for animation as they will generally be comprised of overtly simplified controls, for example my Minotaur’s pose rig is controlled only by FK rotations.
Animation rigs are also intended to “pose” a character from one keyframe to the next, while your 3D package interpolates the difference between each pose and creates what is known as tweens or inbetweens, which are simply frames that smooth the movement of the character or object from one keyframe to the next. However, animation rigs differentiate substantially to pose rigs particularly in their setup which will usually involve the addition of controller bones. These bones do not have to be a special software specific type of bone, but can be the same type of bones used throughout the rest of the rig, the main purpose of controller bones is to simplify the process of achieving a pose by manipulating chains of bones with a single controller. Controllers can also be other types of non-bone objects depending on the software you use, such as locators, empties or even polygon geometry.
When I set out to create an animation rig there are several objectives I try to always keep in mind:
- All components of the skinned model should, at their most basic level, be controllable with FK (Forward Kinematics).
- Use IK (Inverse Kinematics) chains and Constraints to control multiple FK bones, other IK chains and avoid base level transforms.
- An intuitive rig will be driven with translations and very few other transform types (rotate, scale).**
**However, when working with certain games engines a combination of translation and rotation controls may work out to be a more effective (especially when it comes to re-targetting animations which may involve an FK rig as a controller).
Base FK Rig
Animation rigs can start looking pretty complicated very soon in the creation process, as a result I like to divide my characters rig’s into atleast two main categories which subsequently fall under the same armature/skeleton hierarchy.
The first category consists of the base components of the rig. These are generally all deformer bones, that when rotated cause the skinned model to deform. Only the parent of this set of bones should be translatable and these bones are not intended to be animated directly.
The second major category consists of all controllers (bones and non-bones). This includes all components which are intended for animation and those that are not intended for animation and are also not a part of the base FK category.
Grouping components like this helps reduce clutter in the viewport and keeps the rig looking simple. Further categorization of controller components is also necessary, but will differentiate from one rig to the next. Creating these categories does not necessarily make use of a specific software feature, but can be done by placing groups of bones in the same bone layers in Blender or creating multiple character sets in Maya. The purpose is simply to reduce the amount of bones and controllers that are visible in the viewport at any time. As skeletons can generally be displayed in X-ray mode in many 3D animation packages, the character’s geometry might get obscured by bones. Hiding bones in the viewport and only working on specific sets at a time can prevent occluding the geometry in the viewport.
To further reduce viewport clutter bones can be proxied by other objects. Bear in mind however that bone proxies are simply a visual aid in setting up armatures and should ultimately assist in simplifying the design of your rig and not complicating it with obscure symbols that, even you as the creator, can tend to forget the meaning of over time.