Identifying Versions

There are only two hard problems in computer science – cache invalidation, naming things, and off by one errors.

Phil Karlton

Over the past four years I rebuilt the asset management system at my current studio in parallel with transitioning to a USD centric pipeline. This blog post provides a brief summary of some of what I have learned.

All productions require a way to register and track versions. Whether you’re just using strongly enforced file naming conventions or an database driven asset management system, registering and tracking versions comes down to naming.

Most studios I have worked at went with a bicameral taxonomy that used separated schema for identify versions for Shots and Assets. The most recent pipeline I worked on originally had a multicameral taxonomy, but has been simplified to a bicameral one with two alternates – one for variants of an Asset, and one for instances of Assets within a Shot. However, none of these taxonomies have an explicit affordance for an Asset specific to a Shot or Sequence. While this can be done implicitly with a variant, that is an imperfect solution.

In a bicameral taxonomy, the identifier schemas would look like this. Fields in parenthesis are optional.

• Project Asset Role Type Label
• Project Shot (Namespace) Role Type Label

The “namespace” field is the suffix applied to the Asset name to make a unique instance of it in the Shot. The “role” field specifies which work group the version was produced by – for example, modeling, rigging, lookdev. The “type” field specifies the contents and use of the version – for example, Maya model, USD geometry, FBX animation, etc. The “label” field provides an affordance for the user to name their work to maintain separate version stacks. For example, they could be doing wedges with different render settings, or trying an alternate camera move.

A unicameral taxonomy provides an affordance for all of the above use cases – Assets, Shots, and instances of Assets in a level. It does this by trading “Shot” for “Level”. For example, a feature film would have three types of levels – show, sequence, and shot. A streaming series would have five types of levels – show, season, episode, sequence, and shot, assuming it doesn’t get canceled after one season to avoid paying residuals.

In a unicameral taxonomy, the identifier schemas would look like this:

• Project Level (Asset) (Namespace) Role Type Label

Having a unicameral taxonomy simplifies your asset management rules by resolving the Shot/Asset divide, which will also simplify your file management, whether you’re using a real file system or a virtual file system. Whether you use a unicameral or bicameral taxonomy, you want the schema to be normalized (any given token appears in only one field).

All versions with the same identifier are part of a version stack. Each version in the stack must have a unique version number. You can employ version tags to identify specific versions as important.