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

@@ -2,17 +2,18 @@
 
 ## Separators
 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`  
+`-` : Separates prefixes (including the Asset Identifier) from each other and from the rest of the name.
+`.` : Separates suffixes, currently only for symmetry sides, ie `.L`/`.R`.
+`_` : Used to separate parts of the base name, eg. `console_button_032`. The base name of an ID never has any technical significance.
+`:` : Separator for variations of an object, eg. `clock:normal`, `clock:broken`, `clock:destroyed`.
 
 ## Asset Identifier
 
-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. 
+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`.
 
-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.
+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.
 
-## Asset Collections
+## 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.
 
@@ -27,59 +28,55 @@ 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 `{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 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}-`.
 So, here's what an asset's collection hierarchy might look like:
 ```txt
 CH-elder_sprite
-    ES-model
-        ES-model-head
-            ES-model-teeth_and_tongue
-    ES-rig
-        ES-rig-widgets
-        ES-rig-helpers
-            ES-rig-eye.L
-            ES-rig-eye.R
-    ES-shading
-        ES-shading-outlines
+    esprite-model
+        esprite-model-head
+            esprite-model-teeth_and_tongue
+    esprite-rig
+        esprite-rig-widgets
+        esprite-rig-helpers
+            esprite-rig-eye.L
+            esprite-rig-eye.R
+    esprite-shading
+        esprite-shading-outlines
 ```
 
-## Asset Datablocks
-- 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.
+## Name Prefixes
+All Object names (not just in Assets) must start with a prefix describing the object's purpose:
+
+- `LGT` : Light objects and mesh-lights, also shadow casters
+- `ENV` : Matte paintings, sky-domes, fog volume objects
+- `GEO` : Geometry, meshes, curves that contribute to the rendered appearance of the asset
+- `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
+- `HLP` : Empties and other helper objects that are not rendered
+- `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.
+
+## 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.
-- 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`.
+- 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.
+    - 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.
     - 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 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:
-
-- `WGT` : Bone shapes
-- `LGT` : Light objects and mesh-lights, also shadow casters
-- `HLP` : Empties and other helper objects that are not rendered
-- `GEO` : Geometry, meshes, curves that contribute to the rendered appearance of the asset
-- `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`/`.R` suffices for objects that belong to one side and are symmetrical.
+## Name Suffixes
+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.
 
-Example: `GEO-WRDB-drawer_knob.L` for the left-side drawer knob of a wardrobe prop.
+"Of" relationships should be part of the base name, and not a suffix. Example: `GEO-wardrobe-drawer_knob.L` for the left-side drawer knob of the Wardrobe prop.
 
-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:
+If the watch had a variant of type `clean` and `dirty`, these would be using a `:` to express the nature of the variant:
 ```
-Good: `GEO-ES-watch_screw`
-Bad:  `GEO-ES-watch.screw`
-```
-
-If the watch had a variant of type `clean` and `dirty`, these would be using a `.` to express the nature of the variant:
-```
-`GEO-ES-watch.clean`
-`GEO-ES-watch.dirty` 
+`GEO-watch.clean`
+`GEO-watch.dirty`
 ```
 
 ## Actions
@@ -90,15 +87,15 @@ Pose Library actions are in their own files, and marked as assets, so they show
 
 Examples:
 ```
-Hand_Fist
-Hand_Splayed
-Face_Happy
-Face_Surprised
-Eyes_Blink
-Eyes_Surprised
+hand_fist
+hand_splayed
+face_happy
+face_surprised
+eyes_blink
+eyes_surprised
 ```
 
-### Rig Constraints
+### 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.
 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 "+".
 
@@ -118,3 +115,25 @@ ANI-ES-060_scratch_layout.v001
 ANI-ES-110_0100_A.v001
 ANI-REX-140_0020_A.v001
 ```
+
+### Bone Names
+Making rigs as easy to learn and work with as possible is the most important thing when naming bones.
+Every bone name should be named properly (never `Bone.023`), avoid ugly number suffixes, and avoid unnecessary padding in numbers.
+Controls that are exposed to animators should ideally have max one prefix, with an intuitive acronym.
+Examples:
+```
+Bad: STR-TIP-Finger_04_003.L
+Good: STR-Finger_Pinky_4.L
+```
+
+Numbering should start from 1, but if a bone gets inserted at the start of the chain, it's better to just number it 0 rather than change all the pre-existing bones' names, to not break any existing animations.
+
+Symmetry sides should be indicated by `.L`/`.R`.
+
+Other prefixes and their meaning:
+- `IK` : Control body parts in Inverse Kinematics mode
+- `FK` : Control body parts in Forward Kinematics mode
+- `STR` : Squash and stretch body parts
+- `ROOT` : Control a cohesive area of the rig (often detachable)
+- `TGT` : Control the target of a Look-At rig set-up
+- `P` : Parent of another control