Hi,

thank you very much for your support request.

The transform paths in the animation clip always need to be relative to the animator (or animation for legacy) component that plays the animation. As the animator component is in your Armature game object, UMotion is also going to make the transform paths relative to the "Armature" game object. If you want your animation to be relative to the root game object, then make sure that you assign the Animator component to that transform.

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

Best regards,
Peter

Hi Carl,

thank you very much for your nice words. That means a lot to me.

I'm looking for options to animate a character interacting and prop, where the prop is situated in world space and isn't a child of the character. One example is a lever. Is this possible?

Animation clips can only reference bones/transforms/object that are a child of the Animator component. The correct approach for your situation depends on what you are trying to create. If you want to create a cut-scene, you can use Unity Timeline to animate both the lever and the character. UMotion's "Sync" button can be used to preview both animations in sync (while editing one animation). For more information, please checkout the chapter "Unity Timeline Integration" in the UMotion manual.

If this is an in-game situation, where the player walks to the lever and then presses a button to actuate the lever, then the problem gets trickier. I would use a runtime IK solution to first blend the hand to the lever (then keep it parented to the lever). Next play an "actuate" animation on the lever, this is automatically moves the hand with it as it is parented to it. Then after the animation was finished, blend the hand back to it's regular animation state. Using a regular animation clip instead of runtime scripting/runtime IK would require that your character is at the exact same position/orientation relative to the lever in-game as it was while authoring the animation.

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

Best regards,

Peter

Hi,
thank you very much for your support request.

Blender might be modifying the bones on import or export thus the new character is not compatible anymore with the original prefab anymore. I would recommend that you try and play with Blender's FBX import/export settings, use a 3D modeling application with better FBX support like 3DS Max or Maya (LT) or just life with it and create a new prefab for the new character.

Please let me know in case there is anything I can help you with.

Best regards,
Peter

Hi,
thank you very much for your support request.

Here is my workflow:

1. Under "Animation" (pose editor) set "Auto Key" to "Generate".
   
2. Go to the first key frame of your left leg bones.
3. Select the left leg bones.
4. Use the "Copy to Other Side" button (pose editor --> tools) to copy the left leg bones animation to the right.
5. Move to the next key frame of your left leg bones and repeat step 4.
6. Then you need to offset the keys of your right leg bones by the half duration of your run cycle.

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

Best regards,
Peter

Hi,
thank you very much for your support request.

Yes you are correct, generic is the way to go. The only real reason to ever use humanoid is when you want to use animation re-targeting (i.e. create an animation for humanoid character A but use it on other humanoid characters B, C, D...). More information about what makes humanoid special can be found in this blog post: https://blogs.unity3d.com/2014/05/26/mecanim-humanoids/

I might add further bones down the line to make the object more lifelike (such as moving certain parts of it in a cartoonish matter) and increase complexity but I want a good foundation so any animation I will create doesn't get messed up.

I highly recommend to add all bones that you need (or might need) before you start doing your animations and do not modify the skeleton afterwards. It's hard to re-use existing animations on a modified skeleton.

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

Best regards,
Peter

Hi Asyl,

thank you very much for your support request.

Yes you can animate generic bones for humanoid models as long as they are a child of the "hips" bone of your character (that's what the error message is trying to say). The sentence in the manual is not correct, I have updated that paragraph shipping with the next patch release. Thank you very much for pointing that out.

Please note that generic bones are invisible by default in humanoid projects. You can make them visible by switching into config mode. Select the generic bone and under "Properties" set "Visibility" to "Show".

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

Best regards,

Peter

Hi Asyl,

thank you very much for your support request.

Generic animation clips only work for the generic character they have originally been created for. You can not use a generic animation created for character A on character B. Simply renaming the hierarchy won't help (it would satisfy the error message you get, but the imported animation would be trash). Only Unity's humanoid animation system is capable of animation re-targeting (i.e. trying to match an animation created for character A on character B). More information about animation re-targeting and why it is necessary can be found in this blog post: https://blogs.unity3d.com/2014/05/26/mecanim-humanoids/

If you get this error message even though the animation you've imported was created for the exact same character, then make sure that you have not altered the hierarchy of your character. The animation clip references all bones/transforms using a so called transform path relative from the animator component (e.g. "Hips_01/Spine_01/Spine_02/Shoulder_R" <-- would reference a bone named "Shoulder_R"). So beginning with the animator component, there must not be any extra transforms or transforms that have been renamed or moved in the hierarchy.

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

Best regards,
Peter

Hi Jim,

thank you very much for your support request.

Just assign a child-of constraint to the IK handle that you want to parent to the baseball bat.

In case you used the IK Setup Wizard to setup your IK constraints, a child-of constraint is already assigned to the IK handles (used for IK pinning). Just disable the IK pinning mode (go into config mode --> select the IK handle --> open the constraints tab --> scroll to the child-of constraint --> disable the check mark for the IK pinning mode).

With a child-of constraint, you can change the parenting during your animation. You can also parent the IK handle to the baseball bat directly in config mode via the "Parent" field in the "Properties" tab (this changes the hierarchy and is thus applied for the whole UMotion project).

For more information regarding the child-of constraint, please checkout the following video tutorials:

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

Best regards,

Peter

Hi,

thank you very much for your support request.

The child-of constraint calculates the position/rotation of the object as if it would have changed the parent, but in reality it does not change the parent. So what you get is a curve that is still in local space of the original parent. If you now export your animation, and the final animation is played a little bit different than the original (for humanoid, there are several reasons why this can happen like bad humanoid avatar setup, wrong root motion settings,...) then the offset doesn't match anymore.

An easy fix is to use generic, as it plays the animation "as it is". No humanoid "black magic" involved. It's less complicated then humanoid (in usage) and has better performance (due to no animation re-targeting) and better quality (humanoid's animation re-targeting is a lossy process that is always sacrificing quality a bit). The only benefit of humanoid is it's ability to use the same animation across different (humanoid) characters (which won't work anyway when you are using the child-of constraint). You can convert your animations to generic by creating a new UMotion project of type generic and import the humanoid project. That's what I would strongly recommend.

More information on humanoid: https://blogs.unity3d.com/2014/05/26/mecanim-humanoids/

Head is still static though.

There might be an issue with your humanoid setup. Check the humanoid configuration (rig tab of the inspector of your source model). Check that all bones are displayed in green. Changing the humanoid setup might require an update of your UMotion project (i.e. create a new humanoid project, assign the new character and then import the old project to keep all the animations you've made).

Another thing you can check: Select the exported *.anim and check the preview window in the inspector (it uses unity's default humanoid character as preview). Does the head preview correctly?

Best regards,
Peter

Hi Netpost,

thank you very much for your support request.

Your approach is correct. In order to advance the root motion between the loop-seams, open the curve of the root motion driving animated position property. Then select all keys of the second loop and adjust their vertical position so that you get a continuous curve/motion.

In case you are also using a root rotation (that doesn't come back to it's initial rotation when the loop ends), I recommend changing the rotation mode of that rotation property to "euler rotation" (related video tutorial). Then you can do the same editing with the curves as you've just done with the root position curve.

Thanks for suggesting this automated workflow. Currently the playback settings in UMotion are only responsible for previewing the animation, but have no impact on the exported animation. That's also how it is communicated in the video tutorials and documentation. The behavior you suggested would be a breaking change (as the playback settings would suddenly have an impact on the output), I have to carefully think about if this has any negative side-effects. Anyway, as mentioned above, this automatic workflow would just save you a few seconds as adjusting the curves should be rather easy.

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

Best regards,
Peter