Clarifying the Animation (NLA) Workflow in Blender 2.5

Over the past few weeks, I've been quietly observing that people are finally starting to actually give many aspects of the animation system in 2.5 a good thrashing, and making feedback about the general state of affairs. Interestingly, this is coming some 8-10 months after when I was really keen on hearing such feedback and/or generally sitting around wondering what ways to best tweak the system. As things go, I now have a bit less time to work on many of these tweaks for another few months at least, with many exciting projects and coursework having sprung up in the meantime.

Nevertheless, it's good to be hearing these discussions at last. With some interest, I've been staying out of discussions to generally see how long it would take for "eureka!" moments to occur, when one or two users finally figure out the intended design as it should be (and is), and hopefully come to the conclusion that actually the situation is better (or significantly) than before. Indeed such moments have occurred, though in some corners it still seems to be taking a bit longer for this to happen.

So, to those who've been venturing out into the field, curiously probing and making new discoveries about how it all fits together and the implications of the new workflows, congratulations on making it this far! For everybody else, I think it's time that I shed a bit of light onto a few of these topics to help ease the journey.

Forget the old... in with the new!
Blender’s new animation system (nicknamed 'Animato') has been based on years of experience using and coding the old animation system and/or fielding support requests/complaints about the old system.

Technically, Animato tries to solve the goals of having 'everything is animatable' and being a cleaner, more well defined pipeline for animation handling with reduced ambiguity. Additionally, Animato represents a greater commitment to optimising the usability of the animation tools, with significant improvements in key areas.

In order to satisfy these goals, many backwards legacy hacks and methodologies have been removed and replaced. Please keep this in mind if you're migrating from older versions of Blender, as trying to do things in the same way as before will really make things a lot more difficult+confusing than they really should have been to start with.

Here I'll just mention some of the major things I've noticed that people seem to have trouble getting their heads around.

Keyframing
Perhaps one of the "key things" in animating, is setting keyframes. This is probably a topic that deserves a blogpost on its own (I've got one in progress on Keying Sets that I'm hoping will be relatively comprehensive), so I won't go into much detail here.

The most noteworthy issue here is about inserting keyframes for non-transform properties. This is stuff like "dLocX", "FStrength", "MisHi", etc., basically the cryptic names for properties that used to be shown in a list in the IPO Editor.

From what I've been hearing, most people seem to get baffled when they don't see such a list anymore in 2.5's equivalent editor, the "Graph Editor". There's a good reason for this: 'everything is animateable' means that that list would be REALLY LONG. If you really want to get a feel for that, open up the "Datablocks" view in the Outliner :) Therefore, only properties that are animated will have channels showing up here.

So, how do you insert keyframes for these properties then? Your two options are:
1) Try to find these properties within the Properties Editor (aka "Buttons Window"). Once you've found the property, either RMB->"Insert Keyframes" or IKEY the property widget. Done. Keyframe inserted.
2) Failing to find the property there, use the Datablocks viewer mentioned above, and do the same thing as per 1 once you've found the property.

Once you've inserted your first keyframe, you can then animate things in the same ways you used to (ctrl-click to add more keyframes for the active F-Curve) if you really wanted to. However, it's probably nicer to just change frames and repeat this process (after adjusting the value via the property widgets).

NLA
Perhaps the area that causes most grief for transitioning users though is the new NLA system.

Having spoken to a few of those who were confused about this, I think that it might help to understand what it tries to do and why.

Design considerations
When redesigning the NLA, one of the first things I did was I sat down and said: "What would anyone want/need to use this for?" From this, there were 2 main things:
1) Chain together a sequence of motions - e.g. "walk", "jump", "walk"
2) Animate in a "layered" way - e.g. "walk" + "wave" + "smile", or "rough animation" + "refining pass 1" + "refining pass 2"

The existing system certainly let you do the first thing (once you had some actions created). But the second thing was much less well defined, and many people who tried doing this ran into some of the problems which follow.

Furthermore, these two use cases naturally mapped onto the requests that people had been making for ages to allow multiple strips to be placed in the same "row" to better "organise" them. Each of these "rows" effectively related to one of the "layers" mentioned in 2), while the strips within each layer would be satisfying 1).

Another of my major considerations was cutting down on some of the buggy behaviour that people were getting, that (as I see it) was caused by the workflow that had to be used.
To animate once you had a NLA-strip setup, you needed to first add a new strip. But, because this strip is empty, how do you decide how long it (will) needs to be? IIRC, 2.49 uses length=100, and older versions used length = 0 or 1. However, all of these approaches will always mean that you don't have a strip of the right length. This makes the strips very susceptible to having "scale explosions" (i.e. scale factor quickly becomes > 1000, as all keyframes end up getting stored between frames 0 and 1), which are really unstable (keyframes end up jumping around a bit, especially when moved, but also when just panning the view), as a result of a nasty mismatch between strip length recalculation + scale calculations that can happen all too easily.

I've seen this sort of problem all too often, such that by the time I started the redesign, I was convinced that the existing workflow was to blame.

Also, the fact that you needed to add a new strip before you could start animating really made the workflow have more of an emphasis on assembling prepared cuts of factory robot meat vs being a tool for organic motion creation based on refinement/layering/passes. This introduced a difference between "pre-NLA animation" and "post-NLA animation". Pre-NLA, you just inserted keyframes, and a new action was created, but Post-NLA, you had to create the action first, and append keyframes to that.

Another consideration was that old NLA system had a number of confusing elements that nobody really understood that well, such as:
- Action vs NLA mode. Action mode was the default, but that meant working with NLA was often error-prone and confusing.
- Mysterious black dot that floated around beside strip names. This actually indicated the action being edited IIRC

Intended Workflow - Unifying these Design Considerations
Taking into account all of these considerations, I designed the "new" NLA system that is basically what you see today.

1. Animate normally - just start inserting keyframes, and then edit these in DopeSheet/Graph Editor until it looks good. A new action is created when the first keyframe is created ("active action").
2. In NLA Editor, click on the snowflake icon on the red "action" line under the name of the object you've just animated (i.e. "snowflake it"). The "active action" gets removed from the Object, and gets added to the Object's NLA-Stack as a NLA-Strip. This new NLA-Strip references that action.
3a. To animate create another action to refine/tweak some aspects of the NLA-Stack, just start animating again. That is, you're back to step 1, with a new "active action" created for all your keyframes to go into. Nice and simple.
3b. To edit an existing NLA strip's action (you may like to call this "NLA action"), select the strip and hit TAB. This temporarily disables (they are hidden, and stop being evaluated) all the NLA tracks above the one that contains this strip, and makes the NLA-strip's action the new (temporary) "active action". When this happens, you can animate in that strip's action just like before in step 1. When you're finished editing, just hit TAB to get out again, and the previously muted tracks come back, and the NLA-strip's action is no longer the "active action" anymore. It's just like entering and exiting EditMode :)

That's it!

Breakdown of Intended Workflow
Ok, so now you know about the workflow in general, let's have a look at some of the rationales behind each step (or hidden detail).

1. This represents your average user, animating away, without needing to worry about NLA at all. The only thing that matters here is that you've got an "active action" that you can see and edit the keyframes of. Inserting keyframes adds keyframes to the "active action".

You'll also notice from later steps, that anytime you end up doing any editing of any keyframes, you're here: editing the "active action". In the NLA Editor, this is represented by the reddish channel below the name of the channel.

2. The snowflake was chosen to symbolise "freezing" the "active action". This implies you're finished editing it, a "layer" or "pass" of animation has been completed (for now), and you're ready to look at the next step. It's a bit like the old "add new strip", except that no action/strips are created until you need them (i.e. upon inserting a keyframe). In the original design, I thought of this step as being "freeze + pushdown" (more on "pushdown" later).

3a. Represents creating a new animation layer to go on top of the actions already on the NLA stack. Alternative, it could also be creating another action to follow on from the previous one on the top-most layer.

3b. Selecting a NLA-strip for editing and then entering "Tweaking mode" on it is like temporarily reverting the NLA-stack back to the point when that strip's action was animated. This comes from the "animation layers" paradigm. So, by disabling tracks above, you strip off those layers that were added later, so that you can go back and revise that earlier stage. But, to be able to edit an action's keyframes, it must become the "active action" for the NLA-stack, so that conceptually we enforce that we're only ever editing the contents of the "active action".

---

So, I've talked about a "NLA-stack" and "layers", and "pushdown". How do these things related to each other?

Recall above the 2 use cases? Well, from 2), the NLA-stack is the stack of animation layers (these are more akin to GIMP/Photoshop Layers than Blender 3D-View "Layers"). These "layers" are officially known as "NLA Tracks".

Just like layers in image editors, the order of layers here matters, as it affects the order in which they are evaluated (i.e. calculated), which in turn affects which one at the end will be more dominant in the final result. Also, just like in these editors, the order of evaluation is from "bottom up", with the active action being the last thing evaluated on top of the NLA-stack results. So, let's see a little diagram of this to clear this up:

Look familiar? That there is an example of part of the "channel list" of the NLA Editor. The green arrows and annotations show the evaluation order.

As you can see, the bottom-most track is evaluated first, followed by the next one up, and so on until we get the active action evaluated on top of all of that. The total result of this stack is then flushed to the "stack owner" (i.e. the Object, Lamp, or other data that is animated using the NLA system. Part of 'everything is animateable' means that NLA should work for all of these as well as it does on Objects + Armatures and in the same way too ;)).

You'll see a comment there which says "find frame". Just as with standard animation, the current frame decides what part of the animation curves we use. So, here, the current frame determines what values we'll find on that frame through the stack. To visualise this, imagine shooting a bullet (or if you're a vegetarian, a non-invasive laser beam) through a stack of glass tanks. Each tank is an animation layer, with some fish swimming around, but the fish are so fat that they can't swim past each other. If you hit a fish as you travel up, it gets flattened onto your skewer. When you reach the top, the result you have is what you'll find by having a look at what parts of the fish you skewered. [EDIT: err... perhaps that wasn't such a great metaphor, but I hope you get the general idea for how the accumulation happens]

So, getting back to "pushdown". 
From the diagram above, you've got your "action action" poised on top of your stack. When you click the snowflake, Blender will try to create a new strip of the right length, and then "push" this "down" into "empty space" (i.e. a gap between strips, or before/after some) in the topmost track. Now, it may happen that there is already a long strip occupying parts of the region this new strip would occupy, or perhaps the gap between two other strips already in that track is too small. We cannot have strips overlapping within the same track (see fish analogy above), so a new track is created at the top of the stack (but below the active action, as it must always come last), and the new strip is added there. Hence, the "active action" gets "pushed down" from the "active action" row to the track a track at the top of the stack. Since this action is now represented on the stack, we can now clear-out the "active action" slot, ready for the next one to be made.

Other stuff you might want to know
There is some extra functionality for tracks that you should know about.
1) The 'dot' beside each track name now represents whether the track has been enabled for "solo" mode. This means that you can just preview the effects of just that track in isolation when this dot is yellow.
2) Eye icon beside "Stack owner" name disables all NLA-tracks, leaving only the "active action" running. This is the old Action mode vs NLA mode toggle, but it defaults to showing NLA results too instead of Action, as we can now do without this
3) When "tweaking" a strip's action, you can use the "pin" icon on the "tweaking action" track (i.e. "active action" track drawn in green instead of orange/red; note that the relevant strip is also that colour, while other strips using this action are highlighted in red to alert you to possibility of some errors/unintended editing that you are about to do) to toggle between editing the action "in place" (i.e. with NLA scaling+offsets), or as it is naturally.

There are also some more other new features, but I think those are relatively more straightforward than these, and are probably good fodder for later posts :)

Roundup
So, I hope this post has been an informative and useful reference for animators wishing working with the new Blender 2.5 animation system.

I probably should have written up these docs and posted them publicly a lot earlier, but writing "formal" docs for stuff (i.e. suitable for book form) is just a bit hard to do, as you tend to become inclined to treat it as "an eternally correct reference" vs "some errors may be present, use at own risk, and I reserve the right to only write up what is correct for the time of writing" ;)