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
Member

This updates the manual's Action page in two ways:

  • General clean up and better explanations, because what was there before
    was quite sparse.
  • Add documentation for the new action slot system.
This updates the manual's Action page in two ways: - General clean up and better explanations, because what was there before was quite sparse. - Add documentation for the new action slot system.
Nathan Vegdahl added the
Module
Animation & Rigging
label 2024-10-17 16:12:31 +02:00
Nathan Vegdahl added 1 commit 2024-10-17 16:12:33 +02:00

looking good, very nice update. The order makes sense to me.
For For more details on these heuristics, see TODO. where would we send the reader? Source code?
I'd advise against explaining that in text because we might change it as we go and it might go out of sync with the manual.
I think the explanation of "Blender tries to be helpful" is enough

looking good, very nice update. The order makes sense to me. For ` For more details on these heuristics, see TODO.` where would we send the reader? Source code? I'd advise against explaining that in text because we might change it as we go and it might go out of sync with the manual. I think the explanation of "Blender tries to be helpful" is enough
Nathan Vegdahl added 1 commit 2024-11-07 16:08:39 +01:00
- Phrasing improvements.
- Add screenshots.
Sybren A. Stüvel reviewed 2024-11-08 11:28:20 +01:00
@ -5,70 +5,111 @@
Actions
*******

Not sure if the glossary entry for 'Action' already links here, but might be worth checking & adding if it doesn't.

Not sure if the glossary entry for 'Action' already links here, but might be worth checking & adding if it doesn't.
Author
Member

Added a glossary entry for "Action" and made it link back here.

Added a glossary entry for "Action" and made it link back here.
nathanvegdahl marked this conversation as resolved
@ -7,3 +7,2 @@
When animating objects and properties in Blender, Actions record and contain the data.
As everything else in Blender, Actions are data-blocks.
*Actions* are Blender's container for animation data. For example, when you animate the location of an object, that animation is stored in an action rather than directly on the object itself. The object then uses the action to get animated, much the same way that a mesh uses a material to get shaded. All animatable data-blocks (objects, meshes, materials, etc.) are animated this way: they don't store their own animation data, but instead use an action that stores the animation data for them.

It may help to keep the word Action capitalised, to emphasise that it's the name of a data-block, rather than a normal noun. No strong preference though, and the rest of the text consistently uses 'normal case'.

When talking about meshes, materials, and shading, add a link to the relevant chapter of the documentation.


data-blocks

Link to the glossary


And as a meta-thing: maybe it's a good idea to rewrap paragraphs instead of having them as long sentences, if anything it'll make reviewing the PR easier (with Gitea's one-note-per-line limitation).

It may help to keep the word Action capitalised, to emphasise that it's the name of a data-block, rather than a normal noun. No strong preference though, and the rest of the text consistently uses 'normal case'. When talking about meshes, materials, and shading, add a link to the relevant chapter of the documentation. ------ > data-blocks Link to the glossary ------ And as a meta-thing: maybe it's a good idea to rewrap paragraphs instead of having them as long sentences, if anything it'll make reviewing the PR easier (with Gitea's one-note-per-line limitation).
Author
Member

Good point about the wrapping. I'll do that after I've addressed the rest of your comments.

Re: keeping Action capitalized, I agree and actually initially wrote it that way. I changed it to be consistent with the rest of the manual (I didn't read the whole manual, but checked a handful of randomly selected pages, and none of them capitalized things that way), which I think is more important. Might be something to change throughout the manual at some point.

Good point about the wrapping. I'll do that after I've addressed the rest of your comments. Re: keeping Action capitalized, I agree and actually initially wrote it that way. I changed it to be consistent with the rest of the manual (I didn't read the whole manual, but checked a handful of randomly selected pages, and none of them capitalized things that way), which I think is more important. Might be something to change throughout the manual at some point.
nathanvegdahl marked this conversation as resolved
@ -14,3 +14,2 @@
So when you animate an object by changing its location with keyframes,
the animation is saved to the Action.
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.

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…"?
nathanvegdahl marked this conversation as resolved
Nathan Vegdahl added 1 commit 2024-11-08 11:46:56 +01:00
Sybren A. Stüvel requested changes 2024-11-08 11:50:35 +01:00
Dismissed
@ -10,3 +9,3 @@
.. figure:: /images/animation_actions_data3.png
The benefit of this approach is that animation data can be flexibly organized and reused. For example, if you're building a library of animations (run cycles, jumps, idling, etc.), each animation can go into its own action, which can then be linked or imported into other files to be reused as needed.

Add that an Action is also a data-block, and thus that it can be appended/linked to other files.

Add that an Action is also a data-block, and thus that it can be appended/linked to other files.
nathanvegdahl marked this conversation as resolved
@ -22,0 +43,4 @@
Slot Names and Associated Types
-------------------------------
Each slot in an action has a name. You can set these names however you like, but by default slots are named after the data-block they were initially created for.

You can set these names however you like, but by default slots are named after the data-block they were initially created for.

I'd split this up into two sentences, as the "but" implies some [I can't come up with the right word here. Conflct? Negativity?] that simply doesn't exist.

> You can set these names however you like, but by default slots are named after the data-block they were initially created for. I'd split this up into two sentences, as the "but" implies some [I can't come up with the right word here. Conflct? Negativity?] that simply doesn't exist.
nathanvegdahl marked this conversation as resolved
@ -22,0 +47,4 @@
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 action editor's channel list you can see the associated type of each slot displayed as an icon next to its name.

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.
Author
Member

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.
dr.sybren marked this conversation as resolved
@ -22,0 +53,4 @@
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.

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.
Author
Member

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."
nathanvegdahl marked this conversation as resolved
@ -42,2 +75,3 @@
The :doc:`Dopesheet Editor's </editors/dope_sheet/introduction>` channel list, with the animated channels of various bones grouped under their bone names.
.. _actions-workflow:
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.

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.
Author
Member

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.
dr.sybren marked this conversation as resolved
@ -50,2 +83,3 @@
The Action data-block menu.
.. 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**.

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.
Author
Member

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*.
Author
Member

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.
nathanvegdahl marked this conversation as resolved
@ -56,3 +90,1 @@
*Actions* can be managed with the *Action data-block menu*
in the Dope Sheet :doc:`Action Editor </editors/dope_sheet/modes/action>` header,
or the Sidebar region of the :doc:`NLA Editor </editors/nla/sidebar>`.
Rather than letting Blender automatically choose an action and slot for a data-block, you can also manually assign them.

"Rather than" → "In addition to"

"Rather than" → "In addition to"
nathanvegdahl marked this conversation as resolved
@ -60,3 +92,1 @@
If you are making multiple actions for the same object,
press the shield button for each action.
This will give the actions a *Fake User* and will make Blender save the unlinked actions.
In the properties of each data-block there is an Animation panel with action and slot selectors. You can use these to assign actions and slots to a data-block.

In the properties of each data-block

This is not true. We've only added them to the Properties editor, which doesn't include every data-block type.

> In the properties of each data-block This is not true. We've only added them to the Properties editor, which doesn't include every data-block type.
Author
Member

That's what I was intending to get across, but clearly failed, ha ha. I'll try rephrasing to make that clearer, without getting too verbose.

That's what I was intending to get across, but clearly failed, ha ha. I'll try rephrasing to make that clearer, without getting too verbose.
nathanvegdahl marked this conversation as resolved
@ -61,3 +92,2 @@
press the shield button for each action.
This will give the actions a *Fake User* and will make Blender save the unlinked actions.
In the properties of each data-block there is an Animation panel with action and slot selectors. You can use these to assign actions and slots to a data-block.

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.
nathanvegdahl marked this conversation as resolved
@ -67,0 +105,4 @@
When selecting a slot for a data-block, you won't necessarily see all the slots of an action listed in the dropdown. This is because Blender limits that dropdown to the slots with an associated type that matches the data-block.
When you select an action to animate a data-block, for convenience Blender will also attempt to automatically select an appropriate slot for you based on name and associated type. If no appropriate slot is found, the slot selector will remain empty.

Add what to do in this case. Something like "You can then create a new slot yourself, or just start keying to let Blender create it for you".

Add what to do in this case. Something like "You can then create a new slot yourself, or just start keying to let Blender create it for you".
nathanvegdahl marked this conversation as resolved
Nathan Vegdahl force-pushed slotted_actions from 6e09a2fef7 to b9dbeff1c1 2024-11-08 17:13:30 +01:00 Compare
Nathan Vegdahl added 1 commit 2024-11-11 10:54:35 +01:00
Nathan Vegdahl added 1 commit 2024-11-11 11:35:44 +01:00
Nathan Vegdahl requested review from Sybren A. Stüvel 2024-11-11 11:37:07 +01:00
Nathan Vegdahl changed title from WIP: update Action documentation to Update Action documentation 2024-11-11 11:37:15 +01:00
Nathan Vegdahl requested review from Christoph Lendenfeld 2024-11-11 11:37:26 +01:00
Author
Member

The PR is now "ready to land" from my perspective. @dr.sybren I've left a few of your comments open because they either need more discussion or I want to double-check that I've addressed them to your satisfaction. @ChrisLend If you can give this one final read-through before landing, that would be appreciated!

The PR is now "ready to land" from my perspective. @dr.sybren I've left a few of your comments open because they either need more discussion or I want to double-check that I've addressed them to your satisfaction. @ChrisLend If you can give this one final read-through before landing, that would be appreciated!
Sybren A. Stüvel approved these changes 2024-11-11 12:32:37 +01:00
Sybren A. Stüvel left a comment
Member

LGTM!

LGTM!
Author
Member

@ChrisLend I'm just going to land this for now. Feel free to leave feedback anyway, and I can address it with follow-up PRs if needed.

@ChrisLend I'm just going to land this for now. Feel free to leave feedback anyway, and I can address it with follow-up PRs if needed.
Nathan Vegdahl merged commit cf91d3124d into main 2024-11-11 15:52:29 +01:00
Nathan Vegdahl deleted branch slotted_actions 2024-11-11 15:52:31 +01:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender-manual#104974
No description provided.