Rendering Using the Frame Server

The Frame Server reduces render times by sharing work over the number of render processes specified in the Preferences. The Frame Server logs renders in the Background Renders panel, including information such as script name, Write node, frame range, progress, and whether or not the render produced errors. The Frame Server does not display a progress bar for render tasks, but you can disable Render using frame server in the Render dialog to use the process from older versions of Nuke.

The Frame Server is disabled by default, but you can enable it in the Preferences > Performance > Threads/Processes or on a per render basis in the Write node's Render dialog.

Note:  Local Frame Server processes use ports 5558-5662.

Rendering Write nodes, either from a node's Properties or from the Render menu, displays the Render dialog. See Output (Write) Nodes for more information on initiating renders. If the Frame Server is enabled, clicking OK in the Render dialog starts the selected renders in the background, allowing you to keep working.

The Background Renders tab is not displayed as part of the workspaces that ship with Nuke, but you can enable Performance > Threads/Processes > focus background renders in the Preferences to open the panel automatically when the Frame Server is in use.

Tip:  You can also add the panel manually by right-clicking the button in the top-left of any pane, and then selecting Windows > Background Renders.

The Background Renders panel includes information such as script name, Write node, frame range, progress, and whether or not the render produced errors.

Frame Server Preferences

You can control how the Frame Server behaves using the Performance > Threads/Processes tab in the Preferences:

• render using frame server (Nuke) - when enabled, the Frame Server is always used for rendering.

• focus background renders - when enabled, rendering using the Frame Server automatically opens the Background Renders panel, or if it is already open, shifts focus to the panel.

• frame server processes to run - sets the number of render processes available to the Frame Server.

Note:  You must restart Nuke if you change the number of processes available.

• export renders - allows you to set limitations on the resources available for render processes:

• limit renderer (more responsive ui) – select this option to make the user interface more responsive during rendering. It tells Nuke to use 2 threads to transcode and to use 25% of RAM to cache. Using this option is likely to result in slower renders.

• no renderer limits (fastest transcoding) – select this option to ensure that renders happen as quickly as possible. This option may result in a less responsive user interface during rendering.

• customize render limits – select this option to manually configure the number of threads used and cache memory available during renders.

Using the Frame Server on External Machines

Although Nuke is capable of rendering frames internally, running the Frame Server on an external machine can accelerate the process considerably by sharing work across a network of machines.

Note:  The Frame Server requires a Nuke license (nuke_i) on the main workstation, but only a Nuke render license (nuke_r) on the render machine.

If you want to use an interactive license (nuke_i) on the render machines, add the --useInteractiveLicense argument to the runframeserver.py command described below.

Configuring the Frame Server on External Machines

Nuke's Frame Server can be set up on an external machine (or a number of machines) to render from your session. To do this, you need to run the runframeserver.py script on the render machines, found inside the Python site-packages, with specific command line arguments.

Warning:  In order for everything to work smoothly, you need to ensure that both your external render machines and main Nuke session can read and write files to a shared location, such as an NFS share.

Depending on platform this can be done by manipulating your default umask setting, but be aware that this alters the permissions of the created files.

Additionally, Macs and certain Linux distributions, such as RHEL, can not function as the main workstation if the firewall is blocking the communication port 5560. You can configure the firewall to allow certain ports through the firewall using the iptables command, but use caution when doing so. For example:

sudo iptables -I INPUT -p tcp --dport 5560 --syn -j ACCEPT

Please refer to the documentation on firewalls for your particular platform for more information.

The Frame Server uses a number of worker processes on the render machine, each of which requires allocated resources, such as threads, memory, and so on. There are a number of arguments that you must pass to runframeserver.py for the server to work correctly:

• --numworkers - this is the number of concurrent Nuke processes that are launched when you run this server render node.

• --nukeworkerthreads - the number of threads that each worker is allocated. This is similar to setting the -m argument when running Nuke from the command line.

• --nukeworkermemory - the amount of memory, in MB, allocated to each frame server worker.

• --workerconnecturl - the TCP port address of the main workstation you want to serve. For example:

tcp://bob:5560

where bob is the resolved hostname of a machine you wish to serve. You can also use an IP address.

Tip:  To ensure that you're entering a valid URL, try using the ping command to see if you get a response.

• --nukepath - the path to the Nuke application on the render machine.

Tip:  On Windows, if there are spaces in the file path, remember to place the path in quotes.
For example, --nukepath="C:\Program Files\Nuke13.1v5\Nuke13.1.exe"

On a Linux render machine, an example command prompt entry running from the install directory might look like this:

./python ./pythonextensions/site-packages/foundry/frameserver/nuke/runframeserver.py --numworkers=2 --nukeworkerthreads=4 --nukeworkermemory=8096 --workerconnecturl=tcp://bob:5560 --nukepath=./Nuke13.1

On a Windows render machine, an example command prompt entry running from the install directory might look like this:

python.exe pythonextensions\site-packages\foundry\frameserver\nuke\runframeserver.py --numworkers=2 --nukeworkerthreads=4 --nukeworkermemory=8096 --workerconnecturl=tcp://bob:5560 --nukepath=Nuke13.1.exe

On a macOS render machine, an example command prompt entry running from the application directory might look like this:

./python ../Resources/pythonextensions/site-packages/foundry/frameserver/nuke/runframeserver.py --numworkers=2 --nukeworkerthreads=4 --nukeworkermemory=8096 --workerconnecturl=tcp://bob:5560 --nukepath=/Applications/Nuke12.1v1/Nuke12.1v1.app/Contents/MacOS/Nuke12.1

In the examples, we specify that the render machine uses two Nuke workers, with four threads and 8 GB RAM each, and are on the same network as the main Nuke workstation running on bob.

Tip:  If your render machines run a different OS than your main Nuke machine, you can use the --remap command line argument to convert file paths between them. The host file path is read first followed by the render file path. Nuke expects all file paths to use / (forward slash) between directories. For example:
--remap "P:/,/mnt/renders/"
converts host paths beginning with P:/ (Windows style) to remote paths beginning with /mnt/renders/ (Linux style).

You can check that the Frame Server and workers are connected by running the following lines in the Script Editor on the main workstation:

from hiero.ui.nuke_bridge.FnNsFrameServer import frameServer

print [worker.address for worker in frameServer.getStatus(1).workerStatus]

Successful connections should report something similar to the following in the output panel:

['Worker 0 - henry.local - 192.168.1.11', 'Worker 0 - bob.local - 192.168.1.111', 'Worker 1 - henry.local - 192.168.1.11']

Where henry.local is the name of the remote render machine, and bob.local is the name of the main Nuke session.

Note:  If the workers cannot contact the Frame Server, an exception is printed in the Script Editor's output panel.

Frame Server Logs

Broker and Worker logging can to help diagnose Frame Server issues. The logs are written to NUKE_TEMP_DIR/logs by default, and take the form:

broker.log

worker-0.log

worker-1.log

worker-2.log

Note:  Running the Frame Server using Python, as described above, always writes log files to the specific OS temporary directory. For example, on Windows C:\temp is used.

Tip:  You can use the FRAMESERVER_LOG_DIR environment variable to force Frame Server logs into a different location. See Environment Variables for more information.