Design Required: How can users choose what datablock/level to edit in the Action Editor? #37512

Closed
opened 2013-11-18 10:21:14 +01:00 by Joshua Leung · 14 comments
Member

Current Situation
The Action Editor currently only displays/edits the action slot on the active object. However, there are many situations where it would be handy to be able to edit actions that can be reused on other levels instead (for example, actions for different sets of colour+intensity cycles for lamps - e.g. for a disco scene or something like that).

Problem
1) How do we make it clear to users which level/slot they're editing?

  • For example, with a single Cube selected, we could potentially have Scene, Compositing Nodes, World, Cube Object, Cube's Material 1, Material 1's Texture..., Material 2, ..., Cube Mesh, ShapeKeys, Particle System 1, Particle System 2,..., and perhaps a few others I've overlooked.

2) How do we allow users to select which level + slot they're editing?

  • This naturally follows from the first problem. Basically, if we can display a slot, we can probably try to reuse that mechanism for primitive selection techniques.

Solutions

Level + Slot Selectors

  • This would be similar to what the IPO Editor used to have (http://wiki.blender.org/index.php/File:ManAnimationEditorsIpoWindowDefaultViz.png).
  • Benefit: This is a fairly self-contained approach, and one of the easier ones to implement.
  • Problem 1: This was quite nasty if you selected another object that didn't have the types of data that the previous one had. Then again, the Properties Editor suffers from similar problems too.
  • Problem 2: Also, it didn't really handle things like materials that well (these were accessed using a number box to choose the index being edited)

Mini-Outliner of Available Slots

  • This is a more advanced version of the Level + Slots idea, except that we display a mini tree of available levels that can be edited given the current selection, with the hierarchical relationships between datablocks visible
  • Benefit: This copes better with things like Materials and Particles
  • Benefit: This is still a "self-contained" approach (i.e. each editor doesn't need to know anything about other editors' states)
  • Problem: We'd have to develop a new widget to do this - somewhat hairy in the current UI widget toolkit, but we'd want to do this for RNA Path building anyway
  • Problem: We'd end up with a semi-blocking/overlapping view that users have to interact with everytime they hunt for this info.

Defer to Outliner (Proper)

  • Instead of creating our own outliner tree and using a localised pointer, we just defer these capabilities to the main Outliner. Thus, clicking on Action Slots there (or just the Animation Data entries) tells the Action Editor where it needs to be.
  • Benefit: Potentially simpler for users who just expect applications to be monolithic blobs where every single view cooperates with every other view to present a single editing state/context
  • Problem: What happens when we've got multiple of each type of window, and we want to have separate views in each?

Controlled by DopeSheet

(From an old suggestion by @venomgfx) The Action Editor can only be entered via DopeSheet. Double-clicking on a channel there opens Action Editor for just that action+level (i.e. in effect it filters the visible channels to just those in that action). When selected object changes or we exit action editor (i.e. back to dopesheet), the slot/level pointer stuff gets reset and/or the Action Editor simply becomes unavailable.

**Current Situation** The Action Editor currently only displays/edits the action slot on the active object. However, there are many situations where it would be handy to be able to edit actions that can be reused on other levels instead (for example, actions for different sets of colour+intensity cycles for lamps - e.g. for a disco scene or something like that). **Problem** *1) How do we make it clear to users which level/slot they're editing?* - For example, with a single Cube selected, we could potentially have Scene, Compositing Nodes, World, Cube Object, Cube's Material 1, Material 1's Texture..., Material 2, ..., Cube Mesh, ShapeKeys, Particle System 1, Particle System 2,..., and perhaps a few others I've overlooked. *2) How do we allow users to select which level + slot they're editing?* - This naturally follows from the first problem. Basically, if we can display a slot, we can probably try to reuse that mechanism for primitive selection techniques. **Solutions** # **Level + Slot Selectors** - This would be similar to what the IPO Editor used to have (http://wiki.blender.org/index.php/File:ManAnimationEditorsIpoWindowDefaultViz.png). - *Benefit:* This is a fairly self-contained approach, and one of the easier ones to implement. - *Problem 1:* This was quite nasty if you selected another object that didn't have the types of data that the previous one had. Then again, the Properties Editor suffers from similar problems too. - *Problem 2:* Also, it didn't really handle things like materials that well (these were accessed using a number box to choose the index being edited) # **Mini-Outliner of Available Slots** - This is a more advanced version of the Level + Slots idea, except that we display a mini tree of available levels that can be edited given the current selection, with the hierarchical relationships between datablocks visible - *Benefit:* This copes better with things like Materials and Particles - *Benefit:* This is still a "self-contained" approach (i.e. each editor doesn't need to know anything about other editors' states) - *Problem:* We'd have to develop a new widget to do this - somewhat hairy in the current UI widget toolkit, but we'd want to do this for RNA Path building anyway - *Problem:* We'd end up with a semi-blocking/overlapping view that users have to interact with everytime they hunt for this info. # **Defer to Outliner (Proper)** - Instead of creating our own outliner tree and using a localised pointer, we just defer these capabilities to the main Outliner. Thus, clicking on Action Slots there (or just the Animation Data entries) tells the Action Editor where it needs to be. - *Benefit:* Potentially simpler for users who just expect applications to be monolithic blobs where every single view cooperates with every other view to present a single editing state/context - *Problem:* What happens when we've got multiple of each type of window, and we want to have separate views in each? # **Controlled by DopeSheet** (From an old suggestion by @venomgfx) The Action Editor can only be entered via DopeSheet. Double-clicking on a channel there opens Action Editor for just that action+level (i.e. in effect it filters the visible channels to just those in that action). When selected object changes or we exit action editor (i.e. back to dopesheet), the slot/level pointer stuff gets reset and/or the Action Editor simply becomes unavailable.
Author
Member

Changed status to: 'Open'

Changed status to: 'Open'
Joshua Leung self-assigned this 2013-11-18 10:21:15 +01:00
Author
Member

Added subscribers: @JoshuaLeung, @cessen, @BassamKurdali

Added subscribers: @JoshuaLeung, @cessen, @BassamKurdali

Added subscriber: @zeauro

Added subscriber: @zeauro

What you are talking about looks like keying sets. I never undertsood why animation editors could not display a keying set action.

What you are talking about looks like keying sets. I never undertsood why animation editors could not display a keying set action.

Added subscriber: @billrey

Added subscriber: @billrey

@JoshuaLeung: Nice topic.

Currently the Action Editor and Dopesheet displays the active object in it. In Presto @ Pixar it's the other way around: The animator adds channels to be animated, and those are the channels that shows up in the editor, not the channels of the selected object.

This also relates to what @cessen often talked about, which is the 'F-Curve-bag' concept. With such a concept, the user could specify a group of F-curves that might be considered to be relaed, and to have the editor display those, irespective of which datablocks they belong to. This is considered superior to the current 'Action' concept because Actions currently can't span multiple datablocks. With the F-Curve-Bag concept, in your example of disco lights, you could just create an F-Curve bag of those channels and work with them as a single action.

@JoshuaLeung: Nice topic. Currently the Action Editor and Dopesheet displays the active object in it. In Presto @ Pixar it's the other way around: The animator adds channels to be animated, and those are the channels that shows up in the editor, not the channels of the selected object. This also relates to what @cessen often talked about, which is the 'F-Curve-bag' concept. With such a concept, the user could specify a group of F-curves that might be considered to be relaed, and to have the editor display those, irespective of which datablocks they belong to. This is considered superior to the current 'Action' concept because Actions currently can't span multiple datablocks. With the F-Curve-Bag concept, in your example of disco lights, you could just create an F-Curve bag of those channels and work with them as a single action.
Member

f-curve bag idea used to be called IPObag :D I'll just call these actions, where actions 'own' a list of channels, rather than datablocks 'owning' an action.

From a usability perspective, actions owning channels might be nicer than datablocks owning actions.
Some questions:

  • animation curves are still associated with properties on datablocks. Do they also 'live' there outside any action, with the possibility of being in one or more ? and if they do:
  • given the previous do they get stored per property or still in some animation_data on their datablock.
  • f-curves need to have a reference back to their 'owner' more than just the path but also the datablock
  • is it possible to have f-curves not in any action?
f-curve bag idea used to be called IPObag :D I'll just call these actions, **where actions 'own' a list of channels, rather than datablocks 'owning' an action.** From a usability perspective, actions owning channels might be nicer than datablocks owning actions. Some questions: - animation curves are still associated with properties on datablocks. Do they also 'live' there outside any action, with the possibility of being in one or more ? and if they do: - given the previous do they get stored per property or still in some animation_data on their datablock. - f-curves need to have a reference back to their 'owner' more than just the path but also the datablock - is it possible to have f-curves not in any action?
Member

Now that I've asked some questions, time to tackle some of the OPs :)

If the action editor / actions get decoupled from selection, they just get promoted to a top level data block,

DopeSheet becomes for 'general' editing where selection in the 3D view can restrict the channels shown (as now)

Action Editor works to edit a specific action, not the active selection any more. Some handy operators could be:
Based on selection:

  • given the selection, display (possibly picking from a list if there are more than one) related actions (i.e. actions containing channels of properties on those selections) in the action editor.
  • given the selection, create a new action with curves for all it's properties that are animated (maybe allow granularity here for bones vs. objects)

given the selection, add it's animation curves to the current action

Based on Dopesheet / action editor:

  • Add selected channels to an action
  • Remove selected channels from an action

Create an action from selected channels

Now that I've asked some questions, time to tackle some of the OPs :) If the action editor / actions get decoupled from selection, they just get promoted to a top level data block, DopeSheet becomes for 'general' editing where selection in the 3D view *can* restrict the channels shown (as now) Action Editor works to edit a specific *action*, not the active selection any more. Some handy operators could be: Based on selection: - given the selection, display (possibly picking from a list if there are more than one) related actions (i.e. actions containing channels of properties on those selections) in the action editor. - given the selection, create a new action with curves for all it's properties that are animated (maybe allow granularity here for bones vs. objects) # given the selection, add it's animation curves to the current action Based on Dopesheet / action editor: - Add selected channels to an action - Remove selected channels from an action # Create an action from selected channels

Added subscriber: @razcore

Added subscriber: @razcore

Wow... this was opened in 2013 and here I was just trying to understand why there's no action created when I insert keyframes for say bezier curve data block level (instead of object). As per the comments above from bassam, best case (from user perspective) would be to be able to define curves/channels for properties detached from datablocks and then to be able to apply them to objects. This makes the most sense, while the other original ideas, I feel solve the problems more from a programmer perspective rather than the artist. As an artist would be a bad time to have to keep track of all the levels and to have to constantly switch between them. I'm not artist, I'm a programmer rather, but I've played lately with some motion graphics idea in blender 2.8 and out of all things so far that I've touched (I looked at pretty much everything, including modeling, sculpting, vse etc.) it seems to me that the dope sheet/action editor and NLA are easily the most unfriendly parts of blender.

edit
as a secondary idea how about creating actions that includes anything below the "normal user" interaction level.

So say a user makes a cube object. The action then will include all properties including & below the object level (object, mesh, material, anything that is a child of object basically). This I assume could also work for say nodes in the node editor, where there's nothing below the node itself. The action editor will still filter out the channels/keys for the selected object and will be attached to the object, but instead of showing only object level properties it will show everything that is object level + children level. Just a thought

Wow... this was opened in 2013 and here I was just trying to understand why there's no action created when I insert keyframes for say bezier curve data block level (instead of object). As per the comments above from bassam, best case (from user perspective) would be to be able to define curves/channels for properties detached from datablocks and then to be able to apply them to objects. This makes the most sense, while the other original ideas, I feel solve the problems more from a programmer perspective rather than the artist. As an artist would be a bad time to have to keep track of all the levels and to have to constantly switch between them. I'm not artist, I'm a programmer rather, but I've played lately with some motion graphics idea in blender 2.8 and out of all things so far that I've touched (I looked at pretty much everything, including modeling, sculpting, vse etc.) it seems to me that the dope sheet/action editor and NLA are easily the most unfriendly parts of blender. *edit* as a secondary idea how about creating actions that includes anything below the "normal user" interaction level. So say a user makes a cube object. The action then will include all properties including & below the object level (object, mesh, material, anything that is a child of object basically). This I assume could also work for say nodes in the node editor, where there's nothing below the node itself. The action editor will still filter out the channels/keys for the selected object and will be attached to the object, but instead of showing only object level properties it will show everything that is object level + children level. Just a thought

Added subscriber: @dr.sybren

Added subscriber: @dr.sybren

I'm moving this task from the 'Planned/Scheduled' to the 'Needs Further Planning' workboard, as there is no plan or schedule.

I'm moving this task from the 'Planned/Scheduled' to the 'Needs Further Planning' workboard, as there is no plan or schedule.
Contributor

Added subscriber: @RedMser

Added subscriber: @RedMser
Philipp Oeser removed the
Interest
Animation & Rigging
label 2023-02-09 14:36:52 +01:00

closing since we will design a new UI for the new animation datablock: #113331: Anim: UI design for layered animation

closing since we will design a new UI for the new animation datablock: [#113331: Anim: UI design for layered animation](https://projects.blender.org/blender/blender/issues/113331)
Blender Bot added
Status
Archived
and removed
Status
Confirmed
labels 2023-10-06 12:01:11 +02:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
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
Asset Browser Project
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
8 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#37512
No description provided.