Table of Contents


The information on this page is intended for advanced users. Customizing paths incorrectly will result in Redshift being unable to run correctly.

This section describes the various options available to customize the location of Redshift binaries and data files. This can be used to facilitate centralized deployments or to support side-by-side installation of more than 1 version of Redshift on a single machine.

Paths

The following paths are used by Redshift:

  • Plugin Path – the path containing the Redshift DCC plugin.
  • Core Data Path – the top-level path containing the core Redshift data files, including the shader binaries and other GPU kernels. This path can be safely shared between multiple machines in a centralized deployment scenario.
  • Local Data Path – the top-level path containing the Log directory and the default location for the license and preferences files. This file should not be shared between multiple machines.
  • Procedurals Path – the search path for Redshift procedurals
  • Preferences File Path – the full path to the preferences xml file.
  • License Path – the path to scan for license files.

Default Paths

Windows

Core data pathC:\ProgramData\Redshift
Local data pathC:\ProgramData\Redshift
Procedurals path<core data path>\Procedurals
License path<local data path>
Preference file path<local data path>\preferences.xml
Log file path<local data path>\Log

Linux

Core data path/usr/redshift
Local data path~/redshift
Procedurals path<core data path>/procedurals
License path<local data path>
Preference file path<local data path>/preferences.xml
Log file path<local data path>/log

macOS

Core data path/Applications/redshift
Local data path~/redshift
Procedurals path<core data path>/procedurals
License path<local data path>
Preference file path<local data path>/preferences.xml
Log file path<local data path>/log

The default behavior described above can be overridden and customized either by setting environment variables, or via a path configuration XML file, as explained below.

Customizing Paths Using Environment Variables

The following environment variables, when set, will override the defaults listed above:

  • REDSHIFT_COREDATAPATH – overrides the Core Data Path
  • REDSHIFT_LOCALDATAPATH – overrides the Local Data Path
  • REDSHIFT_PROCEDURALSPATH overrides the Procedurals Path
  • REDSHIFT_PREFSPATH – overrides the Preferences File Path (full path, including file name to the preferences.xml file)
  • REDSHIFT_LICENSEPATH – overrides the License Path (primary search path for license files)

Example: Centralized Deployment

In environments where Redshift is deployed onto many machines, it can become a burden to run the Redshift installer on each machine every time a new version is released (typically every few days).
By customizing the Redshift data paths using environment variables, a systems administrator can greatly simplify the process such that version updates require only to update a single shared network location.

Running Redshift from a centralized network share involves 1) collecting the necessary files onto the centralized network share, 2) configuring the Redshift core to read its data files from the network share, and 3) configuring each host application (Maya, 3ds Max, etc...) to find the appropriate Redshift plugin and its dependencies.

Collecting necessary files

The simplest way to collect the files required by Redshift onto your network share is to run the Redshift installer for your particular platform and copying the files manually to a new location.  After running the installer, the necessary files will be located in the following path:

WindowsC:\ProgramData\Redshift
Linux/usr/redshift
macOS/Applications/redshift

Simply copy the contents of the path above (for your particular platform) to your centralized network share.

Configuring the Redshift core

The next step is to configure the Redshift core to look for its data in your network share.  You do this by defining the environment variable REDSHIFT_COREDATAPATH on each render machine.  For example, if you collected the necessary files in //server/share/Redshift, you would set REDSHIFT_COREDATAPATH to //server/share//Redshift.  Specific instructions on how to set environment variables is beyond the scope of this document, but should be well known to system administrators.

Configuring host applications

Once the Redshift core has been configured as described above, you will need to configure your host application(s) to find the appropriate Redshift plugin(s) on your network share.  The steps required are host application-specifc and descibed below.

Maya

To configure Maya to find the redshift4maya plugin on your network share, create a Maya module file as shown below (modify Maya version as necessary) and place it somewhere in Maya's module search paths.  To share the Maya module from a central location, you can define the environment variable MAYA_MODULE_PATH (on each render machine) to point to a network share.  Alternatively, the module file may be copied to each render machine.

Windows

+ MAYAVERSION:2017 redshift4maya any %REDSHIFT_COREDATAPATH%
scripts: Plugins/Maya/Common/scripts
icons: Plugins/Maya/Common/icons
plug-ins: Plugins/Maya/2017/nt-x86-64
MAYA_CUSTOM_TEMPLATE_PATH +:= Plugins/Maya/Common/scripts/NETemplates
REDSHIFT_MAYAEXTENSIONSPATH +:= Plugins/Maya/2017/nt-x86-64/extensions
REDSHIFT_PROCEDURALSPATH +:= Procedurals
PATH +:= bin

Linux and macOS

+ MAYAVERSION:2017 redshift4maya any $REDSHIFT_COREDATAPATH
scripts: Plugins/Maya/Common/scripts
icons: Plugins/Maya/Common/icons
plug-ins: Plugins/Maya/2017/nt-x86-64
MAYA_CUSTOM_TEMPLATE_PATH +:= Plugins/Maya/Common/scripts/NETemplates
REDSHIFT_MAYAEXTENSIONSPATH +:= Plugins/Maya/2017/nt-x86-64/extensions
REDSHIFT_PROCEDURALSPATH +:= Procedurals
PATH +:= bin


3ds Max

To configure 3ds Max for use with a centralized Redshift installation, you will need to copy files from the network share to the 3ds Max installation folder on each machine.  The following shows an example of how to accomplish this from the command line (for 3ds Max 2018, modify as necessary for other versions). Note that these commands need to be run on each render machine, and may require Administrator privileges (in order to write to the 3ds Max installation folder).

copy /Y "%REDSHIFT_COREDATAPATH%\Plugins\3dsMax\2018\nt-x86-64\redshift4max.dlr" "%ADSK_3DSMAX_x64_2018%\plugins\"
xcopy /Y "%REDSHIFT_COREDATAPATH%\Plugins\3dsMax\scripts\*" "%ADSK_3DSMAX_x64_2018%\scripts\" /e /h /f
copy /Y "%REDSHIFT_COREDATAPATH%\bin\redshift-core-vc100.dll" "%ADSK_3DSMAX_x64_2018%\"
copy /Y "%REDSHIFT_COREDATAPATH%\bin\OpenImageIO-1.6.17-vc100.dll" "%ADSK_3DSMAX_x64_2018%\"

Additional files required for Redshift version 2.6.x and above:

copy /Y "%REDSHIFT_COREDATAPATH%\bin\altus-api.dll" "%ADSK_3DSMAX_x64_2018%\"
copy /Y "%REDSHIFT_COREDATAPATH%\bin\cudnn64_7.dll" "%ADSK_3DSMAX_x64_2018%\"
copy /Y "%REDSHIFT_COREDATAPATH%\bin\cudart64_90.dll" "%ADSK_3DSMAX_x64_2018%\"
copy /Y "%REDSHIFT_COREDATAPATH%\bin\optix.51.dll" "%ADSK_3DSMAX_x64_2018%\"
copy /Y "%REDSHIFT_COREDATAPATH%\bin\optix_denoiser.51.dll" "%ADSK_3DSMAX_x64_2018%\"

Softimage

Set up a workgroup on each machine to a shared network location (or use an existing shared workgroup).  Next install the appropriate Redshift .xsiaddon to the shared workgroup (this step only needs to be done on one machine).

An alternative to manually installing the Redshift .xsiaddon to the shared workgroup is to use the xsiaddonExtractor tool to extract the contents of the xsiaddon to a folder of your choice.

The syntax is:

xsiaddonExtractor.exe [--output <extraction destination path>]

Note that the --output argument is optional.  If omitted, the addon will be extracted to the current directory.

Examples

This will extract the contents of redshift4softimage2014.xsiaddon to the Tools directory (where xsiaddonExtractor.exe lives).

xsiaddonExtractor.exe ..\Plugins\Softimage\redshift4softimage2014.xsiaddon

This will extract the contents of redshift4softimage2014.xsiaddon to the network folder \\server\share\RedshiftWorkgroup\Addons\Redshift

xsiaddonExtractor.exe --output \\server\share\RedshiftWorkgroup\Addons\Redshift ..\Plugins\Softimage\redshift4softimage2014.xsiaddon

Some additional files must be copied for Redshift versions 2.6.x and above:

set REDSHIFT_ADDON_BIN_DIR = \\server\share\RedshiftWorkgroup\Addons\Redshift\Application\Plugins\bin\nt-x86-64
copy /Y "%REDSHIFT_COREDATAPATH%\bin\altus-api.dll" "%REDSHIFT_ADDON_BIN_DIR%\"
copy /Y "%REDSHIFT_COREDATAPATH%\bin\cudnn64_7.dll" "%REDSHIFT_ADDON_BIN_DIR%\"
copy /Y "%REDSHIFT_COREDATAPATH%\bin\cudart64_90.dll" "%REDSHIFT_ADDON_BIN_DIR%\"
copy /Y "%REDSHIFT_COREDATAPATH%\bin\optix.51.dll" "%REDSHIFT_ADDON_BIN_DIR%\"
copy /Y "%REDSHIFT_COREDATAPATH%\bin\optix_denoiser.51.dll" "%REDSHIFT_ADDON_BIN_DIR%\"

Cinema 4D

Cinema 4D supports loading plugins from an additional location specified via the g_additionalModulePath environment variable or parameter. This can be directed to a network location where the Redshift plugin for the appropriate version of Cinema 4D can be copied.

For example we could set the g_additionalModulePath environment variable to \\server\share\C4D_PLUGINS_R25 and then proceed to copy the R25 Redshift plugin folder to this location.

To prevent issues with incorrect installations, the plugin will not load if the version of the Redshift core does not match the expected version. Furthermore it will also refuse to load if multiple instances are detected in more that one Cinema 4D plugin location. When either of these conditions occur, the following message will be displayed in the Cinema 4D Console window and log:

Redshift: Plugin initialization failed. Please ensure that Redshift has been installed correctly and it matches this version of the plugin.

In that case, please verify that only one Redshift plugin is found in Cinema 4D's plugin paths, and that the correct version of the Redshift core can be located by the plugin via the Redshift-specific environment variables (REDSHIFT_COREDATAPATH etc.) or via the path configuration XML file.


Houdini

To configure Houdini to find the redshift4houdini plugin on your network share, you need to add the path to the redshift4houdini plugin to the HOUDINI_PATH environment variable on each render machine.  This can be accomplished by setting system environment variables, or by modifying the houdini.env file.  On Windows, you will also need to add the path to the Redshift core dlls to the system PATH environment variable in order for redshift4houdini to find its dependencies.  We also recommend defining the variable HOUDINI_DSO_ERROR and setting its value to 2.  Examples are shown below for Houdini 16.0.705.  Modify as necessary depending on the version of Houdini you are running.

When defining variables in the houdini.env file, you should use Linux style syntax for environment variables and path separators, regardless of your platform.


Example houdini.env file on Windows

HOUDINI_DSO_ERROR = 2
HOUDINI_PATH = "$REDSHIFT_COREDATAPATH/Plugins/Houdini/16.0.705;&"
PATH = "$REDSHIFT_COREDATAPATH/bin;$PATH"

Example houdini.env file on Linux and macOS

HOUDINI_DSO_ERROR = 2
HOUDINI_PATH = "$REDSHIFT_COREDATAPATH/redshift4houdini/16.0.705;&"


Note the trailing semicolon ';' and ampersand '&' characters. These are important to allow Houdini to find its own native plugins.

Note the trailing semicolon ';' and ampersand '&' characters. These are important to allow Houdini to find its own native plugins.

Katana

To configure Katana to find the redshift4katana plugin on your network share, you need to add the path to the redshift4katan plugin to the KATANA_RESOURCES environment variable on each render machine.  This can be accomplished by setting system environment variables, or by modifying the Katana launcher.

On Windows, you will also need to add the path to the Redshift core dlls to the system PATH environment variable in order for redshift4katana to find its dependencies.  Similarly, on Linux, you may need to modify the LD_LIBRARY_PATH to point to the Redshift core libraries.

We also recommend defining the variable DEFAULT_RENDERER and setting its value to Redshift.  Examples are shown below for Katana 2.6v1.  Modify as necessary depending on the version of Katana you are running.

Example variables to add to the Katana launcher script on Windows

set "PATH=%REDSHIFT_COREDATAPATH%/bin;%PATH%"
set "KATANA_RESOURCES=%REDSHIFT_COREDATAPATH%/Plugins/Katana/2.6v1;"
set "DEFAULT_RENDERER=Redshift"

Example variables to add to the Katana launcher script on Linux

#render plugins
export LD_LIBRARY_PATH="${REDSHIFT_COREDATAPATH}/bin:${LD_LIBRARY_PATH}"
export KATANA_RESOURCES=${REDSHIFT_COREDATAPATH}/redshift4katana/katana2.5v4
export DEFAULT_RENDERER=Redshift

Updating a centralized installation

To update a centralized Redshift installation to a new version, you simply replace the contents of the network share with new files. For Softimage, you also need to replace the existing Redshift addon files in the shared workgroup either by installing the appropriate .xsiaddon to the shared workgroup on 1 machine, or by using the xsiaddonExtractor.exe tool included with Redshift.

Customizing Paths Using a Path Configuration XML

As an alternative to using environment variables, the various Redshift paths can also be customized by placing a file named pathconfig.xml in the same folder as the Redshift plugin being loaded by the host application. This technique is useful for tying the path configuration to a particular plugin location, thereby making the process of switching between versions of Redshift on a particular version of your host application as simple as configuring the plugin location.

The format of pathconfig.xml is very simple. It should contain 1 or more lines of the following form:

<path name="PATH_VARIABLE" value="//server/share/path" />

For example, to set the REDSHIFT_COREDATAPATH to //server/share/rs-core-data-path , you would include the line:

<path name="REDSHIFT_COREDATAPATH" value="//server/share/rs-core-data-path" />

It is not necessary to set all variables in the xml file. You can, for example, only set REDSHIFT_COREDATAPATH and omit the others, which would result in default behavior for all paths except the core data path.

Note

Path values support environment variable expansion. I.e. if you already have an environment variable named SERVER_SHARE with a value //server/share , you could set a value in the xml as %SERVER_SHARE% (windows) or $SERVER_SHARE (Linux/macOS)

Path Resolution Rules

The various paths are resolved by first checking for a pathconfig.xml entry, then checking for an environment variable, then using a default value: