Design: New Graph Editor Key Manipulation Operators #81836

New Issue

This is the design task for #81785

Builds
Linux: https://blender.community/c/graphicall/6qbbbc/
Windows: https://blender.community/c/graphicall/7qbbbc/

Big picture:
Blender already has the pose sliding tools, that allow you to interactively create breakdowns in Pose mode.
It uses a modal operator and the cursor to interactively set the pose. Using the same interaction, we could add similar functionality to the graph editor to manipulate multiple keyframes.

Here is how it works:
graph_editor_slider_tools.mp4

UI

Operators will be in a submenu in within "Key"

For quicker access they are in a pie menu
However this poses the question of how this would work when more operators get added.
What hotkey should be used? I've temporarily set it as ALT + SHIFT + S

Use the new slider representation from D9054
This makes it possible to quickly reach 0% or 100% because it's capped.
Overshoot can be enabled at the press of a button

This is the design task for #81785 --- **Builds** Linux: https://blender.community/c/graphicall/6qbbbc/ Windows: https://blender.community/c/graphicall/7qbbbc/ --- **Big picture:** Blender already has the pose sliding tools, that allow you to interactively create breakdowns in Pose mode. It uses a modal operator and the cursor to interactively set the pose. Using the same interaction, we could add similar functionality to the graph editor to manipulate multiple keyframes. Here is how it works: [graph_editor_slider_tools.mp4](https://archive.blender.org/developer/F9219671/graph_editor_slider_tools.mp4) --- ### UI **Operators will be in a submenu in within "Key"** ![graph_editor_slider_menu_2.png](https://archive.blender.org/developer/F9052081/graph_editor_slider_menu_2.png) **For quicker access they are in a pie menu** However this poses the question of how this would work when more operators get added. What hotkey should be used? I've temporarily set it as `ALT + SHIFT + S` ![slider_pie_menu.png](https://archive.blender.org/developer/F9052077/slider_pie_menu.png) **Use the new slider representation from [D9054](https://archive.blender.org/developer/D9054)** This makes it possible to quickly reach 0% or 100% because it's capped. Overshoot can be enabled at the press of a button ![slider_gui_2021_04_28.png](https://archive.blender.org/developer/F10113211/slider_gui_2021_04_28.png)

Changed status from 'Needs Triage' to: 'Confirmed'

Added subscriber: @ChrisLend

Added subscriber: @dr.sybren

Using the same interaction, we could add similar functionality to the graph editor to manipulate multiple keyframes.
Here is a rough mockup of how this would work.

Functionality-wise, the video looks nice, indeed.

For quicker access they should be in a pie menu

Can you make a screenshot of what such a pie menu would look like? You can modify any pie menu (for example GRAPH_MT_key_snap in space_graph.py) so that it just has the appropriate labels. That's enough for a screenshot.

However this poses the question of how this would work when more operators get added.

I think that operators should be added based on their function, and not on whether or not they use this manipulation method. That may open up a different categorisation, with a pie menu for every category.

Maybe you can update this task's description so that it's clearer how it relates to its child tasks. Now this task and #81785 (Implementation: Modal Key Manipulation Operators) have almost identical titles.

> Using the same interaction, we could add similar functionality to the graph editor to manipulate multiple keyframes. > Here is a rough mockup of how this would work. Functionality-wise, the video looks nice, indeed. > For quicker access they should be in a pie menu Can you make a screenshot of what such a pie menu would look like? You can modify any pie menu (for example `GRAPH_MT_key_snap` in `space_graph.py`) so that it just has the appropriate labels. That's enough for a screenshot. > However this poses the question of how this would work when more operators get added. I think that operators should be added based on their function, and not on whether or not they use this manipulation method. That may open up a different categorisation, with a pie menu for every category. Maybe you can update this task's description so that it's clearer how it relates to its child tasks. Now this task and #81785 (Implementation: Modal Key Manipulation Operators) have almost identical titles.

Added subscriber: @LucianoMunoz

Would love it if anyone could build a Windows version .... wink wink

Added subscriber: @HazyHops

DUDE this is AMAZING. Most of these work exactly how I initial figured! Thanks for getting that Windows version up! :D

(Having never posted on a design task, let me know if formatting and such is wrong and I can adjust accordingly)

You may or may not know some of these already?

Seemingly any non-flat bezier tangents have issues when modified by any slider. Specifically the left-side handles stay still.
Smooth Slider: Not sure how the specifics are working but it but on the Smooth slider, going over 100% overshoots the value change of any individual key. Would love to hear other's thoughts on it, but since negative values "un-smooth", I would expect a positive overshoot on Smooth to have the same effect as running multiple 100% smooth actions instead overshooting? (lemme know if you need a vid/image lol)
Sensitivity: Slider representation will fix current value adjusting so I look forward to that, but allowing SHIFT for micro adjustments, (and CTRL/something for larger (significant overshoot) adjustments) would make the slider even more powerful.

**DUDE** this is *AMAZING*. Most of these work exactly how I initial figured! Thanks for getting that Windows version up! :D (Having never posted on a design task, let me know if formatting and such is wrong and I can adjust accordingly) You may or may not know some of these already? - Seemingly any non-flat bezier tangents have issues when modified by any slider. Specifically the left-side handles stay still. - Smooth Slider: Not sure how the specifics are working but it but on the Smooth slider, going over 100% overshoots the value change of any individual key. Would love to hear other's thoughts on it, but since negative values "un-smooth", I would expect a positive overshoot on Smooth to have the same effect as running multiple 100% smooth actions instead overshooting? (lemme know if you need a vid/image lol) - Sensitivity: Slider representation will fix current value adjusting so I look forward to that, but allowing SHIFT for micro adjustments, (and CTRL/something for larger (significant overshoot) adjustments) would make the slider even more powerful.

thanks for the feedback
formatting is good ;)

I'll look into the tangent handles issue. I haven't noticed that until now, but it should be reasonably easy to fix. Thanks for pointing that out.
Smooth is less than ideal, I agree. In fact the algorithm doesn't work properly if keys are not evenly spaced. So this needs to be redone, but I'd say this is out of the scope of this task. Especially since I need to decide on an algorithm first (or a choice of algorithms?)
Yes the slider will be implemented in the end. SHIFT and CTRL will work as in D9054. I'll let you know when that's in for testing

thanks for the feedback formatting is good ;) * I'll look into the tangent handles issue. I haven't noticed that until now, but it should be reasonably easy to fix. Thanks for pointing that out. * Smooth is less than ideal, I agree. In fact the algorithm doesn't work properly if keys are not evenly spaced. So this needs to be redone, but I'd say this is out of the scope of this task. Especially since I need to decide on an algorithm first (or a choice of algorithms?) * Yes the slider will be implemented in the end. SHIFT and CTRL will work as in [D9054](https://archive.blender.org/developer/D9054). I'll let you know when that's in for testing

Added subscriber: @acorn

Mac version would be very useful.

Added subscriber: @ErickNyanduKabongo

Added subscriber: @jwvdronkelaar

Added subscriber: @FinbarrORiordan

Added subscriber: @Jaye.Antoni_Whyldz

this needs to be here v2.90

This issue was referenced by 9797b95f61

This issue was referenced by 9797b95f617561dc87b702e1bce829a551260689

Added subscriber: @JasonSchleifer

Super cool! In terms of hotkeys, since animators are already used to Shift+E to go to pose mode while in the 3D viewport, would it be possible to use something similar like ctrl+shift+e or something like that? Then it'll feel like an extension of the tool they're used to, just with more awesome power. :)

I agree wish Jason here, i feel maybe the main one or the last one you use from the piemenu can be put in shift e, and shift alt e or shift control ee could be used to get the pie menu with all the options

Shift+E would be ideal to keep it consistent, but that hotkey is currently used by "Set Keyframe Extrapolation"

To be fair I think that's not used heavily but we should discuss it at the next meeting.
Either move the pose sliding tools to something else than Shift+E that is available in the graph editor
Or move the "Set Keyframe Extrapolation" thingy to something else

As long as it's consistent I don't mind

3.0 might be a good version to swap things around anyway

Shift+E would be ideal to keep it consistent, but that hotkey is currently used by "Set Keyframe Extrapolation" To be fair I think that's not used heavily but we should discuss it at the next meeting. Either move the pose sliding tools to something else than Shift+E that is available in the graph editor Or move the "Set Keyframe Extrapolation" thingy to something else As long as it's consistent I don't mind 3.0 might be a good version to swap things around anyway

I've been inclined to try to think how to do a better version of that menu (set keyframe extrapolation) to be able to use it to add any sort of curve modifier to all the curves selected.
I'd agree that we could move it away from shift e for consitency and come up with a new solution for that.

I've been inclined to try to think how to do a better version of that menu (set keyframe extrapolation) to be able to use it to add any sort of curve modifier to all the curves selected. I'd agree that we could move it away from shift e for consitency and come up with a new solution for that.

Added subscriber: @ChristiaanMoleman

Added subscriber: @AndyCuccaro

Added subscriber: @L0Lock

Added subscriber: @Robonnet

Added subscriber: @KevinCBurke

This comment was removed by @KevinCBurke

*This comment was removed by @KevinCBurke*

I was using it incorrectly at first, but after switching to Blend to Neighbor, I got the right behavior. This feature in incredible, @ChrisLend !!

I was using it incorrectly at first, but after switching to Blend to Neighbor, I got the right behavior. This feature in **incredible**, @ChrisLend !!

Added subscriber: @hahnzhu

Added subscriber: @razed

Can something like sample undershoot? Might be nice for quick cleanup :)

In #81836#1278241, @razed wrote:
Can something like sample undershoot? Might be nice for quick cleanup :)

Could you explain what you mean? Maybe even an example for how it would be used

> In #81836#1278241, @razed wrote: > Can something like sample undershoot? Might be nice for quick cleanup :) Could you explain what you mean? Maybe even an example for how it would be used

Sorry for taking so long to get back to you, I was thinking something like the decimate feature but it would try to keep the original bezier shape as best it possibly could. If this comes off as feature request-y, I apologize and ignore me :). I was thinking it could be an extension of the sample operator (to undershoot) but It might just be unrelated functionality.

Added subscriber: @SteffenD

@ChrisLend is stepping down from this work, as other things in his life take priority. As such, I'll take it off the "Short Term Tasks" list for now.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Design: New Graph Editor Key Manipulation Operators #81836

UI