Introduction

This tutorial will lead you through configuring and using the nuke2backburner submission script.
It was initially developed by Sebastian Elsner at RiseFX. For the purpose of this tutorial i have slightly
modified the original script to ease configuration and setting of default values within the script.

Here is the changelog from the script documenting the things i have changed.

1
2
3
4
5
6
7
8
9
10
11

# Copyright (c) 2008 Rise|fx Gmbh, Schlesische Strasse 28 Aufgang B, 10997 Berlin
# Modified 2010 Thorsten Kaufmann, Mackevision Medien Design GmbH, Forststrasse 7, 70174 Stuttgart
#
# Changes:
# - Added default options on top for easier configuration/setting of defaults (used during __init__)
# - Added documentation for the defaults and options
# - Added "none" to the groups enum allowing for submission to all slaves without group assignment
# - Added MANAGER, NETMASK and PORT settings to allow for distinct manager configuration
# - Removed autodetection of cmdjob.exe (as it broke with x64 here). Instead set the PATH variable to include the cmdjob.exe location
# - Instead added function to detext if cmdjob is found within PATH and return if not
# - Added manager ip/hostname, port and netmask to the title for debugging

Now let's first take a look at backburner and why you might decide to choose it as your rendermanager.

Features and reasons to choose backburner:

• Comes bundled with Max and now also Maya
• Is not windows only anymore (yay)
• Free as in...well...free
• Rather solid for small to medium farms
• Commandline submission interface (via cmdjob.exe wich is also used in the nuke2backnurner script) allows submission of any kind of job, ranging from setting environment variables to deploying software installations

Limitations:

• Missing some advanced functionality that is available in commercial render managers (clustering, license usage tracking, database backends etc etc)
• Not scaling too well with heavy load (many hundred jobs, many users at once etc.)
• Not as customizable as commercial alternatives. Even tho quite some custom stuff can be done with some trickery 

Limitations of the script:

• There is no direct communication with backburner. So groups are hardcoded in the settings instead of beeing dynamically pulled for australia online pokies example
• There is no feedback or monitoring within nuke. Backburner comes with both a monitoring application and a monitoring webinterface tho.
• Some features that would be possible using cmdjob.exe are not  impletemented. Including but not limited to SuspendedSubmission,  Submission to specific servers, email notifications, archiving,  taskBlocking settings and various more. Shouldnt be to hard to add them tho if anyone needs them.
• The script assumes that the very same nuke version is installed to  the same path on all renderslaves (as it constructs the executable  path from the nuke instance the job is submitted from) and does no checks whatsoever. 

Instructions

Prerequisites:

• Local vanilla Nuke installation
• Local vanilla Backburner installation (should already be present if you have Max or Maya installed)
• Working Backburner installation (Backburner Manager running locally or on a dedicated manager machine) 
• Get the script from nukepedia

Installation:

• Add your Backburner directory to your path variable (controlpanel -> system -> advanced -> environment variables -> select variable named "PATH" -> click "edit" -> Add a semicolon to the end of the paths and paste the path to your cmdjob.exe)
• Copy the script to a networkpath part of your nuke plugins directories or locally to locally to "drive:\PROGRAMFILES\NUKEPATH\nukescripts\"
• Open your menu.py and add this line below the other import statements: "import  nuke2backburner"
• Insert this line wherever you want the command to appear in the menu: "m.addCommand("Submit to Backburner",  "nuke2backburner.nuke2backburner()", "^b")" (This also sets Ctrl+B to be the shortcut for the command. Remove or edit "^b" if you do not want that.
• If you have custom menu.py files or network centralized ones then you probably know what to do to add it to them
• Configure the script (see next section) 

Configuration:

There are several REQUIRED settings to be set/changed in the python script to make it work and a bunch of optional settings and defaults that can easily be set on the top of the script:

REQUIRED Settings:

TASKLISTPATH = "//storage/Tasklists/"  
# TASKLISTPATH is the place were tasklists are saved. It MUST be  accessible by  
# all computers taking part in rendering

RENDERGROUPS = "none render10 render20"  
# These are global groups created on the backburner manager (you can  create them  
# in the backburner monitor). You have to keep the first entry "none" as if it  
# is used then the job is submitted to all available renderslaves

MANAGER = "192.168.103.204"  
# Hostname or IP of the manager machine

NETMASK = "255.255.255.0"  
# Network mask of the manager machine. Unless you have a special  setup the default 
 # should work

PORT = "3234"  
# Port the manager is running on. Default with a standard Backburner  install is 3234

Optional Settings:

optPriority = "50 10 20 30 40 50 60 70 80 90 100"  
# Available Priorities in the priority dropdown

Optional Default settings:

You can change these according to your personal needs if you want to.    

defProxyMode = 0  
# Default 0 (Off)  
# Render in proxymode. Set to 1 if you want it to be on by default    

defChunkSize = "5"  
# Default 5.  
# Amount of frames per task. Set to 1 if you want each frame to be a  single task    

defNFrame = "1"  
# Default 1.  
# Render every n-th frame.    

defDeleteAfter = 1  
# Default 1.  
# Delete Job after completion

Usage:

start_frame and end_frame:
Both are pulled from the current scripts' settings on launch and can be edited as needed  

n-frame:
Render only every n-th frame. Default can be changed in the  script  

proxy-mode:
if on render in proxy mode  render nodes: If you have write node(s) selected you can choose if  you want to render all write nodes or only selected ones  

chunk size:
determines how many frames will end up as a single task  in backburner. (Default can be set in the python script. Set to 1 if  each frame should be a task)  

priority:
priority of the job. The available priorities can be set  in the python script  

delete job after completion:
if on the job will autodelete itself  from the backburner manager after it is completed  

render group:
render only on a group of the renderslaves. These can  be configured in the python script. Mind you that the group must  exist as a global group on the manager for this to work. If set to the default of none the job will be  submitted to all renderslaves.

That's all folks. A BIG thank you goes to Sebastian for making the original script available to the public!