Table of Contents Show
For those who don’t know the tool: PlayCanvas develops browser-based realtime graphics technology, while SuperSplat is its free, open-source editor for inspecting, cleaning, transforming, grading, optimising and publishing 3D Gaussian Splat scenes. It sits downstream of capture and reconstruction tools and upstream of realtime viewing or web delivery, accepting Gaussian-splat assets plus COLMAP or INRIA camera poses, then writing edited splat data or self-contained viewer packages. In other words, it occupies the increasingly busy bit of the pipeline between “we reconstructed several million translucent ellipsoids” and “somebody now has to make them presentable.”
The CPU loses its sorting job
SuperSplat 3 is a ground-up rewrite of both the editor renderer and its internal data model around WebGPU. This is not a WebGPU coat of paint applied to the previous editor. The 3. x editor removed the WebGL2 rendering path and the CPU sort worker.
For every Gaussian in the scene, projection, frustum culling, compaction, depth sorting and draw submission now execute on the GPU every frame. PlayCanvas describes the implementation as a compute projector feeding a GPU radix sort and indirect drawing. That moves a particularly awkward part of Gaussian-splat rendering away from the CPU: deciding which potentially millions of translucent primitives matter for the current camera and in what order they should be composited.
Depth sorting is especially relevant to 3D Gaussian Splatting because the representation is not simply a pile of opaque triangles waiting politely for a z-buffer. Gaussian primitives have projected footprints, opacity and view-dependent colour information, so drawing order can affect the blended result. The 3.0 architecture keeps the projection and sorting machinery close to the data it operates on rather than ferrying large working sets back and forth through JavaScript.
The editor’s storage model has changed with it. Static splat data lives in chunked GPU storage. A smaller per-Gaussian instance list carries the state that the editor needs to change interactively, including selection, locks, transforms and colour indices. Previous releases kept complete floating-point scene copies in JavaScript memory; 3.0 no longer does so.
That separation is important for editing because immutable or infrequently changed Gaussian attributes do not need to be duplicated merely so one splat can become selected, transformed or locked. A multi-million-splat capture can therefore remain largely resident in GPU-oriented storage while the comparatively compact editable state does the administrative paperwork.
Histograms, range selection, colour matching, bounds calculations and selection-intersection passes have also moved to GPU compute. The WebGPU rewrite therefore reaches beyond rasterisation. The editor is using the GPU as a general scene-processing device rather than treating it as the place where everything finally goes to become pixels.
Export is streamed instead of assembled
SuperSplat 3 applies the same approach to writing data. PLY, compressed PLY, SOG, SPZ, .ssproj projects and publishing are streamed chunk by chunk through PlayCanvas’ splat-transform layer rather than materialising the complete output scene in JavaScript before writing begins.
For large captures, this removes one source of temporary memory amplification. The source asset still occupies resources, and an export still needs working memory, but the editor no longer needs a monolithic JavaScript representation of the whole result before bytes can start leaving the building.
The current SuperSplat import and export documentation distinguishes carefully between formats that can be read and those that can be written. SuperSplat imports .ply, .compressed.ply, .splat, .ksplat, .spz, .lcc, .lcc2, bundled .sog, unbundled SOG through meta.json, and Streamed SOG through lod-meta.json.
PLY is not a generic escape hatch for arbitrary point clouds. The editor expects 3D Gaussian Splat PLY data containing the relevant Gaussian attributes. An ordinary mesh or point-cloud PLY without the required position, scale, rotation, opacity and colour data will not become a splat merely because the filename is optimistic.
Camera information is handled separately. COLMAP images.txt and INRIA camera-pose JSON can be imported to create timeline keyframes. They do not load splat geometry.
The editor can also create standalone HTML and ZIP viewer packages. Those are delivery outputs, not round-trip scene formats. The HTML form embeds compressed splat data into a self-contained viewer, while the ZIP package contains the viewer application and a separate compressed PLY.
Most splat exports offer control over how many spherical-harmonic bands are included. SPZ export additionally exposes SPZ 4 as the current default and SPZ 3 with its legacy gzip container for compatibility with older readers.
SOG compression wants WebGPU too
There is an important wrinkle in the format pipeline. SOG export and standalone HTML or ZIP viewer export use GPU-based SOG compression and therefore require WebGPU. The documentation says those operations fail when WebGPU is unavailable.
That detail is largely academic inside SuperSplat 3 itself because the editor is already WebGPU-only. It becomes more useful when distinguishing the underlying export tooling and documentation from earlier WebGL2-capable workflows. “The format is supported” and “every browser can encode it” are different sentences, and production pipelines have collected enough scars from treating them as synonyms.
Sorting takes a strategic holiday
Millions of translucent Gaussians are not cheap to sort continuously while the camera is moving. SuperSplat 3 introduces Stochastic Alpha as an alternative interaction path for heavy scenes.
In this mode, splats are rendered without the normal full depth sort. They are treated as opaque, depth-tested primitives with stochastic per-fragment coverage. This sacrifices the fully blended sorted result during interaction in exchange for avoiding the sorting workload that can make orbiting or editing a dense scene expensive.
Once movement stops, SuperSplat returns to the fully sorted blended path. The approximation therefore exists to keep interaction responsive; it does not permanently replace the stationary presentation.
There are four modes: Disabled, Enabled, Movement and Auto. Auto is the default. It initially retains conventional sorted rendering and watches measured GPU frame time. When the sorted path proves too costly, SuperSplat can use stochastic rendering during movement and return to sorted rendering when the view settles or becomes cheaper again.
Rings mode is supported during stochastic frames as well, so the interaction optimisation does not require giving up that editing representation.
Sphere Brush paints in world space
Selection receives an equally substantial rewrite. The new Sphere Brush, invoked with Shift+B, lets the artist paint a selection onto the visible geometry represented by the splats.
Each sampled point along the stroke is depth-picked to a world-space position. Those positions form a 3D path against which Gaussians are tested on the GPU. The brush radius maps to a physical size at the picked surface rather than remaining an arbitrary screen-space circle.
Depth discontinuities split the stroke. If the cursor crosses a gap between surfaces, the selection path does not simply bridge empty space and continue harvesting Gaussians on whatever happens to sit farther behind. This gives the tool a better notion of “the thing under the brush” in scenes where foreground foliage, railings, doorways or reconstruction gaps expose unrelated material at greater depth.
Brush size is shared with the 2D brush and can be changed with the bracket keys or Alt plus the mouse wheel.
The underlying selection model has also been disentangled. The previous surface-versus-through choice has been replaced by two independent controls.
Selection Depth limits picking to splats on the visible surface. Selection Footprint changes the geometric test from Gaussian centres to complete projected Gaussian footprints. The latter uses a GPU intersection pass and applies across both 2D and 3D selection tools.
Separating the two controls avoids bundling two different questions into one switch: whether selection should penetrate the scene, and whether a Gaussian counts because its centre lies inside the region or because part of its footprint overlaps it.
Zero-alpha splats can now be selected as well. Invisible data is still data, and occasionally it needs eviction papers.
SuperSplat also isolates a selection that is still computing from later camera movement or repainting. An asynchronous selection should therefore no longer be corrupted because the viewpoint changed before its GPU work completed.
Colour grading becomes selective
The colour controls have moved from a floating popup into the Scene Manager, where they operate on the active splat data.
The controls include Tint, Temperature, Saturation, Brightness, Black Point, White Point and Transparency. With a selection active, adjustments affect that selection and can be baked with Apply. Without a selection, the controls operate on the full splat.
This is local splat manipulation, not a replacement for a managed shot-grading pipeline. SuperSplat is editing colour data attached to the reconstruction, while a colourist working in a finishing system is dealing with an entirely different set of image transforms, monitoring requirements and deliverables.
For cleanup, visualisation and web-presentation work, however, selection-aware adjustments remove an otherwise rather silly detour. A patch of capture with the wrong brightness can be corrected where the splats already live instead of taking the whole reconstruction on a sightseeing tour through another application.
The grid discovers perspective
The viewport grid has been rebuilt as well. XZ, XY and YZ planes can be enabled independently, and the chosen planes are retained in both preferences and the document. Grid density adapts with the view. Large scenes gain 100 m and 1000 m lines, while close views avoid generating grids finer than the pixels available to display them. Coarser levels are drawn more prominently.
Analytic line antialiasing addresses horizon artefacts and keeps axes cleaner toward the vanishing point. PlayCanvas also removed the dither noise that could appear where grid lines crossed splats. None of this will make a reconstruction better, but it does prevent a kilometre-scale scan from being supervised by a grid apparently designed for a teacup.
Camera imports rebuild once
Camera-pose imports from JSON and COLMAP are now batched so the spline and timeline rebuild once after import instead of repeatedly while poses arrive. When imported poses omit field-of-view information, the current FOV is retained. Project loading has also been changed so the editor reaches its final state before rendering instead of briefly displaying partially assembled intermediate states. Loading .ssproj projects from a URL has been fixed as part of the same release work.
WebGPU is now admission, not acceleration
SuperSplat 3 requires WebGPU to start. PlayCanvas lists current Chrome and Edge, Safari 26 or later, and Firefox where WebGPU is enabled. Hardware acceleration must also be available.
If those requirements are not met, the editor presents a startup message instead of proceeding with a fallback renderer. There is no WebGL2 path in 3.0. The previous service worker and offline cache have also been removed. PlayCanvas says the old cache never covered the application’s content-hashed chunks fully and introduced staleness risk. The first 3.0 load unregisters service workers installed by older versions; users who still encounter the previous build are advised to perform a hard refresh. Stored preferences carry over from 2.x, although several controls have changed homes. Stochastic Alpha defaults to Auto.
Installable, but still a web application
SuperSplat can be installed as a Progressive Web App, and its manifest registers file handlers for .ply, .splat, .sog, .spz, .ksplat and .ssproj. That allows supported operating systems to hand matching files directly to the installed web application. It does not mean every registered file type has symmetrical import and export support; file association and format capability remain separate concerns.
The hosted editor can additionally load assets by URL using a load query parameter. For remote assets, the serving host must permit browser access through CORS. Multi-file formats retain their relative-file requirements, so publishing one metadata file while hiding its chunks somewhere the browser cannot reach remains an efficient way to create a very small error message.
SuperSplat can also recognise PLY sequences as animation frames and expose them through the Timeline. Each frame loads as a complete splat scene, so animated PLY sequences can become memory-intensive rapidly. Sequence support does not somehow turn a collection of full scenes into a lightweight temporal codec.
Under the bonnet
The 3.0 release is built on PlayCanvas Engine 2.22.0 and splat-transform 3.3.3. The SuperSplat repository is published under the MIT licence. PlayCanvas describes the editor as free and open source, and the source can be run locally for development. The repository’s documented local-development environment requires Node.js 20.19 or later, followed by the project’s npm installation and development build process.
That local-development requirement should not be confused with the requirements for using the hosted editor. Someone editing a splat in the browser does not need Node.js merely because the person modifying SuperSplat’s source code does.
The practical upgrade
SuperSplat 3 changes the editor at three layers simultaneously. The rendering and processing architecture moves to WebGPU compute, GPU sorting and chunked storage. Editing tools take advantage of that architecture through 3D surface-aware selection, asynchronous GPU intersections, faster point picking and selective colour adjustment. Deployment changes because WebGPU becomes mandatory and project files saved by 3.0 no longer reopen in the 2.x generation.
The main production benefit is therefore not one spectacular new button. It is that larger Gaussian-splat datasets can spend less of their working life duplicated in JavaScript while more scene operations happen directly where the bulk data resides.
That also means the upgrade deserves testing as an infrastructure change rather than treating it like a harmless UI refresh. Browser versions, GPU behaviour, project-file handoffs, representative scene sizes and export targets all belong in that check.
Studios should test SuperSplat 3 on representative production captures, target browsers, target GPUs and required export paths before deploying it into an active pipeline.
https://blog.playcanvas.com/new-in-supersplat-editor-3-0-rebuilt-on-webgpu/
https://github.com/playcanvas/supersplat/releases/tag/v3.0.0
| Product | SuperSplat Editor |
| Developer | PlayCanvas |
| Version | 3.0 |
| Core renderer | WebGPU only; compute projection, GPU radix sorting and indirect drawing |
| Browser support | Current Chrome and Edge; Safari 26 or later; Firefox where WebGPU is enabled |
| Splat import | PLY, compressed PLY, SPLAT, KSPLAT, SPZ, LCC/LCC2, bundled SOG, unbundled SOG and Streamed SOG |
| Camera import | COLMAP images.txt; INRIA camera-pose JSON |
| Delivery/export | Supported splat formats plus standalone HTML and ZIP viewer packages; available choices depend on format |
| Project compatibility | 3.0 writes document version 1; version-0 projects open in 3.0, while version-1 projects require 3.0 or later |
| Licence | MIT |
| Cost | Free |
| Documentation | SuperSplat user manual |
| Source code | GitHub repository |
