Troubleshooting & FAQ

A retargeted take previews stretched until it is saved

Save the asset. The animation data was never wrong - the editor was previewing an unsaved asset from state it had not finished building, and saving (or pressing play) makes it re-evaluate. See Retarget Takes.

The clip previews fine but plays IN PLACE in montages / gameplay

The nastiest case first, because nothing you toggle fixes it: broken bone track order. Some mocap and retargeter exports list the animation's bone tracks out of skeleton order (e.g. head first, root second). UE's compression then silently drops the root track - the take looks perfect in the editor (which samples raw data) but loses all root motion in montages and gameplay (which sample compressed data). Every asset derived from such a take inherits the problem.

Run Check Take: it reports Extracted root motion (what montages actually receive) and warns when the track order is broken. Fix Track Order (Review section) repairs the asset in place, losslessly. TakeForge actions normalize their output automatically, so this only affects takes that arrived from somewhere else.

The processed clip plays in place in UE - where's my root motion?

The root track is there; UE is just not applying it. Three cases:

1. Anim editor preview: with Enable Root Motion checked, the preview extracts the root motion and - in a fresh viewport - discards it, so a perfectly good clip plays in place. This is a per-editor-window setting, which is why the same clip can travel in one window and sit still in another, and why no asset checkbox changes anything. Click Preview Root Motion in the TakeForge panel's Motion section (or set the viewport's Character → Root Motion → Loop) to see the travel and the trail. Placing the clip on a level or in a montage always consumes it correctly.
2. Root motion enabled but not consumed: a regular Anim Blueprint ignores root motion unless Root Motion Mode = Root Motion from Everything (class defaults), or the clip plays inside a Montage with root motion.
3. Enable Root Motion off entirely: the mesh will visually travel away from the capsule instead.

My climb/ladder take keeps X and Y but never rises

Transfer Vertical is off - it is off by default, and it is what carries height to the root. With it off the root reproduces the horizontal path and holds a single height, so a climb looks like the character sliding up an invisible rail while the root stays put.

Changing the follow bone will not help, and this is the part that sends people in circles: the vertical component is dropped after whichever bone was sampled, so every bone gives the same flat result.

Turn on Transfer Vertical (TakeForge panel → Defaults, or Editor Preferences → Plugins → TakeForge → Motion) and re-run the conversion. Height is measured against the reference-pose pelvis, so standing height does not offset the result - you get the climb, not the character's height plus the climb. From 1.23 the completion notification flags this case for you, naming how much vertical travel was dropped.

In-place conversion has the mirror version of the same problem: with the setting off the vertical travel is never removed, so a climb converted to in-place still rises.

One gameplay note once the height is baked: the take previews correctly, but CharacterMovementComponent in Walking mode constrains Z and will fight it. Root-motion climbs are normally played with the movement mode switched to Flying (or a custom mode) for the duration of the montage.

"Could not find a pelvis bone"

The configured Pelvis Bone (pelvis by default) is tried first. When the skeleton has no bone by that name, auto-detect tries pelvis, hips, hip, mixamorig:hips, then the first bone with 3+ children. The error means both failed - exotic rigs (extra IK roots, prop bones high in the hierarchy) can defeat the heuristic. Set Pelvis Bone to the right bone in Settings.

Before 1.24 a configured name that was not on the skeleton failed outright, so every Mixamo take (mixamorig:Hips) stopped with "Pelvis bone 'pelvis' not found" until the setting was changed.

"Pelvis bone is the skeleton root"

Your skeleton's bone 0 is the pelvis (some mocap-tool exports have no dedicated root bone). The tool needs a root bone above the pelvis to receive motion. Re-import the skeleton with a root (most mocap exporters have an "add root bone" option), or retarget onto the UE5 skeleton first.

Foot markers are mistimed or missing

• Markers in the swing phase → lower Foot Contact Height Fraction (0.15).
• Missed plants on shuffling gaits → raise it (0.35).
• Zero markers → the foot never rose 1 cm (idle-like take; expected), or the foot bones resolved wrongly - check the bone names in the Check Take report and override in Settings.

Running Ground Snap again does nothing

That is correct. Ground snap targets an absolute height - the reference floor plus Ground Offset - and re-measures the feet on every run. Once they are there, a second run finds nothing to move. The offset is a destination, not a step: for feet 10 cm lower, set −10 once rather than −5 twice.

If the first run did not finish the job, repeating it will not either:

• Whole take zeroes the median plant. Plants above or below that median keep their own error - use Per contact for those.
• Per contact refuses takes whose plants span more than 15 cm (stairs, a slope), and caps each correction at Max Correction.

Check Take reports how far the plants sit off the floor; measure_ground_contact in the Python API also returns the spread between them.

The loop still pops after Make Loopable

• Raise Loop Blend Frames (12–16) for takes with a big start/end mismatch.
• Check the loop mismatch line in Check Take - a "poor candidate" take is better fixed by trimming to a cleaner cycle first.
• A pop in position on a root-motion clip at the seam is expected if the root's velocity differs strongly between end and start - the pose wraps, the root keeps its own motion. Use in-place clips for perfectly seamless cycles.

Trim/Split moved my notifies

Notifies and markers are remapped by the engine's resize API to the new timeline; notifies outside the kept range are removed with the frames they sat on. That's the intended behavior - trim before authoring gameplay notifies when possible.

Can I undo?

Yes. All processing runs inside transaction brackets - Ctrl/Cmd+Z in the editor reverts an in-place action. Created copies can simply be deleted.

Does it change my original assets?

Not unless you ask it to: with Create New Assets on (default), originals are never touched. Unchecked, actions rewrite the selected asset - still undoable in-session.

Which skeletons are supported?

Any humanoid skeleton with a root bone above the pelvis: UE5/MetaHuman (auto-detected end to end), Mixamo-style rigs, and custom skeletons via the bone-name settings. Quadrupeds work for the root-motion math (pick the hips equivalent) but foot-marker auto-detect assumes two feet - set bones manually and expect to place extra markers yourself.

Is the plugin needed at runtime?

No. It's an editor-only module - processed assets are plain AnimSequence assets with standard tracks, curves, and markers. Nothing ships in your packaged game.