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

New Issue

Joshua Leung · 2013-11-18T10:21:14+01:00

Joshua Leung commented

2013-11-18 10:21:14 +01:00

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.

Joshua Leung commented

2013-11-18 10:21:15 +01:00

Changed status to: 'Open'

Joshua Leung self-assigned this 2013-11-18 10:21:15 +01:00

Joshua Leung commented

2013-11-18 10:21:15 +01:00

Added subscribers: @JoshuaLeung, @cessen, @BassamKurdali

ronan ducluzeau commented

2013-11-18 11:50:30 +01:00

Added subscriber: @zeauro

ronan ducluzeau commented

2013-11-18 11:50:30 +01:00

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

William Reynish commented

2013-11-18 17:50:45 +01:00

Added subscriber: @billrey

William Reynish commented

2013-11-18 17:50:45 +01:00

@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.

bassam kurdali commented

2013-11-20 19:04:28 +01:00

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?

bassam kurdali commented

2013-11-20 19:11:22 +01:00

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

Răzvan Cosmin Rădulescu commented

2018-11-20 20:16:25 +01:00

Added subscriber: @razcore

Răzvan Cosmin Rădulescu commented

2018-11-20 20:16:25 +01:00

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

Sybren A. Stüvel commented

2019-12-06 13:30:20 +01:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2019-12-06 13:30:20 +01:00

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

RedMser commented

2020-05-22 02:17:55 +02:00

Added subscriber: @RedMser

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

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

Level + Slot Selectors

Mini-Outliner of Available Slots

Defer to Outliner (Proper)

Controlled by DopeSheet

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

Create an action from selected channels