Setting up a network render

Important Note

When a computer enters in Sleep mode, it stops all its activity. In order to avoid a network job getting stopped for this reason, set the sleep option for all your network computers (both for the Manager, Monitor and Nodes) to Never.

This will ensure all your computers will stay available and do not enter sleep mode during a network task.

Step 1 - Check that all computers are properly connected in your network and that all nodes are properly licensed

Make sure all your computers are properly connected to the network, and check the read/ write permissions on each machine, for example by checking that the currently logged-in user can write a file in the folder you intend to specify as the output folder for network rendering. Make sure there are no firewall restrictions on the machines prior to initializing the Maxwell Render network.

Make sure also that all Maxwell Render installs on each of the nodes is properly licensed. You can do this quickly by simply opening Maxwell.exe (not Studio) in each node and checking in the Console panel that there are no licensing errors.

Step 2 - Launch Manager and the Nodes

Launch the Manager.exe on the computer that is going to run as Maxwell Manager, and launch Maxwell Render Node in the computers that are going to work as nodes. You can also run a node on the computer that is running the Manager. It can manage the network rendering and also contribute to the rendering process. Only one Manager is allowed to run simultaneously on the network.

Step 3 - Launch Monitor

Launch the Monitor on the computer where you want to control (launch/ display/ stop) the rendering process. The Monitor will automatically connect to the network to search for the Manager and the available Nodes. They will be listed in the Nodes panel. The Monitor can run on the same computer that is running the Manager. Check in the Monitor>Nodes panel that all your computer nodes are listed there. If some of them are not listed, check the firewall settings on that computer and make sure it is not being blocked.

Step 4 - Add a job

Use the Add Job button to submit a job. This will open the Add Job Wizard to help you through the process. Select one of the following options.

  • Single job: to make a non-cooperative render queue with each node working on an independent frame.
  • Cooperative job: several computers work on the same image, which will be merged at the end of the process.
  • Animation job: select a scene and the frame range, and the frames will be distributed among the available nodes. You can also render single frames from the same sequence by using a semi-colon “;” when typing. For example: 1-10;12;20-23. This will render frames 1 through 10, frame 12, and finally frames 20 through 23. Any padding number is allowed.
  • Batch job: This option allows you to select multiple MXS scenes to be rendered. All the scenes are rendered using their own settings and output paths. You can perform changes in the rendering settings (render time, SL, resolution, camera, etc), and these changes are applied to all the scenes added. An interesting feature is that in this mode you can choose the Batch Type, between Cooperative type (all render nodes work together in the same scene before starting with another) or Single type (each render node renders a scene separately).

   

Choose the job type

Step 5 - Specify output paths and render settings

Output paths

You have two options of specifying the output paths of your renders:

  • UNC format: this is the safest way to write the output paths. The paths are specified as a network path and the Manager can in this case save the files on any computers shared folder that is part of your network. The network path is written in the format of \\computername\myfolder\myrender.png (where "myfolder" is a shared folder on the network).
  • As standard local paths: if you specify a local path to a folder, the folder needs to be in the same computer that is running the Manager. The Add Job wizard will give you a warning that the paths are not network paths, but you can ignore this if the output folder is in the same computer that is running the Manager.

You should always specify both the image output and the MXI output paths. If the paths are the same, you can simply drag & drop the folder icon of one path over the folder icon of the other path to quickly copy it.

 

Useful information regarding paths

 Click here to expand...

For multi-platform compatibility reasons, all the network paths in Maxwell Render are in UNC format by default. Mac OSX cannot handle UNC paths natively and so some transformations are needed. These transformations cannot always be done automatically, so keep the following tips in mind to make network rendering much easier when using Mac OSX. 

  • Checking the “send dependencies” option will be faster and more reliable in most cases.

  • In a multi-platform environment, it’s preferable to use Mac OSX machines only as render nodes.

  • When launching the render from a Mac OSX machine (and if the Manager is not in the same machine as the Monitor), the output path must be understandable and accessible from the Manager machine. 

  • If the Manager is running on a Mac OSX machine, selecting a local path will save the file in the same local path (if it exists) as where the Manager is running. Using the "Retry" button of the local path warning dialog will convert this local path to a network path. This means the files will be saved in the referring path, but the selected local path must still be located in your user folder (or in any of its subfolders) or in any secondary drive. 

  • If the Manager is running on a Windows machine, you must specify a network UNC path to the MXS file, or a Windows shared folder must be selected in the dialog, which all nodes must have direct access to. If you are saving the MXI/Image output on the same computer that the Manager is running on, you can specify the MXI/Image output paths as local paths. Otherwise, if the output is ment to be saved to a different networked computer, use UNC paths for the output paths. The Manager must have access to this networked path/folder in order to save the final output. If it doesn't, the Manager log window will output a warning that it couldn't save the files to that location, and you can instead find the output in a local path specified in the Manager log window.

  • When "Send Dependencies" is not selected, you must specify a UNC path to the folder where the scene dependencies (textures, IOR, HDR, IES etc. files) are located, which all nodes must have access to. A second option would be that when you create your scenes and load textures for materials, specify HDR maps for environment lighting etc. that you load these files from a networked folder using UNC paths. So all the dependencies paths for all scene assets would already have UNC paths, in which case you don't have to specify a networked folder for these assets in the Add job wizard.

TIP: To quickly gather all the scenes dependencies into one folder, you can use the Pack & Go feature found in Maxwell Studio, and also many of the plugins. In case of Studio, simply open the MXS file, go to File>Pack & Go, and choose a folder where all the files will be copied, including the MXS file. It works in the exact same way in the plugins, please read the plugins documentation to see where this feature is located.

Frame range and Render Options

Set the frame range (for animations), and set the Render Options (Time, Sampling Level). You can also override the render options stored in the MXS file here.

   

 

Send dependencies

When this option is on, any textures and extra files (HDR, IOR, IES etc.) needed for the render are sent by the Monitor to all the Nodes. When off, each node takes the files it needs directly from a networked folder which all nodes must have direct access to. In general, it is recommended to leave this option disabled in all cases, unless you are on multi platform networks mixing OSX and non-OSX computers, when path format conflicts can arise. In pure Windows, pure OSX, pure Linux or mixed Windows / Linux networks this option should be left disabled. The differences between having this option on and off are:

  • Send dependencies OFF: In this case, any textures/files used in the MXS file must point to a network location, accessible directly by all the nodes. The benefit can be that there are no file transfers at all and the render process starts immediately, but when the render starts all the nodes have to load the MXS file and textures from a network path at the same time. This could create a bottleneck in some cases, if for example 20 nodes are eventually accessing to the same large file simultaneously. However if the file server is fast enough this option can be perfectly valid and you skip the file transfer process time. 
  • Send dependencies ON: This option is a must in mixed networks including OSX and non-OSX computers and is generally recommended. Here, the Monitor sends the MXS file and all scene dependencies to Node A. When the transfer finishes, the Monitor starts sending dependencies to Node B, while Node A sends dependencies to Node C and so one. This follows a Peer-to-Peer approach. Moreover, in animations, when most of the dependencies are the same for all the frames the Manager keeps track of which nodes already have each texture so these aren't sent again. When the render starts, each node loads the scene and its files from its local hard drive. This broadcast approach has been designed to prevent some path format conflicts that can arise when there are OSX and non-OSX computers networked together but can also optimize nodes access to textures.

 

Dependencies path

Since we recommend to have Send dependencies unchecked if you are running a network with non OSX computers, you must specify here a UNC path to a networked folder which all nodes have access to. If however Send dependencies is checked, there is no need to specify a path here - Monitor will search for the files using the paths of the textures/files already specified inside the MXS file.

There is a second scenario where you may want to specify a UNC path here - it is if the MXS file itself is still local to the Manager/Monitor, but you have moved the textures used in the MXS to a networked folder. In this case the paths specified in the MXS file will no longer be valid, and you need to specify here the new path to that networked folder.

Where Monitor searches for dependencies

The Monitor will look for textures/files in the following paths:

  • Same path as where the MXS file is.
  • Network path to the dependencies (if you have specified a dependencies path in the Add Job wizard)
  • "textures" subfolder of the path to any referenced MXM materials in your scene (ie, if your MXS contains a link to referenced material as F:\mxmfiles\gold.mxm, it will search for textures used in that material in F:\mxmfiles\textures\)
  • Preferences paths. These are the paths you can specify in Maxwell.exe preferences from File>Preferences>Paths.

 

For more details on the options in the Add Job wizard, see The Monitor page.

Step 6 - Specify the render nodes

Choose the computers you want to work in this job.
 

Assign the nodes you want to work on this job

 

You can also check the "Use any render node available" checkbox, and the Monitor will use any node in your farm as soon as they get available.
   

Render process

Once launched, the Manager sends the necessary files to the nodes, that perform the calculations. When the rendering finishes, the following steps take place:

  • The Manager sends a request to all the nodes to send their MXI files to the Manager computer
  • The Manager stores each MXI file in its temp folder (which you can specify in the Manager preferences, or it will use the default temp folder location of your system)
  • Manager calls mximerge.exe (found in the Maxwell Render install folder) which merges the node MXI files into one final MXI.
  • If merging is successful, Manager copies the final MXI file to the output paths specified in the Add Job wizard.

   

First make some simple tests in your network before attempting a real project or final rendering to ensure that all the Render Nodes can connect and the output is written properly.