Humanoid -> Generic -> uMotion Root Motion Issue
Hi!
I'm attempting to convert some Humanoid animations to Generic animations which I'd like to then import into uMotion for editing. The conversion mostly works, however the root motion appears to be lost and/or incorrect in the final .anim file that is produced.
The input Humanoid out output Generic rigs both have root motion setup correctly and working. Root motion works in the inspector preview and within the game at runtime. After using Animation Converter to convert this Humanoid animation to Generic, the root motion no longer works correctly.
Here's a video of an example the the full process so you can see what is happening. Note that selecting "Loop Pose" makes the preview root motion appear to work - but once this is imported into uMotion, the root motion data is completely gone (see second video).
Is there something I'm missing here? How can I bring a converted Humanoid -> Generic animation with its original root motion into uMotion?
Answer
After some further investigation, I can manage to get root motion data into the uMotion imported animations but the process is slightly more complex.
- On the original animation (Humanoid):
- Set "Loop Time" disabled (even if the animation is a looping cycle!)
- "Motion/Root Motion Node" set to "<Root Transform>" (at least this worked for my animations, may be different for others - "<None>" never works)
- Use AnimationConverter to convert the animation from Humanoid -> Generic using the desired rig input/output
- Open the uMotion project with the generic rig:
- Import the converted animation
- Set RM on the hip bone position and rotation
- Set the clip to loop
- Export clip(s)
- Set RM node on exported FBX
After conversion with the Humanoid animation settings above, the resulting .anim *does not* have any root motion curves but the motion is baked into the animation. uMotion seems able to take this and convert it to RM once the RM transforms are set.
This is good to know and seems to be a work around for now. However it's quite tedious to have to switch of looping and set the root motion node manually on each animation. Is there a bug here? The humanoid animation knows it has RM and knows which node it is - is Animation Converter just not copying the information across correctly? Why do I have to disable Looping on the original animation?
Hi,
thank you very much for your support request.
Why don't you use the generic animation from "xbot_generic" directly in UMotion? For animations that are included in the original *.FBX, Unity converts them into the appropriate animation format automatically depending on the "Rig" settings. You just need to drag & drop the "xbot_generic" character into the import animation dialog in UMotion. Or was this just for demonstrating your actual problem?
Regarding your actual problem: Could you please send me a *.unitypackage including only your generic and humanoid version of your character so that I can reproduce this on my end? Select both in the project window, then click on "Assets --> Export Package". Uncheck the "include dependencies" if necessary. You can send the *.unitypackage to me via the email support form.
Thank you very much.
Best regards,
Peter
Thanks for the reply, Peter.
Yes, the above was just for demonstrating the problem with a simpler example. The actual use case is to remap animations from one rig to another, so it wouldn't be possible to load it directly into UMotion onto the target rig.
I've sent the a package via email support with the rigs and animations from the example above in them.
This problem is fixed in Animation Converter V1.03. Thanks for reporting.
Best regards,
Peter
I think I have the same problem where can we found the V1.03 please Peter ?
Regards
JB
You can send me an email with your invoice ID via the email support form so that I can send you the new version immediately. Otherwise you can get it on the asset store in the next one or two days (as soon as the asset store vetting team finished their review).
Best regards,
Peter
Customer support service by UserEcho
This problem is fixed in Animation Converter V1.03. Thanks for reporting.
Best regards,
Peter