Root motion rotation glitch

[Iremodder]

The Animation is fine UE4 and Blender. When Root motion is enabled in UE4 the animation 'glitches' around the same time near the end of animations. Only seems to occur with animations with rotation. Running animations are fine with root motion. A root bone is present after conversion.

I have attached the TPose and rolling animation for the: original files (.../Root Rotation glitch v1) Converted with root motion disabled (...\Root Rotation glitch v1\Converted (With rotation disabled)) Converted with root motion enabled (...\Root Rotation glitch v1\Converted (With rotation enabled))

Root Rotation glitch v1.zip

[gnuton]

Thanks for filing the issue. I have just checked the problem and I cannot see anything bad in this.. https://youtu.be/Y2P7rT6NUrg Am I missing anything?

[Iremodder]

HI gnuton, The Component Capsule of the character successfully moves. However, I tried a full implementation with root motion with a similar animation from mixamo, enabled 'Root Motion from Everything' but animation skipping still occurs and there is an unexpected change in direction during the start of the animation unfortunately.

[gnuton]

Switching off the the X/Y/Z Euler Rotation should fix this.. not sure yet if this will break other anims. https://youtu.be/1dcF6_awhOA How does this look to you?

[Iremodder]

Thanks for your patience gnuton, I have tried disabling x,y and z euler. It results in the same thing under Root motion in ue4 (only difference is the animation is now (unlike before disabling x/y/z euler) bugged in UE4 preview even when 'Process Root Motion' is enabled)

I set root motion to 'Root motion from everything' within the character's Anim Blueprint.

Am I missing a setting in UE4? Any clue why the preview is working fine (pre-euler edit) when 'process root motion' is enabled, but not in game within ue4?

[gnuton]

How have you disabled the euler rotations? actually only the z is the one which matters here. I m not sure about disabling them as in the video let the changes be reflected into the exported FBX. I may be wrong although. Could it be that the animals has not been exported correctly?

[gnuton]

@Iremodder there is a fix waiting for review. It looks fine to me, but it may break some anims. would you mind to try it out before merging? for me it seems fine. Please note the changes have not been merged yet and they are still in my personal repo. the new version is 1.0.9

[Iremodder]

@gnuton Thanks. The changes you made in your 1.09 version fixed the roll animation and 2 other animations I was trying to get root motion for. Cheers for the support gnuton.

Further testing: Seems your change's only minor negative effect is that the Z-axis (i.e. Jumps) doesn't work as in the non-root anims. Hence, an animated character body (from the pelvis/hip) will only go up/down in the z-axis slightly in contrast to the original animation. However, this could be just from the nature of root motion.

[gnuton]

I had a chat with @enziop and he pointed out that rotation on Z axis is actually needed when character moves on a curved trajectory. That makes sense. For this reason the previous commit as been closed since the solution is not valid.

Back to the problem: What the script does is to apply the rotation around Z of the hips to a plane. The plane location and rotation will affect the root node in unreal. So when this happens? the problem is in the way COPY_ROTATION constraint works when the hips bone goes upside down. Infact in this case the mesh spins backwards.

As for now I m not sure yet how to fix this using contraints

[Iremodder]

@ gnuton, cheers for the support throughout. On top of what you were saying, out of curiosity do you know why bones gets oddly rotated (and displaced) after conversion? It hasn't been an issue yet.

[gnuton]

@Iremodder I haven't really seen that yet. I just noticed there are some weight paiting errors in the mixamo models that fuck up the way the mesh bends close to some joints (eg knees and elbows). But if you stumble across the problem you just described, please feel free to open an issue for it.

[enziop]

@gnuton i have a candidate for the problem

1. the empty objects that are created for extracting the motion use Euler rotation instead of Quaternion, they should use quaternions to avoid weird rotation errors
2. when importing the rolling animation and looking at the quaternion rotation curve of the hip, there is one point where it changes sign, i had that causing problems in some mocap animation in the past and wrote a script to fix it, i will try to find it, or rewrite it and add in the right place in the conversion process

[gnuton]

Great. Waiting for your fix then!;)

[enziop]

quaternion fix is now pushed, it fixes some rotation glitches, but the root turning around weirdly in the QuickRollToRun animation is actually expected behaviour for the current technique, because the Hip bone actually does such a rotation around Z

for the future we need a feature where you can have a list with all source animations and somehow tag each animation how it should be converted, so one can disable features per animation most important: use Z (wanted when jumping, don't remember when its unwanted) (don't) Transfer Rotation (not yet implemented)

so this issue is only partially resolved and became a feature request

[enziop]

@gnuton some clarification: the plane has nothing to do with the root motion, the root motion is transfered to the Armature Object which when exporting to unreal is the root bone, the plane is just a dummy mesh which is skinned to the rig when there is no geometry, it prevents loss of the bindpose in the fbx when converting RigOnly animations if you select the armature in object mode and set the Manipulator coordinate space to Local at the bottom of the 3d view you can see that the armature already has that motion, the plane is just following it because it is skinned to it

[enziop]

one more thing to know: if you use root motion in unreal engine and want to preview it when having an animation open, you have to check in the viewport Show->Animation->ProcessRootMotion to display it right

looks right then even without quaternion fix, so this was not your problem @Iremodder the root bone does weird motion which it shouldnt do, but the resulting animation is still right

do you have an idea how one could prevent this in an algorithmic way without having to convert each animation with different settings?

this is the motion of the original hip, after doing Quaternion Cleanup (removing first small glitch)

[Iremodder]

Hi @enziop I can confirm a 1.08 conversed mixamo animation worked in preview only, "Am I missing a setting in UE4? Any clue why the preview is working fine (pre-euler edit) when 'process root motion' is enabled, but not in game within ue4?"

but as quoted a v1.08 converter conversion of the roll animation doesn't function in game as seen in preview mode when process root motion is enabled (and Root motion everything is set for default and is seen as having an effect in game).

It would always give the same in game result as if Process Root Motion isn't enabled in game (i.e. in 'non-preview'). Now whether I am missing some other aspect of UE4's in-game root motion, idk.

[enziop]

Sorry i overlooked the post does this happen when having a animation blueprint with only the QuickRollToRun animation or in a state Machine with blending? in a animation blueprint with only the roll animation it works for me (only tried with 1.0.9 now) i can imagine, that blending between animations after the roll from the point where the root is rotated oddly it might somehow keep the odd rotation and cause the character to face in a different direction after the roll i'll try to download some walk animations together with this roll forward and build a small state machine and blend tree to try it out

[enziop]

i tried a simple state machine with just a running forward animation and the rolling animation with a transition duration of 0.2sec and my worries were right, the character changes direction when transitioning out of the roll. so i will add a feature to disable rotation transfer for animations which should be straight, for the beginning if you want to batch convert animations you have to sort them in folders and convert them with different settings for animations which should be straight, animations which walk a curve and animations which should not use root motion at all (we have that in our project a lot which will continue in around a month)

[Iremodder]

@enziop

• For me the in-game animation is never the same as the 'process root motion' preview animation regardless of converter version, i.e. 1.0.7-1.0.9.

• 1.0.9 gave the best results (by far), aside from animations animations using the z-axis (such as run jumping and dropping off a ledge). For example, the roll animation comes out pretty prefect.

• These animations are in a state machine, and currently use no blending.

[enziop]

ok its weird, i built a simple character blueprint which allows me to walk forward and roll, if i let the character roll in the animation blueprint preview by just enabling the bool it changes direction after roll, if i roll it in game by setting the bool by blueprint it does not change direction after the roll i have no idea why there is a difference

[enziop]

in 1.1.0 there is now an option to not transfer rotation when converting animations if you want to batch convert many different animations you have to sort them into folders and convert each with different settings:

• animations where character goes around a curve (Transfer rotation = True)
• animations where character should go straight ((Transfer rotation = Fasle)
• animations where character climbs down and has an end position below ground (On Ground = False)

[Iremodder]

Hi @enziop Does this mean that converted animations like Run jumping are now fixed for root motion?

[enziop]

@Iremodder run jumping should have already worked before or are you talking about a specific animation which didn't work?

[Iremodder]

@enziop please see gif attached Its the same issue from before where in-game animations aren't the same as the preview with 'root motion enabled'.

Edit: As you can see in game my character doesn't jump near to the expected height. Is this an issue with the converter or just due to root motion?

just in case (due to gifs compression and clip length): In this video I am toggling between Root and Pelvis bones to show the difference in the leap, without and with root motion. Process Root motion was enabled, but the resulting in-game animtion doesn't reflect this.

The X-Y Based animations (like rolling, ground spin attacks etc) are coming out great.

[crossmr]

This is an old thread, I don't actually use this converter, but I wanted to comment on @Iremodder issue there. It seems that if you add a root bone to the mixamo animations and import them, they only import at 1/10th the scale on the XYZ location. I've been working on several animations that have the character actually jump high or out far, and this is an issue with most of them. Without root motion it seems to look fine, but when you enable root, they barely move. If you scale the XYZ location in blender on the Y axis by 10, they will appear normal. This can cause strange behaviour (which is how I found this thread). An animation which has a spin in it, like a sword slash I'm trying to get into UE4, goes crazy on the spin part of the move. I can't see any reason for it, since the scaling is only on location, not rotation. They need flying enabled on the model to translate the Z location of the animation with root motion as well.

[Iremodder]

@crossmr Unfortunately this issue has yet to be resolved.