Unfortunately the way how SkeletonMecanim applies animations is different from what AnimationState does in SkeletonAnimation.

If you see the last animation being applied without end, you have disabled Advanced Auto Reset in the SkeletonMecanim Inspector:

Auto Reset. When set to true, the skeleton state is mixed out to setup pose when an animation finishes, according to the animation's keyed items. This may be especially important when an animation has changed attachment visibility state: when mixed out, attachment visibility will change back to setup pose state, otherwise current attachment state is held until another animation has a key set at the respective attachment timeline.

If you see the animation ending, but the ending is too quick (an immediate cut), then you are encountering the following limitation of SkeletonMecanim:

From the documentation here:

Required Additional Keys
To smoothly mix out a timeline state (e.g. bone rotation) from one animation to the next, the second animation requires an additional key at the first frame when in setup pose. Otherwise the previous animation would leave a leftover timeline state. This is one of the drawbacks of SkeletonMecanim compared to SkeletonAnimation.

So in order to mix out your animation, the following animation needs a key at the same timelines as the animation to be mixed out.

XiaoFan a écrit

How to add additional keys 。

In the Spine Editor, you need to create an animation (the "empty" or "mix-out" animation) that keys the same bones as your to-be-mixed-out animation (in this case, as the shoot animation). Basically you need any other animation playing that keys the bones again, otherwise the previous animation's state will not be overwritten by anything and left as-is.

Unfortunately these limitations are cumbersome, which is why we recommend to use SkeletonAnimation instead of SkeletonMecanim if possible. Another solution would be to use a Mecanim-wrapper workflow as shown in the example scene Spine Examples/Other Examples/StateMachine SkeletonAnimation/Mecanim Logic SkeletonAnimation View.

I'm sorry to hear that you're facing troubles again. Unfortunately there is no direct equivalent to a Blend Tree node available in the Spine API (and thus in AnimationState), so I'm afraid to say that using a Blend Tree node with the Mecanim Logic SkeletonAnimation View example setup is not supported.

If you need Blend Tree state nodes as well, you unfortunately have to use SkeletonMecanim. In order to smoothly mix-out an overlay layer 1 animation (e.g. gun-grab), you can then either:

• a) Create a mix-out animation at your skeleton in the Spine Editor which keys the same bones as the to-be-mixed-out (gun-grab) animation on layer 1 (e.g. gun-holster which reverses any changes made by the gun-grab animation).

• b) Key the same bones on your base layer animations (e.g. at your walk animation key the arm bones) and transition the layer 1 (gun-grab) animation to an empty animation. So that when the layer 1 (gun-grab) animation ends and transitions to an empty animation, the base layer animation (walk-arms-keyed) applies its keys and does not leave any leftover state of the layer 1 (gun-grab) animation. Due to behaviour of the Unity Mecanim API, you need to create an empty animation in the Spine editor (a new animation without any keys) and assign it at your empty state, because unfortunately a state with a blank Motion property (None) leads to the clip weight always being 1 of the previous state.

Please let us know if anything of the above setup remains unclear. We are sorry that this is a bit complicated. :wounded:

Yes, you are absolutely right about that, it would definitely make sense to support something similar to a blend tree node at the AnimationState API. Currently changing blend weights back and forth (using e.g. a speed parameter) at simultaneously played animations would require having the simultaneous animations on multiple tracks, and changing the TrackEntry alpha values accordingly. While this is technically possible, admittedly it's more of a workaround and not comfortable to use that way.