Motion Matching Heading Channel issues with Input Query Pose

Hey! We’ve been using Motion Matching in our project and we have an issue regarding the Heading channels used. We want to know more details about it and how they are handled internally.

If we replicate the schemas used in GASP in our projects we are getting undesired results, specially on 180 pivots. We found out that changing the Input Query Pose to Continuing Pose on the Future Trajectory channels was giving us the result we wanted, I mean, picking the right animation because the query trajectory was matching with the animation we wanted to be picked.

The thing is, if we change that, 180 starts and TIP are not working as expected. Cause by default, the subchannels of the trajectory are considering the Input Query Pose to Character Space.

We have noticed that if we do the same test on GASP, the differences are not that big even though there are still differences. For example, when triggering pivots, using the continuing pose instead of Character Pose, we will always try to do a right 180 pivot, instead of changing between Left and Right.

So, on our case we need the Continuing Pose for Pivots but directional starts work with Character Space. We want to know if you guys can provide more info about the difference between the two, why you are using the Character Pose as default for trajectory subchannels, why can our issue be happening etc…

Thank you very much for your time.

Steps to Reproduce
We are using GASP for comparing with our project.

  • Go to the PSS_Default schema.
  • Remove the Facing Direction XY trajectory subchannel
  • Create a Heading Channel with the same values

[Image Removed]

Hi, sorry for the delay getting back to you on this. In terms of your specific question about Use Continuing Pose vs Use Character Pose, that changes how the data used for the query is generated. Use Continuing Pose will use data from the next frame of the currently active animation in the database in order to generate the query. Whereas Use Character Pose will try to use data from the pose history in order to construct the query. In the case of the Trajectory, that will be the data that is passed via the Trajectory input on the Pose History node in your anim blueprint:

[Image Removed]In terms of why you see the difference in behaviour, there could be a number of reasons. You can imagine that if the trajectory generation is not consistent with the motion of your animations, you would get inconsistent results. This could also happen if the sampling of the trajectory on the Pose History node isn’t granular enough to catch quick snaps in orientation change (note that in GASP we have the sampling interval on the Pose History node set to every frame which is not the default - you mentioned you had copied the schema setup but you didn’t say about the anim bp nodes).

The best thing to do in terms of tracking down why you don’t get the expected results is to look at the pose search scoring data inside Rewind Debugger. We show some of this debugging in one of the livestreams that we’ve done, which you can find here. That way, you can look at the scoring of each of the poses to understand which channel in the query was responsible for the incorrect pose being selected.

It’s worth mentioning that we also have the ability to draw the heading direction when looking at the pose search debug data in Rewind Debugger via this option:

[Image Removed]Here, the white line represents the x-axis of the mesh and the black line the x-axis of the root. If you see discontinuities in these (eg. a flip 180 degrees) then that’s also a sign that there is an issue with the animation.