Website Pages:
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.
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.
A Bake is a conversion of representation accompanied by a flattening of reference.
See the associated Bake Design Pattern.
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";
Notes:
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.
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.
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.
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.
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.
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.
A sequence of overrides where the last one wins. Typically implemented through redeclaring the attribute.
Example:
object CoffeeCup():
size = size
logo = 'JoesDiner'
object KitchenSet():
cup1 = CoffeeCup()
cup2 = CoffeeCup()
cup2.logo = 'LoveCoffee'
object Shot_1():
kset = KitchenSet()
kset.cup2.logo = 'BestCoffeeShop'
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.
This is the narrow definition of Pipeline. The non-application infrastructure that either connects applications or provides additional services.
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.”
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.
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 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.
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.
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.
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.
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.
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.
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():
Tree(species=Pine)
variant OakTree():
Tree(species=Oak)
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.
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.
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.