• There have been a lot of fantastic games and demos made for WebGL, but that makes it particularly cool to see someone building something different. iChemLabs have just released a 3D library for modelling molecules using WebGL (click the “3D” button at the top to get the WebGL version). They have an overview page showing a bunch of different kinds of views of various molecules, and a page demonstrating their MolGrabber3D canvas where you can pick the drug whose molucule you want to see and can change the kind of representation you want to see it in. There’s also a nice 8-minute overview video, so you can see what they’re up to even if you don’t have WebGL setup on your machine, and a written overview for the MacResearch community site. So that’s chemistry done, any astrophysicists or geologists out there working with WebGL? :-)
• Not strictly WebGL, but it’s using it under the hood: Andor Salga has built a web-based mini-IDE for the Processing.js port of the Processing 3D language.
• A simple demo: drawing cartoon animations using C3DL.

• In the earliest WebGL demos, Vladimir Vukićević used the Sylvester library for vector and matrix maths; it’s convenient, well-written, well-documented, and open source. Pretty much everyone else followed suit. However, its very general-purpose nature means that it can’t be as fast as a specialised library focusing on the specific kinds of calculations we need for 3D graphics. So, he’s started a new project called mjs, to provide just the really simple vector and matrix maths we need, and to do it really quickly. He’s getting pretty encouraging results on his benchmarks, with JITed calculations being more than ten times as quick, and un-JITed at least twice as fast. [UPDATE I've tried porting the upcoming lesson 14 to it, and it works fine. No performance figures yet, though.]
• Another important part of building 3D scenes is getting models designed in 3D graphics programs into your JavaScript code. People are working on tools to import existing 3D graphics formats like 3DS, but an alternative route is to get the 3D modelling tool to output JSON or some other format you can easily read. Paul Brunt’s GLGE has some support for doing this from Blender, but Dennis Ippel has just announced a project that makes exporting from Blender to WebGL code its main focus. So far it exports to SceneJS, but a generic WebGL version is on its way. It’s not ready to download yet, but will be soon.
• Another 3D library for WebGL, this one with its own editor! CopperLicht is definitely worth a look.

• A new interview with a WebGL library creator at 3D test: this time, it’s Marco Di Benedetto on SpiderGL. Well worth a read.
• GLGE has forums! It looks like a good place not just for discussing the library, but also WebGL in general.
• Peter Strohm has added more to his WebGL lessons in German; there are now tutorials on adding interaction, and textures.
• gwt-g3d, one of the three independent projects to create a Google Web Toolkit binding for WebGL, now includes ports of my first 12 lessons as part of its demos. I’m flattered :-) — but additionally, that suggests things have moved on quite a bit since it was announced at the end of December. Its competitors, WGT and GwtGL seem to be coming along nicely too.

Finally, some good news about the next tutorial on this blog: the page for lesson 14 — which covers specular highlights — is pretty much done, as is the video for people who don’t have WebGL-enabled browsers. Now it’s “just” a question of writing about it :-S

• Over at 3D test, an interview with Paul Brunt of GLGE fame — well worth reading.
• On thing that’s going to be important for WebGL going forward is the ability to load up objects that have been designed in 3D modeling tools like Blender, Autodesk 3D Studio or Google SketchUp. There are two ways of doing this — by converting the tools’ files into a JavaScript-friendly format like JSON, or by writing code to load the files directly in JavaScript. Tim Knip has started work on the latter kind: js3ds, a 3DS import library for JavaScript.
• A very neat (Firefox-only) demo from murphy: using a web page as a texture on a WebGL object.
• An impressive (new?) X3DOM demo that I’ve not seen before: floating objects with shadows.
• Some interesting news about the WebGL spec — a while back, Vladimir Vukićević suggested that the WebGLArrayBuffer and WebGL*Array types would be useful outside WebGL. He’s now started moving their definition into a specification of their own. If this goes ahead, and they are broken out of WebGL, then we’ll probably have to change our pages once again — after all, if they’re not WebGL-specific then they won’t have “WebGL” in their names. One to keep an eye on…
• Finally, Benjamin DeLillo reports that he’s moved WebGLU to github (an excellent idea) and shows that the latest version of his library makes his 50-line demo an even more impressive 25 lines!

• Benjamin DeLillo has been quiet for a while, but he’s been working hard on WebGLU, adding (among other things) keyframe animation, image and video-based textures, shader loading from external files, and the beginning stages of import capabilities for .obj files (a common format for 3D models). His blog post gives more information, including a very cool example of a 360° video.
• Paul Brunt’s GLGE improves in leaps and bounds; he’s now added fog effects.
• Lindsay Kay’s SceneJS has now gained the ability to override certain rendering parameters in specific subtrees of the scene graph.

Here’s what the lesson looks like when run on a browser that supports WebGL:

Click here and you’ll see the live WebGL version, if you’ve got a browser that supports it; here’s how to get one if you don’t. You’ll see a sphere and cube orbiting; both will probably be white for a few moments while the textures load, but once that’s done you should see that the sphere is the moon and the cube a (not-to-scale) wooden crate; the scene is similar to the one we had for lesson 12, but we’re closer to the orbiting objects so that you can see more clearly what they look like. As before, both are illuminated by a point light source that is in between them, and if you want to change the light’s position, colour, etc., there are fields beneath the WebGL canvas, along with checkboxes to switch lighting on and off, to switch between per-fragment and per-pixel lighting, and to use or not use the textures.

Try toggling the per-fragment lighting on and off. You should be able to see the difference on the crate pretty easily; the centre is obviously brighter with it switched on. The difference with the moon is more subtle; the edges where the lighting fades out are smoother and less ragged with per-fragment lighting than they are with per-vertex. You will probably be able to see this more easily if you switch off the textures.

More on how it all works below…

The usual warning: these lessons are targeted at people with a reasonable amount of programming knowledge, but no real experience in 3D graphics; the aim is to get you up and running, with a good understanding of what’s going on in the code, so that you can start producing your own 3D Web pages as quickly as possible. If you haven’t read the previous tutorials already, you should probably do so before reading this one — here I will only explain the new stuff. The lesson is based on lesson 12, so you should make sure that you understand that one (and please do post a comment on that post if anything’s unclear about it!)

There may be bugs and misconceptions in this tutorial. If you spot anything wrong, let me know in the comments and I’ll correct it ASAP.

There are two ways you can get the code for this example; just “View Source” while you’re looking at the live version, or if you use GitHub, you can clone it (and the other lessons) from the repository there.

Let’s kick off by describing exactly why it’s worth taking up more graphics processor power by coding per-fragment lighting. You may remember the diagram to the left from lesson 7. As you know, the brightness of a surface is determined by the angle between its normal and the incoming rays of light from the light source. Now, so far, our lighting has been calculated in the vertex shader by combining the normals specified for each vertex with the lighting direction from it. This has provided a light-weighting factor, which we’ve passed from the vertex shader to the fragment shader in a varying variable, and there used to vary the brightness of the colour of the fragment appropriately. This light-weighting factor, like all varying variables, will have been linearly interpolated by the WebGL system to provide values for it for the fragments that lie between the vertices; so, in the diagram, B will be quite bright because the light is parallel with the normal there, A will be dimmer because the light is reaching it at more of an angle, and points in between will shade smoothly between bright and dim. This will look just right.

But now imagine that the light is higher up, as in the diagram to the right. A and C will be dim, as the light reaches them at an angle. We are calculating lighting at the vertices only, and so point B will have the average brightness of A and C, so it will also be dim. This is, of course, wrong — the light is parallel the surface’s normal at B, so it should actually be brighter than either of them. So, in order to calculate the lighting at fragments between vertices, we obviously need to calculate it separately for each fragment.

Calculating the lighting for each fragment means that for each one we need its location (to work out the direction of the light) and its normal; we can get these by passing them from the vertex shader to the fragment shader. They will both be linearly interpolated, so the positions will lie along a straight line between the vertices, and the normals will vary smoothly. That straight line is just what we want, and because the normals at A and C are the same, the normals will be the same for all of the fragments, which is perfect too.

So, that all explains why the cube in our web page looks better and more realistic with per-fragment lighting. But there’s another benefit, and this is that it gives a great effect to shapes made up of flat planes that are meant to approximate curved surfaces, like our sphere. If the normals at two vertices are different, then the smoothly-changing normals at the intervening fragments will give the effect of a curving surface. When considered in this way, per-fragment lighting is a form of what is called Phong shading, and this picture on Wikipedia shows the effect better than I could explain in several thousand words. You can see this in the demo; if you use per-vertex lighting, you can see that the edge of the shadow (where the point light stops having an effect and the ambient lighting takes over) looks a bit “ragged”. This is because the sphere is made up of many triangles, and you can see their edges. When you switch on per-fragment lighting, you can see that the edge of this transition is smoother, giving a better effect of roundness.

Right, that’s the theory out of the way — let’s take a look at the code! The shaders are at the top of the file, so lets take a look at them first. Because this example uses either per-vertex or per-fragment lighting, depending on the setting of the “per-vertex” checkbox, it has vertex and fragment shaders for each kind (it would be possible to write shaders that could do both, but they would be harder to read). The way that we switch between them is something we’ll come to later, but for now you should just note that we distinguish between them by using different id tags when defining them as scripts in the web page. The first to appear are the shaders for per-vertex lighting, and they’re exactly the same as the ones we’ve been using since lesson 7, so I will just show their script tags so that you can match them up with what you will see if you’re following through in the file:

<script id="per-vertex-lighting-fs" type="x-shader/x-fragment">

<script id="per-vertex-lighting-vs" type="x-shader/x-vertex">

Next comes the fragment shader for per-fragment lighting.

<script id="per-fragment-lighting-fs" type="x-shader/x-fragment">
  varying vec2 vTextureCoord;
  varying vec4 vTransformedNormal;
  varying vec4 vPosition;

  uniform bool uUseLighting;
  uniform bool uUseTextures;

  uniform vec3 uAmbientColor;

  uniform vec3 uPointLightingLocation;
  uniform vec3 uPointLightingColor;

  uniform sampler2D uSampler;

  void main(void) {
    vec3 lightWeighting;
    if (!uUseLighting) {
      lightWeighting = vec3(1.0, 1.0, 1.0);
    } else {
      vec3 lightDirection = normalize(uPointLightingLocation - vPosition.xyz);

      float directionalLightWeighting = max(dot(normalize(vTransformedNormal.xyz), lightDirection), 0.0);
      lightWeighting = uAmbientColor + uPointLightingColor * directionalLightWeighting;
    }

    vec4 fragmentColor;
    if (uUseTextures) {
      fragmentColor = texture2D(uSampler, vec2(vTextureCoord.s, 1.0 - vTextureCoord.t));
    } else {
      fragmentColor = vec4(1.0, 1.0, 1.0, 1.0);
    }
    gl_FragColor = vec4(fragmentColor.rgb * lightWeighting, fragmentColor.a);
  }
</script>

You can see that this is very similar to the vertex shaders that we’ve been using so far; it does exactly the same calculations to work out the direction of the light and to then combine that with the normal to calculated a light weighting. The difference is that the inputs to this calculation now come from varying variables rather than per-vertex attributes, and the resulting weighting is immediately combined with the texture colour from the sample rather than passed out for processing later. It’s also worth noting that we have to normalise the varying variable that contains the interpolated normal; normalising, you will remember, adjusts a vector so that its length is one unit. This is because interpolating between two length-one vectors does not necessarily give you a length-one vector, just a vector that points in the right direction. Normalising them fixes that. (Thanks to Glut for pointing that out in the comments.)

Because all of the heavy lifting is being done by the fragment shader, the vertex shader for per-fragment lighting is really simple:

<script id="per-fragment-lighting-vs" type="x-shader/x-vertex">
  attribute vec3 aVertexPosition;
  attribute vec3 aVertexNormal;
  attribute vec2 aTextureCoord;

  uniform mat4 uMVMatrix;
  uniform mat4 uPMatrix;
  uniform mat4 uNMatrix;

  varying vec2 vTextureCoord;
  varying vec4 vTransformedNormal;
  varying vec4 vPosition;

  void main(void) {
    vPosition = uMVMatrix * vec4(aVertexPosition, 1.0);
    gl_Position = uPMatrix * vPosition;
    vTextureCoord = aTextureCoord;
    vTransformedNormal = uNMatrix * vec4(aVertexNormal, 1.0);
  }
</script>

We still need to work out the vertex’s location after the application of the model-view matrix and multiply the normal by the normal matrix, but now we just stash them away in varying variables for later use in the fragment shader.

That’s it for the shaders! The rest of the code will be pretty familiar from the previous lessons, with one exception. So far, we’ve only used one vertex shader and one fragment shader per WebGL page. This one uses two pairs, one for per-vertex lighting and one for per-fragment lighting. Now, you may remember from lesson 1 that the WebGL program object that we use to pass our shader code up to the graphics card can have only one fragment shader and one vertex shader. What this means is that we need to have two programs, and switch which one we use based on the setting of the “per-fragment” checkbox.

The way we do this is simple; our initShaders function is changed to look like this:

  var currentProgram;
  var perVertexProgram;
  var perFragmentProgram;
  function initShaders() {
    perVertexProgram = createProgram("per-vertex-lighting-fs", "per-vertex-lighting-vs");
    perFragmentProgram = createProgram("per-fragment-lighting-fs", "per-fragment-lighting-vs");
  }

So, we have two programs in separate global variables, one for per-vertex lighting and one for per-fragment, and a separate currentProgram variable to store the one that’s currently in use. The createProgram we use to create them is simply a parameterised version of the code we used to have in initShaders, so I won’t duplicate it here.

We then switch in the appropriate program right at the start of the drawScene function:

  function drawScene() {
    gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT)

    perspective(45, 1.0, 0.1, 100.0);

    var perFragmentLighting = document.getElementById("per-fragment").checked;
    if (perFragmentLighting) {
      currentProgram = perFragmentProgram;
    } else {
      currentProgram = perVertexProgram;
    }
    gl.useProgram(currentProgram);

We have to do this before anything else because when we do drawing code (for example setting uniforms or attaching buffers of per-vertex attributes to attributes) we need the current program to be appropriately set up, as otherwise we might use the wrong program:

    var lighting = document.getElementById("lighting").checked;
    gl.uniform1i(currentProgram.useLightingUniform, lighting);

You can see that this means that for each call to drawScene we use one and only one program; it differs only between calls. If you’re wondering whether or not you could use different shader programs at different times within drawScene, so that different parts of the scene were drawn with different ones — perhaps some of your scene might use per-vertex lighting and some per-pixel — the answer is yes! It wasn’t needed for this example, but is perfectly valid and can be useful.

Anyway — with that explained, that’s it for this lesson! You now know how to use multiple programs to switch shaders, and how to code per-pixel lighting. Next time we’ll look at the last bit of lighting that was mentioned in lesson 7: specular highlights.

<< Lesson 12

Acknowledgments: As before, the texture-map for the moon comes from NASA’s JPL website, and the code to generate a sphere is based on this demo, which was originally by the WebKit team. Many thanks to both!

Anyhow, this was such a nice change that I decided to push it back into the older lessons. Here’s an example of what the new code looks like — first, the new initShaders from lesson 1:

  var shaderProgram;
  function initShaders() {
    var fragmentShader = getShader(gl, "shader-fs");
    var vertexShader = getShader(gl, "shader-vs");

    shaderProgram = gl.createProgram();
    gl.attachShader(shaderProgram, vertexShader);
    gl.attachShader(shaderProgram, fragmentShader);
    gl.linkProgram(shaderProgram);

    if (!gl.getProgramParameter(shaderProgram, gl.LINK_STATUS)) {
      alert("Could not initialise shaders");
    }

    gl.useProgram(shaderProgram);

    shaderProgram.vertexPositionAttribute = gl.getAttribLocation(shaderProgram, "aVertexPosition");
    gl.enableVertexAttribArray(shaderProgram.vertexPositionAttribute);

    shaderProgram.pMatrixUniform = gl.getUniformLocation(shaderProgram, "uPMatrix");
    shaderProgram.mvMatrixUniform = gl.getUniformLocation(shaderProgram, "uMVMatrix");
  }

So, you can see that it stores the attributes and uniforms as fields in the program object. This means that setMatrixUniforms can be simplified, as it no longer needs to look up uniforms:

  function setMatrixUniforms() {
    gl.uniformMatrix4fv(shaderProgram.pMatrixUniform, false, new WebGLFloatArray(pMatrix.flatten()));
    gl.uniformMatrix4fv(shaderProgram.mvMatrixUniform, false, new WebGLFloatArray(mvMatrix.flatten()));
  }

…and also, the code in drawScene needs a small adjustment to pick up the attribute locations from the program object rather than the no-longer-existent global variables:

    gl.bindBuffer(gl.ARRAY_BUFFER, triangleVertexPositionBuffer);
    gl.vertexAttribPointer(shaderProgram.vertexPositionAttribute, triangleVertexPositionBuffer.itemSize, gl.FLOAT, false, 0, 0);
    setMatrixUniforms();
    gl.drawArrays(gl.TRIANGLES, 0, triangleVertexPositionBuffer.numItems);

Right, hopefully I can get round to writing up lesson 13 properly now, it’s been too long coming!

• Another very cool graphics-card overloading page from the demo scene guys, who specialise in creating very cool scenes using jaw-droppingly tiny amounts of code, all in the fragment shaders. This one’s called Four Dollar Plastic Laminator, it’s apparently a 1k demo (meaning it’s all coded in just one kilobyte of fragment shader!), and if your GPU’s not powerful enough to view it, you can see it on YouTube here.
• A very cool demo in a different way; this one is unfortunately only on YouTube, but it shows a model taken from World of Warcraft, exported to X3D, and then displayed in a Web browser using X3DOM, which is built on WebGL. Very impressive!
• Finally, two examples of terrain mapping in WebGL, which both look pretty promising.