Go to content

Script Efficiency & Organization - Bullet Guide - Guillermo Algora - Visual Effects Compositor

Skip menu
Guillermo Algora
Skip menu

SCRIPT EFFICIENCY & ORGANIZATION

BULLET GUIDE

Table of Contents:
2.1. Bounding Box.
2.2. Processing Blank Spaces.
2.3. Channels and Layers.
2.4. RAM Overload.
3. Structure affects your performance (as Compositor):
3.1. Use a single Source.
3.2. Script Flow.
3.3. Each Section Self-Contained.
3.4. Optimal Layering Order.
3.5. DTJO (Do Things Just Once).
3.6. Concatenate Transformations.
3.7. Order of Operations Matter.
3.8. Keep Consistency in the Script.
3.9. Explicit as Possible.
3.10. Prepare for Likely Changes.
4. Tips.
1. Metering Performance:

Profile Node:

It allows to measure the performance of a scrip by inserting the node at any point in the node tree and then using the Profile panel to determine the output of the analysis: CPU usage, memory consumption, number of operations (ops) performed by each node, and wall time, which represents the actual time taken for processing. More information here.

Performance Timers:

Nuke can display accurate performance timing data onscreen or output it to XML file to help troubleshoot bottlenecks in slow scripts. When performance timing is enabled, timing information is displayed in the Node Graph, and the nodes themselves are colored according to the proportion of the total processing time spent in each one, from green (fast nodes) through to red (slow nodes).

The Python commands to activate it, through the ScriptEditor are:
nuke.startPerformanceTimers() / nuke.resetPerformanceTimers() / nuke.stopPerformanceTimers()

In addition, the command nuke.Node.performanceInfo() will print the timing information for a particular node. e.g.:
Defocus1 {'callCount': 10228, 'timeTakenWall': 28524348, 'timeTakenCPU': 624512794}

Python for Render Time metering:

Setting a clock-watch with Python can help us in metering render timing information.
2. Aspects that affect performance:

2.1. Bounding Box:

Nuke processes everything that is delimited by the bounding box. Therefore, reducing it to the area that is actually needed is crucial for optimizing performance. There are some native nodes that can help us: Crop, AdjBBox, CopyBBox, and the AutoCrop. The BlackOutside node serves the purpose of adding a one-pixel black border outside the current bounding box, often used to address issues with replicated edge pixels that can occur after cropping or other bounding box adjustments. The Crop node also features an "intersect" option, which, when enabled, limits the output bounding box to the area where the crop region overlaps with the incoming bounding box.

Autocrop: a very powerful tool. When applied to a selected node, it analyses the image data and reduces the bounding box to the smallest possible rectangular area that contains all the non-black pixels (pixels equal or below zero, in the rgba channels that are within the rgba layer). To run it, select the node where you want to analyse, hit "x" on the keyboard and enter the "autocrop" command in the TCL mode. It will be run for the frame range specified in the Project Settings.

In addition, Nuke offers a Bounding Box Warning feature, accessible within the Nuke's Preferences, which highlights nodes that create a bounding box larger than the project's format plus a user specified threshold.

2.2. Processing Blank Spaces:

Likewise, Nuke processes black spaces of an image within the bounding box even if they contain no meaningful data. To avoid unnecessary processing, again the delimitation of the meaningful space with the bounding box is crucial, minimizing the processing of empty or irrelevant regions, which is particularly important when working with high-resolution plates or multi-layer compositions.

2.3. Channel & Layers:

The more channels you process, the more operations are performed. Reduce the processing to only the necessary channels.

2.3.1. Viewer Indicators:
Through the Viewer node, it can be assessed the amount of layers and channels currently available at that point (the Viewer's input point in the script). For that, its top left corner drop-down menu as well as the information at its bottom (next to the bounding box values) indicates the layers and the channels. The "other layers" sub-menu indicates all the available layers in the script, not in regards to the current Viewer's input point.

2.3.2. Node Indicators:
At the same time, Nuke displays in the DAG the current channels processed or by-passed by the node. More precise information can be found here along with a chart guide here.

2.4. RAM Overload:

It occurs when the software attempts to utilize more memory than is physically available on the system. This situation can arise from various factors, including working with exceptionally large scripts containing numerous nodes, processing high-resolution footage and lengthy sequences, and the use of memory-intensive nodes or plugins. When Nuke exceeds the available physical RAM, the operating system resorts to using disk-based virtual memory (also known as paging or swapping). Since disk access is much slower than RAM, this leads to a significant drop in performance. Nuke may still continue processing, but interactive responsiveness and render times can be heavily impacted. To overcome such a problem, the use of precomps along the script of before heavy computational steps are very beneficial.
3. Structure affects your performance (as a Compositor):

3.1. Use a single Source:

Duplicating multiple sources will slowdown the script and make it difficult to update or substitute them, making your work more prone to mistakes. Keeping a single source is ideal in that sense. Although Nuke caches image data efficiently, duplicated Read nodes with difficulties to cache, different settings or usage might bypass efficient caching, increase disk I/O, and add memory load.

3.2. Script Flow:

Use the software's native script flow, which is simply demonstrated in how the inputs are positioned when creating new nodes:
vertical structure from top to bottom. B input at the top, A input at the left-hand side and Mask at the right-hand side. This should be holistically extrapolated to the whole script structure.

3.3. Each Section Self-Contained:

Think of each section as a modular unit. You should be able to enable / disable it and the rest of the script should procedurally adjust. In addition, each should be able to be enabled / disabled from a single point.

3.4. Optimal Layering Order:

Composite BG -> MG -> FG, following the vertical top-to-bottom structure. The BG should be at the very top of the script, followed by the subsequent layers that come in front of it, one after the other, according to their position in the distance from the observer.

3.5. DTJO (Do Things Just Once):

Only do things just once, if you can. For each section / module place similar nodes / tasks together (i.e. grades, transforms, etc.) and avoid duplicates (e.g. multiple blurs instead of one for all merged elements) so that processes only happen once.

In addition, Keymix multiple grades that use the same mask instead of using the same Mask input on each node. Mask your element in the right place, as to avoid duplicating effects. And create custom layers / channels to store data that needs to be modified downstream.

3.6. Concatenate Transformations:

This will also improve performance while avoiding unnecessary filtering and degradation of the image. When multiple effects are not concatenable, can be very useful to apply them to a UV Map and then apply the whole effect at once through an STMap node. You can asses which nodes concatenate here.

3.7. Order of Operations Matter:

It does really matter: grades before premult, transforms after premult, blurs after transforms.

3.8. Keep Consistency in the Script:

If possible, and only when desirable, reformat elements to keep a consistent resolution throughout the script, helping to clearly display in the Viewer frame what is being merged, while at the correct formats to avoid unnecessary outside of the bounding box operations.

3.9. Explicit as Possible:

Avoid obscuring operations and hidden settings, label the work correctly and display as much useful information as possible. Ah, and do not hide inputs.

3.10. Prepare for Likely Changes:

Yes, they will most likely come at some point and from many fronts. Prepare your script for it: make it as simple, efficient and procedural as possible to adapt to changes quickly and successfully. Leave enough space  between setups and tidy up along the way.
4. Tips:

  • ZDefocus and Convolve nodes are computationally expensive, use them wisely.
  • Tracker nodes that are live and plugged in the pipe slow down scripts quite significantly (continuously reprocess image data and can block caching). Try to export the linked or baked transformation instead.
  • Remove unwanted output passes from the rendering nodes (for example, from the ScanlineRender).
  • Disable unused geometry in the script.
  • Save Toolset presets. Allows you to quickly save organized and efficient setups without having re-build them each time.
  • View Overscan in the Viewer Settings. Useful to crop unnecessary parts. Do not forget to change the "size" setting to avoid unwanted cropping in the visualization.
  • Card3D node is much faster than the regular Card node. It useful for tasks like faking camera zooms or perspective adjustments, however limited in the sense that it cannot interact with other 3D objects inside a scene, as it is not actual geometry.
  • LiveGroups to breakdown a big script into smaller and shareable components. More information here.
  • The Frame Server for rendering locally in the background, as it uses multiple instances of Nuke to render many frames at the same time, increasing system usage and decreasing render time. Although keep in mind, it can be bug-ish.
  • Proxy mode: reducing the resolution of the Viewer in the top right-hand side menu (i.e. by half, 1/2) can help to lessen its load on heavy scripts. However, keep in mind that result may vary between what is displayed when reduced resolution is on and the full res (this applies specially to nodes with a filter option).
  • Postage stamps: set their behaviour to "static" in the Nuke Properties, so that their display is not recalculated on every frame.
Back to content