SuperSplat 3.0 Gaussian splat editor rewritten on WebGPU, needs almost 15 times less memory at idle

PlayCanvas has released SuperSplat Editor 3.0 — the browser-based 3D Gaussian splat editor has been rewritten from scratch on WebGPU. Projection, view frustum culling, packing, depth sorting and the issuing of draw calls for every Gaussian now run on the graphics card every frame, and the editor has stopped keeping full float copies of the scene in JavaScript.

On a test scene of 4.4 million splats (a 990 MB PLY), peak memory use at idle fell from 1557 MB to 105 MB; while rendering 1080p video, from 1673 MB to 142 MB; and while saving a compressed PLY, from 2982 MB to 1759 MB. It is this saving that makes it possible to load scenes in an ordinary browser tab that used to exhaust its memory — and, together with the new rendering mode, to work with scenes of tens of millions of Gaussians.

Compatibility has narrowed as a result: WebGL2 rendering has been removed from the third version entirely, and the CPU software sorting worker went with it. Without WebGPU the editor will not start — instead of the interface it shows a message saying that WebGPU is unavailable.

What moving the computation to the graphics card delivers

The changes affect more than rendering. Histograms, selection by range, colour picking, the calculation of bounds and all the intersection passes used in selection have been moved into compute shaders. A telling example is the Orient tool: on a scene of 2.4 million Gaussians, clicking it used to freeze the interface for around 8.5 seconds, and now it completes in less than 25 ms.

Export has been reworked into a streaming scheme: the file is assembled in chunks via splat-transform rather than in RAM as a whole. This applies to PLY, compressed PLY, SOG, SPZ, the .ssproj project file and publishing to the gallery. The build is based on PlayCanvas Engine 2.22.0 and splat-transform 3.3.3.

A Frame Timings diagnostic has been added to the interface: it draws a graph of GPU frame time with the minimum, the median and the 95th percentile over the last second. For anyone preparing splats for specific target hardware, this is a way to see the slowdowns without leaving the editor.

A spherical brush and a rendering mode without sorting

The main novelty in rendering is the Stochastic Alpha mode. Gaussians are drawn opaque, with a depth test and per-pixel coverage, that is, without depth sorting; when the camera stops, the editor draws in a fully sorted frame with blending. The settings offer the options “off”, “on”, “only while moving” and “auto” — the last is the default and switches to the stochastic mode only if the sorted frame turned out to be slow on the particular graphics card, returning to sorting when the view becomes lighter. In the PlayCanvas demonstration the mode is shown on a scan of a botanical garden of roughly 20 million Gaussians.

Among the editing tools, the most noticeable is the new spherical brush (Shift+B): every point of the stroke is placed at the depth under the cursor, the radius is recalculated into a world size at that depth, and at depth discontinuities the stroke is broken up — the brush follows the surface of the scan and does not catch what lies behind it. The old “on surface / through” toggle has been replaced by two separate parameters, Selection Depth and Selection Footprint; selection by the footprint of a Gaussian is computed on the GPU. Splats with zero alpha are now selectable as well.

Colour correction has moved from the general settings into the scene manager and is applied to the selection, not only to the whole scene. Hue, temperature, saturation, brightness, black and white points and transparency are available — with a live preview in the viewport and an apply button that bakes the edit in. A patch of a scan can now be fixed up locally right inside the editor.

Other changes:

• an Appearance panel with separate toggles for Gaussians, centres and rings, ring thickness, centre size and a selection colour setting; the utility overlays are off by default and all of them hide at once with Tab;
• a pop-up overlay panel: grid and planes, bounding box with dimensions, camera positions, camera data, frame timings;
• a reworked grid — the XZ, XY and YZ planes are enabled independently, the step is adaptive, with lines at 100 and 1000 metres for large scenes;
• a Preferences section with language, tone mapping, the number of spherical harmonics bands, fly speed, field of view and a settings reset;
• faster batch import of camera poses from JSON and COLMAP, correct orthographic rendering and depth picking when the camera is inside the scene bounds;
• the editor installs as an application and registers itself as a handler for .ply, .splat, .sog, .spz, .ksplat and .ssproj files.

Requirements and moving over from version 2.x

The WebGPU requirement cuts off part of the user base: current Chrome and Edge work, as does Safari version 26 and above, and Firefox with WebGPU enabled. For those whom this does not suit, PlayCanvas has kept the second branch — the last release, 2.32.5, remains available in the repository. There is also a caveat with projects: .ssproj files saved in 3.0 open only in 3.0 and newer, whereas the third version reads projects from 2.x without any trouble. On first launch a hard page reload is recommended — the old service worker and the offline cache from version 2.x are unregistered.

The distribution terms have not changed: SuperSplat Editor is free, the sources are open under the MIT licence and nothing needs to be installed — the work happens on superspl.at right in the browser.

Why WebGL2 was abandoned precisely now

The decision looks prepared in advance. Back in June PlayCanvas moved its splat viewer to a WebGPU renderer with compute shaders, and the editor was following behind. At that stage, supporting two graphics backends probably stopped paying off: sorting on the CPU and keeping the scene in JavaScript were the main limitation, and the parallel WebGL2 rendering path made it impossible to get rid of them.

The more general trend here is that Gaussian splats are leaving the demonstration stage. Compression and interchange formats are developing — at PlayCanvas that is its own SOG, and alongside it the editor supports SPZ — while support for splats is appearing in engines, mobile capture apps and production pipelines. The tools are adapting to the scale: if a scene of tens of millions of Gaussians becomes the working norm, the editor has no choice but to compute it on the graphics card.

Against the backdrop of this transition, browser-based CG tools will probably move towards WebGPU by the same scenario — first the viewer, then the editor, then dropping compatibility with WebGL2. For studios this means a shift in the requirements for the workstations of modellers and scanning specialists towards recent browsers and drivers.

What matters more to you in SuperSplat 3.0?

• The drop in memory use
• The move to WebGPU