nuBridge 180Browse over 1,300 tools right inside of Nuke

Click here to subscribe

Working with Pipe Numbers

Written by Frank Rueter on .

There are a couple of things to keep in mind when creating groups (and subsequently gizmos), if you want to maintain full control over the way the input pipes behave and thus how the flow of data in the tool is handled:


Input name = pipe name.
To label the input pipes of a gizmo or group, simply change the respective Input node's name inside the group.pipenumbers_01

When using more than one input in your group, make sure to set up the group's internals in such a way that the first Input node (and thus the group node's right most pipe) is connected to the main tree upstream, the one that should prevail if the group node is disabled.
In this example I messed it up and used the first Input node inside my group to connect to the mask, and the second one to connect to the incoming image which is obviously my "main tree":
pipenumbers_02 

To correct this, I need to shuffle my internal Input nodes around and swap the inputs on my gizmo to make sure I keep things connected the right way (shift+x on the gizmo will do that in this case):
pipenumbers_03

 now fix the labels to make sense of it all again:
pipenumbers_04 

Now how do I know which input node is my "main" one without having to look at the pipe labels?!
Well, each Input node has a hidden knob called "number", which corresponds to the order in which their respective pipe is placed on the group node. To visualise this you can put in this little tcl snippet into the Input nodes' labels:
1

[value number]

pipenumbers_05 

The input with number 0 is the one that will be piped through if the group is disabled.

 

Knowing about this hidden "number" knob now also enables you to use it in expressions to disable certain parts in your group to avoid error messages if a given pipe is not connected. Here I'm disabling an internal Copy node if the parent group's input 1 is not connected:

1

![exists parent.input1]
pipenumbers_06

 

 here is an example for a relative tcl expression that just checks if a node's second input ("input1") has an external connection through it's corresponding pipe:
1

![ exists parent.input[value input1.number] ]

pipenumbers_07

You can assign new pipe numbers to Input nodes via python just like you would with any other knob, and you can also just copy/paste the group node into a text editor and change the Input nodes' number knobs there.
Just remember that each Input node must have a unique value in it's number knob or nuke will get confused.

Comments   

 
0 # Victor Perez 2011-06-20 05:45
Clear, smart and useful (as always you do). Thanks Frank
 
 
0 # David Schott 2012-08-07 03:55
Hi Frank,

Would this work on the mask input of a keymix node? I am trying to feed an internal mask input outside of my gizmo for the user to be able to input a matte into themselves but when I hook up the mask input (of the keymix), to a gizmo's 'input' node (to feed it outside) it errors out as it's expecting the matte.

Thanks,

Dave.
 
 
0 # Frank Rueter 2012-08-07 04:33
Hi Dave,
I'm not sure exactly what you mean, a Keymix should not error if the mask input is un-connected. But you can try to insert an AddChannels node and set it to add alpha (or whatever channel you want to use as the mask). This will only add an empty alpha channel if none exists upstream and not do anything if one is already present. So this should prevent any such errors.
 
 
0 # David Schott 2012-08-07 04:41
Thanks for the fast reply! I realised when I was throwing things together I was using an over node and the mask input to that which was erroring out. I actually tried this with a keymix and as you say it doesn't now error out.

Cheers!

Dave.
 
 
-1 # Adam Saini 2014-10-16 08:34
Hi all
I am on the wrong forum to ask below question, I am new to nuke, when I click on viewer panes, node pipes dissapeared can someone advice me.

thanks
Adam
 

You have no rights to post comments

We have 2424 guests and 125 members online