The Animation Revolution

Traditional character animation in UE5 uses state machines: Idle → Walk → Run → Jump, with manual blend logic between every state. This approach works but scales poorly — adding a new movement mode means touching dozens of transitions, and the result often feels stiff because animations play from predetermined starting poses.

Motion Matching takes a fundamentally different approach. Instead of explicit states and transitions, it searches a database of motion capture data every frame to find the pose that best matches the character's current state and trajectory. The result is fluid, natural movement that adapts continuously.

Control Rig complements this by providing runtime procedural adjustments — foot planting, look-at targeting, physics reactions — applied on top of the motion-matched base animation.

Together, they represent the future of UE5 character animation.

How Motion Matching Works

The Core Loop

Every frame, Motion Matching:

1. Evaluates the current pose: Where is each bone right now?
2. Predicts the future trajectory: Based on player input, where will the character be in 0.2s, 0.5s, 1.0s?
3. Searches the database: Which animation frame in the database best matches the current pose AND the predicted trajectory?
4. Blends to the best match: Smoothly transition to the selected frame

This happens 30-60 times per second. The database might contain thousands of animation frames from motion capture sessions covering walking, running, turning, starting, stopping, and transitioning between all of these.

Why It Feels Better

In a state machine, pressing "turn right" triggers a predefined turn animation from its beginning. In Motion Matching, the system finds the animation frame where the character is already mid-stride and beginning to shift weight rightward — starting from a pose that's close to where the character currently is. The transition is nearly invisible.

Setting Up Motion Matching in UE5

Step 1: Build the Animation Database

The database is a collection of animation sequences tagged with metadata:

1. Create a Pose Search Database asset (right-click → Animation → Pose Search Database)
2. Add animation sequences:
   • Locomotion cycles (walk, jog, run at various speeds)
   • Start/stop animations
   • Turn animations (90°, 180° turns at different speeds)
   • Strafe animations
   • Directional transitions

Each sequence gets automatically analyzed for pose and trajectory data.

Step 2: Configure Search Parameters

In the Pose Search Database, configure what the system matches on:

Pose features (current character state):

• Bone positions (feet, hands, pelvis)
• Bone velocities (how fast each bone is moving)
• Root velocity and facing direction

Trajectory features (predicted future):

• Future position samples (at 0.1s, 0.3s, 0.5s ahead)
• Future facing direction
• Future speed

Feature weights control what matters most:

• Higher weight on feet → better foot placement matching
• Higher weight on trajectory → more responsive direction changes
• Higher weight on pose → smoother blending (less popping)

Step 3: Create the Animation Blueprint

The Animation Blueprint drives Motion Matching through the Pose Search node:

[Input: Character velocity, desired direction, movement speed]
    ↓
[Pose Search Node] → Searches database for best match
    ↓
[Output: Selected animation pose]
    ↓
[Control Rig (optional)] → Procedural adjustments
    ↓
[Final pose output]

In the Anim Graph:

1. Add a Pose Search node
2. Connect it to your database
3. Feed in the character's movement data as input
4. The node outputs the best matching animation frame

Step 4: Feed Gameplay Data

Motion Matching needs real-time gameplay state. In your Character class:

void AMyCharacter::UpdateAnimationData()
{
    // Current movement state
    FVector Velocity = GetCharacterMovement()->Velocity;
    float Speed = Velocity.Size();
    FVector FacingDirection = GetActorForwardVector();

    // Predicted trajectory (based on input)
    FVector DesiredDirection = GetDesiredMovementDirection();
    float DesiredSpeed = GetDesiredSpeed();

    // Pass to animation
    if (UMyAnimInstance* AnimInst = Cast<UMyAnimInstance>(GetMesh()->GetAnimInstance()))
    {
        AnimInst->SetMovementData(Velocity, Speed, FacingDirection, DesiredDirection, DesiredSpeed);
    }
}

Control Rig: Procedural Animation Layer

Control Rig runs after Motion Matching to apply runtime adjustments.

What Control Rig Does

• Foot IK: Plant feet on uneven terrain
• Look-at: Rotate head and spine toward a target
• Hand IK: Reach for objects, hold weapons correctly
• Physics reactions: Lean into turns, react to impacts
• Pose corrections: Fix penetration through geometry

Setting Up Foot IK with Control Rig

// Control Rig graph (simplified)
[Get Bone Transform: foot_l] → [Line Trace Down] → [If Hit]
    → [Set Bone Transform: foot_l (adjust Z to ground)]
    → [Adjust pelvis height (compensate for leg extension)]

[Get Bone Transform: foot_r] → [Line Trace Down] → [If Hit]
    → [Set Bone Transform: foot_r (adjust Z to ground)]
    → [Adjust pelvis height]

This ensures feet land on terrain surfaces regardless of ground angle or elevation changes — something Motion Matching alone can't handle since the database animations assume flat ground.

Look-At with Control Rig

// Control Rig: Procedural head/spine look-at
[Get Target Location] → [Calculate Look-At Rotation]
    → [Apply to Spine1: 20% influence]
    → [Apply to Spine2: 30% influence]
    → [Apply to Head: 100% influence]
    → [Clamp to natural range of motion]

The chain of spine → neck → head rotation creates natural-looking head tracking instead of robotic head-only rotation.

Combining Motion Matching + Control Rig

The animation pipeline order:

Motion Matching (base locomotion)
    ↓
Upper Body Override (weapon animations, additive layers)
    ↓
Control Rig (foot IK, look-at, procedural adjustments)
    ↓
Post-Process (physics simulation: cloth, hair, secondary motion)
    ↓
Final Render Pose

Practical Patterns

Pattern: Speed-Based Database Switching

Use different databases for different movement speeds:

// In Animation Blueprint
if (Speed < 150.f)
    ActiveDatabase = WalkDatabase;      // Walking animations
else if (Speed < 400.f)
    ActiveDatabase = JogDatabase;       // Jogging animations
else
    ActiveDatabase = SprintDatabase;    // Sprinting animations

This keeps each database focused and improves search quality. Motion Matching blends between databases smoothly.

Pattern: Combat Stance Switching

Switch databases based on combat state:

if (bInCombat)
{
    if (EquippedWeaponType == EWeaponType::Sword)
        ActiveDatabase = SwordCombatDatabase;
    else if (EquippedWeaponType == EWeaponType::Rifle)
        ActiveDatabase = RifleDatabase;
}
else
{
    ActiveDatabase = CivilianLocomotionDatabase;
}

Pattern: Terrain Adaptation

Combine Motion Matching with Control Rig for terrain:

• Motion Matching handles the base locomotion (flat ground walk/run cycles)
• Control Rig adjusts foot placement to terrain surface
• Control Rig tilts the pelvis and spine for slopes
• The result: natural movement on any terrain, using flat-ground motion capture data

Pattern: Responsive Turns

Motion Matching excels at turns when the database includes:

• 45°, 90°, 135°, 180° pivot turns at walk and run speeds
• Smooth curve turns for gradual direction changes
• Turn-in-place animations for stationary rotation

The system automatically selects the right turn animation based on how much the desired direction differs from the current facing direction.

Performance Considerations

Database Size and Search Cost

Larger databases produce better results but cost more to search:

For games targeting 60fps (16.67ms budget), keep total Motion Matching search time under 1ms. Use database pruning, KD-trees, and frame budget limits.

Optimization Strategies

• Reduce search frequency: Search every 2-3 frames instead of every frame (interpolate between)
• Pre-filter by speed: Only search the relevant speed range, not the entire database
• Use animation tags: Mark sequences with gameplay tags to narrow search scope
• LOD animation: Distant characters use simpler state machines instead of Motion Matching

Memory

Each animation frame in the database stores pose and trajectory data. Budget approximately:

• 1,000 frames ≈ 2-5 MB
• 10,000 frames ≈ 20-50 MB
• 100,000 frames ≈ 200-500 MB

For multiple characters with unique databases, memory adds up quickly.

Migration from State Machines

Incremental Approach

You don't need to replace your entire animation system at once:

1. Start with locomotion only: Replace the walk/run state machine with Motion Matching
2. Keep combat as state machine: Complex ability animations often work better as explicit states
3. Add Control Rig incrementally: Start with foot IK, then add look-at, then physics reactions
4. Profile and tune: Adjust database size and search parameters based on actual performance

What to Keep as State Machines

Some systems are better as explicit states:

• Ability animations: Specific combat moves with precise timing
• Cinematic animations: Pre-authored sequences that must play exactly
• UI animations: Emotes, gestures, celebrations
• Death animations: Physics-driven ragdoll transitions

Hybrid Architecture

The best production setups use both:

Lower Body: Motion Matching (locomotion, turns, starts/stops)
Upper Body: State Machine (combat, abilities, interactions)
Full Body: State Machine (death, cinematics, special moves)
Post-Process: Control Rig (IK, look-at, physics reactions)

Motion Matching and Control Rig represent the direction Epic is taking UE5 animation. Start experimenting with them now — the sooner you understand these systems, the better prepared you'll be for the next generation of character animation.