Download the script from Nukepedia here:
I've written a handy Python script that takes a look at the selected read node and sets the project full-size format, aspect ratio, and frame range to that of the read node. If the full-size format does not exist in the current user's list of formats, it prompts the user to name the new format and adds the new format to the dropdown menu before setting the project settings. Useful when first creating a script and you want to quickly set your project settings.
I've used this script a handful of times when starting up a fresh Nuke project. The script makes setting project information snappy when you know that the read node you're bringing in is exactly right resolution, frame range, and aspect ratio as the output. The idea for this script came from some programming phrase that's something along the lines of "If you have to do a dull simple task more than twice, automate it." And that's exactly what this script aims to address. Setting the project settings has to be done every single time you start on a new shot and it requires multiple steps. Having the ability to adjust all the project information saves a few clicks and lets you get working faster.
Part 1: The Label
The first step I take to organizing my Tracker node is to display the Reference Frame as well as the type of motion that the Tracker is currently using. Being able to view the Reference Frame without having to dive into the node is quick and can help when creating roto-shapes that will be attached to this Tracker. Seeing the output type is helpful for a similar reason, with a glance I can tell what type of motion I should be seeing when viewing the Tracker. This can be achieved with some simple Python code added to your menu.py file.
Furthermore, I find it helpful to have the Tracker's reference frame automatically set to the frame when the Tracker was created. When I'm looking for an element to track, I place my Tracker node on the frame where I want to start my track. This line of code allows me to skip the extra clicks of going inside the node and selecting 'set to current frame'.
Finally, there are a few more defaults that I adjust for my Tracker node. These are mostly personal preferences and are pretty straight forward so I'll refrain from writing more than what's necessary for them.
I set my shutter offset to centered because cameras in the real world always have motion blur that's centered around an object. It's strange that nuke even has this as a default for so many nodes. However, I rarely use the Tracker for calculating transforms because it's quite slow compared to a baked Transform or Corner Pin (more on that later).
I check 'adjust for luminance changes' which I find quite often gets me a better track.
I also check 'hide progress bar', which is a total personal preference, I don't like seeing the bar pop up when I start tracking. I've seen some compers who like to put the progress bar in its own windowpane within Nuke's UI as well.
I set the default export dropdown to 'Transform (match-move, baked)', more on that later on. In the end, the code in my menu.py looks like this
Part 2: Baked Tracker/Corner Pin Naming
When tracking, I like to use the 'Transform (match-move, baked)' export option. I've found that linking Transform nodes to Trackers slows down my comps. The slow down may be caused by Nuke having to process both the Transform and the Tracker nodes when drawing up a frame.
The big downside to this is that, by default, the baked Transform/CornerPin created from the Tracker is difficult to differentiate from regular old Transforms. Additionally, there's no easy way to tell which Tracker created that Transform. Being able to tell where a baked Transform came from is super helpful for other compers picking up shots and when I'm iterating through multiple Trackers. I've written a Python script that is called when the user presses the 'create' button with the Transform (match-move, baked) or CornerPin (match-move, baked) dropdown selected. I've left out the stabilize versions of these as I typically check the 'invert' checkbox within these nodes, to swap between matchmove and stabilize transformations. The script creates a Transform/CornerPin node and sets the nodes name with this format 'TrackerName_Matchmove' or 'TrackerName_CornerPin' depending on the drop down. It also adds in the Trackers reference frame to the label of the Transform. Here's a link to a GitHub page with the 'customTrackerIS.py' script.
To use this script, you have to add these lines of code to your menu.py file:
Part 3: Fast Toggle Tracker TRS Checkboxes
The final amend to Nuke's native Tracker node that I've implemented is a Python button, built into the node that allows me to quickly check or uncheck the translate, rotate and, scale options for all tracks within the Tracker. I do a lot of my tracking using Mocha and when I copy over a Tracker node from Mocha into Nuke, all the tracks inside the node are toggled off by default. I'd find myself having to click through every translate, rotate and, scale checkbox toggling them all on. Using the 'manage user knobs' in the Tracker node, I added three boolean knobs, one for each translate, rotate and, scale and a PyScript button. When pressed, the PyScript button will look at the three checkboxes, and change all tracks in the node to match the selected boxes. So if the user ticks off just the translate and presses the button, only the T (translate) knobs for all trackers will be checked. Here's a GitHub link to the TRS custom tracker node.
Additionally, I've added a separate python script that allows me to quickly tick a specific column using a hotkey. To check all the boxes I can press shift+t, shift+r, and shift+e for translate, rotate, and scale, respectively (shift+s is bound by default for nuke's settings menu) Here's a GitHub link to the script. This script also needs some code added to the menu.py:
That about wraps it up! I'm always looking for more ways to streamline my compositing process, if there's a better way I could be running things, shoot me a chat.
Recently, I've been working on comps that required me to use the native Nuke 3D particle system to create a basic simulation to enhance live-action elements in a few shots. I had various particle nodes piping down into a scanline render at the bottom of the comp, before being merged with the background plate. Many compositors are all too familiar in knowing that nodes like the scanline render can easily become like sandbags in your comp. It only takes a few of these nodes to get the machine grinding, especially with high sample counts. The main issue was that when I previewing my work, a low sample count was acceptable to get the gist of what's going on in the shot, but when I sent the render to the farm, I wanted a higher sample count for the final output.
I tried a few different methods to help solve this issue such as creating a NoOp adding a slider knob and expression linking every samples slider in every scanline render node to that NoOp. This quickly got messy with expression lines everywhere and I still had to remember to change the value in the NoOp when I was ready to render. Furthermore, this method assumed that all scanline renders would use the same sample count. If I wanted to have a scanline with a different sample count, I'd have to create a new NoOp, link all the values and remember to change that node too at render time. The project lead saw me struggling with this pile of jank and offered up a much simple solution, the $gui expression.
the good stuff.
This simple TCL expression checks to see if Nuke's GUI is active and returns a boolean value, True if the GUI is active and False if the GUI is not active. When working on the box, the GUI is running and returns True, but when the script goes out to the farm, the GUI is no longer active with a farm license and will return False. This provides an avenue to be able to tell Nuke how to proceed if a shot is being viewed on the box or the farm. We can use an expression in a switch node to swap inputs between a scanline render with low samples and a scanline render with high samples. In the image below you can see the setup I was using for many of the shots on this project. The switch node has the expression '$gui' in the 'which' knob. The switch pipe will be set to 1 when working on my machine because the GUI is active and will return True. This will enable the low sample, faster to preview scanline render. When the shot goes off to the farm, the GUI will no longer be active and the expression will return False and the switch will be set to 0 which enables the high sample scanline render.
This solution is faster to preview and easy to read if another artist picks up the shot. The script automatically swaps inputs at render-time so we don't have to be bothered with increasing the sample count before the shot goes to the farm. Furthermore, this allows us to have unique sample counts for each scanline render node if the shot requires. This TCL snippet is not restricted to just the scanline render node, it can be used in any scenario where the user wants to change values in a node at render-time. I find myself using this method often with any node that contains a 'samples' or similar knob; motion blur, transforms, defocus, vector blur, god rays in addition to the scanline render to name a handful.
Let's get a tiny bit more technical here. We can apply further boolean logic with TCL to swap samples in a node without the need for the switch node. In the expression editor for a knob a TCL 'if' statement will work just fine in setting knob values that check to see if Nuke's GUI is enabled. The syntax would be as such:
Again, with TCL, you can invert the '$gui' expression to get the opposite value using '!$gui'. I find that adding the expression inside the node, as shown above, is a less user intuative solution. If another artist picks up the shot, they may not be able to tell that there is an expression inside the node which could lead to problems when troubleshooting a shot. Nuke scripts are a lot like handwriting, each person has their own unique style but overall your handwriting should be readable to everyone else! Using the switch is a user intuative method with a clear visual language that displays what you've done in your comp to make it work.
I hope this brief write up is helpful. Happy comping!
One of my favorite aspects of nuke is how easily customizable the interface and user experience is. Having only a minuscule amount of programming knowledge in Python can allow you to tailor nuke in fluid way that fits your personal compositing style. The ability to assign custom hotkeys for specific nodes or operations, adding custom menus for tools, and altering the default properties of nodes have helped save me time as well as keep my node graph more readable. The key ingredient to flavoring Nuke to your heart’s content is editing the menu.py file found in your .nuke folder. Foundry’s online learning database for python is an excellent resource to turn towards if you’re unfamiliar with what the menu.py and the .nuke folder and are looking for a way to get the ball rolling.
menu.py and init.py files
Customizing the UI with menu.py
Recently, I registered for Ben McEwan’s Python for Nuke 101 course and quickly learned some simple snippets of python code that have helped me speed up my compositing workflow. I’d highly recommend this course for anyone who’s new to python and integrating it within nuke. The second lesson from the course was focused on adding shortcuts, menus, and default parameters to nodes for nuke and I’d like to share with you some of my new additions to my menu.py after completing this module. These are primarily shortcuts that I’ve thought up recently and they’ve already made an impact in my compositing workflow. You’ll notice that many of the hotkey changes save only a few keystrokes, but in my experience being able to get the information I need in a shorter time, greatly improves my mental flow when compositing. Saving 2 or 3 clicks here and there may not sound like much but the few seconds it takes to open a menu and find the option or value that you’re looking for can add up through the workweek. The more time you save now, the more time you’ll have for getting started on that next shot, learning something new, or drinking beers at the end of the day.
I first learned of the IBK stacked technique from the Compositing Mentor blog at compositingmentor.com. I’m not going to go into meticulous detail on how this works under hood so check out the Compositing Mentor’s blog for more information. In short, stacking IBKColour nodes will likely lead you to a better result than just using a single IBKColour node. This method works by first creating a “main IBKColour” in which the user sets the screen size to a low value (1) and fiddles with the darks, lights, and erode until the subject is covered with black. Then, the user duplicates the main IBKColour, sets the erode to 0 and patch black to 1. The user continues to duplicate the main IBKColour and setting an erode value of 0 and patch black that increases exponentially with each copy (1, 2, 4, 8 etc.)
I was working on a commercial spot that involved heavy amounts of keying with multiple keying setups and found that the process of copy/pasting the IBKColour nodes and adjusting their values was prone to human error and was super time inefficient. So, I challenged myself to create a python script that would automate the stacking process and speed up my work when keying using IBK.
The video below shows how increasing the stack size creates new IBKColour nodes with exponentially increasing patch black values while also keeping the values of other knobs the same. In this example, there are 5 nodes in the stack (IBK01 through 05) with IBK00 being the “main IBKColour”.
The next video shows how the IBKStacker_IS tool creates the same outcome as the large stack of IBKColour nodes. Overall, using this tool can save a few seconds of time when keying but those few extra seconds can add up when you have lots of keying to do or when experimenting with different methods or values.
Add these lines of code to your menu.py file, located in your .nuke folder.