Bake / Baking

Baking is caching one set of data in the context of another.

There are three types we'll discuss here:

Baked Reference
Baked Evaluation
Baked Response

Bake vs Cache

These terms are sometimes used interchangeably. But more often, in common usage, we seem to maintain a distinction between the two:

Every bake is a cache, but not every cache is a bake.

The distinction in common usage seems to be that Bake applies when there are two sets of data involved. We say things like:

The reference to A has been baked in B.
The data from A has been baked into B.
The response to A has been baked into B.

So to be specific, we might cache the translation of one geometry format to another. But if during translation we incorporate animation data into the new data, then we'd say the animation was baked into the geometry.

I'll maintain this distinction throughout the web/book.

Baked Reference

Click on diagram to Zoom/Unzoom.

This is the simplest type of baking.

In the above diagram, the Geo File contains data of its own, plus a reference to Animation Data. The Output Geo File simply contains both sets of data.

We represent the data with squares to indicate geo data in geo format, and animation data in animation format.

Example

Here is a simple example to make this concrete, and to set up the next section. We have a unit cube with one corner at the origin. It is being animated along a linear path.

Prior to baking the reference:

# animation file
#   filename = OtherFile

tx = linear(frame=0, tx=10, frame=5,tx=20)
# i.e. tx will take on values 10, 12, 14, 16, 18, 20

The geometry file brings this data in by reference. From a pipeline perspective, this allows the animation to change independently of the geometry.

# geometry file with reference
#   filename = InputFile

include animation.data      # this is the reference

cube_points = [
    (0,0,0),
    (1,0,0),
    (0,1,0),
    (0,0,1),
    (1,1,0),
    (0,1,1),
    (1,0,1),
    (1,1,1),
]

After baking the reference:

# geometry file with no reference
#   filename = OutputFile

tx = linear(frame=0, tx=10, frame=5,tx=20)
# i.e. tx will take on values 10, 12, 14, 16, 18, 20

cube_points = [
    (0,0,0),
    (1,0,0),
    (0,1,0),
    (0,0,1),
    (1,1,0),
    (0,1,1),
    (1,0,1),
    (1,1,1),
]

Again, this is the diagram:

Click on diagram to Zoom/Unzoom.

Baked Evaluation

Example: Pose Caching

This is the classic example. People often call this animation baking.

Click on diagram to Zoom/Unzoom.

The big difference from the previous example is that the baking step evaluates the geometry and animation and stores the data back in the geometry format.

For this reason we say: The animation has been baked into the geometry.

We represent the baked data with a circle to indicate it is not in the original format.

Building off the previous example, this is conceptually what the data looks like.

# geometry file with baked animation

# pose_data:

frame = 0
tx    = 10
cube_points[frame] = [
    (10,0,0),
    (11,0,0),
    (10,1,0),
    (10,0,1),
    (11,1,0),
    (10,1,1),
    (11,0,1),
    (11,1,1),
]

frame = 1
tx    = 12
cube_points[frame] = [
    (12,0,0),
    (13,0,0),
    (12,1,0),
    (12,0,1),
    (13,1,0),
    (12,1,1),
    (13,0,1),
    (13,1,1),
]
# etc.

Baked Response

This pattern is used to optimize the evaluation of a Complex Signal in the context of an Asset.

Click on diagram to Zoom/Unzoom.

Specific examples include:

Lighting — We want to evaluate the environment lighting (Result) in a set or game level (Asset) in response to artist placed lights (Complex Signal). To be specific: we have rich setdressing environment with lots of models. We want to add and move lights and get a fast lighting result.

Cloth Simulation — We want to evaluate the secondary animation response (Result) of a garment (Asset) in response to the character animation (Signal). To be specific: our character has a sleeve on her dress. We want to change animation and get a fast recalculation of how the sleeve reacts.

The assumption is that the signal is changing more frequently than the asset, so it makes sense to do some asset-specific pre-calculation.

Overview

It replaces the evaluation with three processes:

pre-calculation — this is the Baking step — the slow step. This is essentially prepping the Asset for fast calculation.
decomposition. This is essentially prepping the Signal for fast calculation.
final (fast) calculation.

Click on diagram to Zoom/Unzoom.

Decomposition into Basis

The Baked Response pattern applies when we can decompose the complex signal into a well defined basis space, and the calculation is linear (or appoximately linear) with respect to this process.

For example, we can decompose certain types of lighting in terms of spherical harmonics, or certain types of animation in terms of a deformation basis. (Often the basis can depend on the asset, as the deformation basis does. I'll cover that in a future pattern.)

In pseudocode, we have:

# the calculation
R = f(S, A)             # f = the calculation
                        # S = signal
                        # A = asset
                        # R = response for this asset and signal

# decomposition
S = sum(w, B)           # w = decomposition weights
                        # B = basis signal

# thus
R = f( sum(w,B), A )
  = sum( w, g(B,A) )    # g = linear approximation to f
                        #     note: g == f if f is linear
  = sum( w, Z )         # Z = linear response for this asset and basis signal
                        #     this is what we bake back into the Asset

Note: my intent here is not to explain basis decomposition, but rather to explain how to represent the concept in diagrams.

The diagram of this looks like:

Click on diagram to Zoom/Unzoom.

Pre-Calculation / Basis Evaluation

Just as we can evaluate the original Signal in the context of the Asset, we can do the same for the Basis Signals. Each evaluation gives a Basis Response which is specific to that Basis and Asset combination.

Click on diagram to Zoom/Unzoom.

Now put these two together:

Click on diagram to Zoom/Unzoom.

Baked Evaluation vs Baked Response

In both cases, we are evaluating how an asset reacts to a signal. The asset is typically a character or prop or set element. The signal can be animation (i.e. time-varying inputs which drive rig controls), or lighting (i.e. a list of light locations, directions, colors, intensities, falloffs, etc.), or something else like a force or density function or etc.

Typically, the signal is owned by some aggregation structure like a shot or set level, which is distinct from the asset.

With this framework, we can say

Baked Evaluation stores the calculation with the Shot, i.e. the thing that owns the signal. In this pattern the baked evaluation obviates the signal.
Baked Response stores the calculation with the Asset. In this pattern the signal needs to be decomposed into its components, and the response of the asset to the component is what is precalculated.

Baked Response vs Conform

Recall our decomposition step:

Click on diagram to Zoom/Unzoom.

The decomposition stores a weight for each basis signal. Drawn this way, the decomposed signal is really an aggregation of references to the basis, and the references are specialized by the decomposition weights.

These references may be just conceptual, as in the case of spherical harmonics. In that case the decomposed signal is simply a list of weights, and for example, the third weight refers (conceptually) to the third spherical harmonic basis function.

This description of the decomposed data is perhaps a little non-intuitive, — and certainly is non-standard — but it is accurate, and it sets up what follows.

“Conform”

The next step is simply to translate the Aggregation of Basis References into Aggregation of Basis Responses, applying the same weight values.

Click on diagram to Zoom/Unzoom.

In other words, we have an aggregation, and we are switching references while applying the same specializations. In addition, the reference mapping is intrinsic, supplied by the asset. This is the definition of Conform Using Assets.

Here is the relevant diagram from that pattern page:

Click on diagram to Zoom/Unzoom.

Note: I'm not advocating using the term “Conform” in this way. I think the standard industry usage is restricted to changes of representation level, such as low-res to high-res. But it's interesting to see the commonality in our patterns.

Example: Rendering

Click on diagram to Zoom/Unzoom.

In a sense, Render Prep is Baking. Typically, renderers read a baked bormat, so the role of prep is to create that.

In this diagram we see a typical render job with a daisy chain of internal references.

The Shot refers to the Camera, the Lights, and the Set.
The Set refers to Models.
Models refer to Geo and Shaders.

After the render prep process, most of the references are flattened, or Baked, into actual data in the prep file. The only references that remain are to the Shaders.

Note

We are using the diagramming shortcut:

left-pointing triangles represent internal references within a structure;
large triangles with stems represent references which are more widely separated.

Both are equivalent. The downstream (referring) file contains a pointer to the upstream file (the file referred to), via include, import, load, or other construct.