Category

Tutorials

Shotgun Tutorial – Using hooks to configure your renderfarm.

By | Blog, Hints and Tips, Shotgun, Tutorials | No Comments
Note : This post is specifically for a Windows based Shotgun installation, but it should be fairly easy to adapt to other environments.

One of the tricky things about getting Shotgun up and running smoothly, is getting your renderfarm environment configured correctly.

The Shotgun docs offer two approaches that are worth trying here and here but as these are specific to Nuke they may not do everything you need to get all your DCCs configured correctly.

Another approach to try is something that we have implemented here at HaloVFX; using Shotgun hooks to build/set your environments from scratch. This approach was developed largely to avoid the need to use 3rd party tools or scripts to set and update environment variables across the studio and renderfarm.

There are a number of benefits to this approach

  • your environment is set entirely within the Shotgun ecosystem; there is no need to launch Shotgun from a custom in-house launcher.
  • you can take a new workstation, install Shotgun and your DCCs, and without any further configuration or setting of a single environment variable, you can open Shotgun.
  • the studio environment can be configured per-project.
  • workstations/rendernodes require no environment configuration.
  • your entire environment is included in the pipeline configuration for any given project facilitating easy backup and retrieval.
  • your environments are entirely isolated per-project with no risk of changes causing un-expected problems across other projects.

In principle, this approach requires three steps.

  1. set studio-wide environment variables inside your core engine-init.py hook
  2. set project specific environment variables in your app-launch.py hook.
  3. update your deadline submissions scripts to include all required environment variables in the job file.

Update Shotgun ‘engine-init.py’

In your project pipeline config ‘core/hooks’ folder, make a copy of the ‘engine-init.py’ file from your core ‘install/core/hooks’ folder. (whether shared or localized)

You can add project-wide environment variables here by adding entries to the EngineInit ‘execute’ method.

Update Shotgun ‘app_launch.py’

In your project pipeline config ‘hooks’ folder, make a copy of the ‘app_launch.py’ file from your ‘config/hooks’ folder.

To help identify environment variables we want to keep track of, they are all prefixed with “HV_”. We will use this later in the deadline submission script to choose which environment variables to pass on to our rendernodes.

It’s up to you want variables you need to define for your pipeline, but here are some paths I found useful to have to use in other tools and apps.

You can define environment variables for specific applications by testing for the engine being called :

For Houdini, you’ll want to set a number of paths including the following.

And if you need to add paths to your PYTHONPATH you can add the following :

Update Deadline submission scripts – submitNukeToDeadline.py

To pass your environment variables through to deadline, you need to edit the submission script and insert something like the following after the jobInfoFile has been opened and assigned to the fileHandle variable;

after :

add something like this:

of course, this example is specific to the deadline submission script for Nuke, but you should be able to adapt this code fairly easily for the submission scripts in other applications.

Once you have this implemented successfully, you should see in your ‘job details’ window of your Deadline monitor, the environment variables you defined. When the rendernode launches the job plugin, the environment of the rendernode will be updated with these environment variables.

It’s up to you how far you push this approach; you can theoretically recreate the entire environment of the machine/session submitting the job without having to worry about how the rendernode has been configured.

Conclusion

When implementing this approach. I half expected there to be  a number of unexpected and unwanted consequences, but I’m glad to report that in production this has proven to be very robust. As an added bonus it also provided me with excellent information with which to debug problematic jobs on the farm!

Thanks for reading, and I’ll look forward to hearing your thoughts on how this approach can be further developed. If you have taken another approach to this then I’d love to hear about it!

 

Skip to toolbar