Aug 30, 2010

Deadline - nuke post job script

We wanted to have an automatic process with deadline, to convert all the 3d renders to exrs with proper compression and autocrop (datawindow) option enabled. Currently I implemented this on linux, and I had to make a little hack to run nuke from shell. I think it's much easier on windows (no permission problems etc.) Usage:
So the main file is a pythonfile, a deadline post job script, the path of this has to be placed in deadline monitor, in the job properties panel. The machine that rendered the last task will "render" this extra task. The file gets data from deadline, like output path, frame range etc. Then it's executing a nuke render, from command line, but the renderable file is not a nuke script, but another python file. It could be a nuke scene, with a read and write node, but I think it's nicer to generate the nodes on the fly, and this way no problem with script paths etc.
So we have 2 python files at this point: a "JobNuke2exr.py" which should be placed in deadline, and "glt_deadlinepostjob.py" which should be reachable by nuke and deadline (that's why I inserted a line with sys.path.append in the first python file, it should be edited). To make it more complex, I had to make an .sh file, (like a .bat on windows) that launches nuke from terminal, with arguments, because the specific deadline command (SpawnProcess) couldn't make this. Of course this .sh file needs also be edited, because it contains the path to nuke executable.
So the first .py calls this .sh, that fires nuke, that renders the other .py! Easy, no? :)
A little thing with the process that has to be solved: currently nuke rendering checkerboards, and not skipping missing frames.
Here you can download the files
I'm sure this whole postprocess can be achieved much easier, but at this point this is working here. Comments, tips are welcome.
Gabor

Aug 7, 2010

Multiple autosave in nuke

So we had a little dataloss yesterday, some of our nuke files went 0B in size. Checked the autosaves... none existing! What happened (other than file system corrruption or what)? We are working on linux, and the NUKE_TEMP_DIR environment variable was properly set in init.py. But, nuke was started as a simple user, and that dir can be written only by root. At least this is my idea. That's about it, but I started to think where and how to place autosaves properly. We now having them in /home/user/Nuke/autosaves folder. Another question is how to preserve the autosave files? Because nuke deletes them as soon as the scene is saved, but we need them to stay, for these occasional dataloss events.
I found a tip in the mailing list, to include the current date, time in the autosaved filename:

/autosaves/[date %y]-[date %m]-[date %d]_[date %H]-[date %M]_[file tail [value root.name]]
But this is too long, and can get infinite number of autosaves.

So another tip: include only the current minute, so it starts again in the next hour, maximum of 60 file (for 1 scenefile, if you save a new version there can be another 60!)
[file rootname [value root.name]]-[date %M].nk.autosave
it gives path like (when for example the current time in minute is 15):
w:/Projects/Test/AutosaveTest/AutosaveTest_v001-15.nk
But that is still to much files.

How can it be reduced? I could include a modulo (%) operator to limit the number of minutes, like %6 gives only 0-5. It's great, but think. When minute is 01, it writes in the fileneme 01. When 02, 02 and so on, and when 06, it starts from the beginning. It would be better to have 1 autosave filename in the first 5 minutes (continuously overwritten), then another in the next 5 minutes, and so on. So in half an hour you still would have the first file, and that gives a good chance to go back if something went wrong. This can be achieved, by an expression like this:

[file rootname [value root.name]]-[expr int ([expr [date %M]%30]/5)].nk.autosave

Let's look at this from closer! The first part (before the "-") is simply gives back the file path, but without extension, so we can put anything after this. The second part can be understood from inside the date part: [date %M] is the minute of current time (That's going 0-59). Outside there is an expr(ession) command for the modulo (%30) operation, that gives the remaining of current minute and 30, with this we modified the range to 0-29. Then comes "/5", notice the brackets, so range is 0-5.8. Then the "expr int" takes only the integer of this. The final range is 0-5 integer only. This is pasted after the filename.
Now this expression makes a "filename-0" file when current minute is between 0-4, then "filename-1" when minutes 5-9... and at 30 it starts from the beginning, overwriting the "filename-0". There can be maximum of 6 files, for 1 version. But remember if you save the script (ctrl-s) the last autosave will be deleted!
I hope this will be useful for someone. Modify as you need.