Proposal: Time Selection

Archive Blender Development
1

Proposal: Time Selection

For what purpose?

Blender lacks a way to modify animation data between points that is not tied to selected keyframes.

If the user wanted to offset an area of an animation, this is how they would have to do it currently. (not entirely 1 to 1)

simplescreenrecorder-2020-11-05_01.34.01

Having a selectable time range will drastically speed this up, here is a hacky implementation in python of this premise.

simplescreenrecorder-2020-11-05_01.35.04

How this would work

The user will select an area on the timeline.

This area can then be used to affect animation data depending on the user’s actions

Here is how it would look.

image

Ideas for implementation

UI

Interaction

Tool, Mode, or Editor??

This would have to add either a toolshelf and new tool, or a new mode in all the affected spaces/editors, which would be everything under the Animation Editor category. Possibly the Sequencer, and graph/dopesheet for Tracking?

It could be a new editor with two modes. One for setting the time selection which would be easily selected from all other animation editors (Like how ctrl-tab toggles dopesheet/graph, it could be press z to toggle the time range space.), and one for editing time-based data within the selected object/bones, like FCurve modifiers. The second mode is outside the scope of this proposal, though.

With the toggling, I am not sure how you would return.

  • Holding shift while left clicking, then dragging will define the start and end of the range (removes falloff)
  • Being able to select handles and drag with G
  • Select 2 handles by clicking the area between them
  • Holding shift and scrolling the mouse wheel expands the outer handles
  • Draw something similar to the playhead scrubber, but green, that follows the mouse snapping to the nearest snap option. This could also be used for when moving the handles, but the color will be orange instead. The selected handles could show their frame in the scrubber while being moved.

Drawing

  • Draw the range, with a faded gradient.
  • Draw Handles, showing if they’re selected.
  • Draw something that reminds the user when the start or end of the range is equal to, or outside the scene’s start/end. Probably unnecessary, but throwing it out there.
  • Draw the lines for how much influence the selection will have for each frame.

Theming

  • Selected Time Range (A somewhat transparent green.)
  • Selected Handles (Slightly transparent, or fully opaque black.)
  • Selected Time Range Influence Line (Same as Selected Time Range, but allow people to make it different if they choose.)
  • Time Selection Scrubber (An opaque green.)

Exposed data

I’ve heard discussion about having something that could edit time ranges and such, so I’ve attempted to split this in a way that multiple areas in Blender can use it to show time ranges in the future possibly, such as a tool that shows the active FCurve modifier’s time range in the graph editor for easier and more visual editing.

TimeRangeHandle

  • frame : The frame value of the handle.
  • select : Whether or not the handle is selected.

TimeRange

I was thinking of calling it TimelineTimeSelection at first, TimeRange would probably be a more apt name, since it could be applied to more things than just selecting a portion of time in the timeline.

  • handles : A read-only collection of 4 TimeRangeHandles.
  • start : Read-only value for where the range starts, for convenience. Could be moved to the scene data instead. As only the scene time selection will really need this, if at all.
  • end : Similar to above.

Now putting this all together as a selection of time usable in the scene.

scene

  • use_selected_time_influence : User toggle that operators can get to change their behaviour.

scene.selected_time_range or context.selected_time_range

  • range : A pointer property of TimeRange.
  • is_enabled or has_selection : Read-only value that should be set to True when range.start != range.end, for convienience. Probably unneeded.
  • falloff_start_interpolation_mode : The type of interpolation the left falloff should use.
  • falloff_end_interpolation_mode : Same as above for the right.
  • falloff_start_easing_type : The type of easing to use for the left side.
  • falloff_end_easing_type : Same as above for the right.
  • evaluate_frame_influence : A function func(float frame) that returns how much influence that frame/step should have. This should also apply easing and interpolation. Will be useful for when an operator is applying an offset or values to animation data between the range.

Here is an add-on I made to show off how it could function, with the hotkeys and such. It should in no way represent an actual implementation in C code.


Here’s a video showing off how it the add-on functions, and it’s preference options.
It needs some polishing to adhere to Blender’s standards, but I think it’s overkill to try to re-implement Blender’s standards in to a prototype. Would be better spent getting the UI down then implementing the functionality in C in my opinion.

simplescreenrecorder-2020-11-04_23.11.49

9 Likes
2

Really cool proposal. Well laid out.
I am not sure what you mean when you say it needs to be a new mode. As in it would be a modal operator and work similar to setting the preview range?

I think it could work like a gizmo:
[Shift + Click] to Select the time range.
You’ll then get handles that you can select and drag around to change the time range and falloff.
There could be a toggle (like with the preview range) where you can quickly disable the selection while saving it.
You’d deselect range by Shift + Clicking the time selector.
Here is a quick mockup

time_selection_proposal
time_selection_proposal774×600 36.8 KB

Pros:
Quick to access
Selection works similar to the rest of blender. Click selects a single point in time, Shift+Click selects multiple.

Cons:
Deselection works differently. When Clicking on a thing in Blender, this thing is the only thing selected. Here Clicking would just move the current frame around
How would this be discovered? I think it would be quite hard for the user to find

Questions:
Can there be multiple selected ranges?

3

I think we can use the “preview range” which is created by pressing P , because its really underused we could do so many things with this.

4

Thank you!

In my post, I had meant a new mode similar to how dopesheet has action editor, dopesheet, shapekey editor, etc. I am very much against a new mode in that way the more I think about it though, as that would have to be added to every space’s dropdown for changing modes and it would also be cumbersome.
Especially since some spaces don’t have that type of mode changing at all currently.
A new space I am still somewhat interested in. It might not be worth it though, and this next idea could work instead.

It could be a new mode similar to how you would choose between vertices/edges/face in model edit mode. Using 1/2 to swap between manipulating keyframes/time ranges.
manipulation_pick_mockup
Would this help with discovery?
Also while in this mode, if there isn’t a selected area of time, it could always show the green scrubber under the mouse, instead of having to hold shift.
That way the user has some sort of feedback from the UI after the change in modes.
While not in this mode, the user could still be able to [ Shift+LeftDrag ] in the scrubber area to set a time selection range.

I had thought about something similar to your gizmo idea early on, but I had dismissed it as I felt as it would be annoying to be forced to click a small area like that.
You came up with something much better than I had though, and I think it would work as an alternative for making quick edits to the range. So you wouldn’t have to switch modes. Would love making sure that there’s options to do things.
It also fixes the issue of the outer handles being hidden when on top of the inner handles by always displaying something for them.

For the gizmo:
I think ditching selection entirely would be better.
Add a handle on the left or bottom that moves the entire thing.
Clicking the line or area between 2 handles will drag those handles.

mockup_time_selection_gizmo_00
mockup_time_selection_gizmo_00950×126 5.92 KB

This drops being able to move three handles at once with the gizmo, but I think switching to the time range mode should be used instead at that point.

Off-topic suggestion: With Looch bringing up the preview range, I think your gizmo could be modified to be used for the that as well, which could also use [ Ctrl+LeftDrag ] in the scrubbing area to define its range. [ P ] is a very annoying shortcut to use in my opinion.
The prototype addon has an option to enable syncing the preview range to the selected time range, which could be a faster way of setting that up if you needed something like that.

“Can there be multiple selected ranges?”
I don’t see why not, I can’t think of much use for that though.
[ Shift + LeftDrag ] Could create a new range, and [ X ] can delete them.
Pros:
It would be faster to do the same type of modifications on varying points within the timeline.

Cons:
The user would have to remember that they made a selection earlier in the timeline, which could be outside the viewport, if they’re working on something later in the timeline.

3 Likes
5

I like it. Logic Pro has a toolset for retiming audio and midi tracks that is super intuitive and not completely unlike what you’re proposing here. It might be worth checking out.

6

My observation:
Correct me if I’m wrong but it feels that frame-base and time-base are parallel concepts, if you think of frames as coarsely-quantised time?
This proposal to me shouts ‘factorise’; if you have to make a ‘timeline’ engine which edits in time-sequences, then just add the existing frame functionality as a seamlessly managed coarse-grained subset. One interface can thus ‘rule them all’.

Thinking about this raises a point: frames are frequently looped and reversed, animators are used to using the same deck of image cels for multiple effects; in the playback domain these cel sequences are ‘unrolled’ to occupy their true place in the visual story. An editor which itself understood this workflow and made these time/frame relationships explicit would not only be intuitive to existing artists but a great help in bringing new talent onboard.
With my experienced software hat on, this predicts less work than shoehorning in a separate time editor, then inevitably spending forever trying to reconcile user interface confusion across different mindsets, not to mention internal resource contention and complexity with two engines doing the same thing at the same time.
Hope this helps with what sounds like a very good proposal.

7

I actually really like the idea of keyframe vs time selection you proposed. It feels like the Blender way to do it and is super fast to access with the 1 and 2 hotkeys. In this mode you’d not need to click on the scrubbing area, but just anywhere in the timeline, correct? So you can’t select keyframes. Something to keep in mind, but it doesn’t bother me since it’s clear enough to the user.

I think multiple ranges and setting the preview range kind of conflicts unless the preview range is still a separate concept. Unless if you have two preview ranges and playback hits the end of the first one, it jumps to the start of the second one. But that might be too crazy

@OookLout Not sure if I understand you correctly but the idea of cels doesn’t quite work with keyframes. Even though instanced keyframes would be interesting what you usually do for reusing animation is the NLA editor.

8

A more correct name for this would be Frame Range Selection, which would be consistent with what’s already in Blender. Like FCurve Modifier’s Restrict Frame Range.
Should I update the first post to correct this? After looking at Restrict Frame Range, should falloff_start/falloff_end be changed to in/out to match with already existing naming?

@OookLout

There would be no new engine, just a way to allow people to select a range of time, or rather from frame x to frame y. Which can then be used to add/edit/remove keyframes within the selection.

@ChristophLendenfeld
Correct, you would click anywhere in the region to modifiy the selected frame ranges and yes, it would block keyframe selection. The preview range would still be separate.

Some ideas on preview syncing, If using multiple Frame Range Selections then when “automatically sync preview range” is active it would either go from the start of the first selection to the end of the last selection, or sync to the active selection. Preferably an option to use either.

I think that the preview range could be kept inside the scrubber using [ Ctrl + LeftDrag ] to activate the Set Preview Range operator in either mode. This can actually be done already by modifying the keymap for “Time Scrub” (Not exposed in the UI).

Here’s a video where I show off the normal call for the operator, the keymap edit for Time Scrub, and then how it could improve with some UI tweaking, so it’s not a selection box.

set_preview_range

Here’s some ideas for changing the keymap. These would work in either mode.
Assuming setting the preview range is changed to [ Ctrl + LeftDrag ] in the Time Scrub keymap and Frame Range Selection is implemented.

[ P ] can be replaced with “Toggle Sync Preview Range to Frame Range Selection”
[ Alt + P ] toggles between use multiple frame ranges when syncing the preview range or just the active frame range.
[ Alt + C ] would be a pie menu that chooses between

  • Clear Active Frame Range Selection
  • Clear all Frame Range Selections
  • Clear Preview Range

Moving Set/Clear Preview from [ P ] makes it so the user doesn’t have to take their hand off the mouse and should be faster, though this brings back the hard for discovery concern. Unless the user happens to see “Set Preview Range” in the “View” menu and then looks at the documentation. I also don’t know where to put “Auto-Set Preview Range”, [ Ctrl + Alt + P ], so it can just stay there I suppose.