• Editor

  • Feature suggestion - Dopesheet layer for secondary movement

Usually you will first lay out the basic movement of an animation, meaning you will have set up maybe 6 or 8 basic poses scattered through the timeline. In a running animation, for instance, the basic poses will be the character with both his legs on the ground taking impulse for a step, then jumping forward with one of his legs stretched out, then landing on the foot of that leg, etc. If the animation feels awkward, you'll adjust these few basic poses and the timing between them until the overall motion makes sense and feels good. It's great, it's just 6 or 8 frames to keep track.

All good so far! But then you need to start adding keyframes all around the timeline to add micro-adjustments (like aligning the char feet in frames where the interpolation doesn't produce the desired results) and secondary movements, cause we all love characters with bouncy hair and clothes and weapons! The thing is, the timeline then gets really messy, and it becomes much more difficult to then go back and tweak the overall movement if you ever need to do that (you usually do, as you guys know animation is all about iteration and refining). So when you're about to start adding secondary motion, it really feels like a leap of faith moment, as once your timeline gets keyframed at every single frame, it's practically impossible to keep track of the 'main' keyframes.

So this is how I imagine a dopesheet layer for secondary movement could work: we have a button that we press to let Spine know that we're now adding secondary movement. When we press it, all new adjustments in the dopesheet will be done in a separate 'layer' that can then be turned off when we need to back to tweak the general motion. This second layer would always be applied on top of the main movement, and its keyframes would be intertwined with the ones that define the main movement.

Wouldn't that be useful? 🙂

Related Discussions
...

1)
You're right. And I think your assessment of the problem is right. Mixing primary and secondary motion under the dopesheet does mess things up a lot especially if you have a LOT of secondary motion.

I like it. It gives a lot of clarity for animators (and it also facilitates the process of how professional character animators actually work) and I'd love it if this was how Spine editor worked.

But being dopesheet/timeline-centric has a chance of clashing with how the runtimes actually work.
If this feature were to be implemented, it should not allow having two of the same timeline (one on the secondary movement "layer" and one on the primary) because that's how the runtime and the system works anyway. This isn't only a matter of changing the runtimes but the understandability of the system to the animators and programmers too.

2)
Actually, Nate mentioned planning an actual "Layers" feature that's kinda based off of 3D programs. viewtopic.php?t=3099

The Layers feature categorizes items in the tree (slots, bones, attachments) and then allows you to control their editability and visibility per layer. This actually helps achieve what you're looking for but in a different way.

The downside to this implementation of Layers is that things are grouped per item in the tree, which means any item on the tree can't both be part of primary and secondary motion. Honestly, I can't think of a situation where this might actually become a problem but that doesn't mean it won't. Though I guess it can't possibly be too bad. It'll be handy nonetheless.

I don't think making a specific layer for secondary motion would be the right choice. While the idea is great, it would be better to make something more flexible. Like being able to just create multiple tabs in the dopesheet and naming them whatever you want.
The Layers feature we mentioned earlier might work for it, it would work like a filter, but it would then require being able to add the same bones to multiple layers.
Sorry for the short reply on the subject, I managed to land myself the flu. Good thing Nate is back today! 🙂

I'm not sure the proposed layers feature is related to separating main pose keys from secondary motion keys.

I would expect that the multiple layers of keys would be flattened to a single timeline for export and the runtimes would not be affected.

I agree the timeline does get messy easily. Describing it as a "leap of faith" when beginning secondary motion keys is a good description. Anything we can do to improve this would be great, but it has to be thought thru all the way. Regardless of how the UI is implemented (tabs, etc), how would the feature work?

If you move keys for the main poses, the secondary motion keys may no longer match up. Automatically moving the secondary motion keys may be possible

we know what main pose keys are before or after the main pose key we are moving, so we could move all secondary motion keys between those. The secondary keys may need to be moved between frames, which isn't good.

What happens if you have a secondary motion key at the same frames as a main pose key? I guess the main pose keys could show up when editing secondary motion keys and disallow secondary motion keys at those frames.

The Layers feature will inevitably help a lot with this, but only if (at least most) tree items involved in primary motion aren't also involved in secondary motion. And I think that'll be the case most of the time. But I definitely think the Layers feature's UI design needs to facilitate this use case.

Those are good points about the dopesheet/timeline-centered primary and secondary motion segregation.
I'm still for this implementation if it doesn't mess up the system's other purposes.

Here are some things that stick out for me:
If it flattened, how are the keys combined? Additively, I guess?
I mean the secondary keys being interpolated with the primary motion keys would just make it confusing on so many fronts.
Could they be flattened when easing curves are involved? Would exporting/reimporting JSON totally break this feature?

In the editor, what numbers would the UI show in that case? Just the numbers as if they were flattened?

The other implementation I can think of is just a purely hiding-and-showing UI thing:
That there would never be two timelines of the same bone of the same kind at any point, and you'd just be working with how Spine currently works.
But the keys on the secondary motion "dopesheet layer" could be greatly dimmed but still visible, while the primary motion keys would be normally colored and stand out normally. And you could swap these out with a button or shortcut.
And timelines that have no keys in the currently active layer would just be hidden.

This would not completely solve the problem of difficulty going back and fixing primary motion if you, for example, had primary and secondary rotation motion on the same bone. But the keys would at least be marked and clearly visible for you (which ones are primary and which aren't) while still being able to see keys for other parts too if you need to move them in groups.

This implementation might not be a viable option at all, but it's extra ideas for what could and can't be done.

Yeah, some great points, I see how this could quickly grow into an overcomplex feature! Also it would certainly require some experimentation and iteration so that it could be naturally integrated into the workflow while bringing more benefits than side effects...

As a reference, I'm working with a 30-frames wide running animation. It has 8 'real' keyframes which define the movement. However, after adding basic secondary motion and finetuning some weird mid frames, I've got 20 out of the 30 frames made into keyframes. I'm now way beyond the overall motion adjustments threshold! 😃

I have to admit this is not reeeeeally a problem for me. I knew about this leap of faith moment, so I kinda planned for it. But since we're discussing the matter, here's an updated understanding on how this could work based on all I read:

-What if we could select what we consider the Main Keyframes and give them names - such as "Right Foot touches ground", "Anticipation Frame", etc.

-The orange inclined square icon that appears in the Dopesheet for said keyframe would be different - maybe a different shape, a little bigger and in a different color from 'regular' keyframes.

-With a 'Adjust Main Keyframes' button turned on, only those keyframes would appear in the Dopesheet. Also, if you dragged one of these keyframes' position over the timeline to change the timing of the overall motion, all keyframes between that and the two adjacent 'Main Keyframes' would be resized proportionally. Yeah, that would kinda move them between frames, which could optionally be set to always stick to natural numbers instead.

-When you transform a keyframe into a "Main Keyframe", each and every change that is keyed to happen at that frame is now part of the Main Keyframe.

-However, if you keep editing the animation AFTER you have set the Main Keyframes, then it would work like this:

  -[b]If you have "Edit Main Keyframes" turned ON[/b] (therefore only showing Main Keyframes in the timeline), all changes you make become part of these Main Keyframes.

  -[b]If you have "Edit Main Keyframes" turned OFF[/b], you would be seeing the whole dopesheet as usual. If you made changes to any frames other than the Main Keyframes, it is business as usual (and those keyframes would be resized through the timeline as explained above if you moved an adjacent Main Keyframe). If you made changes to the Main Keyframes while in that mode, those changes would apply but would NOT be part of the Main Keyframe - the system could internally handle these changes as actually being an invisible, separate keyframe that changes the skeleton 0.01 milisecond after the Main Keyframe. This way you would have the freedom to keep editing stuff as usual and, internally and for the runtimes, it would all keep working as usual. And the secondary changes that you make to the keyframes that happen to 'overlap' with Main Keyframes would still 'obey' the Main Keyframes and apply on top of it, as relative changes.

Ok, my brain is burning. Does it make any sense? 😃

Annotating keys is on trello I think. I see Pharan's points on not flattening the timelines. GabrielDSC's approach is interesting. I wonder if there is something simple we could do for the edge cases...