Dropping a Nuke on a pesky Python

Well, more like a little basic 101 on using Python in The Foundry's Nuke compositing package.  I wrote this example script as an initial introduction to learning simple python scripting in Nuke.  As well as the chance to dabble in Nuke, it gave me the opportunity to develop a useful tool for my own work...


Oh those whacky students and their crazy file management techniques

One thing I'm always running into with teaching is the number of times you try and enforce good file management habits with software, but the amount of times it appears to be a in-one-ear-out-the-other affair. Some students are great and put it into practice - but as most student work is on the one machine, the fact that files will load from the local hard drive means that there is little chance of errors, hence not much reason to really bother.

However, on the other hand, this is where it starts - and then stops.  Trying to take files from one machine and across to another is where all the sloppiness just falls apart.  Files are stored with absolute paths - and then there's the whole OSX and Windows path structures.

The reason for project folders, content directories and these good habits all starts to look like a good idea.  But it just doesn't seem to deter some people...


How about making MY life easier?

What I got back when marking a compositing project was a nuke file and a folder of images that were reported as errors because Nuke couldn't find the images.  The main issue was, to package up their projects for submission, they'd moved files (from folders, desktop, etc) into a single folder.  The Nuke project of course was already saved and using the old file paths.

One students who did follow the instructions still had a broken Nuke file - not of their own fault - but because (I'm no Nuke veteran, so I could be missing a feature here I didn't know of) the absolute file path was stored in the Nuke file.

Well, after manually editing one project to get it to load, I decided that with another 12-13 students to go through that this was probably a real-world example that would make for a good excuse to produce a python script in Nuke.  And hence the downloadable file below was born.  Like the scripts I've been posting here, I've heavily commented the code so its (hopefully) easy to swallow and provide some level of educational value to those unfamiliar with python/Nuke scripting.

DOWNLOAD Nuke_CorrectReadErrors_example.py

Running this in Nuke can be done via the script editor.  If you've never delved into Nuke's script editor before, you can add it as a Pane as shown in the screenshot below.

To test the functionality, create (or load) a simple nuke project.  To quickly 'break' the project, open your file explorer (in Windows, not Nuke in case you were wondering where to find this "file explorer" tool), make a folder called breakNuke and just move all of your images into this folder.  If you go back to Nuke, your Read nodes should appear broken as the files are no longer in the same location.  You can force them to check by opening their properties and clicking the reload button next to the missing frames option.

1. Load (or even copy-paste) the script into your script editor.  Select all of the script (Ctrl A will suffice) and then press CTRL Enter to run it.
2. If there were errors, a message box will tell you which Read nodes were having problems.  Click OK.
3. You will be asked to select the folder where the files are.  Just go to the folder you made (breakNuke) and click OK
4. The read nodes should be all good.  You'll see that they now load up the images again just fine.

Right now it just does a very basic job of telling the Read nodes to look in a folder for all images, which for my purposes was good enough. With a little more work, this could become a much more powerful tool - keeping sub-folder structures for instance and allowing a base folder to be set, rather then expecting all files to be inside a single folder.   But I'll leave that til later...  Enjoy!