SuperSplat rewrote itself on WebGPU and deleted the fallback

Why it matters: SuperSplat is where a great many captures get cleaned up before they go anywhere, and its binding constraint has always been browser memory. A large PLY had to be parsed into JavaScript, held there as float arrays, and sorted on the CPU by a worker every time the camera moved. Scenes that were merely big became scenes that crashed the tab.

In 3.0 the splat data lives in chunked GPU storage, with only a small per-gaussian instance list — selection, locks, transform and colour indices — describing the editable state. Projection, frustum culling, compaction, depth sorting and draw submission all run on the GPU every frame, through a compute projector, a GPU radix sort and indirect draws. The CPU sort worker is gone.

Exports were the other memory cliff, and they are now streamed chunk by chunk through splat-transform, so saving a PLY, SOG, SPZ or project file no longer materialises the whole scene before writing it.

By the numbers:

• On a 4.4-million-splat scene from a 990 MB PLY, peak JavaScript heap while idle falls from 1,557 MB in 2.x to 105 MB in 3.0 — a factor of fifteen.
• Rendering a 1080p video drops from 1,673 MB to 142 MB.
• Publishing falls from 1,934 MB to 741 MB, and saving a project from 1,723 MB to 790 MB.
• Loading the editor today it reports v3.3.0, and it took a two-million-splat scene from a URL without complaint.
• Seven releases in seven days: 3.0.0 on 8 September through 3.3.0 on the 14th.

What else changed: The most interesting new feature is Stochastic Alpha, a sort-free transparency mode that renders splats opaque and depth-tested with per-fragment coverage so a heavy scene stays responsive while you orbit. The moment the view settles, a properly sorted and blended frame is drawn, so what you inspect at rest is still exact. The default setting is Auto, which keeps the clean sorted path until a sorted frame's GPU time proves slow, then switches during movement and drops back when the view lightens. That is a well-judged default: it degrades only while you are moving, which is when you cannot see the difference anyway.

Selection has been rebuilt around two independent switches — Selection Depth picks only what is on the visible surface, Selection Footprint tests whole gaussian footprints rather than centres — replacing the old surface/through toggle. There is a new 3D sphere brush whose every sample is depth-picked to a world position, so the stroke follows the surface instead of cutting through the scene.

Yes, but: The memory win is real but uneven, and the release notes publish the unflattering row alongside the good ones. Saving a compressed PLY still peaks at 1,759 MB, down from 2,982 — better, but not the fifteenfold improvement the idle figure suggests. The dramatic numbers are idle and video rendering; the export paths remain heavy.

The compatibility break is the part to think about before upgrading. WebGPU is required, and the editor refuses to load without it — including on machines where hardware acceleration is simply switched off, which is common enough in managed corporate environments. The answer offered is the preserved v2 branch.

That escape hatch only opens one way, though. Projects saved by 3.0 use a new document version and must be opened in 3.0 or later. So falling back to 2.x works if you have not saved anything yet, and does not if you have.

Seven releases in the week since launch is also worth reading for what it is. A rewrite this deep shakes out a long tail of crashes — pointer capture on touch, races between scene changes and repaints, a publish that hung on a failed upload — and the fixes are landing quickly, which is the good version of this. But 3.0.0 was not the version to put a deadline behind.

The big picture: This is the same story the browser splat stack has been telling all month from different directions. luma.gl added a bounded residency window, Babylon.js added a render budget, an Edinburgh group proposed block-descent training to make VRAM independent of scene size. Every one of them is an admission that the naive approach — hold it all, sort it all, draw it all — stops working somewhere short of the scenes people now want to edit.

SuperSplat's answer is the most decisive, because it does not add a budget on top of the old path. It deletes the old path. That is a bet that WebGPU is now broadly enough available to be a requirement rather than a fast lane, and for a browser tool with this much of the market, it is a reasonable moment to make it.