previous | next | writing shaders: contents | rmannotes: top

Introduction

When writing shaders, as with most programming tasks, there are many ways to solve the same problem. The flexibility of the shading language is what makes it powerful, but also difficult for beginning shader writers. This section of RManNotes presents a general methodology for writing shaders and specific techniques and conventions for writing surface shaders and displacement shaders. All shaders listed in RManNotes follow the conventions described in this section.

The techniques presented here are not necessarily the best way and are certainly not the only way to write shaders. In fact, there may be times when these techniques don't work at all for a shader that you're trying write. But, these techniques have worked well for myself and my students (who often have little or no programming experience) for most shader-writing tasks.

Why Follow a Methodology?

I'm not encouraging you to be a conformist, but there are some good reasons for following the methodology presented:

• it reduces the "cognitive load" of writing a shader. That is, it gives you some rules and a basic pattern that you can follow when writing a new shader -- i.e. you don't start with a completely blank page;
• all of your shaders will have a similar format. This will make understanding your shader 6 months from now a lot easier. You'll also be able to more easily understand shaders written by other people who follow the same (or a similar) methodology and vice versa; and
• it should be easier to re-use parts of an existing shader in a new shader because a) your shaders will have similarities in structure and naming conventions and b) the "layered approach" breaks a shader down into independent, reusable layers.

The Layered Approach

One of the most fundamental problem solving techniques is "divide and conquer." That is, break down a complex problem into simpler parts; solve the simpler parts; then combine those parts to solve the original complex problem.

In shaders, we'll break down complicated surface patterns and texture into layers. Each layer should be fairly easy to write (if not, then we can break the layer into sub-layers). Then, we'll combine the layers by compositing. For example, to write a "banana" surface shader we would develop separate layers for each component of the overall surface appearance: the yellow-green coloration, the fibers of the banana peel, the bruises, the insect bites, and the illumination (shading based on light sources).

We'll always define the layers from back to front (as we read the shader from top to bottom) and composite each layer as we go. The banana surface shader pseudo-code might look something like:

surface banana(...)
{
  /* background (layer 0) */

  surface_color = yellow-green variations;

  /* layer 1 */

  layer = fibers;
  surface_color = composite layer on surface_color;

  /* layer 2 */

  layer = bruises;
  surface_color = composite layer on surface_color;

  /* layer 3 */

  layer = bites;
  surface_color = composite layer on surface_color;

  /* illumination */

  surface_color = illumination based on surface_color and illum params;

  /* output */

  Ci = surface_color;
}

previous | next | writing shaders: contents | rmannotes: top

Last Modified: 5/6/96