The issue is caused by the way that we calculate the leader sample's Time vs the follower sample’s Time and how that calculation switches on the frame when a follower sample becomes a lead sample. On that frame, we continue to update LeaderSampleData.Time and PreviousTime using the same logic that we did on previous frames when the leader didn’t change. ie. the following code:
float CurrentTime = NormalizedCurrentTime * NewAnimLength;
LeaderSampleData.PreviousTime = CurrentTime;
FAnimationRuntime::AdvanceTime(Instance.bLooping, NewDelta, /*inout*/ CurrentTime, NewAnimLength);
LeaderSampleData.Time = CurrentTime;
NormalizedCurrentTime = NewAnimLength ? (CurrentTime / NewAnimLength) : 0.0f;
This uses NormalizedCurrentTime (based on the time accumulator of the BS) to calculate the new PreviousTime and Time of the lead sample (Time is set again in ResetBlendSamples). But this new time bears no relation to the time of the sample on the previous frame when it was a follower and was being updated via the follower branch logic (ie. by UBlendSpace::TickFollowerSamples). So we can get pops from large jumps forwards, or backwards, in the playback time.
Note that while the intention with this update mode is that it’s used with a motion matching or blendstack node, the layer blending when the BS parameters change only partially hides the issue.
There's no existing public thread on this issue, so head over to Questions & Answers just mention UE-393854 in the post.
| 0 |
| Component | UE - Runtime - Anim BP |
|---|---|
| Affects Versions | 5.8.2 |
| Created | Aug 27, 2026 |
|---|---|
| Updated | Aug 27, 2026 |