Nodes vs. Layers

The following is a slight retooling of an email I sent to a small group as a part of a discusion about the layer-based compositing paradign, as found in After Effects, “vs.” the node-based system used by Shake, Digital Fusion, Nuke, and others. It’s partly a petition to get After Effects to expand its node interface option, and partly an attempt to undertstand these two different ways of visualizing the image assembly process.

A filmmaker friend was making the transition from camera crew to screenwriting, and misguidedly asking me for advice along the way. She was having a really tough time with the notion that all great films subscribe to very similar “rules” of screenplay structure. Surely, she thought, this was an outdated notion, and in order to make one’s mark one should dispense with any such formulae.

I said to her, “Think of it in terms of photography. Every photograph has a composition, whether it was consciously studied or an accident of a dropped camera. But is it good composition? Every screenplay has a structure, whether arbitrary or calculated. So the question is, do you want to better understand the structure of the thing you’re writing, in the same way that knowing the Rule of Thirds may help you understand why you don’t wish to use it on a particular shot?”

Or something like that. However I put it, I think I got her to come around a bit, if not become a Syd Field devote. Anyway, the question of nodes is similar to this example. Any non-destructive image processing system has a process tree. The only question is, do you want to see it?

What crazy program is this? It’s the purportedly un-nodal After Effects, of course. AE’s mysterious Flowchart View (when fully unfurled) is almost identical to Combustion’s, which is the best candidate for comparison since both apps have the notion of a layered “Composition,” or Comp, as a special type of node. AE, like Combustion, is actually a node-based compositor underneath all the fancy UI.

It seems to me that Shake and Digital Fusion, the applications we most associate with hard-core nodalogy, are heavily biased towards a Big Complicated VFX Shot model, where all inputs are likely to be the same size and duration. Want to put A over B? Use the “over” node. Want to put 100 layers together? Use 100 of those nodes. Want to reorder those layers to see how they might work together another way? That’s gonna take some time. Wanna see how things relate in time? Good luck.

AE’s timeline is an obvious advantage over these guys, but so too is the idea of a “node” with an infinite number of possible inputs, layer ordering, transfer modes, and 3D transformations. That node is the Comp. Why a Shake or DF user would not want to avail themselves of this, the most powerful of image processing tools, is beyond me. But the trade off is that they can see at a glance exactly what is happening to their images, something that is tricky in Combustion and nearly impossible in AE.

Remember the last time you took over someone else’s complicated AE Project? That was probably the last time, if ever, that you broke out the Flowchart View. Since you can’t edit the project with it, it’s basically a handy browser to better understand what’s going where. There’s no better tool for understanding the structure of the Comp than the Timeline/Comp Window combo, and there’s no better tool for understanding the structure of the Project than the Flowchart View.

I find the Flowchart View most useful as a replacement for the Project Window. To this end, I find it most intuitive when it is configured as shown in the attachment - Layer switch off, zoomed such that all text is visible. It seems to be less of a screen real estate hog in Left to Right mode rather than Top to Bottom. Most of my wishes for the Flowchart View are for features that help me use it instead of the Project Window - updating its context menus to match, some drag-and-drop action. Simple things that would facilitate using the Flowchart as the principal navigation tool for the project, but not necessarily as a way to edit a Comp.

When I do switch Layers and Effects on, there’s a small part of me that even thinks it might be cool to see the effects on a layer strung out sequentially like in Combustion. Maybe I could even see adding and editing effects here. But it’s not important. The thing that’s important to understand is that this would not change the way AE works at all — it would just expose the inner workings a bit more, making it more obvious what AE’s largely hidden Order of Operations is, which is a point on which many users get hung up time and again.

That order of operations belies a complex set of tasks handled and made very simple by the layer paradigm of AE’s Timeline. The above image is an attemt to illustrate the inner workings of AE’s layers to an experienced Shake user. The script pictured is the Shake equivalent of a three-layer comp, with each layer having 2 Effects applied. Is seeing everything that’s going on always a good thing? Shake users probably look at this image and think, “Ah, sweet clarity.” AE users probably want to run from it.

Most AE users think of the Comp as the workspace of AE, when in fact it is the Project. Precomposing removes something from this Comp model and instantly makes things a little abstract and raises many questions for new users. Telling them they have to precompose to get some effect to work as they expect makes it even worse. In Fusion, Shake, and even Combustion, there’s a strong sense that the flow, script, or workspace (respectively) is the creative arena. I’d love it if this was true of AE’s Project as well. The way Comps work in AE is perfect, but the way the Project is viewed and edited as whole could use some help.

Being able to twirl open the contents of a precomp in the Timeline would be one great way to improve this. It may even be enough to permanently rid people of precomp-phobia. But I think the Flowchart View is the tool to make people truly understand what they’re doing with AE at the project level. And it doesn’t need any crazy new functionality to become this — it just needs to be a viable alternative to the Project Window.