Redshift in a Windows domain environment

Usage of the Cinema 4D Standard or Physical renderer has decreased to a very low percentage in our studio. They still have their ocassional uses of course, as for certain renderings with simple materials it is very hard to beat the speed of the built-in renderers. For anything else, it’s now a mixture of Octane and Redshift.

Both are fantastic GPU based render engines and both have their pros and cons. Personally, I’m a big fan of Redshifts policy of including all the plugins in the main license, and similar to Sidefx, release new versions with bugfixes on a new weekly basis (sometimes even faster). That’s great – but it comes with the problem of making sure all workstations are running the same version of the software.

In Octane’s case the solution to this is rather straight forward – everything is self-contained in the Cinema 4D plugin, so all you do is replace the c4doctane folder in your plugins folder and you’re done. This can easily be accomplished through a simple shell script.

Redshift on the other hand has a few more bells and whistles running in the background, that require a bit more setup. Luckily, they provide a so called “zero-install zip package” of each build. It’s really just the entire build in one single zip file. This file you should unzip to a central network location, that can be read by all workstations.

To make things easier to maintain, I’ve set up two environment variables via Group Policies like so:

This way all I need to do when a new version arrives is to change the version number and unzip the new build to the proper location. The version number gets replaced in the REDSHIFT_COREDATAPATH (not the Order number! It’s important that the REDSHIFT_VERSION is set first). REDSHIFT_COREDATAPATHFWD is identical to REDSHIFT_COREDATAPATH, however the slashes are replaced with forward slashes for Houdini.

For the actual installation, a simple PowerShell script is being called. In the case of Cinema 4D it would look something like this:

Copy-Item -Path ($env:REDSHIFT_COREDATAPATH + "\Plugins\C4D\R19\*") -Destination "c:\Program Files\MAXON\Cinema 4D R19\plugins\" -Force -Recurse
Copy-Item -Path ($env:REDSHIFT_COREDATAPATH + "\bin\redshift-core-vc100.dll") -Destination "C:\Program Files\MAXON\Cinema 4D R19\" -Force -Recurse
Copy-Item -Path ($env:REDSHIFT_COREDATAPATH + "\bin\OpenImageIO-1.6.17-vc100.dll") -Destination "c:\Program Files\MAXON\Cinema 4D R19\" -Force -Recurse

For completeness, you can just as easily “uninstall” Redshift:

Get-ChildItem -Path "C:\Program Files\MAXON\CINEMA 4D R19\plugins\Redshift" -Recurse | Remove-Item -force -recurse
Remove-Item -Path "C:\Program Files\MAXON\CINEMA 4D R19\plugins\Redshift" -Force -Recurse
Remove-Item -Path "C:\Program Files\MAXON\Cinema 4D R19\redshift-core-vc100.dll" -Force
Remove-Item -Path "C:\Program Files\MAXON\Cinema 4D R19\OpenImageIO-1.6.17-vc100.dll" -Force

For Houdini, it’s quite easy as well, everything is set up through the environment variables and the houdini.env:


Unfortunately I have yet to figure out a way to get the current build number from within the houdini.env file. By setting the version through the GPO, it sort of limits the workstations to a single Houdini build. However, there may be multiple builds installed (for reasons). Luckily there’s an easy solution to this, since the GPO-set environment variables are set system-wide and can be overridden with user environment variables (can be done very conveniently with something like the Rapid Environment Editor).

And that’s it. Now whenever there is a new version of Redshift I only have to unzip the zero-install file to my network location, adjust a single Environment Variable in a Group Policy and trigger the script to update the Cinema 4D plugin (I use EMCO Remote Installer for those things). For Houdini I don’t even have to do a thing. Just make sure to run GPUpdate on all workstations though (see this article regarding a domain wide update).

Leave a Reply

Your email address will not be published.