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 2ec549e247 - Show all commits

View File

@ -11,7 +11,7 @@ We only have 3 separators to work with, so we try keep their meaning consistent
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 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`.

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.
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 useful/necessary because of the way Blender's Override system works, which 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.
## Asset Collection Hierarchy ## Asset Collection Hierarchy
@ -24,7 +24,7 @@ We use prefixes for the root collections of assets to help distinguish different
- `LG` : Light Rig - `LG` : Light Rig
- `CAM`: Camera Rig - `CAM`: Camera Rig
Example: `CH-elder_sprite` Example root collection name: `CH-elder_sprite`
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.

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.
@ -49,22 +49,21 @@ All Object names (not just in Assets) must start with a prefix describing the ob
- `LGT` : Light objects and mesh-lights, also shadow casters - `LGT` : Light objects and mesh-lights, also shadow casters
- `ENV` : Matte paintings, sky-domes, fog volume objects - `ENV` : Matte paintings, sky-domes, fog volume objects
- `GEO` : Geometry, meshes, curves that contribute to the rendered appearance of the asset - `GEO` : Geometry, meshes, curves that contribute to the rendered appearance of an asset
- `RIG` : Armatures of an asset
- `GPL` : Grease pencil stroke objects (need to differentiate from GEO because can not be rendered on the farm) - `GPL` : Grease pencil stroke objects (need to differentiate from GEO because can not be rendered on the farm)
- `RIG` : Rig and rig specific objects that do not appear in rendering
- `WGT` : Bone shapes - `WGT` : Bone shapes
- `HLP` : Empties and other helper objects that are not rendered - `HLP` : Empties and other helper objects that are not rendered

This needs stronger wording than "should be advisable", every object datablock should have that prefix to make it clear when linking/appending what that object is and to visually distinguish the objects in the outliner and python query.

This needs stronger wording than "should be advisable", every object datablock should have that prefix to make it clear when linking/appending what that object is *and* to visually distinguish the objects in the outliner and python query.

Gotcha, will replace "should" with "must".

Gotcha, will replace "should" with "must".
- `TMP` : Any object used in pre-viz that should be replaced with final assets over the course of the production. - `TMP` : Any object used in pre-viz that should be replaced with final assets over the course of the production.
All local datablocks of an asset (Object, Mesh, Material, Action, etc.) must also include either the asset's shortened or full name. Eg., `RIG-elder_sprite` or `GEO-elder-eye.L`. This is enforced by the Asset Pipeline add-on. All local datablocks of an asset (Object, Mesh, Material, Action, etc.) must also include either the asset's shortened or full name. Eg., `RIG-elder_sprite` or `GEO-esprite-eye.L`. This is enforced by the Asset Pipeline add-on.
## Base Names ## Base Names
- 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-HS-wooden_plank.023` becomes `GEO-HS-wooden_plank_023`, making the number a part of the base name. - 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.
- The purpose of this is that when there are >1 copies of this asset overridden (and therefore local) in a file, 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 of the asset will have object names like `GEO-HS-wooden_plank_023.001`, which is fine. If we didn't do this step, this object would instead end up getting named `GEO-HS-wooden_plank.024`, which is not fine because now the suffix number has no correlation with which overridden copy of the asset this object belongs to. - 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.
- Without this step, debugging shot files with multiple copies of an asset becomes a nightmare, and it could even confuse the Library Override system and break shots.
- "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. - "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.
@ -75,15 +74,15 @@ On the other hand, avoid using `.L`/`.R` when similar objects exist on each side
If the watch had a variant of type `clean` and `dirty`, these would be using a `:` to express the nature of the variant: 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` `GEO-watch:clean`
`GEO-watch.dirty` `GEO-watch:dirty`

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!
``` ```
## 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. Since the Pose Library doesn't have collections, use naming to make sure that poses for a given body part get sorted together alphabetically. 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.
Examples: Examples:
``` ```
@ -96,14 +95,14 @@ eyes_surprised
``` ```
### Rig Actions ### Rig Actions
Rigs may use Actions for Action Constraint based control set-ups. Since these are asset datablocks, they must start with the asset identifier. Rigs may use Actions for Action Constraint based control set-ups. Since these are datablocks and part of the character asset, they must start with the asset identifier.
Corrective Actions are ones which are meant to activate when two other actions activate. These should use the name of the two trigger actions, separated by a "+". Corrective Actions are ones which are meant to activate when two other actions activate. These should use the name of the two trigger actions, separated by a "+".
Examples: Examples:
``` ```
RIG-ES-mouth_open RIG-esprite-mouth_open
RIG-ES-lips_wide RIG-esprite-lips_wide
RIG-ES-mouth_open+lips_wide RIG-esprite-mouth_open+lips_wide
``` ```
### Animations of Shots ### Animations of Shots
@ -111,9 +110,9 @@ Actions created for shots should be named `ANI-{asset_identifier}-{scene_name}.{
Examples: Examples:
``` ```
ANI-ES-060_scratch_layout.v001 ANI-esprite-060_scratch_layout.v001
ANI-ES-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