Thoughts on Vocabulary

A huge part of the Design Patterns approach is nailing down vocabulary, which requires thoughtful choices. This is about that process.

Conversations

Good vocabulary allows good conversations, like the following. Arturo, the artist, and Penelope, the pipeline guru, are in complete sync on concepts and terminology:

Arturo— “I just registered, but did not publish, a new revision of the render archive representation of the hero version of the JoesDiner variation of the CoffeeCup.”

Penelope— “Let's make sure that DinerKitchen shots are subscribing to the approved revision. If that's true then go ahead and publish the latest revision, and subscribe to that in the DinerCounter shots. We should get test renders with the new cup.”

Arturo— “Good idea. And once those are approved I'll promote the new cup and remove the pins.”

Penelope— “Excellent. And I'll buy the beer.”

This is our goal. What's in the way?

We need clarity of language

There are no standard definitions of important terms such as Asset, Publish, Workflow, or even of the term Pipeline itself.

Certain terms—such as Bake and Cache, or the aforementioned Representation and Variation —are used interchangeably, and this ignores some very useful distinctions.

We are careful to maintain these types of distinctions in other discussions—for example, between vector and normal when discussing geometry, or between bump and disp when discussing shading. We should be just as careful with pipeline concepts.

This is particularly unfortunate in that these terms often have specific and useful meanings in normal discourse, and those meanings are (even more!) useful in the context of pipeline.

And sometimes, we need new terms. I will propose some new terms for important concepts. As an example: Object vs Instance variation, to denote the ways in which objects are specialized in in their definition vs in their usage.

But we also need flexibility

Definitions require words, which require more definitions, and the transitive closure of that is a compendium like Webster's Dictionary—which took decades to complete, and bankrupted the author! So we need to leave some things undefined: object, structure, component, file, data, and so forth. I think we know what those mean. They provide a common framework of somewhat flexible terms that we can use to define other things.

Also, too much precision can cause gridlock.

True story (maybe embellished a tiny bit). Once I asked a developer about the shading tool he'd been working on.

Me— “I have this group of woodgrain parameters that I want to control downstream...”

// Group? Set? Bundle? of WoodShader Parameters
float grain_spacing     = 0.01;
float grain_wavyness    = 0.4;
float dark_grain_color  = DARK_BROWN;
float light_grain_color = LIGHT_BROWN;

Developer— “No, that's not a group. A group is a subclass of a collection, distinguished by how it's initialized. And you don't want collection either.”

Me (bewildered)— “Um, OK, I have this set of parameters...”

Developer— “No, very different concept. Set is not what you mean.”

Me— “OK, I have this bundle of parameters...”

Developer— “No, bundles were in the old version, they are deprecated now.”

And on we went, through combination, package and so on. He seemed to have raided a thesaurus for all the useful collective nouns, then given them hyper-precise definitions.

One last try:

Me (desperate now)— “I have a posse of parameters...”

Developer— “Ah, but those are not parameters, those are attributes. You see the distinction lies in ...”

This is exaggerated (slightly) for humor, but the point is valid: we must be careful not to over-specify the language.

A Standard Vocabulary?

Throughout the industry we all use terms like Asset or Publish without definition. We all assume “we know what we mean,” and yet we all know we mean something different. So our late night SIGGRAPH drinking conversations are tricky.

After much thought I'm convinced we cannot standardize all the definitions. Each project is different enough, and the technology is changing rapidly enough, that our definition of Asset, say, needs to change with each project.

But we can standardize some of them. I propose we need to think about precision in layers.

As illustrated above, we need some undefined terms like Attribute and Group. Perhaps a better description is commonly defined terms—they mean what you think they mean.
Then we need a layer of precisely defined terms, like Path Override and Adapter. This layer relies on the undefined terms for its definition.
Then we can discuss Asset in these terms. We can say things like: At our studio an asset is this in terms of standard terminology and patterns.

So at one studio, an asset is a static assembly of workflow specific run-time representations which are converted on publish, tracked in a revision list, and subscribed to by multi-level indirection and path overrides.

Whereas at another studio, an asset is a dynamic assembly of adapters and run-time representations which are converted and cached on subscription, which occurs by query on metadata.