Publishing

 

With this in mind, changes that are made to a digital asset can then be published through a dialog created with PyQt and executed via an OPMenu action. The artist making changes must specify a brief message describing changes they made (like a commit message for git), along with either choosing minor or major version for the publish. The last thing to choose is the "element" to publish for. This can either be a studio wide publish, or something like a Project, Sequence, or Shot can be chosen.

 

Levels of Granularity

 

This concept is very interesting and has many applications because it allows for these Houdini tools to be versioned for specific use-cases. Say a specific shot needs an HDA that imports alembics to be tweaked a certain way in order for assets to be properly imported for this corner case. The change doesn't have to be pushed out studio-wide and potentially break other setups, but can be published for just this shot and allow for other artists who are working on the shot to also benefit from the change. Since we are aware of what "element" an artist is working on based on the file path of the scene, we choose to advertise new element-specific versions only when it is relevant to show them.

 

Prompting for new versions

 

The system I developed prompts users with new available versions of HDAs whenever they open a scene file. However, as stated before, this is not only context-specific to what sort of element they are working on, but is also populated with only versions of digital assets that the artist is currently using in this scene file. Compared to the old system of "versioning", the artist also has the choice to ignore the newer versions and stick with the versions they currently have in the scene file. The system allows you to change back and forth to any version of the digital asset at any given time.

 

Redefining how HDAs are sourced

 

Due to the way that the publishing system works, the versioned .hda files are placed in a subdirectory structure automatically on publish. This means that the traditional method of "scanning" for HDAs on startup using the HOUDINI_OTLSCAN_PATH will not work since that scans only 1 directory deep. As a result, I developed a startup Python script that recursively searches a given directory for HDAs given potential regexes to exclude (i.e. the "backup" folder of HDAs).

Overview

 

This tool was developed during my Pipeline internship at Blur Studio (Summer 2017). At the time, the versioning system for the HDAs created by the FX Artists was very basic and didn't allow for much more than forced version updates when a new version was committed to the Git repository. This system that I developed sought to broaden that horizon.

 

I leveraged an already implemented publishing system that is used throughout the studio to publish new versions of assets, sequences, etc. in order to start with a base system that versions HDA files. The second aspect of this is a distinction between minor and major versions. Minor versions would constitute small bug fixes or tweaks to HDAs that should be backwards compatible with old Houdini setups using that HDA. Changes that fundamentally change the functionality of the HDA (like changing how parameters are referenced or the node setup within the asset) should be a major version, and require a more conscious decision by the artist to choose to switch to it, as it may break their current setup.

 

HDA Version Manager

Blur Studio Tool