This is an open source production pipeline framework developed by students, staff, and faculty in the Clemson University Digital Production Arts (DPA) MFA program. This project was overseen by DPA staff software engineer Josh Tomlinson and DPA professor Dr. Jerry Tessendorf, both formerly of Rhythm & Hues Studios. The implementation is primarily based on the talk given at SIGGRAPH 2014 entitled A Framework for Global Visual Effects Production Pipelines by Josh and his former colleagues based on their work at Rhythm & Hues. This project was also introduced at the Global Pipeline Birds of a Feather meeting at SIGGRAPH that same year.

The primary goals of this project are to:

• provide students exposure to a professional quality pipeline that best approximates what they will encounter in the workforce
• support multi-site workflows
• create a teaching platform for students to learn python and other production support technologies
• expose DPA to possible outreach opportunities with industry collaborators
• expose pipeline and workflow concepts to undergraduate programs that may feed interested students into DPA

Features of the framework include:

• No assumptions made about the type of work being done, the type of data being shared, or the content creation software being used
• Flexible, adaptable project hierarchy
• Consistent toolsets and workflows for any/all production stages
• Integrated asset management system
• Customizable workflow actions
• Basic workflow support for common content creation applications

Django backend:

A django backend defines the data models for the framework. The Django REST framework provides a REST API that is consistent across all data models and used by the front end python APIs. In the long term, it would be nice to provide a layer to support a Shotgun backend as well.

The backend repo is separate and can be found here.

Production Tasks (ptasks):

PTasks are generic, hierarchical representations of something that needs to get done on production. For example, a project ptask contains sequence ptasks, which might contain shot ptasks, etc. No ptask types are hardcoded into the system so you can create a project structure based on the type of production. Beyond that, the structure can differ within branches of the same parent.

All ptasks have attached meta data including start/due dates, status, priority, etc. Individual ptasks are versioned, so you can snapshot the state of your project at any level. Currently only the leaf ptasks have a version action defined, but it is completely reasonable to define what it means to 'version' a sequence, build, or an entire project. The framework makes it easy to restore old versions of a ptask and even work within multiple versions simultaneously.

Products:

If ptasks are the functional parts of the project, then products are the outputs. Products are categorized results of the work done within a given ptask. Versions of products are tied directly to the version of the ptask that created them which makes it easy to find and restore the state of your work when a product was created.

One of the biggest features of the framework is the subscription layer that allows downstream ptasks to subscribe to published versions of upstream products. The subscription layer allows for a complete, historical overview of the data flow at any time within a project.

Products have other features like location statuses (what locations does a given version of a product exist?) and groupings (a 'character' product may be comprised of model, rig, and surfacing related products), though these features have not been fully tested.

Actions:

Actions are custom behaviors that define a project's workflow. Actions are implemented by subclassing an abstract base class and then registering within the pipeline. Actions can be triggered via the command line or within python. Actions include, but are not limited to, versioning a ptask or product, subscribing to products, and setting your ptask context.

Application support:

The framework provides Session and Entity APIs for defining common behaviors and interfaces for content creation packages and the importable/exportable items within them. The framework has some simple implementations that drive DPAs Maya, Mari, Nuke, and Houdini workflows allow the same tools and interfaces to be used across all of these packages.

The code in this repository represents the state of the framework's development to this point. The codebase should not be considered a drop-in, ready-to-use pipeline solution. We consider this project a continual work-in-progress that currently needs some hand-holding, yet is a functioning system for building and executing a digital production pipeline. The framework is currently in use by DPA students as they complete an intense summer mentorship program with Dreamworks Animation.

The framework is currently lacking/needs help in these areas:

• Multi-location testing
• Proper user authentication/security
• More/better application support
• Proper documentation
• Web views into the backend data
• Code review and cleanup
• A million other things. Please ask!

If you're thinking about, or are in the process of, building your own production pipeline and would just like to know more about this project, please contact Clemson-DPA or simply create a new issue.