There really isn't that much to the Node Graph as such. Its just a blank sheet onto much the Nodes are arranged. Perhaps more than any other aspect on Nuke, knowing the keystrokes makes a lot of difference to how easy it is to use.
Node tree layout
It is possible to lay the nodes out in Node Graph in many different ways. It consideration is not given to how it is done then your working life can be made very bothersome. If you work collaboratively then this can make the lives of other people bothersome as well. If your co-workers have a set of house rules then I propose that you learn them asap, unless you want co-workers pissing in your coffee.
In DT2010 you are free to make your own rules as long as they are consistent and rational. However, if your coffee starts to taste funny it might be time to review your procedure according to the following guidelines:
So what makes layout such a thorny issue? Well... take the snippet below: a Multiply node is being masked out by a Roto shape and they are arranged in a Y shaped manner.
This is identical to the merge pair below.
The problem is that, visually, these two very different sets (one a mask, the other a merge pair) look identical and this makes the script difficult to read. The only significant point of difference is the color of the node at which the two streams join (node types are color coded). But color is not as perceptually significant as shape, so it is in our interset to establish a shape-based node layout convention.
As the two feeds for the Merge node are naturally Y shaped, we can set aside that particular configuration only for use by Merge pairs. A better arrangement for a mask pair should be following the default read in from the right, as below:
However, if take this arrangement to its logical conclusion, we can end up with a layout that is a long diagonal, as below. This can be very difficult to read.
Better this simple approach: that the script be divided into 'scenic chunks': each one a discrete and significant component part of the composite. These should be placed inside of Backdrops, color-coded in whatever way seems right. This color coding might refer to the thematic content of the Backdrop ( blue for sky, green for tree etc) or whether it is CG or live action. Nuke has its own native color coding (red for 3D, blue for color correct etc) that you might wish to observe.
These backdroped chunks should be arranged in a vertical manner, layers included and topping this chunk would normally be a key Read node, such as a sky, figure, house etc. The chunks should be joined in whatever way seems to be right, bearing in mind that things near the top of the tree should normally be further away in compositing space.
Nuke has a couple of nodes devoted entirky to housekeeping.
- This is a plian sheet that one places behind a collection of nodes. It can be colored and can be 'written into'. As well as offering a visual home for these nodes it also enables them to be collectivly selected (just click and drag the bar at the top). Command click on it to select just the Backdrop without without the nodes (usefull for copying the BCkdrop to other groups). The only troublsome thing about this node is the fact that any text that is placd insude it is so darn difficult to format. Line breaks have to be added in manually or they will spill outside of the Backfdrop. this can be a PITA should one decide to change the size of the text midway (the default size is a tad small).
- A 'sticky style' note thingy. it floats above any backdrops in the script and will expand to acomadate any text placed iside of it.
- A dot is a point that one can place on the arrows that connect the nodes (in the old compositing app Shake, these arrows were called noodles). They can be used to right angle an arrow or to fork it. xxx image here. They can also be adapted to hold floting text. Paste this in a script: note that its xxx.
- Many nodes can be 'wrapped up' together in a group with the keystroke Command G. These nodes are then replaced by a single Group node the contents of which can be revealed by pressing the S icon on the top of the node's parameter window.
DT2010 suggested conventions
To sum up: I propose the following general style guidelines:
- Side masks feed in from right.
- Layer pairs either as Y shaped or A feed on left, B feed above (see Primacy of the B Feed).
- Avoid diagonal connecting arrows. These may be spilt by adding a dot (Command then select yellow dot).
- If the script has a lot of CG elements it will be wise to visually separate them in some way (color the nodes or feed them from another directions).
- Label, label, label.
All of Nuke's nodes are stored in the Tools panel. However, if the Tab kay is pressed whilst the user is within the Node Graph then the charming tab menu appears. As the user starts typing a list of Nodes appear. The arrow keys will navigate down or up the list and a hit on the enter key will summon that node.
Reading the node graph
Remember: scripts are not just meant to function, they are also meant to be read (by colleagues, by yourself and by your poor Nuke teacher). Reading scripts within the Node Graph is, for the most part, a fairly logical process. From the top a script presents as a set of sequential actions: e.g. Read followed by Multiply followed by Write. There is, however, a lot of hidden nuance to a script a lot of which is contained in some subtle niceties of the node interface.
In the set of nodes below each node tells us what changes there have been to the node stream:
- A No change
- B Alpha channel added (this is done automatically by many nodes)
- C Animation added
- D Expression driven
- E Channel other than RGBA added