Evaluating Script Structure
Start
Mistakes made when the script is first being written can cause knock-on problems later on.
Keep all project files within a folder
Nuke scripts are not like Photoshop files that can be saved as self-sufficient entities. In order for a Nuke script to function it must 'know' where all the referenced source files are. To ensure this proper project management is needed. DT2010 house convention is this:
- Make a folder (project_name and any version or sequence number).
- Save the Nuke script into that folder and name it in a rational manner.
- Create a folder called 'sources' into which all the assets (image sequences, tiffs, tgs etc) are to be placed.
As long as the file paths in the Read node (see below) are properly configured, the project is now completely portable.
Name all assets rationally
Don't always use the names that the assets came with. DCS_00953.jpg or gjfhghjfg.jpg, are not good descriptors. Above all be consistent.
Dont use absolute paths in Read nodes
Absolute paths in the Read node (e.g. My Computer /funky_school_stuff/Martins_Class/session one/Stuff/ Asset_Name.JPG) will become meaningless the moment the Nuke script travels outside of the computer in which it was authored. Instead a relative path should be used. This will point to the media in a manner that is relative to the script. Below on the left is an absolute path and on the right a relative one (using 'Method 1' outlined below).
Method 1 (easy): DT2010 house convention is this: paste this into the file parameter of the Read node:
[file dirname [value root.name]]/sources/Asset_Name.JPG.
This will only work if you keep all your media in a folder marked ʻsourcesʼ which is in the same folder as your Nuke script.
Method 2: If, by chance, you are keeping the footage on a network drive then a different approach is needed. The expression can point instead to a value in a paramater within a NoOp node. The NoOp can be re-named to Project_Path with a paramater name of Path. The Read node can then refer to [value Project_Path.path]. To make this a bit easier: here is a NoOp configured for this purpose:
set cut_paste_input [stack 0]
version 6.3 v2
push $cut_paste_input
NoOp {
name Project_Path
label "\nPlace in this node the file\npath of your project. "
note_font "Verdana Bold Bold Bold Bold Bold Bold Bold Bold"
note_font_size 9
note_font_color 0xff
selected true
xpos -1593
ypos -581
addUserKnob {20 User}
addUserKnob {2 tutorpath l "Project Directory:" t "This field needs the full path of the location where you have stored your project files. \n\nIf you don't know the path, click the folder button and browse through your directory structure to find and select the folder where the project files are stored. "}
addUserKnob {26 ""}
addUserKnob {26 directions l Directions: -STARTLINE T "Place here the path of 'top level' folder of your \nproject. If you don't know it drop the folder \ninto the node script and copy it from there \n(it will be in the file parameter of one the \nresulting read nodes)"}
}
Consider image sequences instead of QuickTime files
Movies wrapped up in a QuickTime file can sometimes be difficult to perform time edits upon. It is recommended that you make an image sequence instead. See: Read#Image sequence.
Always set the values correctly in Project Settings before you start
The format, once set, will determine all default formats after that. This is very important as a wrongly set format can screw up a script. Aso... the frame range value should always start from 1.
Dont over use the reformat node
If you wish to re-format a still image why not just do so in Photoshop? It requires less processing from Nuke and looks tidier. It also, in my experience, encourages a more careful evaluation of how the image might relate to the rectangle of the new format. Heres how to reformat: Photoshop Nuke Workflow.
Color
Lots of stuff here about premultiplication
Don't color correct an image that has been pre multiplied
Color correction must only be done on FG images that are not pre multiplied. To un-premultiply you may use an Unpremult node.
Don't composite a FG that is not pre-multiplied
For a lucid explanation see Premultiplication.
Don't premultiply twice in a row
Double pre-multiplication is bad. It can lead to fuzzy edges.
Color adjust only RGB
By default all color adjustments work on the alpha of an image as well as the RGB. Almost always this is not a good thing and can really screw up a comp. Set the color adjustment to RGB only.
Consider using simple color tools before using complex ones
Fancy nodes with lots of sliders might look fun to play with but are they necessary? You will find that for a lot of color correction work a Multiply or ColorLookup is enough.
Consider using separate color adjustments instead of one large one
Though it is possible to roll many color adjustments into one, they are easier to evaluate if done as separate adjustments. This can be important when 'perception value' pairs like lightness / color or saturation / hue are being adjusted together.
Housekeeping
Clean the sink, tidy your bedroom and comb the cat.
Keep a tidy script
DT2010 students: observe the ʻhouse script conventionsʼ or evolve a good set of your own.
Consider masking stills in Photoshop
A Nuke roto is not always a good way to mask a still image. Consider using Photoshop masks instead: they are quicker to make and usually better at complex forms (far more able to cope with things like the soft edges of hair and far more capable of handling knock-out shapes and negative shapes). Save Photoshop result as tiff. Look at Photoshop Workflow for tips on how to do this.
Donʼt leave 'fiddle' values in the parameters
When reading someone else's script it can be very confusing to open something like a ColorCorrect and discover that some of the parameters have been set to random, completely ineffectual values (e.g. a saturation value of .00004). It is inevitable to want to fiddle with a set of paramaters whilst trying to get the best result, but if a parameter change has no effect then it should be returned to its default (to set to default Command click on the slider or contextual menu it). Try to get to know exactly what each parameter does and what its place within the adjustment is.
Layers, keyers and masks
Avoid side masking a merge node
Side masks are for things like color corrections, filters etc. They are not to be used to determine transparency in a Merge node. The same mask can be added to the Merge feeds as a Matte value using a Max or Min blend mode.
Observe the primacy of the B feed
A script can be bothersome to manage if B feed primacy is not observed. See Primacy of the B Feed.
Manage the bounding box
Poor Bounding Box Consideration can slow down a script with unnecessary processing.
Avoid feeding more than two inputs into a merge node
Though the Merge node will accept many streams it does not always do so in a way that is consistent and predictable. Also, a script that has all its merge operations stacked inside of one node is very hard to troubleshoot as its layers can not easily be turned off one by one. It can also be hell to re-order the layers such an arrangement. Consider instead stacking the merge operations one after the other.
Donʼt use a keyer node as a substitute for a merge node
The keyer's main job is to deliver an alpha, not to do the layering itself. The foreground of a comp done in a keyer is very difficult to color edit without also affecting the green screen values. The merging on the foreground with the background, and the associated color editing involved, is best handled as a completely separate operation to the key pull.
Avoid to many points when you roto
Many points can be difficult to edit and hell to animate. Use as few as you can. More on roto here: Rotoscoping.
Avoid recycled masks
If a single mask is used on two or more nodes in a row then it can cause problems. This topic is covered fully in the KeyMix page.
