Maslow's hierarchy of animation editing tools

People who are really experienced with text editors like vim and emacs can play them like a musical instrument. Open and closing files, navigation, find and replace, etc all just sort of magically happen while they type, without apparent cause.*

This kind of frictionless experience, where the UI gets out of your way and you can just do what you want, is what I want the animation process to be like. There is some low-hanging fruit in this regard that is already pretty common in conventional rigging--custom pick walks, for instance. But it usually doesn’t go very far beyond that. That’s because current animation techniques don’t generally rely on things that can be done with a keystroke you could commit to muscle memory. Instead, most operations you’d do with a conventional workflow require a lot of context (like, is this arm in FK, IK or somewhere in between on this frame?) and multi-step processes.

Creating an animation process that can be reduced to simple operations is a big part of the goal of the ephemeral/interpolationless approach. In trying to define the best ways for the animator to interact with the rig and animation data, I’ve ended up with a sort of hierarchy** of different ways of manipulating a character.

Modes

At the very top of the hierarchy is what I’m referring to as a Mode. A mode is for interacting with the rig in a particular manner, and all modes are mutually exclusive. You can interact with the rig in Forward mode, or Backward mode, or IK mode, and once you have done so the rig’s transforms have now been moved, but nothing else has changed.

A mode is, in my view, a superior animator interaction concept because it is completely “fire-and-forget.” What mode you’re using is only relevant while you use it. The system doesn’t remember what modes you’ve previously used, which means that you don’t have to remember either. Interacting through a mode is truly and completely ephemeral.

Options

If you can’t do something with a mode, you use an option. An option modifies how modes are used. In the current ephemeral system, for instance, you can choose to “suspend” intermediate controls such as elbows and knees for psudo-IK behavior, and it will do so whenever the mode you are in does not explicitly prohibit it (for example, Forward mode quite naturally insists that an elbow must be FK rather then suspended). You can also choose not to suspend them, and have elbows and knees maintain their position for completely free interaction of hands and feet.

This is slightly less good then a mode, because it’s not completely “fire-and-forget”--the option remains set until you change it, so you do need to remember what the options you’ve set are or you’ll get suspended behavior when you don’t want it or vice-versa. But because they are character-wide, you only need to remember a few of them--the current system has four--and it’s easy to display how they’re set in the UI in a way the user can understand with a glance. And if you get it wrong, it’s a couple of key strokes to undo, change the setting, and keep going.

In the future, I want to explore having the options depend on holding keys down rather then switching with a hotkey--this could make remembering what options are currently set even simpler, since you know they won’t be set unless you actively hold down a key.

Setting

If you can’t use a system-wide option, use a control-specific setting. This isn’t great because it requires that you consider how things behave on a control-by-control basis, but sometimes it’s unavoidable. The ephemeral system uses per-control settings in only one place--when establishing pairs between controls for interaction between a character and a prop, or a character and another character. I may end up needing to use them in other places as I expand the features of the system though.

Time-based setting

The absolute worst thing you can do is have a time-based setting. A time-based setting changes the behavior of the rig at particular points in time. Conventional FK/IK switches and space switches are all time-based settings, and they require the animator to keep track of rig state in multiple dimensions. First, what things are being switched? And second, when are the switches happening?

As any animator who’s done complex prop interaction using constraints can tell you, time-based settings are a special kind of hell. It’s so bad that many animators--myself included, depending on the situation--may choose to manually eyeball the relationship between a hand and prop just to avoid dealing with the pain that is space switching! I’ve come to believe that the ideal interface for animating characters would avoid time-based settings completely, and I don’t currently use them anywhere in the ephemeral system.

This is a set of ideas that takes some getting used to. When other riggers first encounter the ephemeral system, they often ask me why it’s not primarily setting-based. “Wouldn’t you want to offer the animator the ability to switch one arm to FK and the other to IK? Why wouldn’t you let them choose how breakdowns are made on a per-control basis?” However reasonable this sounds--and it does sound very reasonable, from the perspective of rigging and animation tools as we know them--the answer is no. I do not want to offer the animator that ability. As an animator, I do not want to have that ability.

As I’ve done before, I’d like to make an analogy to digital painting. You could theoretically program a painting tool to change brushes based on the layer or region being painted, which is (albeit weakly) analogous to telling the rig to behave a different way depending on the current time. You generally wouldn’t though. The additional cognitive load of remembering what everything was set to while you work wouldn’t be worth it. It’s easier to just change the settings of the brush to be whatever you need them to be right now, for what you’re about to do next. This becomes even easier if you bind whatever brushes you use to keys, and commit the key strokes to muscle memory. Once you can change how you interact in a quick and transparent way, the idea of trying to do it automatically becomes much more questionable.

Remember our graph of complexity against difficulty from Why Keyframes Are Bad For Character Animation? Well, we can make a similar graph for setting-centric vs mode-centric interaction models.

Just like with our previous example with keyframes vs dense data, the utility of time based settings goes down as “complexity”*** goes up. For simple things they’re actually great, but in the context of full character animation they’re a disaster.

This introduces something I’ve begun to think may be an important principle for animator interaction: Things that are easy to do are also easy to do over.

As an example, the current ephemeral system lets you make breakdowns in either default (ie ‘IK’) or Forward modes (I intend to expand the breakdown system to allow other modes, such as Backward, as well, but doing so requires a bit of extra bookkeeping and I probably won’t implement it until the next iteration of the system). But using forward mode commonly does various things you might not like, such as interpolating the feet such that they move through the floor.

The traditional answer to this would be to introduce control-specific settings. You could tell some controls to interpolate linearly and others in Forward mode. But there’s a simpler answer--if some part of the character does something you don’t want, just do that bit again!

Doing two operations like this seems much faster to me, from both a cognitive and operational standpoint, then doing one operation that requires you to muck around with per-control settings--especially since you’re very likely to end up doing two operations anyway after you inevitably screw up the settings the first time.

Animation tools have been driven by the concept of “more control” for a long time. The problem with this conception is that “more control” is a multidimensional concept. More direct control over a character’s silhouette? Very important. But fine grained control over rig behavior at the animator level? Actually, that may not always be a good thing. If we want to create better animation tools we’re going to have to learn something UX designers learned a long time ago: sometimes less is more.

*Despite rumors to the contrary, most vim and emacs users achieve their mastery of the text editor through a comprehensive set of key-bound commands. The percentage of the userbase that consorts with dark powers beyond human understanding is actually very small.

** You know I hate hierarchies, but this hierarchy is good, I promise. It’s like a turncoat hierarchy that was raised by kindly old people, and now hunts its own kind to protect humanity.

***As in my post on keyframes, “complexity” here doesn’t refer to visual complexity, but rather how “composable” the data you’re trying to create is. Motion graphics and graphic design are very composable--you can break down complex visuals into simpler pieces that will be composed into the final image/video. Painting and character animation are not easily composable, so I’m referring to these mediums as, for lack of a better term, “inherently complex.”