Character Skeleton Rigging

Character Skeleton Rigging for Games

A character skeleton is not just a set of bones for animation. It's an architectural decision that determines how much each animation will cost in the project and how easily an animator can work without constant rework. Badly configured rigs show problems not immediately—at the stage when twenty animations are recorded and something goes wrong with the legs during state transitions.

Unity Humanoid vs Generic—and When It Really Matters

In Unity the choice of Avatar type—Humanoid or Generic—is determined not by personal preference but by pipeline requirements. Humanoid provides access to Avatar Mask, Animator Controller with retargeting and Animation Rigging package. The cost—mandatory binding to 15 required bones, rotation restrictions, and problems with non-standard proportions (four-armed characters, creatures with tail as body part).

Generic rig is more flexible in these cases: no hierarchy requirements, arbitrary skeleton topology, any bone can be animated directly. But retargeting is lost. For characters with similar proportions this is non-critical, for a project with 50+ unique creatures—a noticeable loss.

In practice: humanoid for main game characters (player, humanoid NPCs), generic for monsters, vehicles, mechanisms.

What Goes Into Skeleton Before First Animation

Number of bones is not a parameter to maximize. Mobile title with GPU skinning holds 75 bones per character without frame drops. On PC with compute skinning—more. But each extra bone in tail or cape is a bone the animator must account for in every animation. Either Physics Bone in Unity (through Animation Rigging + Bone Renderer) or secondary dynamics through Jiggle—but these are separate systems on top of main rig.

Guideline for average-quality humanoid character: spine 3–5 bones, neck 1–2, fingers three phalanges if grab animation is needed, otherwise one is sufficient. Toe bones—only if there's boss animation or walking on uneven surface with IK.

Bone names—standard from day one. Unity Humanoid automatically maps bones by name. Naming mismatch (Bip001_L_Thigh instead of LeftUpLeg) breaks auto-mapping and requires manual fix in Avatar Configuration each time. If project uses Mixamo, its naming becomes the standard as de facto convention.

Axis Orientation and Rest Pose

The most non-obvious part for beginners: bone axis orientation in bind pose. In Blender bone is directed along Y-axis of local space. In Maya—X-axis. In Unity runtime axes are read differently. Orientation error shows at first IK attempt: arm reaches wrong place or knee bends backward.

Rule: all limb bones are oriented so the main axis (usually X in Maya, Y in Blender) points along the bone from root to tip. Bend axis (pole axis) is perpendicular to limb plane. If pole axis is set incorrectly, IK-solver chooses arbitrary bend direction for the knee—and this cannot be fixed without re-orienting the skeleton.

T-Pose vs A-Pose for bind pose: T-Pose gives clean mapping in Unity Humanoid Avatar. A-Pose is more natural for skinning—less weight stretching in armpit area. Compromise: T-Pose for automatic mapping, then Reset Pose to A-Pose through Avatar Configuration.

Working Process

Starting with technical specification and references. Need to understand avatar type, platform, number of characters, retargeting presence and dynamic element requirements.

After skeleton assembly—test animation: simple walk cycle with hands in Blender or Maya to check deformations before skinning. FBX export with Unity settings: Smoothing Groups, Tangents, Scale Factor 0.01 if working in centimeters.

Final check—import to Unity, Avatar Configuration, test with any standard Humanoid Motion Clip. If Avatar is green and no warnings—skeleton is ready for skinning.

Work cost is calculated individually: influenced by number of characters, common pipeline presence and retargeting requirements.