Like many other applications, Houdini’s configuration can be modified by using environment variables. It is a very useful way of creating different Houdini setups for different purposes – let it be different projects, different plugin versions, sandboxes for testing assets, personal configurations, etc. While this post is written for Houdini and have examples for windows and linux, it is applicable for any other application and operating system.
A couple of words about environment variables.
At first I will try to explain basic concepts of env vars and later on I will show examples for Houdini (linux and windows).
Environment variables might be a bit hidden to many users, but they can be very helpful. Actually a lot of operating system behavior is controlled by them. Apart from configuring Houdini, env vars can be used to modify a search path for binaries, libraries, can set up proxy settings, get current user’s name, path to home, temp directory, hostname, shell and much more.
An useful thing is that they can be applied globally to the whole system, and locally to the current environment in a shell (a terminal session or environment set up and executed from batch/bash script). For example one might specify global settings which are available to the whole system (path to system cache dir, username, path to root directory of all projects…) and local settings for each configured environments (houdini version, project name, project root, path to textures directory, license information about a plugin…). All child environments (set up through batch/bash script) will inherit global settings (available to the whole operating system or an user) and can have specific local settings needed for their purpose.
Here are couple of situations which env vars can efficiently address:
- having a multiple versions of Houdini using different renderer plugin versions and different assets libraries
- using different configurations for different projects / sequences / shots / tasks
- sharing the same settings (home dir, temp dir, cache dir, footage path, rv path) for various applications (Houdini, Nuke, Katana, Maya)
Using environment variables on windows
Here I will show an example of one of my Houdini startup script which sets an environment for a project and executes Houdini: houdini.bat.
Note that Houdini understands a lot of useful env vars, documentation can be found here.
Here I will explain some of batch syntax:
@echo off – hides printing of commands into the console, it makes output more readable
rem foo – lines starting with rem are comments
call foo.bat – executes foo.bat batch script and inherits all env vars specified in it
%MYVAR% – value of MYVAR variable
set “MYVAR=FOO” – sets MYVAR variable to FOO – those variables are specific to softwares, which are expecting them
set “PATH=%PATH%;FOO” – appends FOO to the PATH variable which is used for locating binaries to be executed (houdinifx command is not known to the whole windows system, only when houdini bin directory (containing houdinifx.exe) is appended to the PATH var)
start foo – executes foo.exe (which must be found in one of the paths in the PATH env var) while passing on all existing variables to this child environment
This script can be used for setting up local environment variables, to define a variable for the whole system environment on windows, follow this video.
Using environment variables on linux
(Linux version should be directly transferable to mac OS.)
In linux env vars can be set up on multiple locations (~/.profile, ~/.bashrc, ~/.bash_profile, ~/.bash_login, /etc/environment …)
System env vars can be specified in /etc/environment. User env vars can be specified in ~/.profile (~ symbol points to the user home directory).
~/.profile, ~/.bashrc, ~/.bash_profile, and ~/.bash_login have similar usage, but I recommend using ~/.profile, which is the only one executed when running applications from graphical environment in a desktop session..
In a Bash terminal the quickest way of executing an application inheriting env vars is to use this syntax:
$ MYVAR1=foo MYVAR2=bar houdinifx #executes houdinifx with MYVAR1 and MYVAR2 variables set to "foo" and "bar"
While this is useful for quick testing one might want to create a start script instead of typing the command into the terminal.
To create a bash script, create a file houdini.sh and make it executable (chmod +x houdini.sh), then put shebang into the first line. In the script you can set variables using this syntax
#!/usr/bin/env bash cd /opt/hfsXX.X.XXX/ #replace X with your Houdini version source houdini_setup export MYVAR1="foo" export MYVAR2="bar" houdinifx
This simple script will source (inherit) environment from houdini_setup script shipped with houdini, execute houdinifx command with MYVAR1 and MYVAR2 variables present.
Here is another simple start script which I use when testing a houdini plugin. It is different from the windows batch script showed before, but you can use this syntax to port it for linux as well 🙂
Also one note – in your linux shell a houdini command might not be available if you have not sourced environment from /opt/hfsXX.X.XXX/houdini_setup script before:
$ cd /opt/hfsXX.X.XXX/ $ source houdini_setup
Which is basically calling houdini_setup script to set up and inherit needed variables (equivalend to the call command in windows batch).
Checking if variables are present in Houdini
Once you have run Houdini from your batch/bash script you can quickly check if your variables are present in your Houdini session.
Open texport pane and type following
Output of this command should match the value specified in your starting script.
Now you can use $MYVAR1 in any parameter inside Houdini, useful, isn’t it?
Open python shell pane and type following
With that command you can get value of MYVAR1 in any python context inside your Houdini session.
Those setups can be very useful, it might take a bit of time when setting them up for the first time but it will definitely pay off later on. Especially when your setups will get more complicated 🙂
You also then need to manage your scripts somehow, because your variables will not work when houdini project file will be run in another environment (without executing your starting script). This happens often when running scripts from another user, machine, on renderfarm etc.
Hope you find it helpful, if you spot any mistakes please let me know so that I can correct them.