Click Inserting Keyframes in the Graph Editor should obey Automatic Time Snapping #83710

New Issue

bassam kurdali · 2020-12-12T21:46:52+01:00

bassam kurdali commented

2020-12-12 21:46:52 +01:00

Currently in the Graph Editor, ctrl-right click allows the animator to insert a new keyframe into an f-curve. The new keyframe is inserted directly under the mouse pointer.

The problem is that the inserted keyframe is almost certainly on a non-integer frame:

breaks workflow - animators are usually not trying to animate subframes (until they are), and results in a need to clean up each frame after ctrl clicking: first ctrl click, then snap to nearest frame immediately after
or confuses new users who might not understand why keyframing very close to the recently inserted keyframe results in discontinuity or jumps since the 'replace' part of add and replace doesn't work when the keyframe is not exactly the same.

Since the Graph Editor already has a setting for auto snapping in the header, it makes sense that ctrl right click inserting should just use the current setting (which defaults to nearest frame and eliminates the previous problems in the default setting), however new issues arise:

No Auto Snap
No change from current behavior, nothing to be done.

Nearest Frame
The default and most often used setting. Here we should create the new inserted keyframe to the frame nearest to the mouse. This can result in one of the following situations:

**best case:**animator clicks close to the snapped frame - the created keyframe is only slightly off from where the mouse was, which is ideal (fig 1), and would almost always be the case when zoomed out far enough.(fig 1)
middle case: animator clicks far from an snapped frame (perhaps we're zoomed in or are using a snap option with bigger distances, e.g. nearest marker) - the keyframe jumps a lot. (fig 2)

worst case: animator clicks far from the snapped frame which is outside the view - the keyframe now gets created so far away that the animator doesn't see it (no visual indication) which feels like a bug. (fig 3)

Frame Step
Doesn't map to inserting keyframes at all! perhaps we should just adopt / fall back to the same behavior as Nearest Frame

Second Step
Doesn't map to inserting keyframes at all! perhaps we should just adopt / fall back to the same behavior as Nearest Second

Nearest Second
This maps well, however, since seconds are further apart than frames, it's more likely we'd run into the undesirable cases in Nearest Frame. We could also consider falling back to Nearest Frame as well, depending on the zoom level.

Nearest Marker
This could work the same, but it feels weird/ likely to result in undesirable cases. We could fall back to nearest frame or nearest second, and have a sperate command for 'insert keyframe at marker'

Solving the problems for middle and worst case snapping

We have some options:

Highlight keyframe location before clicking: While holding control, but before right clicking, highlight the nearest snap-target, and use an indicator to the left or right of the view if the keyframe is out of view (like a gradient or a glow). problem could result in annoying noise when the user presses control for other reasons, e.g. to select keyframes to the right or left (control left click)
Animated highlight after clicking: an attention grabbing glow that animates on and fades off after clicking, on the frame where the new keyframe is added, tells the user "this is what you added" after the fact. we can also borrow the idea of the glow to the left or right of the graph editor when the new keyframe is off screen.

Solving the problems for snapping settings that may not make sense for click insert keyframe

Using 'fall backs' as suggest above
Having a different setting just for ctrl click (potentially a user preference)

The above is intended as a problem statement and start of discussion, not a final design. Once we decide on UX design, we could generate mockups for how it should look (UI)

Currently in the Graph Editor, ctrl-right click allows the animator to insert a new keyframe into an f-curve. The new keyframe is inserted directly under the mouse pointer. The problem is that the inserted keyframe is almost certainly on a non-integer frame: - breaks workflow - animators are usually not trying to animate subframes (until they are), and results in a need to clean up each frame after ctrl clicking: first ctrl click, then snap to nearest frame immediately after - or confuses new users who might not understand why keyframing very close to the recently inserted keyframe results in discontinuity or jumps since the 'replace' part of add and replace doesn't work when the keyframe is not exactly the same. Since the Graph Editor already has a setting for auto snapping in the header, it makes sense that ctrl right click inserting should just use the current setting (which defaults to nearest frame and eliminates the previous problems in the default setting), however new issues arise: **No Auto Snap** No change from current behavior, nothing to be done. **Nearest Frame** The default and most often used setting. Here we should create the new inserted keyframe to the frame nearest to the mouse. This can result in one of the following situations: - **best case:**animator clicks close to the snapped frame - the created keyframe is only slightly off from where the mouse was, which is ideal (fig 1), and would almost always be the case when zoomed out far enough.(fig 1) - **middle case:** animator clicks far from an snapped frame (perhaps we're zoomed in or are using a snap option with bigger distances, e.g. nearest marker) - the keyframe jumps a lot. (fig 2) # **worst case:** animator clicks far from the snapped frame which is *outside the view* - the keyframe now gets created so far away that the animator doesn't see it (no visual indication) which feels like a bug. (fig 3) ![ctrlclick.png](https://archive.blender.org/developer/F9505423/ctrlclick.png) **Frame Step** Doesn't map to inserting keyframes at all! perhaps we should just adopt / fall back to the same behavior as Nearest Frame **Second Step** Doesn't map to inserting keyframes at all! perhaps we should just adopt / fall back to the same behavior as Nearest Second **Nearest Second** This maps well, however, since seconds are further apart than frames, it's more likely we'd run into the undesirable cases in Nearest Frame. We could also consider falling back to Nearest Frame as well, depending on the zoom level. **Nearest Marker** This could work the same, but it feels weird/ likely to result in undesirable cases. We could fall back to nearest frame or nearest second, and have a sperate command for 'insert keyframe at marker' **Solving the problems for middle and worst case snapping** We have some options: - Highlight keyframe location before clicking: While holding control, but before right clicking, highlight the nearest snap-target, and use an indicator to the left or right of the view if the keyframe is out of view (like a gradient or a glow). **problem** could result in annoying noise when the user presses control for other reasons, e.g. to select keyframes to the right or left (control left click) - Animated highlight after clicking: an attention grabbing glow that animates on and fades off after clicking, on the frame where the new keyframe is added, tells the user "this is what you added" after the fact. we can also borrow the idea of the glow to the left or right of the graph editor when the new keyframe is off screen. **Solving the problems for snapping settings that may not make sense for click insert keyframe** - Using 'fall backs' as suggest above - Having a different setting just for ctrl click (potentially a user preference) The above is intended as a problem statement and start of discussion, not a final design. Once we decide on UX design, we could generate mockups for how it should look (UI)

bassam kurdali commented

2020-12-12 21:46:52 +01:00

Added subscriber: @BassamKurdali

bassam kurdali self-assigned this 2020-12-13 16:58:37 +01:00

bassam kurdali commented

2020-12-13 17:08:38 +01:00

A slightly more radical proposal:

We should probably examine the options in auto time snapping, and see if they are even useful/used. The ones that are not used for long periods of time should probably be an operator (and in most cases already exist):

No Snap: definitely useful when animating subframes or when working in the drivers editor
Nearest Frame: definitely useful, almost all the time, good as a default
Nearest Second: I've never seen this used by anybody, not sure why you would want it. shift S menu covers it if you need to in some case.
Nearest Marker: Ditto, but feels utterly bizzare. What happens if there are no markers in the scene? shift S menu covers it if you need it in some case.
Frame Step: I've never used this, I wouldn't swear no-body does but I don't know why.
Second Step: Ditto but more unlikely

We could instead replace the menu with:

A checkbox/ boolean: True means no snap, On mean means Nearest Frame
An integer: 0 means no snapping, 1 means one frame, 2 means every two frames, 3 etc... 24 would give you back nearest second (however, once you go higher than 1 you start needing offsets, e.g. if 2 do you want even frames or odd? 2 would be nice maybe if you are trying to animate on twos with constant interpolation

A slightly more radical proposal: We should probably examine the options in auto time snapping, and see if they are even useful/used. The ones that are not used for long periods of time should probably be an operator (and in most cases already exist): - No Snap: definitely useful when animating subframes or when working in the drivers editor - Nearest Frame: definitely useful, almost all the time, good as a default - Nearest Second: I've never seen this used by anybody, not sure why you would want it. shift S menu covers it if you need to in some case. - Nearest Marker: Ditto, but feels utterly bizzare. What happens if there are no markers in the scene? shift S menu covers it if you need it in some case. - Frame Step: I've never used this, I wouldn't swear no-body does but I don't know why. - Second Step: Ditto but more unlikely We could instead replace the menu with: - A checkbox/ boolean: True means no snap, On mean means Nearest Frame - An integer: 0 means no snapping, 1 means one frame, 2 means every two frames, 3 etc... 24 would give you back nearest second (however, once you go higher than 1 you start needing offsets, e.g. if 2 do you want even frames or odd? 2 would be nice maybe if you are trying to animate on twos with constant interpolation

Luciano Muñoz Sessarego commented

2020-12-13 20:21:52 +01:00

Added subscriber: @LucianoMunoz

Luciano Muñoz Sessarego commented

2020-12-13 20:21:52 +01:00

Also as a side note I think it would be really beneficial to have a maximum zoom to 1 frame of visibility,
Going further than that is no use for anyone, and would also solve the "snapping to a frame you cant see"

something like this:

Also as a side note I think it would be really beneficial to have a maximum zoom to 1 frame of visibility, Going further than that is no use for anyone, and would also solve the "snapping to a frame you cant see" something like this: ![2020-12-13 19_20_54-Blender.png](https://archive.blender.org/developer/F9506988/2020-12-13_19_20_54-Blender.png)

Jan-Willem van Dronkelaar commented

2020-12-14 00:39:31 +01:00

Added subscriber: @jwvdronkelaar

Jan-Willem van Dronkelaar commented

2020-12-14 00:49:59 +01:00

In #83710#1074439, @LucianoMunoz wrote:
Also as a side note I think it would be really beneficial to have a maximum zoom to 1 frame of visibility,

I was thinking the same thing when I was looking at the worst case scenarios. While I can only speak for myself I have never felt the need to zoom in further then a few frames. Animation is a game of "in relation to"; seeing a keyframe all on its own has little value.

With that said, a zoom max of 1 frame (technically 2 when you look at Luciano's screenshot) sounds like a sensible limit. Doing it this way would remove the need for a discussion on UI and therefore simplify the fixing of this bug somewhat.

> In #83710#1074439, @LucianoMunoz wrote: > Also as a side note I think it would be really beneficial to have a maximum zoom to 1 frame of visibility, I was thinking the same thing when I was looking at the worst case scenarios. While I can only speak for myself I have never felt the need to zoom in further then a few frames. Animation is a game of "in relation to"; seeing a keyframe all on its own has little value. With that said, a zoom max of 1 frame (technically 2 when you look at Luciano's screenshot) sounds like a sensible limit. Doing it this way would remove the need for a discussion on UI and therefore simplify the fixing of this bug somewhat.

bassam kurdali commented

2020-12-14 16:17:46 +01:00

Agreed. Note you'd still have some of the corner cases pop up, but I think a brief animated highlight after you click would make it quite understandable (and it would be less likely)

Experienced animators are going to click close to the integer frame anyway (unless they have snapping turned off and are animating subframes)
New animators will probably be a bit confused - we could have an info in the status bar indicating that snapping is on resulting in new keys not being under the mouse.

Agreed. Note you'd still have some of the corner cases pop up, but I think a brief animated highlight after you click would make it quite understandable (and it would be less likely) - Experienced animators are going to click close to the integer frame anyway (unless they have snapping turned off and are animating subframes) - New animators will probably be a bit confused - we could have an info in the status bar indicating that snapping is on resulting in new keys not being under the mouse.

bassam kurdali commented

2020-12-15 17:38:32 +01:00

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

bassam kurdali commented

2020-12-21 15:49:42 +01:00

Further Notes on Snapping modes (worth thinking through):

No snapping is obvious, just move freely on X and Y
Nearest Frame snaps horizontally to single frame, it is extremely useful and a good default since: only keys on integer frames are rendered, thus showing animator's intent, not interpolation, and the 'replace' mode of replacing keys when tweaking only works when keys are exactly on the same frame, which breaks if you've transformed them off frame.
Nearest Second: still struggling to find the workflow for this one, perhaps someone else can enlighten? Perhaps it could work as a 'magnetize' sort of way, as a snapping option that can be added to frame step, similar to how snap to vertex (e.g.) works in the 3D view.
Frame step: Assuming that you've already animated on subframes (non integer frames) and are now wanting to offset your animation to adjust timing, you want to keep integer frame keys on frames, but also not snap your subframes to integer frames, this is probably a pretty specific workflow but useful.
Second step: would be similar, except I don't know why we'd be animating on seconds
Nearest marker: perhaps you could use it in a 'magnetize' sort of way as it's own snapping option, similar to how snap to e.g. vertex works in the 3D view

Even with the magnetizing option, I am struggling to see why I would want snap to second or snap to marker as a mode as opposed to an operator. I can see frame step being useful sometimes (see above) but not really second step.

For marker snapping: I could see a more useful feature being locking a bunch of keyframes together (with a marker?) for e.g. IK/FK switching, where the IK, FK and constraint switching get locked together by the rig ui, to keep them in sync, but the snap to marker mode doesn't really do that - it's indiscriminate and quit strange.

My recommendation for snapping would be:

Keep Nearest Frame, Frame Step and No Snapping and drop all others
Have ctrl - insert keyframe obey no snapping, and snap to nearest frame on nearest frame (and potentially on frame step) *
Perhaps follow luciano's limit zoom idea? it needs thought though. *
Follow Sybren's idea of animating the inserted key so it gets created under the mouse , then moves to it's snapped location (after ctrl - right click)

If people complain about marker/second snapping find out about their workflow and implement them properly (with magnetization/as shift-clickable options)

It miiiiight be useful to think about specific ctrl-right click behaviors on frame step- for instance, absolutely snapping to integer frames only when nearest frame is enabled, and using a threshold allowing subframes when using frame step? How to limit zoom is also interesting, as you don't want one integer frame in the middle of the graph editor with none visible on the edges, rather you want one integer frame visible on each edge.

Further Notes on Snapping modes (worth thinking through): - No snapping is obvious, just move freely on X and Y - Nearest Frame snaps horizontally to single frame, it is extremely useful and a good default since: only keys on integer frames are rendered, thus showing animator's intent, not interpolation, and the 'replace' mode of replacing keys when tweaking only works when keys are exactly on the same frame, which breaks if you've transformed them off frame. - Nearest Second: still struggling to find the workflow for this one, perhaps someone else can enlighten? Perhaps it could work as a 'magnetize' sort of way, as a snapping option that can be added to frame step, similar to how snap to vertex (e.g.) works in the 3D view. - Frame step: Assuming that you've already animated on subframes (non integer frames) and are now wanting to offset your animation to adjust timing, you want to keep integer frame keys on frames, but also not snap your subframes to integer frames, this is probably a pretty specific workflow but useful. - Second step: would be similar, except I don't know why we'd be animating on seconds - Nearest marker: perhaps you could use it in a 'magnetize' sort of way as it's own snapping option, similar to how snap to e.g. vertex works in the 3D view Even with the magnetizing option, I am struggling to see why I would want snap to second or snap to marker *as a mode* as opposed to an operator. I can see frame step being useful sometimes (see above) but not really second step. For marker snapping: I could see a more useful feature being locking a bunch of keyframes together (with a marker?) for e.g. IK/FK switching, where the IK, FK and constraint switching get locked together by the rig ui, to keep them in sync, but the snap to marker mode doesn't really do that - it's indiscriminate and quit strange. My recommendation for snapping would be: - Keep Nearest Frame, Frame Step and No Snapping and drop all others - Have ctrl - insert keyframe obey no snapping, and snap to nearest frame on nearest frame (and potentially on frame step) * - Perhaps follow luciano's limit zoom idea? it needs thought though. * - Follow Sybren's idea of animating the inserted key so it gets created under the mouse , then moves to it's snapped location (after ctrl - right click) # If people complain about marker/second snapping find out about their workflow and implement them properly (with magnetization/as shift-clickable options) * It miiiiight be useful to think about specific ctrl-right click behaviors on frame step- for instance, absolutely snapping to integer frames only when nearest frame is enabled, and using a threshold allowing subframes when using frame step? How to limit zoom is also interesting, as you don't want one integer frame in the middle of the graph editor with none visible on the edges, rather you want one integer frame visible on each edge.

Sybren A. Stüvel commented

2021-07-08 17:23:08 +02:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2021-07-08 17:23:08 +02:00

In #83710#1074439, @LucianoMunoz wrote:
Also as a side note I think it would be really beneficial to have a maximum zoom to 1 frame of visibility,

I think this is a good idea, but should be optional somehow. Sometimes it's nice to be able to zoom in arbitrarily far, for example when trying to debug some Python script that just puts the keys ever so slightly in the wrong place. That should be the exception, though, as indeed for normal animation work you don't need rediculous-level zooming.

> In #83710#1074439, @LucianoMunoz wrote: > Also as a side note I think it would be really beneficial to have a maximum zoom to 1 frame of visibility, I think this is a good idea, but should be optional somehow. Sometimes it's nice to be able to zoom in arbitrarily far, for example when trying to debug some Python script that just puts the keys ever so slightly in the wrong place. That should be the exception, though, as indeed for normal animation work you don't need rediculous-level zooming.

Paul Larson commented

2021-10-23 02:47:15 +02:00

Added subscriber: @GeorgiaPacific

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Click Inserting Keyframes in the Graph Editor should obey Automatic Time Snapping #83710

worst case: animator clicks far from the snapped frame which is outside the view - the keyframe now gets created so far away that the animator doesn't see it (no visual indication) which feels like a bug. (fig 3)

If people complain about marker/second snapping find out about their workflow and implement them properly (with magnetization/as shift-clickable options)