studio/blender-studio-tools
13
32
Fork 19
Code Issues 21 Pull Requests 4 Projects Releases 1 Activity

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
Conversation 2 Commits 12 Files Changed 3 +7 -7
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 2435c664be - Show all commits

14
docs/naming-conventions/in-file-prefixes.md
View File

@ -6,11 +6,11 @@ We only have 3 separators to work with, so we try keep their meaning consistent
`_` : Used instead of spacebar in composite words, eg. `eifel_tower_base`. `_` : Used instead of spacebar in composite words, eg. `eifel_tower_base`.
Simon Thommes commented 2023-09-18 13:04:52 +02:00
Outdated
Review
Copy Link

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.
Demeter Dzadik commented 2023-09-18 16:26:34 +02:00
Outdated
Review
Copy Link

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.
`.` : Suffixes, used only for symmetry sides, ie `.L`/`.R`, and for variations, `clock.normal`, `clock.broken`, `clock.destroyed` `.` : Suffixes, used only for symmetry sides, ie `.L`/`.R`, and for variations, `clock.normal`, `clock.broken`, `clock.destroyed`
Simon Thommes commented 2023-09-18 13:07:37 +02:00
Outdated
Review
Copy Link

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.
Demeter Dzadik commented 2023-09-18 16:19:51 +02:00
Outdated
Review
Copy Link

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.)
## Asset Mnemonic ## Asset Identifier
Simon Thommes commented 2023-09-18 12:49:10 +02:00
Outdated
Review
Copy Link

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?
Demeter Dzadik commented 2023-09-18 16:18:05 +02:00
Outdated
Review
Copy Link

Agreed!

Agreed!
All local datablocks across all assets of a production must have a unique name. To faciliate this, each asset is assigned a mnemonic that must remain unique within a given production. For example, a character named "Elder Sprite" might get the mnemonic "ES". The max length of this mnemonic is not limited, but the shorter the better. If a minor prop in the production is called "Electric Switch", it can not have the mnemonic "ES", because it's already taken. So, "ELSW" would be fine. All local datablocks across all assets of a production must have a unique name. To faciliate this, each asset is assigned an identifier that must remain unique within a given production. For example, a character named "Elder Sprite" might get the identifier "ES". The max length of this identifier is not limited, but the shorter the better. If a minor prop in the production is called "Electric Switch", it can not have the identifier "ES", because it's already taken. So, "ELSW" would be fine.
Andy Goralczyk commented 2023-09-18 13:04:39 +02:00
Outdated
Review
Copy Link

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.
Demeter Dzadik commented 2023-09-18 15:52:07 +02:00
Outdated
Review
Copy Link

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 mnemonic will be used in the names of datablocks, to make sure all names are unique, not just in a single file, but 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 collisions. This identifier will be used in the names of datablocks, to make sure all names are unique, not just in a single file, but 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 collisions.
## Asset Collections ## Asset Collections
@ -27,7 +27,7 @@ Example: `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.
The immediate sub-collections of the root collection are strictly defined by our Asset Pipeline add-on, as being `{mnemonic}-{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 `{mnemonic}-{task_layer}-`. 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}-`.
Simon Thommes commented 2023-09-18 13:11:45 +02:00
Outdated
Review
Copy Link

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.
Demeter Dzadik commented 2023-09-18 16:17:33 +02:00
Outdated
Review
Copy Link

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.
Simon Thommes commented 2023-09-18 16:36:07 +02:00
Outdated
Review
Copy Link

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.
Nick Alberelli commented 2023-09-18 16:55:52 +02:00
Outdated
Review
Copy Link

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.
Demeter Dzadik commented 2023-09-18 17:05:17 +02:00
Outdated
Review
Copy Link

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.
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
@ -44,7 +44,7 @@ CH-elder_sprite
``` ```
## Asset Datablocks ## Asset Datablocks
- All local datablocks of an asset (Object, Mesh, Material, Action, etc.) must include either the asset's mnemonic or full name (both is not necessary). Eg., `RIG-elder_sprite` or `GEO-ES-eye.L`. This is automated by the Asset Pipeline add-on. - All local datablocks of an asset (Object, Mesh, Material, Action, etc.) must include either the asset's identifier or full name (both is not necessary). Eg., `RIG-elder_sprite` or `GEO-ES-eye.L`. 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. - Object Data and Shape Keys should be named the same as the containing Object. This is automated by the Asset Pipeline add-on.
- Datablock names must not end with a `.00x` suffix. This is enforced by the Asset Pipeline add-on. - 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`. - 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`.
@ -99,7 +99,7 @@ Eyes_Surprised
``` ```
### Rig Constraints ### Rig Constraints
Rigs may use Actions for Action Constraint based control set-ups. Since these are asset datablocks, they must start with the asset mnemonic. Rigs may use Actions for Action Constraint based control set-ups. Since these are asset datablocks, 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:
@ -110,7 +110,7 @@ RIG-ES-mouth_open+lips_wide
``` ```
### Animations of Shots ### Animations of Shots
Actions created for shots should be named `ANI-{asset_mnemonic}-{scene_name}.{version}` Actions created for shots should be named `ANI-{asset_identifier}-{scene_name}.{version}`
Examples: Examples:
``` ```