Q100431: Improving render times using the Buffer cache for non image editing changes
When rendering image channels as separate Write nodes, Nuke will render the furthest upstream Write node first. Nuke's render process uses the Buffer cache to store this render data, which can be reused after to render downstream Write nodes faster.
This article explains the benefit that this rendering process has to offer and provides examples of how this can be used practically within a Nuke script.
The script illustrated below shows a main comp image with red, green, blue and alpha channels. The comp image is rendered via the first Write node. Each channel is then split out from the main rgba layer using Remove nodes. The end Write nodes are used to render each channel into a separate image file.
NOTE: For this to work, the Write node upstream needs to have rendered the channels which are used in the Write nodes downstream.
The rendering process in this example will first start processing the nodes required for rendering the upstream Write node, as displayed by the yellow arrows:
Once the upstream Write node has completed rendering the current frame, the rendering process will use the previous render image data stored in the Buffer cache to continue rendering the rest of the nodes, as displayed by the blue arrows.
Additional nodes like the ModifyMetaData node, which do not directly affect the result of the image, can be added before the end Write nodes. This allows you to modify metadata for downstream branches and Write the result out without needing the re-evaluation of the Buffer cache.
The benefit of this process is that it gives users the ability to set up a 'main' Write node upstream and reuse the Buffer cache data to render additional Write nodes, with non image editing changes, significantly faster.
In this example, rendering each end Write node only took 0.2-seconds on average compared to the 3.44-seconds of rendering the upstream main comp Write node:
3D node setups
The Buffer cache also works when using Nuke scripts with additional layers, the below example uses Nuke's 3D system to generate additional layers.
In this example, users have the ability to split motion and depth information into their own layer files. These additional files can be rendered faster as the image data is not changed between Write nodes. Also, they can be used for additional compositing (as pre-composited files) or can be shared with other applications.
In the screenshot below, the 3D layers created earlier in the script are shuffled into an RGB layer and exported, with modified metadata:
NOTE: Unfortunately, when splitting multiple view scripts, such as stereo scripts, each view will need to run the full rendering process.
To review the workflow example provided above, please download the attached zip archive which contains the Nuke project and setup files.
To learn more about Nuke's Write node render outputs, please check the Nuke Online Help here: Nuke Online Help - Rendering Output
For more information on channels please see the sections of our Online Help here: Nuke Online Help - Channels.
For an explanation of the differences between channels and layers can be found here: Q100263: Layers and Channels differences in Nuke
Documentation on the Buffer cache and other types of image caching used in Nuke, can be found here: Nuke Online Help - Image Caching.
We're sorry to hear that!Please tell us why.