Humanoid > Generic root motion rotation incorrect

Hi John,

thank you very much for your support request.

This might be a bug. In order for me to identify the exact issue, may I ask you to send me all the files I need to reproduce the exact same conversion that you performed (i.e. the source animation, the character,...)? You can send the files to me via the email support form (if file size is > 20MB, you can request a link to my dropbox via said form).

Thank you very much.

Best regards,
Peter

Sure, np.  Thank you Peter.

The bug reporter is hanging on submission.. not sure if you got it or not.  I sent an email to info at soxware.com instead.  

Strange, I just tried to send something via the email support form and it worked for me. Maybe the uploaded file was too large?

Anyway, I received the email you've sent to me directly. Thank you very much, I'm looking into it (might take till Monday, as there are still some other requests I have to process today, thanks for your patience).

Best regards,
Peter

Hi Peter, I am going to try to dig into this more, I don't understand the difference yet or why there is a root rotation vs the red arrow which apparently means the direction Mecanim thinks the character is facing.  I just know it is breaking the move logic at runtime... :)  

Do you have any suggestions on how to get the red arrow to match like in the source animations?

I've tried copying the data from RootT, RootQ curves in the original animation to the newly generated one but that didn't help.  Continuing to research :)  

Oh, also I wasn't clear.  I actually have rootmotion disabled on the animator for this animation.  The problem is the animation is not facing the correct way compared to the original.  I confused rootmotion with animation orientation.

I'm not 100% sure what the red arrow means in the context of a generic animation. In the context of humanoid, it describes where the humanoid animation re-targeting algorithm thinks your character is facing towards. The algorithm generates this based on the average body orientation (and the position based on the character's center of mass). Source: https://blog.unity.com/technology/mecanim-humanoids (headline "Root Motion")

As a generic animation can be just anything (even a can of coke), I'm not sure if the red arrow has any meaning as there might not be a distinctive "forward" for the object being animated. But I honestly

If you're character is facing in the wrong direction, you might want to try to apply a rotation offset (in the inspector of the clip). If you're not using the root motion system, enabling "bake into pose" might also make sense (depends on how you've implemented your character controller).

Hope that helps.

Best regards,
Peter

Hi, I've returned to this. This approach allows me to work around animations that do not require root motion but its a hack and does not work for animations that do require root motion that have baked incorrectly.  I have to ask, is it possible to get the source code of the conversion?  I've fixed a similar problem pretty easily with a different plugin.  Without the source I either have to either painstakingly fix each animation by hand (no thanks, there are a lot) or be forced to recreate the conversion script.

I was previewing the animation incorrectly.  Here is the correct way to preview the animation.  It shows exactly what happens in game (motion and visuals unsynced).  I can't understand how this is not a bug.

I have more info for you to help explain the issue.  This animation's originally has motion set to the root in the fbx import.  This does not play nice with the conversion resulting in the video above.  Setting this to none will get the motion and visuals to match but it causes another issue.  The rotation of the visual is different than the original.  Adding an offset does not help because that offsets both the visual and the motion.  Take a look at the starting frames of the original compared to the converted.

Original, visual is facing forward:

Converted, visual is rotated 90 degrees from forward:

One more note.  The orientation problem can be adjusted by manipulating the source animation offset.  The original problem remains though.  Without support of using the authored root motion node, the generated animation's root motion is different  and lose the correct timing/motion.  

With this animation for example I did the following:

- set root motion node to none, allows animation and visual to move together (but does not match original's root motion rotation speed or orientation)

- manipulated rotational offset of original animation to match original look (face roughly right direction now, super tedious to do)

The results of this are still not perfect.  It is important for the authored root motion rotation to be unchanged.  Otherwise this animation rotates too slow and the character's foot isn't aligned with the movement direction when turning. Anyway, would really appreciate if support for using root motion node could be added or if source could be provided to see if I can work around this issue.  

Ok I might have overcome most of the issues.  I think the problem with my approach described above was the baked animation includes the original offset in the animation (good) but it also keeps applying the offset data to the newly created animations params (bad, doublely offset).  For example, if a source animation is rotated 180 degrees so that it faces forward, the destination will bake this correctly so that the offset is not needed, but the 180 degree offset is still applied causing the wrong rotation to be used.  Anyway,  I think definitely some improvements can be made.  This process was very tedious and time consuming (especially matching the original rotation offsets). I will test with the rest of the animations.

PS. The animation motion timing problem still exists (originals still look better) but at least the rotation is finally correct.

I had to write my own baker.  It now works correctly for all animations (ones with root node set on import) without any fussing with animation settings or losing the original authored root motion.  My guess is you have a bug with world space rotation breaking animations with hand authored root motion.  Maybe not clearing out the previous animations position/rotation on the animator as I saw that when I wrote my version.

Anyway, I have to say, I am pretty disappointed the source for the baking wasn't included. I assumed it was when included when I read on the store that it was extendable and full source was included.  Who needs just the source of the window?  This would have been probably an hour to fix rather than days.

Hi John,

sorry for the late reply, I'm not in the office on weekends :-)

Glad to hear that you've found a way to workaround the problem. If you still want the source of the converter, please feel free to send me an email with your invoice ID (you can use the email support form for that).

Best regards,
Peter