This looks as if you are using MixBlend.Add where you should be using the default MixBlend.Replace. I assume that you previewed the second track in Spine normally and did not switch the second track to Additive Mixing as described here, right?

If this is not the problem, then perhaps the looping first shoot 1 animation has not keyed the position/rotation of the yaw bone. This way the additive animation would add to a never reset value, leading to an ever growing offset.

Thanks for the clarification and sorry that the assumption was wrong, the described behaviour just looked exacly as if that was the case (and it's easy to misunderstand MixMode or the small additive button).

We could reproduce that there is a difference between the Spine Preview window and the runtime behaviour (also with the spine-libgdx runtime and SkeletonViewer). We will get back to you as soon as we have figured out the cause of this difference.

Thanks for reporting!

Erika ：

I had this happen once on the Owl project when I forgot to key some features in the "idle" pose, the head would explode in a similar manner!

Alerif ：

Can you please explain it? Is it really necessary to key ALL bones in ALL animations in order to make it possible to mix them in additive mode?

What Erika meant was the same solution that we have discussed above, adding keys to the yaw bone in the track 0 animation shoot. You answered:

Alerif ：

And keying the jaw bone in shoot animation doesn’t help. It helps only if I key small rotation and transition to jaw bone in shoot animation, but it shouldn’t be a solution, don’t you think so?

What is stange here, is that there should not be any small rotation and transition change necessary, just keying the current position and rotation should do.

In general however, I would consider this as the proper solution and workflow. The base track animation sets an absolute translation and rotation value, then the additive animation track adds to this absolute value. When there is no key in the underlying tracks of the additive animation, nothing "resets" the value to the absolute base before adding to it, thus the rotation/translation value gets higher and higher every frame.

I understand however, that in regards to additive animation, it would be comfortable if the base track would count as "everything keyed". I fear we will have to wait until the official reply by Nate, as described below.

Alerif ：

I assume that the problem is on my side, but I can't figure out what exactly I should fix in my code or animations.

We also have to solve why the Preview window in Spine displays a different result than the runtimes (and SkeletonViewer). Nate will investigate the issue, unfortunately the pile of work on his desk is especially high in the last few days, so unfortunately the answer to this question will not arrive as quickly as we are otherwise used to, we are very sorry about that.

It is indeed very strange that the keys on the underlying track are not respected as you say. We will have a look at it, thanks for posting the reproduction package!

This is the main issue ticket url where you can subscribe to receive updates upon any progress:
https://github.com/EsotericSoftware/spine-editor/issues/547

@Alerif regarding the problem with keying on the first track does not help either: I just noticed that the export option Animation clean up does not export keys that are equal to the setup pose, so this leads to triggering the same problem again. So as a workaround until the official bugfix is out, you could export the animation with Animation clean up disabled.

From the above export behaviour, I guess that the desired behaviour was that the setup pose would be applied before any (missing or additive) keys, and that this setup-pose rotation is currently not applied in any runtimes.

Sorry again about the account problem.

romanalerif ：

The problem with mixing animations in additive mode also exists in Skeleton Viewer.

Thanks for the information. We are already aware of this (I mentioned it in my reply 6 days ago).
The current information is collected in this issue ticket:
https://github.com/EsotericSoftware/spine-editor/issues/547

No problem at all. It is totally normal to mentally skip over parts that seem less relavant or unknown.

Yes, you anderstood that right. So the solution for the problem will be adding a key (without any rotation change) to the jaw-bone on the base-track animation and exporting with Animation clean up disabled.