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

Hi,
thank you very much for your support request.

Please check out the following video tutorial regarding pose mirroring:

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

Best regards,
Peter