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 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:
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.
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_COREDATAPATHon 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.
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. Information about the syntax and the available options can be printed by running these without any arguments directly from Windows Explorer.
redshift4max_install [options] version [version [...]]
Arguments:
version
The version of 3ds Max to install, as a year number only (e.g. 2022).
Options:
-clean
Remove plugin files installed prior to Redshift 3.5.
-help
Show extended help.
-interactive
Enables interactive prompts
-noelevate
Do not attempt UAC elevation if insufficient privileges detected.
-name str
The name template for the package directory to create. The characters #### will be substituted with the 3ds Max version. When installing multiple versions at once, the template must contain this character sequence.
Default: Redshift3dsMax####
-packages dir
The path to Autodesk's ApplicationPlugins directory.
The path to Redshift's installation directory. If not specified, the location is inferred as a path relative to the current directory.
Default: C:\ProgramData\Redshift
-skipmaxcheck
Bypass checking for active 3ds Max processes.
-symlink
Install Redshift binaries as symbolic links instead of copying files.
-verbose
Enable verbose output.
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.
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).
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 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.
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.
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:
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:
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.
Click here to view syntax and options.