Shaders in Processing 2.0 beta

Processing 2.0 beta was finally released a couple of weeks ago, with the 2.0b3 version being the latest release in the beta series at this time. The new shader API described in the previous posts (1, 2, and 3) received some tweaking and cleaning-up, so the examples mentioned earlier might not work properly. Check below for a more detailed description of the shader API updates in the beta.
Update: With the release of Processing 2.0 final, some of the contents in this post are outdated, please check this tutorial for a detailed description of the finalized shader API.

The basic structure of the shader mechanism in Processing 2.0 beta remains the same as in the latest alphas, with shaders being classified by Processing in 6 types depending on the class of geometry they are meant to render:

1. filled polygons without lights and textures
2. filled polygons with lights but without textures
3. filled polygons with textures but without lights
4. filled polygons with lights and textures
5. stroke geometry (lines)
6. points

In the alphas, the type of shader had to be specified explicitly when loading the GLSL code, by means of a PShader constant (FLAT, LIT, TEXTURED, FULL, LINE, POINT). This is not longer the case, since the shader type is automatically determined by Processing by examining the GLSL source code. As described in this previous post, each shader type must expose a certain number of uniform and attribute variables needed to handle the geometry. So for example, if the vertex shader being loaded declares a vec4 attribute named “inLine”, then Processing will try to use that shader to render stroke lines.

A shader should be set immediately before the drawing calls that should be rendered by it, and once it is used the resetShader() call should be issued to restore the default shaders:

PImage img;
PShader edges;
void setup() {
  size(640, 360, P2D);
  img = loadImage("leaves.jpg");      
  edges = loadShader("edges.glsl");
  ...
}

void draw() {  
  shader(edges);  
  // Render image using shader edges.  
  image(img, 0, 0);
  resetShader();

  // Further images will be rendered with the
  // default shader for textures.
  ...
}

In this code example, the shader edges should be capable of handling textures, which means that it needs to have a vec2 attribute named “inTexcoord” to stores the texture coordinates of the image. If Processing doesn’t find this attribute in the GLSL code, then it will print a warning message and then use its own default shader for rendering textures.