Animation export makes a weird hand rotation flips on Animator Transitions

Hi,

thank you very much for your support request.

I need a few more information in order to being able to reproduce your exact same situation:

1. Are you using humanoid or generic?
2. Do you export your animation to *.fbx or to *.anim?
3. If possible, please create a small repo project that includes all your settings. Create an empty Unity project and add your character's FBX files to it. Then create a new UMotion project, import and export the animations and create an animator controller that blends the animations as you need it. Then *.zip the whole project and send it to. This ensures that I'm looking at your exact use-case with the exact same settings etc.
   You can also send the link to me in private if you want via the email support form.

Thank you very much.

Best regards,
Peter

Hi,

I exported to .anim and it is Humanoid.

I've sent you the project with repro via email support form.

Below is how you can see it creates this hand rotation bug only when its import/export via UMotion.

I've placed 2 example side by side where it works fine without UMotion and the other that has bug with UMotion.

The tool is the best one in the Unity market and it is such a huge impact on my project, I really hope this bug gets fixed. It does not just happen for this one but other animations too.

P.s, the email support takes a very long time to upload 10mb .zip project file so I've sent you a separate email with google drive link to the .zip file as well. Please check it out.

Hi Jae,

thank you very much for sending me the repo project. That made it a lot easier to look into your issue.

I've took a look and this is a bug of the Unity Animator in your version of Unity. In the attack animation, the right forearm is rotated around it's own axis for more than 360°. When the animator does the transition, instead of taking the shortest path it "unrolls" the forearm.

This problem also happens with your original animations, but on the original animation it happens when transitioning from the idle animation to the beginning of the attack animation. In the Umotion exported version, it happens when transitioning from attack to idle. The reason for this difference is that UMotion starts with the forearm being not rotated  (and ends up being rotated by more then 360°) and the original animation starts with the forearm being twisted and ends up being at 0°. Both are valid representations of the same data (and generate exactly the same result in regular cases), but in conjunction with this animator bug you see the 2 different behaviors.

(Unity 2019.4.1f1, original animations, transition from idle to attack)

Long story short: In Unity 2020.3, this animator bug is definitely fixed (both the original animations and the umotion exported animations are interpolating correctly). I haven't tried other Unity versions yet. I recommend that you are trying to update to the latest Unity 2019.4 version. If the problem is still present, update to Unity 2020.3.

(Unity 2020.3.4f1, UMotion exported animations)

Let me know in case you have any follow-up questions.

Best regards,
Peter

I think you are trying it on Unity 2019.4.1

You need to try it on Unity 2019.4.27f1.

Also, the problem does not occur when its transition from Attack to Idle. (Not from Idle to Attack)

That Attack to Idle hand rotation only occurs with the fbx export from UMotion.

I just opened the bug repro project in Unity 2020.3.16f1 LTS and exactly same bug happens only for the .anim that is exported from UMotion.

Original FBX

Attack -> Idle - no transition hand rotation

UMotion exported .anim

Attack -< Idle - transition causes weird hand rotation.

Hi Jae,

Also, the problem does not occur when its transition from Attack to Idle. (Not from Idle to Attack)

I'm sorry for not being clear about that. There are two ways to represent the twist of the right forehand in case of the attack animation. You can either have a curve that looks like this (this is the animation from the original fbx):

Or you can have a curve that looks like this (this is the UMotion exported *.anim) version:

The curves are in muscle space. A delta of 2 units in muscle space means 360° rotation in the case of the forearm twist in-out curve. Notice how the curve of the UMotion exported version is shifted by 4 units (i.e. shifted by 720°). If you look at both animations separately, you won't notice a difference in world space rotation.

The Unity animator is not dealing well when transitioning the hand from > 360° rotation to the idle animation that is < 360 as it does unwind the rotation of the hand during the transition. This is what you see when transitioning from the end of the attack (UMotion version) to the idle as the rotation of the forearm is at ~3 (= ~480° of spin).

When you would transition from idle to attack (using your original FBX animations), your attack animation is at ~-4 (= 720°) at this point so Unity would again unwind your hand.

Do you get what I mean?

I was not correct with thinking that this is a problem that is gone in Unity 2020.3. For some reason, when I copied the animations to Unity 2020.3 Unity shifted the right forearm curve of the UMotion exported attack animation by 720° so that it suddenly was represented in the same way as the original animation. That caused me to think that the Unity animator can now transition using the shortest path instead of unwinding the rotation. I'm sorry for that misunderstanding.

So as the Unity animator is not transitioning well when the forearm is rotated more than > 360°  the solution is simple: We need to fix the attack animation to never do a >360° spin on the forearm.

If you look at the source attack animation, you can see that in the beginning it does a > 360° rotation:

I've changed the attack fbx animation to generic to see if the problem really is the animation included in the FBX, or if Unity is introducing this rotation when converting the FBX animation to humanoid:

As you can see, the generic version does not have this issue. I think that the unnatural bending of the elbow might cause Unity's humanoid animation importer to introduce the weird 360° rotation. Maybe try to keep your joints within the "real life human capable limits", then the animation might translate correctly to the humanoid animation format. Or (and that might be the simplest solution) you just use your character configured as generic, that way the animation is played directly as it was authored.

I hope I was able to shed some light into this issue. Let me know if you have any questions.

Best regards,
Peter

Notice how the curve of the UMotion exported version is shifted by 4 units (i.e. shifted by 720°). If you look at both animations separately, you won't notice a difference in world space rotation.

Is there an option to have the same value as the original so it does not do that rotation in UMotion when exported?

If not, if I manually just move the curve to match the "forearm twist" row, would that just work?

I have this issue only with 4 animations that I've been working with UMotion so its not a lot to manually fix it. (it happens 1 out of 80 animation works somehow :) )

Humanoid -> Generic is not an easy option for me since I am not in an early stage of the game and there is a lot of other animation which works frame tightly since it is a real-time action game.

I don't want to risk all other stuff that is done to the game for this rotation issue.

Looking forward to hear the answer.

If not, if I manually just move the curve to match the "forearm twist" row, would that just work?

Yes, moving the forearm twist in-out curve down (using Unity's Animation window) would workaround your specific issue with the transition. A "cleaner" fix would be to ensure that your forearm never does a complete 360° spin within the whole "attack" animation

Currently the attack animation does a >360° spin at this position:

I've looked into your UMotion project and it turns out that at frame 8, your pole target (that defines the elbow direction) is at the wrong position:

Move the pole target to the correct position and re-export your animation. Then exported attack animation then stays within 360° and also transitions correctly.

Best regards,
Peter

Hi Peter,

I've manually "Shifted" the curve to find the best spot and now the weird rotation is gone.

For this bike attack/idle animation, as you mentioned, shifting Forearm Twist In-Out did the trick!

For other animations, it was Hand In-Out. Once I shifted into a more similar spot which Idle animation has its curves at. All seems to work fine now.

This is a great found for me because some animations that were exported from UMotion always have greater In-Out value which makes the additional turn during the transition even it looks the same in world-space.

I can just shift the In-Out curve if this occurs again.

However, the In-Out value getting stronger often happened only from the animations that were exported from UMotion. I can fix it manually since it does not happen a lot.

Btw, The pole position is whole another thing that has nothing to do with this transition rotation between looking the same animation. The issue that we are talking about is Attack -> Idle only!

Btw, The pole position is whole another thing that has nothing to do with this transition rotation between looking the same animation. The issue that we are talking about is Attack -> Idle only!

It is the reason why the "Forearm twist In-Out" of the attack animation gets out of range (> 360°) and thus doesn't transition to idle correctly. On frame 8 of your animation within UMotion, you're doing a > 360° spin on the elbow. Once you get rid of this (by correcting the pole position), the curve stays in range (see screenshot) thus is also transitioning correctly to idle:

In other words, if you're animations produce curves that go beyond 360°, make sure that your animation in UMotion does not have "unrealistic/not human capable" poses.

For other animations, it was Hand In-Out

In that case, check that your animation in UMotion does not do any unrealistic rotations on the hand. Always stay within the human capable limits, then your animation should generate curves that stay within range that also interpolate correctly.

I hope this makes sense to you.

Best regards,
Peter

I see, I guess I have 2 solid solutions for it and the latter one that you've explained seems like a more cleaner solution.

UMotion has been super helpful for my project so far.

Thanks again for creating such a wonderful plugin.

Thanks for the nice words, I'm glad I was able to help.

Enjoy your time using UMotion and let me know in case you have any other issue in the future. I'm always happy to help.

PS: Please update your satisfaction mark, if this thread solved your issue.

Best regards,
Peter