Building a WebGPU Renderer for Interactive 3D Manuals

Hal Wayland asked me to build a renderer for a specific job: present animated 3D assembly procedures in a browser, keep interaction deterministic, and own the complete rendering pipeline. I did not need to reproduce a general-purpose engine. I needed to render the parts, transitions, highlights, cutaways, labels, and inspection states required by an interactive manual.

We began with Three.js as a reference. The comparison page loaded the same glTF bytes, applied the same camera and scene controls, and let Hal Wayland switch between the reference and the new WebGPU renderer. That exposed incorrect output quickly. It also prevented a familiar result from becoming the specification by accident.

Establishing the base renderer

The first useful boundary was deliberately narrow. The loader parses GLB and glTF data, decodes Draco geometry, uploads the required metallic-roughness material data, and keeps GPU resources under explicit ownership. The frame graph renders shadows, depth and normal data, physically based materials, image-based lighting, overlays, picking, and final presentation.

The environment pipeline integrates an HDR image into diffuse irradiance, a GGX specular mip chain, and a split-sum lookup. The material pass uses inverse-transpose normal transforms, normal maps, correlated Smith visibility, and multiple-scattering energy compensation. Khronos PBR Neutral performs the final tone mapping. Hal Wayland selected it in place of ACES because the manual needs controlled product color rather than a cinematic look.

Several early failures were basic but useful. A WGSL overlay shader attempted compound assignment through a vector swizzle, which WebGPU rejects. The first lighting comparison overexposed the custom output until both renderers received equivalent light energy. A bad normal path reduced the model to a bright stencil with almost no readable shape. Those failures established a rule for the rest of the work: compare data entering the pipeline before compensating for the image leaving it.

Ambient occlusion and edge reconstruction

The final ambient-occlusion path uses GTAO. It reads full-resolution depth and normals, calculates occlusion at half resolution, denoises it with depth and normal awareness, and reconstructs the result at full resolution before indirect-light composition. This kept the cost bounded while preserving the contact information that makes mechanical parts legible.

Adding GTAO initially broke edge antialiasing because the new composition path bypassed the previous resolved output. Restoring four-sample MSAA after the pass fixed that regression. AO also remained fully visible when a model faded, so I multiplied its contribution by the same presentation opacity. Otherwise an invisible part left a dark imprint in the scene.

Making a part disappear without turning it into glass

Opacity became a larger experiment than expected. Conventional alpha blending exposes draw ordering as soon as surfaces overlap. The model begins to look like transparent plastic, with back faces and nested parts composited in an order that changes with the camera. That was the wrong visual model. The required operation was a clean transition from present to absent.

I implemented bounded depth peeling to test whether resolving several ordered layers would improve the result. It produced a more systematic version of the same glass-like image. Weighted blended OIT was considered for the same reason and rejected before implementation: it improves order independence for transparent surfaces, but the manual did not need transparent volume.

The retained solution converts opacity into deterministic blue-noise sample coverage. Each fragment writes an MSAA sample mask, retained samples remain opaque and write depth, and the hardware resolve turns spatial coverage into a smooth fade. The part disappears as one surface instead of revealing ordered internal layers.

Visibility and interaction are separate state. A model can remain visible while its pickable property excludes it from the GPU ID pass. Fully invisible models are excluded automatically. Positive-opacity fades retain complete picking geometry, so blue-noise coverage cannot create holes in selection.

Bevel shading without bevel geometry

Mechanical CAD exports often preserve perfectly sharp edges that look synthetic under PBR lighting. Adding bevel geometry to every source asset would increase production work and alter silhouettes, depth, shadows, and picking. I instead built a shading-only bevel system.

The first version stored local edge adjacency for each triangle and perturbed the normal near eligible edges. It looked plausible at ordinary radii, but exaggerated values exposed triangular spikes and discontinuities. A fragment only knew about the three edges owned by its triangle. It could cross a neighboring face without receiving the crease candidate that should continue across that face.

The final preprocessing step welds split positions across material primitives, identifies creases by automatic angle or Blender's exported edge weights, and propagates each crease candidate across connected triangles within its radius. The fragment shader evaluates a bounded candidate list and modifies only the shading normal. The material, GTAO, and reflection G-buffer receive the rounded result. Source geometry still controls the silhouette, depth, shadows, transparency coverage, and picking.

This topology is static. Skinned and morph-target meshes retain their source shading because deformation can invalidate the precomputed relationships. Supporting them would require dynamic adjacency or another bounded deformation-aware representation.

Reflections, followed by removal

The floor uses a planar reflection rendered from a mirrored camera. Model self-reflections use screen-space tracing against view-space depth and an extended G-buffer containing the final normal, roughness, reflectance, and environment intensity. Those two cases need different data, so forcing both through one approximation created obvious errors.

The first SSR implementation produced bands, broken floor hits, shimmering internal edges, and bright model silhouettes. Increasing trace resolution did not remove them. Increasing roughness hid some errors but did not correct the hit test. I then added temporal accumulation, neighborhood rejection, radiance mips, and an à-trous filter. The result accumulated complexity faster than quality: camera movement shook the image, history flickered, shader-interface mistakes could invalidate the frame, and the reflections still did not justify the pipeline.

We removed those layers. The retained SSR path converts depth once, builds a nearest-depth mip chain, traces one deterministic ray for each eligible model pixel, skips empty ranges, and refines an accepted crossing. Model rays that reach the floor use an analytic plane intersection. A separate MSAA receiver-coverage channel and a grazing-angle reduction return mixed silhouette pixels continuously to the environment instead of drawing a hard reflection outline.

This is still screen-space reflection. It cannot see geometry outside the viewport, hidden behind the first depth layer, or removed by clipping. It does not recurse. A BVH trace remains a separate future decision rather than another corrective layer on this pass.

Antialiasing after the render graph

Four-sample MSAA resolves geometry coverage inside the main pass, but post-process output can reintroduce hard transitions. I tried SMAA and removed it after Hal Wayland found it worse than FXAA on this material. The final display path applies adjustable FXAA after reflections, tone mapping, and background composition. Its control stops at four because higher values over-filter the image.

The renderer can also allocate every pass at 1.5 or 2 times the viewport dimensions, then downsample the final canvas. During direct inspection, Hal Wayland selected four-strength FXAA with 1.5-times supersampling as the useful high-quality preset. The renderer does not use camera jitter, motion vectors, or temporal antialiasing.

Testing the resulting boundary

The laboratory can decode and upload the same source model repeatedly as independent GPU assets, place each copy nearby with a random rotation, and report scene geometry separately from submitted work. That distinction matters because shadow, G-buffer, AO, reflection, and composition passes can submit the same geometry more than once. CPU submission time, complete GPU time, SSR time, decoded bytes, model count, scene triangles, submitted draws, and submitted triangles describe different parts of the frame.

The result is not a smaller Three.js. It is a procedure renderer whose data and passes match the manual: deterministic scene evaluation, metallic-roughness PBR, GTAO, shadows, blue-noise fades, GPU picking, propagated shading bevels, planar floor reflections, bounded SSR, overlays, and explicit resource ownership. Features that do not serve that workload remain outside the engine.

The live renderer laboratory loads local glTF assets and switches between the Three.js reference and the current WebGPU implementation. It is an inspection tool, not a published performance benchmark.