Update Action documentation #104974

Merged
Nathan Vegdahl merged 8 commits from nathanvegdahl/blender-manual:slotted_actions into main 2024-11-11 15:52:29 +01:00
6 changed files with 37 additions and 16 deletions
Showing only changes of commit 1156f55fe0 - Show all commits

View File

@ -12,25 +12,31 @@ The benefit of this approach is that animation data can be flexibly organized an
Action Slots
============
The animation data inside an action is further organized into *Slots*. Each slot has animation data for a single data-block, and an animated data-block must specify not only which action it uses but also which slot within that action it uses.
The animation data inside an action is further organized into *Slots*. Each action has a set of slots and different animation data for each of those slots. An animated data-block then specifies both which action it uses and also which slot within that action it uses, and that determines which animation data the data-block is animated by.
nathanvegdahl marked this conversation as resolved Outdated

The combination of "both" and "and also" seems a bit much, especially with the doubling of "it uses". Maybe just "…specifies both an action and a slot within that action, and that determines…"?

The combination of "both" and "and also" seems a bit much, especially with the doubling of "it uses". Maybe just "…specifies both an action and a slot within that action, and that determines…"?
.. figure:: /images/animation_actions_slots_ui.png
Action selector and its accompanying slot selector. **TODO: create this screenshot.**
Action selector and its accompanying slot selector in the properties of an object, for seeing and selecting which action and slot animate the object.
Slots allow an action to store animation data for more than one data-block at a time. For example, you may have an animation of a bouncing ball that changes its color on each bounce. That would involve two data-blocks: the object and its material. Slots allow you to put both the object's animation and the material's animation in the same action by having a slot for each.
The purpose of slots is to allow an action to store distinct animation data for multiple data-blocks. For example, you may have an animation of a bouncing ball that changes its color on each bounce, and that involves two data-blocks: the object and its material. Slots allow you to put both the object's animation and the material's animation in the same action by having a different slot for each.
.. figure:: /images/animation_actions_slots_diagram.png
.. figure:: /images/animation_actions_slots_diagram_object_and_material.png
Visualization of a ball and its material connected to different slots in an action. **TODO: create this diagram.**
In this example there is one slot for an object and one slot for a material, but you can have as many slots as you like for as many objects, materials, lights, etc. as you like. If you're baking down a simulation of *100* bouncing balls, you could store that animation in single action with 100 slots.
In this example there is one slot for an object and one slot for a material, but you can have as many slots as you like for as many objects, materials, lights, etc. as you like. If you're baking down a simulation of 100 bouncing balls, you could store that animation in single action with 100 slots.
Not all actions need to take advantage of slots: you are free to use 100 separate actions for all those bouncing balls if you prefer. Nevertheless, animation data in an action is always organized into slots, and therefore you need at least one slot in an action in order to animate something.
.. figure:: /images/animation_actions_slots_diagram_many_objects.png
Visualization of many balls all connected to different slots in an action. **TODO: create this diagram.**
Not all actions need to take advantage of slots: you are free to use 100 separate actions for all those bouncing balls if you prefer. Nevertheless, the animation data in an action is always organized into slots, and therefore you need at least one slot in an action in order to animate something.
Note that slots are not "for" any specific data-block: any data-block can use any slot. For example, you can have two different characters use the same slot in the same action, and they'll both simply get animated by the same animation data. Slots are just a way to organize distinct animation data within an action, and don't have any intrinsic attachment to anything in the scene.
.. note::
Internally, the animation data in an action is further organized into layers and strips. This is not currently exposed in the UI and does not impact how you utilize actions right now. It is purely in preparation for future animation features that are not yet in Blender, and can be safely ignored for now.
Internally, the animation data in an action is further organized into layers and strips. This is not currently exposed in the UI and does not impact how you use actions right now. It is purely in preparation for future animation features that are not yet in Blender, and you can safely ignore it for now.
However, layers and strips *are* exposed in the Python API, so you will need to be aware of this when writing scripts and addons that work with actions. See the Python API documentation for more details.
@ -41,17 +47,17 @@ Each slot in an action has a name. You can set these names however you like, bu
In addition to having a name, each slot also has an associated data-block type that it is intended for (for example, "material", "object", etc.). This is set automatically when a slot is first assigned to animate a data-block.
In the animation editors you can see the associated type of each slot displayed as an icon next to its name in the channel list.
In the action editor's channel list you can see the associated type of each slot displayed as an icon next to its name.
dr.sybren marked this conversation as resolved Outdated

This is also shown in the side-panel of the Action editor, whenever there is an active Slot.

This is also shown in the side-panel of the Action editor, whenever there is an active Slot.

That's true, but I wasn't meaning to be exhaustive here, but rather give one place that this is visible to help illustrate the concept. I'll try rephrasing to make that clearer.

That's true, but I wasn't meaning to be exhaustive here, but rather give one place that this is visible to help illustrate the concept. I'll try rephrasing to make that clearer.
.. figure:: /images/animation_actions_slots_in_channel_list.png
Slots displayed in the :doc:`Dopesheet Editor's </editors/dope_sheet/introduction>` channel list, with their associated type as an icon. **TODO: create this screenshot.**
Slots displayed in the :doc:`Action Editor's </editors/dope_sheet/modes/action>` channel list, with their associated type as an icon.
A slot must have a unique combination of name + associated type within its action. For example, you can have two slots named "Cube" in an action as long as one of them is for objects and the other is for materials, but not if they are both for objects.
nathanvegdahl marked this conversation as resolved Outdated

A slot must have a unique combination of name + associated type within its action.

This is a bit ambiguous, as it can be read as (name) + (associated type within its action). Maybe it's better to elaborate a bit more, at the cost of some repetition (which in itself might be good, as this is a complex topic until it clicks). How's this?

"As described above, each slot has a name and an associated type. This combination of name + type has to be unique within its action."

but not if they are both for objects.

It might help to clarify things when you describe the 'positive case' here. So instead of saying that it doesn't work when they are both for object, explain what it would look like if that were the case. Something like:

"When they are both for objects, their associated type is the same, and thus they have to have different names. Blender will use the familiar approach and name them Cube and Cube.001."

Actually, I think you can keep the 'it doesn't work when they are both for object' text, and just add the above as well.

> A slot must have a unique combination of name + associated type within its action. This is a bit ambiguous, as it can be read as (name) + (associated type within its action). Maybe it's better to elaborate a bit more, at the cost of some repetition (which in itself might be good, as this is a complex topic until it clicks). How's this? "As described above, each slot has a name and an associated type. This combination of name + type has to be unique within its action." > but not if they are both for objects. It might help to clarify things when you describe the 'positive case' here. So instead of saying that it doesn't work when they are both for object, explain what it would look like if that were the case. Something like: "When they are both for objects, their associated type is the same, and thus they have to have different names. Blender will use the familiar approach and name them `Cube` and `Cube.001`." Actually, I think you can keep the 'it doesn't work when they are both for object' text, and just add the above as well.

This is a bit ambiguous, as it can be read as (name) + (associated type within its action).

Ah! Good catch. I think it can be fixed by just rearranging the clauses: "Within an action, a slot must have a unique combination of name + associated type."

> This is a bit ambiguous, as it can be read as (name) + (associated type within its action). Ah! Good catch. I think it can be fixed by just rearranging the clauses: "Within an action, a slot must have a unique combination of name + associated type."
.. note::
Although it's not useful, and Blender tries to make it difficult to do, it is nevertheless possible cause slots to get assigned to a data-block of the wrong type. For example, assigning a slot intended for materials to an object. Nothing bad happens if you manage to do this, but the F-Curves of that slot are unlikely to match any properties on the mismatched data-block, and therefore won't animate anything.
Although it's not useful, and Blender makes this difficult to do, it is nevertheless possible to cause slots to get assigned to a data-block of the wrong type. For example, assigning a slot intended for materials to an object. Nothing bad happens if you manage to do this, but the F-Curves of that slot are unlikely to match any properties on the mismatched data-block, and therefore won't animate anything.
F-Curves & Channels
===================
@ -62,18 +68,18 @@ F-Curves & Channels
:doc:`Graph Editor</editors/graph_editor/introduction>`, displaying three F-Curves for three different properties.
Blender's animation editors (such as the dopesheet, graph editor, etc.) have a **channel list** on the left side that display animated properties. For actions, these channels correspond to the F-Curves that animate those properties.
Blender's animation editors (such as the dopesheet, graph editor, etc.) have a **channel list** on their left side that display animated properties. For actions, these channels correspond to the F-Curves that animate those properties.
.. figure:: /images/animation_actions_channels_and_groups.png
The :doc:`Dopesheet Editor's </editors/dope_sheet/introduction>` channel list, with the animated channels of various bones. **TODO: create this screenshot.**
The :doc:`Dopesheet Editor's </editors/dope_sheet/introduction>` channel list, with the animated channels of various bones grouped under their bone names.
Channels also support a limited form of organization called "channel groups". For example, by default Blender creates a channel group for the channels of each bone. These groups are purely for your convenience and have no impact on how Blender interprets or uses the channels.
Channels also support a limited form of organization called "channel groups". For example, by default Blender creates a channel group for the channels of each bone. These groups are purely for your convenience and have no impact on how Blender interprets the channels.
dr.sybren marked this conversation as resolved Outdated

These groups are purely for your convenience and have no impact on how Blender interprets the channels.

😹 if only that were true. AFAIK there's still code that loops over the groups, and assumes that this is enough to get the list of animated bones. IMO that's just a bad implementation and if (well, when) this causes issues for people it's great to get a bug report about this so it can get fixed.

> These groups are purely for your convenience and have no impact on how Blender interprets the channels. 😹 if only that were true. AFAIK there's still code that loops over the groups, and assumes that this is enough to get the list of animated bones. IMO that's just a bad implementation and if (well, when) this causes issues for people it's great to get a bug report about this so it can get fixed.

I'm unclear on what you want here: should I change this or leave it as-is? I was aware I was lying here (😆), but I felt like it was a "good" lie for the reasons you outlined.

I'm unclear on what you want here: should I change this or leave it as-is? I was aware I was lying here (😆), but I felt like it was a "good" lie for the reasons you outlined.

Yeah, just keep the lie, as at some point in the future it'll "automatically" become true.

Yeah, just keep the lie, as at some point in the future it'll "automatically" become true.
Working With Actions
====================
When you first animate an object (or other data-block) in Blender, Blender tries to automatically find an appropriate action for it, or if it can't find an appropriate action then it will create one. After assigning that action, it also creates and assigns a new slot for the data-block.
When you first animate an object (or other data-block) in Blender, Blender tries to automatically find an appropriate action for it, or if it can't find an appropriate action then it will create one. After an action has been assigned, it also creates and assigns a new slot for the data-block.
.. note::
The full heuristics Blender uses to find an appropriate action are beyond the scope of this manual, but can be summarized as: look for actions on closely related attached data-blocks. For example, if a camera object is already animated and you're now inserting keys for its fov (which lives on the camera data, *not* the camera object), the action the object is using will be reused for the camera data as well. For more details on these heuristics, see **TODO**.
nathanvegdahl marked this conversation as resolved Outdated

The full heuristics Blender uses to find an appropriate action are beyond the scope of this manual

I think it's good to explain why. Even when this heuristic might change in the future, I don't see it being in constant flux, and thus IMO it would be fine to just explain how it works.

its fov

Use proper puncuation to indicate this is an abbreviation, and make it link to the glossary. Or just write "Field of View". And link it to the glossary.

> The full heuristics Blender uses to find an appropriate action are beyond the scope of this manual I think it's good to explain why. Even when this heuristic might change in the future, I don't see it being in constant flux, and thus IMO it would be fine to just explain how it works. > its fov Use proper puncuation to indicate this is an abbreviation, and make it link to the glossary. Or just write "Field of View". And link it to the glossary.

I don't see it being in constant flux, and thus IMO it would be fine to just explain how it works.

I agree it's unlikely to change much, if at all. The reason I left it out of scope is because of how detailed the heuristics are (basically a table of which data-blocks are considered related and when), and knowing the details doesn't seem important to normal usage...? Where the specific details become more relevant is when doing scripting that interacts with this, I think?

So instead I opted to give the broad idea behind it, and refer people elsewhere for people who do need the details. Although as is clear from the todo, I don't know where yet. But I agree that it should be documented somewhere.

> I don't see it being in constant flux, and thus IMO it would be fine to just explain how it works. I agree it's unlikely to change much, if at all. The reason I left it out of scope is because of how detailed the heuristics are (basically a table of which data-blocks are considered related and when), and knowing the details doesn't seem important to normal usage...? Where the specific details become more relevant is when doing scripting that interacts with this, I think? So instead I opted to give the broad idea behind it, and refer people elsewhere for people who do need the details. Although as is clear from the todo, I don't know where yet. But I agree that it should be documented *somewhere*.

Re: explaining the related data-blocks: after sleeping on it over the weekend, I think I've come around to explaining this in a bit more detail, and then we can get rid of the TODO to link it. I'll try to explain it as concisely as I can without turning it into a table. It probably won't be fully detailed, but should give enough info for users to predict what will happen in typical cases.

Re: explaining the related data-blocks: after sleeping on it over the weekend, I think I've come around to explaining this in a bit more detail, and then we can get rid of the TODO to link it. I'll try to explain it as concisely as I can without turning it into a table. It probably won't be fully detailed, but should give enough info for users to predict what will happen in typical cases.
@ -87,13 +93,13 @@ In the properties of each data-block there is an Animation panel with action and
nathanvegdahl marked this conversation as resolved Outdated

Add an explanation as to why you would do this. Also include that you can assign an action but keep the slot unassigned, and what you'd use that for.

Add an explanation as to _why_ you would do this. Also include that you can assign an action but keep the slot unassigned, and what you'd use that for.
.. figure:: /images/animation_actions_properties_action_slot_selector.png
The action and slot selector for Camera data in the :doc:`Properties Editor </editors/properties_editor>`. **TODO: create this screenshot.**
The action and slot selector for Camera data in the :doc:`Properties Editor </editors/properties_editor>`.
For the active object you can also assign its action and slot in the action Editor's header.
.. figure:: /images/animation_actions_action_editor_action_slot_selector.png
The action and slot selector for the active object in the :doc:`Action Editor </editors/dope_sheet/modes/action>`. **TODO: create this screenshot.**
The action and slot selector for the active object (in this case a camera object) in the :doc:`Action Editor </editors/dope_sheet/modes/action>`.
.. note::

Binary file not shown.

BIN
manual/images/animation_actions_channels_and_groups.png (Stored with Git LFS) Normal file

Binary file not shown.

Binary file not shown.

BIN
manual/images/animation_actions_slots_in_channel_list.png (Stored with Git LFS) Normal file

Binary file not shown.

BIN
manual/images/animation_actions_slots_ui.png (Stored with Git LFS) Normal file

Binary file not shown.