Localising Houdini Libraries
If you work in a studio setting you are always reading/writing files to a shared server (NAS). Often this means scene files, caches and renders, but it also applies to Houdini libraries which much be loaded for each Houdini instance.
From my experience, no matter how good your LAN and NAS speeds are, loading this collection of files significantly increases Houdini launch time (on Windows at least) - from ~20s for a ‘empty’ Houdini instance to upwards of 2-3 minutes for a full set of 3rd-party libraries and plugins.
My solution has been to load the minimum number of libraries from the NAS (Redshift and ‘live’ libraries like Aelib where HDAs are sometimes updated) and mirror the rest to individual PCs on a daily schedule for local loading. This reduced Houdini launch times significantly for us.
File Mirror Script
We can use a very short batch file to copy files from the NAS to a location on the C: drive
"copy_houdini_libs.bat":robocopy \\192.168.0.1\Pipeline\HoudiniLibs C:\Pipeline\HoudiniLibs /MIR /XD ".git" "backup"
exit
Replace \\192.168.0.1\Pipeline\HoudiniLibs with the path of the parent folder on your NAS containing your Houdini libs.
/MIR performs a mirror operation - copying files from the source and also purging any extra files at the destination
/XD excludes directions matching a given pattern. Here we ignore git repository files and and .hip backup folders
More info on Robocopy
Deployment
We want to schedule this copy action so library updates on the NAS are automatically reflected on every PC in our network.
Task Scheduler
For a small outfit running a handful of machines you can use Windows Task Scheduler to set up the scheduled task on each PC individually.
You can find task scheduler guides like this easily online. Choose the trigger you want - “On User Login” works well, as does a Daily schedule.
For the action we pick ‘Start a program’ and enter the path to our .bat file. Right-click the new task and hit run to test it out. Job done!
PDQ
At a certain point a studio becomes large enough that managing individual PCs becomes unsustainable and centralised deployment is necessary.
PDQ is a must-have for any Windows-first studio. It has a free version with enough functionality for simple deployments. The paid version is not too pricey once extra features are needed. https://www.pdq.com/pdq-deploy/
I won’t go into detail here but the general idea is to install and PDQ on a single PC, configure ‘Targets’ (i.e the PCs in your network) and create/schedule running of ‘Packages’ (Commands run on a selection of targets).
The batch script we created above can be run via using a simple ‘Command’ package.
Active Directory
Another inevitable step in a growing Windows-first outfit is moving to a proper domain in the form of Active Directory.
PCs and Users on an AD domain can be configured centrally, in granular fashion, and in immense detail using ‘Group Policy Objects’. GPOs can be created to control almost anything in Windows. For deploying a batch files like ours we could use a ‘Logon Script’. These are found under:
User Configuration > Windows Settings > Scripts (Logon/Logoff)
I won’t outline the whole process here - see the official docs.
PDQ and GPOs are both fine options for our use case here. GPOs really shine for things like Environment Variables, Registry insertions, Firewall settings and fine control over groups of Users/PCs.
Houdini Config
The last step is to update your Houdini packages, which are likely stored in a shared $HSITE location on the NAS.
Decide which libraries you want to use the local versions of (3rd party plugins like Labs, MOPs, Axiom are good targets) and update each package.json file to point to the new C:/ drive location. Our batch script copies every library locally so you can quickly localise or ‘unlocalise’ a package as needed.
Even after all this effort Houdini launch times will probably still be longer than our ever-diminishing attention spans. A final tip: always have an empty 2nd Houdini instance open in preparation for crashes!
