Open topic with navigation

Custom Install Locations

 

This page contains information regarding all supported DCCs and operating systems.

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:


Default Paths

Windows

Core data path C:\ProgramData\Redshift
Local data path C:\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:


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.
By customizing the Redshift data paths using environment variables, a systems administrator can simplify the process so that version updates only require updating 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:

 

Windows C:\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, a plugin package must be created. This approach is new in Redshift 3.5. For older versions of Redshift, see the 3ds Max (Legacy) section.

Decide on a location for your 3ds Max plugin packages. As per Autodesk's documentation, there are a few standard locations where 3ds Max searches for plugins. For a centralized plugin deployment, the environment variable ADSK_APPLICATION_PLUGINS can specify a custom location: e.g \\server\share\Autodesk\ApplicationPlugins.

Plugin packages are created and managed with the script redshift4max_install.bat located in Redshift\Plugins\3dsMax\tools. Run this without arguments directly from Windows Explorer to learn about its syntax and available options.

The -packages option specifies where your 3ds Max plugin package(s) should be installed. The following command will create plugin packages for three separate versions of 3ds Max in the directory specified by the ADSK_APPLICATION_PLUGINS environment variable. If the current user does not have permissions to modify that directory, either run as Administrator or omit the -noelevate option.

"%REDSHIFT_COREDATAPATH%\Plugins\3dsMax\tools\redshift4max_install.bat" -packages "%ADSK_APPLICATION_PLUGINS%" -verbose -pause -skipmaxcheck -noelevate 2021 2022 2023

If the system already contains a custom 3ds Max plugin installation for Redshift versions prior to 3.5 these must be removed, as supporting Redshift DLLs installed in the 3ds Max directory can conflict with the plugin package. To remove legacy deployments of Redshift for 3ds Max on the local machine, use the options -clean and -remove followed by the target 3ds Max version(s).

"%REDSHIFT_COREDATAPATH%\Plugins\3dsMax\tools\redshift4max_install.bat" -clean -remove -verbose -pause 2021 2022

 

Note that the -clean option does not apply to 3ds Max 2023 onwards. If you have manually installed the Redshift plugin into the 3ds Max directory for versions 2023 or later, you must remove it yourself.

Advanced system administrators may prefer to use the tool redshift4max_package.bat directly. This manages only plugin packaging without the additional features provided by redshift4max_install.bat such as interactivity, cleaning legacy installations, automatic UAC elevation, checking for active 3ds Max sessions etc.

 

Prior to Redshift 3.5 (or 3.0.67 in the case of 3ds Max 2023), the Redshift plugin for 3ds Max must be installed directly into the 3ds Max application directory. Example:

set MAX_VERSION=2022

call set "MAX_ROOTDIR=%ADSK_3DSMAX_x64_%MAX_VERSION%%"

xcopy "%REDSHIFT_COREDATAPATH%\bin\*.dll" "%MAX_ROOTDIR%\" /F /Y

xcopy "%REDSHIFT_COREDATAPATH%\Plugins\3dsMax\%MAX_VERSION%\nt-x86-64\redshift4max.dlr" "%MAX_ROOTDIR%\Plugins\" /F /Y

xcopy "%REDSHIFT_COREDATAPATH%\Plugins\3dsMax\scripts\*" "%MAX_ROOTDIR%\Scripts\" /E /F /Y

3ds Max 2013 and 2014 also require Qt support files:

xcopy "%REDSHIFT_COREDATAPATH%\Plugins\3dsMax\Qt\*.dll" "%MAX_ROOTDIR%\" /F /Y


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.


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 3ds Max, you must also re-run the package installation.

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_SHAREwith 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.