<     > 

Setting Up For Distributed Rendering

To set up distributed rendering for XSI, several steps must be followed before and after the program is installed.

In a network rendering setup, whichever computer initiates the render (the master) oversees the organization of the images to be rendered and distributes the rendering tasks among the other computers in the setup (the slaves). This is accomplished through the use of the ray3hosts and linktab text files.

• The ray3hosts file identifies the computers that will participate in distributed renders.

The ray3hosts file must be created on the master computer.

• The linktab file is used to coordinate sharing resources when rendering on a network that uses a mix of Windows and other operating systems.

The linktab file must be created on every computer that will be part of the distributed rendering setup.

For the master to properly communicate with the slaves, each computer should have the same version of the mental ray rendering software installed and use the same TCP/IP port number. In cases where both Satellite and Standalone distributed rendering are configured, each service should be using the same port number on every computer.

It is particularly important to use the same TCP/IP port number if you are distributed rendering across different platforms. Any port number greater than 1024 is recommended.

The master should have more memory than the slave computers and as much virtual memory as possible.

Installing mental ray

To install mental ray on a computer designated for distributed rendering, you simply choose the Render Slave option during the Setup process, choose the type of distributed rendering you wish to configure (Satellite or Standalone), and set the TCP/IP port number for the mental ray service. The setup automatically installs all the mental ray software files and sets the necessary services and configuration files that enable proper communication with the mental ray renderer.

See Render Slave Installation and Choosing a TCP/IP Port for Distributed Rendering in the Setup & Licensing guide.

Defining a .ray3hosts File

The .ray3hosts file identifies the computers that will participate in distributed renders. If a rayhosts file does not already exist, it is automatically created during the Setup process and written to the %Systemdrive%\users\%username%\Softimage\XSI_6.01 directory. This file must reside on the computer designated as the master.

The .ray3hosts file contains a list of the computers that can participate in distributed rendering (not including the master) and the port numbers they use for the mental ray service.

Each computer must be listed by name on a separate line, optionally followed by a colon and the port number you want mental ray to use on that computer. If no port number is listed for a given computer, that computer will use the port defined in its MI_RAY3_SERVICE variable.

Any line preceded by a hash (#) symbol is considered a comment and ignored by SOFTIMAGE|XSI.

Here’s a sample .ray3hosts file:

# The first three computers are always part of the
# render network.  The last computer listed is only
# used for overnight renders; remove the # to make
# it available.
larry:7003
moe:7003
curly:7003
# shemp:7024

The .ray3hosts file must be present on the master computer, as specified by the MI_RAY_HOSTSFILE environment variable. MI_RAY_HOSTSFILE can specify both the path and file name or just the path; if no file name is explicitly set, XSI searches for .ray3hosts first, then .rayhosts.

If you are importing scenes from SOFTIMAGE|3D, you can set MI_RAY_HOSTSFILE to point to your existing .rayhosts file.

Depending on your network settings, it can take up to several minutes for a computer to tell mental ray that a host does not answer, so be sure to modify your .ray3hosts file if you know that certain computers are down.

Defining a .ray3hosts File for Satellite and Standalone

Satellite and Standalone distributed rendering both use the same .ray3hosts file. If you configured both types at setup time, and intend to switch between the two, you should modify your .ray3hosts file accordingly.

Each render slave should be listed twice in the .ray3hosts file—once with its Satellite port number and once with its Standalone port number. To switch between the two, you can comment out the entries for the service that you’re not using.

A dual-use .ray3hosts file should look something like this:

# The render network uses port 7004 for Satellite
# and port 7040 for Standalone. Remove the # from one
# set and add it to the other to switch distributed
# rendering types.
#Satellite
groucho:7004
harpo:7004
zeppo:7004
chico:7004
#Standalone
#groucho:7040
#harpo:7040
#zeppo:7040
#chico:7040

Defining the linktab File

The linktab file is used when the render network uses a mix of Windows and other operating systems. Each line in a linktab file contains a Windows-style path and a UNIX-style path, indicating where XSI or resources such as textures are located on both operating systems. This allows the rendering master to find required files on slaves regardless of operating system.

Most linktab file contain only one line, indicating where XSI is located on both platforms. Here’s a sample linktab file:

C:\Softimage     /usr/Softimage

• The Windows path must come before the Unix-style path and they must be separated by a tab, not spaces.

• Linux path names are case-sensitive, but Windows paths are not (they are case-insensitive).

• Do not use slashes (\ or /) at the end of the linktab paths.

• If you are using textures or memory-mapped images, you must have entries that point to the directories containing them.

• You can use an exclamation mark to distinguish a mounted volume from the rest of the path. For example, if \\foobar\users\fred (Windows) is equivalent to /home/fred (Linux) and F:\foobar\users is a mounted volume, the line in the linktab file would look like this:

   \\foobar\users!fred     /home/fred

The linktab file must be present on the master and slave computers, in the directory specified by the SI_LINKTAB_LOCATION environment variable.

• SI_LINKTAB_LOCATION can define both the path and file name or just the path; if no file name is explicitly set, XSI assumes the name will be linktab.ini.

• When a scene is imported from SOFTIMAGE|3D into XSI, XSI searches in SI_LOCATION for linktab.ini. Define SI_LOCATION in setenv.bat (Windows) or .xsi_6.01 (Linux) as the directory where XSI is installed and place a copy of linktab.ini there (if you want to reuse the linktab file used by SOFTIMAGE|3D; otherwise, just make SI_LOCATION point to the same path and linktab name as defined by SI_LINKTAB_LOCATION for XSI).

For details on how XSI uses the linktab file, see Configuring the linktab.ini File in the Setup & Licensing Guide.

Environment Variables for Distributed Rendering

This section lists the environment variables required for distributed rendering. Unless otherwise noted, these variables are automatically set during installation in the environment script (setenv.bat on Windows and .xsi_6.01 on Linux).

• SPM_HOST must be set to the computer name or IP address of the computer running the SPM license server software. For example:

SPM_HOST=192.168.1.50
SPM_HOST=buzzgoodhost

SPM_HOST is set in the environment script during setup.

• MI_ROOT defines the location of the ray3rc file.

The default location is the Application/rsrc subfolder of the directory specified by SI_HOME. MI_ROOT is set in the environment script during setup.

On Linux it is also set in ray3.sh which is called during distributed rendering.

• SI_HOME must be set to the directory in which XSI is installed.

SI_HOME is set in the environment script during setup.

• SI_LINKTAB_LOCATION points to the location of the linktab.ini file.

If the linktab file is not named linktab.ini, you must also include the file name.

• If you are importing scenes from SOFTIMAGE|3D into XSI, set SI_LOCATION to point to the location of the linktab.ini file.

• MI_RAY_HOSTSFILE defines the location and name of the .ray3hosts file on the master computer.

For details on how to define the various environment variables used by XSI, see the Environment Variable Reference.

Managing the mental ray Services

The mental ray service name is based on the version of mental ray that ships with XSI. The version number specified in the documentation may differ from the actual version of mental ray that you are using.

The raysat3_5_7_12server or ray3_5_7_12server services must be running on each slave computer for it to connect to the master. This is usually an automatic process, but you may need to perform some operations manually when troubleshooting.

For example, from the XSI command prompt type:

raysat3_5_7_12server /stop

This stops the raysat3_5_7_12server service on the current machine.

You can run the raysat3_5_7_12server and/or ray3_5_7_12server executables from an XSI command prompt with the following options:

Using Custom Shaders with Distributed Rendering

If you have a renderfarm set up and your scene uses custom shaders, it is crucial that each machine in the renderfarm uses the same version of each custom shader.

Although you can install custom shaders on every machine in your renderfarm, it is quicker and easier to install them to a workgroup path to which all render slaves are pointing.

• In an XSI interactive setup, where all of the render slaves have XSI installed, you can install your custom shaders as part of an add-on.

• Render slaves using the mental ray standalone do not recognize XSI add-on files (*.xsiaddon).

Installing Custom Shaders to Workgroups

The best way to ensure that all of your renderfarm machines are using the same custom shaders is to copy the shaders to a shared workgroup location. The advantage to using a workgroup location is that the ray3rc file loads workgroup shaders last, so the render slaves will find and use the custom shaders.

For this approach to work, the following requirements must be met:

• Every render slave’s raysat3_5_7_12server or ray3_5_7_12server service must be logged in using the same user name and password (see below). Because the workgroup path is set for the user, every render slave will point to the same workgroup path.

The best thing to do is create a user account specifically for rendering. This user must have administrative privileges and have access to the shared workgroup directory.

• The custom shaders must be in a shared directory to which the render user has access. A good approach is to use a shared directory on a server (such as \\SERVER\share\addons directory). XSI does not have to be installed on the same machine as the shared directory.

To run raysat3_5_7_12server or ray3_5_7_12server as a specific user (Windows systems)

The mental ray service name is based on the version of mental ray that ships with XSI. The version number specified in the documentation may differ from the actual version of mental ray that you are using.

On each render slave where XSI is installed, do the following:

1. Edit the raysat3_5_7_12server or ray3_5_7_12server service’s properties from the Windows Management Console.

To open the console, right-click the My Computer icon and choose Manage from the menu. The management console opens, from which you can select Services and Applications > Services to display a list of services on your machine.

2. Right-click the raysat3_5_7_12server or ray3_5_7_12server service and choose Properties from the menu.

3. From the Log On tab, specify that the service should log on using a particular account.

4. Enter the user name and password for the rendering user account.

5. Close the management console. Log off the render slave and log back on using the render account’s username and password.

6. Open an XSI command prompt and set the workgroup path using the following command.

xsi -w workgrouppath

Now, whenever the raysat3_5_7_12server or ray3_5_7_12server is called, it renders under the specified user and uses the workgroup path set for that user.

To maintain a custom shader workgroup

To keep your distributed rendering setup working smoothly, you can use the following process to test, upload, and update your custom shaders.

If you need to update your custom shaders, you can test the updates locally, back up the shader in the workgroup directory on the server, and promote the updated shader to the server.

1. Create the custom shader locally.

2. Install the shader locally under “user” and test that it works.

3. If the shader works correctly, copy it to the workgroup directory using the following command:

xsi -i myshader -dest workgroup

On startup the shader directories are scanned for new or removed shaders and a current list of shaders is kept in a file on disk.

If you are updating shaders in the workgroup directory, make sure that all of the render slaves have stopped rendering. Otherwise, the shaders may be locked by one of the slaves and the copy process will fail.

Window systems allow you to run commands according to a schedule using the “at” command. Using this command with the “net start” and “net stop” commands lets you specify when the raysat3_5_7_12server or ray3_5_7_12server service stops and restarts on each render slave. This makes it easy to create a window of time during which you can upload updated shaders.

Installing Custom Shaders to the Local Factory Path

If you want to install a custom shader locally, it is recommended that you use add-ons.

1. Install your custom shader on a machine using the following command from the XSI command prompt:

xsi -i blah.spdl

2. Repackage the shader as an add-on. For more information about creating add-ons, see Sharing and Managing Customizations in the Customization guide.

3. Install the add-on on each of the machines in the distributed rendering network using the following command from the XSI command prompt:

xsi -i blah.xsiaddon -dest factory

This installs the add-on in the machine’s Factory path instead of its User path.

SOFTIMAGE|XSI v.6.01     <     >