Publishing and Asset Management

This is pretty much the core of traditional pipeline, to make sure assets can be shared between departments and be tracked.

The first part of this is Asset Publishing.

When a department deems it’s work ready, it decides to publish it so the next department in the chain can consume it. For example modeling exports models, but does animation export animation? Well that depends on who is consuming it. This is dependent on whether it needs to be interactive past this point or not.

For geometry we often just publish as a geometry cache using Alembic which is a industry standard developed by Imageworks and ILM so that we can have a consistent cache format.

For point cloud data, we either use Alembic or OpenVDB, for images we tend to use tiff’s or OpenEXR.

Soon the industry will probably also standardize on a universal scene format from Pixar called OpenUSD.

Anyway the idea is to generally keep the data in the most efficient format possible, while allowing for easy interchange. Cache data is often best because you really only take an IO hit, which is cheap, versus a deformation hit, which can be very expensive.

This all gets really complex though. Artists don’t need to know where their data is coming from or going to, or even how it gets there. They just need to be able to load it in and publish it out.

This is the pipeline. We develop the UI’s and the tools to do this in a very user friendly manner.

To publish data, the user just has to open a publish UI that will validate their assets against some tests, and then send it off to the machine farms where the conversion to one of the open formats happens.

To ingest the published data, we similarly just have an asset browser that lets the artist pick which asset they want. Often they just see a thumbnail and description. The details are irrelevant to most artists.

Because these publishing and asset management systems need to be common to multiple apps, we develop them in Python and Qt (PyQt or PySide) , which allows us to reuse our code without recompiling for each application and makes it easy to rapidly add functionality where needed.

This is common to pretty much every department, so I figure it warrants its own section here rather than repeating for each.