Nuke scripts often start out as well-intentioned, clutterless masterpieces that even Marie Kondo would be proud of. However, endless revisions and client notes in the heat of a deadline often cause tidy Nuke scripts to unravel into unintelligible, slow messes.
Compositors often lean into pre-comping to help wrangle these large, lethargic beasts, so Nuke will run at an interactive speed again. This article will cover best practices when pre-comping, to ensure you maintain optimal speed with your image processing.
When you pre-comp, you’re aiming to solve the following problems:
- Speed up a slow Nuke script, so you can work interactively.
- Render your shot faster, to allow for quicker turn-around times and more iterations where necessary.
However, sometimes pre-comps are used as a crutch for the lazy. Before you pre-comp, you should decide if you’re doing so as a quick fix, or if it’s totally necessary for your Nuke script to run efficiently. After all, pre-comping can actually limit interactivity, as you have to render every time you make a change. Sometimes a simple check to make sure bounding boxes are as small as possible, unused channels are removed, nodes are concatenating where they are able to, as well as only using nodes with heavy processes once (e.g. defocusing with one node at the end of your script, vs. defocusing every element individually) can prevent the need for a pre-comp entirely!
There is definitely a right and a wrong way to approach pre-comping. The most efficient way to comp a shot is to ensure you’re processing pixels as few times as you can get away with; the hallmark of a great compositor is getting to a fantastic end result with as little nodes as possible. If you’re working on one of those massive shots with many Deep renders, that also requires plenty of nodes to integrate plate elements, pre-comps are your best friend. Use them as sparingly, and as correctly as you can.
Daisy-chaining pre-comps, as per the above image, is not efficient for you or your computer. If your sky DMP changes, you must spend time and render farm resources re-rendering every subsequent pre-comp in the dependency chain. Your computer is processing the same pixels many times over when writing & reading every pre-comp layer, too. Then what happens when you realize your previously-balanced elements have now broken because upstream pixels have changed? You’re forced to re-balance the shot, and re-render all your layers of pre-comps once again!
Instead, it’s best to pre-comp like every Nuke script is going to be stereo-converted (this is beneficial in more ways that one!). If you plan out your work so that you’re easily able to A over B all your elements, and are able to pre-comp your A pipe without affecting anything else downstream, you’ve done a great job. Your renders change? No problem: adjust them accordingly, re-render only the changed pre-comp, et voila. The floor is now lava? Your script is already speedy and interactive, so you can efficiently comp in your new lava renders.
Speaking of efficiency, I am a heavy user of Tor Andreassen‘s fxT_precompController. This utility makes it super quick and easy to selectively toggle between a pre-comp or it’s associated section of the live Nuke script, without having to scroll all over the place & constantly rewire things. Definitely worth your time to download, install and try it out.