New naming convention proposal #149

Merged
Demeter Dzadik merged 12 commits from Mets/blender-studio-pipeline:mets-naming-conventions into main 2023-11-23 17:11:47 +01:00
Showing only changes of commit 69e1a19eec - Show all commits

View File

@ -1,47 +1,53 @@
# Datablock names # Datablock names
Naming objects in a Blender production can be quite non-trivial when trying to achieve stability, clarity, and the ability to easily make shot files fully local at the end of production, to create fully interactive demo files that can be shared with the world.
## Separators ## Separators
We only have 3 separators to work with, so we try keep their meaning consistent across conventions: We try keep their meaning consistent across conventions:

I agree with this characterization of _ which to me stands in confilct of the proposal to use it for hierarchies/parts later in this document.

I agree with this characterization of `_` which to me stands in confilct of the proposal to use it for hierarchies/parts later in this document.

I think that later part of the document is over-explaining a bit, and makes things that I see as part of the base name (without any suffixes or prefixes) sound as if they were something technically significant. I'll try to clarify this better.

I think that later part of the document is over-explaining a bit, and makes things that I see as part of the base name (without any suffixes or prefixes) sound as if they were something technically significant. I'll try to clarify this better.
`-` : Separates prefixes (including the Asset Identifier) from each other and from the rest of the name. `-` : Separates prefixes (including the Namespace Identifier) from each other and from the rest of the name, eg. `GEO-esprite-head`. Also should be used for naming objects in a hierarchical way when possible, see "Indicating a hierarchy" below.

To me these two categories are completely separate from each other. There could also be variations of symmetric objects.

I'd propose to use . generally for parts/hierarchies like we have in the past. .L/R is compatible with that definition imo.
Variations are for me something orthogonal to that. Could we introduce :? Not sure why we are limited to those 3, as compatibility shouldn't be an issue.

To me these two categories are completely separate from each other. There could also be variations of symmetric objects. I'd propose to use `.` generally for parts/hierarchies like we have in the past. `.L/R` is compatible with that definition imo. Variations are for me something orthogonal to that. Could we introduce `:`? Not sure why we are limited to those 3, as compatibility shouldn't be an issue.

I agree with introducing : as a separator for variants, I only didn't do this because I wasn't sure if you guys are open to it.

Only note is that I would still always put .L/.R at the very end, even if there is a variation, otherwise blender's built-in name flipping function wouldn't work. (Which to be fair isn't used for any built-in operators in Object mode, but for add-ons it's still handy.)

I agree with introducing `:` as a separator for variants, I only didn't do this because I wasn't sure if you guys are open to it. Only note is that I would still always put `.L/.R` at the very end, even if there is a variation, otherwise blender's built-in name flipping function wouldn't work. (Which to be fair isn't used for any built-in operators in Object mode, but for add-ons it's still handy.)
`.` : Separates suffixes, currently only for symmetry sides, ie `.L`/`.R`. `.` : Separates suffixes for symmetry sides, eg. `GEO-esprite-eye.L`, as well as asset variants, see below.
`_` : Used to separate parts of the base name, eg. `console_button_032`. The base name of an ID never has any technical significance. `_` : Used to separate parts of the base name, eg. `wooden_wardrobe_032`. The base name of an ID never has any technical significance.

I had to google what mnemonic means. Maybe we can move to something more intuitive like identifier?

I had to google what mnemonic means. Maybe we can move to something more intuitive like identifier?

Agreed!

Agreed!
`:` : Separator for variations of an object, eg. `clock:normal`, `clock:broken`, `clock:destroyed`.
## Asset Identifier ## Namespace Identifier

The mnemonics should have more 4 letters (more than the 2 and 3) to distinguish them from asset prefixes. otherwise it would be easy to confuse the two. maybe making them lower case would help too.

The mnemonics should have more 4 letters (more than the 2 and 3) to distinguish them from asset prefixes. otherwise it would be easy to confuse the two. maybe making them lower case would help too.

If we don't mind longer ID names, I'm happy to use just a slightly shortened version of names, eg. "elder" for Elder Sprite or "rocket_int" for Rocket Interior.

If we don't mind longer ID names, I'm happy to use just a slightly shortened version of names, eg. "elder" for Elder Sprite or "rocket_int" for Rocket Interior.
All local datablocks across all assets of a production must have a unique name. To faciliate this, each asset's name, or a shortened version of it, should be present in all ID names of that asset. For example, the character "Elder Sprite" might have a full-length unique identifier of `elder_sprite`, along with an optional shortened (but still unique) version, eg. `esprite`. All datablocks across the entire production must have a unique name. To faciliate this, each asset's name, or a shortened version of it, should be present in all datablock names of that asset. This should be enforced by add-ons wherever possible. For example, the character "Elder Sprite" might have a full-length unique identifier of `elder_sprite`, along with an optional shortened (but still unique) version, eg. `esprite`. You should use the short version most of the time, eg. `GEO-esprite-head`, but the longer version when the name doesn't have a lot of other information, eg. the asset's root collection (`CH-elder_sprite`) or the rig object (`RIG-elder_sprite`).
This also applies to datablocks which are not part of an asset, for example pose library poses and shared node groups that get linked into assets. Their namespace identifier should simply be the name of the .blend file that they're in, or a shortened version of it.
This identifier will be present among the prefixes in the names of datablocks, to make sure all names are unique, not just in a single file, but across the whole production. This is necessary because Blender's Library Override system relies on making local copies of linked object hierarchies, meaning all assets need to be able to exist in the same namespace without name collisions. This identifier will be present among the prefixes in the names of datablocks, to make sure all names are unique, not just in a single file, but across the whole production. This is necessary because Blender's Library Override system relies on making local copies of linked object hierarchies, meaning all assets need to be able to exist in the same namespace without name collisions.
The identifier can also have underscores and numbers in it, which may be the case for library assets, eg. `LI-tree_birch_001`.
## Asset Collection Hierarchy ## Asset Collection Hierarchy
We use prefixes for the root collections of assets to help distinguish different types of assets in the Outliner of a complex shot file. The name of the asset itself should be lowercase. We use prefixes for the root collections (and only the root) of assets to help distinguish different types of assets in the Outliner of a complex shot file. The name of the asset itself should be lowercase.
- `CH` : Character - `CH` : Character
- `PR` : Prop - `PR` : Rigger Prop
- `EN` : Environment Prop - `LI` : Library/Environment Asset
- `SE` : Set - `SE` : Set
- `LG` : Light Rig - `LG` : Light Rig
- `CAM`: Camera Rig - `CA`: Camera Rig

I don't remember this being a necessity in the current design of the asset pipeline. Maybe I'm misremembering but I don't generally think that binding the tasklayer association with the name is a good idea, since that will make changing this without breakage impossible.

I don't remember this being a necessity in the current design of the asset pipeline. Maybe I'm misremembering but I don't generally think that binding the tasklayer association with the name is a good idea, since that will make changing this without breakage impossible.

It is, it's necessary for each task layer to be assigned its own piece of the hierarchy, otherwise the pipeline doesn't know which hierarchy to keep; The one being pulled in, or the one already in the current file. So when pulling into Rigging currently, it will preserve the current hierarchy for the Rigging collection, but take the hierarchy of the other collections from the publish.

It is, it's necessary for each task layer to be assigned its own piece of the hierarchy, otherwise the pipeline doesn't know which hierarchy to keep; The one being pulled in, or the one already in the current file. So when pulling into Rigging currently, it will preserve the current hierarchy for the Rigging collection, but take the hierarchy of the other collections from the publish.

But I thought we agreed on storing this data as custom properties and keeping the hierarchies out of it, no?
Because this isn't just about the exceptions, right? Every collection would have that. Having the tasklayer name in every single collection of an asset seems quite off to me, that's not something I remember considering. Maybe that was a misunderstanding at the time.

But I thought we agreed on storing this data as custom properties and keeping the hierarchies out of it, no? Because this isn't just about the exceptions, right? Every collection would have that. Having the tasklayer name in every single collection of an asset seems quite off to me, that's not something I remember considering. Maybe that was a misunderstanding at the time.

So as far as the Asset Pipeline is concerned, we did agree on storing ownership information inside property groups on the individual objects, and that is how ownership of objects is handled by the Asset Pipeline.

But for consistency in the organization of collections each task layer has a collection, the user can assign objects to their task layer collection. These top-level collections are named after the task layers and are purely organizational and don't influence who owns what object, but they are necessary to avoid conflicts in collection assignments during Push/Pull. Personally I prefer the collection set-up like this, but I'm open to discussing alternatives.

It is possible to replace this feature with some kind of ownership system and UI similar to objects for collections, but that not within the scope of things we are currently focused on. We are more focused on finalizing the transfer logic and getting 'ownership' working on non-object IDs like GeoNode groups.

So as far as the Asset Pipeline is concerned, we did agree on storing ownership information inside property groups on the individual objects, and that is how ownership of objects is handled by the Asset Pipeline. But for consistency in the organization of collections each task layer has a collection, the user can assign objects to their task layer collection. These top-level collections are named after the task layers and are purely organizational and don't influence who owns what object, but they are necessary to avoid conflicts in collection assignments during Push/Pull. Personally I prefer the collection set-up like this, but I'm open to discussing alternatives. It is possible to replace this feature with some kind of ownership system and UI similar to objects for collections, but that not within the scope of things we are currently focused on. We are more focused on finalizing the transfer logic and getting 'ownership' working on non-object IDs like GeoNode groups.

It's actually not necessary for the sub-collections' names to include the task layer name, that's true. That was more of a stylistic choice on my end. So you're right, this is in fact legal:

CH-elder_sprite
    esprite-model
        esprite-head
        esprite-eyes
            esprite-eye.L
            esprite-eye.R
    esprite-rig
    esprite-shading

I think it might be a bit nicer with the task layer names, when seeing the collections as a flat list, like when appending or using the Blend File view of the Outliner. Also because multiple task layers might have their own collection relating to a given part of a character. But I don't mind too much if this isn't strictly enforced.

It's actually not necessary for the sub-collections' names to include the task layer name, that's true. That was more of a stylistic choice on my end. So you're right, this is in fact legal: ``` CH-elder_sprite esprite-model esprite-head esprite-eyes esprite-eye.L esprite-eye.R esprite-rig esprite-shading ``` I think it might be a bit nicer with the task layer names, when seeing the collections as a flat list, like when appending or using the Blend File view of the Outliner. Also because multiple task layers might have their own collection relating to a given part of a character. But I don't mind too much if this isn't strictly enforced.
Example root collection name: `CH-elder_sprite` Example root collection names: `CH-elder_sprite`, `LI-rock_large_013`
Note that there's no technical distinction between different types of assets. This is purely for organizational purposes and comfort. Note that there's no technical distinction between different types of assets. This is purely for organizational purposes and comfort.
Review

I find it quite confusing if the main asset collection prefix and any other collection prefix share the exact same formatting. I'd propose to keep those clearly different to avoid confusion and improve readability.

So either making the identifier not capitalized or using a different separator or both.

I find it quite confusing if the main asset collection prefix and any other collection prefix share the exact same formatting. I'd propose to keep those clearly different to avoid confusion and improve readability. So either making the identifier not capitalized or using a different separator or both.
Review

This seems to align with Andy's suggestion of keeping these identifiers longer. In that case, I agree with lower-case, so instead of "ES" or "elder_sprite", we could just have "esprite" or "elder" (up to whoever is first creating the asset). For most assets, especially characters, our names tend to be quite short, so additional shortening isn't always needed. Only downside is that maybe sometimes we'll end up with some pretty long names, but it's not the end of the world.

This seems to align with Andy's suggestion of keeping these identifiers longer. In that case, I agree with lower-case, so instead of "ES" or "elder_sprite", we could just have "esprite" or "elder" (up to whoever is first creating the asset). For most assets, especially characters, our names tend to be quite short, so additional shortening isn't always needed. Only downside is that maybe sometimes we'll end up with some pretty long names, but it's not the end of the world.
The immediate sub-collections of the root collection are strictly defined by our Asset Pipeline add-on, as being `{identifier}-{task layer}`. Task Layers are the different data layers that make up an asset, such as Modeling, Rigging, and Shading. Inside these Task Layer Collections, each artist responsible for their own Task Layer may create sub-collections freely, as long as each sub-collection still starts with `{identifier}-{task layer}-`. The immediate sub-collections of the root collection should be named according to the Task Layers configured in our Asset Pipeline add-on, but this is not strictly required. Task Layers are the different data layers that make up an asset, such as Modeling, Rigging, and Shading. Collections nested beyond this can be named freely, as long as they still start with the namespace identifier.
So, here's what an asset's collection hierarchy might look like: So, here's what an asset's collection hierarchy might look like:
```txt ```txt
CH-elder_sprite CH-elder_sprite
esprite-model esprite-model
esprite-model-head esprite-head
esprite-model-teeth_and_tongue esprite-teeth_and_tongue
esprite-rig esprite-rig
esprite-rig-widgets esprite-widgets
esprite-rig-helpers esprite-helpers
esprite-rig-eye.L esprite-eye.L
esprite-rig-eye.R esprite-eye.R
esprite-shading esprite-shading
esprite-shading-outlines esprite-outlines
``` ```
## Name Prefixes ## Name Prefixes
@ -62,36 +68,58 @@ All local datablocks of an asset (Object, Mesh, Material, Action, etc.) must als
- Object Data and Shape Keys should be named the same as the containing Object. This is automated by the Asset Pipeline add-on. - Object Data and Shape Keys should be named the same as the containing Object. This is automated by the Asset Pipeline add-on.
- Words in all base names should be lower-case and separated by `_`. - Words in all base names should be lower-case and separated by `_`.
- All datablock names must not end with a `.00x` suffix. This is enforced by the Asset Pipeline add-on. - All datablock names must not end with a `.00x` suffix. This is enforced by the Asset Pipeline add-on.
- When there's too many objects to manually name, like when building a house out of a hundred wooden plank objects, the **Batch Rename Datablocks** built-in add-on should be used to give groups of objects the same name. Then replace the `.` in the `.00x` suffixes with an `_` instead, so `GEO-house-wooden_plank.023` becomes `GEO-house-wooden_plank_023`, making the number a part of the base name for the purposes of Library Overrides and duplication. - When there's too many objects to manually name, like when building a house out of a hundred wooden plank objects, the **Batch Rename Datablocks Operator** should be used to give groups of objects the same name. Then replace the `.` in the `.00x` suffixes with an `_` instead, so `GEO-house-wooden_plank.023` becomes `GEO-house-wooden_plank_023`, making the number a part of the base name for the purposes of Library Overrides and duplication.

according to the first section, _ is used only as spacebar replacement, it's not a separator. so an of relationship could be - instead

according to the first section, `_` is used only as spacebar replacement, it's not a separator. so an _of_ relationship could be `-` instead

Thinking about it now, I actually don't think an of relationship needs to be signified by the ID name at all, since it has no technical significance in the pipeline. To me, it's just the same as any other word separation. Collections also help with this.

Thinking about it now, I actually don't think an *of* relationship needs to be signified by the ID name at all, since it has no technical significance in the pipeline. To me, it's just the same as any other word separation. Collections also help with this.
- This makes it so that when an asset is duplicated in a shot, every object in the same copy of the asset will have the same number suffix. The first copy will have no suffix, the second copy will have .001, etc. Without this step, this object would instead end up getting named `GEO-HS-wooden_plank.024`, which would mean the suffix number has no correlation with which overridden copy of the asset this object belongs to. This could break Library Overrides. - This makes it so that when an asset is duplicated in a shot, every object in the same copy of the asset will have the same number suffix. The first copy will have no suffix, the second copy will have .001, etc. Without this step, this object would instead end up getting named `GEO-house-wooden_plank.024`, which would mean the suffix number has no correlation with which overridden copy of the asset this object belongs to. This could break Library Overrides.
- "Of" relationships should be part of the base name, as there is nothing special about them from a technical sense, so they are not a suffix or a prefix. Example: `GEO-wardrobe-drawer_knob.L` for the knob of a drawer on the Wardrobe prop.
## Indicating Hierarchy
## Name Suffixes For complex assets, try to use dashes to indicate a nested hierarchy of objects, eg:
Use `.L`/`.R` suffixes for objects that belong to one side and are symmetrical.
On the other hand, avoid using `.L`/`.R` when similar objects exist on each side of an asset but aren't meant to be symmetrical.
If the watch had a variant of type `clean` and `dirty`, these would be using a `:` to express the nature of the variant:
``` ```
`GEO-watch:clean` PR-wardrobe
`GEO-watch:dirty` wardrobe.model

dot . should become a dash -
everything else looks good and can be merged as far as I am concerned :)

dot `.` should become a dash `-` everything else looks good and can be merged as far as I am concerned :)

Thanks, fixed!

Thanks, fixed!
GEO-wardrobe-base
GEO-wardrobe-drawer_01
GEO-wardrobe-drawer_01-knob
GEO-wardrobe-drawer_02
GEO-wardrobe-drawer_02-knob
``` ```
## Indicating Asset Variants
The `.` is also used for indicating asset variants, which is when an asset has multiple states or versions in the production.
The variant indicator can be placed anywhere in the name hierarchy:
`GEO-wardrobe:burned-shelf-book` indicates that the whole wardrobe has a burned variant. Perhaps there was a house fire in the film.
`GEO-wardrobe-shelf-book:burned` indicates that only the book is burned, perhaps because a candle fell over in the film.

we established the "no caps, no gaps" rule at some point, should be used here as well. so no uppercase letters except for prefix and suffixes.

we established the "no caps, no gaps" rule at some point, should be used here as well. so no uppercase letters except for prefix and suffixes.
## Symmetry Suffixes
Use exactly `.L`/`.R` suffixes for objects that belong to one side and are symmetrical.
On the other hand, avoid using `.L`/`.R` when similar objects exist on each side of an asset but aren't meant to be symmetrical, and use a different side indicator if necessary, such as `_left`.
## Node Trees
Node Trees (aka Node Groups) in Blender are unfortunately all stored in one location, which is inconvenient when trying to browse them, which we frequently do. To remedy this, node groups should be prefixed with what type of node group they are.
```
`GN` : Geometry Nodes
`SH` : Shading Nodes
`CM` : Compositing Nodes
```
And as always, the namespace identifier must be included, eg. `GN-esprite-procedural_beard`.
## Actions ## Actions
### Pose Library ### Pose Library
Pose Library actions are in their own files, and marked as assets, so they show up in the Asset Browser and therefore the built-in Pose Library add-on. Due to frequent use, limited UI space in the Pose Library UI, and the fact that these assets are never duplicated or made local in a shot file (therefore unique naming across the procution isn't important), their names should be kept very simple. No need for any prefix, just simply describe the pose. For easy consistency, lowercase words separated by underscores is recommended. Pose Library actions also need a namespace identifier. For easy consistency, use lowercase words separated by underscores, as usual.
Examples: Examples:
``` ```
hand_fist rex-hand_fist
hand_splayed rex-hand_splayed
face_happy rex-face_happy
face_surprised rex-face_surprised
eyes_blink rex-eyes_blink
eyes_surprised rex-eyes_surprised
``` ```
### Rig Actions ### Rig Actions
@ -106,13 +134,13 @@ RIG-esprite-mouth_open+lips_wide
``` ```
### Animations of Shots ### Animations of Shots
Actions created for shots should be named `ANI-{asset_identifier}-{scene_name}.{version}` Actions created for shots should be named `ANI-{asset_identifier}-{scene_name}-{version}`
Examples: Examples:
``` ```
ANI-esprite-060_scratch_layout.v001 ANI-esprite-060_scratch_layout-v001
ANI-esprite-110_0100_A.v001 ANI-esprite-110_0100_A-v001
ANI-rex-140_0020_A.v001 ANI-rex-140_0020_A-v001
``` ```
### Bone Names ### Bone Names