Initialization and Configuration |
Introduction
Initialization files
Initialization commands
Sample ini File
Alfred.ini
.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.
RenderMan for Maya relies on several different files to ensure proper configuration:
RenderMan Studio (Maya Edition) throws a few more files into the equation:
![]()
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.
Any legal Tcl code can be used within these initialization files.
Brief sections of the $RMSTREE/etc/slim.ini file are illustrated below as examples of setting up .ini files.
if {[GetEnv SLIM_RUNMODE artist] == "developer"}
SetPref ShaderCompiler "shader -I%I %f"
} else {
SetPref ShaderCompiler "shader -I%I -nolint %f"
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.
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.
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.
|
Pixar Animation Studios
|