Volume Shader Test: How Browser-Based 3D Rendering Works

Watch a volume shader test run and you see something that looks almost impossible for a web page: soft, glowing three-dimensional smoke or cloud, lit from within, rendered live on a canvas with no plugin in sight. What you are actually watching is a technique called ray-marching, where the GPU builds every frame by tracing a path through empty space for each pixel and sampling what it finds along the way. Understanding how that works — step by step — makes the test far more interesting than a pretty animation, and it explains why this particular workload is such a demanding exercise for graphics hardware. This guide takes the mechanism apart piece by piece.

The usual way: rasterization

To appreciate ray-marching, start with the method it replaces. Almost all real-time 3D — games, CAD, most of the web’s 3D — uses rasterization. The scene is built from triangles; the GPU projects each triangle onto the screen, figures out which pixels it covers, and runs a fragment shader to colour those pixels. It is extraordinarily fast because it only ever touches surfaces, and because decades of hardware design have been poured into making triangle-filling quick.

Rasterization’s strength is also its limit: it draws shells. A rasterized object is hollow, a skin with nothing inside. That is fine for a solid car or a character, but it cannot naturally represent a medium that light travels through — fog, smoke, a flame, a cloud, or medical scan data. For those you need to simulate the interior, and that is where a volume shader earns its place.

The core idea: marching a ray

A volume shader flips the question. Instead of asking “which pixels does this triangle cover?” it asks, for each pixel, “what would I see if I looked in this exact direction?” To answer that, it fires a ray from the camera through the pixel and into the scene, then advances along the ray in small, fixed steps, sampling the volume at each one. This walking-forward-in-steps is the “march.”

Here is the loop the fragment shader runs for a single pixel:

1. Cast the ray. Compute a starting point (the camera) and a direction that points through this pixel into the 3D scene.
2. Take a step. Move a small distance along the ray to a new sample position.
3. Sample the density. Ask a function — mathematical noise, or a 3D texture — how much “stuff” exists at this point. Empty space returns nothing; the heart of a cloud returns a lot.
4. Light the sample. Work out how much light reaches this point and how much the medium absorbs or emits there.
5. Accumulate. Blend this sample’s colour and opacity into a running total for the pixel.
6. Repeat or stop. Step forward again. Stop when the ray exits the volume, when the accumulated opacity is effectively solid, or when a step limit is reached.
7. Write the pixel. The accumulated total becomes the final colour on screen.

Every pixel runs that entire loop, independently, every frame.

Why the cost explodes

Now the arithmetic. The fragment shader runs once per pixel, so the number of rays scales with your resolution — millions of pixels means millions of rays. Each ray then takes many steps, often dozens to a few hundred, and each step performs sampling and lighting math. And none of it persists: a live render redoes the whole thing for the next frame.

Multiply those together — pixels times steps times per-step math times frames per second — and a volume render reaches into the billions of operations per second. That is the crux of why the workload is so heavy, and why it keeps the GPU’s arithmetic units genuinely busy rather than idling on memory transfers. It is the extreme end of the per-pixel load that any shader performance test measures.

What the test shows you

Because the whole render is per-pixel math running through WebGL, a volume shader test doubles as a clean measurement of your GPU’s shading throughput. Using the browser’s high-resolution animation clock, it reports:

• Frame time in milliseconds — how long each frame took, the clearest signal of GPU effort.
• Frames per second, the reciprocal of frame time, capped by your display’s refresh rate through vsync.
• 1% lows, the slowest 1% of frames, which reveal hitches the average smooths over.
• Consistency, how tightly frame times cluster — the real definition of “smooth.”

It is worth being clear about the limits too. The browser can time frames, but it cannot read your GPU’s temperature, utilisation percentage, VRAM, or power draw — those live behind system drivers off-limits to web pages. If the test lets you raise the step count or resolution, that is the configured workload, not a measured utilisation figure. Watching how frame time responds when you turn those dials is the most instructive thing you can do with the tool.

Running the test

The steps are simple; the value is in changing one variable at a time and watching the mechanism respond.

1. Open the tool. Launch the volume shader test and let it start rendering on your GPU.
2. Let it warm up. GPUs boost clocks under load, so ignore the first second or two and read numbers once frame time settles.
3. Raise the step count (if available). More steps per ray means finer, softer volume — and a proportionally higher frame time. This is the per-ray cost made visible.
4. Change the resolution or window size. More pixels means more rays. Frame time should rise roughly with the pixel count, demonstrating the per-pixel cost directly.
5. Watch frame time, not just FPS. A flat trace is a healthy result; a jagged one points to background activity or thermal limits.

Because a volume render is a sustained, heavy load, be sensible on portable hardware: run laptops on AC power on a hard, flat surface so the fans can breathe, and remember phones and tablets throttle quickly and lack fans. If the device gets uncomfortably hot or the tab misbehaves, stop the test.

Frequently asked questions

What is the difference between a volume shader test and rasterized 3D?

Rasterization draws surfaces — it fills the pixels a triangle covers and stops at the shell. A volume shader marches a ray through a 3D medium per pixel, sampling density and light at many points along the way, which lets it render smoke, fog, and clouds that light passes through. It is far heavier because it does many samples per pixel instead of one.

Does the volume shader test actually measure my GPU?

Yes. The ray-marched render is a real per-pixel workload, and the tool times how long your GPU takes each frame using the browser’s animation clock. The resulting frame time, FPS, and 1% lows are genuine throughput measurements, not a scripted animation.

Why does raising the step count make it slower?

Each additional step is another sample-and-light calculation for every ray, and there is one ray per pixel. More steps produce a smoother, more detailed volume but multiply the per-pixel work, so frame time rises. Watching that trade-off is one of the clearest ways to see how ray-marching cost scales.

Can this test read my GPU temperature or VRAM?

No. Web pages cannot access temperature, utilisation, VRAM, or power sensors — those need system-level drivers. The test measures timing only. You can infer that the GPU is throttling if frame time slowly climbs during a long run, but the temperature itself is invisible to the browser.

Is the volume shader test the same as the benchmark?

They share the same rendering technique, but the emphasis differs. This test is about understanding and observing the mechanism as you change settings. If you want a fixed-workload, comparable score, the volume shader benchmark guide explains what that number represents.

Ray-marching is one of the most elegant ideas in real-time graphics: build an image not by drawing surfaces but by asking, for every pixel, what a ray sees as it travels through space. Seeing it run makes the technique click. Open the volume shader test to watch it work and change the settings yourself — and if you want to understand the WebGL engine that makes it possible in a browser, the WebGL performance test guide is a good place to go next.