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!
