Different behaviour with rotated element (left and right)
Grelle Thank you for sending us the Unity package! I was able to reproduce the problem you describe when I entered a value like -0.2 for f_plug in the parameters tab of the Animator window and set b_plug to True (I also confirmed that setting f_plug to -1 did not reproduce the problem).
We will investigate the cause of the problem and let you know what we find.
@Grelle Sorry for the late reply! The problem lies in the difference between Unity clip weights and Spine animation weights. Unity provides absolute weights of the form result = A*w1 + B*w2 + C*w3 where the sum of all weights w1 + w2 + w3 == 1. Spine animations in the SkeletonMecanim component are applied on the preceding skeleton state with a certain weight, which can be described as result = lerp(lerp(A, B, x), C, y) for the same three animations.
In your blend tree, the order is important when you have three animations and two of them are identical. Close to the end of the transition, the values are as follows:
lerp(lerp(idle, idle, 0.8), right, 0.2) equals lerp(idle, right, 0.2) and is as expected, while
lerp(lerp(idle, left, 0.2), idle, 0.8) equals left * 0.2*0.2 + idle * (1 - 0.2*0.2) which weights left far lower.
When the transition is done, there are no longer three animations but only two, which is then again correct, thus immediately jumping to the correct end result, as you can see in your reproduction project.
I have just added an experimental additional MixMode called Resolve to the Mecanim Translator which calculates the respective Spine weights to match Unity's absolute weights better. While this will not resolve all issues for every possible scenario, it should be a fix for your use-case. It will take some more testing before this feature will be released officially, but I have attached it below for you for testing. Please let us know whether this works for you, and also if new issues arise.
@Grelle We have just pushed some commits (main commit and a compile-error fix on Unity 2017) to officially support this feature. Compared to the intermediate version provided in the zip file in the above posting, the Mix Mode has been renamed from Resolve to Match, and one issue with the first clip's weights has been resolved.
From the Changelog:
Skeleton Mecanim: Added new
Mix ModeMatch. When selected, Spine animation weights are calculated to best match the provided Mecanim clip weights.
A new spine-unity 4.2 unitypackage is available:
https://esotericsoftware.com/spine-unity-download
The spine-unity documentation will be adjusted soon as well.
Please let us know if you encounter any issues with this new feature. Thanks again for reporting!
Oh, thanks for info. Unfortunately I had no time to report one problem I found... It was more complicated situation to explain what is going on.
Now I need to check this issue with yout recent update, but I can't take time on it. I'm sorry.
I can provide less investigated results.
It is about this tree and how user interact with it. You can pull it, release it - and this tree go back to idle state, but with animation of some inertia. More you pull - more inertia is. It is made with Blend Tree, no problem.
Problem there: user can pull tree again from inertia state, and tree reacts immidiately, thats all right. But user cat catch the moment when animation is in transition (inertia -> idle). In this case tree will wait transition end, and will react on pull only with some delay.
First, Of course, we made interruption of transition, to make tree react immideately. But in this new mode tree behaviour was completely broken. So, other mods work bad, too (it blinks), but new mode was worst (especially when pull to the left).
We didnt solve this problem. We remove transition interruppt, and made transition time as small as possible, so user will not wait for long time.
So I can add some gifs, where user behaviour was imitated by some code. It is sequence:
- user pull,
- user release tree, and wait
- user grab tree again when tree in transition state.
Unfortunately I didnt have time to research Unity animator behaviour in same situation. May be it is all the same, but I doubt.
I have some package with this demo, if you interested.
And small video with real object and real interaction (by me). This blink on sart of the video is the part of the problematic behaviour.
Tree is set up to:
- new mode;
- no Auto Reset;
- interuption source for transition: NextStage
Grelle I have some package with this demo, if you interested.
Yes, please always send us a reproduction project when your have one available, no need for asking. Just sharing animated GIFs where things go wrong is like calling the fire department concerning a burning house but not telling them where it's located 
.
Oh sorry ) I decided I can send a packages only after... getting some confirmation from someone from forum.
I sent the package.
@Grelle Did you test your reproduction scene with the latest spine-unity package mentioned in my above posting? When trying to reproduce the issue, the GameObject in the bottom line named Resolve_Interruption using the new Match Mix Mode works without any sudden position jumps on my end, while the other two in the bottom line (MixNext_Interruption and AlwaysMix_Interruption) are showing such an issue.