Retargeting maps animation from one skeleton onto another so a library of motion works across many characters.
What has to match
- Skeleton structure. The same bones in the same hierarchy. Extra bones are usually fine; missing ones are not.
- Bone naming, or an explicit mapping between the two.
- A shared reference pose, so the systems can compute the difference between the source's rest pose and the target's.
What can differ
Proportions, mostly. That is the whole point: a short character can play a tall character's walk, with the system scaling translations to suit.
Where it goes wrong
- Foot sliding. Different leg lengths mean the same hip motion covers different ground. Solved with IK on the feet.
- Interpenetration. A character with a wider torso puts its arms through itself in an animation authored for a narrower one.
- Contact points missed. A hand that reached a hip precisely now reaches the air, because the hip is elsewhere.
- Style loss. A heavy character playing a light character's animation reads as weight-less. Retargeting preserves motion, not intention.
IK correction
Inverse kinematics fixes the contact problems: pin the feet to the ground and the hands to their targets, and let the solver adjust. Most engine retargeting systems include this, and it is what makes retargeted animation usable rather than approximately right.
Humanoid abstractions
Some engines define a standard humanoid abstraction and retarget through it rather than skeleton to skeleton. That makes any conforming character able to play any conforming animation, at the cost of some fidelity to the original motion.
Why standard skeletons matter
All of this works because skeletons share a layout. Adopting a widely-used humanoid convention — rather than an idiosyncratic one — is what makes third-party animation, motion capture libraries and engine tooling available to you without remapping every time. It is the main practical argument for auto-rigging producing a standard skeleton.