Rigging and Animation
Character model is ready, looks great—and then falls into Unity like a wooden puppet because bones are placed arbitrarily and don't match Humanoid Avatar requirements. Programmer tries to use a ready-made Animator Controller from Asset Store, but animation blending breaks the pose because root motion is misconfigured. This is a typical situation when rigging and animation pipeline aren't designed for the engine from the start.
Rigging isn't just "add bones." It's designing a control system that must work inside a specific engine with specific format requirements.
Humanoid Rig Pipeline in Unity: In Depth
Unity works with two rig types: Generic and Humanoid. This choice affects the entire animation pipeline.
Generic rig — Arbitrary bone hierarchy. Animations are bound to the specific model; retargeting is impossible. Suitable for non-character animation (machinery, doors, creatures with non-standard anatomy).
Humanoid rig — Unity maps bones to a standard scheme of 17 required bones (spine, head, arms, legs) and up to 32 optional ones. After that, any Humanoid animation applies to any Humanoid character. This is the foundation for retargeting and Animator Controller with Blend Tree.
Skeleton Requirements for Humanoid
Errors that break Avatar mapping:
- Incorrect bone orientation. Unity expects the X-axis to point along the bone toward the child bone. If the arm points along Z or -Y, Avatar generates with distorted T-pose.
- Extra intermediate bones in the spine chain. If there's an unmapped intermediate bone between Spine and Chest, it's lost during retargeting—spine animation looks stiff.
- Roll bones (twist bones) — Bones for distributing forearm and thigh twisting. In Humanoid, add them as additional (optional) bones and configure weights correctly. Without twist bones, the forearm folds ungracefully when the wrist rotates.
T-pose vs A-pose
Unity recommends T-pose as the binding pose. A-pose (arms lowered at ~45°) technically works, but retargeted animations give slight errors at the shoulder joint. For armored characters or wide shoulders, A-pose is sometimes preferable—less stretch on retargeting. This decision is made during rigging; changing it later is expensive.
Avatar Mask
Avatar Mask is a tool for partial animation application. For example: lower body plays running animation, upper body plays shooting. Without Avatar Mask, these states conflict.
Proper Animator Controller structure for a shooter:
Base Layer (Full Body weight: 1.0)
└── Locomotion Blend Tree (idle / walk / run / sprint)
Upper Body Layer (Avatar Mask: upper body, weight: 1.0)
├── Idle_upper
├── Shoot
├── Reload
└── Aim_offset (2D Blend Tree by pitch/yaw)
Additive Layer (Avatar Mask: spine, weight: by parameter)
└── Lean_left / Lean_right
Additive layer for leaning is a typical optimization: instead of 8 separate animations (run_left, run_right, walk_left...), one additive lean applies over any state.
Blend Tree for Locomotion: Practical Analysis
Blend Tree is an animation blending system by one or two parameters. For character locomotion, standard is 2D Freeform Directional with velocityX and velocityZ parameters.
Minimum clip set for basic locomotion:
| Animation | velocityX | velocityZ |
|---|---|---|
| Idle | 0 | 0 |
| Walk Forward | 0 | 0.5 |
| Run Forward | 0 | 1.0 |
| Walk Backward | 0 | -0.5 |
| Run Backward | 0 | -1.0 |
| Strafe Left | -0.5 | 0 |
| Strafe Right | 0.5 | 0 |
Freeform Directional interpolates between clips by angle and magnitude of velocity vector. At velocity (0.35, 0.35), it blends Walk Forward and Strafe Right with weights calculated by distance to each point in 2D space.
Root Motion vs. In-Place animations:
-
Root Motion — Character movement is controlled by root bone displacement in the animation clip. The animator "bakes" movement speed into the animation. Unity reads this displacement and moves the character Transform. Advantage: animation and movement always stay synchronized (footsteps match displacement). Disadvantage: harder to control speed via code, requires correct Animator setup (
Apply Root Motion: true). - In-Place — Pelvis bone stays in place, displacement controlled by code (CharacterController or Rigidbody). Easier to integrate with physics, but risk of desynchronization between footsteps and movement speed (foot slipping).
For most action games, In-Place is used with Foot IK via the Animation Rigging package (Unity) for proper foot placement on uneven surfaces.
Skinning: Weights and Problem Areas
Skinning (binding mesh to bones via weights) is the most labor-intensive rigging stage for organic characters.
Tools:
- Maya — Weight Paint tool + Component Editor for precise manual editing. Smooth Skin Weights as starting point, then manual tweaking of problem areas.
- Blender — Weight Paint mode + Automatic Weights as basis. Vertex Group Editor for point editing.
- 3ds Max — Skin modifier + Weight Table.
Problem areas and solutions:
Armpits: standard solution—"candy wrapper" artifacts when raising arm. Solved by adding corrective shape keys (blend shapes) that trigger at a certain shoulder angle. In Maya—Pose Space Deformation (PSD), in Unity—BlendShape managed through AnimationClip controlled by IK angle.
Knees and elbows: need strictly perpendicular edge loop rings (a topology requirement established during retopology). Twist bones distribute deformation across three joints (shoulder twist, elbow, forearm twist), eliminating cylinder twisting.
Combat Animations and States
A combat animation system isn't just a collection of clips. It's a state graph with transition conditions and interrupt priorities.
Typical error: transition from Idle → Attack with Has Exit Time: true and Exit Time: 0.9. This means attack only starts when idle plays 90%. Player pressed attack button and waits 0.5 seconds. Solution: Has Exit Time: false, transition by trigger, Interruption Source: Current State with priority.
Combat state structure:
Any State → Hit Reaction (trigger: onHit, interrupts current)
Any State → Death (trigger: onDeath, interrupts all)
Attack Layer:
Idle → Attack1 (trigger: attack)
Attack1 → Attack2 (trigger: attack, exit time: 0.6) // combo window
Attack2 → Attack3 (trigger: attack, exit time: 0.6)
Attack1/2/3 → Idle (no trigger, exit time: 1.0)
Combo window opens at ~40% of animation length and closes at ~80%. This creates responsiveness without breaking animation.
Spine 2D for Mobile Games
Spine is standard for 2D animation in mobile RPG, idle games, action-platformers. Character mesh is split into parts bound to a 2D skeleton. Animation is bone transformations, mesh deformation through weighted vertices.
Advantages over frame-by-frame:
- Animation file weighs kilobytes instead of megabytes (sprite sheets).
- Retargeting: same attack animations work on different characters with identical skeletal structure.
- Animation blending and IK—same concepts as in 3D.
Unity integration: official Spine Runtime for Unity. SkeletonAnimation component manages playback, SkeletonMecanim allows Animator Controller on top of Spine skeleton. For programmatic animation—direct API control: skeletonAnimation.AnimationState.SetAnimation(0, "walk", true).
DOTween is often used alongside Spine for non-skeletal animations of UI elements bound to character (health bar, damage numbers)—not the skeleton itself, but for syncing UI with game events.
What We Deliver
- Character rigging for Unity Humanoid / Generic Avatar with retargeting support.
- Skinning with manual weight adjustment in problem areas, twist bones, corrective shapes.
- Animator Controller development: Blend Tree for locomotion, Avatar Mask for multi-layer systems, combat state graphs.
- Animation clip creation: locomotion, combat, reactions, cinematics.
- Spine 2D rigging and animation for mobile projects, Unity integration.
- Root Motion and Foot IK setup via Animation Rigging.





