It's an interesting idea, I think I like it. We have a similar idea for adding arbitrary name/value pairs, but for use at runtime rather than tree filtering. It could be for both.

Do you know about selection groups? They help some, though I know it's not a replacement for your proposal.

One of the easily missed features in Spine is selection history. Page Up and Page Down will navigate the history of things you've selected. It's very common to have something selected, select something else, then need to select the first thing again. Pressing Page Down will select that first thing without any hunting through the tree or even needing to click in the viewport.

Ooo, I'd love something like this.

(Also, that pageup/pagedown selection trick will come in handy!)

Of course, my current project might be a little more complex than usual...

...but I'd definitely appreciate tools for managing rigs as they grow in complexity! I've only been able to keep things even slightly manageable by being diligent with naming schemes and using the search filter. A tagging system would be an excellent complement to that.

Two things that I think might be helpful to add to that:

1. Allow tags to override bone colour. I try to make sense of my rig by separating functional elements by colour; basic bones, advanced controls, bones for skin attachments, bones for structure, bones for constraint calculations, etc. It makes the skeleton a lot more legible, but I have to manually set the bones; it'd be convenient to set a tag to "override bone colour". If a bone has multiple tags that override colour, then use whichever was applied first.

2. Shortcuts for toggling the scene visibility for tag groups. I don't normally need to see the calculator bones or non-control structural parts and they cause some clutter, so it'd be nice to hide them selectively.

IanM Your idea sounds very cool! By the way, there is an issue ticket on our roadmap to add a Selections panel: EsotericSoftware/spine-editor409
There was a cool image of the panel made by a user, but unfortunately, now it seems to be not found. Adding tags to the Tree view would certainly be nice, but personally I really like the idea of adding a Selections panel that allows you to manipulate selections across all views. If you have anything you want to add to the issue, please feel free to add your comment.

Hm. You already get most of this functionality by box-selecting the dopesheet, turning on shift, etc. It also raises questions about how it's supposed to resolve when two of these animation groups have conflicting keys; what does it look like when they're overlapped?

OTOH, I do like how that creates landmarks for the animation! What if it were simplified it down to a "comment/tagging track"? That is, a global track with "tag" keys that have text associated with them that shows up at the top (no matter what's selected) like in your mockup, except now they're tied to a single frame for simplicity.

In most cases you'd only need the tag at the start of a section, with the next one implying the end boundary, and box-select, shift, and the other existing tools get the manipulation you want. If you needed to specify overlapping durations, you could use start + end tags. You could also leave "note to future animators"-style comments!

For the layering/overlap stuff you describe, one thing many animation packages implement are animation layers. It's a feature I've occasionally found myself wishing for in Spine. An animation turns into a collection of layers, potentially with keys on every track. With only a single layer nothing really changes, but every additional layer is added on top for a composite effect.

This can be really powerful; for instance, you can:

• Animate the main motion on one layer, then put secondary and detail motion on another, reducing clutter and letting you make big changes on the main layer without needing to change the others.
• Make non-destructive alterations/what-ifs
• Declutter by animating parts that move independently on a layer
• Keep sections of the animation (like what you've described) on separate layers for easy shifting, stretching, and crossfading
• Author additive animations (recoil or hit impacts, for instance) in context using the standard idle pose as a reference.

In theory Spine should have some of the groundwork done to support this since it already can do additive animation. I think draw order changes are the only thing that doesn't cleanly map onto that; presumably that'd be "base layer only". That said, I imagine animation layers would break a ton of assumptions in the runtime and editor.

It'd be a lovely addition, though!