Network rendering renders images using all of the GPUs in a networked group of computers. OctaneRender distributes compiled render data and not scene data, so no file management is required by the user. Conceptually 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 Node and one or more Render Nodes on different computers. The OctaneRender instance that drives the rendering is referred as the “Primary Node” and the OctaneRender instances that are helping are referred as the “Render Nodes”.
Since an OctaneRender Render Node currently requires an activated Standalone license, it is advisable to run the Standalone first to activate a Standalone license on that computer, if necessary. It is best to copy the whole folder of the released archive onto the Render Node computer. Also ensure that the Primary Node and the Render Node are not blocked by the Operating System firewall or any firewalls in the network. This can be done, for example, by turning off the firewall for home/work networks on the Primary Node. If that does not help, also try switching off the firewall on the Render Node computer for home/work networks.
Primary Node, Render Nodes and Daemons
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. Of course, they should be all on different computers or they would have to share the same GPUs. Running the Render Node on the same computer as the Primary Node is pointless.
The OctaneRender network Render Node is fairly dumb and all the render data processing is actually done on the Primary Node side. The Render Node does not need to have a powerful CPU at all, but the Render Node is of course required to have enough memory (RAM) to store the render data plus some render results. The operating systems of the Render Nodes can also be different since the communication between the machines is cross platform. No data is stored on the Render Nodes’ discs, it all happens 100% in memory.
Each time network rendering is required, the Render Node process has to be launched on the Render Node machines. The Render Node daemon makes the control of the Render Nodes more practical, as Render Node daemon can be set up to be launched at every start up of the operating system of 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 will try to stop the Render Node gracefully and if that does not work, it kills the process. 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 at all. This Render Node daemon eliminates the need to launch the Render Node process manually on each computer each time rendering is required on the Render Node.
The Standalone Edition’s network rendering feature is also useful while using a Plugin Edition:
Octane’s licenses are per machine where any machine can become either Primary Node or Render Node.
Setting Up The Render Node Daemon
To set up the daemon, simply run the batch script _install_daemon.bat on the Render Node computer. During the setup, it will ask which port the daemon should listen to for Primary Node requests. After that, the daemon will be resident on that machine and it will be active at all times.
When a daemon is invoked by a Primary Node, the Render Node is quickly launched to get some information about the number of GPUs, version, bitness, etc. and then closed again. After that there is no Render Node process running. So the daemon just sits there and waits for Primary Nodes (there could be multiple Primary Nodes in the local network) 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 can have the following reasons:
Only when you enable a daemon in the Primary Node settings, the Render Node gets actually launched and will eventually appear in the status bar of the Primary Node. One daemon can be activated only by one Primary Node at a time. If daemon is currently “occupied” by another Primary Node the user will see the daemon state change accordingly. The automatic port configuration is an option on the Primary Node that enables multiple Primary Nodes to be used on the same computer.
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.