Our “Rules”

These are some of the rules we work by. Maybe you’ll find them helpful too:)

General:

• People don’t like to read instructions. They might watch a video. If it’s short.
• The question is never if something can be done but if the time spent is outweighed by it’s usefulness.
• Credit those who help you or who’s work you use a a base.  Our industry is small.
• Document your code. Be considerate, you could die tomorrow
• “It’s always been this way” is not an acceptable reason to not try something else. “We tried that and it didn’t work because x” might well be.
• “I don’t like that” is a criticism with no practical value. “I don’t like x because y” is better. “z might work better than x” is better still.
• Don’t reinvent the wheel. If there is a perfectly good tool out there, why make another?
• No pymel in the base libraries. For why, see this post from one of our favorite toolmakers.

Tools:

• Tools should be intuitive and efficient. One button doing different things depending on what is selected at the time it is pushed  is better than 4 buttons to handle those tasks.
• 3 steps is better than 4, etc..

GUI Rules

• Tools should attempt to usefully load selected objects into a gui if the logic checks (one less step)
• When a tool creates or updates something, it should be selected at the end
• When a tool requires a selection, that same selection should be selected at the end of the process unless something new was created
• Function Priority
  • Selected
  • Loaded

Rigging

• Rigs must scale.
• Everything created shall be named
• Any hard stored positional information (as in on an extra attribute) will be stored in cm (maya’s default unit) and should be translated on call to your local units
• Controls
  • Every animation control must zero out
  • Main controls should have at least one constrainable group transform above them
  • Rotation orders deserve some thought.