Why should we name our stuff in Maya?
— Makes selection easy:
For me, this is the biggest reason. 3D scenes are filled with characters, props, environments, their rigs, textures and we need to work with them. Scripts can be written to automate a lot of the repetitive work in 3D work and often times it heavily involves with selecting nodes and then running functions. It’s way simpler for these scripts to be written if there’s a naming convention within the pipeline.
Often times we’ll have to spend a lot of time trying to hunt for stuff from the viewport or the outliner in a poorly organised scene. Wasted time! Even more time is wasted when we make simple mistakes just because the names are confusing.
A little effort in naming our stuff as we go will ease the lives of people down the pipeline. The TDs will certainly thank you for that.
Enough of the why.
Here’s my recommended naming convention for use within a Maya pipeline. I use it myself and I’ve seen many studios adopt a similar naming convention.
— Type of Object:
The last three letters (only 3 for scripting purposes) in caps to denote the object type. This allows for ease of selection. Some examples:
ball_GEO for Geometry
ball_NUL for Null Locators
ball_JNT for Joints
ball_CON for Controllers
ball_MAT for Materials
Tip: Using Maya’s “Select by Name” field, we can type “*_GEO” and it’ll select all the objects we’ve tagged with “_GEO”
Use underscores only for separate types of information. For instance, if it’s the left elbow joint, it’ll be “nose_JNT”.
— Camel Casing:
If it takes two words to describe an object like the joint of “Red Ball”, do not use “red_ball_JNT”, instead use camel case to contract these two words into one entity resulting in “noseBridge_JNT”
If done correctly, it greatly improves the readibility.
— Left/Right indication
lf_ or rt_ as a prefix
Why not just “l” and “r”?
l and r is slightly less visible compared to lf and rt
— Upper/Lower indication
There’s more left/right mirroring in characters than top down mirroring. So upper/lower indication doesn’t justify the use of an underscore to separate the information.
So, instead of “lf_upper_Lid_JNT”, use “lf_upLid_JNT”
It’s natural to use “upper” in speech but depending on preference, we may contract it to “up” as in “lf_upLid_JNT”. This way, it can be really neat:
— Corresponding root names
We should also make an effort to standardise the root names of our objects and it’s “relatives”