Hi David,

thank you very much for your support request.

Please refer to the UMotion manual at "Clip Editor --> Import/Export". There is a nice table that compares the features each animation format supports. As you can see on the table, the FBX file format does not support animating Unity specific component properties (like the blend shape weights which are a sub property of Unity's renderer components).

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

Best regards,
Peter

Hi Peter,

Many thanks you for your kind offer of additional help.  I finally had time to get back to this project today, and I find that I am unable to recreate the problem.  This means that either I am unknowingly doing something different that's critical to getting it right, or the latest update of Unity has somehow had a positive impact on clearing up the problem.  If I find myself having this "problem" again, I will re-check this post for advice and ask for your kind help if needed.

Regards - Owen

Hi,
thank you very much for your support request.

This is very easy:

1. Create a new UMotion project for your sub machine gun. Usually you would just temporarily create an instance of your sub machine gun in your Unity scene. Then create a new "generic" UMotion project and drag & drop the sub machine gun (scene instance) into the pose editor's "Animated GameObject" field.
2. Import the animations you want to edit into UMotion ("File --> Import Clips"). You can either select the whole *.fbx and then use the ticks next to each animation clip to select which animation you want to import. You can also drag & drop separate animation clips from Unity's Project Window into UMotion's import window.
3. Edit the animation to your liking.
4. Open the settings by clicking on the gear icon. Change export type to FBX (binary or ascii is totally up to you). Set "Write Mode" to "Update Existing File". Then under "Destination File" select the "SubmachineGun_Animations.fbx" file.
5. Export your animations ("File --> Export --> ..."). The changes are automatically written into the *.fbx file.

Here are some related video tutorials for completeness:

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

Best regards,
Peter

Hi Kev,

thank you very much for reporting.

This seems to be a Unity bug in older releases of Unity 2020.2. Please update to the latest Unity 2020.2 release (I just verified that this issue does not appear in Unity 2020.2.6f1).

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

Best regards,
Peter

Hi,
thank you very much for your support request.

This is a common issue of the asset store/package manager (doesn't really relate to a specific asset). What you can do is to delete the affected asset (in this case UMotion) from the cache folder of the package manager: https://docs.unity3d.com/Manual/upm-cache.html

Then re-download the asset again, remove the existing "UMotionEditor" folder from your project and then install it again.

Let me know if you need any further assistance.

Best regards,
Peter

Hi,
thank you very much for your support request.

Unfortunately UMotion does not support motion paths. I've took a note on my "ideas for the future" list but can't promise anything as of right now.

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

Best regards,
Peter

Hi,

thank you very much for reaching out.

All methods that you described are feasible, it's probably more a thing you can decide based on your person preferences (and how it fits into the other systems you use in your game). A few things to consider:

1.  Re-parenting is usually faster than Instantiating/Destroying and also allocates less memory garbage. But as you're doing it at a very slow interval (only when the user clicks something), you won't notice the performance benefits.
2. If your objects store some internal states/variables, re-parenting might be easier (as all states are kept). If you switch between new instances, you might have to copy those states.
3. If the offset between the player and the object you want to interact with can be different due to player input, you might need a runtime IK solution to adjust your pre-made animation to reach the target object correctly. UMotion's IK is baked into the animation, so it can't serve you in this situation.
4. Make sure your animation is not directly referencing a picked up object that you are then removing (either because it is re-parented or because it is destroyed). This makes the animation point to a transform that doesn't exist anymore. You can instead use an empty GameObject as "anchor" transform that always exists. Parent picked-up objects to this anchor. Move the anchor in your animations, instead of the picked-up object.

Please let me know if there is anything else you want to know.

Best regards,
Peter

Hi Murat,

thank you very much for your support request.

Humanoid is an intermediate file format that stores the animation in "muscle space" which is a normalized space that can be applied to any other humanoid character (i.e. animation re-targeting). When UMotion exports your animation to humanoid, it needs to re-sample the animation to convert it into said muscle space. When importing the humanoid animation back into UMotion, the animation is then again re-sampled from muscle space into the authoring friendly local space of your character.

Re-sampling means that as the curves can't be translated 1:1, their shape has to be rebuilt by creating those additional key frames you see here.

So instead of importing back and forth, try to stay in regular local space and once you've finished your work, export once as humanoid. You can also export your animation as FBX (for humanoid, set "Write Mode" to "Update Existing File" and your character's FBX file as destination file!) and then in the FBX's inspector you can play with the animation compression settings to get the humanoid animation within the memory size budget you require (if build size is your concern).

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

Best regards,
Peter