Skip to main content

Vibe Coding a Nuke Assist Storage Optimizer

· 6 min read
Cameron Target
Cameron Target
Author

TLDR: This is about a storage clean-up tool and why your Gen-Z coordinators need to be using Nuke Assist.

Why Nuke Assist Actually Slaps​

Nuke Assist is a limited version of Nuke that comes packaged twice with each NukeX or Studio license. This extra version of the software is extremely useful in a large studio pipeline because it lets you break up work and licenses in a way that is efficient and cost effective. The limitations (no write nodes, limited comp nodes, gizmos etc...) are a feature and not a bug. You can use nuke --assist for paint, roto and tracking work, while breaking out final comp and render work for regular nuke. Similarly, certain coordinator tasks like ingesting, as well as some supervisor tasks like node tree hygiene checks, can also be done using nuke --assist. This article is going to focus on the coordinator's use-case and how Nuke Assist can help act as a connection layer between Autodesk ShotGrid and a filesystem. First, a little history.

How we got a ShotGrid/Nuke storage optimizer before GTA VI​

Back on Spike Lee's Highest 2 Lowest, Baked Studios outlined two priorities:

  1. Conserving disk space.
  2. Conserving Nuke licenses.

At the time, we were using Suite Studios and storage costs ballooned quickly. Cloud storage space had become a problem that needed solving. In addition, working on a big show meant we had expanded our license pool meaning software costs were rising quickly. However with more NukeX licenses, came more nuke --assist licenses packaged at no extra cost. We had been using Nuke Assist for ingest, so familiarity with the tool was assumed. The problem had a solution, build a script that coordinators could use to manage storage.

From a practical perspective, Assist made sense because if you're using ShotGrid Desktop, it's already bootstrapped to ShotGrid's engine for context (eg. sgtk.platform.current_engine()). Using Nuke Assist also meant I didn't have to deploy anything new, we could work with our shared library of python scripts made available through Cragl's smartScripter to artists and expand it more to coordinator usage.

screenshot

Screenshot of Cragl accesibility.

Broken down, we needed a script that:

  • Would run in Nuke Assist
  • Connect to the current SG context
  • Grab data about versions in SG
  • Find paths from SG published file path fields
  • Preview versions (EXR sequences) discovered and potential space saved
  • Move files to an archivable or deletable location

To do this, we were going to need a great interface, and a great AI developer. I use Zed so their Claude API Integration and native git support was the perfect candidate.

A detailed GUI is an easy W​

Nuke's whole GUI is built with Qt (Nuke is written in C++). PySide is a binding for Qt which lets you create the same kinds of windows, buttons, and panels, but controlled by Python. This means any PySide widgets you run in Assist, will be inside the same process and the same global QApplication that Nuke created. It makes the whole process easy and uniform. There's a great course on Rebelway I'm taking that covers this.

For my GUI, I wanted detailed information on what the script was actually doing, the rules being matched, as well as a preview screen for feedback from the script itself.

screenshot

Screenshot of interface in Nuke Assist.

In the above screenshot you can see the interface shows you the progress of the scan, the results, including versions kept vs ones that matched rules, and then gives you a summary of what will happen when you move the versions.

Nuke and SG have lowkey great APIs​

There's a reason people still use Nuke over Fusion or anything else. Nuke has a profoundly robust nodes and knobs python-first API that's been extensively battle-tested by many platforms, studios, and other DCCs. It uses one mental model: Nodes and Knobs. The same nodes you move around in your node graph are the same ones you script, and the parameters on a knob are the same as well.

ShotGrid's python API has all the extensiblity one might need for a platform as heavily used in production as SG. The documentation and forum sites will get you 90% if not all the way to where you want to go.

This script leveraged the following API integrations to plug itself into Nuke, SG, the OS and the filesystem. The full list of API functions is in the documentation.

Nuke API​

  • User messaging
  • (No nodes/knobs here; Nuke is mainly the host + message box.)

Qt / PySide (GUI)​

  • Core widgets & windowing
  • Text cursor (autoscroll) - for scrolling through large responses in the preview. (for like 100s of versions)
  • Dialog control

ShotGrid API (via Toolkit / sgtk)​

  • Toolkit bootstrap
  • Project context
  • Fetching Versions
  • Entity field access - to grab version statuses etc... (All SG interaction is read-only here.)

shutil (file moves)​

  • Moving folders

os / filesystem helpers​

  • Path inspection - checking to see if paths matched published file paths in SG.
  • Directory walking & sizing - I wanted to know how much space would be cleared in preview.

Why shutil.rmtree() is cringe and shutil.move() is based AF​

The first iteration of this script deleted the files found after the preview. There's a school of thought that really no one should be diving into the filesystem for information in VFX, and mostly things should be handled through loaders, publishers, various asset libraries etc. In fact many shops don't grant coordinators or artists permissions to access the filesystem at all. However, for this specific script, I thought about it and opted to move the files instead of getting rid of them entirely. For obvious reasons, deleting things can be risky, especially when you do it programatically. This new approach of using shutil.move() instead of shutil.rmtree() also changed the workflow a bit to allow a choice for where to move the files. An archive folder could be used and compressed, or you had the option to go back in and delete it all. This approach gives more choice.

screenshot

Dialog window for choosing move location.

Locking in for a sec: Things to Consider​

I come from production with a focus on pipeline, so keep in mind this project made use of an LLM in place of a developer - I heavily supervised, modified, and tested the script, the whole process was super valuable. When used appropriately, LLMs can be an accelerator for handy scripts like this, and for the learning I did along the way. Especially if you have an overarching understanding of the tools and APIs in use.

I wouldn't use this script in production if you have other options (we did not at Baked). But that's not to say it can't be a starting point for a senior TD or dev willing to refine the syntax.

🤖 Full Documentation can be found here on Github 💾