- over 1,000 free tools for The Foundry's Nuke
Render Manager - Alfred
INTRO
You’ll find in this article the general method we have been using at Mikros Image to tie Alfred (1) with Nuke (2).
ALFRED
Let’s start by the end.... To work, eg launch Nuke render jobs, Alfred needs to deal with some particular TCL script (alfredscript) describing a subset of commands with reserved and specific keywords. This script is ran by Alfred and the different commands are sent to different render boxes.
We are using python commands in the alfredscript. These python commands are actually a path to python scripts. Each of these python scripts are describing how to do the job ( plenty of args, see below) and the type of job ( Nuke or Maya (3) render jobs by example).
Alfredscrpt look like this :
You’ll find in this article the general method we have been using at Mikros Image to tie Alfred (1) with Nuke (2).
ALFRED
Let’s start by the end.... To work, eg launch Nuke render jobs, Alfred needs to deal with some particular TCL script (alfredscript) describing a subset of commands with reserved and specific keywords. This script is ran by Alfred and the different commands are sent to different render boxes.
We are using python commands in the alfredscript. These python commands are actually a path to python scripts. Each of these python scripts are describing how to do the job ( plenty of args, see below) and the type of job ( Nuke or Maya (3) render jobs by example).
Alfredscrpt look like this :
1 2 3 4 5 |
Job -title {'jobTitle'} -crews {render_crew} -sqlset {user='toto',jobgroup='Prod_Name',filename='outPath/outFile.@@@@.ext : pyPath/taskName.Job.py',prod='prodName',comment='',nbframes='201',resolution='1920x1080'} } Task {taskName} -sqlset {mitid='0',miftid='0',micmt='',mioutfile='outPath/outFile.@@@@.ext'} -subtasks {Task {taskName frames 0 to 19 by 1} -sqlset {mitid='3',miftid='0',micmt='',mioutfile='outPath/outFile.@@@@.ext : pyPath/0.0-taskName.RenderNuke.py'} -subtasks { Task {taskName frames 20 to 39 by 1} -sqlset {mitid='4',miftid='0',micmt='',mioutfile='outPath/outFile.@@@@.ext : pyPath/0.1-taskName.RenderNuke.py'} Instance {taskName} -sqlset {mitid='2',miftid='13',micmt='',mioutfile='scriptPath/taskName.nk'} |
....... And so on until all the job is covered / described.
BUILDING ALFREDSCRIPT
We’re using an in-house app, Mikser (4), to generate alfredscript files. But even without Mikser, it’s possible to handle it with TCL or python, or whatever language that deals with text and http requests. And it’s possible to do it directly from Nuke, if you write the right stuff of course.
Mikser has a graphic user interface to help computer graphic artists to build graphs and trees for rendering tasks, from really simple ( only one Nuke script to render) to more complex ( multiple rendering tasks tied to some Nuke script to be started only once all previous renders are done).
The main informations settled by users are the Nuke script to render, the write node to execute, the outputpath, the frame range, the Nuke version, the number of frames to be rendered on each box ( the block size)..... We then have a function ( java coded, executed inside Mikser) that takes this graph and converts it in a bunch of (ordered) python files. The whole job / graph is divided into single / simple tasks.
All of this can be taken from the current opened Nuke script, and the selected Write nodes(s). That could be briefly described like this : check out all or selected write node(s), order them using the render_order knob if needed, check Nuke version, ask the frame range.... etc, and build a bunch of py / tcl / bat / sh... (or whatever suits your pipeline and OS ) files to describe properly the job, and according to your internal needs. Store their name and path, and write out an alfredscript using this kind of pattern. The last step is to send it to Alfred via http request.
COMMANDS EXECUTED
What follows is strongly linked to our ‘modus operandi’, that is Mikros Image pipeline and inhouse apps. This is detailed only as an example, not as the 11th commandment ; )
Well, back in here, with our bunch of python file... All of them are built by using a template (a python file we called RenderNuke.py), Mikser kind of “fills the blanks” with parameters the user has defined. These python files describe how to render each block ( a pack of X frames), it contains all information and actions needed and the command line to launch the Nuke render itself. The informations are the same as mentionned before.
The main actions being done when the python command is executed are :
- making a copy of the script in a local render box temp directory
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
## Looking for a temp directory... import platform if platform.system() == 'Linux': tempDir = "/tmp" else: tempDir = "T:/Temp" if (not os.path.exists(tempDir)): mikser.PrintError("The temp directory \"" + tempDir + "\" does not exist !") sys.exit(1) srcNukeFile = open(inFiles[0], 'r') ## Creating nuke tmp out file in tempDir import datetime date = datetime.datetime.now() dateStr = date.strftime("%d%m%Y_%H_%M_%S") localNukeScene = os.path.join(tempDir, os.path.basename(srcNukeFile.name) + "_" + dateStr + ".nk") dstNukeFile = open(localNukeScene, 'w') ## Copying nuke file in tempFile contentStr = srcNukeFile.read() srcNukeFile.close() dstNukeFile.write(contentStr) |
- modifying the write node according the out path, name, padding and extension, defined by user
( as in our case this might be done outside Nuke)
1 2 3 4 5 |
#### outImage is a var previously defined = full_path/name.####.ext dstNukeFile.write("\n#### ADDED BY RENDER TASK : " + dateStr + " ###\n") dstNukeFile.write("\n## WRITES NODES ###\n") dstNukeFile.write("\nknob " + writeNode + ".file \"" + outImages + "\"") dstNukeFile.write("\n") |
- launching the render, using the command line (built with the informations described before)
- when all went fine, removing local file
1 2 |
## deleting local scene to keep rooms tidy : os.remove(localNukeScene) |
SENDING TO ALFRED
The alfredscript is sent to Alfred via http request, in our case this is done once the alfredscript, and some other files, are generated. When Alfred receives it, the render process starts and all the python commands will be executed in the order they appear in the script. The order is really important in complex graphs, as some process must be done first ( intermediate renders, vectors render...or 3D renders).
We then use the Alfred webservice to follow the whole job progression. These info are put back into Mikser to provide user a friendly UI. It also lets us add lots of custom vars and info. The basic Alfred is only web pages. Efficient, but not really friendly...
CONCLUSION
Next time I will tell you how Mikros Image is improving jobs queing with new job dispatcher (code name Puli) developed with HD3D consortium.
--------------------------------------------------------------
(1) Alfred™ is Pixar Animation Studios’s solution for jobs distribution, developed by Pixar for RenderMan™ rendering tasks management.
(2) Nuke™ compositing software is a trademark of The Foundry Visionmongers Ltd.
(3) Maya® is Autodesk® 3D animation software.
(4) Mikser is Mikros Image built-in application to define and manage CG dataflow and rendering jobs.
--------------------------------------------------------------
(1) Alfred™ is Pixar Animation Studios’s solution for jobs distribution, developed by Pixar for RenderMan™ rendering tasks management.
(2) Nuke™ compositing software is a trademark of The Foundry Visionmongers Ltd.
(3) Maya® is Autodesk® 3D animation software.
(4) Mikser is Mikros Image built-in application to define and manage CG dataflow and rendering jobs.
--------------------------------------------------------------