Multi Data-block Animation

This thread is here to provide animators with information about how to test the new multi data-block animation. This is the first phase of the multi-layered animation project.

Multi Data-block Animation

Some animation sequences rely heavily on the interaction between multiple characters (e.g., a hug scene), multiple objects (someone drinking their morning coffee), or even multiple data-blocks (stage lights synced with a dancer performance).

To improve this workflow, a new system was devised where an Action data-block can contain the animation of different data-blocks (see Animation Slots below).

Animation Slots

Similarly to material slots, an Action can now have multiple slots, each one used by a different character (or data-block).

How to Test

  • Download, install, and run the PR122500 test build.
  • Go to Preferences → Experimental and enable ‘Multi-Slot Actions’.
  • Save your preferences now, as your testing might crash Blender later.

What to Test

Animation sequences that require the interaction between multiple data-blocks.

What Should Work

  • Create a new Action by keying something: This can be done pressing I in the 3D viewport, or when hovering over a property in some panel.
  • Create a new Slot: in the Action editor, assign an already-existing Action to the active Object, then create a key. This should create a new slot for that object.
  • Assign an Action for Object Data: Select a Camera object and animate it. Then go to its Camera Data properties, assign the same Action that already animated the camera object, and animate one of the camera data properties. This should create a new Slot for the Camera Data in the same Action.
  • Deleting keys: should work by right-clicking on a yellow property & choosing ‘Delete Keyframe’. Also in the Dope Sheet and Graph Editors this should work.
  • Convert a Legacy Action: Append an existing Action from another file into your test file. In the Dope Sheet, press F3, search for ‘convert’, then run the ‘Convert Legacy Action’ operator. This should create a new Action {Action Name}_legacy that gets auto-assigned to the active object.

What Does Not Work

  • No Grouping of F-Curves: there are no F-Curve groups yet, so no grouping by bone name, or ‘Object Transforms’ or those things.
  • No ‘Show Only Selected’ in pose mode: because there are no F-Curve groups for bones, this feature also doesn’t work.
  • No NLA support: just don’t test with the NLA right now, it’s not going to make anyone happy.
  • Add-ons not specifically made for the new system: these won’t work. There will be a compatibility layer, but that’s simply not there yet.

What Is Unknown

It’s unknown how various animation tools are going to work. Operators in the Graph Editor and Dope Sheet should work, but may not. Please list operators that you have tested, and whether they worked or not. Because also the thing working should be tracked (because then it doesn’t have to be tested again).

Feedback

Share your impressions, any issues you may had, which workarounds you resorted to, and eventual showstoppers you found.

Ah, and please post your tests/work here. This helps to anchor your feedback (besides being very satisfying to the development team to see the tools in use :).

10 Likes

The demo from today’s meeting looked really promising!

Filter flipping

The branch is currently adding another keyframe filter called “Show All Slots”. I think it was Paolo who raised a concern that it’s a bit confusing how different filters “exclude” or “include” more curves when they are toggled on, so, let’s consider some UI boolean inversions.

Filters in the manual: Navigating - Blender 4.3 Manual

Option A: Leave as is, can’t decidedly improve.

Option B: True means Exclude - Invert these two filters:
“Show All Slots” → “Show Only Object Slots”
“Show Hidden” → “Show Only Visible”

But then all the type filters are still the wrong way around, and those can’t really be inverted, because changing “Include Scene Keys” to “Show Only Non-Scene Keys” is terrible.

Option C: True means Include - Invert these two filters:
“Only Show Errors” → “Show Curves Without Errors”
“Only Show Selected” → “Show Unselected”

That doesn’t conflict with the type filters, but the names are super awkward.

Note that inverting the behaviours themselves (rather than just the UI toggles) would result in “Include Errors” and “Include Selected” buttons, which are totally useless if you think about it. You couldn’t filter out unselected bones, and you couldn’t isolate broken drivers.

So, my preference for now is A > C > B. I’m in the “it is what it is” camp.
But I would change the order of the filters in the UI from
slots, selected, hidden, errors
to
slots, hidden, (separator), selected, errors


Properties UI clutter
The branch aims to solve the issue that the actions assigned to any datablock other than an object isn’t visible anywhere in the UI. Currently it’s doing this by adding an “Animation” panel in the Properties Editor for all datablock panels, since all datablocks can be animated.
I personally already find the Properties Editor overwhelming enough to use add-ons to hide various panels to reduce the UI clutter. The Render tab of stock Blender is the worst offender, full of top level panels with 1 or 2 properties inside.
So to avoid contributing to what I perceive as a problem, I propose to consolidate the action and slot assignment of the active object and its sub-IDs elsewhere, unless this Animation panel can be populated with many more properties.

Idea 1: Existing Anim Editors
The Action editor’s header is already where the active object’s animation is assigned, so it’s not a reach to try and put sub-ID action and slot assignments somewhere here as well. Probably not the header though.
The channel list already displays Actions. In fact, you can even rename an Action from there. So, all it would take is making that into an ID selector. Which I’m sure would involve a bit of UI code and design, since the channel list is much smaller than an ID selector.

Idea 2: Outliner
A bit more radical. The Outliner isn’t an animation editor and it’s not a property editor. But it is kind-of a property editor, since the things on the right side are properties. Having the action/slot of objects there would provide a really nice overview of who’s animated by what. Obviously, this will make the Outliner cluttered, when it’s enabled.
I prefer the first idea.


Those are some early thoughts, thanks for reading!

2 Likes

Thanks!

Filter flipping

So, my preference for now is A > C > B. I’m in the “it is what it is” camp.
But I would change the order of the filters in the UI from
slots, selected, hidden, errors
to
slots, hidden, (separator), selected, errors

Thanks for the analysis. Your suggestion (A + the reordering) looks good to me too. I’d love more feedback on this from animators though, before we really decide.

Properties UI clutter

I propose to consolidate the action and slot assignment of the active object and its sub-IDs elsewhere, unless this Animation panel can be populated with many more properties.

There are also animatable IDs that wouldn’t map to “active object + sub-IDs”, like Scene and World.

Idea 1: Existing Anim Editors

The channel list already displays Actions. In fact, you can even rename an Action from there. So, all it would take is making that into an ID selector.

This could work, but then you’d also have to have a slot selector in there as well. If it were limited to the active object, a ‘use this slot’ button + indicator of the assigned slot could work, but it’ll get hairy once you throw in things like Mesh animation, ShapeKey animation, Material animation, etc.

Idea 2: Outliner

Having the action/slot of objects there would provide a really nice overview of who’s animated by what.

This might work for objects and their data, but I’m not sure if it’s really going to be handy. Also (apart from visibility) you don’t animate values there so much, whereas animating them in the properties panel is more common. Because of that, and because ‘the assigned Action+Slot’ are also properties of the data-block, I figured the properties editor would be the right place to have this selector.

Thanks for your thoughts!

1 Like

First of all, take my love.

  • Gotta be honest I struggled a bit to put camera_obj and camera_data in the same action. Problem was I would animate camera_obj, go to properties and hit I on focal length, and go searching for keys in action editor. It took me a while to realize that by default it was creating it’s own action.

I hated that. I think while new actions are very generic in a sense, we should account for most common cases in user experience. I don’t think anybody would want (by default) to put object and object data animations in different actions. So I think there should be a logic that puts object and object data in the same action always, regardless of which was animated first (same should go for shape keys). In future we can put them in different layers to keep separation.

  • Talking about sad state of shape keys, there is no animation panel in Shape Keys panel… so you can’t assign slot there, so it creates new action always and can’t be combined with obj and obj_data. To avoid this I suggest ALWAYS treat shape keys as regular mesh properties and put them in whatever action mesh has (or curve or lattice).

  • We talked about this and its documented so its not new, but for other people who might be interested: There should be scene-level “Active Action” picker so that you can just freely keep hitting I and put everything in the same action. Changing slots and actions takes a while and is not comfortable workflow. I would go as far to say when first action is created in the scene it should become active by default.

  • I animated camera and camera_data in the same action, assigned that to second camera and two problems there:
    1 - I expected that second camera would just inherit the entire animation just by having same action, but of course it didn’t. Its obvious to me why that is the case, but again I think there should be “protection” in case of such common workflows, such as: When existing action is assigned to object, create new slots for it (if applicable). Detecting when to create those slots is gonna be mighty difficult task, so I don’t know. Just throwing stuff.
    2 - When I duplicated that action second camera inherited animation of first camera, but second camera_data didn’t inherit animation of first camera_data.

I also think UI could be improved, but don’t have anything to propose yet.

2 Likes

Thinking about last point I made I thought about having property in object_data animation panel “Treat Object and Its Data as Single Data-Block”. It should be enabled by default, and when it is enabled it should always apply whatever is done for one to another.

  • Created action (& slot) for object - Assign that action to object-data and create slot for it (or vice-versa if object_data animated first)
  • Action duplicated for object - duplicate it for object_data too.
2 Likes

I’ve noticed I have to prod the action slot handle to get other objects after the first animated object to get the animation to play. I just swap them away then back to what they were.


Also could you clarify on this step?

I saw nickberckley above also had a hard time finding how this worked. And I haven’t cracked the code yet

EDIT: Ah, I found it, might want to highlight that there is a dropdown section for animation in the instructions above.

1 Like

Thank you for setting this up @sybren . Baklava is looking very promising!
After some quick tests my feedback is similar to nickberckley’s so I’ll avoid repeating it all.

I would expect that once I key anything for the first time it would create a new action (as it does now), but any key made on any yet-to-be-animated object/data afterward would go into that same action unless the selected object/data is assigned another action. At least as the default behaviour.

I imagine users that require separated actions for their projects would understand better the technical parts of Blender and be able to create and manage multiple actions. Makes me think we will probably need an operator to extract a slot’s f-curves to a new action for when you want to split an action into parts. :thinking:

At the moment animations made on data do not create Action data blocks which makes them hard to find if you need to do anything more than placing and removing keys. Having those be f-curves be placed into an action by default would help. Though I wonder if that does not bring out new issues? Like where would animated action data reside? Could it reside in itself?

But definitely looking forward to animating data properties (especially cameras fov and material alpha) and seeing the keys be included in the action editor. :smile:
Would also love to see all the slots appear on the f-curve channel list.

:purple_heart:

  • Gotta be honest I struggled a bit to put camera_obj and camera_data in the same action. Problem was I would animate camera_obj, go to properties and hit I on focal length, and go searching for keys in action editor. It took me a while to realize that by default it was creating it’s own action.

Yup, that’s the current behaviour.

I hated that.

Good. Hate it with all your heart. Let the black bubbly goo of your hatred spill out into the world and…

Yeah, we’re going to change that. This PR is intentionally relatively early in the development process, and so there will be limitations as to how far we’ve brought things.

What I’m intending to implement is to have ‘object’ + ‘object data’ share the same Action by default. This will work nicely when there are 1:1 relationships between objects and their data. In other words, once that’s implemented, the way you tried things will actually work.

In future we can put them in different layers to keep separation.

“We” (as in “Blender, the software”) shouldn’t. There will be tools to separate a layer into a layer per slot. That can then be used regardless of how that layer came to be.

  • Talking about sad state of shape keys, there is no animation panel in Shape Keys panel…

Yup, that’s something I’m working on too. For now, there will just be two Action selectors in the Mesh Animation panel, one for the mesh and one for the shapekeys. Once that’s working, we can of course at better places to organise the GUI elements.

To avoid this I suggest ALWAYS treat shape keys as regular mesh properties and put them in whatever action mesh has (or curve or lattice).

I’m not 100% sure about that. To me the shapekey values are similar to the pose data of an armature object. The Armature Data owns the bones, but the Armature Object contains the pose of those bones. In that sense, the value sliders are more object data than mesh data. Having said that, IMO we should just replace shapekeys and reimplement them better – they are quite a wart in Blender’s current code.

  • We talked about this and its documented so its not new, but for other people who might be interested: There should be scene-level “Active Action” picker

Yup. I do want to see how far we can push the current system, though, without relying on an ‘Active Action’. I have the gut feeling that we’ll get a more robust and easier to understand system that way.

  • I animated camera and camera_data in the same action, assigned that to second camera and two problems there:
    1. I expected that second camera would just inherit the entire animation just by having same action, but of course it didn’t. Its obvious to me why that is the case, but again I think there should be “protection” in case of such common workflows, such as: When existing action is assigned to object, create new slots for it (if applicable). Detecting when to create those slots is gonna be mighty difficult task, so I don’t know. Just throwing stuff.
    2. When I duplicated that action second camera inherited animation of first camera, but second camera_data didn’t inherit animation of first camera_data.

Yes, I do want to look carefully at these cases. I got confused by this myself as well at some point, because certain assumptions of the new system are so easy to make. My own confusion is actually why there’s now an indicator in the Action editor when a Slot is unassigned :wink:

I think the rule “make the duplicates share an Action when the originals shared an Action” is not too hard to implement. The other one, though (nr. 1 in your list), is harder, because it can be generalised to a few different cases:

  1. Assign another Action to an Object: what happens to the Object Data? Does it switch to the other Action too? Probably “yes” when they already shared the same Action. But what if you were doing that assignment because you wanted to give them separate Actions?
  2. Assign another Action to the Object Data, what happens to the Object? Should that be symmetrical with the above, or not?
  3. Assign another Action in general, what happens to the other users of the Action?

Because of these questions (and because I simply didn’t have time to build anything for this) there’s currently very little automation here. If you have any opinions / ideas / expectations as to ‘the right behaviour’, please share :slight_smile:

2 Likes

Would that be a property of the object data? Or the object? My gut feeling is that it should be on the Object, and maybe exposed also in the Object Data panels. But I’m not sure if that’ll be good or confusing.

Yeah this is a bug that we’re working on.

That would be a mix of these two features:

  • Keeping Object and Object Data on the same Action by default (which I want to implement sooner than later), and
  • Having the concept of Active Action on the Scene (as @nickberckley described above), which is probably something for later.

We will probably need an operator to extract a slot’s f-curves to a new action for when you want to split an action into parts. :thinking:

Yup, that’s on the todo list (#120406)

At the moment animations made on data do not create Action data blocks

That’s impossible. Anything that’s animated by F-Curves does so via Actions. (disclaimer: very specific curves on NLA properties do not, but that’s not what you’re talking about here)

So either I’m missing something, or what you’re asking for is already possible.

Would also love to see all the slots appear on the f-curve channel list.

They do, in the Action editor. In other places (Dope Sheet, Graph Editor) the slots wouldn’t add much, as there they’re already listed in the context of whatever data-block they animate.

1 Like

At the moment animations made on data do not create Action data blocks

I definitely was wrong about that. :sweat_smile:
I was asking for something that was already possible.

Would also love to see all the slots appear on the f-curve channel list.

Again, was wrong about that as well. I got confused between all the different kinds of names in the Baklava panel.
Slot : OBCube
Name : Cube
handle : 1
Internal Name : OBCube
ADT Slot Name : OBCube

With it appearing 3 times I was expecting “OBCube” to be the slot’s name in the Action’s channel list instead of just “Cube” even though it’s clearly indicating that “Cube” is the name. It will most likely be easier to understand in the future with the help of some UI icons.

Bugfix: #125236: Anim: rebuild depsgraph relations when creating a new F-Curve

That’s basically a “developer GUI” and not meant for being understandable. It’s just there to help me hack at things. It’ll disappear soon, and get replaced with a Slot selector in the Action editor (just like in the Properties editor).

3 Likes

Is this demo available for those who were not at the meeting?
It sounds like it’ll be a great visual presentation of where the project is going to.

Blender UI should be approached with respect. Even if something is a part of experimental feature set, or is designed to be used for development/debugging purposes it should be clear from the interface. For example, Dependency Graph panel, or Cycles Debug, debug passes, etc.

In this case it should be Animation Slots Debug or Animation Debug or something similar.

1 Like

There isn’t, but I can record a video this/next week.

:+1: done.