Jump to content
Jason

Naming Conventions

Recommended Posts

Hey all!

I was having a great discussion with @Jarom Brand the other day about a bunch of stuff, and naming conventions came up. Jarom has some great ideas around them (which I'd love for him to share.. hint hint..? ) and would love to hear from the rest of you about your thoughts.

Obviously we all know the reason WHY we should name things... clarity... consistency... making it easier to find things... but there are all sorts of ways people go about coming up with their conventions.

For example, do you ALL_CAPS the type of object it is?

head_JNThead_GEO vs head_jnt, head_geo...

Do you break things apart with underscores? dashes? what about dots?

is it l_uparm_JNT or LFT_uparm_JNT?

Send your thoughts!

 

Share this post


Link to post
Share on other sites

Hey @Jason

Yeah, I'd love to share what I've been working on and get some feedback. I'll see about putting together some kind of a presentation over the weekend and share it here. 

  • Like 1

Share this post


Link to post
Share on other sites

Hey @Jason

When I do naming conventions for rigs I tend to use underscores. I usually don't spend much time renaming. Must of the time ill just leave the default name and just add L or R for left and right.

Share this post


Link to post
Share on other sites

Just back to this again as I'm working on setting up some rules for a project.

@Jarom Brand if I remember right from our discussion, you like to do something like:

<side>_<objectName>_<descriptive>_<TYPE> right?  And the descriptive is optional?

examples:

l_upArm_JNT

l_upArm_offset_JNT

r_hand_ik_ANI

r_hand_fk_ANI

m_all_GRP

m_all_offset_GRP

something like that?

Share this post


Link to post
Share on other sites

Hi @Jason! So sorry, I have been meaning to get back to this thread, but work has been crazy busy lately. I still want to dive into what I'm working on with naming conventions, but it will have to wait for life to calm down a bit so I can take the time to do it properly. In the mean time, here are my thoughts on naming conventions:

 

The most important aspect of a good naming is consistency. So if you are consistent then  <side>_<objectName>_<descriptive>_<TYPE> will work just fine. 

This is naming convention I like:  <SIDE>_<ObjectName><descriptive><Numerator>_<Type>

Why use this convention

The driving force behind this naming convention is the need to present animators with a  clean, easy to read rig. Typically all animators will see are the controls, however we will use this same convention for all rigging nodes as well as model geometry and its groups so that tool development can be consistent.
 
This naming convention is not meant for system files and directories and will not work well as such. 
 
SIDE_NodeName##_NodeType
In this convention there are only ever 2 underscores and only 1 if there is no side identifier.
 
e.g.
  • L_Arm_Ikh
  • R_FkKnee_Ctrl
  • Head_Jnt
  • Chest_Ctrl

SIDE(optional)

Single letter side identifier followed by an underscore. If the object is centered or does not have an obvious side then there is no need for the side identifier
 
Valid side identifiers:
  • L - left
  • R - right
  • T - top(only if there is not a left and right side)
  • B - bottom(only if there is not a left and right side)

NodeName

The node name describes what the thing is. For example the node name for the poleVector control could be ArmPV, or the node name for the head joint would be Head. 
  • CamelCase name of the node
  • Always starts with a capital letter
  • No underscores 
  • If there needs to be an adjective in the name, say Inner, Outer, Front, Back, Proximal, Distal, etc. Place it at the beginning

        e.g.

                Leg
                InnerEyeBrow               
                FrontDoor                
                ArmPV           
                

##(optional padding)

2 digit padded numbering starting at 01. If there is only one object with a given side identifier and node name, then no number is needed, so don't add it. 
 

NodeType

The NodeType is a suffix that is separated from the Node name with an underscore. it describes the type of node it is as well as its function. It is CamelCased, always starts with an upper case letter and there are no underscores within this section.

e.g.

  • Jnt - Joints that move renderable geometry through skin clusters or constraints
  • Jx - Non-skinning joints(utility joints)
  • Ctrl - Visible and selectable curves used for animation
  • Grp - General transform used for organizing the hierarchy 
  • Null
  • Mesh - Non-renderable polygon meshes
  • surf -  Non-renderable nurbs surfaces
  • Ikh - IK Handels
  • SkClus - Skin Clusters
  • Clus - Clusters
  • Loc - Space Locators
  • MCNull - Mocap Null(a hidden null above the control where mobcap data is dumped)
  • Offset - A group that offsets the parent space of a zero group
  • Zero - A group that is used to Zero out the transform of its child. The name of the zero group should be the same as its child but with "Zero" added to the NodeType suffix. 

            e.g.

                Head_CtrlZero
                L_ArmTwister_JntZero

  • Geo - Renderable geometry

Note: Any uncommon / less used node type like a FourByFourMatrix should be written out fully for clarity.

Edited by Jarom Brand

Share this post


Link to post
Share on other sites

This is great, thanks @Jarom Brand!

 

i do have a couple of questions for ya - if you have time ?

I was wondering why you capitalize the first word in camel case? I’ve always done camelCase with a lower case first word - was your choice based off experience at a particular studio, or another language? 

How do you handle surfacing and materials?  For example, if you have a particular material for an arm I imagine the nodes might look something like:

L_ArmDiffuse_Tex

L_ArmSpec_Tex

L_Arm_Mtl

L_Arm_SG

and then you could add some plastic materials like:

RedPlastic_Mtl

BluePlastic_Mtl

?

thanks!

Share this post


Link to post
Share on other sites

This naming convention is one we came up with while I was at Mr. X. We capitalized the first letter because that's what the animation directors asked for. They liked the way it looked and felt like it was the cleanest. I have gotten used to it and now I prefer it. 

I have done very little with surfacing and materials in maya. All my work with surfacing, materials, lighting and rendering has been in Cinema 4D, and for some reason I tend to be rather sloppy with naming in C4D. So I can't really talk from experience on that, however what you have looks to be compliant with my naming convention. 

Share this post


Link to post
Share on other sites

What if instead of having long and complex naming conventions we could have a tagging system?.

say, "rig", "arm", "left", "deformation", etc, etc, and you'd have just the name of the object or body part and all those tags would help, finding, grouping, classifiying, hierarchying or so many other uses?

I may be saying just BS, but who knows maybe there is something there.

Share this post


Link to post
Share on other sites

Oh and a while ago, I made 2 posts about naming conventions in rigs in blender, because they decided to give you some naming conventions already for some things

Explained briefly, whatever ends in .L .R .l .r _l _R _left _Left _Right _right, is considered left and right, but has to END in those conventions, but there are a lot of advantages, mirroring rig in edit mode, autonaming the other side if you made only one, symmetrizing the rig aswel, and then in posemode mirroring poses or animation, quickly invertin selection to the other side, or adding the other side to the selection.

https://lollypopman.com/2016/02/23/quick-tip-naming-bones-left-and-right/

In the case of the second post, whatever is prefixed "ORG-", "MCH-" or "DEF-" will not get keyed unless you go manually key the transform attributes, so you can leave those bones untouched.

https://lollypopman.com/2016/02/17/quick-tip-naming-bones/

Would be nice to be able to customize these behaviours, that's for sure, but I'm already glad they exist just knowing them helps so much.

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, Luciano A. Muñoz Sessarego said:

What if instead of having long and complex naming conventions we could have a tagging system?.

say, "rig", "arm", "left", "deformation", etc, etc, and you'd have just the name of the object or body part and all those tags would help, finding, grouping, classifiying, hierarchying or so many other uses?

I may be saying just BS, but who knows maybe there is something there.

Tagging would be super cool for classification - especially if you could auto-color/filter based on the task that you're doing.  Does any tool do that?

Share this post


Link to post
Share on other sites
5 hours ago, Luciano A. Muñoz Sessarego said:

Oh and a while ago, I made 2 posts about naming conventions in rigs in blender, because they decided to give you some naming conventions already for some things

Explained briefly, whatever ends in .L .R .l .r _l _R _left _Left _Right _right, is considered left and right, but has to END in those conventions, but there are a lot of advantages, mirroring rig in edit mode, autonaming the other side if you made only one, symmetrizing the rig aswel, and then in posemode mirroring poses or animation, quickly invertin selection to the other side, or adding the other side to the selection.

https://lollypopman.com/2016/02/23/quick-tip-naming-bones-left-and-right/

In the case of the second post, whatever is prefixed "ORG-", "MCH-" or "DEF-" will not get keyed unless you go manually key the transform attributes, so you can leave those bones untouched.

https://lollypopman.com/2016/02/17/quick-tip-naming-bones/

Would be nice to be able to customize these behaviours, that's for sure, but I'm already glad they exist just knowing them helps so much.

One of the things I LOVE about blender is how it understands these naming conventions!  I didn't know about the ORG, MCH and DEF ones.. super cool!!

At dreamworks in PREMO we had a pretty cool tool that allowed you to mirror your interaction based on the name of the control.  So for example if you grabbed the left mouth corner and pulled it would move it.. but if you held down a hotkey (m, I think) it would also manipulate the right corner in the opposite direction.  Super fast for lipsync.  I loved it!

I wish more tools realized that riggers work symmetrically - and make it easier to do this symmetrical work.

Share this post


Link to post
Share on other sites
4 hours ago, Jason said:

One of the things I LOVE about blender is how it understands these naming conventions!  I didn't know about the ORG, MCH and DEF ones.. super cool!!

At dreamworks in PREMO we had a pretty cool tool that allowed you to mirror your interaction based on the name of the control.  So for example if you grabbed the left mouth corner and pulled it would move it.. but if you held down a hotkey (m, I think) it would also manipulate the right corner in the opposite direction.  Super fast for lipsync.  I loved it!

I wish more tools realized that riggers work symmetrically - and make it easier to do this symmetrical work.

Yes!, have you tried Animbot ? from alan camilo it has a tool to do that too (maybe would be something to consider having his tools available for maya animator would be totally a plus plus.) , crazily he managed to pull of a mirror tool that as far as ive used it, it works with any rig in maya, i just need now someone to code the missing tools from there  for blender.

Also blender if you create your increments with .000 at the end then it will respect that and go .001 .002 .003 , so even if not all is how you like it specially, its base conventions work really nicely when you manage to figure them out!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...