Hi,
i just discovered a potential bug in the ‘View Output’ menu of a Nuke job. Please see the attached screenshot to see what i’m talking about. The submenu offers to show the frame number 654 of the output although i right-clicked onto the chunk that rendered frames 550-559. I think this might be related to the issue “Nuke submitter issues” (http://forums.thinkboxsoftware.com/viewtopic.php?f=205&t=12485) i posted today. I’m thinking so because the job the screenshto has been taken from is the one i submitted with the fixed Nuke.py plugin in the repository which means the file path in the Write node has a) an expression in it and b) uses the %0Xd notation. All the other jobs from before the fix were using the ##### notation for the frame padding. In the latter cases the “View Output” option shows the frames as …######.jpg and not a specific frame number.
cheers,
Holger
I think the problem is that we need to evaluate the output path before we include it with the Deadline job. If we didn’t do this, then the TCL code would show up when trying to view the output path. We’ll see if we can do anything to prevent this problem from occurring.
Cheers,
Ryan
Yup, it’s because of the evaluation that we have to do. If we evaluate the output path, we get this (we had frame 972 currently selected):
# Result:
'Y://wmp/wav_001_050/comp/wmp_wav_001_050_comp_v001_an/1920x1080_jpg/wmp_wav_001_050_comp_v001_an.0000972.jpg'
If we just get the actual value, we get this:
# Result:
'Y://wmp/wav_001_050/comp/wmp_wav_001_050_comp_v001_an/1920x1080_jpg/wmp_wav_001_050_comp_v001_an.%0[value ZDefocus1.size]d.jpg'
To determine if a path has padding or not, we check the un-evaulated path for either %0#d, where ‘#’ is a numerical value, or for the actual ‘#’ character. Because of the TCL code, neither of these checks pass, so we don’t swap out the frame number with ####### when the output path is passed to Deadline. Now, we don’t want to just blindly swap out the last occurrence of numbers in a path with ####### in case the output path has no padding, and has a hardcoded number at the end (ie: a QT movie render might do this).
So unfortunately, I’m a little stuck on how to properly handle this situation in a general way. Do you know if it would be possible to just evaluate the TCL code of the path, without replacing the resulting %07d with the current frame number? If we can do that in Nuke, then we should be able to do that as a general solution to this problem.
Thanks!
Ryan
hi Ryan,
i think you can actually evaluate any TCL code in Nuke.
evalString = nuke.tcl("expr", "[value RenderNode1.fn_padding]")
print evalString
Is this what you meant?
Problem is that you need the Nuke python module for this. Or does this not matter as the evaluation would happen inside a Nuke session anyhow?
cheers,
Holger
The problem though is that the code is embedded in a path value. What we would need is a function that returns the path as this:
Y://wmp/wav_001_050/comp/wmp_wav_001_050_comp_v001_an/1920x1080_jpg/wmp_wav_001_050_comp_v001_an.%07d.jpg
Currently, the .evaluate() call on the ‘path’ knob returns the path above, but with the %07d swapped out for the actual frame number. It would be great to just get the path with only the TCL part evaluated…
hi Ryan,
below is a (probably not very advanced) way to do it inside of Nuke.
node = nuke.selectedNode()
file = node[‘file’].value()
s1 = file[:file.rfind("[")]
s2 = file[file.rfind("["):file.rfind("]")+1]
s3 = file[file.rfind("]")+1:]
evalString = s1 + nuke.tcl(“expr”, s2) + s3
print evalString
Y://wmp/wav_001_050/comp/wmp_wav_001_050_comp_v001_an/1920x1080_jpg/wmp_wav_001_050_comp_v001_an.%07d.jpg
This’ll only work of course if there’s no TCL expression in the file path string after the one for the frame padding.
So i’m not sure this is a very good solution. The issue in general is not the most important one to me but of course it would be nice to have.
cheers,
Holger
Thanks! That should actually work fine. We can do something like this in a “while” loop so that we’re able to evaluate multiple TCL expressions in the path.
I’ve uploaded a modified Nuke submitter that you can unzip to \your\repository\submission\Nuke\Main and overwrite the existing SubmitNukeToDeadline.py file. Restart Nuke to load the updated submitter, and then submit a new job and let us know if the padding is now handled properly.
Thanks!
Ryan
SubmitNukeToDeadline.zip (18.4 KB)
hi Ryan,
works like a charm, thanks a lot!
Proof: see screenshot 
cheers,
Holger
Thanks for confirming! We’ll include this fix in beta 5.
