Weapon Socket Offset on Retargeted Characters (UE 5.6) – Correct in Editor, Offset at Runtime

Development Character & Animation
1

Post body (cleaned, optimized)

I’m encountering a persistent and frustrating issue with weapon placement on retargeted characters, including MetaHumans and others derived from the Game Animation Sample.

:small_blue_diamond: Problem Summary

When a weapon is attached to the hand socket, it appears correctly positioned and perfectly aligned in the Skeletal Mesh Editor preview.
However, once gameplay begins, the weapon shifts a noticeable distance away from the hand.
This occurs with all retargeted characters (including MetaHuman), though the offset is smaller on MetaHuman.

The parent character (UEFN mannequin) holds the weapon perfectly in-game, confirming the issue only affects retargeted skeletons at runtime.

:small_blue_diamond: Steps Already Taken

  1. Socket setup:
    Created Weapon_Socket on the hand_r bone of each character. In the Skeletal Mesh Editor, the weapon preview aligns perfectly after manual adjustment.

  2. Attachment logic:
    Weapon actor is attached via Blueprint using

    AttachActorToComponent(Mesh, Weapon_Socket, SnapToTargetIncludingScale)

    ensuring a perfect initial alignment in editor preview.

  3. Parent/child test:
    Making the character mesh a child of the base UEFN mannequin skeleton fixes the offset visually — but introduces severe animation artifacts (stretching, floating, incorrect poses).

  4. Debugging:
    Added debug spheres to track world transforms of both socket and weapon mesh.
    The offset appears only during gameplay, implying it’s introduced after animation evaluation.

  5. IK & Retargeting:
    Verified bone mappings in the IK Retargeter. Locomotion plays correctly, but hand location does not match runtime socket transform.

:small_blue_diamond: What I Suspect

  • A timing issue during animation update: the weapon attach might be reading the socket transform before final pose evaluation.

  • A mismatch in retargeted bone scales or constraints between skeletons.

  • A Control Rig / additive layer overriding the hand transform at runtime.

  • A hidden Retarget Pose or IK Goal offset baked into the animation data.

:small_blue_diamond: What I’d Like to Know

  • Are there known issues where additive animation blending or IK retargeting introduces small runtime offsets on sockets?

  • Could differing PhysicsAssets or Skeleton Hierarchies cause socket displacement?

  • Is there a known fix using Post Process AnimBP or ModifyBone nodes to compensate?

  • Which tools best visualize per-frame bone transform deltas at runtime? (e.g., Animation Insights, Pose Watchers, Control Rig debug, etc.)

:small_blue_diamond: Version Info

  • Engine: Unreal Engine 5.6

  • Template: Game Animation Sample (motion matching)

  • Characters: MetaHuman and other retargeted skeletons derived from UEFN mannequin

Any advanced insights, debugging steps, or engine-level explanations would be greatly appreciated.
I’m not looking for “check your socket placement” type answers — I’ve verified all transforms match perfectly in the editor.
I’m specifically trying to understand what happens between animation update and attachment transform evaluation on retargeted characters.

2

I had the same issue. I was using a different weapon mesh in my character mesh preview compared to what I was equipping to my character (SM vs SKM)

3

I’m having the same issue with metahumans in gasp 5.7. I’ve tried doing a set relative location on the weapon after it’s attached to the socket but this seems erratic. I know I had this working in 5.5.4 gasp but so far it’s just making me a bit crazy in 5.7

4

I’ve solved this but I’m not sure exactly how I did it. It was all in the retargeting. I generated the two IK rigs for UEFN and makehuman skeletons, then created a new retargeter and loaded those into it. I fooled around with a couple of iterations of this for a day or two. I ended up making a new chain for the arm, then disabling IK on it. Or I think that’s what I did. But it works now so the solution is in the retargeter.