Skip to content

Root Motion vs Character Movement

Most Character movement is capsule-first: input and Character Movement move the body, animation follows. Root motion flips that for specific animations: the root bone's authored motion is extracted and applied to the character.

At a glance

Use this for: authored lunges, vaults, knockdowns, finishing moves, cinematic movement, montage-driven special actions - Default beginner movement: Character Movement drives the capsule; animation reads velocity and plays poses - Root motion movement: animation root data is extracted and applied through the character/movement path when enabled - Can fail by: missing root bone motion, disabled root motion, wrong AnimBP root-motion mode, mesh/capsule drift, movement-mode limits, or multiplayer correction - Official docs: Root Motion, UCharacterMovementComponent, and Networked Movement in the Character Movement Component

The one-minute version

  • Normal Character movement moves the capsule through Character Movement. Animation reads the result and poses the mesh.
  • Root motion uses movement authored on the skeleton's root bone, extracts it from the animation, and can move the character/capsule through the animation system and Character Movement.
  • If root motion is disabled, an animation with a moving root can make the mesh drift away from the capsule and then snap back.
  • Root motion must be enabled on the animation asset and allowed by the Animation Blueprint's root-motion mode.
  • For beginner gameplay movement, prefer Character Movement, Add Movement Input, Launch Character, or deliberate movement code. Use root motion for specific authored actions where the animation should own the exact movement.
  • Multiplayer root motion is not "ignore networking." Character Movement has root-motion handling, but server authority, montage replication, prediction, and correction still matter.

Capsule-first movement

The normal Character loop is:

Input / AI Move To / Launch Character
-> Character Movement Component moves the capsule
-> Skeletal mesh follows the Character
-> AnimBP reads velocity/movement mode
-> state machine / Blend Space plays the matching pose

This is the default for:

  • walking/running;
  • jumping/falling;
  • AI navigation;
  • ordinary knockback with Launch Character;
  • multiplayer player movement.

Animation communicates what movement happened. It does not own the real collision path.

Animation-first movement

Root motion starts with authored root-bone movement:

Attack_Lunge animation:
    root bone moves forward 300 units over 0.6 seconds

Root motion enabled:
    engine extracts that root movement
    applies it to the character movement/capsule path
    mesh stays aligned with capsule

This is useful when foot contact, body weight, and exact pose timing matter more than a simple velocity:

  • melee lunge;
  • vault over a low obstacle;
  • climb up a ledge;
  • knockdown/get-up;
  • finishing move;
  • cinematic door kick.

It is not needed just because "the animation moves." Many locomotion clips are authored in-place on purpose and should remain capsule-first.

The mesh drift symptom

Classic failure:

Animation has root bone moving forward
Root motion is not enabled/applied
-> mesh walks out of the capsule
-> collision remains behind
-> at the end, mesh snaps back to capsule

That means the visible mesh and the gameplay collision body disagree. Do not fix that by moving the mesh component separately every frame. Decide whether the clip should be in-place locomotion or real root-motion movement.

Enabling root motion

The setup has two sides:

Animation Sequence / Montage:
    Enable Root Motion = true when the asset should provide movement
    Root Motion Root Lock chosen deliberately

Animation Blueprint Class Defaults:
    Root Motion Mode decides which root motion sources are extracted/applied

Beginner rule:

Mode Use when
No Root Motion Extraction You want root bone motion left in the pose.
Ignore Root Motion You want to extract/remove root motion from the pose but not apply it as movement.
Root Motion from Everything Multiple contributing animation assets can provide root motion. Use deliberately; it can force more game-thread animation work.
Root Motion from Montages Only Common gameplay default for authored special actions such as attacks/vaults while normal locomotion remains movement-driven.

For first projects, montage-only root motion is usually easier to reason about than letting every Blend Space sample contribute movement.

Root locks and offsets

Root-motion assets need clean root data:

  • skeleton has a real root bone;
  • root bone movement is the intended body movement, not accidental export offset;
  • root lock choice matches the animation;
  • capsule starts where the animation expects;
  • mesh relative transform is not hiding an offset problem.

If the character pops at the start or end, inspect the animation in the editor with root-motion visualization and check root lock settings before changing Blueprint movement code.

Character Movement still matters

Root motion is applied through the character/movement system for Characters. Movement mode still shapes parts of the result. For example:

  • while walking/falling, vertical movement may be handled differently from horizontal motion, with gravity still relevant;
  • collision still blocks the capsule;
  • normal movement resumes when the root-motion action ends;
  • AI/pathing logic may be suspended or overridden during an authored action.

Root motion is not ghost movement through walls. It is another source of movement that the Character Movement path consumes.

Root motion vs other movement tools

Tool Use when Not for
Character Movement / Add Movement Input Ongoing player/AI locomotion. Exact authored lunge/vault timing.
Launch Character One-time velocity such as jump pad, knockback, bounce. Animation-authored foot/body contact.
Set Actor Location Teleport or deliberate direct placement. Normal walking or root-motion action movement.
Timeline/FInterp Scripted non-character movement or simple interpolation. Character locomotion with collision/prediction unless designed carefully.
Root Motion Montage A specific animation should drive a Character action's movement. General input movement or freeform AI navigation.
Root Motion Source Code/system-driven special movement needs Character Movement/network support. Basic Blueprint first-project movement.

Use the simplest tool whose owner matches the feature. If input should steer freely, Character Movement is usually the owner. If the animation's authored path must be followed, root motion may be the owner for that action.

AI and root motion

AI Move To and Behavior Trees assume movement requests drive the pawn toward a goal through navigation. A root-motion montage temporarily changes that relationship:

AI reaches attack range
-> stop/lock normal movement as needed
-> play root-motion attack lunge montage
-> montage/root motion moves character for the attack
-> when action ends, resume AI movement decisions

If you let AI path following and root-motion lunge both fight for movement, the result can look like sliding, snapping, or canceled attacks. Gate the action state clearly.

Multiplayer boundary

Networked Character Movement has root-motion support, especially for montage root motion, but the beginner rule is still:

Client requests action
-> server validates action
-> server/owning path triggers the root-motion montage state
-> machines that should see it play the montage
-> Character Movement handles movement/prediction/correction according to role

Do not rely on a client-only root-motion montage to move the authoritative character. It may look responsive locally and then be corrected by the server.

Also decide what other players need:

  • first-person arms root motion may be owner-only presentation;
  • third-person lunge movement is public gameplay movement;
  • damage/hits remain server-owned even if the montage times the swing.

When it fails, and what failure looks like

Symptom Likely cause
Mesh leaves capsule and snaps back Animation has root movement, but root motion is not extracted/applied.
Character does not move during root-motion montage Asset root motion disabled, AnimBP root-motion mode wrong, montage not in active slot/path, or no root-bone movement.
Character ignores player input during attack Root motion is overriding normal movement for the action; decide if that is intended.
Lunge goes through or stops at geometry oddly Capsule collision and movement mode are interacting with the authored path.
AI attack cancels/path fights lunge AI movement/path following is still trying to drive the character during root-motion action.
Works standalone but snaps in multiplayer Client-only movement disagrees with server/Character Movement replication.
Vertical root motion ignored while falling/walking Movement mode/physics rules are shaping vertical movement.
Feet slide after action Root motion, root lock, montage blend, or transition back to locomotion is mismatched.

Debug with capsule visibility, root-motion visualization in the animation editor, current movement mode, montage playback state, and network role prints.

What root motion does not do

  • It does not make any animation move the character unless root data is present and extraction/application are enabled.
  • It does not replace Character Movement for ordinary walking/jumping.
  • It does not bypass collision.
  • It does not make AI navigation goals update automatically.
  • It does not make multiplayer authority disappear.
  • It does not apply damage, score, or gameplay results by itself.
  • It does not fix bad export/root-bone data.

Lookalikes - which one do I want?

Tool Use when Watch out
In-place animation + Character Movement Normal locomotion should be responsive and steerable. Animation follows movement; do not expect root bone motion to move the capsule.
Root Motion Montage Authored action should move the Character for a short controlled move. Slot, root mode, movement mode, and networking all matter.
Launch Character A single velocity impulse should move a Character. Not animation-authored path control.
Set Actor Location You intend to teleport/place. Can fight Character Movement and networking if used as movement.
AI Move To AI should pathfind through NavMesh. Root-motion actions may need to pause/resume path following.
FRootMotionSource / ability tasks Code/system movement needs root-motion-style Character Movement integration. More advanced than the first Blueprint pattern.

Rule of thumb: Character Movement owns normal locomotion; root motion owns short authored movement moments where animation must drive the body.

Going deeper