<?xml encoding="utf-8"?>

Just before Blender Conference 2024, the Animation & Rigging module held a day-long workshop to discuss layered actions should work in Blender. In this post, we’ll share the outcomes of that workshop.

For more context on this topic, please visit Animation 2025: Progress & Planning.

Joining in the workshop were Brad Clark, Christoph Lendenfeld, Dorothee Ditrich, Falk David, Lukas Tönne, Marion Stalke, Nate Rupsis, Nathan Vegdahl, Nika Kutsniashvili, Pierrick Picaut, Raymond Luc, Rik Schutte, and Sybren Stüvel.

Workshop Focus

A single day isn’t long enough to come up with a full design, so we tried to focus on topics that we could make real progress on within a day, and which would help orient the project. With that in mind, we structured the workshop into two parts:

Part 1: decide which use cases and supporting workflows we should target in the initial minimal version of layered actions, and also what features we need to support in service of that. The focus here was on determining a minimal set of features that we can feasibly develop in a reasonable time frame, while still being a useful initial version.

Part 2: discuss some of the trickier UI/UX questions raised by the features we decided on, and how they should work in practice.

So, without further delay, here is what we discussed at the workshop.

Use Cases and Workflows

We identified four broad categories of use cases/workflows for animation layers:

1. Creating new animations from scratch via layers. For example, animating a base layer of a character walking and then an additional layer for finer details in the motion, like shivering.
2. Adjusting existing animations. For example, adjusting mocap data non-destructively, or fixing an intersecting hand in someone else’s (or your own!) messy animation.
3. Organizing animation data. For example, putting a character’s facial animation on one layer and their body animation on another, or storing backups of previous animation stages (blocking, splining, etc.) in disabled layers for reference.
4. Incorporating non-keyframe data. This might be things like simulation layers, layers that bring in motion from cache files, layers that define animation-level constraints, etc.

Of these categories, we decided to leave #4 out of the initial version of layered actions. There are a lot of unknowns and potentially hard problems to solve with many of the use cases in that category, and just generally it’s not the primary reason people want animation layers.

We decided that the remaining three categories are all reasonable to accomodate in an initial “minimal viable product” (MVP) as long as we stick to the basics rather than trying to get fancy.

Initial Feature Set

From the above use cases, we narrowed down what we thought a reasonable minimal feature set would be. Additional features can always be added later, so the focus of this was on the minimum features needed for it to be useful. We of course want additional features down the line.

Here is a list of what we thought we couldn’t be without:

• Layers can be named.
• Layers can be given a color.
• Layers can be selected, and there is an active layer.
• Layers can be reordered.
• Layers can be added, deleted, and duplicated.
• Layers can be locked.
• Layers can be muted/disabled.
• Layers can be solo’ed (multiple layers can be solo’ed simultaneously).
• Each Layer has a blend mode. For initial release, these will be “replace” (similar to alpha-over in compositing software) and “combine” (conceptually an “add” mode, except data-type aware so that rotations rotate, scales scale, etc.).
• Layers have animatable influence / weight.
• Layers can be baked down together with the layers below them, as a way of merging layers togther. For the initial version this will just be a dumb per-frame bake.
• Layers are contained within, and owned by, an Action. Each Action has its own set of layers.

These features may seem quite basic. That’s because they are quite basic, and that’s the point. It’s a small, basic set of features that are manageable to tackle in an initial Minimal Viable Product (MVP). Additional features (like layer groups, smart baking, time warping, etc.) can wait for after the MVP is completed and in people’s hands.

We don’t want people to have to wait for all of the fancy features to be done before they can use the system at all. And when we get feedback, we want a ‘simple’ system we can easily adjust.

Where/How Do You Manage Layers?

There will be a separate editor for managing layers, and for selecting the active layer within an Action. Maybe this will even start out as a panel in the Action editor for the simplest of implementations.

At first, the other animation editors are only going to show data from the active layer.

This is just a start to get something simple in the hands of animators as soon as possible. With a more tangible layered workflow in Blender, it will be easier to design the necessary improvements to the UI/UX.

Where Do Keys Go?

When working with multiple layers, it is not immediately obvious where keys should go when you press the I button to key something. Below is the flow diagram we came up with.

Let’s talk through the above flow diagram:

• If there are no layers yet, create one and use that to store the keys.
• If there is only one layer, use that to store the keys.
• With multiple layers, there is a choice depending on whether the “Available” (name to be improved) checkbox is checked.
  • Unchecked: keys should always go to the active layer. Blender ensures that there is always a layer active (if there are no layers → see above).
  • Checked: keys should go to the layer that already animates whatever you’re keying now. See below.
• How many layers are already animating this property?
  • none → use the active layer (*)
  • one layer → use that
  • more than one layer: is one of those the active layer? If so, use it, otherwise use the topmost, unlocked layer.

(*): The flow diagram also goes into a choice for auto-keying vs. explicit keying. We hope that with this text the rest of the diagram is also clear.

That “Available” checkbox will likely be a user preference, as it is expected that it’ll be a personal choice and reflect more how you animate than what file you’re working in.

How Does Blending Work?

Blending the animation from different layers together is a fundamental aspect of layered animation, but is also surprisingly tricky to get right. It also impacts how certain other features should work.

So “how does blending work?” was an important question to answer. Below are our answers to that, as well as to the further questions that it raises.

What blend modes are there, and how do they work?

The initial Minimal Viable Product (MVP) will have just two blend modes: “replace” and “combine”. Other blend modes may be added in the future if there are real use cases for them, but for the MVP we will just have these two:

• Replace is like alpha over, overriding the animated values of the layers below. Changing the layer’s influence between 0-100% blends between the values of the layers below and the values of the current layer.
• Combine is conceptually like add, accumulating on top of the animated values of the layers below. For most properties this is a literal mathematical add, but for some properties (such as scale and quaternion rotation) that either isn’t really what you want or isn’t even sensical. In those latter cases the most appropriate accumulation operation is used instead (e.g. multiply for scale and quaternion multiplication for quaternion rotations). Changing the layer’s influence between 0-100% blends between the values of the layers below and the accumulated result of those values with the current layer.

For both blend modes, layers only affect properties that they animate: if a property is not animated on a layer then its value is simply passed through untouched.

What happens when there is no value on the layers below?

For “replace” layers with less-than-100% influence and “combine” layers with any influence, there has to be something below for the layer to blend with. But what if the layer is the bottom layer? Or what if it animates a property that isn’t animated on any of the layers below it? What does it blend with?

We considered two alternatives:

• Not blending: if there is nothing to blend with, don’t blend at all and just replace at 100% regardless of the layer’s actual blend mode and influence.
• Blend to default: use the property’s default value as the “value below” to blend with. This means blending to zero for location, one for scale, etc. Effectively, this means bones blend to their rest pose, and objects blend to their delta transform (which is often also zero, so then they blend to the origin, parent, etc.).

Neither solution is perfect, each having less-than-ideal behavior in at least some situations.

Not blending means that the effective influence of a layer can be 100% even when actually set to 0% or an extremely small percentage. Moreover, that effective influence can be different for different animated properties depending on what is and isn’t animated on the layers below, which could be confusing. It could also frustrate certain workflows, such as temporarily muting other layers to tweak the current layer’s animation in isolation: if the current layer’s influence is small, then muting the layers below it would effectively jump its influence to 100%, exaggerating its actual effect on the animation.

On the other hand, blend to default also has issues. The default values for properties often aren’t useful/meaningful, so blending with them is likely to be pretty useless in many cases. For example, unparented objects would typically blend to the world origin.

In the end we settled on blend to default. Its behavior is more predictable and less disruptive, and the user can work around useless default values if needed by keying useful values on a base layer.

What happens when you mute a layer?

Muting a layer will affect blending as if you removed the layer entirely. Note that for animated properties that are not on any layers below, this is specifically different from setting the layer’s influence to zero; that would blend to default, while muting the layer stops animating the property altogether.

Terminology note: we may want to call this “disable” rather than “mute”. To be decided.

Inserting and editing keys on middle layers

When you have multiple layers, you will often want to insert keys on one of the middle layers. When this happens, the value of that key must be determined.

We decided that the inserted value should be whatever value makes the final mix of all layers together produce the current pose. In practice this is almost always what is wanted: any other behavior would mean that inserting a key with the current pose may actually change the pose itself, which would be quite surprising! Accomplishing this means that the keyframing code needs to account for and reverse the effects of the other layers when determining the value to key. This is a bit like crazy space in mesh edit mode, which allows you to directly adjust the deformed positions of vertices.

However, just like crazy space, this isn’t always the behavior you want. Occasionally you want to specify the exact value to key, regardless of the effects of other layers. For the initial MVP you will be able to more-or-less accomplish this by soloing the layer before posing and keying, but in the future we want to explore approaches to accomplish this more directly.

There are also operations other than key insertion that may be useful to do with this “crazy space” behavior. For example, perhaps you want to add a layer and use it to smooth out the final mixed animation. If the smooth operator in the graph editor only sees the f-curves of a single layer in isolation, this won’t work. Instead, it will need to (optionally) perform the smoothing on the final mixed values and then back-propagate those smoothed values, accounting for the effects of the other layers. For the MVP we likely won’t be implementing this; there are some subtle and non-obvious details that may be challenging to get right. But it is something we want to support in the future.

Finally, there are of course cases where the “crazy space” keying behavior is impossible. For example, if there is a “replace” layer with 100% influence above the layer you’re keying on: no matter what value you insert a key with, it cannot affect the final mixed pose. We discussed a few alternatives for what should happen in such cases, but ultimately decided that for the MVP we should keep it simple: Blender will simply reject keying and issue an error. After this system is built, we can experiment with other approaches and see what actually works best in practice.

Wrapping Up

We’re extremely happy with how the workshop went, and we believe this is a solid direction for layered actions. Nevertheless, this is not the end of the design process. There is still a lot that needs to be figured out. Moreover, we could only accommodate a limited number of people at the workshop, and we want feedback and ideas from wider community as well. The best way to get involved is to join our weekly module meeting, and we look forward to seeing you there!

Support the Future of Blender

Donate to Blender by joining the Development Fund to support the Blender Foundation’s work on core development, maintenance, and new releases.

♥ Donate to Blender