Scaling keys in dope sheet is different from graph editor (ignores handles, esp, noticable when scaling negative) #103802
Short description of error
Seems like if handles are not auto-clamped then Dope Sheet messes things up.
Exact steps for others to reproduce the error
In attached file duplicate and translate both keys further in timeline, also put timeline cursor between them:
- With Graph Editor press S-1 to reverse new keys -> result is OK
- CTRL Z to undo and repeat reversing in Dope Sheet -> bezier handles are processed incorrectly
Changed status from 'Needs Triage' to: 'Confirmed'
The difference here is between:
The later sets handles to auto (afaict from quick glance) to compensate, the former ignores handles alltogether it seems.
This is not nice, surprised it hasnt been reported before, not sure if this will be considered a bug though (might be a borderline feature request).
@dr.sybren : this is worth keeping, right (will confirm for now)?
I wouldn't call this a bug per se, but the current behavior certainly doesn't seem properly thought out. So I think it deserves some proper consideration, and then we can change the behavior to whatever seems best.
@dr.sybren Mentioned to me that regardless of the decision (e.g. even if we decide it's best to leave as-is), the rationale for the differing behaviors should be documented in the code. Currently it is not.
We discussed this in last week's animation module meeting, and the conclusion was that there are several related behaviors here that should be worked out holistically together:
- How do (non-auto) key frame handle transforms work in the dope sheet/action editor.
- How do (non-auto) key frame handle transforms work in the f-curves editor in various circumstances:
- When only the keys are selected.
- When the keys and handles are selected.
- When the handles are hidden.
- Whether handles are scaled/rotated or not should depend on whether those handles are selected. If they are selected, they're scaled/rotated. If not, then they aren't scaled/rotated.
- Conceptually, handles are defined as relative to their keys. So keys should still translate their handles with them when scaling/rotating, even when the handles themselves aren't selected.
- In views where the handles aren't visible (e.g. in the dope sheet, but also in the graph editor with handles hidden), selecting keys also automatically selects their handles. So in these views selecting keys and e.g. scaling them will scale their handles as well.
- In views where the handles are visible, selecting keys does not automatically select their handles. So in these views (unless the handles are specifically selected as well) they don't get scaled/rotated.
- Add graph editor operators (if they don't already exist) to select/deselect the handles of selected keys, to make it fast for the animator to get the selection (and thus behavior) they want.
The general rationale for this proposal is:
- Blender has a "select what you want to operate on -> operate" interaction model, and this keeps animation editing consistent with that. So the behavior won't be surprising when coming from other parts of Blender.
- This actually makes the graph editor more flexible than it is now, because it's current behavior is to always affect handles even when they aren't selected. So this is a more powerful editing model.
- This can potentially be extended to more than just the transform operators: all selection-respecting operators could be made to respect handle selection as well, giving the animator more power in general to define what they're operating on.
- When handles aren't visible (e.g. dope sheet), the animator is effectively working with the keys as a higher-level representation of the animation in that area, which includes the handles. So it makes sense to select the handles as well. And this leads to more intuitive behavior, where selecting part of the animation and scaling on x by -1 properly reverses the animation. And scaling by 2 properly slows the whole animation down. Etc.
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?