WebGL and Shaders

WebGL is the browser’s interface to the graphics card. GLSL is the language you write the programs that run on it. Everything else in this set of notes sits on top of those two things.

Drawing in 3D on the web involves four layers, and it helps to know which layer a given problem belongs to before you start debugging it.

Where This Fits

This is the entry point for the set, and the only note that spans every layer. The rest are named for the layer they belong to, so the prefix tells you what kind of note you are opening before you read a word of it:

Prefix	Layer	Changes when
Graphics Data	The vertex data any renderer works with	Effectively never
Rendering Engines	Concepts three.js supplies on top of WebGL	The engine’s API changes
GLSL	The shader language and how it is fed	Effectively never
Tooling	Build steps and harnesses around the work	A tool is replaced

The right-hand column is the useful part. Two of the four layers are stable enough to learn once, which is where these notes spend most of their time.

The Layers

The GPU is a processor built to do the same small calculation to millions of pieces of data at once, and comparatively bad at everything else. Rendering a frame is exactly that kind of problem, which is why graphics runs there rather than on the CPU.

WebGL is the browser API giving JavaScript access to the GPU. It is low-level: allocate buffers, compile programs, bind state, issue draw calls. Most of that tedium has nothing to do with what you are trying to draw.

GLSL is the language the GPU programs are written in. It looks like C, and it is the part you write by hand even when everything else is abstracted away, so it is where most of these notes concentrate.

three.js is a rendering engine wrapping WebGL. It supplies the concepts you think in — scene, camera, meshes, lights — and generates the WebGL calls. It does not hide GLSL, and is not meant to.

canvas-sketch is a harness for a single piece of work, owning the canvas, the loop and the export pipeline, so a sketch is just a function that draws.

Each layer is optional and only exists to save you from the one below.

The Rendering Pipeline

A frame runs through a fixed sequence. Two stages are programs you write; the rest happens for you.

graph TD
    A[Geometry: vertex data] --> B[Vertex Shader]
    B --> C[Rasteriser]
    C --> D[Fragment Shader]
    D --> E[Framebuffer: the image on screen]

The geometry supplies a list of points. The vertex shader runs once per point and decides where it lands on screen. The rasteriser works out which pixels each resulting triangle covers and hands each to the fragment shader, which decides its colour. The results go into the framebuffer, which is what you see.

The rasteriser is fixed-function — you can only feed it. The two shader stages are yours.

Where the Notes Go

The data first: Coordinates and Geometry is what the GPU is actually given, The Scene Graph is how an engine organises it, and 3D Transformations is how objects move within it.

Then the programs: Shaders and the GPU introduces the language and why shader code is shaped as it is. Vertex and Fragment Shaders covers the two stages above, and Attributes, Uniforms and Varyings covers how data gets into them — the part that trips people up.

Then the applications: Waves and Noise is the maths most generative work rests on, Shader Modules and Reuse is how to stop copy-pasting it between projects, and canvas-sketch Workflow is how a sketch becomes a file. Further Reading collects what to read next.

Every image in these notes is the output of the code shown beside it.

See Also

• Shaders and the GPU — what runs at the two programmable stages, and why
• The Scene Graph — how a rendering engine structures a frame
• Further Reading — books, references and tools

Resources

• WebGL & GLSL — A Primer — the interactive guidebook these notes are drawn from
• three.js documentation
• The Book of Shaders

---

Source: WebGL & GLSL — A Primer by Matt DesLauriers, and its workshop repository