WIP: Animation: Select Grouped operator #104758

Draft
RedMser wants to merge 9 commits from RedMser/blender:animation-select-grouped into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Contributor

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:
Brecht Van Lommel added this to the Animation & Rigging project 2023-02-15 09:53:35 +01:00

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?
Author
Contributor

@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

@blender-bot package
Member

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.
Sybren A. Stüvel added the
Module
Animation & Rigging
label 2023-02-16 18:14:22 +01:00
RedMser closed this pull request 2023-02-16 18:32:11 +01:00
RedMser reopened this pull request 2023-02-16 18:32:17 +01:00
RedMser reviewed 2023-02-16 18:35:24 +01:00
RedMser left a comment
Author
Contributor

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.
Author
Contributor

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

I mean this:

image

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 ^^

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.

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.
RedMser force-pushed animation-select-grouped from eff3619d5d to ead2243a63 2023-02-21 20:50:57 +01:00 Compare
RedMser changed title from Animation: Select Grouped operator to WIP: Animation: Select Grouped operator 2023-02-21 20:51:58 +01:00

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.
Author
Contributor

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.
Sybren A. Stüvel removed this from the Animation & Rigging project 2023-03-14 10:50:02 +01:00
This pull request has changes conflicting with the target branch.
  • scripts/presets/keyconfig/keymap_data/industry_compatible_data.py
  • scripts/startup/bl_ui/space_graph.py
  • source/blender/editors/space_action/action_intern.h
  • source/blender/editors/space_action/action_ops.c
  • source/blender/editors/space_action/action_select.c
  • source/blender/editors/space_graph/graph_intern.h
  • source/blender/editors/space_graph/graph_ops.c
  • source/blender/editors/space_graph/graph_select.c
  • source/blender/editors/space_nla/nla_intern.h
  • source/blender/editors/space_nla/nla_ops.c

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u animation-select-grouped:RedMser-animation-select-grouped
git checkout RedMser-animation-select-grouped
Sign in to join this conversation.
No reviewers
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#104758
No description provided.