Paperbot

2. Fallback/Return keys

Based on the example you provided, it seems like the issue could potentially be resolved by separating the animations and consolidating the ones that manage the same attachments onto a single track. For instance, it’s common practice to dedicate specific tracks to different parts of a character — such as using track 2 for eye animations and track 3 for mouth animations. That’s why I had trouble understanding why this approach wouldn’t work in your case.

Additionally, methods like setEmptyAnimation or setToSetupPose can reset the pose to the setup pose from the previous animations when needed at runtime.

To better understand your specific use case and why this functionality might be necessary, it would be helpful if you could create a small sample project demonstrating the issue and send it to us via email: contact@esotericsoftware.com

3. Animation pointing sliders

This proposal is certainly creative, but I have some concerns from a practical standpoint. Specifically, I’m worried that introducing a feature where a slider indirectly selects an animation by index would add a layer of indirection that could be difficult to manage in larger projects.

Currently, Spine doesn’t provide an easy way to see what value is keyed on a slider without selecting the keyframe and manually inspecting its value. That means if a slider is used to determine which animation is active, it could become difficult to understand why something is happening just by looking at the timeline.

In contrast, managing animations via AnimationState at runtime keeps the animation flow more transparent: you can clearly see which animations are playing on which tracks, and the control logic remains centralized within the engine, where dependencies are easier to manage.

You mentioned that it might be better handled on the engine side, and I agree. If anything, I think it would be helpful if the Spine Editor's preview tools allowed for more advanced testing — such as playing back individual tracks at specific times. But embedding this kind of logic directly into animations could lead to confusion, especially when trying to maintain or debug complex setups.

I don’t mean to dismiss your idea at all, but from our perspective, we try to prioritize features that will be broadly useful across as many use cases as possible. We're still not entirely sure whether the feature you're suggesting would benefit a large number of users, so if you have any additional context or supporting information, we’d be happy to hear it.

Paperbot Thank you for providing the steps to reproduce the issue!
After creating an animation slider that caused such drops in FPS, I confirmed that, even when the slider's mix value is set to 0, unrelated animations and the editor itself become laggy. This is indeed an issue that needs to be addressed. I will create an issue ticket for this.

Regarding skins, I would like to add one point:
There is an important distinction between disabling constraints via skins and disabling them by setting them inactive in the tree view—particularly in terms of whether they can actually be made inactive at runtime.
Disabling constraints using the visibility dots in the tree view is intended only for preview purposes within the Spine Editor and does not affect the exported data.
While skins themselves cannot be keyed in animations, they can be set or removed at runtime via script. For example, you can set event keys during an animation and then use those event keys to change the skins. Skins are an effective means of disabling and enabling many constraints instantly, without requiring smooth transitions.

Paperbot I'm glad to hear that it was helpful!

I have created an issue ticket to fix the problem with the slider affecting the editor's performance:
EsotericSoftware/spine-editor892
You can subscribe to this issue ticket to receive notifications when there is any progress on this issue.

Great input @Paperbot, we really appreciate your ideas! Sorry for my delayed response, got hit with the man flu.

I wrote a bit about the slider slowdown in the issue Misaki linked above (fixed in 4.3.25-beta, available now). We put reasonable effort into the editor being efficient and occasionally we do testing with huge projects to see where further improvements can be made. For this, sliders are new and were doing work that could be avoided. Still a draw order timeline with 26,000 keys is relatively slow in the editor (27fps for me). Probably don't do that.

The idea for "clear" keys is a good one! 4.3 might be a good time to get it in. We'll check how disruptive it will be to implement.

The idea for numbered animations for sliders is maybe a bit complex. We have considered allowing a slider's animation to be keyed. We even implemented it, but removed it. For sliders to work significant runtime changes were needed (that's why porting is taking a while) and this feature complicated that. The dust is mostly settled now, so maybe it could be revived. When a slider animation changes, the skeleton "update cache" has to be recomputed. That is relatively heavy, but could be OK if it doesn't happen very often (surely not 26,000 keys, right?!). The editor already does it every frame so the impact is only at runtime.

Anyway, once you can key a slider animation, then you can just use another slider and that gives you the numbered slider animations that you wanted. There is no problem that can't be solved by throwing sliders at it!

I'm scared of what a multidimensional array might mean! It is really cool seeing what people come up with, especially when it's not readily apparent even to us how they could have possibly done it.

Spine is very efficient in general because it is written like a game rather than like a typical desktop app. That allows us to not worry about performance most of the time, as the performance we get without special acrobatics is acceptable for the majority of users. This is good because optimizations can greatly complicate development. The flip side is that Spine may not scale up to what it potentially could, if it really needed to.

That said, if you run into a real world scenario where performance is an issue, please let us know and we may be able to improve it. There will always be limits that can be found with artificial scenarios, such as how many attachments can Spine handle before slowing down (IIRC 50-75k). As long as those are higher than any sane person would ever do, we're good. Eg, if you have 50k+ attachments you should probably be creating them at runtime with templates rather than rigging them all in Spine.

You can check performance in Skeleton Viewer to see how it compares to the editor. Of course you shouldn't have to suffer through a 10 FPS editor even if it's OK at runtime.

Thinking about "clear" keys, it would be pretty easy to make it a curve type. In other words, the transition between 2 keys could be set to stepped, linear, Bezier, or "clear" which would mean no change. For animations applied on top of others, this would allow the animations below to control the value. The downside is there is no transition. It would work like stepped: whatever value the animation was setting, suddenly the value from the animation below can be seen. That's OK for attachment visibility or anything else without transitions, but I expect people will want to transition smoothly to/from animations below.

To do that and keep it a curve type, we could say all clear keys are also Bezier. That's a bit hacky though. It also means you'd have some useless Bezier handles:

some keys > clear key > Bezier transition > clear key for the end of the transition > useless Bezier transition > clear key to start transition back > Bezier transition > some other keys

Otherwise, if it's not just a curve type we'd need a sort of first class key value possible for every timeline, then you'd be able to use stepped, linear, or Bezier as normal.

Or, we could make it a modifier on the curve type. So you still set stepped, linear, or Bezier but also whether it is clear. This works well with the many timelines that have curves. For the timelines that don't (attachment, draw order, event, inherit, physics reset, sequence), we'd need to do something else.

No worries, it's helpful to think through all ideas. We have no problem discard those that are too hard.

I agree a button in the dopesheet and graph may be sufficient.

After more thought, it seems hard to use the Bezier handles for the clear transition. The handles are in "value space" while the transition to or from clear is a percentage. Using the setup value as the clear value to define the transition could work, but feels a bit magical. A better way might be to have a separate timeline just for clear, though that has some complexities.

I'm now thinking maybe stepped and linear could be enough. After all, those are the only options when mixing between animations with AnimationState. Maybe clear can even be just linear, if it simplifies things.

Here's a proposal: any key can be marked as clear. The first clear key after a non-clear key is a linear transition to clear (fade out). Adjacent clear keys hold clear. The next non-clear key makes a linear transition to not clear (fade in). All keys work the same as normal -- you can still set values for clear keys, so you have the normal transition between key values and also fading in or out.

This makes clear a sort of annotation on top of the regular key system. Storing which keys are clear is easy. The difficulty of this feature is mainly what it does to the timeline logic. The next step is adding it to one timeline type and seeing how gnarly it gets.

We tried it out and I hoped to shoehorn it in with minimal changes, but ultimately it complicates the timelines a bit more than I like.

The lack of clear keys can be worked around by using multiple animations. For example, an animation played on top of other animations that does some main action, then has a few animated parts lingering for a while could be 2 animations: 1 for the main part and 1 for the lingering part. 2 animations is a bit annoying to manage, but it's possible.

There's also another way that's pretty flexible: use a slider for the part that needs to be clear. When a slider's mix is 0, its animation isn't applied at all. That means what it affects can be either keyed or clear at any time. This may come close to "playing" an animation be keying the slider frame, which so far I've been recommending against, but it could do the job. One caveat is all animations on all tracks are applied, then sliders and other constraints are applied. That means the slider animation is always on top of all animations.

Given those 3 things I think it's better not to implement clear keys. It's a neat feature but the need doesn't come up super often, has workarounds, and is a bit involved to implement. It was interesting to think through and was worth a look!

Maybe you could use one slider with each attachment keyed on a different frame? Than you'd use the slider to choose which attachment is visible, with 0 mix to clear.

I believe that is working correctly. A deform (FFD) can only be applied to 1) the mesh the deform was keyed for, or 2) any linked meshes for that mesh that have "inherit timelines" checked.

As always, we recommend not using deform keys as much as possible:
https://esotericsoftware.com/spine-keys#Deform-keys
Use bone weights to deform meshes, it's better!