PoseSearch Query is flipped 180 degrees 1 frame after a capsule/actor rotation happens.

Using MotionMatching with a PoseSearchSchema with a Trajectory grouping. The query gets rotated to match the capsule/mesh component instead of the offset root/actual location of those bones/trajectory. This only happens for 1 frame after changing directions. Using rewind debugger Run in one direction, then turn 180 degrees and keep running. pause editor and step through the rewind debugger pose search details. Draw the query and Trajectory. Note that they are in sync most of the time. 1 Frame after picking a turn 180, the query is rotated 180 off from the Trajectory. The next frame it is back in sync with the Trajectory. The query should always be in sync with the Trajectory.

I was unable to repro this using the Animation Sample in 5.6.1. But both Atomic Arcade and Invoke Studios are experiencing this issue after updating from 5.5 to 5.6.1.

Steps to Reproduce
Using motion matching like the Game Animation Sample.

  1. Run forward in orient to movement
  2. Perform 180 pivot/turn
  3. Continue running in the new direction
  4. Notice the rewind issue on the second frame of a turn

Hey there,

In the game animation sample, we sample the pose history node every frame to generate the trajectory using the Pose Search Generate Trejectory (for Character). The intention here is to handle when there is an offset in mesh from the desired capsule rotation. This function does require you to inherit from ACharacter. It is possible there is a desync between your pose history node and your capsule update depending on what you are feeding in as your trajectory.

I think we would need to understand more about your setup, how you are calculating trajectory, and what differences you may be seeing in those setups and the Gameplay Animation Sample Project.

Thanks,

Dustin

I can do some work to validate any key differences between 5.5 and 5.6 (there was some deprecated calls) but if you have an video or screenshots you can post showing your setup, how you generate trajectory, and what you’re seeing in the rewind debugger, it can go a long way to helping us finding what the issue might be.

Are you fully capsule driven or are you using any root motion?

Are you using GASP animation, or are you using your own animation? If you are using your own animation, it might also be helpful to look at how your root bone is animated.

Dustin

I am experiencing the same on 5.6.1

I reverted the pose search, chooser & blend stack plugins to 5.5 and the problem went away.

It seems like in the continuing pose feature vector there is an issue after the swift 180 that we do (that gets counter animated by the offset root motion)

I am fully capsule driven, with our own animations, but with the same data 5.5 does not have the issue

Hey folks,

We are struggling to reproduce the trajectory, but this has highlighted some potential debug draw issues; we’re still exploring what those might be. In your screenshots, for example, there is a disconnect of the green lines, and the velocity of the feet potentially points in the wrong direction.

That said, if you can share any videos of specific issues with your trajectory or cases where you feel the debug information is not showing you what you expect, that would be helpful. We don’t believe this is causing any problems with your queries, but if you are experiencing issues, we would need a video of your content to help verify.

Dustin

Hi Dustin,

I do not believe it is a debug rendering problem. The query thinks that’s where things are. Possibly rotated with the actor instead of staying in line with the root. The scores from the PoseSearch debug details shows the trajctory problem. Sharing video would require a confidential ticket(which we can do if necessary). But the repro in GameAnimationSample should be the same problem. Here’s screengrabs of the details showing the bad scores.

[Image Removed]

Notice the score goes from .251 Trajectory to 1.802 Trajectory picking a different turn animation the next frame. This is because of the query Trajectory bug. It keeps picking different animations because of this. (Orient to movement, turn 180).

Thanks,

Josh

Thanks for all of that info, we’ve been able to repro and see the issue you’re describing in GASP and we’re currently looking into it still. Unfortunately, at this moment, I don’t have much information in terms of potential workarounds or systems to investigate that could be affecting the trajectory data. I’ll log a bug and post a link to the issue here for you to follow as well.

I’ve logged the issue here, it will take 24-48 hours to show up.

https://issues.unrealengine.com/issue/UE-317264

Yep, with your example case, we were able to identify an issue where the pose search history was desynchronized by delta time.

The CL in Perforce is 45599537, but since you are having issues seeing that, you can also see the change here:

https://github.com/EpicGames/UnrealEngine/commit/48ce30580e11682d5a7635110547518aa3589134

Hi Dustin,

The trajectory itself is correct. It appears to be the Motion Matching schema/scoring. If I render what the query looks like via the rewind debugger I can see it doesn’t line up with the Trajectory. The Trajectory is correct, where the Motion Matching query thinks the trajectory is incorrect.

As far as I can tell we have pretty much the same setup as the sample. I don’t understand how the sample works with what Invoke and I both can repro with no shared code between us. We were working correctly in 5.5. 5.6 introduced this issue.

Thanks,

Josh

Update: I am able to repro the query issue in the GameAnimationSample(5.6.1). It doesn’t appear to happen to the trajectory in the sample (trajectory and query are in sync). But the Feet tracking is rotated 180 degrees. You can see the debug rendering where it thinks the feet are, is 180 degrees off. It doesn’t happen on the first frame of the rotation. It appears to be the second frame that it gets confused. And it is only wrong for 1 frame then fixes itself. We experience it with our bones and our trajectory.[Image Removed]

We managed to repro the Query not lining up with the character even in 5.5. Something with 5.6 has it causing other issues.

When I get this its also good to see that lower in the list, the frames around the continuing pose all have very high trajectory cost.

So 1 frame after choosing a 180 degree pivot, all frames around it show up as very expensive in terms of cost

It looks like that bug is flagged as fixed! When we use our login to your perforce it appears restricted. Any chance you can share the fix with us?

Thanks, and I updated our TrasnformHistory to match. Seems to resolve the issue! Thanks for the support!