Network rendering is dependent on the Standalone Edition’s connectivity to other machines. The 3DS Max® plugin needs to connect to this feature through the Standalone Edition. For this reason, each machine that houses GPUs used for distributed rendering should have its own unique Standalone Edition license key.
Figure 1: Connectivity for network rendering
To use the plugin’s network rendering feature, you need the Enterprise Render Node installed on each of the external computers. Refer to the Standalone manual to learn how to do this.
The network render nodes must have the same version as the current plugin’s engine version, otherwise you will not be able to use the render nodes.
Once you install, authenticate, and set up the OctaneRender® Enterprise Render Nodes, go back to the Primary Render Node machine and click on Render Setup, then the Network tab, and then click on Open Network Configuration. Click the Open Network Configuration button.
Figure 2: Opening the Network Configuration window
The Network RenderingThe utilization of multiple CPUs or GPUs over a network to complete the rendering process. preferences work a bit different compared to the other settings, as you can only edit these preferences when Network Rendering is disabled. Likewise, any changes on the network preferences are updated when you re-enable Network Rendering. The Cancel button does not have an effect in this case.
Figure 3: OctaneRender Network Preferences
Network rendering lets you utilize additional GPUs in other computers to render images. OctaneRender® distributes compiled render data and not scene data, so no file management is required. It is similar to working with additional GPUs by allowing the distributed rendering of single images over multiple computers connected through a fast local area network. Network rendering requires a Primary Render Node and one or more helper render nodes on different computers. The OctaneRender® instance that drives the rendering is the Primary Render Node, and the OctaneRender® instances that help are the render nodes.
The Primary Render Node requires an OctaneRender®Enterprise license while the render nodes will each require an OctaneRender®Enterprise Render Node license. Make sure that the Primary Render Node and the helper render nodes are not blocked by any firewalls in the network or operating system.
The Standalone version or the octane.exe act as Primary Node and a special console version of OctaneRender®, octane_node.exe, can run on other computers as Render Nodes. They should all be on different computers, or they would have to share the same GPUs.
The OctaneRender® Primary Node does all the render data processing. The Render Node does not need to have a powerful CPU, but the Render Node needs enough RAM to store the render data plus some render results. The Render Node's operating systems can also be different since the communication between the machines is cross-platform. No data is stored on the Render Node’s discs, it's all stored in memory.
Each time network rendering is required, the Render Node process has to launch on the Render Node machines. The Render Node daemon makes the control of the Render Nodes more practical, as it can launch at startup on each machine in the network. The daemon is the little program that starts a Render Node process on the machine on request by a Primary Node, monitors it, and stops it on request by a Primary Node. Monitoring means making sure that a running Render Node sends a regular heartbeat to the daemon, and if that doesn’t happen, it first tries to stop the Render Node, and then it kills the process as a last resort if necessary. The daemon runs all the time, and starts/stops a Render Node process if a Primary Node requests it. The daemon also listens for the heartbeat of the Render Node to check if the Render Node process is still running. This Render Node daemon eliminates needing to launch the Render Node process manually on each computer each time rendering is required on the Render Node.
Figure 4: Primary Node - Render Node configuration
The Standalone Edition’s network rendering feature is also useful while using a plugin. OctaneRender’s licenses are assigned per machine, so any machine can become a Primary Node or Render Node.
To set up the daemon, run the batch script _install_daemon.bat on the Render Node computer. During the setup, OctaneRender® asks you to choose a port for Primary Node requests. After that, the daemon resides on that machine, active at all times.
When a Primary Node invokes a daemon, the Render Node launches to get some information about the number of GPUs, version, bitness, etc., and closes again. After that there is no Render Node process running, so the daemon waits for Primary Nodes to detect it by scanning the complete local network in regular intervals. The daemon should appear in the daemon list of the network preferences of the Primary Nodes. If it does not, it could be because:
When you enable a daemon in the Primary Node's settings, the Render Node launches and appears in the Primary Node's status bar. One Primary Node can activate one daemon at a time. If daemon is occupied by another Primary Node, you will see the daemon state change accordingly. The automatic port configuration is an option on the Primary Node that enables the same computer to use multiple Primary Nodes.
When network rendering is disabled, the local network is not scanned for daemons. The Primary Node scans for daemons only when network rendering is enabled.
OctaneRender® (through the Primary Node) may use the networked GPUs as long as the number of GPUs do not exceed the limit set by the OctaneRender® license for that Primary Node. The OctaneRender® Enterprise license lets a Primary node render with up to 200 GPUs at a timeincluding the Primary Node's GPUs in the machine. For Studio licenses, a machine can use up to two GPUs at a time and has no support for network rendering.
In versions 3.05.0 and earlier, OctaneRender® looks for GPUs in Render Node nodes within the same subnet, so OctaneRender® treats every GPUThe GPU is responsible for displaying graphical elements on a computer display. The GPU plays a key role in the Octane rendering process as the CUDA cores are utilized during the rendering process. in the Primary Node and Render Nodes as if these are installed in the Primary Node machine. Each local and remote GPU in the Render Nodes is just another GPU, so as long as it is available (not used by other renderers or the OS or any other application) and it's exposed as a CUDA® GPU, OctaneRender® will pick those GPUs in that subnet until it reaches the GPU limit, if the network has more than the GPUs limit then the rest of the available GPUs will just not be used.
In OctaneRender® v3.06.x and later, the native Octane Network Rendering feature has integrated support for multiple subnets and considers hostnames and IP addresses. The improved Network Render feature considers the per-Render Node systems that determine how GPUs are allocated to applications and the overall network system configuration that affect how networked nodes allocate processing capabilities between nodes. Depending on how the mix of configurations play out, there are some cases where a network allows OctaneRender® to use up to the GPU limit across the network, regardless what Render Nodes the GPUs are installed in (per GPU regardless of the Render Node), and there are also other cases where the network cuts off the other remaining Render Nodes when a Render Node will go over the GPU limit (so per Render Node rather than per GPU, this means it will use all GPUs in that Render Node or not use that Render Node at all) - effectively reducing the total rendering GPUs to significantly less than the limit.
In all versions of OctaneRender®, there is always some hardware considerations, such as the node/GPU power density and heat loads within the Render Nodes that affect the availability and usability of each installed GPU.