| 29 June 2010
3. CONCATENATING TRANSFORMS
4. CARD3D
5. BLUR INSTEAD OF DEFOCUS
7. LOWER RES / LESS FRAMES PREVIEW
Previewing at lower resolutions / frame rates. In the process of compositing a shot, it's not neccessary to view all your frames at full res all the time. You can get away with working in proxy modes, and also rendering in proxy modes for you just to check how things are going in the comp. Sure when it comes time to submit, or you are getting pretty close then rendering full res is what's required, but for just getting comps up the scratch or problem solving errors rendering proxy sizes is more efficient. The same applies to frames, you can also get away with rendering say every fifth frame instead of every frame in the early stages of your comp work. The render time will be five times faster (10 minutes instead of 50 mintues for instance) and you will able to spot most errors this way. I wouldn't recommend doing this all day, everyday as you will need to see the inbetween frames, but its a very quick way of getting up to speed on your comp and really does save you and the rest of the team wanting to using the render farm time! Most flipbook viewers can play back at various frame rates so if you do render every fifth frame you can play back at %20 of the speed.. sure this will look steppy but you will get the idea of timing. Even if you are rendering every second frame, this is two times faster of course, something to think about it.
8. PRECOMP
Precomp sections of your script that you aren't changing or have been signed off. Even so called 'still frames' can actually use quite a bit of processing for each frame, so if it really is supposed to be just a 'held' frame or matte painting that has a lot of additional work done in Nuke, it's best to pre render this as a still frame. You can precomp on the fly while rendering you whole script also. If you set render orders on write nodes, you can go down through your tree creating write nodes, and then read nodes straight after, rending in the write nodes. If you haven't rendered these write nodes yet, you will have to manually fill out a read node with the path from the write node, and remember to set the frame range! Nuke will default to 1 during this process. You will also get an error from the read nodes saying it doesn't exist, and it doesn't, yet! So working your way down, set the write node orders so your final main comp has the highest value, say if you had two precomps in your script, the first would be 1, second would be 2 and your main comp write node would be 3. Nuke now has a read check box on write nodes, saving you from creating both read and write nodes for precomps. You will have to write them out first before you select read othewise it will error.
Nuke now also had a 'precomp' node that saves a selected portion of your script into a new script and adds a write node to it. You can also manage versioning of this new script and its output for bringing back into your comp. If you have render an exr sequence from this precomp script, Nuke will be smart enough to realise if the script has been updated but the file sequence that is being read is out of date (Nuke picks this up from the hash information in the EXR). Although you can create these precomp scripts for your own use, I prefer to manage my precomps in the same script with my own read/write breaks. I would keep the precomp scripts function for collaborative work (either with lighting TD's or other compers for example). Refer to the excellent Nuke user manual for more information. 
9. RENDER LOCALLY
Render locally in the back ground. Most modern workstations have tonnes of RAM and multiple processors - you will probably find that you can get away with rendering in the background via the command line, yet still be able to work pretty comfortably in terms of interactive responsiveness. Especially if your frame ranges are short, and if the farm is clogged or slow to pick up (if you have one!).
Valerio Oss
said:
|
... Hi just an update about the precomp chapter: now the WRITE note INCLUDES a READ node: just use the checkbox readfile at the end of the Write parameters tab and that' is, no need of the READ node anymore, the node writes the data to disk and reads them immediately after! Two nodes in one! |
rasika jayawardene
said:
|
... i second the tip on channels.. im relatively new to nuke and found the hard way that certain heavy channels should be removed at the beginning on the pipe so that it doesn't create problems at the end. specially when there are a lot of blurs and defocuses and when forgotten to change the channels to RGB instead of all... i find this is very relevant when working with multilayered exr's for cg...use the layers to make the composite, and then remove the extra channels for the pipe so that it doesn't create problems down end!!! |
Chidi Ozieh
said:
|
... This is very helpful. I am currently work on quite a large comp in Nuke and this has literally saved my project. Thanks! |
a guest
said:
|
... I'd love to know more about why I should be avoiding TIFFs. Do they hog memory when they're in RAM or when they're on the filesystem? |
Scott Chambers
said:
|
... As far as I know, TIFF images have to be read and stored in memory in one pass, so you don't get the speed advantages from the adaptive scanline viewer renderer or crops and bounding boxes. |
Chidi Ozieh
said:
|
... Hi Scott was just wondering if you know how to add motion blur to an image. ( png sequence on a 2d card in a scene ). Much appreciated. If this is posted in the wrong place apologies. |
Scott Chambers
said:
|
... Hey Chidi, this isn't really the forum for questions and answers but happy to help - stay tuned for forums in Nukepedia in the future... To add motion blur to an image coming out of the scanline renderer you can use multisampling in the scanline renderer to be greater than 1 (gets pretty slow as you go up the samples for higher quality) or use the vector blur straight after the scanline renderer. There is quite a bit of info in the user manual regarding both methods. Good luck! S. |
steve morel
said:
|
... Thans a lot for those tips ! I'm pretty new in NUKE, and this community looks really awesome !! :D Keep up the great work ! : ) |
Cédric Mau
said:
|
... A lot of thanks Scott for those tips. Very helpful. Harsh : As far as i know, targa images have 8 bits limitations. And i'm pretty sure that you can't export additionnal channels |
a guest
said:
|
... // Avoid tifs, those memory hogs are for print and have nothing to do in a compositing pipeline (have fun explaining that to your matte painter).// Amazing quote! and also great article, of course :D |
