Skip to content

Blender 4.4: Animation & Rigging

Slotted Actions

The icon for Action Slots

The structure of Actions has changed, introducing the concept of Slots (43d7558e5b). In short, slots make it possible to store the animation of multiple "things" into the same Action.

Action editor, showing one Action with two Slots, one for the Camera Object and one for the Camera Data. You can distinguish them by the icon on the right-hand side of the channel list. The camera is both moving and zooming in.

Examples of slotted Actions use:

  • Mesh objects: location in the scene (object), together with shape key values (belongs to the object data), and the locations of 'hook' empties (different objects).
  • Camera objects: transform (object) and lens parameters (object data).
  • Metaball transforms, where all objects in a group of metaballs can share the same Action.
  • Materials, which effectively consist of two data-blocks (the Material itself, and its shader node tree).

As a result of this change:

  • All newly created Actions will be slotted Actions.
  • Actions loaded from disk will be versioned to slotted Actions.
  • A new Python API for slots, layers, strips, and channel bags is available.
  • A legacy Python API for accessing F-Curves and Action Groups is still available, and will operate on the F-Curves/Groups for the first slot only.
  • Creating an Action by keying (via the UI, operators, or the rna_struct.keyframe_insert function) will try and share Actions between related data-blocks. See #126655: Anim: Reuse action between related data for more info about this.
  • Assigning an Action to a data-block will auto-assign a suitable Action Slot. The logic for this is described below. However, There are cases where this does not automatically assign a slot, and thus the Action will effectively not animate the data-block. Effort has been spent to make Action selection work both reliably for Blender users as well as keep the behaviour the same for Python scripts. Where these two goals did not converge, reliability and understandability for users was prioritised.

Auto-selection of the Action Slot upon assigning the Action works as follows. The first rule to find a slot wins.

  1. The data-block remembers the slot name that was last assigned. If the newly assigned Action has a slot with that name, it is chosen.
  2. If the Action has a slot with the same name as the data-block, it is chosen.
  3. If the Action has only one slot, and it has never been assigned to anything, it is chosen.
  4. If the Action is assigned to an NLA strip or an Action constraint, and the Action has a single slot, and that slot has a suitable ID type, it is chosen.

This last step is what I was referring to with "Where these two goals did not converge, reliability and understandability for users was prioritised." For regular Action assignments (like via the Action selectors in the Properties editor) this rule doesn't apply, even though with legacy Actions the final state ("it is animated by this Action") differs from the final state with slotted Actions ("it has no slot so is not animated"). This is done to support the following workflow:

  • Create an Action by animating Cube.
  • In order to animate Suzanne with that same Action, assign the Action to Suzanne.
  • Start keying Suzanne. This auto-creates and auto-assigns a new slot for Suzanne.

If rule 4. above would apply in this case, the 2nd step would automatically select the Cube slot for Suzanne as well, which would immediately overwrite Suzanne's properties with the Cube animation.

Note that 'slotted Actions' and 'layered Actions' are the exact same thing, just focusing on different aspects (slot & layers) of the new data model.

The following limitations are in place: - an Action can have zero or one layer, - that layer can have zero or one strip, - that strip must be of type 'keyframe' and be infinite with zero offset.

For more information on slotted Actions, see Multi Data-Block Animation.