Summary
We have encountered a regression in UE 5.7 where Skeletal Mesh Morph Targets do not visually reset when all weights are set to 0.0.
The mesh retains the deformation from the previous frame. This issue was not present in UE 5.5.After analyzing the render thread code, it appears to be caused by changes in how bMorphNeedsUpdate is handled and a missing check for the “transition to zero” state in
FSkeletalMeshObjectGPUSkin.
Technical Analysis
We compared the implementation of FSkeletalMeshObjectGPUSkin
between UE 5.5 and UE 5.7.1.
UE 5.5 (Correct Behavior) In 5.5,UpdateDynamicData_RenderThread compares the previous and current frame’s active morphs. Even if the current frame has no active morphs (weights are 0), ActiveMorphTargetsEqual returns false (because the previous frame had morphs), setting
bMorphNeedsUpdate to true.
C++
// UE 5.5 Logic
bMorphNeedsUpdate =
InDynamicData->ExternalMorphWeightData.HasActiveMorphs() ||
(DynamicData ? (DynamicData->LODIndex != InDynamicData->LODIndex ||
!DynamicData->ActiveMorphTargetsEqual(InDynamicData->ActiveMorphTargets, InDynamicData->MorphTargetWeights)) // <--- Detected change here
: true);
This ensured ProcessUpdatedDynamicData was called to clear the buffer.
2. UE 5.7 (The Issue) In 5.7, bMorphNeedsUpdate has become a member variable, and the update logic inside FSkeletalMeshObjectGPUSkin::ProcessUpdatedDynamicData seems to optimize too aggressively when there are no active morphs.
C++
// UE 5.7 FSkeletalMeshObjectGPUSkin::ProcessUpdatedDynamicData
const bool bHasWeightedActiveMorphs = DynamicData->NumWeightedActiveMorphTargets > 0;
// ...
if (GEnableMorphTargets && ... && (bHasWeightedActiveMorphs || bHasExternalMorphs))
{
// Normal update path
if (bMorphNeedsUpdate) { ... }
}
else
{
// Regression Cause:
// If weights become 0, we enter this block.
// The code assumes we don't need to do anything, effectively skipping the "Clear" pass.
MorphVertexBuffer = nullptr;
bMorphNeedsUpdate = false;
}
Because it enters the else block immediately, the render thread never executes the logic to bind a cleared/null buffer or reset the existing one. The GPU continues to use the dirty buffer from the previous frame.
Workaround
We confirmed this analysis by setting the weight to 0.001f instead of 0.f.
This forces bHasWeightedActiveMorphs to true, triggering the update path, and the mesh updates correctly.
Request
Could you confirm if this logic change was intended? It seems the logic needs a check to see if “morphs were active last frame” to perform a one-time clear/reset.
[Attachment Removed]