WIP: Animation: Select Grouped operator #104758

Revival of D14811

Closes #86180 for the Dopesheet, Graph and NLA editors

Supports filtering in multiple datablocks, and takes the properties from all selected keyframes/strips into account (similar to how this operator works in the 3D view).

Each operation can also be filtered to only apply to the currently selected channels, as opposed to all visible channels.

The code is a bit sub-optimal, due to how KeyframeEditData works, but from my testing it seems to work fine.

Currently doesn't handle the Dopesheet modes Grease Pencil, Mask and Cache File (simply de-selects all keyframes).

For animators interested in trying this out, here are short descriptions of all the available operations:

Dopesheet

Channel Type: Select keyframes based on the "kind" of a channel. E.g. all "Location" or all "Scale" keyframes.
Channel Type (Strict): Same as "Channel Type", but also checks that the axis matches (X/Y/Z).
Key Type: Select keyframes based on its color (breakdown, extreme, etc.).
Interpolation Type: Select keyframes based on interpolation mode (constant, bezier, etc.)
Handle Type: Select keyframes based on handle type (vector, automatic, etc.). In Graph Editor, the left/right handles can be selected separately here.
Modifiers: Select keyframes based on which FCurve modifiers the channel has. This is done by checking which modifier types exist, and ensuring all of them match (so Cyclic ≠ Noise ≠ Cyclic+Noise).
Datablock: Select keyframes which belong to the same datablock (similar to "Select All", but only based on your current selection).

Graph Editor

All of Dopesheet's operations, but also:

Handle Side: Select keyframes based on which handle sides are selected (left or right).

NLA

Blending: Select all strips that use the same blending mode (replace, combine, add, etc.).
Action: Select all strips that use the same action datablock (linked duplicates).
Extrapolation: Select all strips that use the same extrapolation mode (hold, hold forward, etc.).
Reversed: Select all strips that have the same value for the reserved checkbox.
Muted: Select all strips that have the same value for the muted checkbox.
Datablock: Select all strips belonging to the same datablock (similar to "Select All", but only based on your current selection).

Slightly outdated videos of the operator below:

Revival of [D14811](https://archive.blender.org/developer/D14811) Closes #86180 for the Dopesheet, Graph and NLA editors ----- Supports filtering in multiple datablocks, and takes the properties from all selected keyframes/strips into account (similar to how this operator works in the 3D view). Each operation can also be filtered to only apply to the currently selected channels, as opposed to all visible channels. The code is a bit sub-optimal, due to how KeyframeEditData works, but from my testing it seems to work fine. Currently doesn't handle the Dopesheet modes Grease Pencil, Mask and Cache File (simply de-selects all keyframes). ----- For animators interested in trying this out, here are short descriptions of all the available operations: ## Dopesheet - **Channel Type**: Select keyframes based on the "kind" of a channel. E.g. all "Location" or all "Scale" keyframes. - **Channel Type (Strict)**: Same as "Channel Type", but also checks that the axis matches (X/Y/Z). - **Key Type**: Select keyframes based on its color (breakdown, extreme, etc.). - **Interpolation Type**: Select keyframes based on interpolation mode (constant, bezier, etc.) - **Handle Type**: Select keyframes based on handle type (vector, automatic, etc.). In Graph Editor, the left/right handles can be selected separately here. - **Modifiers**: Select keyframes based on which FCurve modifiers the channel has. This is done by checking which modifier types exist, and ensuring all of them match (so Cyclic ≠ Noise ≠ Cyclic+Noise). - **Datablock**: Select keyframes which belong to the same datablock (similar to "Select All", but only based on your current selection). ## Graph Editor All of Dopesheet's operations, but also: - **Handle Side**: Select keyframes based on which handle sides are selected (left or right). ## NLA - **Blending**: Select all strips that use the same blending mode (replace, combine, add, etc.). - **Action**: Select all strips that use the same action datablock (linked duplicates). - **Extrapolation**: Select all strips that use the same extrapolation mode (hold, hold forward, etc.). - **Reversed**: Select all strips that have the same value for the reserved checkbox. - **Muted**: Select all strips that have the same value for the muted checkbox. - **Datablock**: Select all strips belonging to the same datablock (similar to "Select All", but only based on your current selection). ----- Slightly outdated videos of the operator below:

nla_select_grouped.mp4

355 KiB

blender_xG2RmGt7rf_an.mp4

796 KiB

graph_select_grouped.mp4

597 KiB

Thanks! I've put this on the agenda for today's module meeting.

The code is a bit sub-optimal, due to how KeyframeEditData works, but from my testing it seems to work fine.

What is sub-optimal, exactly? Is there something you need help with? Is it a software design issue, or more an implementation issue?

Thanks! I've put this on the agenda for today's module meeting. > The code is a bit sub-optimal, due to how KeyframeEditData works, but from my testing it seems to work fine. What is sub-optimal, exactly? Is there something you need help with? Is it a software design issue, or more an implementation issue?

@dr.sybren I'll see if I get the time to join today. There's some ideas and design questions I'd like to discuss.

What is sub-optimal, exactly? Is there something you need help with?

I'm not a C developer, so the entire way the code is structured feels a bit hacked together to me.

There's large amounts of code duplication between the Dopesheet and Graph Editor operator. I don't know where to put this kind of shared code.
Since most other animation operators are also just copy-pasted between these files (with TODO comments hinting at that), I can't find any existing operator to take as reference there.

If you believe it is fine to keep it like this initially, and possibly refactor it later, then I won't object.

@dr.sybren I'll see if I get the time to join today. There's some ideas and design questions I'd like to discuss. > What is sub-optimal, exactly? Is there something you need help with? I'm not a C developer, so the entire way the code is structured feels a bit hacked together to me. There's large amounts of code duplication between the Dopesheet and Graph Editor operator. I don't know where to put this kind of shared code. Since most other animation operators are also just copy-pasted between these files (with TODO comments hinting at that), I can't find any existing operator to take as reference there. If you believe it is fine to keep it like this initially, and possibly refactor it later, then I won't object.

@blender-bot package

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR104758) when ready.

@dr.sybren I'll see if I get the time to join today. There's some ideas and design questions I'd like to discuss.

👍

I'm not a C developer, so the entire way the code is structured feels a bit hacked together to me.

There's large amounts of code duplication between the Dopesheet and Graph Editor operator. I don't know where to put this kind of shared code.
Since most other animation operators are also just copy-pasted between these files (with TODO comments hinting at that), I can't find any existing operator to take as reference there.

Ok, I'll keep that in mind when reviewing. Maybe me, @ChrisLend or @nrupsis can help with this.

> @dr.sybren I'll see if I get the time to join today. There's some ideas and design questions I'd like to discuss. :+1: > I'm not a C developer, so the entire way the code is structured feels a bit hacked together to me. > > There's large amounts of code duplication between the Dopesheet and Graph Editor operator. I don't know where to put this kind of shared code. > Since most other animation operators are also just copy-pasted between these files (with TODO comments hinting at that), I can't find any existing operator to take as reference there. Ok, I'll keep that in mind when reviewing. Maybe me, @ChrisLend or @nrupsis can help with this.

Needs to handle Channel Type better (currently breaks for deeper RNA paths, like bones).

Also have some open design questions in #86180 that need attention first.

(I dont have permissions to request changes on my own PR?? 🤯)

Needs to handle Channel Type better (currently breaks for deeper RNA paths, like bones). Also have some open design questions in #86180 that need attention first. (I dont have permissions to request changes on my own PR?? 🤯)

(I dont have permissions to request changes on my own PR?? 🤯)

You can't, who would you request it to?

You can mark the PR as "work in progress" though. The "Still in progress? Add WIP: prefix" link in the sidebar is a convenient way to do that.

> (I dont have permissions to request changes on my own PR?? 🤯) You can't, who would you request it to? You can mark the PR as "work in progress" though. The "Still in progress? Add WIP: prefix" link in the sidebar is a convenient way to do that.

You can't, who would you request it to?

I mean this:

I believe WIP is meant for "not ready for review", whereas request changes is for "unapproved / not ready to merge".

But it doesn't matter much anyway ^^

> You can't, who would you request it to? I mean this: ![image](/attachments/7465be90-92ac-4cb7-b97b-16c133b71651) I believe WIP is meant for "not ready for review", whereas request changes is for "unapproved / not ready to merge". But it doesn't matter much anyway ^^

image.png

23 KiB

That's exactly my point. When you're planning changes to a PR, and thus it shouldn't be reviewed, marking as WIP is exactly the thing that accomplishes that. It will set the status to "Draft" and it won't (or at least shouldn't) appear on anyone's review queue.

I'm not a C developer, so the entire way the code is structured feels a bit hacked together to me.

I only just looked at the code -- you weren't kidding ;-)
It seems you took inspiration from code in a style we actually want to get rid of.

New operators should IMO be implemented in C++, and this one would likely benefit from that. There certainly is too much duplication going on.

A few general remarks that can help move things forward:

Don't use short when you actually can use a bool. Use true and false and not 1 or 0.
Document what function return values mean.
case blocks do not need {}; those are only necessary if you declare new variables inside the block.

These are relatively minor things though. I think the biggest issue with the code, and that's not something you can do anything about, is that it builds up on a system that we want to get rid of: the animation data filtering system.

Maybe it's better to put this patch on hold for now, until we have a good replacement for that.

> I'm not a C developer, so the entire way the code is structured feels a bit hacked together to me. I only just looked at the code -- you weren't kidding ;-) It seems you took inspiration from code in a style we actually want to get rid of. New operators should IMO be implemented in C++, and this one would likely benefit from that. There certainly is too much duplication going on. A few general remarks that can help move things forward: - Don't use `short` when you actually can use a `bool`. Use `true` and `false` and not `1` or `0`. - Document what function return values mean. - `case` blocks do not need `{}`; those are only necessary if you declare new variables inside the block. These are relatively minor things though. I think the biggest issue with the code, and that's not something you can do anything about, is that it builds up on a system that we want to get rid of: the animation data filtering system. Maybe it's better to put this patch on hold for now, until we have a good replacement for that.

Thanks for the tips @dr.sybren - I probably followed really old code to end up with what I have now haha.

Maybe it's better to put this patch on hold for now, until we have a good replacement for that.

I wouldn't mind this tbh, since there's some kinks to work out regarding the design, and since the feature doesn't seem to be in urgent demand or anything. I'll keep this PR around and can update it in the future.

Thanks for the tips @dr.sybren - I probably followed really old code to end up with what I have now haha. > Maybe it's better to put this patch on hold for now, until we have a good replacement for that. I wouldn't mind this tbh, since there's some kinks to work out regarding the design, and since the feature doesn't seem to be in urgent demand or anything. I'll keep this PR around and can update it in the future.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Labels Milestones

WIP: Animation: Select Grouped operator #104758

Dopesheet

Graph Editor

NLA