Hi Nory,

thank you very much for your support request.

The problem you are seeing here isn't really related to UMotion, but to how the humanoid animation system itself works. The humanoid animation system is an animation re-targeting system. When Unity imports an FBX file configured as humanoid, it converts the actual authored animation into a "normalized" format that can then be played by the humanoid animation system on any other humanoid character even if the animation wasn't made specifically for that character. The system is designed to make animations look similar to the original authored animation, but they won't be precisely the same.

Hands being at wrong relative positions is one such problem humanoid can introduce. In order to compensate that error, humanoid has an internal corrective IK pass implemented that can correct wrong hand and foot positions. It's just not enabled by default (but you can preview it's effect when previewing the animation in the inspector window by enabling the IK toggle button).

More information about humanoid: https://blog.unity.com/technology/mecanim-humanoids

This blog post also covers the issue you are seeing with your hands at headline ("IK Solver").

In order to enable the corrective IK pass at you're game's runtime, you need to use scripting (only the foot IK pass can be enabled via Unity's animator UI). You can use this script (make sure to have "IK Pass" enabled in your Animator window):

using UnityEngine;
using UnityEditor;
using System.Collections;

    public class AnimatorHumanoidIK : MonoBehaviour
    {
        //********************************************************************************
        // Public Properties
        //********************************************************************************

        [Header("In order to use this, enable \"IK Pass\" in your Animator Controller!")]
        [Space(15)]
        public bool EnableFootIK = true;
        public bool EnableHandIK = true;

        //********************************************************************************
        // Private Properties
        //********************************************************************************
        
        //----------------------
        // Inspector
        //----------------------
        
        //----------------------
        // Internal
        //----------------------
        private Animator animator = null;

        //********************************************************************************
        // Public Methods
        //********************************************************************************

        //********************************************************************************
        // Private Methods
        //********************************************************************************

        private void OnAnimatorIK(int layerIndex)
        {
            if (animator == null)
            {
                animator = GetComponent<animator>();
            }

            float footIKWeight = EnableFootIK ? 1 : 0;
            float handIKWeight = EnableHandIK ? 1 : 0;

            animator.SetIKPositionWeight(AvatarIKGoal.LeftFoot, footIKWeight);
            animator.SetIKPositionWeight(AvatarIKGoal.RightFoot, footIKWeight);
            animator.SetIKRotationWeight(AvatarIKGoal.LeftFoot, footIKWeight);
            animator.SetIKRotationWeight(AvatarIKGoal.RightFoot, footIKWeight);

            animator.SetIKPositionWeight(AvatarIKGoal.LeftHand, handIKWeight);
            animator.SetIKPositionWeight(AvatarIKGoal.RightHand, handIKWeight);
            animator.SetIKRotationWeight(AvatarIKGoal.LeftHand, handIKWeight);
            animator.SetIKRotationWeight(AvatarIKGoal.RightHand, handIKWeight);
        }
    }

----

If you do not plan to share your animation across multiple characters, I would highly recommend using "generic" instead. "Generic" is true "what you see is what you get" as the generic animation system plays the authored animation 1:1.

-----

My suspicion is that the culprit is most likely found in some interaction between IK and the root of the object being rotated, but I haven't been able to pinpoint it, so far.

Please note that the exported animation does not contain any custom IK code. The effect of UMotion's IK solver is completely baked into the final animation. Once exported, UMotion does not execute any IK code anymore. In order to preview what UMotion exported into your *.FBX file, you need to preview it as generic. Only generic shows you the actual authored animation. When configured as humanoid, Unity converts the actual animation of the FBX into it's humanoid format which can introduce imperfections like the ones you are seeing.

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

Best regards,
Peter

It works when Twist Bones are set to none, UMotion does not add twist bones itself?

That makes sense.

UMotion is not altering you're bone hierarchy. If you do not have twist bones in your character's hierarchy but want some, you need to add them in your 3D modelling application of choice.

Having wrong twist bone settings in the ik wizard explains why you get into a dependency loop. UMotion assumes that your arm's/leg's bone chains are longer than they really are. As a result the IK targets are placed at a wrong positions in the bone hierarchy which results in being dependent on each other --> loop.

Btw. you can click on the black "info" buttons (spread across the entire UMotion UI) to jump right to the related page in the UMotion manual. Stuff like how the "Twist Bones" setting exactly works is explained there: https://www.soxware.com/umotion-manual/IKSetupWizard.html#HumanIK

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

Best regards,
Peter

Hi Adrian,

thank you very much for your improvement suggestion.

I've noted your idea on my internal "ideas for the future" list. This list is used when considering which new features to ship in new updates.

Best regards,
Peter

Hi Dave,
thank you very much for your input and also thanks for your nice words. I'm glad you enjoy working with UMotion.

The problem I see with this feature is when people new to UMotion accidentally use it and then get confused why the pose doesn't update while scrubbing. Maybe a different but similar affective feature would be copy/paste buttons in the pose editor. What do you think?

Best regards,
Peter

Hi Dave,
thank you very much for your support request.

IK pinning changes the coordinate system of your keys (from one local space to another local space). When looking at position/rotation curves, you see these jumps where it switches between different coordinate spaces.

Under the hood, IK pinning is just a simplified mode of the child-of constraint. You always need to keep in your head that changing the parenting affects your keys (existing keys need to be converted into the new coordinate space etc.). More information can be found in the related manual page (headline "Dealing with spaces") and in the following video tutorial:

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

Best regards,
Peter

Hi,
thank you very much for providing feedback. Much appreciated.

You can assign a custom shortcut to your preferred export option to avoid accidentally clicking the wrong option. Shortcuts can be assigned by clicking on "Edit --> Preferences" in the clip editor.

Best regards,
Peter

Hi Dave,

thank you very much for sharing your idea.

This is more or less already possible, but you need to work directly on the animation data (not via the humanoid format as humanoid always requires re-sampling on import/export which is introducing keys for each frame again).

1. Decide on a character you want to use to do your mocap clean-up.
2. Convert your mocap animation to generic (for that character):
   a) Configure your character and mocap anim as humanoid.
   b) Create a humanoid UMotion project for that character and import the animation.
   c) Export the animation into your character's *.FBX file.
   d) Configure your character as generic.
3. In the animation tab of your character's FBX settings you now have exactly those options you described in your idea.
   
   
4. Create a new UMotion project of type generic and edit your animation. You are now working directly on the animation data (due to the use of generic), no re-sampling required when importing or exporting the animation. Data-wise, this is equal to editing the mocap animation in motion builder, maya or similar.

With humanoid, you do not have the level of control over the animation's data that would be needed.

PS: Step 1 and 2 are not necessary if your mocap animations can already be used as generic because they where all exported using the same standard character model (by your mocap software).

Hope this makes sense to you. Please let me know in case you have any follow-up questions.

Best regards,
Peter