PlayCanvas and SuperSplat

PlayCanvas is the only major web engine whose splat stack is first-party end to end: the renderer, the SOG delivery format, the SuperSplat editor and the superspl.at hosting service all come from one team and are built to feed each other. That coherence, more than any single benchmark, is why this pipeline delivers through it: every handoff from trained PLY to a scene in a client’s browser stays inside one toolchain.

What the engine ships today

The engine sits at v2.20 as of July 2026 (v2.20.6 released 6 July), on a release cadence of multiple patches a month. Splats render through the gsplat component, which loads three formats: raw PLYPolygon File Format: the element/property container every 3DGS trainer writes its raw output to, one row per Gaussian holding position, scale, rotation, opacity and spherical-harmonics colour. Lossless and universal as an interchange format, but too large to ship straight to a browser., PlayCanvas’s older compressed PLY, and SOG. The current rendering architecture, which the team calls unified gsplat, landed in v2.11.0 in September 2025, the same release that added support for the current SOG version. On top of it sit the renderer modes covered in the browser rendering article: an automatic mode, a CPU-sorted path that runs everywhere, and a WebGPU-only GPU-sorted path that the engine documents as exactly that and falls back from cleanly on WebGL devices.

Loading a SOG

SOGCompressed splat format storing Gaussian attributes as sorted 2D image grids (typically WebP), giving large size reductions for web delivery. is covered in depth in the compression part; the short version is that it stores Gaussian attributes as spatially sorted WebP images, either unbundled as a meta.json plus image files or bundled into a single .sog archive, at roughly 95 percent smaller than the raw PLY (PlayCanvas’s September 2025 SOG open-source announcement compresses its Skate Park example, a 1 GB, 4 million Gaussian PLY, to 42 MB; a separate, earlier example from PlayCanvas’s SOGS-adoption post reaches 55 MB from a similarly sized church scene, see the SOG format for both). To the engine it’s just another gsplat asset: point loadFromUrl or an asset registry entry at the .sog, attach the loaded asset to an entity’s gsplat component, and it renders. The same applies through @playcanvas/react for React apps. This is what that looks like with a real capture:

A door capture from the author's pipeline: PostShot-trained, cleaned in SuperSplat, delivered as a 12 MB SOG

.sog capture · 12 MB

Load 3D view (12 MB)

That 12 MB is the entire scene payload, textures and all, which is the point: a SOG this size is a perfectly ordinary image download, not a special 3D asset problem.

SuperSplat: the editor in the middle

SuperSplat (playcanvas/supersplat on GitHub, free and open source) is where a trained scene gets made presentable: cropping to the region that matters, deleting floaters, colour adjustment, transforms, and export to PLY, compressed PLY or SOG. It runs in the browser, imports the common formats including .splat and SPZ-era files, and has been iterating fast: it reached v2.28.1 at the end of June 2026 across roughly 155 releases. The 2026 additions chart where the tool is going: SuperSplat Studio in February, walk mode and streamed level-of-detail publishing in March, attribution and collision generation in May, then the June release that moved the viewer to WebGPU rendering with streamed loading, with PlayCanvas publishing device numbers to match.

superspl.at: hosting as the default last step

The same team runs superspl.at, a free publishing service wired directly into the editor: a scene can go from local edit to a shareable hosted URL without leaving SuperSplat, and since the March 2026 release, uploads get streamed level-of-detail treatment applied automatically, so even very large scenes start rendering from a coarse level almost immediately. For client work a self-hosted SOG behind the project’s own domain is usually the right call, but superspl.at is the fastest way to put a capture in front of someone for review, and its existence means the format’s loader and streaming behaviour get exercised at scale by the vendor itself.

In practice

The production flow this knowledge base documents runs: PLY out of PostShot, into SuperSplat for floater cleanup, crop and colour, export as SOG, then loaded through the engine’s gsplat component or @playcanvas/react in the delivery app. Pin the engine version in package.json and read the release notes before bumping: the splat renderer is the most actively developed part of the engine right now, which is mostly good news but means behaviour genuinely changes between minor versions. Keep the PLY archived; SOG is a delivery format, and re-exporting from the lossless original is always cleaner than converting a compressed file twice.