Repository navigation
Network Rendering
LuxRender has the built-in functionality to render on networks, so that multiple computers can work together to increase render speed. This feature works both on local networks and over the internet.
When using network rendering, it is important to make sure that the same version of LuxRender is installed on all computers.
The basic concept of network rendering with LuxRender involves one managing computer (or master) and one or more rendering servers (or slaves). The client sends the rendering job to the servers, receives the result of the rendering at regular time intervals and displays the combined result.
The process of setting up network rendering consists of just a few steps: -on all of the servers, start the LuxConsole program and write down the computers' IP address -on the client, start the rendering and add the IP addresses of the rendering servers,
Luxconsole is a stripped down version of LuxRender that runs without a graphical user interface. This means it has to be started from a terminal or command line. The exact command to be typed depends on the operating system you are using.
In a terminal window, type “./luxconsole -s”. If all goes right, you should see some text saying something like “Launching server [2 threads] mode on port '18018'”.
On Linux, you probably know where to look.
Now that the render servers are set up, open LuxRender on the client and start the rendering (or start LuxRender directly from an exporter). In LuxRender, go to the network tab, for all of the render servers fill in the IP address in the Server field and press the “+” button. That's all!
After a while, the first contributions of the render servers will be sent back to the client. The contributions of the render servers will be added to the rendering in progress right away, so they can be seen in the Render tab. Also the S/px value should jump up any time a rendering contribution from a server arrives. Additionally, information about interaction between the client and servers can be followed in the Log tab.
Instead of starting the rendering from LuxRender's graphical interface, it is also possible to start the rendering from the terminal/command line. For example:
luxconsole -u 192.168.1.248 -u 192.168.1.19 -t 2 fullcornell-metropolis.lxs
Where "192.168.1.248" and "192.168.1.19" are the IP addresses of 2 servers. You can use as many "--useserver" (or "-u") options as you like (one for each server available). By default every 180 seconds the client will contact the server in order to download the traced samples. This interval can be changed by using the "--serverinterval" (or "-i") option:
luxconsole -u 192.168.1.248 -u 192.168.1.19 -t 2 -i 300 fullcornell-metropolis.lxs
The default TCP port used for client/server communication is 18018. You can use the "--serverport" (or "-p") option in order to change the tcp port:
luxconsole -s -p 10001
The "--useserver" (or "-u") also supports an extended format in order to define the port used by the server:
luxconsole -u 192.168.1.248:10001 -u 192.168.1.19 -t 2 fullcornell-metropolis.lxs
Network rendering over the internet works in the same way as on a local network, with the exception that one should use a proper IP address instead of an address on the local network.
On the render servers, network port 18018 should be available. If it is blocked by a firewall or router, LuxRender will be unable to connect, so you may need to adjust the firewall settings accordingly. It is also a good idea to specify the port explicitly in LuxRender's network tab, so for example 172.16.254.1:18018 instead of just 172.16.254.1.
Including support for all features required by a render farm (like job queues, accounting, authentication, etc.) is currently out of the scope of LuxRender. However, you can easy integrate LuxRender in one of the existing Distributed Render Queue Managers, for example the open source program DrQueue.
LuxRender is supported in DrQueue in the webinterface DrQueueOnRails through Ruby bindings. It does not yet work with the GTK gui drqman.
You can find all needed additional information in their Trac wiki and community forums.