Website Pages:

Welcome to Pipeline Design Patterns
Thoughts on Vocabulary
A Vocabulary for Diagrams
A Theory of Pipeline
Pipeline Design Patterns
Case Studies

Sections in this Page:



Definitions for all terms. Some are proposed; most are just an attempt to capture common usage. See Thoughts on Vocabulary.

Note: these are very much in flux. I'm always searching for better definitions. Many of these will end up defined in context with a pattern or case study.



A collection of similar or equivalent things. In programming terms, think list.

For example, in some pipelines, an animation set or game level is an aggregation (list) of models. Actually, typically they are aggregations (lists) of references to models.

Aggregation is often used interchangeably wih Assembly —as in Set Assembly— but not in this book. The main reason is diagramming: these two things need to be drawn differently. Also, in popular usage, Assembly carries an added connotation of dissimilar things being carefully put together like an IKEA chair: Tab A in Slot B.

Aggregations can be of objects, or of references to objects. At large scale, the common design pattern is Manifest, which is defined Aggregation of References, with Instance Specialization. There are often additional semantics, such as ordering, internal dependencies between objects, etc. These would be encoded in MetaData.

Also, many large scale structures (such as sets or levels) are assemblies of aggregations of references to assemblies etc.


A structure made of components which are internally consistent and fit together according to a Schema. In progamming terms, think struct.

For example, a model is typically an assembly (struct) of geometry, shading, and other data.

Again, note the popular connotation of assembling an IKEA chair: Tab A in Slot B.


Fundamental unit of re-usable production data.

An asset is data—typically, a file or files—-having the following characteristics:

  • Structure — The asset is an assembly, with slots dictated by a schema. The downstream consumer of the asset knows what to expect.

  • Immutability — The asset is not directly editable. You would need to return to a source representation, then edit, rebuild, and re-install/publish etc.

  • Instance-ability — The asset, to be re-usable, needs to be able to be instanced, usually with Specialization.

    Assets are typically assemblies of run-time components, or manifests of references to run-time components.

Asset Management System

Assets are distinguished from other data in part by having their ownership and access managed by some system. This is that system. It typically provides at least these services:

  • Registration — A mechanism for registering a new asset, or a new version of an existing asset.

  • Catalog — A mechanism for discovering which assets are registered.

  • Mediated Access — Typically assets are referenced by downstream consumers, and the references are indirect. The Asset Management System manages that indirection.

    This usually involves a publishing scheme for making assets visible to downstream consumers, and a subscription scheme by which downstream consumers can select which published revisions to consume.

Often times the Asset Management System also provides

  • Build — A mechanism for generating all the asset's representations consistent with a given source revision, whether in a batch or incrementally. The build enforces the [Schema]. More.

For more, see the discussion of Asset Management.


An aspect of an object, a slot for data, typically implemented as a name=value pair.



A Bake is a conversion of representation accompanied by a flattening of reference.

See the associated Bake Design Pattern.

Baked Response

See the associated Baked Response Design Pattern.

Blind Data

Object data —often attributes— which are not part of the attribute schema for the representation in question.

Typically blind data is buried inside other data which is not blind. In this example the shader parameter names are useful quantities (somewhere in the pipeline) but not part of the actual attributes/parameters that the shader knows about.

# shader parameters
uniform float color_A = RED;
varying float color_B = BLUE;
uniform string param_names = "color_A, color_B";


  • In this book, Not-Blind is the opposite of Blind.

  • The same data may be blind in one representation, and not blind in another. This status can/will change along the pipeline.


A set of conversions which enforce a schema.

Typically used to keep assets in sync with their source edits. In other words, the build in (pythonic) pseudocode is:

def build(asset):
    for slot in asset.schema:
        slot.run_time = slot.convert(slot.source)

The build can be triggered by user action, or automatically. The build can occur at server level, or artist workspace level.



Result of a process, saved to avoid re-executing that process unless needed. Typically caches are checked against the process inputs to decide whether to re-execute.

There are several reasons to cache a file:

  • Execution is expensive and needs to be avoided if possible.

  • Dependencies are burdensome to manage. It's useful to get an output and keep it if the processes are changing constantly.

  • Access is expensive. For example, getting the input from a remote location, due to network latency, etc. In this case, the input can be cached locally.

See the Cache design pattern.

Checkin / Check In

This is a Source Control concept.


A familiar term from computer science — transformation of human readable code into machine readable code. Compilation optimizes the intended consumption and execution, at the cost of losing source-code editability and readability.

In the language of this book:

compilation is a type of conversion of source data into run-time data.

compilation/conversion changes the level of abstraction.


Any change in data representation.



Detection and consolidation of duplicate data. The key idea is that the original access patterns of the data consumers are unchanged.

Attribute level — A type of data conversion in which attribute values are consolidated. i.e if name1 = val1 and name2 = val2, and val1 is identical to val2, then the duplicate storage can be avoided.

In this case, name1 and name2 continue to be valid variable names. Only the data is consolidated. (If the var names need to change, that's a different concept.)

File-level — Similar concept, where a number of files share the same data. This is typically implemented via linking schemes.


Pipeline direction.

Source data or artist edits are upstream.

The deliverable film or game is downstream.



In pipeline usage, the best, most fully developed, most accurate version of an asset.

(In general film/game terms, the hero is a character.)



To register an asset, or new revision of an asset, into an Asset Management System.


An occurence of an object —i.e. re-use— in a downstream consumption context.

Take the example of loading a model into a scene, multiple times, with all occurrences having a full copy of the model and its data.

To avoid this duplication we can use an instancing scheme where the occurrences share certain data (such as geometry etc.) by referring to a master copy, but acquire independent variations of other data, such as name, placement, attachment hierarchy, etc.

The variation data required for instancing is called Instance Variation.

Instance Variation

See Variation.


Level of Detail / LOD

Multiple run-time representations which are used to manage visual complexity. For example, foreground (high res) vs background (low res).

Typically this term is used to describe automated schemes, where either

  • the various representations are generated automatically from the same source,

  • or the various representations are swapped in and out automatically, as needed by the downstream consumers,

  • or both.



An aggregation of references to similar things. The references are all specialized.

This is proposed terminology.

See the associated Manifest design pattern.


Literally: “Data about data.” This can mean any/all of:

  • Data about properties: “the sphere's radius is set in the build.”

  • Data about attributes: “the radius on Sphere_12 was overridden in lighting.”

  • Data about the object that is outside the scope of the schema: “the master Sphere was last installed on this date.”

  • Data about the instance that is outside the scope of the schema: “ Sphere_12 is a standin for the hero baseball.”


The use of the term model is very historical and ad-hoc. In general, we use the term to mean anything that can be loaded and viewed in a 3D application. With that in mind, here is a definition:

A package of geometry, transforms, deformations, etc. often with internal hierarchy.

Typically a model forms the basis for an asset, i.e. it occupies one of the slots of the schema.


Object Variation

See Variation.

Override, Attribute

Attributes/Parameters have a default value, specified in the object definition. This default value can be reset during object instancing.

The process is called overriding, and the new value is called an override.

Layered Override

A sequence of overrides where the last one wins. Typically implemented through redeclaring the attribute.


object CoffeeCup():
    size = size
    logo = 'JoesDiner'

object KitchenSet():
    cup1 = CoffeeCup()
    cup2 = CoffeeCup()
    cup2.logo = 'LoveCoffee'

object Shot_1():
    kset = KitchenSet()
    kset.cup2.logo = 'BestCoffeeShop'

Sparse Override

Overrides of just a few attributes/parameters, relative to the total number.

Speculative Override

During instancing, overriding a parameter which may not yet exist. In the above example, imagine we set the logo attribute in the shot before the cup has been built to handle it.



This is the broad definition of Pipeline. The overall system by which we convert artist edits to the appropriate deliverable, whether a film, game, online experience, etc.

Pipeline / Pipeline Infrastructure / Plumbing

This is the narrow definition of Pipeline. The non-application infrastructure that either connects applications or provides additional services.

See also Toolchain, Workflow.


A type of Subscription in which the downstream dataset stores a pointer to the preferred asset revision, thus ignoring publishing updates on that asset.

Usage: “the DinerSet set is pinned to Revision_14 of the CoffeeCup.

Production Management System

A system which tracks the completion status of all the stages of the the production (project, film, game, etc.). It tracks what is to be done, by whom, and by when.

This is not the subject of this book.

I include the definition here simply to point out that Production Management is different from Asset Management, which is different from Source Management.


See the definition of Standin.


Publish and Subscribe are paired but distinct concepts.

A revision of an asset is published when it is made available to downstream processes.

The downstream process can subscribe to that revision—-i.e. consume it—-or not, as needed. Note: consuming the asset involves not only subscription, but also instancing, variation, and execution.

Push / Pull

Push and Pull are paired concepts.

  • Push — In a push pipeline, artist revisions to source files are automatically propagated downstream. This includes automatic conversions to downstream representations, as needed.

  • Pull — In a pull pipeline, the propagation is not automatic. A second artist decision is required, downstream, to consume the new revision.

Whether a pipeline is push or pull (or both) is determined by how it handles publishing and subscription. For example, a pure push pipeline would involve the patterns Publish on Save and Subscribe to Latest.

Related: Publish, Subscribe, Pin.



A version of data that gives a similar visual result, with a different encoding or execution path.

For example: the Full Model vs the Render Archive.


A version of data that represents the evolution of the data,

For example: the 1st Checkin vs 2nd Checkin.

Source Revision Management System

A system which stores all the stages of the evolution of some data. Typically these store source rather than run-time data.

Typically these systems have no notion of Representation.

Examples include RCS, Perforce, and GIT.

Run-Time Data

A representation of data which is optimized for downsteam consumption. Typically this is not editable.

Assets are typically made up from run-time data rather than source data.



In the broadest definition, an object's schema is the specification for the complete lifetime data structure of an object, i.e. the object's footprint in the pipeline.

The schema can contain multiple structures, each appropriate for a given editing workflow or downstream consumer. The schema will also contain (perhaps implicitly) the instructions for conversion between representations.

In a narrower definition, an object's schema is the specification for its data structure at a given stage, i.e. its schema here is this, its schema there is something else.

Which one we mean is usually clear from context.


A representation of data which is directly editable, usually by a specific application. Typically this data is not optimized for downstream consumption.

An example is source shader networks vs run-time compiled shaders.


A run-time representation of data which manages the execution complexity in a given workflow. For example, a layout standin might have positioning controls but not deformations. An animation standin might have a full rig but reduced geometric resolution. Use of the term standin implies the existence of a full representation for that workflow.

Related: Hero, Proxy

Subscribe / Subscription

Publish and Subscribe are paired but distinct concepts.

A revision of an asset is published when it is made available to downstream processes.

The downstream process can subscribe to that revision—-i.e. consume it—-or not, as needed. Note: consuming the asset involves not only subscription, but also instancing, variation, and execution.



Application and process infrastructure: i.e. which programs and tools are used, for which tasks, in what order.

This, plus the data representation schemas and the asset management system, specifies the pipeline.


Undefined Term

Used to enable conversation, so that not all useful words are appropriated with highly detailed restrictions on their use. In other words, it means what you think it means.

See the discussion in Thoughts on Vocabulary.


Pipeline direction. See Downstream.



A particular type of Object Variation which has been singled out as important and given a name. Typically a Variant is an object which is directly instanceable with no further object variation attributes.

For example, the Pine Tree vs the Oak Tree.

object Tree(species=None):
    leaves  = False
    needles = True
    cones   = True
    acorns  = False

    if species == Pine:
        leaves  = False
        needles = True
        cones   = True
    elif species == Oak:
        acorns = True

variant PineTree():

variant OakTree():


A version of data that, for a given encoding or representaion, gives a different artistic result. For example: the Red CoffeeCup vs the Blue CoffeeCup.

Variation, Object

Object Variation attributes are those which change the asset's visual appearance. Things like color or shape details that do not require the wholesale replacement of the object.

Variation, Instance (or Scene)

Instance/Scene Variation attributes are those which place the object into the scene. Things like object name, parent, etc.


Generic concept, encompassing Representation, Revision, and Variation.



What the artist does. All the steps and commands he/she must execute to accomplish a task.

Alternate usage — uncommon — The flow of inventory (literally, the flow of work) from department to department. This is a far less common usage, but I once spent 30 minutes in confused conversation with a counterpart from another studio. She meant one thing; I heard the other.