New naming convention proposal #149
@ -65,13 +65,13 @@ All local datablocks of an asset (Object, Mesh, Material, Action, etc.) must als
|
|||||||
- 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-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.
|
- 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.
|
- 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.
|
||||||
|
|
||||||
|
|
||||||
## Name Suffixes
|
## Name Suffixes
|
||||||
|
|||||||
Use `.L`/`.R` suffixes for objects that belong to one side and are symmetrical.
|
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.
|
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.
|
||||||
|
|
||||||
"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 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:
|
||||||
```
|
```
|
||||||
|
Loading…
Reference in New Issue
Block a user
according to the first section,
_
is used only as spacebar replacement, it's not a separator. so an of relationship could be-
insteadThinking 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.