What Are Shaders in Games?

The Role of Shaders in Real-Time Rendering

When a game engine draws a frame, it sends geometry data (vertices, triangles, textures) to the GPU along with a set of shader programs. The GPU executes these programs in a massively parallel fashion, processing thousands of vertices and millions of pixels simultaneously. Each shader program defines a specific transformation: the vertex shader decides where geometry appears on screen, and the fragment shader decides what color each pixel receives.

This division of labor is deliberate. GPUs are designed for throughput, not latency. A CPU core handles complex branching logic quickly but processes one thing at a time. A GPU has thousands of simple cores that each run the same program on different data points. Shaders are the programs those cores execute, which is why shader code must be relatively simple per-invocation but can handle enormous volumes of data per frame.

Without shaders, a game could only use preset rendering modes baked into the GPU hardware. With them, developers can implement any visual effect they can describe mathematically, from photorealistic physically-based rendering to abstract stylized aesthetics. The same hardware can produce a gritty war simulator and a pastel watercolor puzzle game, with shaders being the only difference in how that hardware is programmed.

A Brief History of Shader Hardware

The earliest consumer 3D accelerators in the mid-1990s, like the 3dfx Voodoo, had a completely fixed rendering pipeline. Developers could configure texture filtering, alpha blending, and fog, but the actual math was hardcoded in silicon. The range of possible visual effects was limited to whatever the hardware designers anticipated.

NVIDIA's GeForce 3 in 2001 introduced the first consumer-level programmable vertex shaders (via DirectX 8), allowing developers to write custom vertex transformation code. Fragment shaders followed soon after, and by the time DirectX 9 and OpenGL 2.0 arrived, both shader stages were fully programmable with high-level shading languages (HLSL for DirectX, GLSL for OpenGL).

The unified shader architecture, introduced around 2006, merged the separate vertex and fragment hardware into a single pool of shader cores that could be allocated dynamically. If a scene was geometry-heavy, more cores ran vertex shaders. If it was pixel-heavy, more cores ran fragment shaders. Modern GPUs all use unified architectures, and this is the hardware model that WebGL and WebGPU target.

For web developers, this history matters because WebGL is built on OpenGL ES 2.0 and 3.0, which require programmable shaders. There is no fixed-function fallback. Every material in a WebGL application, whether you wrote the shader yourself or used an engine's built-in material, is ultimately a pair of vertex and fragment shader programs compiled and executed on the GPU.

Types of Shaders

Vertex shaders run once per vertex in the geometry being rendered. They receive attributes like position, normal, and texture coordinates, and their primary job is to transform the vertex position from local object space into the screen-space coordinate system (clip space) that the GPU's rasterizer expects. Vertex shaders can also modify positions for animation, calculate per-vertex lighting, and pass data to the fragment shader through varying outputs.

Fragment shaders (called pixel shaders in DirectX) run once per pixel candidate generated by rasterization. They receive interpolated data from the vertex shader and produce a final color for that pixel. This is where texture sampling, lighting calculations, shadow lookups, and visual effects happen. Fragment shaders dominate GPU workload in most scenes because the number of pixels processed per frame far exceeds the number of vertices.

Compute shaders are a newer category that does not follow the traditional rendering pipeline at all. Instead, they run arbitrary parallel computations on GPU data buffers. Game developers use them for physics simulations, particle system updates, terrain generation, and other tasks that benefit from massive parallelism. WebGL does not support compute shaders natively, but WebGPU does, and developers working in WebGL can approximate some compute functionality using transform feedback or render-to-texture techniques.

Geometry shaders and tessellation shaders exist in desktop OpenGL and DirectX but are not available in WebGL or WebGPU. Geometry shaders can generate new primitives on the fly, while tessellation shaders subdivide geometry for level-of-detail control. Web game developers work without these stages, relying on vertex and fragment shaders (plus compute shaders in WebGPU) for all their effects.

What Shaders Control Visually

Shaders determine nearly everything you see on screen in a modern game. Lighting and shadows, material appearance (metal, wood, skin, glass), reflections, refractions, fog, atmospheric scattering, color grading, bloom, and motion blur are all implemented as shader code. Even seemingly simple things like applying a texture to a surface require a fragment shader to sample the texture at the correct coordinates and output the resulting color.

Surface materials in physically-based rendering (PBR) use shaders that model how light interacts with surfaces based on physical properties like roughness, metallicity, and albedo. Rough surfaces scatter light diffusely, producing soft highlights. Smooth metallic surfaces produce sharp, tinted reflections. These calculations happen entirely in the fragment shader, using equations derived from physics research (typically the Cook-Torrance microfacet BRDF model) that approximate how photons bounce off microscopic surface geometry.

Stylized rendering takes the opposite approach, deliberately breaking physical accuracy to achieve an artistic look. Cel shaders quantize lighting into discrete bands. Outline shaders detect edges and draw dark borders. Sketch shaders apply hatching patterns based on light intensity. Watercolor shaders bleed colors and add paper texture. All of these are fragment shader programs that transform the standard lighting result into something non-photorealistic.

Vertex shaders control geometry in motion. Grass swaying, ocean waves, cloth simulation, procedural terrain deformation, and skeletal animation all involve the vertex shader modifying vertex positions before they reach the screen. By encoding animation logic in the shader rather than updating vertex buffers from JavaScript every frame, the GPU handles the computation in parallel, keeping performance smooth even with millions of animated vertices.

Shaders in Web Games

Web games use the same shader concepts as native games, with a few platform-specific details. WebGL exposes the OpenGL ES shader pipeline through JavaScript, meaning developers write GLSL (OpenGL Shading Language) code that gets compiled and linked on the GPU at runtime. The shader source code is a plain string in JavaScript, passed to the WebGL API through a sequence of compile, attach, and link calls.

In practice, most web game developers never call these low-level WebGL functions directly. Engines like Three.js and Babylon.js handle shader compilation, uniform management, and pipeline state automatically. Developers interact with shaders either by choosing a built-in material (which uses the engine's internal shader code) or by writing custom GLSL and passing it to a ShaderMaterial class that the engine provides.

The web platform adds some constraints that native game developers do not face. Mobile browsers run on GPUs with limited compute power and memory bandwidth, making shader complexity budgets tighter. Cross-browser compatibility means testing on multiple GPU drivers and shader compilers, since different browsers and platforms may interpret edge cases in GLSL slightly differently. And because WebGL runs in a browser sandbox, there is no direct access to driver-level profiling tools, though extensions like Spector.js and the browser's built-in performance panels provide useful alternatives.

WebGPU, the newer web graphics API, changes the shader landscape by using WGSL (WebGPU Shading Language) instead of GLSL. WGSL has a different syntax (more Rust-like) and supports compute shaders natively. As WebGPU adoption grows, web game developers will increasingly work with WGSL, though Three.js's TSL system and Babylon.js's NodeMaterial can abstract the choice of shader language away, generating the correct code for whichever backend is active.