This work-in-progress document is version 0.1 of the openPipeline Specification, issued August, 2007. It represents the official technical specification for openPipeline.
The inherent complexity of the production of digital content places high demands on artists in terms of time and attention which can significantly lower the quality and increase the cost of delivering the final product. Organization, standardization, and efficiency of the pipeline takes a large amount of the burden off the artists. The level of sophistication previously associated with large scale projects such as 3D animated films and blockbuster effects sequences are now becoming commonplace in the production of television commercials and games. The depth of production pipelines, numbers of artists required, and sheer data size and complexity of all digital productions continues to increase. The openPipeline project is a community-based, open-source, specification for a production pipeline and a collection of tools which implement this into existing production applications all in an effort to alieviate these issues.
Definition of an Animation Production Pipeline
An animation pipeline handles the flow of data as it travels through the stages of production. They are based upon the interplay of tasks associated with assets and shots. Abstractly, a pipeline is both an established set of decisions and a collection of tools developed before production and managed throughout so that the focus for the artist is on the creative and technical challenges not the nuts and bolts of production. By laying this foundation, the pipeline sets the ground rules so that individual work is integrated into the bigger picture of production. openPipeline is a specification for a production pipeline.
openPipeline is based on the notion of the asset library and the shot collection. The asset library is the repository of production elements that are developed, managed, and reused throughout the project. The shot collection is the container of data files which store the composed assets as defined by the production. The terminology for the key production elements is below:
A proposed directory structure would be as follows:
ProjectName 3d --------------------------- lib assetType01 asset01 components workshop versions notes asset01_masterFile assetType02 assetType03 ... scene sequence01 sequence02 sequence03 ... archive concept --------------------------- composite ---------------------------
Projects are defined by name and file path. Attributes such as folder naming, data filetypes, deadline, and project status are available. The project file is stored as XML.
Create Asset Types
- Create an Asset for type: “character” named “bob”
- Save workshop files through openPipeline for “bob” until done.
- Publish asset “bob”.
Publishing (also know as Mastering) strips a file of all its dependencies, procedurally cleans it up, and puts it into a public place in the production tree with a clear name like:
bob_asset.mb. Every time a file is mastered, this file is replaced. Dependencies downstream from it get the updated file for free because the file they reference remains the same. Assets and Shots and their components all work this way.
A workshop file is where insulated artist work is carried out. When the asset is ready to be released into active production, it is mastered. So in the end, editing an asset means editing the latest workshop.
The directory structure that it creates is also easy to work with but most users never need to search for files or use the standard
File Open commands. When they want to edit an asset they select it by name and openPipeline does the rest. The modularity inherent in the openPipeline workflow allows objects created in one project can easily be ported to another.
Create Sequence: sq01
Create Shot: shot001
Reference in Asset “bob”
Animate (save Workshops)
Mastering and flattening references along the way ensures that upstream changes are dealt with properly.
1) No spaces in any names.
2) All descriptive information is stored in generic XML files.
3) Incremental saves are the default form of revision control.