rayhost Server Tips

In theory, once you've installed mental ray correctly on all your server machines, all you have to do is put the name of your servers in the .rayhosts file of your main machine (the client).[Note that you may also see the terminology master host and slave hosts relating to what we'll continue to refer to as client and server, respectively.]

When setting up multiple ray hosts for mental ray, there are a couple of subtle pieces of information from Vol. 1 1.8 Parallelism and 17.6 Filename Rewriting, and Vol. 2 1.1 Parallelism which may help debug a situation that doesn't come up simply, or work correctly with your custom or 3D application-specific shaders.

To begin, let's separate the task into two parts:

1. establishing client communication with the servers, and
2. ensuring that the servers load the same shaders and declarations as the client.

Client-Server Communication

Step by step summary:

1. Use ping to verify client-server connection.
2. Put server hostnames in client's .rayhosts file.
3. Ensure identical mi-ray port numbers in all services files.
4. Reset services: kill -HUP inetd or kill -HUP xinetd

Assuming you can ping the servers, begin by putting the server hostnames, listed one line at a time, in the .rayhosts file, or maya.rayhosts file, and place this in your user directory. The ray executable looks in the current directory, or the home directory of the user. An application may specify how to get this information separately, or change the name to isolate possible conflicts, as Maya does. You can also explicity specify this on the command line for the ray executable.

After this, try a render with a verbosity level of 5, 'ray -v 5' or more. This is the equivalent of Translation->Export Verbosity->Info Messages in Maya's mental ray render globals. You should see a message connecting up the servers when the .rayhosts file is parsed. (In Maya, this is at the first time you use mental ray.) If the port connection does not work, you will see messages to that effect; so check to see that its attempting to connect on the machines and port you thought it should.

If it doesn't work, your install may not have completely finished, and you may need to do some additional work to get the communications operating properly...

To get the client to communicate with the servers, you need to ensure that the mi-ray service is communicating across the same port on all your machines. Usually, this is handled for you on install, especially for standalone. However, it is best to check, for example, your /etc/services file (in Linux land) to make sure you see an entry for mi-ray usually at the bottom of the file, and usually using tcp/7001 or tcp/7010. The number is the port number which has to be the same. If you have missed the proper install from your 3D app, this may not appear, so be sure to first check your client machine. If it is missing, it is best to refer to the spm installation notes, or relevant application specific doc regarding server setup. (If you're trying to do it manually, you can't just add the line to the /etc/services file; but you will also have to restart the inetd, or xinetd, and you'll want to set it up to come up at boot time as well.)

Shader Library and Declaration loading

Once you have the communication working, you may still have issues with loading the correct shaders (.so or .dll files) and shader declarations (.mi files). This corresponds to how mental ray passes information regarding the lookup of these files. Once the client machine determines the shader location, it passes this information along to the server machines. This means that with respect to library paths, server machines ignore the link commands in their local .rayrc files. Use caution in thinking this one out; the link commands from the client are passed "as is" to the servers, registry variables and all. The value registry command is resolved on the local machine, ie each server, to resolve variable name substitutions.

There are two ways generally used to specify shader library and declaration paths in a .rayrc. One method uses the two special registry variables {_MI_REG_INCLUDE} and {_MI_REG_LIBRARY} When a file name is enclosed in quotes without a path, the paths specified by these special variables are checked. Here is a simple example of this for Maya6:

registry "{_MI_REG_INCLUDE}"
 value "/usr/aw/maya6.0/mentalray/include;/usr/local/mi/rayinc33"
end registry

registry "{_MI_REG_LIBRARY}"
 value "/usr/aw/maya6.0/mentalray/lib;/usr/local/mi/shaders33"
end registry

link "base.so"
link "physics.so"
link "contour.so"
link "mayabase.so"

$include "base.mi"
$include "physics.mi"
$include "contour.mi"
$include "mayabase.mi"

echo "mental ray for Maya - startup done"

The other method uses more direct specifications using user- or application specified registry variables. Vol. 1 Section 17.6 Filename Rewriting shows an example of this. In addition, the default rayrc file for Maya (typically in /usr/aw/maya6.0/mentalray/on Linux) shows a fairly extensive example of the second method. As mentioned in that section, and repeating loudly a different way then it was said above, servers always get their library lists from the client. So to make it work this way, you can place the registry lookup for the variable parts of the library paths in the local .rayrc file of the server. For example if the library path is specified with "{MAYABASE}/lib/base.{DSO}" on the client, then {MAYABASE} and {DSO} should be defined correctly in the .rayrc of the server machine.

Here's what you might find in a default maya.rayrc file, for example:

registry "{MAYABASE}" value "/usr/aw/maya6.0/mentalray" end registry

registry "{SYSTEM}" value "irix" end registry
registry "{DSO}" value "so" end registry

$lookup "{MAYABASE}"
$lookup "{SYSTEM}"
$lookup "{DSO}"

registry "{MRMAYA_START}"
  link "{MAYABASE}/lib/shaveMRShader.{DSO}"
  mi "{MAYABASE}/include/shaveMRShader.mi"
  link "{MAYABASE}/lib/shaveMRGeoShader.{DSO}"
  mi "{MAYABASE}/include/shaveMRGeoShader.mi"
  link "{MAYABASE}/lib/base.{DSO}"
  link "{MAYABASE}/lib/physics.{DSO}"
  link "{MAYABASE}/lib/mayabase.{DSO}"
  link "{MAYABASE}/lib/contour.{DSO}"
  mi "{MAYABASE}/include/mayabase.mi"
  mi "{MAYABASE}/include/base.mi"
  mi "{MAYABASE}/include/physics.mi"
  mi "{MAYABASE}/include/contour.mi"
  echo "mental ray for Maya - startup done"
end registry

$lookup "{MRMAYA_START}"

This sits on the client, while on the server(s), you only need to include the registry variables {MAYABASE}, and {DSO}. The {MAYABASE} variable would point to the appropriate place on the server machine(s). For example, typically:

registry "{MAYABASE}" value "/usr/local/mi/shaders" end registry

Mixing the two above described methods between the client and the servers could get confusing. So we recommend you choose one or the other. Either, use the special registry variables with search paths that work on both the client and the server machines. Or, make sure that you use the same registry variable names on the server as are referenced by the explicit paths on the client, and that they point to where the libraries exist for the server machine.

In setting up Maya, I prefer to switch over to using the special registry variables as in the first example above. Then, making sure the search path first contains the maya specific path, such as /usr/aw/maya6.0/mentalray/include or ../shaders, add the typical standalone paths such as /usr/local/mi/rayinc or ../shaders.

Every production situation has different constraints so choose the best fit for your house.