Esoteric Software

[eglynum]

Hello!

I'm using the spine runtime to animate an enemy when it gets punched. The two animations being played are an idle animation and a recoil animation. The idea is that the idle animation never stops playing, and then the recoil animation plays in addition to the idle animation when the enemy is punched.

My first step was to play the animations on different tracks. That alone worked well enough except that the final frame of the recoil animation continues to influence the enemy's animations after it's done. So my first question is how can I completely eliminate the track entry playing the recoil animation after it's complete?

Another thing that didn't go as expected was when I tried using MixBlend_Add on the recoil animation's track entry. I was hoping that every frame the recoil animation would be added to the idle animation. But it works more like every frame the recoil animation is added to all previous frame's recoil animation additions. So a subtle recoil turns into a spin. So my second question is can MixBlend_Add be used in the way I want to use it? Maybe I need to reset the recoil track to the t-pose every frame?

[Harald]

So my first question is how can I completely eliminate the track entry playing the recoil animation after it's complete?

You add an empty animation after it if you want it to be mixed out:
AnimationState addEmptyAnimation

can MixBlend_Add be used in the way I want to use it? Maybe I need to reset the recoil track to the t-pose every frame?

Please see the documentation here:
MixBlend add
Additive animation requires keys on lower tracks for each additive key to base the addition on. So if you have three bones animated in your additive animation, you need to set keys at the same three bones on a lower track. Otherwise your additive animation will e.g. add the difference of rotation - setupPoseRotation every frame, making it spin like a propeller .

[eglynum]

Thanks! That helps a lot.

Adding the empty animation is the main thing I needed, and it works great. As for using MixBlend_Add, the requirement that upstream animations reset/anchor the downstream additions makes sense in hindsight.

In general, I can see now that any attempt to overlap animations adds more requirements than I expected for how animations must be keyed. But I'm excited to have just learned that Spine supports viewing how things will look when dealing with overlapping animations very well (for those confused like I was, find the preview view tutorial).

[Harald]

Glad to hear, thanks for getting back to us!

[eglynum]

I have a follow-up question. After taking some time to understand how to properly use the preview view, it's showing the exact result that I want to see in-game. And I'm using the same animations that we thought had keying issues. So now my question is how can I get the runtime to function exactly as the Spine editor does?

Here's what I do in code:
- setAnimation idle on track 0, and leave the mix blend default as 'replace'
- setAnimation recoil on track 1, and then change the mix blend to 'add'

Here's what I do in the Spine editor's preview view:
- click on track 0
- click on the idle animation
- click on track 1
- click on the 'additive' button
- click on the recoil animation

[Harald]

So now my question is how can I get the runtime to function exactly as the Spine editor does?

Your code looks correct, it mirrors your setup in the Spine Editor.

A difference of the Spine Editor is that the Preview view calls Skeleton setToSetupPose each frame, while runtimes do not do that. This hides problems of additive tracks where the lower track doesn't key all the same properties as tracks with higher track indices.

Please also be sure to have Animation cleanup disabled upon skeleton export when using additive tracks, which will remove keys identical to the setup pose. You don't want these explicitly set keys deleted on the lower track when basing additive animation keys on top of them.

You can see this issue ticket comment for more info:
https://github.com/EsotericSoftware/spine-editor/issues/547#issuecomment-606071406

[eglynum]

Very helpful again, thank you!

[Harald]

Glad it helped, thanks for getting back to us.