I’m excited to announce that I have just released a new course, aimed at introducing Compositors to GitHub!

If you are unfamiliar, Git is a powerful version control system, which supports the backbone of most modern VFX pipelines. Compositors like you are starting to embrace GitHub for finding and developing gizmos & python scripts, as well as version-controlling their .nuke directories.

Gone are the days where your Nuke preferences, toolsets, and menu.py have to be re-built at every new studio. Click here to get ahead of the curve, and introduce GitHub to your workflow today!

Compositing CG renders into a plate with a rack focus can sometimes be tricky to get right. However, your defocus has to match perfectly, otherwise the illusion falls apart! Manually creating keyframes and adjusting curve slopes can be a bit cumbersome, so I thought there had to be a better way to approach this. In this tutorial, I will share what I came up with!

We can learn a lot about what our CG needs by taking cues from our plate, and matching defocus is no exception. We can look at the size of our plate’s bokeh shapes, or how soft high-contrast edges are for reference. Animating a rack focus is a natural extension of this!

Continue Reading "Automatically matching a plate’s rack focus."

Nuke’s merge node has 30 operations, and finding a Compositor who has utilized them all would be a difficult task. However, I want to shed some light on two merge operations that are incredibly useful, and don’t get as much love as they should.

The most common operation, Over, is pretty self-explanatory: The image in the A pipe goes over the top of the B pipe. So how and why would this concept need to be expanded upon?

When working with CG renders that have baked-in holdouts, or if you’re creating and precomping your own holdouts using Deeps, you might find that you get dark edges when merging everything back together. This is where disjoint-over can help! Let’s take a look at a quick example to demonstrate:

Continue Reading "Disjoint-over and Conjoint-over, explained."

The beginning of my Compositing career started with After Effects, and while I’m now living and breathing Nuke, there’s one thing I still miss — the ease of use of After Effects’ animation tools.

Coupled with a recent fascination with bezier curves, I decided to set out and see if I could bring the most basic functionality from After Effects, “easy ease”, into Nuke, with a way to control the smoothness of that curve.

To start out, I wanted to explore what was already possible. Selecting a keyframe and hitting “h” on your keyboard changes the keyframe type to “horizontal”. If you do that on the first and/or last keyframe of a curve, you get a smooth ramp in/out. However, if it’s not easing enough, grabbing one of the handles and trying to adjust the curve quickly results in frustration.

Continue Reading "Programmatically editing animation curves in Nuke."

Using TCL expressions in Nuke can help us to evaluate mathematical operations, as well as link values together to create something new. However, an often forgotten feature in Nuke is the ability to add expressions to RotoShapes and Paint strokes (which are also splines under the hood).

Nuke’s built-in “Tracker linking dialog” (pictured above), helps us to link individual vertices to various things in a Tracker node, and is doing so by automatically adding TCL expressions for us! However, what if we wanted to link things the other way around?

Continue Reading "A simple tutorial on using expressions with Paint Strokes."

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.

If you haven’t already, I recommend periodically switching this feature on and paying attention to any warnings that show, to ensure your Nuke scripts remain speedy and efficient! Although once you’ve optimized your bboxes, I would advise turning this feature off again, as it automatically processes every node every time you change frame, and can cause dramatic UI slowdowns on larger scripts…

Additionally, think about some knob defaults you can set on certain nodes to ensure your bbox stays small.
(e.g. create a shortcut that creates a Merge node, sets its ‘operation’ to mask and it’s bbox to A)

Lastly, with any node selected, you can run nukescripts.autocrop() in Nuke’s Script Editor to automatically reduce the size of your bbox to its optimal size.

Thanks to Conrad Olson for the tip!