MotionWarping — 100% crash in `UMotionWarpingUtilities::ExtractBoneTransformFromAnimationAtTime` with compatible skeletons (bone index out of bounds)

Hi - We’ve run into a 100% repro crash when calling `UMotionWarpingUtilities::ExtractBoneTransformFromAnimationAtTime` when using `BonesToRemove` feature in the skeletal mesh LOD settings.

We’ve attached a 100% repro of this crash that happens on a very small repro project. As you can see in the callstack, `UMotionWarpingUtilities::ExtractBoneTransformFromAnimationAtTime` in `MotionWarpingComponent.cpp` crashes with an array index out of bounds when the AnimBlueprint’s skeleton and the SkeletalMesh’s skeleton are different but compatible.

[Image Removed]

Repro conditions:

- AnimBlueprint compiled against Skeleton A

- SkeletalMesh assigned with compatible Skeleton B

- Motion Warping notify references a bone by name for warp point extraction

Root cause analysis:

`GetPoseBoneIndexForBoneName()` (line 260 in `UMotionWarpingUtilities::ExtractBoneTransformFromAnimationAtTime`) internally calls `RefSkeleton->FindBoneIndex(BoneName)` and returns a mesh/skeleton bone index. The code then wraps this directly in `FCompactPoseBoneIndex(BoneIndex)` and uses it to index into `FCompactPose` or `FCSPose<FCompactPose>`. The compact pose only contains the bones in the required bones set - a subset of the full skeleton - so the skeleton-space index can be larger than the compact pose array, triggering an out-of-bounds access.

With compatible skeletons, the mismatch is amplified: the bone container is from Skeleton A, but the pose data is evaluated against Skeleton B’s bone layout. An index valid in one skeleton’s compact representation is meaningless in the other’s.

Expected fix (already applied locally):

Convert the mesh bone index to a compact pose index using `FBoneContainer::MakeCompactPoseIndex(FMeshPoseBoneIndex)` before indexing into the pose. This is the same pattern used elsewhere in the engine (e.g., `AnimSingleNodeInstanceProxy.cpp` line 534). An additional `INDEX_NONE` check is needed on the resulting compact index in case the bone is present in the skeleton but absent from the required bones set.

[Image Removed]

Affected file: `Engine/Plugins/Animation/MotionWarping/Source/MotionWarping/Private/MotionWarpingComponent.cpp` — `ExtractBoneTransformFromAnimationAtTime`, both the local-space and component-space code paths.

Please advise if this fix seems reasonable (since we’ve applied it as an engine mod), and please let us know if there will be a fix directly in the engine source in future versions so that we don’t need to continue to maintain this engine divergence to avoid the crash.

[Attachment Removed]

Steps to Reproduce

See the `MotionWarpingCrashRepro_Explained.mp4` video found in the attached min-repro sample project .zip file - pressing play with the `BP_MotionWarpingCrashRepro` blueprint in the level will trigger the crash.

[Attachment Removed]

Hi, thanks for reporting this (and taking the time to make the repro project). In this case, we ran into the same issue a while back and have made the same fix. If you want to look at the CL, it’s 51652808. The only difference is that MakeCompactPoseIndex should deal with the failure case when GetPoseBoneIndexForBoneName returns an invalid index. That change will be part of the 5.8 release.

[Attachment Removed]

No problem! No, unfortunately, we don’t have anything that I’m aware of which is external-facing and will map from the P4 CLs to git commit hashes. You can always ask on EPS if you need to know since we can track them down quite easily, although I realize it would be much more helpful to have something that gave you the information immediately. In this case, the git commit is here.

[Attachment Removed]

Thank you! We’ll remove our engine mod once we upgrade to 5.8 in the coming months. As an aside, what’s the easiest way to go from a CL number like you posted to the actual change diff in the Unreal GitHub repository? Are there instructions anywhere for licensees for how to do that?

[Attachment Removed]