Prev | Next

Initialization and Configuration

Initialization files
Initialization commands
Sample ini File
.rman Files


RenderMan for Maya and the other applications that comprise RenderMan Studio use a sequence of startup files to initialize preferences and Tcl based extensions. The primary reason behind having a sequence of multiple startup files is to help establish a set of program-specific parameters that are configurable among a multitude of different setups. Namely, this allows a site to specify different preferences based on group, project, user, machine, et cetera, and to share these preferences among all users of the system. By searching for and sourcing the same filename that appears in different paths one can control which settings are administrator- configurable and which can be changed based on individual user's needs. This idea is further refined by the inclusion of the LockPref and LockExtension commands. Using these guarantees that certain program settings can always be counted on at the beginning of program execution.


Initialization Files

RenderMan for Maya relies on several different files to ensure proper configuration:

This is the primary initialization file, containing the fundamental settings.
This initialization file is essential for establishing shared initialization states between the various tools included with RenderMan Studio, but it also sets the “asset strategy” for RfM, defining the directory structure for RenderMan data, shaders, textures, and outputs.
This script is references by the RMS.ini file and does the bulk of the hard work for defining the aforementioned initialization state.

RenderMan Studio (Maya Edition) throws a few more files into the equation:

This is essentially a supplement to the RenderMan_for_Maya.ini file, containing the initialization settings for the “Pro” features of the plugin, e.g. RIB generation, protocols for the accompanying tools, et cetera.
The RAT.ini file is used to set certain shared preferences that are not handled by the RfM and RfM Pro ini files, including, most inmportantly, licensing preferences.
The Slim.ini controls Slim-specific preferences.
The alfred.ini provides configuration settings and default user preferences for Alfred.
The it.ini sets your it-specific preferences.

All of these settings and files are site-configurable, but we highly recommend that, rather than editing the file in your installation directory ($RMSTREE/etc), you create a duplicate file containing your site-specific overrides and place it in a separate directory, referenced via an $RMS_SCRIPT_PATHS environment variable.

All RenderMan_for_Maya.ini files are loaded, followed by all RenderMan_for_Maya_Pro.ini and RMS.ini files, and finally all appname.ini files.


Initialization Commands

General Commands:
Initialization Commands:
1.2 alfred.ini
1.3 it.ini
1.4 slim.ini

Any legal Tcl code can be used within these initialization files.


Sample ini File

Brief sections of the $RMSTREE/etc/slim.ini file are illustrated below as examples of setting up .ini files.

LoadExtension tcl [file join [RATGetDir etc] SlimExpression.tcl]
loads the "tcl" extension "SlimExpression.tcl" into SLIM; uses the RATGetDir command to get the location of "SlimExpression.tcl"
	if {[GetEnv SLIM_RUNMODE artist] == "developer"}
		SetPref ShaderCompiler "shader -I%I %f"
	} else {
		SetPref ShaderCompiler "shader -I%I -nolint %f"
checks the system environment variable SLIM_RUNMODE to determine user specific settings of preferences for ShaderCompiler.
SetPref ExpertMenus 0
sets the pref ExpertMenus to 0 (this setting will be overridden by any subsequent call to SetPref ExpertMenus
LockPref ROColor #8080a0
set and lock the value of ROColor to #8080a0. This will be the value of ROColor upon start of the application

During the initialization process, the same preference can be set multiple times (possibly using different values). As long as the preference is not set with LockPref, then the value of the preference will be that of the last call to SetPref. If the preference is set with LockPref somewhere within the hierarchy of files, all modifications after that setting will be ignored.



Settings in alfred.ini should be reviewed by a system administrator, especially with regard to site security. The default values here have been chosen to be generally useful, although most multi-user sites will want to name, and initialize, an alfred maitre-d host.

The notes accompanying each configuration variable are intended to be self-explanatory, but they do assume a familiarity with the basic alfred concepts and vocabulary.

In addition to the alfred.ini file, the alfred.schedule file contains the (crucial!) remote server definitions. See the notes on scheduling and remote servers for detailed information.

See the Alfred Site Administration Notes for information on installing and configuring some of the more esoteric alfred features such as:

For a discussion of overall installation issues, including the license manager, see the RenderMan Toolkit installation notes.

Scheme Files

Similar to .ini files.  Scheme files are used by RAT to define the look of the apps and to define mouse and keyboard events.  Scheme files are sourced in the same manner and use the same search paths as .ini files.

RAT.scheme - all RAT applications load this
$appname.scheme - only $appname loads this

Event commands: define and manipulate virtual events

The Event singleton object maintains an internal database of virtual event definitions. These definitions can be combined and used to create actual events using Tk's event command.

Event define <event> <binding>- Define a new virtual event.
Event exists <event>- Returns 1 if the event exists, 0 otherwise.
Event forget <event>- Removes an event from the internal database.
Event lookup <event>- Lookup the binding for a previously defined event.

The Event singleton object can also be used to do maintenance on Tk's event system, here are the relevant methods:

Event add <event> <binding>- Add a new binding to an event.  This will append the binding to the end of the list of all. bindings previously defined for this event. 

Event set <event> <binding>- Replace all bindings to an event with a new binding.
Event info <event>- Returns all the current bindings for the given event, if any
Event delete <event>-Removes an event

Options commands: define and manipulate window options

Option define <option> <value>- Define a new window option.
Option lookup <option>- Lookup a previously defined window option.
Option add <option> <value>- Add a new value to a window option. 


Prev | Next



Pixar Animation Studios
Copyright© Pixar. All rights reserved.
Pixar® and RenderMan® are registered trademarks of Pixar.
All other trademarks are the properties of their respective holders.