How to Retarget Humanoid Animation Clips Between Two Characters

Retargeting works when you treat it as a source-versus-target problem, not a single button. You need a source GLB that actually contains animation clips with humanoid bone names GripForge recognizes, and a target character whose rest pose and bone naming are close enough for the heuristics to map correctly. Run the retarget, then inspect the result on the target rig before you trust it — arbitrary skeletons are not guaranteed to map cleanly.

Why source vs. target matters

Animation tracks refer to properties in a hierarchy, so transferring motion requires a correspondence between source and target bones. Rest pose, local bone axes and proportions can also affect the result. gripforge_retarget uses bone-name heuristics for supported conventions such as Mixamo; matching names is useful, but it does not certify that every part of the motion will fit. See the MCP documentation for the parameters.

Step 1: Review rest pose and bone naming on both characters

Before running anything, open both the source and target characters and check two things:

• Rest pose. Are both skeletons in a similar default pose (T-pose or A-pose), or wildly different? Large rest-pose divergence is a common cause of twisted forearms or rotated feet after retargeting.
• Bone naming. Do bone names follow a convention the heuristics can read (Mixamo-style names like mixamorig:LeftArm, or a similarly consistent scheme)? Renamed, merged, or missing bones (e.g., no separate hand bones) reduce mapping accuracy.

Acceptance criteria: both skeletons use a recognizable, consistent naming convention, and their rest poses are close enough that limbs point in roughly the same direction. If the target uses a custom or heavily modified rig, inspect the mapping and output rather than assuming compatibility. A separate retargeting workflow may be necessary.

Step 2: Choose a source GLB that actually contains clips

A surprisingly common failure is picking a source file that only has a rigged mesh with no baked animation clips. gripforge_retarget needs a source_id pointing to a Library GLB that already contains the clip(s) you want to transfer. Before running the tool:

• Confirm the source asset lists at least one animation clip (not just a skeleton).
• Note the exact clip name if the source contains several (walk, run, idle) — you'll pass this via the optional clip parameter.

Acceptance criteria: you can name the specific clip you intend to move, and you've confirmed it exists in the source asset before calling the tool.

Step 3: Run the retarget

Call gripforge_retarget with:

• source_id — the Library GLB containing the clip.
• target_id — the Library character that should receive it.
• clip (optional) — the specific clip name if the source has more than one.
• name (optional) — a label for the resulting output so it's easy to find later.

The tool applies its bone-name heuristics and produces a retargeted result tied to the target skeleton. It does not guarantee that arbitrary skeleton pairs will map — if bone names or hierarchies diverge, verify the result before choosing this workflow for the asset.

Step 4: Inspect the clip on the target character

Don't ship a retarget on faith. Open the resulting animation on the target character in an appropriate viewer or your game engine, and check:

• Feet: no sliding, no floating, no ankle rotation past a natural range during footfalls.
• Hands: fingers not clipping through weapons or clothing, wrists not over-rotated.
• Equipment: anything attached to hand or spine bones (weapons, shields, capes) should track naturally through the full clip, not just at the first frame. If you're also aligning weapon sockets, the socket-transfer workflow in the Unreal weapon socket checklist covers that inspection step in more detail.
• Root motion: if the clip drives forward movement, confirm the target's root bone moves at a sensible scale for its size — check the imported scale and how the game consumes that motion.

Acceptance criteria: the clip plays through its full length on the target without visible foot sliding, joint popping, or equipment detachment at any frame you scrub to, not just frame one.

Step 5: Save reusable output

Supply a useful output name when you request the retarget, then record the resulting Library asset identifier after inspection so teammates can retrieve the accepted result. Keep the source clip and target character identifiers with that record. If you're working through the local MCP client (@gripforgeai/mcp), its gripforge_library_pull tool can write the result into your project folder. The hosted endpoint at https://gripforge.ai/mcp returns an asset URL but cannot write directly into your local project — pull it down explicitly when you want a local copy. See the MCP docs for both paths, and the general documentation for broader setup.

Troubleshooting

Checklist before shipping a retargeted clip

• [ ] Source GLB confirmed to contain the named clip
• [ ] Source and target rest poses compared
• [ ] Bone naming convention consistent on both rigs
• [ ] Resulting clip previewed full-length on the target in the viewer or game engine
• [ ] Feet, hands, and equipment checked at multiple frames, not just frame one
• [ ] Output saved with a clear name and pulled into the local project if needed

FAQ

Will retargeting work between any two humanoid rigs?

No. gripforge_retarget uses bone-name heuristics for supported conventions such as Mixamo; arbitrary or heavily customized skeletons are not guaranteed to map correctly.

Where does the retargeted asset get saved?

The hosted MCP endpoint returns an asset URL. To get a local file, use the local MCP client's gripforge_library_pull tool, which writes into your project folder.

What should I inspect when a retarget looks wrong?

Inspect bone correspondence, rest poses, local axes and proportions, then check how the target engine applies the clip. Different symptoms can have different causes.

For the broader pipeline this fits into, see rigged, animated characters from a text prompt.