# Installation

The Yeti distributions consists of two main components; the Maya plug-in which is used for building Yeti graphs, grooming and simulation - and the rendering extensions which are used by the various rendering engines to evaluate the graph at render time.

## Yeti Documentation

By default Yeti will try and access on-line documentation via the UI based help tools - if YETI_DOCS exists it will check this location first for a local copy of the documentation.

## Maya Plug-in Configuration

Yeti’s distribution takes advantage of Maya’s Module scheme, where a single .mod file located in the installation root can be used to define the location of all plugins, scripts and icons needed ot use Yeti. Once you have extracted Yeti to the location of your choosing there are two quick steps that need to be followed to make sure Yeti can be used properly within Maya.

1. You will need to edit the pgYetiMaya.mod file and replace path_to_yeti_root with the full path to the Yeti root directory ( which is most likely the directory the file is in )

and then

2. set the environment variable MAYA_MODULE_PATH to point to the directory when the previously edited .mod file resides

When Maya loads you will be able to load the plug-in from Maya’s plug-ins window by selected pgYetiMaya.so/dylib/dll from the plug-ins manager. This is the only plugin you will need to worry about loading, all of the other extensions will be loaded automatically when required.

Note

On Windows be sure that the Yeti bin directory has been added to your PATH environment variable.

## Rendering Plug-in Configuration

Yeti ships with support for multiple rendering engines, due to the difference in the way each of these renderers have been integrated into Maya as well as how they resolve dependencies each one may need to be configured differently and may require multiple environment variables to be set.

Note

If you are unfamiliar with the process of setting environment variables for your specific platform here are some resources for Windows and OSX - if using Linux you should add these to your .tcshrc, .cshrc or .bashrc files depending on what Shell you’re using.

### 3Delight Studio Pro

Yeti uses both a procedural DSO for rendering Yeti cache files as well as integrating into 3Delight Studio Pro.

The 3delight extension must be included in the procedural search path which can either be set in your rendermn.ini file or by setting the `DL_PROCEDURALS_PATH` environment variable. If you’d prefer not to set these for some reason you can also make sure your 3Delight for Maya ( or other rib generation software ) adds the search path option to the rib files.

The 3Delight Maya translator also needs to be told how to interpret the custom Yeti shapes when generating rib files to be able to output the neccesary information for render Yeti caches. We provide a very generic set of Mel commands that does this for you in `pgYetiDL.mel` - this Mel script defines the required `DL_userGetGeoTypeData` and `DL_pgYetiMayaCanUseObjectInstance` global procedures as described in the 3delight manuals, if Yeti is the only procedural shape you are using it is safe to source this file directly.

If you have other custom shapes you will need to integrate the settings from our supplied `pgYetiDL.mel` file in the one used by your studio.

If in doubt, it’s probably safe to use `source pgYetiDL;` before rendering.

On OSX you may need to set DYLD_LIBRARY_PATH to 3Delights /lib directory if the renderer complains it can’t load lib3delight.dylib - whether or not this is correctly set depends on your 3delight installation and how you have launched Maya which can vary between platforms and installations.

### Pixar’s Photo Realistic Renderman and Renderman For Maya Pro

Rendering with PRMan and Renderman For Maya Pro is straight forward, the main installation concern is to make sure you have the Yeti DSO in the Procedural search path.

Note

Windows Users - a different version of the Yeti DSO has to be used when rendering internally to RMS than when using PRMan, please make sure your RMS path is set to /bin/rms

There are two ways of doing this, via the RMSWorkspace.ini file for Renderman For Maya and/or the rendermn.ini file.

If you want to edit the RMSWorkspace.ini file you need to update the WSSearchPaths.procedural preference to include the path where Yeti is installed. Open RMSWorkspace.ini and change

`SetPref WSSearchPaths.procedural [list \\\${RMSTREE}/lib/plugins @]`

to

`SetPref WSSearchPaths.procedural [list \\\${RMSTREE}/lib/plugins @ {/Applications/Peregrine Labs/Yeti 1.0/bin} ]`

If you have spaces in the path you need to include curly braces, you can also use environment variables but they have to be prefaced with slashes, for example:

`SetPref WSSearchPaths.procedural [list \\\${RMSTREE}/lib/plugins @ \\\$OUR_PROCEDURAL_LOCATION ]`

to update your rendermn.ini it’s just a matter of adding the path to the proceduralpath option, like

`/proceduralpath .:@:"/Applications/Peregrine Labs/Yeti 1.0/bin"`

and any instance of PRman should be configured correctly.

Please refer to the PRMan documentation “Using Procedural Primitives in PhotoRealistic RenderMan” for cross platform installation solutions.

### Chaos Group V-Ray

To render Yeti graphs using the supplied VRay plugins you first need to make sure that VRay will be able to find the appropriate binaries, to support rendering in both Maya and standalone you will need to append the bin directory in the Yeti installation path to the `VRAY_FOR_MAYA2012_PLUGINS_x64` and `VRAY_PLUGINS_x64` environment variables.

Warning

Be sure to append these to the paths already set or else VRAY will cease to function correctly.

Once the environment variables have been set your Yeti nodes will be rendered as expected, Yeti supports all shader assignments and is meant to be used with Chaos Groups supplied hair and fur shaders.

Note

On Windows be sure that the Yeti bin directory has been added to your PATH environment variable.

### Solid Angle’s Arnold

To render Yeti graphs using the supplied Arnold plugins you first need to make sure that Arnold will be able to find the appropriate binaries, to support rendering in both Maya and standalone you will need to set `MTOA_EXTENSIONS_PATH` to point to the plug-ins directory. You will then have to tell Arnold how to find the Yeti procedural by specifying the Yeti bin path in the Procedural Path parameter of the Arnold render globals or make sure the Yeti bin directory has been added to your LD_LIBRARY_PATH/DYLD_LIBRARY_PATH environment variables.

Warning

be sure to append these to the paths already set or else Arnold will cease to function correctly.

Once the environment variables have been set you’re Yeti nodes will be rendered as expected, Yeti supports all shader assignments and is meant to be used with Solid Angle’s supplied hair and fur shaders.

## Environment Variables

YETI_HOME - the root directory of the Yeti installation

YETI_DOCS - used to specify the location of the Yeti documentation, if not available on-line docs will be used.

YETI_TMP - let’s you specify where Yeti will store intermediate files. When Yeti renders it will cache out a temporary file that the rendering DSO will use to generate data - generally you will want these to go into a directory that will be purged often, by default this is a yeti/tmp directory within your projects root directory.

YETI_INTERACTIVE_LICENSE - if set to 0 it will force Yeti to avoid checking out an interactive license, if it doesn’t exist or set to 1 it will allow it.

PEREGRINE_LOG_FILE - can be used to specify a log file to store Yeti’s console output, this is a full absolute path.

RLM_LICENSE - used to specify the machine to be used as a license server, port@servername - ie. 5053@licenseserver