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 master and one or more slaves on different computers. The OctaneRender instance that drives the rendering is referred as the ‘master’ and the OctaneRender instances that are helping are referred as the rendering ‘slaves’.
Since an OctaneRender slave 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 slave computer. Also ensure that the master and the slave 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 master. If that does not help, also try switching off the firewall on the slave computer for home/work networks.
Master, Slaves and Daemons
The Standalone version or the octane.exe act as master and a special console version of OctaneRender, octane_slave.exe, can run on other computers as slaves. Of course, they should be all on different computers or they would have to share the same GPUs. Running the slave on the same computer as the master is pointless.
The OctaneRender network render slave is fairly dumb and all the render data processing is actually done on the master side. The slave does not need to have a powerful CPU at all, but the slave is of course required to have enough memory (RAM) to store the render data plus some render results. The operating systems of the slaves can also be different since the communication between the machines is cross platform. No data is stored on the slaves’ discs, it all happens 100% in memory.
Each time network rendering is required, the slave process has to be launched on the slave machines. The slave daemon makes the control of the slaves more practical, as slave 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 slave process on the machine (on request by a master), monitors it and stops it (on request by a master). Monitoring means making sure that a running slave sends a regular ‘heartbeat’ to the daemon and if that doesn’t happen it will try to stop the slave gracefully and if that does not work, it kills the process. The daemon runs all the time and starts/stops a slave process if a master requests it. The daemon also listens for the ‘heartbeat’ of the slave to check if the slave process is still running at all. This slave daemon eliminates the need to launch the slave process manually on each computer each time rendering is required on the slave.
The Standalone Edition’s network rendering feature is also useful while using the ArchiCAD Plugin Edition:
Octane’s licenses are per machine where any machine can become either master or slave.
Setting Up The Slave Daemon
To set up the daemon, simply run the batch script _install_daemon.bat on the slave computer. During the setup, it will ask which port the daemon should listen to for master requests. After that, the daemon will be resident on that machine and it will be active at all times.
← Double-click ‘_install_daemon.bat’ to install the Slave Daemon.
Figure: Requests during setup of the Slave Daemon.
When a daemon is invoked by a master, the slave is quickly launched to get some information about the number of GPUs, version, bitness, etc. and then closed again. After that there is no slave process running. So the daemon just sits there and waits for masters (there could be multiple masters 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 masters. If it does not, it can have the following reasons:
Only when you enable a daemon in the master settings, the slave gets actually launched and will eventually appear in the status bar of the master. One daemon can be activated only by one master at a time. If daemon is currently ‘occupied’ by another master the user will see the daemon state change accordingly. The automatic port configuration is an option on the master that enables multiple masters to be used on the same computer.
When network rendering is disabled, the local network is not scanned for daemons. The master scans for daemons only when network rendering is enabled.
In all versions of Octane, there is always some hardware considerations such as the node/ 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. power density and heat loads within the slaves which affect availability and usability of each installed GPU.