Website Pages:

Welcome to Pipeline Design Patterns
Vocabulary
A Theory of Pipeline
Pipeline Design Patterns
Case Studies
Big Animation Studio, Circa 2000

Sections in this Page:

Big Animation Studio, Circa 2000
Overview
Modeling and Shading
Projective Paint
Set Construction
Shot Creation, Animation, Lighting

Definitions:

A Vocabulary for Diagrams
Glossary

Big Animation Studio, Circa 2000

This was the first production pipeline I ever worked in (1997-2001). To the five people who remember it better, my apologies.

pixar1
Click on diagram to Zoom/Unzoom.

Overview

This case study covers the pipeline steps to make and render a simple prop. The diagram is divided into panels.

Server Level — the top panel spanning the pipeline. It has a lower sub-level for the server file system, and an upper sub-level for source control.


On the lower level, each panel represents a workflow stage for a single artist. Left to right indicates stage order, in time.

Modeling/Shading — First panel. Geometry, shader setup (binding), shader authoring, and simple texture painting.

Projective Paint — Second panel. Paint (projective camera) setup and texture painting.

Set Creation — Third panel. Aggregation of references to models.

Shot-Based Work — The last few panels. Separate workspaces for shot creation, animation, and lighting.


Coming soon: diagrams for Rendering, Rigging, FX, and Master Lighting.

Modeling and Shading

pixar1_model
Click on diagram to Zoom/Unzoom.

Overall, this stage implements a Server L-Shape with a U-Shape on the Sandbox/Workspace. (Note how this simple shape-based description conveys a lot of info.)

The resulting asset is subscribed to by Pin-to-Latest.


In detail:

Model

pixar1_model1
Click on diagram to Zoom/Unzoom.

Models were built in Alias Power Animator, then saved, then converted into three files:

Model structure— the overall framework of the model, including scopes and universal stuff that all models needed.

Geometry— the polymesh, in a format amenable for downstream display.

Shader Bindings — an initial skeleton framework, meant to be edited in the next step. This is the Hack Pattern.

Shader Bindings

pixar1_sbind
Click on diagram to Zoom/Unzoom.

Shader bindings were written manually, using a text editor. To be clear, this was fragile workflow. If we repeated the model conversion, we had to take care not to stomp this file.

It was considered a minor art form to craft a tight shader binding that exposed the correct controls for downstream specialization.

Shader and Texture

pixar1_shader
Click on diagram to Zoom/Unzoom.

Shaders were also written manually, in RenderMan Shading Language. (These were early days, before shader node graphs and co-shaders.) Again, it was an art form to write convincing, performant shaders.

The shaders were compiled manually, using nshader.

If the shaders needed projective paint, they included a reference to the upstream paint setup. In this case, the compilation step baked the paint projection matrices into compiled shader code.

Texture

pixar1_tex
Click on diagram to Zoom/Unzoom.

Most shaders were procedural, unless they needed projective paint (next stage).

Often we'd use simple textures —like generic wood-grain or marble— to drive other calculations. We'd paint these with a simple paint program, using Tiff or other format, then export them to a mip-mapped texture format. Here I've indicated that the conversion was via plugin export.

Projective Paint

pixar1_paint
Click on diagram to Zoom/Unzoom.

Overall, this stage implements a C-Shape with a Server L-Shape which implements Build on the Head Revision.

The resulting asset is subscribed to by Pin-to-Latest.


The general workflow was:

Paint Setup

The artist aimed paint cameras at the object. These defined projection matrices — one projection for each paint texture. The references to the textures were embedded in the paint setup. In a sense, the paint setup is an Aggregation of Specialized texture instances. where the specialization parameters are the projection matrices.

Remember, this was all in the days before robust UV texturing workflows.

Paint

Once the cameras were placed, background images of the object were rendered. These temporary handoff files were used as background layers in a full-on paint program. The artistic input was painted in a separate layer, which was converted to texture format.

The conversion was a filter which extracted only the foreground layers and discarded the temporary background layers.


Again, this was a very fragile workflow. Any change to the upstream model, or to the paint cameras, would invalidate the painstaking work done by the artist.

Set Construction

pixar1_set
Click on diagram to Zoom/Unzoom.

Overall, this stage implements the left-hand vertical part of an H-Shape which drives rendering. I need to add that to the diagrams.

Editing happens in a Sandbox / Workspace, and the resulting asset is accessed via the Server Head Revision.

Set Aggregation

pixar1_set1
Click on diagram to Zoom/Unzoom.

The set data is a manifest of references to models, along with parameters for Object Specialization and Instance Specialization.

Shot Creation, Animation, Lighting

pixar1_shot
Click on diagram to Zoom/Unzoom.

Again, each stage implements the left-hand vertical part of a H-Shape, which drives rendering. Coming soon.

Also again, editing happens in a Sandbox / Workspace, and the resulting asset is accessed via the Server Head Revision.

Shot Creation

Layout Artists created shots, which were an Assembly of References to Set, Character, Animation, and Lighting data.

These references were to work by other artists. In addition the Layout Artists added work of their own: Camera information such as lenses, framing, blocking, etc. — the traditional domain of a Director of Photography.