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

Hi,
thank you very much for your support request.

Afaik, there is no easy fix for this. I think I've also seen this in AAA games from time to time. Maybe advanced machine learning based techniques like motion matching can handle this in a better way. Anyway, usually this is a very minor/subtle problem and it might be better investing your time in a more visible/important feature of your game.

Here are some tips I've found related to this: https://forum.unity.com/threads/movement-animset-pro-controller-added.220742/page-3#post-2385517

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

Best regards,

Peter

Hi,

thank you very much for your support request.

This is just a false alert generated by Unity in some situations. It has no negative impact on the functionality of UMotion or Unity and you can safely ignore that.

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

Best regards,
Peter

Hi,
thank you very much for your support request.

It depends on the FBX import settings in blender. I tried a few things, and the best result I get was when exporting the animation with the character's mesh (you can do that by setting "Write Mode" to "Update Existing File" in UMotion's export settings, then select your character's source fbx file as destination file) and with the following import settings in blender (displayed on the lower left when browsing for the fbx file):

If you don't need the mesh, you can delete it after the import.

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

Best regards,
Peter

Hi,
thank you very much for your support request and thanks for the nice words.

Yes this is possible, just not enabled by default. Go into settings (click on the gear icon) and remove the tick from the "Chain Neighbour Keys" checkbox.

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

Best regards,

Peter

Hi Ivarsson,

thank you very much for your support request.

Export to FBX requires unique names for all bones/transforms in the hierarchy. When creating a new UMotion project for this character (with duplicate names), UMotion should warn you that this might cause issues when exporting to FBX.

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

Best regards,
Peter

Hi,
thank you very much for your support request.

A constraint dependency loop is a result of wrong placements of (IK) constraints in the hierarchy. Here a common example: If a hands IK handle (that also contains the IK constraint) is a child of the bones the IK constraint should calculate (in this case a child of the upper and/or lower arm bone) you get a dependency loop. The rotation of the arm bones are dependent on the IK handles position, but as the IK handle is also a child of the arm bones, the IK handles position itself is also dependent of the arm bones (as rotating the arm bones would alter the IK handles position).

To resolve this, open config mode and check all your IK constraints for this type of situations.

When you are using a humanoid UMotion project, and you are only setting up IK via the IK setup wizard (and do not alter the IK constraints manually or add constraints manually) you should never get a constraint dependency loop. If you do get a dependency loop in this case, this is considered to be a bug (please make a bug report in this case providing everything I need to reproduce your exact steps) via the email support form. Thank you very much.

Please let me know in case you need any further assistance.

PS: You wrote your UMotion Version is V1.22. The latest version is UMotion V1.22p14. I recommend updating just to cancel out the chance that you are experiencing any bugs that have already been solved.

Best regards,
Peter

Hi,

thank you very much for your bug report.

I was able to reproduce this issue and a fix is going to be shipped in UMotion V1.23. Thank you very much for reporting.

Here are some workarounds (copy & paste from my reply to your original email I've sent you in the meantime):

1) The issue is caused by an IK constraint in your UMotion project that has an empty (null) target object in it's settings. Go into config mode and remove that IK constraint (or assign something for the "Target" field).

2) Or you can simply disable the "Delete FK Keys" setting in the animation clip import dialog. You can then delete the FK Keys by hand afterwards.

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

Best regards,

Peter