Blender 4.4 - Slotted Actions - Feedback

Feature & Design Feedback
1

Blender 4.4 introduces Slotted Actions. In a nutshell, slots make it possible to store the animation of multiple “things” in the same Action.

What are Slotted Actions?

In Blender 4.3, an Action was just a “dumb bag of F-Curves”. Anything that gets an Action assigned will be animated by the same F-Curves.

Slotted Actions have a separate “dumb bag of F-Curves” for each slot. Anything that gets an Action assigned can choose which slot it gets animated by.

A slot is just a label stored by the Action. It has two components:

  • the display name (like “Suzanne” or “Cube”), and
  • the type it is meant to animate (OBJECT, CAMERA, SCENE, etc.).

This combination (name+type) is unique, so you can have an Object slot named “Camera” and a Camera Data slot also named “Camera”. Like always in Blender, the next one of those will become “Camera.001”.

Examples of Typical Usage

  1. Object and Object Data together: one action “CameraAction” could have two slots:
    • for the camera object (animating location & rotation), and
    • for the camera data (animating focal length & focus distance).
  2. Object, Mesh, and Shape Key parameters together: basically the same as above, where one “CharacterAction” could have three slots:
    • for the mesh object (animating location / rotation /scale)
    • for the mesh data (animating remesh voxel size)
    • for the shape key (animating blend values)
  3. Object rig: where one “character” consists of multiple objects parented together. Each object can have its own slot in the same Action.
  4. Brick wall physics simulation: a brick wall can consist of hundreds of individual objects. These can all be using the same Action, consisting of a slot per brick.

How to use Slotted Actions

There are three ways in which you can use slotted Actions:

  • Explicitly: Assign an Action, but do not pick a slot yet. When you start keying, Blender will create a new slot in that Action, to hold your keys. With this, you have full control over which Action your keys will go into.
  • Automatically: Blender will automatically make certain data share the same Action. For example, when you start keying a Camera Object, this will create an Action with a single slot. When you then key its Camera Data, that will use the same Action, and create a second slot for the camera data. This is also done for other combinations, like Material/World/Scene and their Shader Node Tree.
    This only happens if there was no Action assigned yet, so you can use the explicit method above if you do not want this automatic behaviour. See the release notes for more detailed information about the auto-assignment.
  • Afterwards: If you’ve keyed multiple objects, and then decide they should actually be using the same Action, you can merge Actions. Select the objects you want to merge. Then go to the Action editor, Action menu, and choose Merge Animation. For more info on how this works exactly, see the Action Menu chapter in the manual.

What does not happen?

Because this is the first release with slotted Actions, it was decided to not automate too much. This avoids the feel of “hard to understand magic”, at the cost of having to do more manually. These things were deliberately chosen not to implement in Blender 4.4, and to wait until a wider audience has had the chance to use slotted Actions in practice.

  • Select multiple objects & press I to key them. This still creates separate Actions, one per object. You can either use the “Explicitly” or “Afterwards” approaches (described above) if you want them to share Actions.
  • Action assignment only assigns that one Action, on that one thing. So when you assign an Action to the Camera Object, you may see “(unassigned)” behind the slot name of the Camera Data. In the Camera properties there is another Action selector (since Blender 4.3) that you can use to also assign the same Action to the Camera Data.
  • Similar to the previous point, switching Actions does not mass-switch all users of that Action.

So if you feel that these are stupid, and could be better, you’re in the right place. See below.

Already Foreseen Improvements

These improvements are already in our minds. Even though they’re not yet planned (as in, no date has been picked yet at which development would start), we do want them. In no particular order:

  • Simplify the Action selectors. Currently a Material + its node tree can have separate Actions (and will have, if you animated them in Blender 4.3 or earlier). When they do have the same Action assigned, it would be nice if the selectors would collapse, to show only a single Action selector and
    two slot selectors.
  • Pinning Actions in the Action editor. Currently the Action editor still works like it did before, and only shows the Action of the active object. It would be useful to be able to view any Action there, without assigning it to any object.
  • Operators to manage switching Actions: #133725: Anim: switching assigned action on multiple data-blocks together

What to give feedback on?

Blender 4.4’s behaviour is intentionally kept quite simple. There are ideas for streamlining the workflows, and for making things happen more automatially. And in order to automate the right things, and still ensure people have full control over their animation, we want to know about your experience.

First and foremost: please try to work with slotted Actions for a while, before giving feedback. Also read through the entire feedback thread, and if somebody else already voiced your idea, give them a :purple_heart:. This will make it much easier for developers to go through the thread and see which views are shared among a wide range of people.

These are some questions that we would love to see different points of view on:

  • When keying multiple objects simultaneously (and they do not have an Action assigned yet), should that make them share an Action, always? If not, should this be a user preference? If so, what should the default value for that preference be?
  • The “Automatically” case above makes certain types of data share the same Action by default. Should a similar kind of system also be in effect when switching Actions? And what should happen when you do want them to have different Actions? Is that even necessary for Blender to support?
  • What is missing / unexpected / counter-intuitive?
12 Likes
2

Hi just for this part i think a new shortcut or a new operator could do the trick, advanced user would know about it and use it and wandering beginners will just ignore it exist.
The shorctut can be “Shift I” because “Shift M” is for link collection and “Shift I” can be for link action.

2 Likes
3

Hey this is really exciting news!

I’m trying out the slotted actions by combining pose bone keys and shape keys. Just a little demo with an elbow bending (pose bone rotation) and a bicep flexing (mesh shape key).

It seems to be working, but it’s a little confusing to work with.
I can see the ‘Shape Key’ slot in the action, but it doesn’t appear in the slots drop-down in the Action Editor. It took me a lot of poking around to discover that I had to switch to the Shape Key Editor subsection, I’m wondering if there’s something that can help indicate this better. A good start would be to add the “SHAPEKEY_DATA” icon next to slots that are for shape keys (Right now there is no icon).

Also, it seems that the shape keys aren’t getting saved into my pose asset, do pose assets support this? My flexing arm is only saving the bone rotation into the pose asset.

1 Like
4

Thanks for your feedback @Xury46 !

This is effectively how Blender has worked for a long time. Except that you didn’t even see the shape key’s action in the Action mode of the editor (that only showed Object Actions), and you could only see Shape Key Actions in the Shape Key mode.

Even though things haven’t fundamentally changed here, I do agree that the new system exposes people more to this confusion. I’d love to see some improvements in the slot selector, but that’ll have to wait until Blender 4.5 I’m afraid. Most notably, I want the not-suitable slots (like a shape keyt slot while the selector is for object slots) to still show, but greyed out. And I’d want the slot type to be shown as well.

That’s correct. The pose asset only contains the pose of the selected bones in the Armature, and any (keyed) custom properties of those bones. So if you set up some drivers on the shape key values, and make sure they can be driven by bone transforms or custom props, it’ll work. In the future this might be better supported, but not yet.

1 Like
5

Hi! I really love the idea of ​​slots, and I wanted to share a couple of thoughts. Sometimes, I find myself wanting to focus on the keyframes of a specific slot, so I was thinking it might be helpful to have the option to hide or show slots. Also, it would be awesome if we could assign different colors to each slot. That way, it’s easier to manage and dedicate time to each one individually. Just an idea!

3 Likes
6

There is the option to only show the slot of the active object. The ability to hide individual slots is an interesting one, I’ll keep it in mind.

This is also an interesting option, one which I think we should consider when designing the UI for layered animation. Then there will be more information in the animation editors, and the choices for the colouring should be taking this into account.

Maybe we could even automatically pick a colour for some slots, based on the object viewport colour, material viewport colour, etc. Of course this would be optional, the default view should be non-distracting.

These are not promises of any future feature, just my personal response to some interesting ideas :slight_smile:

4 Likes
7

Working on updating my add-ons to the new API this weekend, and one thing I seriously lack is the ability to get how many users a slot has. I looked into release notes but found nothing, and users doesn’t work since it’s not an ID. Is it not possible yet?

I have cases where I have automated the process of removing unused keyframes or entire f-curves, but now I need to check if an action slot has other users as well, and if it does, then do not remove them (as others will still need it). Now I default to checking for action users, but that’s not ideal and will result in cases where keyframes/f-curves aren’t removed even though they’re not used anymore.

Besides count, getting user IDs will be very helpful as well for filtering (for example when removing custom property, first I would check if any of the slot owners have that property in the first place).

1 Like
8

The slot users are tracked in C++. We decided to not expose this to Python yet, because we didn’t see a concrete use case yet. Since exposing things to Python is significantly easier than removing things from the API once they’ve been exposed, we erred on the side of caution.

That sounds quite reasonable, indeed.

1 Like
9

For context, my only use-case is video games development, not film or VFX. My content is not linear. It requires for multiple (100+) animations targeting the same asset to exist.

When keying multiple objects simultaneously (and they do not have an Action assigned yet), should that make them share an Action, always? If not, should this be a user preference? If so, what should the default value for that preference be?

Yes always!
Otherwise, definitely an option, with a default value of yes preferably.

The “Automatically” case above makes certain types of data share the same Action by default. Should a similar kind of system also be in effect when switching Actions? And what should happen when you do want them to have different Actions? Is that even necessary for Blender to support?

The idea of a data-block “having” an Action is unintuitive. An artist now has to deal with every potentially animatable data-block individually. However, it’s the Action that animates the data-blocks. The active Action should be THE active Action, none others should be considered for anything. From a user and data-model perspective, that makes just sense. When an artist selects an Action, that one should be played and keyed, and that one only. If a combination of Actions are supposed to be played, isn’t that what the NLA is supposed to be for?

What is missing / unexpected / counter-intuitive?

  • Subjectively, most of my ‘I’ presses land the keyframe somewhere, just not where I want.

  • The Action also doesn’t remember which exact data-block its Slots target. It is impossible to export anything other than the currently assigned animation data, making Blender 4.4 as-is useless for animation for video-game assets.

  • The auto switching of the active Action has to be implemented before I can use this system at all. I’m stuck on 4.3 for now.

    Excited for when that happens, as that will give Blender 4.5? an edge over market dominant alternatives like 3dsMax or Maya for game dev. They have an animation workflow that works, but is still quite jank for gamedev. Less jank than Blender 4.3-, and way less jank than the current state of 4.4. The potential here is big, especially if the FBX exporter is adapted to that future iteration of the animation system.

I implemented a simple add-on in Python to auto-switch Actions fully at the press of a button. It requires artists to manually specify the Actions targets, but works for me in the meantime.

I hope Blender 4.5 can make this obsolete, but at least from a game-dev perspective, it’s not very complicated.

3 Likes
10

Can you elaborate on that? Do you mean that the keyframe doesn’t appear on the current frame?

You should be able to work with actions just as in 4.3 by ignoring slots altogether. What stops you from transitioning?

I am sure it makes sense for your workflow but I am less certain this can be generalized to all users.

11

This is how Blender has worked since the 2.5x series was released, though. So basically for the past 15 years.

The active Action should be THE active Action

There is no such thing as THE active Action in Blender. Each animatable data-block can choose which Action it’s animated by, slotted Actions don’t change anything in this respect.

When an artist selects an Action, that one should be played and keyed, and that one only.

This is exactly what happens, for that data-block. Each Object can have its own Action, or all can share the same Action (with action slots in 4.4).

If a combination of Actions are supposed to be played, isn’t that what the NLA is supposed to be for?

If the combination of Action is to be played for one data-block, then yes, that’s what the NLA is for.

2 Likes
12

I think idea of “pinned” or “scene action” we discussed while back is what’s gonna answer this workflow. Ability to choose one action on scene-level and let every keyframe go there automatically.

3 Likes
13

Yip! But I hope Actions will remember which of its Slots were linked to which data-blocks by then. Otherwise, we still get effectively only one animation that can be exported at one time.

With Actions being previously so restricted, I guess it didn’t come to bite me as much before.
So far, I had to do about 90% of my animation work in the game engine. My hope was that in 4.4 I could move most of that into Blender, so that my assets could become more universally compatible instead of being locked into Unity.

They appear on the correct frame, but not the correct Action.
Yes, it’s because the Action and Slot which is bound to that data-block is different from the one I selected in the Action editor. It’s not a technical bug, it’s a UX issue.
I have no intention of manually managing every single data-block’s animation-data when I’m dealing with hundreds of Actions.

Actually yes, good to know, thanks!

14

Please read the documentation and try out how things work. This thread is for gathering feedback after getting experience with how the system behaves.

If the documentation is unclear, let us know. But don’t expect this thread to be used as source of explanations how things work. That’s what the docs are for :wink:

2 Likes
15

Gladly, just give me a sec to gather some plutonium for my DeLorean, so I can look at the documentation of this future iteration of Blender’s animation system that I commented on. :wink:

16

https://docs.blender.org/manual/en/4.4/animation/actions.html

3 Likes
17

Python API feedback.

Since fcurves are located inside channelbags, action properties that calculate frame range of the whole action such as frame_range, frame_start and frame_end are pointless, I would rather have them as channelbag properties.

18

I disagree that the Action level properties would be useless, but I can totally see their need on the Channelbag.

19

What use case that’ll be? You cannot use action without specifying slot which points to specific channelbag. What’s the point of knowing frame_start of a whole action when you can only use single channelbag?

20

I can’t stop laughing every time I’m reading “channel bag”…

2 Likes