docs/naming-conventions/in-file-prefixes.md

@@ -1,14 +1,16 @@
 # Datablock names
 
 ## Separators
-We only have 3 separators to work with, so we try to make the most of them and keep their meaning consistent across conventions:  
+We only have 3 separators to work with, so we try keep their meaning consistent across conventions:  
 `-` : Separates prefixes from each other and from the rest of the name.  
 `_` : Used instead of spacebar in composite words, eg. `eifel_tower_base`.  
 `.` : Suffixes, used only for symmetry sides, ie `.L`/`.R`, and for variations, `clock.normal`, `clock.broken`, `clock.destroyed`  
 
 ## Asset Mnemonic
 
-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 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. 
+
+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.
 
 ## Asset Collections
 
@@ -25,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.
 
-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. Beyond those two layers, any number of collections may be created according to the needs and wants of the person responsible for a given Task Layer. However, each sub-collection should still start with `{mnemonic}-{task_layer}-`.
+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}-`.
 So, here's what an asset's collection hierarchy might look like:
 ```txt
 CH-elder_sprite
@@ -40,13 +42,15 @@ CH-elder_sprite
     ES-shading
         ES-shading-outlines
 ```
+
 ## Asset Datablocks
-- All local datablocks (Mesh, Material, Action, etc.) of an asset must start with or at least include the asset's mnemonic, eg `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 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.
 - Object Data and Shape Keys should be named the same as the containing Object. This is automated by the Asset Pipeline add-on.
-- Object 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.
-    - In some cases it may be truly unreasonable to expect an artist to give every object in an asset a unique, manually typed in name, like when building a house out of a hundred wooden slab objects. In these cases, the Batch Rename Datablocks built-in add-on should be used to give groups of objects the same name, then in a subsequent step replace the `.` in the `.00x` suffixes with an `_` instead.
+    - 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`.
-    - The purpose of this is so that, when there are >1 copies of this asset overridden in a file, every object in the same copy of the asset will have the same number suffix. This would not be the case if we didn't replace the `.` with an `_` before publishing the asset.
+    - 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.
-    - Without this step, debugging shot files with multiple copies of an asset becomes an absolute nightmare, and if you add the occasional deletion of copies into the mix, it could even confuse Blender's Library Override system and break shots.
+    - 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.
+
 
 It is advisable to give Objects an additional prefix to provide information about the object's purpose, especially when it is NOT part of an asset. This is purely for organizational and comfort purposes. Here are some recommendations:
 
@@ -57,13 +61,14 @@ It is advisable to give Objects an additional prefix to provide information abou
 - `RIG` : Rig and rig specific objects that do not appear in rendering
 - `ENV` : Matte paintings, sky-domes, fog volume objects
 - `GPL` : Grease pencil stroke objects (need to differentiate from GEO because can not be rendered on the farm)
+- `TMP` : Any object used in pre-viz that should be replaced with final assets over the course of the production.
 
-Use `.L` or `.R` for objects that belong to one side and are symmetrical.
+Use `.L`/`.R` suffices for objects that belong to one side and are symmetrical.
-On the other hand, avoid using `.L` and `.R` when similar objects exist on each side of an asset but aren't meant to be 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.
 
 Example: `GEO-WRDB-drawer_knob.L` for the left-side drawer knob of a wardrobe prop.
 
-If a name contains a *of* relationship - in the above example the `knob` of the `drawer` - these should NOT be separated by `.`, but rather with `_`.
+If a name contains an "*of*" relationship - in the above example the `knob` *of* the `drawer` - these should NOT be separated by `.`, but rather with `_`.
 
 Another example:
 ```