Nuke Project Manager with Python and QT

Introduction

Recently, I have picked up a decent amount of freelance compositing work. As a freelancer one of the difficulties is that you don’t have access to all of the production tools that a studio provides. I end up spending a lot of time opening, clicking through file explore, and manually creating and copying files and folders. Its not only annoying, but a waste of time, that interrupts productive work flow, and is error prone. I decided to use this issue as an opportunity to practice building pipeline tools, and add a project to my GitHub. The goal is to create a desktop application that will allow me to easily browse through files, and generate project directories and Nuke scripts.

Establishing Project Scope

First of all, I am going to refer to this project as Nuke File Manager (NFM) from now on, just to help with clarity and brevity.

As previously stated, there are three main functionalities NFM needs to have. First, NFM should have a file browser for existing shows/projects. By double clicking the user should be able open files in the proper application through NFM. Second, NFM should generate a directory structure for each project. That means all the folders for holding renders, pre-comps, scripts, and footage. Finally, NFM should generate Nuke scripts for each shot and place the files in the correct directory so that the shot browser can find and open them.

Framework

The technology framework for this project is Python and Qt5 with Pyside2 for the GUI. Qt5 is a C library for building GUI applications. While Pyside2 is a Python binding for Qt5 that allows one to access the C library using Python. An advantage of using Pyside2 and Qt5 is that we are able to work at a higher level with python and maintaining some of the efficiencies and speed of a C library. Also since, Nuke is also built on the Qt framework it is easy to imagine integrating this application in Nuke as plug-in. In fact a lot of 3D and graphic applications are built with C++ and Qt, which means I’ll be able to apply what I learn from this project to developing plug-ins and apps for other programs like Maya, and Houdini.

Script Browser

The Script Browser functions by asking the user to input a root directory folder, that holds every show/project, a show directory, that contains all the files for a given project, and a shot directory, that contains Nuke scripts. Initially, the user had to manually type the directory names into a text field, but that was really tedious. Eventually, I updated functionality so that only the root directory is a text field, and is saved to a JSON file and loaded when NFM launches. This means the user only has type in the root directory once and information is saved. The other fields for the show directory and shot directory are in drop down menus that are automatically generated from a list of subfolders. Once a root, show, and shot directory are selected a list of all nuke scripts within a shot folder is generated. The user is then able to browse through this list and double a script to open in Nuke.

Whenever an input field is changed by the user, all the down stream fields are cleared. That means that if the user selects a different show that the shot field and the Script Browser are cleared. Additionally, the use of Qt data structures to store list of subfolders and scripts means that the data will stay synced and updated when updated by NFM.

Finally, I also added a button to launch Nuke incase the user wants to open Nuke through NFM with out having to select a script.

Shot Builder

While simply being able to browser for a script is useful, being able to generate new files for project without having to manually copy or create them is equally important. That’s where the Shot Builder and Show Builder functionality come in. Shot Builder allow the user to create a new show by selecting a show from the root directory and entering a shot name. When a new shot is created a folder with the shot name is placed in the “Scripts” folder and a template Nuke script name “shotCode_v001.nk” is placed in the folder. The user can then return to the Script Browser to open the shot.

Shot names should be structured ‘showcode_scenecode_shotcode_version.nk‘. At this point there no way to check that the user correctly names the shot. Ideally, the shot name would be automatically generated from a database. For instance, the user would select from a list of shots assigned to him and then all the shot info would be filled in by NFM.

Show Builder

Extending the concept of Shot Builder, Show Builder similarly creates all the folders for a show/project. When a new show is created the directory structure for footage, reference, scripts, renders, working files, and assets is created and placed in the root directory. All of these folders are empty. Below you can see the directory structure for a show.

There is no way for the user choose their own preferred folder structure. Possibly in the future there could be a setting that allows this. Once again, NFM does not enforce any naming conventions for shows.

Once a show is created shots can be added to is using Shot Builder.

Conclusion and Possible Future Expansion

The Nuke File Manager at this point has basic functionality, but there is still a lot possible additional improvements that could be made. For instance, the application could allow the user to browse for footage or assets and import the files into Nuke. Another additional feature could be automatically adding plate footage to the template script when a shot is created. Also, I would like to add that ideally NFM would be integrated within Nuke so the user didn’t have to leave the app. Unfortunately, I only have a license for Nuke Indie which only allows 5 lines of Python to run at once, and full license is outside of my budget at something like $2,500.

I would also like to touch on some learning out comes I had on this project. Mainly, this project was an introduction to GUI applications for me. One of the most important ideas I learned is how GUI applications tend to be structured in model-view architecture. That the parts of the code that enable functionality should be kept separated from the parts that run the interface. For instance, if one is building a calculator the method that adds two values should be separate from the method listens for user input. This makes a lot sense and mimics the way web applications work. Where you have html/css running the frontend of website and Java or Python running the backend, and the frontend is calling methods from the backend when user gives input.

In final conclusion, this project could really be worked on for while with a lot of added functionality. However, at the end of the day building NFM is a learning project for me. I feel like I got a lot out of building it, so I am ready to put it up and move on to continue learning. Who knows maybe one day I will pick it back up. If you want to see the code or even contribute feel free to check out the project on my GitHub here: https://github.com/zackthomas1/NukeFileManager