How to Retarget Animations in UE5 (IK Rig + IK Retargeter)
By the Cosindra team · Updated August 9, 2026
Retargeting is how an animation authored for one skeleton plays on another. In Unreal Engine 5 that job belongs to two assets — the IK Rig and the IK Retargeter — and the workflow is genuinely reliable once you understand what each one is for. Most of the pain people report comes from a single step being skipped: the retarget pose.
This guide covers the pipeline end to end, the failures that actually happen, and the case where the right answer is to not retarget at all.
The two assets, and which does what
An IK Rig describes ONE skeleton. You create one per skeleton and it holds two things that matter for retargeting: the retarget root (the pelvis, in almost every humanoid) and the retarget chains — named bone runs like spine, left arm, right leg, head. Optionally it also holds IK goals for feet and hands.
An IK Retargeter connects TWO IK Rigs, a source and a target. It maps the source chains onto the target chains, holds the retarget pose used to align the two skeletons, and is the asset you run a batch retarget from.
The mental model worth keeping: the IK Rig says "here is what a spine is on this skeleton", and the IK Retargeter says "this skeleton's spine drives that skeleton's spine".
The workflow
- Create an IK Rig for the SOURCE skeleton (the one your animations were authored for) — set the retarget root to the pelvis, then add retarget chains for spine, neck/head, both arms, both legs, and fingers if you need them.
- Create an IK Rig for the TARGET skeleton the same way. If your target is the UE5 mannequin, recent engine versions ship or auto-generate one for you.
- Create an IK Retargeter, assign source and target IK Rigs, and check the chain mapping — matching names usually auto-map, and anything left unmapped simply will not animate.
- Fix the retarget pose. This is the step that decides whether the result looks right; see the next section.
- Preview with a real animation in the retargeter viewport before batching anything.
- Batch-retarget: select the animations in the Content Browser, retarget them through the retargeter, and choose an output folder and naming prefix so the new assets stay separable from the originals.
The retarget pose is the whole game
Retargeting compares the source and target skeletons in a reference pose and carries the difference through every frame. If one skeleton is in an A-pose and the other in a T-pose, every frame inherits that arm offset — the classic result is a character that animates correctly but holds its arms at the wrong angle, or shoulders that shear.
The fix is to edit the retarget pose on the target (and source, when needed) until the two skeletons visually match: rotate the arms so both are in the same pose, then confirm the spine and head line up. Recent UE5 versions can generate an initial retarget pose from the mesh, which gets you most of the way, but reviewing it by eye is still the difference between "usable" and "correct".
The four failures that actually happen
| Symptom | Cause | Fix |
|---|---|---|
| Arms out at the wrong angle, shoulders shearing | Retarget pose mismatch (A-pose vs T-pose) | Edit the retarget pose until both skeletons match visually |
| Character floats or sinks through the floor | Retarget root or proportion/scale handling | Confirm the retarget root is the pelvis on both rigs; check the retargeter's scale settings against a height difference |
| Fingers stay frozen while the body animates | Finger chains never mapped | Add finger chains to both IK Rigs and map them in the retargeter |
| Character animates in place, movement gone | Root motion not carried across | Confirm both skeletons have a root bone at the origin and the source clip actually has root motion — hip-driven clips have none to carry |
When NOT to retarget
Retargeting is a per-project setup plus a re-export for every animation set you adopt. Done once, it is fine. Done for every character and every pack, it compounds into real time.
If your character is headed for UE5 and your animations target the Manny/Quinn skeleton — the engine defaults plus the large pool of Fab packs built for the UE5 mannequin — the cheaper move is to rig the character to that skeleton in the first place. A Manny-native auto-rigger like RigMaster outputs an FBX already on the compatible skeleton, so those packs play directly and there is no retargeting chapter at all. Retargeting stays the right tool when the animations you want only exist on another skeleton, which is exactly the Mixamo-library case.
Skip the rigging chapter entirely
RigMaster rigs your humanoid mesh to the UE5 Manny-compatible skeleton in the browser: upload a GLB, place a few markers, download a UE-ready FBX that plays Manny/Quinn animations without retargeting.
Rig my characterFrequently asked questions
What is the difference between an IK Rig and an IK Retargeter in UE5?
An IK Rig describes a single skeleton — its retarget root, its named bone chains and its IK goals. An IK Retargeter connects two IK Rigs and maps the source skeleton's chains onto the target's. You need one IK Rig per skeleton and one IK Retargeter per source→target pair.
Why are my retargeted arms in the wrong position?
Almost always a retarget pose mismatch: the source skeleton is in an A-pose and the target in a T-pose (or the reverse), so every frame inherits that offset. Edit the retarget pose until both skeletons visually match before batching.
Can I retarget a whole animation pack at once?
Yes — select the animations in the Content Browser and batch-retarget them through the retargeter. Send the output to its own folder with a naming prefix so retargeted assets stay separable from the originals.
Do I need to retarget if my character is already on the Manny skeleton?
No. That is the entire point of skeleton compatibility: animations authored for the UE5 mannequin play on a Manny-compatible character directly. Retargeting only exists to bridge two different skeletons.
Why did my character lose its movement after retargeting?
Root motion did not carry across. Check that both skeletons have a root bone at the origin and that the source clip actually contains root motion — many library clips animate the hips instead, in which case there is nothing to transfer and movement must come from your character movement component.