Hi Shayan,

thank you very much for sharing your ideas. I've collected them in my "ideas for the future list".

Some kind of automatic key generation/animation record feature.

UMotion has an auto key feature that automatically creates key frames when you modify an animated porperty / a bone. To enable it, set "Auto Key" in the "Animation" section of the pose editor to "Generate". This feature does only record changes at the currently selected frame though (unlike the feature you requested, which should be able to record changes in real-time).

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

Best regards,
Peter

Hi Shayan,

thank you very much for your support request.

Yes humanoid is a lossy animation format, but for regular cases like a walking, idle, swimming,... animation the loss in precision shouldn't be very noticeable. If you're precision loss is very extreme, make sure that your humanoid character is setup correctly:

1. Select your character's 3D model file (in Unity's project window), open the "Rig" tab in the inspector and click the "Configure..." button.
2. The humanoid avatar editor opens.
3. Make sure that you've assigned all bones to the correct slots.
4. Also make sure that your character is in a T-Pose.
   

I also recommend that you do not have any scaling (that is not 1) on transforms (except the root) of your character.

Exporting to FBX (use write mode = "Update Existing File" to export directly into your character's FBX file) often also improves quality a bit.

If that doesn't help, please provide some further information about your specific situation.

PS: Also make sure that you are using the latest UMotion version from the asset store.

Best regards,
Peter

Hi Erik,

thank you very much for your support request.

#3 - Duplicate the animation clip asset and check the "Mirror" checkbox in the inspector.

That's the method I would recommend. Please note that this method not only swaps left/right keys, but also mirrors the spine.

Also, there are times when I want to not just copy in one direction (left-to-right or right-to-left), but also perform a swap on the same key. So the "Copy to the Other Side" feature would actually overwrite a key that I need for the swap.

Swapping is supported by "Copy to Other Side". Just select both bones (on left and right side) and perform the action. Using shortcuts usually makes it really fast to use "Copy to Other Side" on all keys of an animation. I did something similar in this video tutorial:

(See 10:05)

BTW, I really love UMotion. Thanks for making the great software.

Thank you very much for the nice words, that means a lot to me :-)

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

Best regards,
Peter

Hi,

thank you very much for your support request.

When switching the parent of a child-of constraint, 2 key frames are created. One with the position/rotation values relative to the new parent and exactly one frame before UMotion automatically creates position/rotation keys relative to the old parent. 

It's a bit hard to tell from the screenshot in which order the keys have been created, but it looks like the keys on frame 0 have been created relative to parent "A" but then the parent channel was keyed for parent "none" (on frame 0) thus the position/rotation keys  are in the wrong coordinate space?

Please check-out the official child-of video tutorial to learn how the child-of constraint works:

I thought IK Pinning might work but when I try that the Parent option isn't available anymore.

IK Pinning is an option of the child-of constraint and is used in conjunction with an IK handle (an IK constraint). This option is simply a replacing the arbitrary parent selection input field with a check box, where ticking the checkbox makes the IK handle relative to world-space. You do not need IK pinning in your case. More information can be found in this video tutorial: 

If after watching the child-of video tutorial, you still think that there is something wrong going on, would it be possible to record a video where you do the same steps as shown in the screenshots so that I can see exactly what's going on? That makes it easier for me to identify if this is a bug or not.

Thank you very much.

Best regards,
Peter

Hi,

thank you very much for your support request.

The blue bones are the "IK" bones and the "Grey" bones are the regular "FK" bones. As you have IK setup for your arms and legs, you have the regular "FK" bones for your arms and legs and the "IK" bones for your arms and legs. With the "FK/IK Blend" value (shown in the "channels" view when having the IK handle i.e. the wired cube selected) you can make the mesh follow either the FK bones or the IK bones.

Under the "Display" section of the pose editor, you can show hide the FK/IK bones.

The getting started video tutorial briefly covers this:

And the inverse kinematics video tutorial goes even more in-depth on this topic:

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

Best regards,

Peter

Hi,

thanks for reaching out.

I can delete your account for you if you want. Btw. you do not need an account to ask a question on this forum.

Best regards,
Peter

Hi,

thank you very much for your support request.

In order to remove an animation clip from the UMotion project, use the button highlighted below. It deletes the currently opened animation clip.

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

Best regards,
Peter

Hi,

thank you very much for your support request.

Ok so I see 2 things going on:

1. You're character is in a default humanoid "feutal" pose at the beginning. That happens for example when the animation you are playing is not compatible with that character (e.g. the animation you're animation controller state-machine is playing is "generic" but your character is "humanoid"). Check you're "Animator" window to see which animation is played in this situation. This is default Unity animation stuff and shouldn't be related to UMotion.
   
   It's normal that you're not possible to move your character by adjusting the position/rotation values in the inspector because the Unity Animator is driving those values.
   
   
2. The second issue (with the character getting offset while the running animation is played) might either be a result of a scripting problem in you're movement code or a result of wrong root motion settings (or both). You're running animation is an "in-place" animation (i.e. the animation itself does not move the character forward). You also need to tell Unity to treat it that way. Select the *.anim file of your running animation (that you've exported from UMotion). Then in the inspector window, set the tick-mark on every "Bake Into Pose" setting.
   
   Disabling "Apply Root Motion" in you're character's "Animator" component might also help (in case you're not using any other root motion animation).

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

Best regards,
Peter

Hi Max,

thanks for your support request.

As mentioned in my reply to your bug report, please update your UMotion version to the latest from the asset store. Not only does it most possibly solve the exception that you've experienced when using custom IK, it should also help with the timeline syncing.

Also make sure that your Unity timeline version is up-to-date (see Unity package manager).

Regarding the Unity timeline offset, there are several settings that affect how Unity timeline does offset your character. It depends on the exported animation clips root motion settings (i.e. if it uses the "Original" root motion authored in your animation clip or if it uses the "Center Of Mass" of your character). Then inside Unity timeline, it depends on the settings you have made for your animation track and the animation clip inside your track (e.g. the pos/rot offset values and if "remove start offset" is used or not).

Using "original" for all your root motion curves (of your exported animation clip) and disabling the "remove start offset" in the clip settings in Untiy Timeline might be a good starting point.

But when you want really precise interactions, I highly recommend using generic and animate both character's at the same time using a single "uber" animation clip. Despite being the simplest solution, it also comes with no quality trade-offs (as humanoid does).

Best regards,
Peter

OH MAN,

I just solved this! Out of some unknown reason the pickaxe gameobject was checked as static.

So, thanks a lot for bouncing this stupid issue back and forth.

Keep up your great work - your tool is absolutely awesome.