This week, I dug into Nuke’s autolabel process, and now I have it providing useful labels on Shuffle2 nodes. That’s the new Shuffle, the one where we connect lines between in and out to make connection. The autolabel can help us understand simple shuffles like this one without even opening the control panel:

For complicated shuffles, we don’t even try to bake them down into an instantly-understandable label, but we do give an indication of what kind of complication is present, so we know to open the control panel and see… whatever craziness is going on in here:

Seriously, please don’t comp like this.

In the process of making this autolabel, I was reminded of a few things that make them more complicated in Nuke than we would expect. Here’s a list of the gotchas.

We are responsible for all of the node’s labelling.

Nuke uses the autolabel process to make all of the text and icons on a node. Placing an autolabel on a node completely replaces Nuke’s default one. That means we are now responsible for putting the name on the node, and adding any label text the user has written.

Node icons come from autolabel, too.

Node icons are those little graphics we’ve all seen so often that we don’t even think about them anymore. They’re the channel indicator rectangles in the lower-left corner and the C or E in a circle that alerts us to cloned nodes or expression-driven knobs.

Use Nuke’s default autolabel as a reference.

Nuke creates the default node autolabel for every node from a single Python script. It’s called autolabel.py and it lives inside the plugins folder in our Nuke install folder. Do not edit this file! But do refer to it when making a custom autolabel. Our code will need to replicate the functionality of this script.

It is relatively straightforward to handle the Node name and any label text ourselves. But if we need a reminder, find this part of autolabel.py by searching for: “# do stuff that works even if autolabel is turned off:“. Then, go down to “# build the autolabel:” to see how to assemble the autolabel.

One part that is both important and easy to overlook is the node icons. To see how Foundry is handling them, search for “# do the icons:“. Instead of trying to replicate this myself, I copied this whole section into my code.

Foundry’s documentation on autolabel.py is meh.

Here it is. See? I told you so.

This post on the Community site is a good kick-start: https://community.foundry.com/discuss/topic/144994/autolabel-knob-and-indicators-labels-and-all-that-jazz

With a bit of searching, you’ll also find some other writers’ blog posts about it as well.

Good luck.

I believe customizing Nuke to work the way you want to work is a comping superpower. Having less to hold in our heads while working helps us make better, more situationally appropriate decisions. But with great power comes great responsibility. Make it easy to disable your code if you discover it’s creating a problem you didn’t anticipate. And go crush some comps.

Thanks go to Eva Mateo, indoorjetpacks, Kyle Rottman, and Erwan Leroy on the VFXTalk Discord for being my copilots on this project. If you’re into VFX — whether as a pro, a student, a teacher, or an aficionado — come join us on the server!

This is an article about knowing, rather than hoping, we’ve nailed a track with Foundry’s Nuke. The approaches we’ll discuss are not software-specific, but our examples definitely will be. Feel free to apply these ideas to your compositing software of choice.

A Case Study

I had an experience during dailies for The Great Gatsby that changed my approach to tracking forever. The shot of that beautiful, yellow car careening around a corner came up for review. The artist on it – I remember it being Ben McEwan, but could be mistaken – had replaced the heads on the stunt driver and passenger with Gatsby and Nick. With the big, dynamic car motion, it was hard to tell if the faces were really stuck on. I would have relied on my comp supe to say if it was good enough. But Ben had added two little squares in the bottom corner of the frame containing stabilized views of each person’s head. Without the overall motion, it was really easy to see if his patches were truly stuck on to the plate. 

My approach at the time relied on someone else to find my faults. Ben provided tools for verifying that he’d gotten it right. It’s the difference between hoping we’ve nailed it and knowing we have. I learned my lesson (thanks Ben!) and haven’t assumed a track was stuck on since.

Checking Tracks

Maybe the Tracker is showing green lights and the patch looks stuck on as the feature we’re tracking thrashes all over the screen. Watching the overlay as it follows our tracked feature is better than nothing, but still suffers from a weakness in human perception: we don’t distinguish small slips on things that are making big movements in our visual field. 

So how can we know our track is really stuck on? We stop it from making big movements in our visual field. Inverting our track yields a stabilize. Apply that to the plate. 

Now… is that feature really nailed down… or is it wobbling a little bit?

This is the time for a gut-check. We’re about to build a lot of work on top of that track. It’s much easier to be sure we nailed it now, before we use it to drive a bunch of things. The last thing we want is to have our supe call out that it’s slipping when we’re up against the delivery deadline and have to remember to fix it in every place we use the track. So let’s be sure it’s locked down now.

To increase the power of our slip-detection, lay a reference grid over the stabilized footage. Then crop it down to only the feature we’re tracking so it caches quickly in Nuke’s Viewer. Use the expression-linked stabilize so our tweaks to the track appear instantly.

Fixing Failed Tracks

If our track fails the stabilize test, don’t stress, but also don’t quit. We have options. Try one (or all) of the following.

Try Again with a Different Approach on the Same Feature

Nuke’s Tracker has a lot of options for how to find a feature over multiple frames. Try re-running the track with different settings. A common one is to change the warp type to better match the kind of transformation that’s happening to our feature in the plate. (Affine is a good option for features that are changing their perspective.) We could also try setting initial keyframes, have the Tracker adjust for luminance changes, use a higher track tolerance, or grab a reference frame more frequently.

Break It into Two (Or More) Tracks

For shots that have a definite change in light or motion which is causing track trouble across the transition, we could try using a separate tracker for each part.

Post-track Tweak

If the track is stable, but doesn’t lock down the feature we need it to, we can add a manual tweak downstream to get it running where we need it. This is often a matter of putting a Transform downstream and setting keyframes at the beginning and end of the shot (and maybe one somewhere in the middle if necessary.) 

Track Something Else

Maybe we’re having trouble tracking the feature we want. If there’s a feature that’s easier to track nearby, something that moves like our preferred feature, we can track it and use the same post-track tweak approach to adapt it to what we need.

Manual Tracking

Avoid manual tracking  if at all possible. It is slow and painstaking, but sometimes only a person can make sense of the chaotic motion of a feature. We’ll do this only as a last resort, after every other approach has failed. A careful review through the stabilize after each pass through the track shows us what to tweak on the next pass.

Using the Track

Now that we have our track nailed down nice and tight, there’s something we need to discuss before we use that track data. I know I’ve been harping on making sure the track is perfect before we use it. But this is the part where we consider that maybe we’ve made a mistake in the track (perish the thought) and look at ways to protect ourselves from further damage.

There are two ways to use the track we just made. We can expression link the track data, or we can bake it out as keyframed curves.

The expression link has the advantage of updating as soon as we make a change to the track. This is convenient if we do find an error in the track and need to fix it. But it’s really not good if we’ve based some roto or paint on the track data. Updating the track moves our splines or strokes from the places we put them, introducing errors where previously there were none.

Some folks prefer using baked keyframes just because they don’t like to have green lines stretched across their node graph. That’s fair, too. (Although we can easily hide them by typing alt-e.)

Consider these possibilities when using the track. Expression links are generally safe for simple things like backgrounds or static patches, but baked keyframes are much safer when we’ll be building a lot of work on top of the track.

Supporting Tools

Earlier we discussed track solutions that will end up as multiple nodes. This can work perfectly fine as long as the nodes stay together. Remember that transform node concatenation in Nuke only works if all the transforms use the same filter mode. Motion blur will be determined by the last node in the line. 

For folk who really hate the way this looks or have a situation where that can only accept a single set of transform values (such as iTransform), have a look at Nuke Matrix Toolset by Erwan Leroy and Mathieu Goulet-Aubin. It contains a tool for baking multiple transforms down into a single node. It’s very user friendly. It also provides an easy way to make Roto nodes that are set up for track-assisted roto. There’s so much more in the toolset, but these are the things I reach for every single day.

Go Forth and Nail Tracks

Now that we’ve learned how to check tracks and several ways to fix them when they’ve gone wrong, we’ve immunized ourselves from bad, track-related surprises during dailies and tech-checks. We’ve also started down the road to being a trusted member of the comp crew. (Rule 3) Don’t be surprised when your supe notices your increased reliability and starts handing you harder shots. Don’t worry, these techniques work on hard shots, too!

“I’ll remember this when I come back to it later.”

This is one of the easiest lies to tell ourselves when we’re compositing. Here are a few techniques for turning that lie into the truth when you (or whoever touches this shot next, see Rule 4) come back to your script.

The reality is, even if we do continue the work hours, days, or even weeks later, we won’t remember the details of what we were doing. If we haven’t left ourselves any notes, we’ll have to spend time figuring out what all this stuff is and what it’s for all over again. That’s time wasted.

Or maybe we do still remember the details. But holding them in memory was not the best use of our brain power during that period. In Getting Things Done, David Allen describes the mental effort of keeping our to-do list in our head and how carrying that list leaves us less capacity for addressing the problems at hand. That’s brainpower wasted.

Writing things down in a place where we’ll see them again is Allen’s key tool for unlocking productivity. We can’t bring our full attention to bear on our current problem until we get that list off our mind. But we won’t be able to get that list off our mind unless we know it’s in a place where we’ll see it again when we need to. Luckily, Nuke comes with some built-in labeling tools that are perfect for writing down that information in exactly the place we’ll need it later.

Node Name

Node names are editable. There’s even a keyboard shortcut for it. Select the node, hit n,and type. It only takes a few seconds to turn Roto11 into Roto_redDress, making it so much easier to remember the next time we see it.

Nuke will even let us remove the node’s class from the name, but be careful. We get very used to having it there. It’s frustrating to have to open the properties panel to tell whether that orange node is a Blur or a Defocus.

Node Labels

Every Nuke node has a Label knob with a text box where we can type anything we want. This is the perfect place for a quick comment about the purpose this node serves in the comp, about where it came from, or any other piece of data that may be useful later. 

Labeled Dots

Dots stick the label text out the side to increase readability. Labeled Dots are really useful for labeling the output point of a section of our script, such as an assembled AOV build, or the group of nodes that create our background.

We can even make the label text really big, so it’s still readable even while we’re viewing the entire graph. (Extra points for stepping down the label sizes as you move into smaller and smaller subsections of your graph. These will get hidden and revealed automatically, maintaining readability as you zoom the Node Graph in or out.)

Sticky Notes

A big, yellow StickyNote makes an eye-catching reminder of something that’s unfinished or will need refinement before final delivery.

They’re also a great place to hold a to-do list. Place it close to the main Write node and give it three sections: “done,” “to-do,” and “questions.” When notes come up in reviews, make them new entries in “to-do.” As you address each note, move it to “done.” Having that to-do list written down frees us up to focus on one task at a time.

As we work, there will be things that we see that will need to be addressed for final, but will need to wait for later because the shot isn’t yet at that level of scrutiny. Add a to-do item so you don’t lose track of it.

Similarly, issues may pop up that need a lead’s or supervisor’s input. Add them to “questions” so whoever’s reviewing can respond.

All this note-taking seems like a lot of work at first. But the magic of keeping these running lists is that when it’s time to publish and send for review, we can copy this whole thing and paste it into the submission comments. Now anyone who views our work knows exactly what we did since the last version, has a list of the problems that we know need to be solved in later versions, and can clear up any questions we asked. This tells them way more than a cryptic “improved integration” note ever would. Clear and open communication builds trust (Rule 3) and makes your working life easier.

Pro tip: Start the text with <alignl> to get nice, left-justified lists instead of centered ones.

Backdrops

The Backdrop is the least useful node for organizing and labeling, even though it was designed for, and is commonly used for those purposes. 

Why? 

It is harder to select a Backdrop than the nodes it contains, especially as it gets bigger.

Backdrops do not expand automatically as the portion of the node graph that they contain grows. Ever tried to grab the bottom-right corner of a big Backdrop when zoomed out in the Node Graph? Such a pain. So fiddly and slow. And no setup ever got smaller as it got closer to final. Everything grows,all the time.

Finally, the default behavior adds bright, random color to your node graph, making it more difficult to see subtle color differences in your Viewer. 

Okay, so what should we do instead?

Arrange each chunk of nodes so it can be easily selected in a single swipe, without also selecting unwanted nodes. This replicates the organizing feature of the Backdrop while avoiding the selecting and resizing problems.

Then, use a Dot to label the chunk’s output. Make the text size appropriate to the size of the chunk. Large labels will still be visible when viewing the entire Node Graph, and smaller ones will become visible as we zoom into smaller sections of the graph.

Using these two techniques (as in the script in Labeled Dots, above) gives us a script that’s more flexible and easier to refactor as the shot evolves. The easier rearranging our Node Graph is, the more likely we are to do it, giving us easier to read scripts with much less time spent tracing pipe paths and figuring out what feeds where.

Wrapup

Labeling things pays dividends when we come back to our scripts and can get right to work. It pays back double when our script gets handed off to someone else before we get back to it. That person will be able to find their way around just like we did thanks to our handy labels. They’ll think we’re pretty nice to work with.

And what about that day your supe has to hop into one of your scripts? (You know they’re the ones who fix any last-minute issues in our comps once we’ve rotated onto other shows, right?) That day is going to be a stressful one for them. If they find a conveniently-labeled, organized script, they’ll be able to get right to work and fix the issue. Easy-peasy. And they’ll also remember how nice your stuff was to work with the next time they’re requesting people for their crew. Being easy to work with puts you at the top of the list.

It’s been a long time coming. Originally scheduled for release in 2023, Jerry Seinfelds’s Unfrosted will come to screens on 3 May 2024. I can’t wait. I learned so many things working on this show. Our crew was experienced and collaborative — the best kind of crew — and I’m excited for our (invisible) work to be shared with the world.

One of the challenging parts of compositing is that there are always multiple ways to do anything. How do we know which way is best? Use these Comp Rules.

Rule 1: Keep it simple.

Nothing in VFX is ever simple. But that doesn’t mean your work should be complicated.

The minimum viable product is an idea from business development. Apply this idea to compositing. When starting a new comp, only build out as much of the comp as is necessary to get the feedback you need.

As you get that feedback and respond to it, keep simplicity in mind. Organize and label things clearly so that your comp is easy to understand (because Rule 4.) Keep building the minimum viable product in the context of that new feedback. Sometimes the process will lead to complication. Don’t stress. (Rule 6).

Rule 2: Faster is better.

Compositing is an iterative process. Each time you go through the review cycle (make a change, render, review, plan the next step, repeat), your work gets better. The faster you can get through the cycle, the faster you can get to final. Consider how your choices affect both render speed and interactivity in the GUI.

Picking up someone else’s work? See what you can do to make it run faster. If all else fails, precomp the parts you aren’t actively working on. Don’t wait for anything that you’re not adjusting.

Rule 3: Build trust.

This rule has nothing at all to do with compositing practice — it’s all about people skills. Having the trust of your immediate supervisor and teammates will make your job easier and help you final faster.

How can you build that trust? Be predictable. Communicate early and often.

You’ve been assigned some work, and probably a deadline to finish it. If you don’t have the time, materials, or anything else you need to finish the work by the deadline, that’s a problem.

Don’t ignore the problem. Sing out about it. Do it as early as possible. You may be reluctant to pass along bad news or be seen as a complainer. But you might be the only person in your team that is aware of the problem right now. If you stay quiet, other people will find out about the problem eventually. But by then it’ll be too late to fix it easily. Raising an issue early means you and your team have more options.

Problems arrive for so many different reasons. Maybe you misunderstood the brief. Maybe there’s a bottleneck somewhere upstream in the pipeline. Maybe the client changed their mind about what they want. Each one of these is only a problem until it’s acknowledged and solved. So speak out, get it solved, and get back to work.

Hiding problems destroys trust. Revealing them — especially if you can offer possible solutions when you do — builds it, and makes your work life better.

Rule 4: You won’t be the last person to work on it.

Don’t assume that nobody else is going to see the mess you are currently making in your comp script. Picking up work from other compositors is a regular part of the VFX process. Chances are that you won’t be the last person to touch the comp you’re doing now, even if you do take it to final. Did you know that your comp supe will be the one who opens up your script to hit a last-minute client note that comes in after you and the rest of the compositors have rotated onto new shows? Your supe may not be in the most forgiving mindset while they wade into your mess, and might still have that in mind the next time you’re on their crew. It’s a sobering thought, no?

So make your work easy for someone else to pick up, whether it’s your supervisor, your crewmate, or even you if you have to go back to something after some time has passed. Work in single-purpose sections that have clear inputs and outputs. Label things. Leave notes about what’s done and what still needs attention. Clean up your messes. Do it because your script is a representation of you, and because you remember Rule 3.

Rule 5: Check your work.

Have you ever sat in dailies and watched a render-mangled version of your shot loop on the big screen? It’s not fun, is it? You missed an opportunity to get feedback on your work and wasted the time of everyone in the room. That happened because you didn’t check your work.

Check every render, every time. Difference your output against the plate and make sure there are only changes where there are supposed to be changes. Check your frame edges. Check your grain.

Checking your work doesn’t only apply to your comp’s output. How do you know the track you just made is good? Check it. Reversing a matchmove yields a stabilize. If the feature you just tracked jumps around in the stabilize, that track is no good. Redo it.

Picking up a new matte painting or an AOV build for your CG monster? Check the new work against the previous version to make sure that nothing changes that wasn’t supposed to change.

Build a reputation for finding and fixing errors before someone else points them out. Do it by checking your work.

Rule 6: Every rule has an exception.

No simple heuristic will always work in every situation. Production shots have a way of blooming in complexity. It’s not always easy to contain the chaos. Don’t worry. But also, don’t give up on the rules entirely. Stay focused on getting your shot to final. Keep going where the process leads.

Rule 7: Facilitate changes.

Change is inevitable. You are working to someone else’s specifications. Don’t fight it, flow with it.

Make your life easier by building structures that are easily modified. Make edits at source resolution when possible. Make sure each section of your comp has a single function and that it has clear inputs and outputs.

Responding to last-minute changes becomes much easier when you’re prepared for it. And being able to respond with, “Okay, will do.” instead of, “That will take three days.” helps your supervisor relax. (See Rule 3.)

That’s it.

What do you think of these rules? Have a bone to pick? Did I miss something? Please let me know! In the spirit of Sister Corita, “There should be new rules next week.” Stay tuned.