Answered

Foot IK Behaviour in uMotion

Adunato 2 weeks ago updated 1 week ago 4

Hi,

I'm trying to understand the differences between the way uMotion manages animations in relation to feet position and the vanilla Unity system. This question is not specifically about uMotion IK system, but rather a more general point including root motion and unity "foot IK" setting. Apologies as I'm sure this behaviour is explained somewhere in the video tutorials, but I can't quite link this to any of the features explained there.

From the comparison I have made below, it seems that uMotion adds a "foot IK" of sorts in the exported animation even when the IK constraints have not been created in uMotion. I say "of sorts" because the behaviour is slightly different:

- #2: feet are "pinned" (despite no IK in either uMotion or Animator state) but the left thigh make a jerky rotaion movement

- #3: feet are floating (as expected as no "foot IK" is selected in Animator state)

- #4: feet are pinned (as "foot IK" in animator state is selected) with a smooth thigh rotation

    The basic problem here is that uMotion produces a jerky rotation of the thigh in the exported animation that is not present in the uMotion editor animation. But in addition to trying to resolve this issue, I would also like to understand how uMotion manages the addition of a "foot IK" behaviour in the vanilla setting export.

    #1 - Animation in uMotion editor

    #2 - Exported in-game animation




    #3 - Original animation without Foot IK

    #4 - Original animation with Foot IK

    Settings


    Character settings

    Animator state settings (note: foot IK is enabled in the 4th sample above)

    uMotion Settings

    UMotion Version:
    1.25p01
    Unity Version:
    2020.3.2f1
    GOOD, I'M SATISFIED

    Fantasic support :-)

    Satisfaction mark by Adunato 1 week ago
    Answered

    Hi,

    thank you very much for your support request.

    The humanoid foot/hand IK feature is a core feature of the humanoid animation system. It was implemented by Unity to reduce errors (like foot sliding or hands not reaching to desired positions) introduced by the humaniod animation re-targeting algorithm due to different bone lengths / body part proportions between characters. It has nothing to do with using IK in UMotion or in an external 3D modeling application. When you import an animation into Unity, Unity is automatically creating the Foot IK/Hand IK curves for you. These IK curves are solely driven by the hands/feet position found in the original animation. Thus UMotion also automatically adds those curves to your exported humanoid animations.

    I highly recommend reading this blog post, it gives you a good insight into how the humanoid animation system works. It also covers the foot/hand IK stuff: https://blog.unity.com/technology/mecanim-humanoids


    Your video number 4 shows that your animation was exported correctly by UMotion. Due to the animation being played on the original character you created the animation for, it gives you the best playback result. When playing the same animation on a different character, the quality of the animation is going to suffer depending on how close the proportions of this character match the original one. Animation re-targeting (i.e. transferring an animation from one character to another) is always introducing some sort of quality loss and trade-offs. What you are seeing here is somewhat expected.

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

    Best regards,
    Peter

    Hi Peter,

    Many thanks for taking the time to answer my question, I did come across the article you mention but I appreciate the wider context you have provided in your response.

    With regard to my issue, there's a misunderstanding in your answer. Video #4 is based on the original animation not processed by uMotion. 

    • Video #1 is the uMotion animation in the editor (playing correctly)
    • Video #2 is the uMotion exported animation (with artefact)

    So I do have an issue with the uMotion export and will need some guidance on solution as it's well beyond the simple difference between character models, in fact the same artefact can be observed in both Kyle and woman character.


    All the best.

    Video #4 is based on the original animation not processed by uMotion.

    Ah ok thanks for clearing this up. Sorry for the confusion.


    What character rig was the original animation created with? Let's say the original animation was created for character A and you edit it on character B (that would be the female character) using UMotion, then export it and then using it on character C (robot kyle) this is going to introduce more and more errors. Because first you have the re-targeting algorithm that converts from character A to character B (this happens on import in UMotion) which introduces errors. Then at runtime, you get additional re-targeting errors when played on character C (re-targeting is now from B to C). And if B and C are further apart than A and C in terms of body proportions, you get worse results.


    This would be the most lossless way to work with a humanoid animation:

    1.  Duplicate the original animation (FBX) and switch it to generic.
    2. Create a new UMotion project of type generic and assign the character which was used to create the animation (also configured as generic) to the pose editor.
    3. Import the animation and make your changes.
    4. Use the FBX export (in Update Existing File mode) and write your changes into the humanoid animation FBX file (this ensures that you are using the correct humanoid configuration; you could also export into your generic FBX but then you would need to restore the humanoid avatar settings which might introduce new sources of problems).

    This is the most lossless way as you never have a re-targeting step involved. That's also how humanoid is intended to be used by Unity, as a conversion step once you finished all your work.


    If you still do want to edit the humanoid animation directly, you might want to try to export your modified animation as FBX (using the "Update Existing File" write mode). Export directly into your humanoid character which you used to edit your animation. This often creates better results then the direct *.anim export.

    Let me know how that works for you.


    Best regards,
    Peter

    Hi Peter,

    Thanks for the great depth in your answer, I have to say I'm really impressed.

    You are correct, the animation was created using the default character in mixamo and then edited in the female character.

    I'll try the techniques you mention in your answer and see how I can minimize lossy transformations.

    Many thanks again for your support.

    All the best.