Motion warping inconsistent results(bug?)

Not sure if I don’t understand something with the motion warping, but this seems like a bug.

These 3 actors are playing the exact same animation at the same time, using the same sync point. They are at different locations in the scene. 2 of them have the same rotation. The 3rd one has a different rotation. The end result is that the guy with rotation has inconsistent motion warping. He fails to hit the target, and ends up in a different location as well. This suggests that there is an aspect of the motion warping dealing with rotation that messes up the results you get from the motion warp action. The degree of error seems to be proportional to how much rotation correction needs to be performed. The 2 guys already aligned to the rotation of the target are superimposed on each other, but as soon as you start adjusting the initial rotation of any of them, they don’t hit their mark.

The expectation I think is that it doesn’t matter what the initial state of an actor is, motion warping hits a transform target by the time that warp window ends, and the remaining playback of that animation should basically be identical for these 3.

Am I missing something or is this a bug? @LDelayen

Hi JSwigart, are you getting the same result with all the warping types (root motion modifiers)? Looks like you are using Adjustment Blend Warp in this example. Have you tried Simple Warp or Skew Warp?

Great question I forgot to compare.

Simple warp does not have this issue.

  • Adjustment Blend warp misses the target based on the delta between the initial rotation and the sync rotation.
  • Skew warp, none of them hit the target. Not even sure what that is supposed to do. They all come up short and separated.
  • Scale warp is irrelevant I guess because it doesn’t use a target. I would assume it would scale the root motion by the provided scale values, but it doesn’t appear to do that either. Seems to have no effect on the root when I play with the scale values

Documentation is lacking for these differences currently.

Hi JSwigart,

Scale Warp is a very simple modifier. As you said, it just scales the root motion by the provided scale value. One detail to take into consideration is that there must be root motion in the original animation to be able to scale it or warp it.

Skew Warp it’s similar to Simple Warp in the sense that it also warps the root motion to ensure the character reaches the target at the end of the warping window. The difference between this one and Simple Warp is that it deals better with complex curves, like imagine a jump animation where we want to warp the whole arc of that jump from the take off to the landing. Skew Warp could be used here using a single warping window that goes from the take off to the landing and the algorithm will do his best to maintain the original arc in the animation. On the other side, if you want to warp the same motion but using simple warp it would require two warping windows, one from the take off to the apex (requiring you to manually calculate the target at that point, the apex of the jump) and a second window from there to the landing.

Adjustment Blend Warp is the most experimental of the three warp modifiers. It’s just a different method that we have been playing around with that allows us to warp not just the root trajectory but also the trajectory of other bones, like IK bones and this allows us to use IK to modify the pose while the warping is happening to reduce foot sliding. It also requires a bit of extra setup on the AnimGraph for IK, we will share more details about it once its in a more solid state.

If you can share a sample project where the issues you have encountered are reproducible I would be happy to take a look at it.



Hi @Fernando.Coello

Thanks for taking the time to reply. It’s been some time so I went back to a test I had set up when I initially observed this issue to see if anything has changed in the UE5 EA hotfix 2 branch. It appears that the problems are still there.

Here is a sample project. The sync target point is called “Plant” since it loses that field when you change the warp type. The level blueprint sets up the warps a couple seconds after you hit play.

Simplewarp appears to work as expected. Despite each guy starting from a different place and orientation, they hit the target and animate through, at the end they are basically superimposed on each other, as I would expect from a perfect warping.

Neither Adjustment Blend and Skew hit the target, and so they end in different places.

In the case of adjustment blend, the accuracy of hitting the target appears to be related to how far off the target rotation they are. The red box guy for instance is rotated differently than the sync transform for instance, while the other 2 green guys are already aligned. If you adjust the starting rotation, you will notice variable error. This leads me to think that the initial rotation error plays into the bug. Given the experimental nature of this I will ignore it for now, but I can’t imagine it’s working in a useful fashion at the moment, so might be worth a look.

The setup is 3 zombies, their starting color merely brings attention to which one(in red) is oriented differently than the sync position.

Here is the setup. Fairly basic, Ignore Z turned off. “Plant” is the sync point name

The result of this Blend warp is shown here, where the guy off by himself is the red box guy, and how much he is off will be dependent on his starting rotation.

Their height is also incorrect. The sync point is lower. I’m not sure why they move up this high.

Skew warp is the worst. They don’t even hit the target on the near side of the wall, much less animate through it properly.

Hopefully this helps track down some issues. Really excited for this feature and thanks again for your time.

P.S. It would be fantastic if switching root motion modifiers preserved shared named properties, like the sync point name. It’s very easy to miss that getting reset when you swap to experiment with different ones.

Hi @JSwigart sorry for the very late response. I just had a chance to take a quick look at this and was able to reproduce the bugs you mentioned.

For Adjustment Blend Warp, there seems to be a bug related to the rotation of the Ref Pose. I haven’t investigated further, but I noticed that in your project the character was imported with Y axis pointing downward and Z axis pointing forward (Pitch=0,Yaw=0,Roll=90). So I just did a quick test and re-imported those assets removing that rotation offset so Y points forward and Z points up and with that, Adjustment Blend Warp seems to work fine. That said, we should be able to deal with this case out of the box and the warping should work regardless of the rotation of the ref pose, so this is something that we will have to investigate further and try to fix.

I was also able to reproduce the bug using Skew Warp, and this one seems to be happening when there is a vertical offset between the root of the mesh and the bottom of the capsule. Same as before, this is something that should work out of the box, but in the meantime you can fix this by adjusting the relative location of the mesh component in your character blueprint to Z: -88 instead of -90 that way the root of the mesh will perfectly match the bottom of the capsule. Now, even by doing that you will get a bad result and this is because you are using Set Collision Enabled: No Collision to completely disable the collision with the capsule. For some reason this method creates and vertical offset between the capsule and the mesh comp that contributes to the warping not reaching the target. I’m not sure why this is happening, but in general I would not recommend to disable collision this way for warping, specially because this would prevent the CharMovementComp from moving the character along the floor when using Walking Mode (instead of Flying like in your example). For this case I would recommend to use Set Collision Response To All Channels: Ignore. By making those two changes Skew Warp should work in your example.

That said, as I mentioned before, this is something that should work regardless of whether there is a vertical offset between the mesh and the capsule so we will need to look into this.

Hope this helps. We will try to fix these two bugs as soon as possible. Keep in mind that you are completely fine using Simple Warp for a case like this. So, hopefully this doesn’t prevents you from using motion warping in your project.

Thank you for reporting this and sharing the test project. I will let you know as soon as we have a solution for these two bugs.


1 Like

Thanks again @Fernando.Coello