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


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

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.


  1. Level + Slot Selectors - This would be similar to what the IPO Editor used to have (
    • 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 @Pablo Vazquez (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.



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