Offset root rotation and heading channel query issues with Rewind Debugger

Development Character & Animation
, ,
1

I’m investigating the interaction between offset root node and pose search. Specifically for turn on the spot animations. I know that in the Game Anim Sample this is solved. But we cannot make the capsule rotate instantly due to other game dependencies. So I’m looking into fixing this in different ways.

My main idea is to use offset root. What we have at the moment is:

  • We register input and a start animation begins, which uses offset root to avoid sliding
  • Input stops, our start animation has played a couple frames. The capsule rotates fast so it’s ahead (2/3 of the way), the animation is about 1/3
  • A turn on the spot anim is picked. However, I’m seeing inconsistencies in rewind debugger on the heading vectors of the trajectory.

The query debug draw seems to be based on my current animation root, rather than the direction that I wish to face. Which makes sense because when the query is built the pose history is used to find the root transform. Since offset root modifies the bone, it gets recorded in the history.

But this is a problem because now there is a mismatch between my trajectory and the query. So the animations that are picked never reach the full rotation I requested.

I found the bDefaultWithRootBone flag, which is not exposed on the trajectory feature channel. And it seems to be able to overcome this issue. The query perfectly aligns with my trajectory if I dont use offset root. However, if I use offset root bone the query shown in RDebugger seems to have an offset.

This offset I believe is due to FSearchContext::GetSampleRotationInternal still using RootSchemaBoneIdx even when SchemaOriginBoneIdx tells it to use the trajectory. However, I believe it could also be an issue with RD debug draw code, and not the runtime code. (could be both?)

What I see is that the further away trajectory samples, seem to overshoot by the root offset rotation amount, and as the animation catches up with the capsule, that error reduces.

My concern is that visually I cannot see any issues on the animation. And when new anims are selected, they seem to pick the correct frame for the given capsule trajectory.

But the RD is showing that the query may be wrong. I really want to trust the RD because it’s the only tool to see through pose search at the moment, so it’s a little concerning and I just want to verify.

I also know that flag is experimental and GASP uses Steering (I’m not fully sure I understand that second steering node btw). But perhaps you have any pointers on what is happening here.

2

Just wanted to add some notes to clarify. After getting some perspective.

It’s up to us on what trajectory we feed into the pose search history collector. This trajectory on our end is being built based on the capsule movement. Which starts being an issue once root offset kicks in.

After some thought, I don’t think we want to use bDefaultWithRootBone=false, because we want to make the current pose find the best animation that leads it to where our capsule is going, from where the root bone is.

To recap. We have:

MM -> OffsetRoot -> … -> Pose History -> OutputPose

PoseHistory gets the trajectory that we build on update. And records the root transforms on evaluate.

My current line of thought in order to produce frame accurate trajectories whilst using offset root. Is that we want to produce trajectories that:

  • Have the recorded root samples from previous frames, available in pose history
  • Start where the root is at time offset 0.
  • Warp the trajectory samples from that transform towards our capsule based generated samples

With our current approach we have:

  • Trajectory build fully based on capsule’s past and future
  • Query is built from root transform, but samples are built from capsule transform. This generates a mismatch in the query.
  • bDefaultWithRootBone=false seemed like it would help fix this mismatch. But even if that works to generate queries based at the trajectory, the samples still assume we depart from the capsule’s history, not the root’s. So we’re not really asking for the poses we need to get from A to B.

My current idea is to postprocess the trajectory, to warp it to always follow our capsule predicted movement, but keeping its past and current sample to be faithful to the root bone.

Hope this clarifies the question a bit.

3

Hey there,

So I’ll start by saying these issues are very tough to solve sometimes, so there might be some back-and-forth here as we figure things out. The other thing I’ll add is that as we approach holidays, the best engineers that might handle issues might be starting there travel and end of year family things, so there might be delays as we work through this.

There was an issue where the trajectory data generated from the pose history was feeding bad data back into the system in similar scenarios. We made a fix for 5.7, and I’d like to start by trying this one out.

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

Dustin

4

Hey there,

We did make a fix recently to address and issue that was similar in 5.7. Main CL: 44118738. And the git for reference:

https://github.com/EpicGames/UnrealEngine/commit/1713d720c0d579392954345f9fef2171676d0930

You could implement it and see if it addresses your issue.

Dustin

5

Hi Dustin,

Sure, I’m happy to wait for responses :slight_smile: I appreciate these are busy times.

Regarding trajectory, we’re not using Epic’s trajectory generation, we have our own version of it.

Let me know if I can clarify anything here as my original message was maybe not as clear as I would’ve liked.

Thanks!