Unexpected anim sync groups time position behaviour during transitions or blendings

For the last month of work on my project i found several bugs in sync groups behavior. I dont know how many more oddities has sync groups code, but its already critical for my project.

Link to expample project - syncGroupBugsV26.7z - Google Drive

steps te reproduce:

step 0. Download and open project (v4.26)

step 1.Open state machine in ThirdPerson_animBP and link entry pin to any walk state for dubug

step 2. Run game and see resuilts.

note: transition rules driven by pulsating value in animBP, change pulsating rate for faster or slower transition rate between walk and run states.

Here is what i found and stored in example TPS project for easy debugging.

case 1. Sync group always reset time position during zero or near zero transition between states in state machine.

I think if transition fully executed at one frame, sync group time will reset to most relevant anim start position. If i set sufficient time for transitions (eg 0.1), sync group will keep previous position correctly, but if i clamp max FPS to 10 for example - sync group again will reset position.

case 2. Sync group always reset time position during transition between states in state machine in inertialization mode, independently to blend duration time.

Same problem, but in inertialization mode that error happens always, independently to blend duration time. That means i cannot use this feature if anims in different states are synced.

case 3. Sync markers based syncing dont work with non-looping animations.

If new leader animation in marker based sync group is non-looping - sync group always reset position in all cases.

case 4. Sync markers based syncing ignores “Always reset on entry” option in anim state settings.

If blended states has true “Always reset on entry” option, marker based sync group will keep prev position without reset

This behavior list also detected with blend nodes winthin one anim state…

This bug also reported to new Epic’s bug submission form (Case # 00346730), but this does not provide an opportunity for community discussion or editing. I hope devs will pay attention to my problem. Thanks and sorry for my English!

1 Like