Update Action documentation #104974
@ -5,7 +5,8 @@
|
||||
Actions
|
||||
*******
|
||||
nathanvegdahl marked this conversation as resolved
|
||||
|
||||
*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.
|
||||
*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 :term:`data-blocks <Data-Block>` (:doc:`objects </scene_layout/object/introduction>`, :doc:`meshes </modeling/meshes/introduction>`, :doc:`materials </render/materials/introduction>`, 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.
|
||||
nathanvegdahl marked this conversation as resolved
Outdated
Sybren A. Stüvel
commented
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.
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).
Nathan Vegdahl
commented
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.
|
||||
|
||||
|
||||
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.
|
||||
nathanvegdahl marked this conversation as resolved
Outdated
Sybren A. Stüvel
commented
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.
|
||||
|
||||
@ -82,7 +83,7 @@ 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 an action has been assigned, it also creates and assigns a new slot for the data-block.
|
||||
|
||||
.. note::
|
||||
nathanvegdahl marked this conversation as resolved
Outdated
Sybren A. Stüvel
commented
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.
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.
Nathan Vegdahl
commented
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*.
Nathan Vegdahl
commented
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.
|
||||
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, 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 :term:`focal length <Focal Length>` (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**.
|
||||
|
||||
Manually Assigning Actions and Slots
|
||||
------------------------------------
|
||||
|
@ -18,6 +18,9 @@ This page lists definitions for terms used in Blender and this manual.
|
||||
|
||||
See also :ref:`selection states <object-active>`.
|
||||
|
||||
:doc:`Action </animation/actions>`
|
||||
Blender's container for animation data. In Blender, animatable :term:`data-blocks <Data-Block>` do not store their own animation data, but instead store their animation data an actions.
|
||||
|
||||
Action Safe
|
||||
Area of the screen visible on most devices. Place content inside it to ensure it does not get cut off.
|
||||
|
||||
|
Not sure if the glossary entry for 'Action' already links here, but might be worth checking & adding if it doesn't.
Added a glossary entry for "Action" and made it link back here.