Categories
Blog Post rigtip video

Cult of Rig : Season 00 day 001 Naming and Components

season 00 day001 stream – namingAndComps

What the first Season will be about:

  • Show was inspired by HandMade Hero format
  • Few streams leading up to SIGGRAPH and first season will be after SIGGRAPH
  • New rig every season getting more complex
    • Season 1 will be rigging  a Unicycle in Vanilla out of box Maya
    • How to organize the rig
  • Performance is a big part of this “The absolute #1 important thing in a rig”
    • Check out what can be a bottleneck
    • If we hit a node we are missing we will write it
  • Escalation of concepts- not just a button combo of clicks and “named” technique taught as if they were something special. Learning the maths and ideas and design of a rig
  • Start with the simple rig needs and as we hit something like algebra or a need for vectors, we will dig into them piecemeal.

First Principles “8:00”

  • Rig by first principles – something you assume to be true and base your thinking on.
  • Have to be simple and bullet proof basic building blocks.
  • Nothing should drop the performance of a rig unless necessary. (feature vs. performance)
  • Great ideas that are slow don’t get adopted (clunky demos) so make them fast

Rig organization – Naming Conventions

  • Not a matter of opinion (despite your opinion of them 🙂  but don’t follow along blind, explore your own and try it out
  • First principles of naming
    • Names will be strings
    • Facts about strings
      • CPU string processing is slow
      • No long tokens at start of string (token discrete element or name)
        • component_side_ etc_extension or type
        • Note: “Type” is what it should be used for not just what it is “loc” example , DON’T DO THIS
        • Instead the “Type” is what the node is doing, not what it is – examples – “hrc” (hierarchy separator or spacer ) “srt” (scale rotate translate) “srtBuffer” (aka zero or offset or pivot)”leg_R_something_srt”We will look at Apps Hungarian notation as reference
      • Edges of the string are fast to get to in code
        • First block “leg” will be fastest part of string compare
        • End block is second fastest, “FK” checking the string
        • block length doesn’t matter, doesn’t have to be 3 char for example.
      • Capitalization  use  “lowerCamelCase”
      • _L_ _M_ _R_  vs. _Lf_ _Rt_ _Md_  etc.. doesn’t matter really it just depends on how you want to do it and how many things you have to describe, what do you do if you have more than just left and right?
      • Name spaces vs. separators? Need to use Name spaces to fully get use out of Maya but the problem is that the tools to deal with them are or can be buggy.
      • NAME shouldn’t have any effect on what happens to the node or what the node actually does on the back end.
      • NAME should be able to made sense of if you have to work through the rig during trouble shooting or tracking down a bug.
      • Context Matters (hiearchy + name) can help make sure you know what the nodes are doing.
      • Remember the name is also for the animators and a good naming convention will help them know what they have selected and what they do and how much space they take up in the graph editor outliner so understand when and where to be flexible.
      • Question – What about fingers or spine Numbering?
        • “hand_L_[finger01_knuckle]_srt or fingerKnuckle_L but more of this will be covered in the next video talking about how to break the rig in to components

Rigging Dojo note: “There is an argument for not putting a buffer node above controls that will be in world space” I will disagree here because of how many cases where having animation be relative to a transform node and not the world is such a great thing,  that we will recommend you buffer any animation control nodes. You could argue that you can always move the data to be relative and bake the animation it back out to world but that is a time cost that isn’t worth it.

Rig organization – MetaData 59:00

  • Names can act as redundant work but don’t replace or should be used as MetaData
  • Have as much redundancy that doesn’t cost performance as possible.
  • MetaData can be a source of problems or get broken, causing TD to have to troubleshoot by hand or repair from the name but name isn’t only source.

Intro to components:

  • For you to organize the rig
    Example: Bike
    Wheel + Fork/frame + pedals
  • Help with evaluation of graph not just pure visual
    • What order do you want the components to drive each other
      • Pedals drive wheel?
      • Frame moves Wheel and updates pedals?

Rigging Dojo note: “Raf digs in to some examples on circular logic but the core concept is good component design allows for more flexibility in changing relationships AKA having easy space switching or layers of drivers that don’t break.
Picking what and when is in charge like a multi way constraints
Raf hits a point where he gets to the point of why and what he really means with not labeling techniques like “Broken Hierarchy” or “Flat Hierarchy”  He doesn’t have formal names for this part due to the existing names not being clear so he would call a “Flat or a non-hiearchy” a WIDE vs. DEEP hiearchy.   It can’t be a hiearchy if it is flat and it isn’t Broken hiearchy because it works and it isn’t a hiearchy either. We Actually agree here that being stuck on the  names for things and not being mindful of or creating meaningful ideas of what is really there “seeing the rig” vs. getting stuck on a technique name.

Wrap up QA

 

Get involved:
Follow me on twitter for announcements and news
https://twitter.com/ThE_JacO
Follow the Streams live on Twitch
https://www.twitch.tv/cultofrig/
And keep up to date with news on the website
http://www.cultofrig.com

4 replies on “Cult of Rig : Season 00 day 001 Naming and Components”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: