Blog Posts: tagged with Quick Tip

Managing the size of your Comp’s bounding box is one of the lowest-effort things you can do to find massive performance gains in Nuke. There are a few things we can do to stop processing extra, unseen pixels, and speed up your comp.

Some gizmos dynamically hide/show a number of knobs with the KnobChanged python callback. This is a good option to keep your gizmo's UI clean, but can start to get very heavy when you have too many knobs to handle, and too many nodes inside your gizmo.

Instead, it can be cleaner to use Python Script Buttons to add/remove knobs/nodes from your gizmo to keep things fast, neat and tidy.

I whipped up the following example node, which you can download here, to see how this works.

Some nodes in Nuke, such as the Particle Emitter or your favourite Camera Shake gizmo, have a random seed knob. This allows you to create a different variation of a setup using the same parameters on a given node. When these setups are used throughout a sequence, we often want to change up the random seed value so every shot matches an approved look, but doesn't behave in exactly the same way.

When setting up a sequence template, you could expression link all random seed knobs to a NoOp-based control panel, but there is a better, more automated way to get a "random" value by default.

There are two common ways you can expression-link knobs in Nuke.

1. CTRL+Dragging one knob to another
2. Right-clicking, choosing "add expression", then typing your expression.

The TCL syntax for expression-linking knobs is simple: {node_name}.{knob_name}.

However, there are some knobs that are a little more difficult to expression-link. For example, a channels knob can only be linked to other channels knobs, by CTRL+dragging+dropping the = button between them. Additionally, there is no visible option to expression-link Pulldown Knobs, such as a node's filter knob. However, we can solve these problems with a little bit of Python.

In the following example, we're going to be expression-linking Transform2's filter knob to Transform1's filter knob. Let's write one line of Python to help us do this in the Script Editor.

In Nuke, you're able to dynamically change any knob's value depending on if you're looking through a Viewer in Nuke's GUI, or rendering your Nuke script on a render farm. This can be useful to keep your Nuke scripts light & efficient while working, while automatically switching to more processor-intensive tasks at render time — for example, increasing motion blur render samples.

When adding a new gizmo to a menu inside of Nuke, I like to recycle the existing icons so I can keep everything thematically consistent. However, these icons are buried inside Nuke's install directory, and I always forget exactly where they live...

When warping, I always use ST Maps as the base, as they provide so much extra control. Nuke's built-in "MotionBlur" node, RSMB, and other nodes are available to generate motion blur from our warped input images, however, these nodes are generating new motion vectors, essentially making their best guess at where the pixels are travelling. Wouldn't it be better to use our warp data to drive this instead?

You might have seen gizmos with knobs that dynamically disable/enable, or hide/show, based on the value of another knob. This is achieved by accessing the knobChanged knob, which is hidden to users, and can be accessed via Python.

We've all had one of those shots where our CG animates through frame and needs to change from one lighting condition to another. Perhaps this is a character travelling from indoors to outdoors, flashing lights in a scene, or an object passing through atmospheric haze; it can come in many forms.

This has been a feature since Nuke 11.3v1, but I had no idea it existed until recently! In Preferences > Node Graph, there is a setting that enables a warning on a node when its bounding box is larger than a certain preset threshold. When enabled, the erroneous node will display a thick red border with a black dotted line around it; any downstream nodes that carry the large bbox will only display the black dotted line.

A common complaint I hear among compositors, especially those working on large shots is: "My script is so slow". There are many things to consider when trying to speed up a cumbersome script, but the sneaky culprit usually reveals itself in the form of a ReadGeo node importing geometry over the network.

SmartVectors, and the associated VectorDistort node is one of the best new additions to Nuke in recent years. Being able to effortlessly track a texture to an organically-moving object is amazing when it works, but oftentimes SmartVectors only gets us part of the way there and needs refinement...

HTML is a programming language designed to view documents or websites in a web browser, although we can make use of it in Nuke to add some extra style to our nodes, gizmos, etc.

The aim of this article isn't to teach you HTML, as that would be rather convoluted for what you need to know, but instead, I'll share some easy snippets of code that will help you inside of Nuke!

Something I'm endlessly frustrated by is having to work around the way Nuke uses confusing hex colour values in Python to do things such as set a node's tile_color knob. For example, how are we supposed to remember that 0xff000ff = green ? I wrote two simple functions to get around this, which I hope you can make use of too...

Updated nodes in Nuke should be better than their predecessors, although that's not always the case. For example, I love that the latest VectorBlur node is GPU-accelerated, although I find it's output quite arbitrary; it never does what I expect out of the box, and I personally prefer the old version.

Classic financial advice tells us, "to save a dollar, you first have to save some cents". The same can be said about your time. Those extra few clicks per shot might only cost you 5 seconds. Although 3 shots per day = 15 seconds per day = 1 minute, 15 seconds per week = 1 hour, 31 minutes and 15 seconds per year. Share that with your 10-person compositing team, and the results are obviously ten-fold! The numbers add up quickly, so as you can see, it pays dearly to create your own tools & save time and clicks wherever you can!

Cheesy stock photo aside, it goes without saying that who you work with makes a big difference. I would argue that it matters more than the project you're working on.

The ImagePlane gizmo is my favourite for speedily placing an object on a card in (pseudo) 3D space. Rather than dealing with Nuke's clunky 3D system, you can easily get a handful of atmospheric smoke elements layered up and in your shot! But that convenience of fast setup time comes at a price...