Nuke - Read/Write Nodes with different frame ranges

Deadline
1

Hi,
Found an issue which I think will need a modifciation to the deadline submission code.
See attached *.nk nuke script file which contains 2 read nodes and 2 write nodes.

Different_Read_Node_Frame_Ranges.zip (941 Bytes)
Simply, we need Deadline to handle the situation where the 2 read nodes have different frame ranges and hence the 2 write nodes need to have corresponding frame ranges when they are submitted to Deadline. At present, the submission, takes the overall, root (project) settings as the frame ranges for ALL write nodes, which is incorrect in this situation.
Any ideas?
Thanks,
Mike

PS - Nuke nk files are banned from attachements!

2

Hi Mike,

It appears that we would need to grab the frame range from the read node, as opposed to the write node. But what about the case where there are more than one Read nodes up the path (assuming this is possible)? Also, I may be wrong here, but it doesn’t seem like Nuke itself supports the ability to do this. If I select Render -> Render All or Render -> Render Selected, I can only give Nuke one frame range, and that’s what it renders, regardless of what the Read node inputs are.

Cheers,

  • Ryan
3

The only way to fix this would be to roll a custom node for deadline to check like a “DeadlineSettings” noOp node.

Add a few custom settings like priority and frame range. Then have deadline check for a parent NoOp with the deadline GUID tucked away in a hidden integer value.

So for instance you would have two trunks:

Read_01 && Read_02 -> Merge_01 -> Deadline_01 -> Write_01

Read_03 && Constant_01 -> Merge_02 -> Deadline_02 -> Write_02

NoOp { name Deadline_01 selected true xpos 90 ypos -57 addUserKnob {20 DeadlineWrite l Deadline} addUserKnob {1 FrameList l "Frame List:"} addUserKnob {1 DeadlineID l INVISIBLE +INVISIBLE} DeadlineID "DEADLINERENDERSETTINGS v4.1" }

4

Thanks Gavin.
In the end, we simply disabled all but 1 write node and then just carried out multiple submissions with 1 write node enabled at any 1 submission time.
The submission code would need customising to support this feature and I’m just curious as to how actually useful it would be for production use?
Our compositors like keeping everything in 1 nuke script for easy updating of multiple shots, but in bigger productions, you really should be using pre-comps more and of course, you would be working on just 1 shot at a time, but referencing general node trees for overall look/dev, generic node assemblies, etc (ie: precomps). Might be the case, that as its specific to us and our way of working on this particular project, I might just develop it in-house for future jobs.
Thanks for the info Gavin.
Mike