The above shader contains only a simple model and thus it is not very flexible. It can be generalized by adding more parameters, by making the parameters into tuples, by making them recursive structures, and so on. The generalization process eventually leads to a shader that includes a small interpreter that implements a shading language. The core of Pixar's RenderMan(tm) system is exactly this [RenderMan]. Here is a program written in `the' shading language---a shader---that produces a checkerboard similar to the previous example.

surface checker(float Kd         = 0.5,
                      Ka         = 0.1,
                      frequency  = 10;
                color blackcolor = color(0,0,0))
{
   float smod = mod(s * frequency, 1),
         tmod = mod(t * frequency, 1);

   if (smod < 0.5) {
      if (tmod < 0.5)
         Ci = Cs;
      else
         Ci = blackcolor;
   } else {
      if (tmod < 0.5)
         Ci = blackcolor;
      else
         Ci = Cs;
   }
   Oi = Os;
   Ci = Oi * Ci * (Ka * ambient() +
                   Kd * diffuse(faceforward(normalize(N), I)));
}

RenderMan has a number of features that make it particularly easy to write shaders. Short vectors are highly integrated (arithmetic operators work on vectors, and scalars and vectors); it has special global variables (eg s and t above); it knows how to sum over lights (eg ambient, illuminance); and can even do derivatives (implemented numerically) with respect to the special variables.

Note that the above program is a (static) argument to the shading interpreter, while the code in the previous shading procedure example is the interpreter.

Pixar's implementation (prman) uses a buffered interpreter (see buffering) to evaluate a shading procedure (which describes how to shade one point on a surface) over a mesh of micropolygons. Pixar's implementation performed very well when it was originally designed (usually within 90% [Peachey94] of compilation, though that was many years ago).

Pixar could have built an implementation that compiled shaders into C, then compiled them with the local C compiler, and finally dynamically loaded the code. But this requires painfully tricky and non-portable code. Furthermore, if the system were interactive the time spent compiling code might introduce an unacceptably long pause.

Recent research from Microsoft indicates compiling shaders and specializing them to particular surface properties has great benefits (as much as 100x) for interactive modeling.

What if Alvy Ray Smith and Darwyn Peachey had had tools like DCG and `C [tick-C]? The portability (OS and architecture) code could be isolated, while bringing the overhead () way down.

This concludes our discussion of compilation and RTCG. Next, compiler generation via partial evaluation is presented as a tool for achieving lightweight languages.