A release archive contains everything you need to run Redshift for Houdini and Solaris, including the Redshift libraries, the plugin binaries, the menu shelf, the HDAs, etc. Redshift for Houdini supports the latest production build for the 4 most recent major Houdini versions (18.0, 18.5, 19.0, 19.5, and 20.0) as well as the three most recent production builds of the most recent major Houdini version (19.5). Both the Qt5 (regular) and Qt4 flavors of Houdini are supported. In general you need will need to match the versions of Houdini and the Redshift plugin target Houdini version, however if there are no changes in the Houdini HDK between the Redshift plugin's target Houdini version and your preferred Houdini version, you may be able to run Redshift.
In this forum topic, there are additional custom builds of the Houdini/Solaris plugins released before they are available inside the main Redshift release installers to support recent Houdini production builds or to include quick fixes:
Before you can use Redshift in Houdini, you have to tell Houdini where the Redshift plugins are located on your system. The location of the Houdini and Solaris plugins must be established in one of two ways, editing a houdini.env file or creating a Houdini .json package file. This must be done for each version of Houdini you are using.
After installation, Redshift and the Houdini plugin will be installed in the C:\ProgramData\Redshift folder along with your log files, license file (if using a node-locked license), and the Redshift preferences.
If you want OCIO support in Solaris, Mplay, or to avoid OCIO warnings in Houdini 20, you should force Houdini to use Redshift's default OCIO config by adding the following line to your Houdini .env configuration:
If you switch to the Redshift OCIO config and load a scene you already started with the Houdini OCIO config you may need to update the camera parameters so it recognizes the OCIO change. This can be accomplished by selecting the cameras in your scene and pressing the "CamParms" button highlighted in the image below. Or you can automatically update all cameras in the scene by using the "Redshift_cameraSpareParameters" command in the Houdini Textport.
A Houdini package is a .json file that can be created and used to configure Redshift for Houdini instead of editing a Houdini .env file. It is generally easier to manage and maintain since they can be separated from other plugin configurations unlike in a .env file where multiple plugins share the same file. For more information, please see the Houdini Packages help page.
Create a Houdini package for Redshift that contains the following:
Before you can use Redshift in Houdini, you have to tell Houdini where the Redshift plugins are located on your system. The location of the Houdini plugins must be established in one of two ways, editing a houdini.env file or creating a Houdini .json package file. This must be done for each version of Houdini you are using.
After installation, Redshift and the Houdini plugin will be installed in the /usr/redshift default folder along with your log files, license file (if using a node-locked license), and the Redshift preferences..
On Linux, establishing a link to the Solaris plugins requires a different method from other operating systems. Instead of being included in the .env or .json file, the environment variable "PXR_PLUGINPATH_NAME" needs to be added to the launch script for Houdini or used as a system level environment variable. This variable should point to the Solaris plugin files.
After installation, Redshift and the Houdini plugin will be installed in the /Applications/redshift default folder along with your log files, license file (if using a node-locked license), and the Redshift preferences..
If you want OCIO support in Solaris, Mplay, or to avoid OCIO warnings in Houdini 20, you should force Houdini to use Redshift's default OCIO config by adding the following line to your Houdini .env configuration:
I was Apprentice, then Indie. I think, that I was able to copypaste from my .HIPNC into my .HIPLC ... (maybe there was some signature in those .hipnc, that indicated I created them on the same machine/id?)
You're completely missing the point. It's a licensing restriction. SESI doesn't want people using the Apprentice version or Indie version to do major commercial work. That's what the more expensive commercial versions are for. If it was easy to convert the file types then it would be easy to break the license agreements. It's supposed to be a pain in the ass and controlled by only a few so the licensing agreements can actually be enforced.
It's the same situation with the Orbolt assets too. If you buy the Indie version of the Orbolt asset it won't work in the commercial versions of Houdini. I think SESI will do a one time conversion of files (but probably not Orbolt assets) if a commercial version of Houdini was recently purchased. Other than that one time situation the different scene formats don't intermingle or convert.
Someone on here helped me figure something out, but now I can't use my commercial project but add in their little helper file, it will make the project non-commercial. I get the licensing aspect, but this sucks for those who paid for license.
I have some similar problem.
I am working on a project sind a few weeks in houdini indie. Yesterday i was opening another file from the apprentice version to look into that for some hints that can help me with my actual project.
Houdini said that it now enters a non-commercial-session-mode, wich was fine, cause it was an apprentice project that i opened.
Then i reopened my actual project and worked there, i didnt copy anything from other project in there, i have typed all in by hand and created all the nodes by my self.
Today i wanted to open my project and i get the popup that says that houdini will open this project in non-commercial-session-mode, what the hell?
Just by opening another non-commercial-project all my other proejcts are now non-commercial too? Whats that? How can i fix it? Makes me mad about it
Keeping track of your changes is important in every workflow and the same applies to dealing with digital assets in Houdini (HDA/OTL). Houdini enables you to have non-destructive workflows and has a nice way of managing its assets versions.
To create a version namespace, add a numeric suffix after you asset name. You can use number and periods only, but you can design your own convention. For example after couple of iterations on your ivy asset you can have assets with those names:
As you probably noticed, Houdini uses two colons (::) for separating namespaces. In file names it replaces :: with two underscores (__). When creating an asset you should use namespaces in Operator Name. For Operator Label use a descriptive name, like Ivy generator. As for a file you want to save the asset into, you can skip the version part. You can do it because you can have multiple versions of an asset in one library file (.hda). Then it is not misleading if you have 10 different versions of assets in a file having first version number in its name.
To manually switch versions, go to Configuration tab of Asset Manager and select Display Menu of All Definitions in Asset Bar dropdown menu. This will show a handy dropdown menu at parameter interface of each node.
Take a look at Asset Manager, it provides you useful tools for managing your asset libraries. Also check my post about using environment variables if you want to learn more about how Houdini finds digital assets on your disk.
Saving hip files as text seems to be easily done through File -> Save as text option, or with hou.hipFile.setSaveMode(hou.saveMode.Text) Python command. Digital assets need to be converted to folders and back with hotl command line utility. You can chain this operation to your publishing pipeline, where assets are expanded to folders and files before committing to the repository and later converted back when pulled.
c80f0f1006