Post #1 promised WebGPU "later." Later is now — /viewer renders
through Three.js's WebGPURenderer, using real WebGPU where the browser
provides it and a WebGL2 backend where it doesn't:
const renderer = new THREE.WebGPURenderer({
canvas,
antialias: true,
forceWebGL: !navigator.gpu,
});
await renderer.init();
That's the whole migration. Three changes, honestly:
import * as THREE from 'three'→from 'three/webgpu'— the node-material build, which re-exports the whole classic APIWebGLRenderer→WebGPURendererwithforceWebGLfallbackbuild.target: 'es2022'in vite — top-levelawaitforrenderer.init()
Why classic materials still work
WebGPURenderer internally translates MeshStandardMaterial,
LineBasicMaterial, MeshBasicMaterial — the entire classic material API —
into its node system. We rewrote zero materials. Clipping planes, the
section plane, the highlight material, edge lines: all came through
unchanged. The compatibility layer did exactly what it promised.
What WebGPU actually buys us today
Honest answer: nothing user-visible. Same frame rate on the same models — the bottleneck in this app is tessellation in the worker, not draw calls. What it buys is the platform: compute shaders are next door when we want them — GPU-side decimation, curvature analysis, tessellation refinement — and the fallback means nobody on an older browser loses anything.
The cost, also honestly
- Bundle: the viewer chunk went from ~300 KB to ~810 KB (220 KB gzipped). The node-material system plus two rendering backends is not free.
- Browser floor: Safari 14-era browsers lose the viewer — the fallback is WebGL2, not WebGL1. A fair trade for a CAD tool in 2026; noted for the record.
The state of the roadmap
Both originally promised items shipped: parse → render → parts → edges → sections → faces → measurement → true B-rep edges → WebGPU. What remains is the genuinely hard list — section caps, edge measurements, mesh formats. The infrastructure work is done; what's left is CAD.