Page MenuHome

Design Required: How can users choose what datablock/level to edit in the Action Editor?
Open, NormalPublic

Description

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

  1. 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)
  2. 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.
  3. 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?
  4. 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.

Details

Type
Design

Event Timeline

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

@Joshua Leung (aligorith): 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 @Nathan Vegdahl (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.

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:

  1. 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:
  2. given the previous do they get stored per property or still in some animation_data on their datablock.
  3. f-curves need to have a reference back to their 'owner' more than just the path but also the datablock
  4. is it possible to have f-curves not in any action?

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:

  1. 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.
  2. 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)
  3. given the selection, add it's animation curves to the current action

Based on Dopesheet / action editor:

  1. Add selected channels to an action
  2. Remove selected channels from an action
  3. Create an action from selected channels

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