Initial UX design for the new Animation data model #118008

New Issue

Nathan Vegdahl · 2024-02-08T17:57:23+01:00

Nathan Vegdahl commented

2024-02-08 17:57:23 +01:00

Background: at the animation workshop last year we designed a data model for the upcoming new animation system, with a focus on making sure it could represent the things needed for the use cases we plan to accommodate. There have been some changes to the data model since then as we prototyped and explored it further. But the basics of having layers, strips, and outputs within a new Animation datablock have not changed.

This design task is for the corresponding UX and UI design: how does the user actually create and work with animation under this new data model.

Don't Ruin Existing Workflows / Simple Things Should Be Simple

If users don't want to use animation layers, or strips, or any of that fancy stuff, it shouldn't be shoved in their faces. They should be able to just animate as they always have. Layers and strips should both be opt in.

Therefore, newly created Animation datablocks will just have a single layer with a single infinite strip, and the user does not need to interact with the layers UI at all when animating. All keys just go into that one strip on that one layer, and can be edited with the normal tools as always.

Layered Animation Workflows

There are broadly two things people may want to use animation layers for:

Animating the same channels on multiple layers and mixing those layers on top of each other to build up an animation.
Putting different channels on different layers for organization purposes. For example, putting object A's animation on one layer and object B's on another.

Accommodating both workflows within the same system may be challenging. Here is my proposal:

Layers can be selected.
When inserting keys, those keys go into the currently selected layer.
If more than one layer is selected, the keys go into the top-most selected layer that accepts the keys (more on that below).
The user can "limit" layers, which prevents them from accepting keys for channels that aren't already keyed on that layer.
Whether a layer can accept a key or not is based on several factors:
- If the layer is "limited" as described above.
- If the layer is locked.
- If the layer is disabled.
- If the layer has enough effect on the final mix to make it match the given pose. For example, if the layer's influence is zero, if there's another full-influence replace layer above it, etc.

What Value of Keys Get Inserted?

Rather than naively inserting the current value of a property into the selected layer, the animation system should figure out what value needs to be inserted on that layer to make the final mix (with all the layers) result in the current value of the property.

In other words, keying should be layer-mixing aware.

Where Do Keys Go?

There are three parts to this:

Where do keys go when you key an object/ID that doesn't have an animation data block yet?
Where do keys go when there are no layers or strips on the animation data block?
Where do keys go when there is more than one layer or strip?

1. No Animation Datablock

There are two behaviors users might want:

All animation goes into the same Animation datablock.
Each ID gets its own Animation datablock (similar to how actions work).

The Animation datablock can handle both approaches, and both should be supported.

Proposal: there is an ID pointer property in the scene that can point to an Animation datablock. When it is empty/unset, new Animation datablocks are created for each object/ID that don't have one when inserting keys. When it is set, objects/IDs without an Animation datablock are hooked up to that shared Animation datablock and their keys are inserted there.

Alternatively, we could have a user setting for this. However, I think that's probably not a good idea because of the "opening up and working on someone else's file" case. The way animation data is organized may vary per scene and blend file (e.g. a shot file vs an animation library file), and it's nice if things "just work" and everything stays consistent within a file.

2. No Layers / Strips

If there are no layers or strips, I propose a simple rule: keying fails.

The general rule here is that layers and strips are never automatically created (aside from the default layer and strip of a freshly created Animation datablock). That should be left to the user.

We may want to revisit this if we introduce options to e.g. always automatically put different objects/IDs on different layers, to make certain workflows easier.

3. More Than One Layer/Strip

This was partially covered earlier, but here's a more complete explanation.

I propose the following approach for determining where keys go when there's more than one layer or and/or overlapping strips:

Where keys can go is limited by selection. For example, if only one layer or strip is selected, that's the only place keys can go.
If more than one layer or strip is selected, simple predictable rules are used to determine which of the selected layers/strips the keys goes into:
- If more than one layer is selected, the keys go into the top selected layer that can accept them.
- If more than one overlapping strip on the same layer is selected, keys go into the strip with the highest influence at that frame, defaulting to the earlier strip in a tie.

This allows the user to predict and rely on the automatic rules when appropriate, but also control exactly where keys go via selection when needed.

Graph Editor and Dopesheet

The graph editor will still exist. The dopesheet will probably still exist, but see further down for discussion of the possibility of fully merging the Animation editor and dopesheet into one thing. In this section, I assume the dopesheet will still exist.

The graph editor and dopesheet will still have a "global" view of things, just as they do now. They will be able to visualize and edit animation data for more than one Animation datablock at a time if desired, just as they can with actions now. And just like now they will still be able to filter/scope their view down when desired as well.

The main difference is that layers and strips need a way to be represented in the channel list. For example, you could have two different layers animating the same property, and it's important to be able to view and edit them both.

Proposal: simply add layers and strips to the channel hierarchy. Also add filter options to be able to filter based on selected layer(s) and strip(s).

It may also make sense to exclude layers/strips from the hierarchy when there's only one, since no layer distinction is needed then. However, this should be based on how many layers/strips actually exist in a given Animation datablock, not how many are visible after filtering. Seeing a layer/strip in the hierarchy then serves as an indicator that layer/strip-based animation is involved in what the user is currently working on.

The New Animation Editor

A new Animation Editor will be introduced. It will at least be responsible for:

Visualizing and editing animation layers.
Visualizing and editing animation strips.
Managing (creating/deleting/renaming) animation outputs manually.
Managing Animation datablocks as datablocks (creating, renaming, editing properties, etc.).

Multiple Animation Datablocks

One question that came up for me while thinking/mocking things up was: what happens if you have two objects selected, each hooked up to a different Animation datablock? Does the Animation Editor visualize both animation datablocks?

My tentative conclusion (which is arguable) is that, no, it should show a single Animation datablock at a time, which in this case would be the one hooked up to the active object. The rationale is as follows:

There needs to be some place for managing Animation datablocks as datablocks, and the other places in Blender that do this kind of thing (e.g. node graph editors, image editors, text editors, etc.) all manage a single datablock at a time. So this follows the Suzzane principle.
If two pieces of animation are closely related enough that you need to visualize/edit them side-by-side, they probably belong in the same Animation datablock anyway. So in practice the utility of displaying two Animation datablocks at once may be low.

Unify the Animation Editor and Dopesheet Into One Thing?

Advantages

Fewer editors for the user to juggle.
For many use cases, directly editing the key frames on the layers themselves is more straightforward.
It presents a simple, direct mental model of where your animation data is.

Challenges

The dopesheet provides some advantages that may be tricky to reproduce in a layer-based animation editor:

Animation filtering: "I want to view the keys of object A on layer 1 and the keys of object B on layer 4 right next to each other". Since the layers are semantically meaningful (and potentially nested!) filtering within the same visualization where they are managed could be both awkward and misleading. Additionally, providing a way for the user to specify that filtering is more of a UI challenge than in a dopesheet where it could just filter based on layer selection in the Animation Editor.
Alternative visual organization: "I want the layers visualized under each object, rather than the objects visualized under each layer." This inverts the display hierarchy, and it's not clear how to do that in a reasonable way in the same editor that defines and edits the real hierarchy. Whereas in the dopesheet it's easier to make the visualized organization dynamic and switchable for whatever the user needs at that moment.
Clear, flexible keyframe selection tools: since there are only keys in the dopesheet, things like box select, alt-clicking (to select all keys in the same column), etc. have obvious semantics. However, when keys are on different layers and potentially interleaved with strip UI, it becomes less clear what such selection operators should do. Should alt-clicking select all keys in a column across all layers, or only within the current one? Should box selecting select strips or keys (or both?), and when? These are solvable issues, but the solutions may introduce additional complexity and more things that the user has to understand to use the tools.
Access to all keys: strips can contain keys that are outside their visible bounds on the timeline. And those keys can affect the in-bounds animation due to interpolation. So there needs to be a way to access and edit them. In the dopesheet this is trivial: you can simply give each strip its own row and display all of its keys. That may work for the Animation Editor as well, but the additional vertical space it would occupy is potentially more problematic due to the aforementioned challenges with quickly filtering/scoping the data.

Animating Layer Influence

Each layer will have an influence property, that acts something like an alpha-blend. This property should be animatable. However, the influence property doesn't belong to a particular output and doesn't live on any strips, instead being a direct property of the layer itself.

Data Management

Assigning Animations to IDs

One of the stupid things about Blender right now is that you can only (easily) manage what Actions Objects are hooked up to (via the Action Editor). There is no place in the UI to change what Action a Material is hooked up to, for example.

We should address this in the new animation system. As a bare minimum to start out with, I propose that we simply add an "Animation" panel in the properties of each (animatable) ID, which contains fields for the Animation datablock + output that the ID uses. In the future we can explore more sophisticated approaches, but this bare minimum UI should always be there.

Some animatable IDs are not represented in the main properties editor. For example, masks. However, all such data is represented somewhere in Blender's UI, and an Animation panel can be added there. In the case of masks, that would be in the n-panel of the Movie Clip Editor when in mask mode.

Managing an Animation Datablock's Outputs

Outputs can be automatically created when needed. For example, when a previously unanimated ID is keyed, a new output for it may be made.

However, there should also be a way for the user to manually manage them. Proposal: we take a simple approach: an "Outputs" panel in the Animation Editor's n-panel, that provides an editable list of outputs for the current Animation datablock. The user can add, delete, and rename outputs there.

Background: at the [animation workshop](https://code.blender.org/2023/07/animation-workshop-june-2023/) last year we designed a data model for the upcoming new animation system, with a focus on making sure it could represent the things needed for the use cases we plan to accommodate. There have been some changes to the data model since then as we prototyped and explored it further. But the basics of having layers, strips, and outputs within a new Animation datablock have not changed. This design task is for the corresponding UX and UI design: how does the user actually create and work with animation under this new data model. # Don't Ruin Existing Workflows / Simple Things Should Be Simple If users don't want to use animation layers, or strips, or any of that fancy stuff, it shouldn't be shoved in their faces. They should be able to just animate as they always have. Layers and strips should both be *opt in*. Therefore, newly created Animation datablocks will just have a single layer with a single infinite strip, and the user does not need to interact with the layers UI at all when animating. All keys just go into that one strip on that one layer, and can be edited with the normal tools as always. # Layered Animation Workflows There are broadly two things people may want to use animation layers for: 1. Animating the same channels on multiple layers and mixing those layers on top of each other to build up an animation. 2. Putting different channels on different layers for organization purposes. For example, putting object A's animation on one layer and object B's on another. Accommodating both workflows within the same system may be challenging. Here is my proposal: - Layers can be selected. - When inserting keys, those keys go into the currently selected layer. - If more than one layer is selected, the keys go into the top-most selected layer *that accepts the keys* (more on that below). - The user can "limit" layers, which prevents them from accepting keys for channels that aren't already keyed on that layer. - Whether a layer can accept a key or not is based on several factors: - If the layer is "limited" as described above. - If the layer is locked. - If the layer is disabled. - If the layer has enough effect on the final mix to make it match the given pose. For example, if the layer's influence is zero, if there's another full-influence replace layer above it, etc. ![layered_animation_flows.jpg](/attachments/1c6697ee-991e-4dce-9596-b6527858ed44) ![layer_limiting.jpg](/attachments/b222eb28-b7a4-4bc3-a865-10c54cb249d1) # What Value of Keys Get Inserted? Rather than naively inserting the current value of a property into the selected layer, the animation system should figure out what value needs to be inserted on that layer to make the *final mix* (with all the layers) result in the current value of the property. In other words, keying should be layer-mixing aware. # Where Do Keys Go? There are three parts to this: 1. Where do keys go when you key an object/ID that doesn't have an animation data block yet? 2. Where do keys go when there are no layers or strips on the animation data block? 3. Where do keys go when there is more than one layer or strip? ## 1. No Animation Datablock There are two behaviors users might want: 1. All animation goes into the same Animation datablock. 2. Each ID gets its own Animation datablock (similar to how actions work). The Animation datablock can handle both approaches, and both should be supported. **Proposal:** there is an ID pointer property in the scene that can point to an Animation datablock. When it is empty/unset, new Animation datablocks are created for each object/ID that don't have one when inserting keys. When it is set, objects/IDs without an Animation datablock are hooked up to that shared Animation datablock and their keys are inserted there. Alternatively, we could have a user setting for this. However, I think that's *probably* not a good idea because of the "opening up and working on someone else's file" case. The way animation data is organized may vary per scene and blend file (e.g. a shot file vs an animation library file), and it's nice if things "just work" and everything stays consistent within a file. ## 2. No Layers / Strips If there are no layers or strips, I propose a simple rule: keying fails. The general rule here is that layers and strips are never automatically created (aside from the default layer and strip of a freshly created Animation datablock). That should be left to the user. We may want to revisit this if we introduce options to e.g. always automatically put different objects/IDs on different layers, to make certain workflows easier. ## 3. More Than One Layer/Strip This was partially covered earlier, but here's a more complete explanation. I propose the following approach for determining where keys go when there's more than one layer or and/or overlapping strips: 1. Where keys can go is *limited* by selection. For example, if only one layer or strip is selected, that's the only place keys can go. 2. If more than one layer or strip is selected, simple predictable rules are used to determine which of the selected layers/strips the keys goes into: - If more than one layer is selected, the keys go into the top selected layer that can accept them. - If more than one overlapping strip on the same layer is selected, keys go into the strip with the highest influence at that frame, defaulting to the earlier strip in a tie. This allows the user to predict and rely on the automatic rules when appropriate, but also control exactly where keys go via selection when needed. # Graph Editor and Dopesheet The graph editor will still exist. The dopesheet will *probably* still exist, but see further down for discussion of the possibility of fully merging the Animation editor and dopesheet into one thing. In this section, I assume the dopesheet will still exist. The graph editor and dopesheet will still have a "global" view of things, just as they do now. They will be able to visualize and edit animation data for more than one Animation datablock at a time if desired, just as they can with actions now. And just like now they will still be able to filter/scope their view down when desired as well. The main difference is that layers and strips need a way to be represented in the channel list. For example, you could have two different layers animating the same property, and it's important to be able to view and edit them both. **Proposal:** simply add layers and strips to the channel hierarchy. Also add filter options to be able to filter based on selected layer(s) and strip(s). It may also make sense to exclude layers/strips from the hierarchy when there's only one, since no layer distinction is needed then. However, this should be based on how many layers/strips *actually exist* in a given Animation datablock, not how many are visible after filtering. Seeing a layer/strip in the hierarchy then serves as an indicator that layer/strip-based animation is involved in what the user is currently working on. ![dopesheet_and_graph_editor_channels_hierarchy.jpg](/attachments/a854a566-d130-47ee-a6af-b5218f634d79) # The New Animation Editor A new Animation Editor will be introduced. It will *at least* be responsible for: - Visualizing and editing animation layers. - Visualizing and editing animation strips. - Managing (creating/deleting/renaming) animation outputs manually. - Managing Animation datablocks *as datablocks* (creating, renaming, editing properties, etc.). ## Multiple Animation Datablocks One question that came up for me while thinking/mocking things up was: what happens if you have two objects selected, each hooked up to a different Animation datablock? Does the Animation Editor visualize both animation datablocks? My tentative conclusion (which is arguable) is that, no, it should show a single Animation datablock at a time, which in this case would be the one hooked up to the active object. The rationale is as follows: 1. There needs to be some place for managing Animation datablocks *as datablocks*, and the other places in Blender that do this kind of thing (e.g. node graph editors, image editors, text editors, etc.) all manage a single datablock at a time. So this follows the Suzzane principle. 2. If two pieces of animation are closely related enough that you need to visualize/edit them side-by-side, they probably belong in the same Animation datablock anyway. So in practice the utility of displaying two Animation datablocks at once may be low. ## Unify the Animation Editor and Dopesheet Into One Thing? ### Advantages 1. Fewer editors for the user to juggle. 2. For many use cases, directly editing the key frames on the layers themselves is more straightforward. 3. It presents a simple, direct mental model of where your animation data is. ### Challenges The dopesheet provides some advantages that may be tricky to reproduce in a layer-based animation editor: 1. **Animation filtering**: "I want to view the keys of object A on layer 1 and the keys of object B on layer 4 right next to each other". Since the layers are semantically meaningful (and potentially nested!) filtering within the same visualization where they are managed could be both awkward and misleading. Additionally, providing a way for the user to specify that filtering is more of a UI challenge than in a dopesheet where it could just filter based on layer selection in the Animation Editor. 2. **Alternative visual organization**: "I want the layers visualized under each object, rather than the objects visualized under each layer." This inverts the display hierarchy, and it's not clear how to do that in a reasonable way in the same editor that defines and edits the real hierarchy. Whereas in the dopesheet it's easier to make the visualized organization dynamic and switchable for whatever the user needs at that moment. 3. **Clear, flexible keyframe selection tools**: since there are only keys in the dopesheet, things like box select, alt-clicking (to select all keys in the same column), etc. have obvious semantics. However, when keys are on different layers and potentially interleaved with strip UI, it becomes less clear what such selection operators should do. Should alt-clicking select all keys in a column across all layers, or only within the current one? Should box selecting select strips or keys (or both?), and when? These are solvable issues, but the solutions may introduce additional complexity and more things that the user has to understand to use the tools. 4. **Access to all keys**: strips can contain keys that are outside their visible bounds on the timeline. And those keys can affect the in-bounds animation due to interpolation. So there needs to be a way to access and edit them. In the dopesheet this is trivial: you can simply give each strip its own row and display all of its keys. That may work for the Animation Editor as well, but the additional vertical space it would occupy is potentially more problematic due to the aforementioned challenges with quickly filtering/scoping the data. ![unified_animation_dopesheet_editor.jpg](/attachments/98a0381c-48ea-497e-9f8b-e8ff980d3038) ### Animating Layer Influence Each layer will have an influence property, that acts something like an alpha-blend. This property should be animatable. However, the influence property doesn't belong to a particular output and doesn't live on any strips, instead being a direct property of the layer itself. ![layer_influence_keyframing_explorations.jpg](/attachments/45cc7f6c-7eeb-4f85-8bef-7fbadd82caeb) # Data Management ## Assigning Animations to IDs One of the stupid things about Blender right now is that you can only (easily) manage what Actions *Objects* are hooked up to (via the Action Editor). There is no place in the UI to change what Action a Material is hooked up to, for example. We should address this in the new animation system. **As a bare minimum** to start out with, I propose that we simply add an "Animation" panel in the properties of each (animatable) ID, which contains fields for the Animation datablock + output that the ID uses. In the future we can explore more sophisticated approaches, but this bare minimum UI should always be there. Some animatable IDs are not represented in the main properties editor. For example, masks. However, all such data is represented *somewhere* in Blender's UI, and an Animation panel can be added there. In the case of masks, that would be in the n-panel of the Movie Clip Editor when in mask mode. ![animation_datablock_management.jpg](/attachments/2cb7227b-4d4e-4377-a603-48b4be8abcac) ## Managing an Animation Datablock's Outputs Outputs can be automatically created when needed. For example, when a previously unanimated ID is keyed, a new output for it may be made. However, there should also be a way for the user to manually manage them. **Proposal**: we take a simple approach: an "Outputs" panel in the Animation Editor's n-panel, that provides an editable list of outputs for the current Animation datablock. The user can add, delete, and rename outputs there. ![animation_outputs_management.jpg](/attachments/9b93d110-67ca-4267-b949-20641d4a9824)

layered_animation_flows.jpg

1020 KiB

animation_datablock_management.jpg

1.2 MiB

layer_influence_keyframing_explorations.jpg

367 KiB

unified_animation_dopesheet_editor.jpg

579 KiB

dopesheet_and_graph_editor_channels_hierarchy.jpg

214 KiB

animation_outputs_management.jpg

144 KiB

layer_limiting.jpg

92 KiB

👍 3 👀 3 ❤️ 5 🚀 6

Nathan Vegdahl added the

Type

Design

label 2024-02-08 17:57:23 +01:00

Nathan Vegdahl added this to the Animation & Rigging project 2024-02-08 17:57:26 +01:00

Christoph Lendenfeld commented

2024-02-09 11:01:12 +01:00

If more than one layer is selected, the keys go into the top-most selected layer that accepts the keys (more on that below).

I am not sure about this. It means the artist needs to manage and be aware of the selection. And what if you want to apply an operator to a bunch of layers? That would also go by selection so afterwards you'd need to re-establish the previous selection to continue work.
I would argue that it might be better to only go by key acceptance rules as you have outlined it (locked, limited etc.)

We could do the inverse though, if layers are soloed, keys will only go to those.
Alternatively we could have a "keyable" state on layers which needs to be enabled for it to be keyable.
Anyway my point is we should avoid mixing the concepts of selection and keyability.

No Animation Datablock

About the whole thing of creating one datablock per object or have it shared. I think there is no good solution which means we need to provide good tooling to merge and split datablocks whenever needed.

If there are no layers or strips, I propose a simple rule: keying fails.

Agree 100%. This also makes it very predictable in cases where there are no layers or strips that are valid to insert keys into. They might exist but are locked, which makes them non-existent for the keying system.

One question that came up for me while thinking/mocking things up was: what happens if you have two objects selected, each hooked up to a different Animation datablock? Does the Animation Editor visualize both animation datablocks?

I disagree about the conclusion that it should only ever display one anim data block, especially with the reasoning. Animation has always displayed more than one action (which is a datablock, right?) and this is super useful. Also it would mean we have an editor where moving layers between datablocks could be as easy as a drag and drop.

If two pieces of animation are closely related enough that you need to visualize/edit them side-by-side, they probably belong in the same Animation datablock anyway

Yes they should be, but they might not be. In the chaos of a production many things happen that are not ideal and I think we should keep the GUI as flexible as possible in that regard.

Unify the Animation Editor and Dopesheet Into One Thing?

Due to the challenges you listed I think it's a good idea to NOT do that. Especially the "truncated Strip with keys outside its range" issue is something the Animation editor just cannot solve.
I think it's important to display the key summary within the strips as you have it in your drawings to easily allow broad changes to timing.
However I think we also need a new "Strip Editor", which is basically the action editor but would allow changing which strip is displayed right now. It could also indicate the limits of the strip. Entering that editor should be as simple as pressing "Tab" on a strip in the animation editor. This could also solve the issue of looping animation. If the editor is aware which strip it is modifying, it can wrap keys around the ends seamlessly.
We are going to have a similar issue with the Graph Editor, so I think solving that early is beneficial.

I propose that we simply add an "Animation" panel in the properties of each (animatable) ID

YES

Proposal: we take a simple approach: an "Outputs" panel in the Animation Editor's n-panel

I think that's a good idea

Thanks for the awesome work Nathan! Exciting seeing it come together

> If more than one layer is selected, the keys go into the top-most selected layer that accepts the keys (more on that below). I am not sure about this. It means the artist needs to manage and be aware of the selection. And what if you want to apply an operator to a bunch of layers? That would also go by selection so afterwards you'd need to re-establish the previous selection to continue work. I would argue that it might be better to only go by key acceptance rules as you have outlined it (locked, limited etc.) We could do the inverse though, if layers are soloed, keys will only go to those. Alternatively we could have a "keyable" state on layers which needs to be enabled for it to be keyable. Anyway my point is we should avoid mixing the concepts of selection and keyability. > 1. No Animation Datablock About the whole thing of creating one datablock per object or have it shared. I think there is no good solution which means we need to provide good tooling to merge and split datablocks whenever needed. > If there are no layers or strips, I propose a simple rule: keying fails. Agree 100%. This also makes it very predictable in cases where there are no layers or strips that are valid to insert keys into. They might exist but are locked, which makes them non-existent for the keying system. > One question that came up for me while thinking/mocking things up was: what happens if you have two objects selected, each hooked up to a different Animation datablock? Does the Animation Editor visualize both animation datablocks? I disagree about the conclusion that it should only ever display one anim data block, especially with the reasoning. Animation has always displayed more than one action (which is a datablock, right?) and this is super useful. Also it would mean we have an editor where moving layers between datablocks could be as easy as a drag and drop. > If two pieces of animation are closely related enough that you need to visualize/edit them side-by-side, they probably belong in the same Animation datablock anyway Yes they should be, but they might not be. In the chaos of a production many things happen that are not ideal and I think we should keep the GUI as flexible as possible in that regard. > Unify the Animation Editor and Dopesheet Into One Thing? Due to the challenges you listed I think it's a good idea to NOT do that. Especially the "truncated Strip with keys outside its range" issue is something the Animation editor just cannot solve. I think it's important to display the key summary within the strips as you have it in your drawings to easily allow broad changes to timing. However I think we also need a new "Strip Editor", which is basically the action editor but would allow changing which strip is displayed right now. It could also indicate the limits of the strip. Entering that editor should be as simple as pressing "Tab" on a strip in the animation editor. This could also solve the issue of looping animation. If the editor is aware which strip it is modifying, it can wrap keys around the ends seamlessly. We are going to have a similar issue with the Graph Editor, so I think solving that early is beneficial. > I propose that we simply add an "Animation" panel in the properties of each (animatable) ID YES > Proposal: we take a simple approach: an "Outputs" panel in the Animation Editor's n-panel I think that's a good idea Thanks for the awesome work Nathan! Exciting seeing it come together

Nathan Vegdahl commented

2024-02-09 15:37:27 +01:00

These are my notes from the meetings I've had with people about the mockups so far. I did my best to accurately represent what people said, but of course may have made some mistakes or missed things. If I misrepresented or missed a point of yours, don't hesitate to say so!

Meeting 1

With @dr.sybren.

Data Management Flows

Sybren prefers the idea of storing an ID's last assigned output name in the ID, and using that to auto-hook-up IDs with outputs later.
- Nathan: I have some gut-feeling reservations, but no concrete objections yet.
- We'll move forward with that for now. If concrete objections manifest, we can revisit it then.

Merging Animation Editor and Dopesheet

Layer influence keyframes could be visualized at the top of the layer, to avoid getting in the way of the channel keyframes at the bottom.
Keyframes on the border of two strips: if we do the top/bottom split with strip handles on the top and keys on the bottom, the strip handles should not extend to the bottom. This is because it makes selecting keys on the border of the strips ambiguous. Additionally, it may make sense to have two rows for the keys so that they can be staggered to make room for the edge keys of abutting strips.
We could make the borders between layers draggable, to expand the vertical space available. When they're expanded, they could show the strips and the keys. When they're collapsed, they could show just the strips.
We could have different modes, to switch between working in terms of keys vs strips, or working only within the bounds of each strip on the timeline vs expanding to show all the keys of a strip when selected.
Nathan: We don't necessarily have to get rid of the dopesheet, but could instead make it a more specialized tool. So most of the time animators will work directly in the Animation Editor, but can drop into the dopesheet for more finicky cases as needed. This would relieve some of the pressure on designing the Animation Editor to be all-powerful, and then it can instead focus on the common cases and workflows.
We can continue to explore both directions, and see which one seems to accommodate real use cases the best:
- A unified animation editor that essentially incorporates the dopesheet.
- A separate animation editor that's just for working with layers and strips, and which leaves keyframe editing to the dopesheet and graph editor.

Meeting 2

With @dfelinto, @brecht, @Sergey.

(Note: we didn't get through all of the mockups in this meeting, just the layered animation flows.)

Layered Animation Flows

Dalai: instead of allowing layer multi-select, can we only allow selecting a single layer at a time? Can the desired workflows work within those constraints?
Brecht:
- Have settings that allow the user to configure behavior for different workflows.
  - For example: a mode to automatically create and use different layers per ID.
- It feels potentially muddy and confusing to have both the "tweak layer" case and the "organization layer" (a.k.a. limited layer) case both handled/represented by the same layers. Maybe we can make these two cases more distinct and clear somehow.
- When mixing the organization and tweak use cases via hierarchical layers, what is the typical organization going to be? E.g. will the top level be the organization layers, each of which has a bunch of tweak layers? Or will the top level be a bunch of tweak layers, each of which has organization layers under it?
- Think about keeping the simple cases simple, and then if the user wants to do something more complex (like mixing the tweak and organization workflows) it means they need to deal with that complexity.
- With limited layers, maybe prevent the user from accidentally moving things that can't be keyed on the current layer.

Meeting 3

With @BassamKurdali.

General

"Pay attention to what people need, not what they say."
Be careful about clever solutions that try to make a problem not happen. It can sometimes be better to let the problem happen, and just make it more pleasant when it does (e.g. giving good, clear feedback to the user and an easy way to resolve it).
When designing "smart" features (where the computer tries to automatically do things for you), figure out its failure modes, and consider their impact.

Data Management (library linked) Flows

Re: the possibility in 2c of automatically hooking up to the new output with the same name:
- "There is no right thing to do." Auto-hooking-up vs simply losing the connection both have cases they get wrong.
- What are the failure modes?
- What if the output name is totally different from the object?
- What if the new output was made for a different purpose?
- Which outcome is more confusing: the failure modes of auto-hooking up, or those of not?
Re: storing an ID's last assigned output name in the ID, and using that to auto-hook-up outputs later:
- The stored name can become stale. E.g. a rigger doing some quick movement tests in the rig file: that output wasn't supposed to be significant/meaningful.
- "If it exists, it shouldn't be hidden." Consider how much the hidden inverse parent transform confuses people.
- "If a system does something smart, it should actually know things, not guess."
- Bassam's recommendation: for a first implementation, keep it simple and do nothing. Add things to handle it later after you get experience.

Merging Animation Editor and Dopesheet

Emotionally, really wants this to work. It would be great.
Bassam's intuition: a unified editor can certainly be built, but it's not clear it would actually be better than separate editors.
The design explorations so far don't hurt the simple case, which is good.
There's an intrinsic amount of complexity in how much information you're trying to display at once.
"Once I've got strips, I probably just want to work with them as strips."
- But maybe the ability to "dive in" within the same editor would be good. Like a "local" view for when the user wants to view just a single strip.
One of the benefits of a unified editor: it's annoying to manage the different timelines in multiple editors.
If it's a unified editor, but everything that varies over time isn't represented and manipulatable in it, then we've somehow failed. However, that doesn't necessarily mean everything at once, which could be overwhelming.
- Example: a frustration of his is that there are a lot of things in Blender whose time aspects can't be directly visually manipulated in an editor right now. For example, you can't drag a function curve modifier around in the graph editor or dopesheet along with the keyframes.

Misc

Not directly relevant to the current targets, but Bassam independently mentioned the "separation of poses vs interpolation" idea. Treating keyframes as full poses, rather than as individual keyframed properties/channels, opens up possibilities.

Meeting 4

With @Mets, @Felipe-G, @EosFoxx, @nrupsis, @nickberckley

(Note: apologies if I've mis-attributed any of the comments below. I failed to note down who said what during the meeting, which was a silly goof. In some cases I've left no attribution, where I totally forgot who said what.)

Layered Animation Flows

Building up animations with adjustment layers:

Nika: There should be a way to select multiple layers for display, while still being able to specify precisely which layer you want keys to go on.
- Nika: active layer? An "active layer" concept would also be good for merging, so the user can specify which layer is getting merged into (for e.g. the name).
Nika: when Blender is choosing among several layers where to put keys, there should be a visual indication of what layer(s) your keys are going to go into. E.g. dots next to the layers that would get keys right now if you hit "i" in the 3d viewport.

Limiting the channels/properties that can go into a layer:

Demeter: the proposed way of doing this could introduce annoying manual maintenance for animators when e.g. a rig is updated with new controls. They would have to manually un-limit the layer, key the new controls, and then re-limit it.
- Demeter: being able to limit layers by object/ID could be more straightforward for that.
- Nathan: true, but it's good to have more granularity if the animator wants to e.g. put the face and body of a character on different layers. You can't do that at the object/ID level. Additionally, some animators really want tight control over exactly what gets keyed in their animations, and might not want the allowed channels to auto-update.
- Nathan: maybe we could have two systems, one for ID-level and one for finer-grained. But we have to be wary of creating too many systems that the user has to juggle in their head and understand. Too many rules makes the system unpredictable in practice.
- Maybe instead of two different systems, we make it easier to manage the more granular system. For example, an operator that adds the animatable properties of the currently selected object(s) to the current layer. Then animators can more quickly update as desired.
Nika: Accidents should be accounted for in the new system, because they will inevitably happen. If someone accidentally keys something on the wrong layer, it should be quick and easy to fix and move to the right layer.

General:

Nika: How will the user see what objects/IDs are using an output in e.g. the channel list in the dopesheet and graph editor?
- Nathan: Good point. We discussed some possibilities in the past, but it kind of fell off the radar.
- Nathan: When there's only one ID, its name could simply replace the output's name in the channel hierarchy. When there's more than one ID, that part of the hierarchy could be duplicated for each ID, under the ID's name. Alternatively, there could be a list of connected IDs along with the output name.
- Nathan: In any case, not sure what the best solution is yet, but definitely needs to be figured out.

Data Management Flows

Linked library flow:

Nika: There should be a "missing output" message when a (used) output has been deleted from the library file. Don't silently try to resolve it.

General:

Nika: How to manage the Animation datablock and outputs of shape keys? They are also their own ID.

Merging Animation Editor and Dopesheet

General consensus: love this idea.
Editor modes are a common thing in Blender. For example, the Movie Clip Editor. Maybe something similar could be used to make a unified editor more manageable.
- Nathan: keep in mind that the more those modes diverge, the more they approach being separate editors anyway. The idea is still very good—it has a lot of merit. Just saying that there's a continuum between fully separate editors and a fully unified editor, and we should be intentional about where we land on that continuum and what we're getting out of it
It's annoying to manage the separate timelines in different editors.
- Some way of linking the timeline between animation editors would be good anyway, because we'll (presumably) at least still have the graph editor as a separate editor.
Re: the UI for animating influence:
- Maybe look at how the sequence editor does it.
- The influence keys could simply be overlayed on top of the strips.
  - Use a toggle to switch between editing the influence keys vs editing the strips.

These are my notes from the meetings I've had with people about the mockups so far. I did my best to accurately represent what people said, but of course may have made some mistakes or missed things. If I misrepresented or missed a point of yours, don't hesitate to say so! ## Meeting 1 With @dr.sybren. ### Data Management Flows - Sybren prefers the idea of storing an ID's last assigned output name in the ID, and using that to auto-hook-up IDs with outputs later. - Nathan: I have some gut-feeling reservations, but no concrete objections yet. - We'll move forward with that for now. If concrete objections manifest, we can revisit it then. ### Merging Animation Editor and Dopesheet - Layer influence keyframes could be visualized at the top of the layer, to avoid getting in the way of the channel keyframes at the bottom. - Keyframes on the border of two strips: if we do the top/bottom split with strip handles on the top and keys on the bottom, the strip handles should not extend to the bottom. This is because it makes selecting keys on the border of the strips ambiguous. Additionally, it may make sense to have two rows for the keys so that they can be staggered to make room for the edge keys of abutting strips. - We could make the borders between layers draggable, to expand the vertical space available. When they're expanded, they could show the strips and the keys. When they're collapsed, they could show just the strips. - We could have different modes, to switch between working in terms of keys vs strips, or working only within the bounds of each strip on the timeline vs expanding to show all the keys of a strip when selected. - Nathan: We don't necessarily have to get rid of the dopesheet, but could instead make it a more specialized tool. So most of the time animators will work directly in the Animation Editor, but can drop into the dopesheet for more finicky cases as needed. This would relieve some of the pressure on designing the Animation Editor to be all-powerful, and then it can instead focus on the common cases and workflows. - We can continue to explore both directions, and see which one seems to accommodate real use cases the best: - A unified animation editor that essentially incorporates the dopesheet. - A separate animation editor that's just for working with layers and strips, and which leaves keyframe editing to the dopesheet and graph editor. ## Meeting 2 With @dfelinto, @brecht, @Sergey. (Note: we didn't get through all of the mockups in this meeting, just the layered animation flows.) ### Layered Animation Flows - Dalai: instead of allowing layer multi-select, can we only allow selecting a single layer at a time? Can the desired workflows work within those constraints? - Brecht: - Have settings that allow the user to configure behavior for different workflows. - For example: a mode to automatically create and use different layers per ID. - It feels potentially muddy and confusing to have both the "tweak layer" case and the "organization layer" (a.k.a. limited layer) case both handled/represented by the same layers. Maybe we can make these two cases more distinct and clear somehow. - When mixing the organization and tweak use cases via hierarchical layers, what is the typical organization going to be? E.g. will the top level be the organization layers, each of which has a bunch of tweak layers? Or will the top level be a bunch of tweak layers, each of which has organization layers under it? - Think about keeping the simple cases simple, and then if the user wants to do something more complex (like mixing the tweak and organization workflows) it means they need to deal with that complexity. - With limited layers, maybe prevent the user from accidentally moving things that can't be keyed on the current layer. ## Meeting 3 With @BassamKurdali. ### General - "Pay attention to what people need, not what they say." - Be careful about clever solutions that try to make a problem not happen. It can sometimes be better to let the problem happen, and just make it more pleasant when it does (e.g. giving good, clear feedback to the user and an easy way to resolve it). - When designing "smart" features (where the computer tries to automatically do things for you), figure out its failure modes, and consider their impact. ### Data Management (library linked) Flows - Re: the possibility in 2c of automatically hooking up to the new output with the same name: - "There is no right thing to do." Auto-hooking-up vs simply losing the connection both have cases they get wrong. - What are the failure modes? - What if the output name is totally different from the object? - What if the new output was made for a different purpose? - Which outcome is more confusing: the failure modes of auto-hooking up, or those of not? - Re: storing an ID's last assigned output name in the ID, and using that to auto-hook-up outputs later: - The stored name can become stale. E.g. a rigger doing some quick movement tests in the rig file: that output wasn't supposed to be significant/meaningful. - "If it exists, it shouldn't be hidden." Consider how much the hidden inverse parent transform confuses people. - "If a system does something smart, it should actually know things, not guess." - Bassam's recommendation: for a first implementation, keep it simple and do nothing. Add things to handle it later after you get experience. ### Merging Animation Editor and Dopesheet - Emotionally, really wants this to work. It would be great. - Bassam's intuition: a unified editor can certainly be built, but it's not clear it would actually be better than separate editors. - The design explorations so far don't hurt the simple case, which is good. - There's an intrinsic amount of complexity in how much information you're trying to display at once. - "Once I've got strips, I probably just want to work with them as strips." - But maybe the ability to "dive in" within the same editor would be good. Like a "local" view for when the user wants to view just a single strip. - One of the benefits of a unified editor: it's annoying to manage the different timelines in multiple editors. - If it's a unified editor, but everything that varies over time isn't represented and manipulatable in it, then we've somehow failed. However, that doesn't necessarily mean everything *at once*, which could be overwhelming. - Example: a frustration of his is that there are a lot of things in Blender whose time aspects can't be directly visually manipulated in an editor right now. For example, you can't drag a function curve modifier around in the graph editor or dopesheet along with the keyframes. ### Misc - Not directly relevant to the current targets, but Bassam independently mentioned the "separation of poses vs interpolation" idea. Treating keyframes as full poses, rather than as individual keyframed properties/channels, opens up possibilities. ## Meeting 4 With @Mets, @Felipe-G, @EosFoxx, @nrupsis, @nickberckley (Note: apologies if I've mis-attributed any of the comments below. I failed to note down who said what during the meeting, which was a silly goof. In some cases I've left no attribution, where I totally forgot who said what.) ### Layered Animation Flows Building up animations with adjustment layers: - Nika: There should be a way to select multiple layers for display, while still being able to specify precisely which layer you want keys to go on. - Nika: active layer? An "active layer" concept would also be good for merging, so the user can specify which layer is getting merged into (for e.g. the name). - Nika: when Blender is choosing among several layers where to put keys, there should be a visual indication of what layer(s) your keys are going to go into. E.g. dots next to the layers that would get keys right now if you hit "i" in the 3d viewport. Limiting the channels/properties that can go into a layer: - Demeter: the proposed way of doing this could introduce annoying manual maintenance for animators when e.g. a rig is updated with new controls. They would have to manually un-limit the layer, key the new controls, and then re-limit it. - Demeter: being able to limit layers by object/ID could be more straightforward for that. - Nathan: true, but it's good to have more granularity if the animator wants to e.g. put the face and body of a character on different layers. You can't do that at the object/ID level. Additionally, some animators really want tight control over exactly what gets keyed in their animations, and might not want the allowed channels to auto-update. - Nathan: maybe we could have two systems, one for ID-level and one for finer-grained. But we have to be wary of creating too many systems that the user has to juggle in their head and understand. Too many rules makes the system unpredictable in practice. - Maybe instead of two different systems, we make it easier to manage the more granular system. For example, an operator that adds the animatable properties of the currently selected object(s) to the current layer. Then animators can more quickly update as desired. - Nika: Accidents should be accounted for in the new system, because they will inevitably happen. If someone accidentally keys something on the wrong layer, it should be quick and easy to fix and move to the right layer. General: - Nika: How will the user see what objects/IDs are using an output in e.g. the channel list in the dopesheet and graph editor? - Nathan: Good point. We discussed some possibilities in the past, but it kind of fell off the radar. - Nathan: When there's only one ID, its name could simply replace the output's name in the channel hierarchy. When there's more than one ID, that part of the hierarchy could be duplicated for each ID, under the ID's name. Alternatively, there could be a list of connected IDs along with the output name. - Nathan: In any case, not sure what the best solution is yet, but definitely needs to be figured out. ### Data Management Flows Linked library flow: - Nika: There should be a "missing output" message when a (used) output has been deleted from the library file. Don't *silently* try to resolve it. General: - Nika: How to manage the Animation datablock and outputs of shape keys? They are also their own ID. ### Merging Animation Editor and Dopesheet - General consensus: love this idea. - Editor modes are a common thing in Blender. For example, the Movie Clip Editor. Maybe something similar could be used to make a unified editor more manageable. - Nathan: keep in mind that the more those modes diverge, the more they approach being separate editors anyway. The idea is still very good—it has a lot of merit. Just saying that there's a continuum between fully separate editors and a fully unified editor, and we should be intentional about where we land on that continuum and what we're getting out of it - It's annoying to manage the separate timelines in different editors. - Some way of linking the timeline between animation editors would be good anyway, because we'll (presumably) at least still have the graph editor as a separate editor. - Re: the UI for animating influence: - Maybe look at how the sequence editor does it. - The influence keys could simply be overlayed on top of the strips. - Use a toggle to switch between editing the influence keys vs editing the strips.

👍 3 ❤️ 1

Raymond-Luc commented

2024-02-16 11:23:49 +01:00

Hi there! Adding some of the feedback collected by the Dillongoo Studios animation team in terms of what we would like from the new animation editor and what we would like to keep from the old systems, as well as some wish-list ideas.

For the unified animation editor:

Combining the Camera data with its properties would be very nice. If you have the camera open in the action editor right now it only shows the transform options. We edit the focal length so often that having consolidating them in the same space would save lots of time
More filter options would be very useful. Being able to filter keyframes based on separate collections, armatures, etc. The main benefit of the action editor is being able to isolate the keyframes for one rig at a time. Ideally we'd be able to recreate that functionality in the new system as well through alternative means.
The main benefit of the action editor for us is that it lets us use the show all filter without displaying the entire scenes keyframe data. The dopesheet doesn't let you do this since it'll display keyframes for everything, rather than just the keyframes for one character
Being able to custom sort the order in which information is being displayed in the summary menu on the left. For example moving Bob above monster or monster above bob in the provided screenshot
Grouping channels in the new unified editor should be a visual sorting feature rather than removing the bone names as it currently works. Right now if you were to group all the FK bones in the dopesheet of a character, it removes the names of all the bones you had selected and populates one mass list of transform channels that are hard to read.
Fuzzy search for the search menu would be great. A way to combine a search for Z quaternion and Z euler rotations is something I've always wanted since our rigs include both kinds of rotation modes. Bonus points if this fuzzy search works in the graph editor as well so that searching items by typing Z R would be possible.
Hiding the stash/Push down buttons

Wish-list ideas:

Being able to mute a vertical column of keyframes would be useful. Temporarily hide specific keys from interpolation to be able to see where the animation can be simplified or to see where tweening issues are coming from.
A way to make rig properties more intuitive on where they are displayed (IK parents, follow spaces and such).

Currently they are only on bones that the property lives on which are hard to edit the keyframes if you don't know which bones they are attached to ( EX: head follow on the torso bone in rigify)

Hi there! Adding some of the feedback collected by the Dillongoo Studios animation team in terms of what we would like from the new animation editor and what we would like to keep from the old systems, as well as some wish-list ideas. For the unified animation editor: - Combining the Camera data with its properties would be very nice. If you have the camera open in the action editor right now it only shows the transform options. We edit the focal length so often that having consolidating them in the same space would save lots of time - More filter options would be very useful. Being able to filter keyframes based on separate collections, armatures, etc. The main benefit of the action editor is being able to isolate the keyframes for one rig at a time. Ideally we'd be able to recreate that functionality in the new system as well through alternative means. - The main benefit of the action editor for us is that it lets us use the show all filter without displaying the entire scenes keyframe data. The dopesheet doesn't let you do this since it'll display keyframes for everything, rather than just the keyframes for one character - Being able to custom sort the order in which information is being displayed in the summary menu on the left. For example moving Bob above monster or monster above bob in the provided screenshot - Grouping channels in the new unified editor should be a visual sorting feature rather than removing the bone names as it currently works. Right now if you were to group all the FK bones in the dopesheet of a character, it removes the names of all the bones you had selected and populates one mass list of transform channels that are hard to read. - Fuzzy search for the search menu would be great. A way to combine a search for Z quaternion and Z euler rotations is something I've always wanted since our rigs include both kinds of rotation modes. Bonus points if this fuzzy search works in the graph editor as well so that searching items by typing Z R would be possible. - Hiding the stash/Push down buttons Wish-list ideas: - Being able to mute a vertical column of keyframes would be useful. Temporarily hide specific keys from interpolation to be able to see where the animation can be simplified or to see where tweening issues are coming from. - A way to make rig properties more intuitive on where they are displayed (IK parents, follow spaces and such). Currently they are only on bones that the property lives on which are hard to edit the keyframes if you don't know which bones they are attached to ( EX: head follow on the torso bone in rigify)

bob monster vs monster bob.png

141 KiB

❤️ 2

Nathan Vegdahl commented

2024-02-29 12:08:09 +01:00

Notes from my meeting with @BClark:

Layered Animation Flows

For deciding which layer keys go to when multiple layers are selected: instead of rule-based, just use the "active" concept from elsewhere in Blender and have an active layer.
Auto-switching which layer(s) are selected/active when changing object selection might not be necessary.
- The user can rely on limiting the layers to prevent keys accidentally going to unintended layers.
- We can still visually highlight layers relevant to the currently selected object(s)/bone(s), so the user can see at-a-glance which layers can take those keys.
Good tools for merging and splitting layers is critical. The user should never be "trapped" into a particular organization of data because of an early decision.
Wants to be able to see the final result of the mixed animation, e.g. in the graph editor.

Data Management Flows

Similar to merging/splitting layers, we need to ensure there are good tools for merging/splitting Animation datablocks. Again, the user should never be trapped into a particular way of organizing their animation data.
When switching Animation datablocks via the drop-down selector, it would be useful to have a visual indication of which ones have matching Outputs for the current ID.

Merging Animation Editor and Dopesheet

Be clear about what the Animation Editor is meant to do, and what it's responsible for.
A potential disadvantage of separate editors: it increases the chances of (what should be) shared functionality diverging over time. For example, consider how the available animation tools are not the same in the 3D viewport between object and pose mode, even though those tools ought to be relevant to both. Avoiding that kind of divergence is something we should strive for.

Notes from my meeting with @BClark: ### Layered Animation Flows - For deciding which layer keys go to when multiple layers are selected: instead of rule-based, just use the "active" concept from elsewhere in Blender and have an active layer. - Auto-switching which layer(s) are selected/active when changing object selection might not be necessary. - The user can rely on limiting the layers to prevent keys accidentally going to unintended layers. - We can still *visually highlight* layers relevant to the currently selected object(s)/bone(s), so the user can see at-a-glance which layers can take those keys. - Good tools for merging and splitting layers is critical. The user should never be "trapped" into a particular organization of data because of an early decision. - Wants to be able to see the final result of the mixed animation, e.g. in the graph editor. ### Data Management Flows - Similar to merging/splitting layers, we need to ensure there are good tools for merging/splitting `Animation` datablocks. Again, the user should never be trapped into a particular way of organizing their animation data. - When switching `Animation` datablocks via the drop-down selector, it would be useful to have a visual indication of which ones have matching `Output`s for the current ID. ### Merging Animation Editor and Dopesheet - Be clear about what the Animation Editor is meant to do, and what it's responsible for. - A potential disadvantage of separate editors: it increases the chances of (what should be) shared functionality diverging over time. For example, consider how the available animation tools are not the same in the 3D viewport between object and pose mode, even though those tools ought to be relevant to both. Avoiding that kind of divergence is something we should strive for.

👍 1

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Initial UX design for the new Animation data model #118008

Don't Ruin Existing Workflows / Simple Things Should Be Simple

Layered Animation Workflows

What Value of Keys Get Inserted?

Where Do Keys Go?

1. No Animation Datablock

2. No Layers / Strips

3. More Than One Layer/Strip

Graph Editor and Dopesheet

The New Animation Editor

Multiple Animation Datablocks

Unify the Animation Editor and Dopesheet Into One Thing?

Advantages

Challenges

Animating Layer Influence

Data Management

Assigning Animations to IDs

Managing an Animation Datablock's Outputs

Meeting 1

Data Management Flows

Merging Animation Editor and Dopesheet

Meeting 2

Layered Animation Flows

Meeting 3

General

Data Management (library linked) Flows

Merging Animation Editor and Dopesheet

Misc

Meeting 4

Layered Animation Flows

Data Management Flows

Merging Animation Editor and Dopesheet

Layered Animation Flows

Data Management Flows

Merging Animation Editor and Dopesheet