It seems like the issue you're experiencing with the tree bending animation in Spine is related to how the transitions and rotations are being handled, especially when moving to the left. Here are a few potential solutions and considerations based on the provided contexts:

1. Additional Keys: Ensure that your animations have the required additional keys at the first frame. This is crucial for smooth transitions, especially when using SkeletonMecanim. Refer to the spine-unity Runtime Documentation: Required Additional Keys.

2. Mixing and Transition Settings: Check your mix duration and transition settings. If the mix duration is not set correctly, it can cause abrupt changes in the animation. Make sure that the MixDuration is applied properly to the correct animation. If necessary, set the transition duration to 0 in Unity to avoid unwanted transitions.

3. Constraint Order: If you are using constraints, ensure that the order of constraints is correct. Incorrect constraint order can lead to unexpected behavior during transitions.

4. Blend Trees: Since you are using a blend tree, ensure that the blend tree is set up correctly with the appropriate animations and transitions. Sometimes, issues can arise from how the blend tree transitions between different states.

5. Auto Reset and Setup Pose: Enable Auto Reset and ensure that the setup pose is correctly defined. This can help in maintaining the correct pose during transitions.

6. Debugging: To further debug the issue, you can try simplifying the project even more by isolating the problematic animation and testing it independently. This can help in identifying if the issue is with the specific animation or the overall setup.

Here is a summary of the steps you can take to troubleshoot and potentially resolve the issue:

• Ensure additional keys are present at the first frame of your animations.
• Verify and adjust mix duration and transition settings.
• Check the order of constraints if any are used.
• Ensure the blend tree is set up correctly.
• Enable Auto Reset and verify the setup pose.
• Simplify the project to isolate and test the problematic animation.

By following these steps, you should be able to identify and resolve the issue with the left bend animation.

Grelle I'm sorry to hear you're having trouble. Could you please email us a minimal Unity project that can reproduce the problem?: contact@esotericsoftware.com
Please include the URL of this forum thread in the email so we know the context. Then we can take a look at what's wrong.

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 Mode Match. 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!

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 .

@Grelle No problem . Thanks for sending the package, we'll have a look at it and get back to you here on the forum once we've figured out what's going wrong.

@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.

@Grelle Glad to hear it fixed the issues on your end as well, thanks for getting back to us!