Sync IK Bones
Bake ik_foot_l / ik_foot_r and the ik_hand_* bones so they follow the
real feet and hands. Retargeted takes leave them parked at the reference
pose, which drags the legs in game while the clip previews perfectly.
Panel: Review → Sync IK Bones. Context menu: TakeForge → Utilities → Sync IK Bones. Always in place - see below.
The bug it fixes
The UE mannequin carries a second, parallel set of bones - ik_foot_l,
ik_foot_r, ik_hand_l, ik_hand_r, ik_hand_gun - which exist only so
that gameplay solvers have something to aim at. Nothing drives them
automatically. An animation authored on the mannequin has them baked in; an
animation retargeted from a rig that has no such bones - Mixamo, and most
mocap - leaves them sitting at the reference pose for the whole clip.
That failure is close to invisible:
- the clip previews correctly, because no IK runs in the asset editor
- the skeleton is right, the length is right, the track count is right
- only in game, where Foot Placement and Leg IK solve toward
ik_foot_landik_foot_r, do the legs get dragged toward a bone pinned near the origin
The symptoms are tiny steps, no foot lift, skating feet - and a torso that looks perfectly fine, which is what makes it so easy to misdiagnose as a retarget or a blendspace problem.
Measured on the UEFN mannequin, with total travel of each IK bone over one clip:
| Clip | ik_foot_l | ik_foot_r |
|---|---|---|
Epic's M_Neutral_Run_Loop_F (authored on the rig) | 964.1 cm | 961.0 cm |
| The same run retargeted from Mixamo | 0.0 cm | 0.0 cm |
| That retarget, after Sync IK Bones | 209.9 cm | 204.2 cm |
What it does
The rule is one line: an IK bone's component-space transform should equal its driver's. Each IK bone is written as a full track expressing exactly that, in its own parent's space.
| IK bone | Follows |
|---|---|
ik_foot_l | foot_l |
ik_foot_r | foot_r |
ik_hand_gun | hand_r |
ik_hand_l | hand_l |
ik_hand_r | hand_r |
ik_hand_r comes out at identity, because its parent ik_hand_gun already
tracks hand_r - which is exactly what Epic's own animations contain, and it
falls out of the rule rather than being special-cased.
ik_foot_root and ik_hand_root are deliberately left alone. They are
anchors parented to the root, and Epic's animations leave them at identity;
driving them would move every IK bone beneath them twice.
A rig without IK bones is not an error - there is simply nothing to drive,
and you're told so. A rig that has ik_foot_l but no foot_l is reported as
not following the mannequin's naming.
When to run it
- After any retarget from a rig without IK bones. It is on by default in the retarget cleanup (Then run), where it runs last - after Foot Lock, so the IK bones shadow the feet where the lock finally left them rather than where they started.
- On an existing library that was retargeted before 1.22, or with any other tool. Select the folder, right-click, run it once.
If the feet look right in the asset editor but the legs barely move in game, this is the first thing to check.
Why it edits in place
Every other output-producing tool writes a suffixed copy. This one rewrites
the take you gave it, because an IK bone shadowing the wrong pose is a
defect in the asset, not a variant of it - a *_IK copy would leave the
broken original sitting next to it, still the one your Anim Blueprint
references. It is a normal undoable transaction in-session.
The completion notification lists which bones were baked. To verify the
result rather than trust it, compare against a clip authored on the rig: an
ik_foot_l that travels roughly as far as foot_l is correct; one that
travels 0 cm is the bug.
Scripting:
# include the hands as well as the feet
ok, err = unreal.TakeForgeLibrary.sync_ik_bones(seq, True)
# feet only - leave ik_hand_* alone
ok, err = unreal.TakeForgeLibrary.sync_ik_bones(seq, False)