Field note 06

Three.js r185 Makes WebGPU Feel More Practical

The r185 release adds WebXR support, clustered lighting, and a collection of smaller changes that make WebGPU projects easier to take seriously.

By Codex Rules EditorialJuly 1, 20266 minute read

WebGPU has spent years in the awkward stage where it is clearly the future and still easy to treat as somebody else's future. Three.js r185 makes that excuse a little harder to maintain.

Released on July 1, r185 is not one giant WebGPU announcement. It is a stack of practical improvements: WebXR support in the WebGPU renderer, a fallback path for XR, clustered Forward+ lighting, external textures, SSGI optimization, and a wide range of fixes across renderers, loaders, nodes, helpers, and examples.

What is confirmed

The official release notes list WebXR support for WebGPURenderer, including a fallback for XR sessions where native WebGPU is not available. The release also adds clustered Forward+ shading to the WebGPU renderer. That technique is especially relevant to scenes with many lights because it avoids evaluating every light for every fragment.

The release includes support for ExternalTexture, several SSGI improvements, volumetric fire, a procedural city generator example, and a Rapier physics helper method for applying impulses. There are also changes to loaders, animation, controls, post-processing, and the node system. As always with Three.js, the release is a collection of many contributions rather than a single feature branch.

The official WebGPURenderer documentation still frames the renderer as the path to both WebGPU and a WebGL 2 fallback. That is important for real sites. A project can begin using the newer material and node architecture without requiring every visitor to have the same graphics backend.

The practical upgrade question

Do not upgrade a 3D project because a release list is exciting. Upgrade because a feature fixes a real constraint, or because staying behind is becoming more expensive.

For an r185 evaluation, check:

Your custom node materials and post-processing passes.
Color, tone-mapping, and texture output against saved reference images.
XR startup and fallback behavior on actual target devices.
Light-heavy scenes with production counts, not a small test scene.
Model loading for every format your users import.
Physics integration at different frame rates.

Save a small gallery of known scenes before changing the dependency. Render the same camera positions after the upgrade and compare them. Visual regression checks are far more useful here than “the build passed.”

A finished tool worth studying

Mixos is a browser-based PBR texturing tool built with Three.js and WebGPU. Its maker described a stack that includes React Three Fiber, Drei, and three-mesh-bvh, with raycast painting and high-resolution material maps. The current product page supports importing common 3D formats and exporting maps for engines and DCC tools.

Mixos should not be read as proof of any specific r185 feature. The builder's post names an earlier Three.js version. It is useful for a different reason: it shows that a browser can now host a serious, specialized 3D content workflow instead of merely displaying a model.

My take

The most important part of WebGPU's progress is that it is becoming boring. Renderers can offer fallback behavior. Tool authors can discuss workflow and export quality instead of apologizing for the graphics API. Engine releases can fold WebGPU changes into a normal list of physics, loader, and animation work.

That is what platform maturity looks like. Not a single spectacular demo, but a growing pile of ordinary reasons to use it.

A rule worth copying

Every 3D engine upgrade needs saved reference scenes, device checks, importer tests, and measured performance on a representative project.