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.

