it seems that attachment mixing is not working properly in this version (4.2).

gunspike

Hello, I am currently using the latest version of Spine 4.27.

It seems that attachment mixing is not working properly in this version (4.2).

Let me provide an example to explain the issue:

Creation Animation 1: This animation contains attachment animation keys. It follows the method used in version 3.8, where attachments were switched, and keys were added accordingly.
Idle Animation 1: This animation does not contain any attachment animation keys.
Now, I attempt to mix these two animations.

Desired Outcome:
When transitioning from Creation Animation 1 to Idle Animation 1, the attachments from Creation Animation 1 should persist, and the two animations should mix seamlessly.

Issue:
In version 4.2, this mixing does not work as expected. Using sequences allows Creation Animation 1 and Idle Animation 1 to mix, but there are some problems:

Idle Animation 1 must have sequence keys for the mix to work.
If Idle Animation 1 does not have sequence keys, the mix fails, resulting in an error.
What I Expect:

The mix should work with attachment keys, not just sequence keys.
When using sequence keys for mixing, the subsequent animation should not require sequence keys to achieve a seamless mix.
As it stands, sequence keys are always displayed on the screen, which can cause various issues.
Is there any way to resolve or improve this behavior?

Misaki

gunspike As Spinebot replied, in general, the behavior during mixing should be specified in the code at runtime. I am not sure why it works with sequence keys, but try changing the value of attachmentThreshold and see if that solves the problem.

Spinebot

In Spine 4.2, the behavior you're experiencing with attachment mixing is due to how animations handle attachment keys. When transitioning from an animation with attachment keys (like Creation Animation 1) to one without (like Idle Animation 1), the attachments revert to the setup pose unless the second animation also keys the attachments. This is consistent with the changes made in Spine 4.1 and later, where animations mix back to the setup pose unless otherwise specified. To achieve the desired outcome you can use the attachmentThreshold setting to control how attachments are applied during mixing.

Nate

In older versions of Spine, the skeleton could keep attachments or other state after an animation was applied. In newer versions of Spine, AnimationState (normally) restores properties that were keyed in animations to the setup pose if they are not keyed in subsequent animations (unless clearTrack, clearTracks, or trackEnd is used). This makes it easier to control the skeleton state when many animations are applied. Previously you would very often have state sticking around that was keyed in a previous animation, but isn't keyed in the current animation. This leads to keying everything so you can be sure what your skeleton state is, but keying everything is error prone and negatively affects performance.

attachmentThreshold controls whether you get attachment keys from the animation you are mixing from or the animation you are mixing to (or the setup pose, if not keyed in the animation you are mixing to) during the mix. After the mix, you will always get the attachment keys of the current animation (or the setup pose).

If you want keyed values to persist after an animation is applied, like they used to, then you'd need to modify the AnimationState source code. I probably posted something about how to do that in the past, we could probably dig it up. However, I suggest moving to the new behavior (especially if starting a new project), as it is much easier to manage. You really don't want all your animations to need to key everything.

If you want an animation to continue to affect the skeleton after it is no longer applied, in some cases you can continue to apply the animation instead of letting it finish. If you are using animations for behavior like equipping an item, I suggest setting attachment visibility explicitly by using game state, rather than having the attachment visible as a side effect of an animation that was applied in the past and is no longer being applied.

As for the difference between AttachmentTimeline and SequenceTimeline, AttachmentTimeline has this code:

if (direction == out) {
	if (blend == setup) setAttachment(skeleton, slot, slot.data.attachmentName);
	return;
}

if (time < frames[0]) {
	if (blend == setup || blend == first) setAttachment(skeleton, slot, slot.data.attachmentName);
	return;
}

SequenceTimeline has this:

if (time < frames[0]) {
	if (blend == setup || blend == first) slot.setSequenceIndex(-1);
	return;
}

Given this, SequenceTimeline is missing logic that it should probably have so that it matches the AttachmentTimeline behavior. Since they are so similar, I think they should behave the same. We will make this change and test internally before publishing the change. Edit: the change is here, soon to be ported to other runtimes.

gunspike

Thank you for your response, but I didn't quite understand it.

In this case, the attachment flickers.
Let me explain more clearly.

Animation 1 has an attachment animation:

A spinning animation (sequence or attachment key).
Animation 2 does not have an attachment animation.

In the settings, attachments should be turned off.

Based on the explanation, if Animation 2 has a sequence or attachment key, it overrides the spinning animation of Animation 1. As a result, the mix between the two animations does not blend naturally.
During mixing, the attachment animation of Animation 1 should appear and mix with Animation 2.

How can I achieve this?![
]

Misaki

gunspike From your illustration alone, it appears that you are not trying to mix animations, but rather play multiple animations simultaneously using AnimationState tracks. Are these animations supposed to play on the same track? You may want to email us a minimal Spine project that can actually demonstrate the problem you are having: 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.

Nate

When we talk about "mixing" it is from one animation to another on the same track. What you have is playing animations on multiple tracks.

It works correctly for me. Here the flapping is a sequence and the translation is an animation:
Loading Image
Project file:
http://n4te.com/x/697-dragon-ess-flap.spine

I set up the multi-animation playback in the Preview view. When you play the flapping animation, you need to disable looping. It is only one key so if looping is on, you will only see the first frame, as it repeats frame 0 over and over. With looping off the track time continues and the sequence plays like you want.