Shake to Nuke, a transition guide - Part III: Data Flow

Written by Ivan Busquets on .

3. Data flow

 

Visual indicators:

Both Shake and Nuke are node-based compositing packages, so if you're used to working with Shake, you won't have too much trouble building and interpreting a script in Nuke. However, Nuke does provide a few more visual cues than Shake as to what's happening on each node. Here's a sample of the different node indicators you may find in Nuke:

 

nodeIndicators2

Layers/Channels:

Apart from learning to read the node indicators, a key factor to understanding Nuke's data flow is understanding one of Nuke's most powerful features: the Layers/Channels system.

There's a lot of literature on that subject already, so I won't cover this in detail here. I recommend reading the "Channels" section of the User Guide, and visiting this other tutorial by Matt Leonard:

http://www.nukepedia.com/written-tutorials/understanding-nukes-unique-layer-and-channel-system-including-the-shuffle-nodes/

For the purpose of this guide, I'll just present a simple example of one of the multiple situations where the Layers/Channels system in Nuke can come in very handy. As a Shake user, you might recognise the following situation:

 

channelsShakeTree

Ugh...

 

You have been given some mattes (or rotoed them) that go with a plate. You are transforming that plate before combining it with another element. Now, you could have used your mmattes to grade the plate before that, but for whatever reason you want your grading to be applied on top of the composite, not only the original plate. You will probably end up making clones of all your transformations to apply them to each one of your mattes. If the number of mattes grows, things can get ugly...

Here's one  of the different ways you could build the same tree in Nuke:

channelsNukeTree

While you're still on the branch of your plate, you could create your roto to be stored into a new channelset (layer) and call that layer 'mattes', for example. This layer can contain multiple channels. So, you can set each one of your roto nodes to go into a different channel.

In this example, a matte containing the trees is stored in 'mattes.trees'. That is, a channel you arbitrarily called 'trees', inside a layer you arbitrarily called 'mattes'. You could do the same thing for as many mattes as you want.

Now the branch of our plate has an additional bit of data (the 'mattes' layer), that gets carried along. So, when we later do some transformations, those are applied not only to the rgb data, but also to the additional 'mattes' layer. At this point, you already have your mattes transformed, still stored in those same channels you put them at. They are there for you to use them any time you want.

You can then perform your layering operation, and proceed to do all the grading, using the relevant layer/channel for each Multiply node by choosing it from the mask dropdown menu.

Your mattes were already transformed the same ay the rgba data was transformed, so everything will still line up, without needing to duplicate any transforms.

This is just a hypothetical and simple example of making a 'good use' of Nuke's layer/channels system. Once again, I recommend you read more about this in the manual and check out the tutorial link above. This tends to be a bit of a dark area for people making the jump from Shake to Nuke, but it's a very powerful feature and it pays off to spend the extra time in understanding it.

 

 

'B' is the main pipe:

 

This is another difference between Shake and Nuke that tends to confuse people at first.

In Shake, layer nodes usually have their inputs labeled as 'Foreground' and 'Background', the main input being always the 'Foreground'. That means, if the layer node is ignored/disabled, the 'Foreground' input is the one that will be passed through.

In Nuke, merge nodes (or other nodes with multiple inputs) have their inputs labels as either A and B (and A1, A2, A3... for additional inputs), or 0 and 1 (and 2,3,4...). The main input in these cases is the B input in the case of letters, and the 0 input in the case of numbers. Again, that means the B input is the one that will be passed through when the merge node is disabled.

The following screenshots show this difference when using an 'Over' operation:

AoverBShake

AoverBNuke

While some Shake users might disagree, Nuke's behaviour is, in my opinion, a much more logical one. Specially as you merge more elements on top of your background.

Imagine you have a BG plate (B) and a few elements comped over it. If you keep your background on the B pipe of all your merge operations, you could, at any point in your tree, ignore the over operation of a certain element, and get the BG with all the other elements (except the ignored one, of course) as a result.

In Shake, you would either have to resort to using 'Under' nodes instead. Otherwise, ignoring an over would ignore the whole BG up until that point, and pass through the element that goes in as a FG in the over you ignored. Not very intuitive.

The 'B is the main pipe' premise is an important one to keep in mind while building your scripts. Quite a few merge operations in Nuke are duplicated so you can choose which input you want passed through when the merge operator is disabled, or what input you want to drive the output resolution (The B input is also the one that will drive the output format when using inputs of different resolutions, but that behaviour is the same as Shake's default 'use background resolution').

A good example of those 'duplicated' operators, and one that also means a significant change when coming from Shake, is the inside/outside operators, and their equivalent mask/stencil in Nuke. Let's take the 'outside' operation as an example:

Nuke has both 'out' and a 'stencil' merge modes, with identical math. The only difference lies in what input is being held outside the other. It's easy to find the logic behind it by using the 'A - B' paradigm. In this case, we could read the operations as follows:

  • A 'out' of B : image A is shown outside B.
  • A 'stencil' of B : A is the stencil of image B.

So, essentially, they would do the same, but with the inputs switched. But it's convenient to have both because of the reasons mentioned before: B pipe is always the one that drives the output format, and the one that gets passed through if the merge is disabled. The following screenshots illustrate this difference.

outVsStencil_copy

out/stencil operators in Nuke. Use one or the other depending what input you want to treat as your 'main input'

 

Other examples of equivalent merge nodes are in / mask, over / under, minus / from. Just like with the example above, use one or the others by choosing what input you want to treat as the main input, and connect that one to the B pipe.

 

Optimization tips:

As a final note to the subject of Nuke's data flow, here's a few things you should try to keep an eye for in order to keep your scripts optimized and get the best performance out of them.

 

- Keep track of bounding boxes

Nuke operators do all their processing to the area of the image inside the bounding box. The bounding box can be smaller or larger than the image format, and some operators can make them grow (particularly transforms that move or scale the image by a big amount). In those cases, you may be left with a bounding box that's larger than you really need it to be, forcing Nuke to process more data than you actually need. It is always a good idea to keep an eye for bounding boxes that appear to be larger than the image format, and bring it back to a size as small as possible. Ideally, a bounding box should always be the smallest possible size that can enclose all the image data you need.

bbox

Example of an unnecessarily large bounding box. Look out for those!

 

Watch this great video tutorial by Frank Rueter to learn a lot more about boundng boxes, the reasons why they might grow unnecessarily, and how to get them back to the size you need them to be:

http://www.nukepedia.com/video-tutorials/15/video/

 

- Keep an eye for unnecessary processing done to additional layers/channels:

With great power comes great responsibility! Now that you can handle multiple channels along the tree, make sure you're not operating on more channels than you really need to. Some operators in Nuke (mainly grade, filter and merge nodes) will let you choose what channels you want them to operate on. Make sure you set them to use 'rgb' or 'rgba' when you're certain you only want the effect to be applied to your rgba data. This is specially important for filter nodes, that tend to default to processing 'all' channels.

blurChannels

Changing a Blur node to only operate on the rgba channelset

 

Even if you didn't consciously add new channels/layers in your tree, keep in mind that some nodes (like the ScanlineRender) can generate data into channels other than rgba by default. It is therefore always a good idea to keep an eye on what channels you're carrying at each point in your tree (have a look at the 'visual indicators' section at the beginning of this page to see how to check if you're carrying data on additional channels), and set your nodes to process only the data you need.

 

- Be careful when using operators that need to request different frames to produce a result

Some of the operators in the 'Time' toolbar (like FrameBlend, TimeBlur, TemporalMedian) need to sample the image at multiple frames to produce their result. This also applies to retime nodes like OFlow or F_Kronos. Unlike Shake, Nuke is flexible enough to let you use those operators at any point in your tree (instead of Shake's retime inside the SFileIn), but be careful if you use any of those after a heavy-processing section of your tree. Keep in mind that, if your time operator requests n different frames to produce its output (like a frameBlend), the whole tree above it will need to be processed n times, one for each frame requested by the time operator. If you're doing a frameBlend of multiple frames (or retiming using motion vectors, or doing a TemporalMedian) somewhere in the middle of your tree, it could be worth pre-comping and rendering right before the time operator. It will be a lot faster to read n different frames written to disk, than processing the whole tree multiple times.

You have no rights to post comments

We have 2748 guests and 127 members online