OpenPipeline Specification

Preface

This work-in-progress document is version 0.1 of the openPipeline Specification, issued August, 2007. It represents the official technical specification for openPipeline.

Overview

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.

Element Description

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:

  • Task: A defined process that connects a process to an discrete aspect of production usually involving dependencies and a time frame. This process can be carried out by an artist or procedurally by the system depending on the nature of the task.
  • Workflow: A series of tasks strung together in a procedural node-network execution order.
  • Asset: A unit of production such as characters, props, environments, which can be made up of components.
  • Component: Pieces required to build the asset. For example, a character is made up of a model, rig, and shading.
  • Sequence: A logical collection of shots.
  • Shot: The composed collection of assets that are animated, lit, and may be rendered.

    • —

    Directory Structure

    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
    ---------------------------

    openPipeline Workflow

    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.
    Project Attributes

    • Name
    • Path
    • Deadline

    Create Asset Types

    • “character”
    • “prop”
    • 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)
    Master
    Mastering and flattening references along the way ensures that upstream changes are dealt with properly.

    Rules

    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.

    Go to Top