Aaron Koressel

Tool Design Philosophy

As a character animator first, and tool writer second, I have a handful of requirements for how I think an animation tool should behave. First and foremost, the tool needs to accommodate a fast and efficient workflow. 3D animation is already a painfully slow medium to work in, so every second that I can conserve means more time that I can spend experimenting. Working fast does not mean cutting corners in the animation process, it means automating the mundane, and turning 5 mouse clicks and a drag into one key press. My prime axiom:


Use Keyboard Shortcuts

Mice are slow for executing commands because they require visual feedback. In order to successfully click a toolbar button your brain has to say "Yes I'm hovering over the correct one, go ahead and click it". To borrow from Fitts's Law, consider then the major fall-off in efficiency if the button is particularly small, or on the other side of the screen.

A keyboard shortcut is confirmed via tactile feedback. Your keyboard hand is already in position and knows without looking what key it needs to press (of course, no hunting and pecking!). To maximize this efficiency further, I put anything I use regularly within reach on the left side of the keyboard. If I have to pick up my wrist to go somewhere else on the keyboard, it should be for a function that I don't use more than once an hour.

This keyboard fanaticism isn't to suggest every key in the graph editor should be moved with the arrow keys. Although ackMoveKeys is designed to do this, a mouse is still often faster because of how dynamically our arm and wrist can express both large and small values. But if you're in a more abstracted modality of thinking (i.e. like an animator, not a computer user) you'll know that this group of keys need to move down exactly 3 frames. If so, pressing Ctrl-Right Arrow 3 times rapidly will always be faster than:

(1) Translate Mode,
(2) hold Shift, middle drag one frame right,
(3) wait for maya to snap to one frame (visual confirmation),
(4)(5) repeat dragging and visual confirm,
(6)(7) once more for the final snap (wait was that 3 snaps?).

That's ridiculous, and for something as primal as moving keys, hours could be wasted over the course of a shot. To summarize: any function that I use at least semi-regularly needs a keyboard shortcut. I've designed my tools with this goal in mind. They are single commands meant to be driven by keyboard shortcuts.



ack Script Paradigms

I have attempted to design this canon of scripts for consistent usability. My hope is that by understanding the way one script works you should be able to use many others in the same way. The following mostly apply to the graph editor and curve manipulation scripts. These are the rules that my tools follow:


  • No Interfaces
  • Tools shouldn't have unnecessary dialog boxes. If I want to delete redundant keys for instance, I don't want to deal with a pop up window asking me for tolerance values, curves or objects, all objects or selection only, etc... I just want it done. There are some exceptions, but in general, dialog windows shouldn't be a part of my normal operations. The last thing I want is my screen cluttered with redundant "Go" buttons and meaningless sliders. See below for how I handle changeable parameters with ackSetup.


  • Curve manipulation not object manipulation
  • My tools will operate on keys and curves, and not necessarily objects. In my opinion, curves are the building blocks of animation and tools should manipulate at this level. If you're like me and often toggle off auto-load curves in a graph editor, there can be a discrepancy between what object is selected, and what curves are displayed. In this mismatched scenario, the tool applies itself to curves in the graph editor. If you do use auto-load, then you can disregard this rule because the objects selected are the same as the curves displayed.


  • Respect key selection
  • My tools, where applicable, will only apply its function to selected keys. This might seem obvious, but a surprising number of tools apply itself to all keys in a curve. This just isn't a fine enough level of control. You should almost always be able to count on deselected keys as being unaffected. In some of my tools (where it makes sense), having no keys selected means "apply to all curves".


  • Pivot points and snap positions look outside the selection
  • My scripts avoid the need for excessive mousing by applying it's function based on the selection's neighboring keys. For example: instead of hauling out the interactive scale tool with the mouse, ackPushPull just scales some amount from it's neighboring key with each key press.


  • Curves are processed independently and relatively
  • It doesn't matter if curves occupy vastly different value ranges - it's all calculated relatively. So using ackPushPull on an eyelid that ranges from 0 to 1, and a torso that ranges from 0 to 360 will have the same effect in the viewport: the pose will be pushed the same percentage on both controls. This rule also means that it doesn't matter if the curves are offset from each other because each curve has it's own pivot point at the closest adjacent key. So in one execution of ackPushPull there are as many pivot points as there are curves selected - potentially pivoting from entirely different values and points in time. This is far more useful than Maya's scale from a single point.


  • ackSetup to change parameters
  • A handful of my curve manipulation tools are considered ackSetup compliant. ackSetup is a special window that contains global parameters that all compliant tools look to for parameters. For instance, you can change the pivot direction between Left, Right, and Last Selected and all scripts that concern themselves with adjacent pivots will use this global value. ackSetup is entirely optional, and all scripts also have default parameters. What's even better is that ackSetup has commands for changing these global parameters with hotkeys, so it's easy to flip between states (like Left or Right mode) without even entering the ackSetup window. Furthermore, global variables are available behind the scenes if you want to wire up your own presets, batch scripts, interfaces, or anything else you come up with.




    All content, unless otherwise noted, are licensed under a Creative Commons BY-NC-SA License - 2017 Aaron Koressel