Performance budgets, streaming and LOD

A splat scene that runs beautifully on the workstation that trained it will happily bring a mid-range phone to its knees, and by the time that’s discovered in delivery it’s expensive to fix. Budgets for splat scenes are set in two currencies, Gaussian count and megabytes, and the honest starting point is that nobody publishes a specification for either: what follows is vendor guidance plus practitioner consensus, labelled as such.

Gaussian-count budgets

PlayCanvas’s official performance guidance is the closest thing to a vendor number: set a global splat budget appropriate to the target hardware, on the order of 1 million Gaussians for mobile and 3 million or more for desktop. Independent practitioner benchmarks are more conservative for older phones, putting comfortable WebGL performance on recent iPhones at 200 to 500 thousand splats and 30 to 45 fps, with 1 to 2 million the desktop comfort zone. WebGPU moves the mobile ceiling meaningfully: PlayCanvas’s own device figures show an iPhone 13 Pro Max running a 4 million Gaussian scene at 42 fps under WebGPU against 20 fps under WebGL2. No GPU vendor or browser publishes a maximum-Gaussians-at-60fps figure, so treat all of these as measured reference points to test against, not guarantees.

File-size budgets

Raw PLY runs roughly 236 to 250 bytes per Gaussian, which is why it is an archive format and not a delivery one. SOGCompressed splat format storing Gaussian attributes as sorted 2D image grids (typically WebP), giving large size reductions for web delivery. changes the arithmetic: PlayCanvas’s Skate Park example, from its September 2025 SOG open-source announcement, takes a 4 million Gaussian, 1 GB PLY to 42 MB (a separate church-scene example from its earlier SOGS-adoption post reaches 55 MB from a similarly sized PLY; see the SOG format for both), and the quantisationStoring a value at lower numeric precision than it was computed at, for example rounding a float32 position to 16 bits or mapping a scale to one of a fixed set of codebook entries, to shrink storage size at the cost of some accuracy. that buys that ratio is tuned to be invisible at normal viewing distances. A sensible mobile budget for an atomically loaded scene is the low tens of megabytes, which is what a large hero image or short video clip already costs a page; the 12 MB door capture embedded in the PlayCanvas article is a realistic single-subject payload at that budget. Desktop scenes can carry 50 to 100 MB before load time, rather than rendering, becomes the complaint.

Where phones actually hit the wall

Three constraints stack up on mobile. The per-frame sort covered in the browser rendering article scales with Gaussian count and runs on CPU under WebGL, so it competes with everything else on the main thread’s siblings. Fill rate goes next: splats are blended, overlapping quads, and millions of them burn bandwidth on exactly the hardware with the least of it. And memory is quieter but real: attribute textures for a multi-million splat scene plus the sort’s working buffers can push a browser tab toward the point where the OS simply reclaims it. The old WebGL guidance of treating 4096 as the safe universal texture dimension still applies to texture-backed splat formats, and is one reason very large scenes get split or streamed rather than shipped as one asset.

Streaming and LOD: shipping today

The atomic-download model stops being the only option in 2026. PlayCanvas’s streamed SOG arranges a scene into multiple pre-generated detail levels over a spatial tree, described by a lod-meta.json alongside the usual files; the viewer loads the coarsest level first, so a complete, stable image appears almost immediately, then streams finer levels in and out by camera distance under a device-tuned Gaussian budget. SuperSplat publishes this format automatically on upload to superspl.at, and PlayCanvas’s June 2026 demo of a 24 million Gaussian scene appearing near-instantly is the capability statement. A plain single .sog file remains an atomic download; the LODLevel of detail: rendering or serving a reduced-detail version of an asset where full detail would be wasted, such as lower Gaussian-count representations of splat scene regions far from the camera. treatment currently comes from the SuperSplat publishing path (or a lod-meta.json written by splat-transform) rather than something the engine synthesises at load time.

PlayCanvas Editor 2.32 (September 2026) changed how that budget is tuned per component. The old LOD Base Distance and LOD Multiplier fields are gone. LOD Range Min and LOD Range Max now bound which levels a splat may use, and LOD Falloff sets how strongly its share of the scene-wide splat budget is concentrated near the camera, with 0 spreading it evenly. The range only has an effect on streamed SOG, because a single .sog or .ply has exactly one level. Scenes tuned with the old fields need retuning after the upgrade.

LOD in research

streamed loadingLoading a scene progressively, showing a coarse but complete version almost immediately and refining as more data arrives, instead of blocking on one atomic download of the full asset. for splats is also an active research area, and two papers are worth knowing by name. LapisGS structures a scene as cumulative detail layers so a streaming server can adapt quality to bandwidth mid-session, the direction adaptive splat delivery is likely to take. LODGE targets the other end, city-scale scenes on constrained hardware, with hierarchical levels of detail and chunked loading by camera position. Neither ships in a web engine today, and nothing equivalent to PlayCanvas’s streamed pipeline has appeared in three.js or Babylon as of mid-2026.

In practice

Set the budget before training, not at delivery: a scene trained to 3 million Gaussians for a mobile-first project has already spent its quality in places the audience will never see, and downsampling after the fact is worse than training to the budget. Sign off performance on the oldest real phone the client’s audience plausibly holds, on WebGL, because that’s the floor; WebGPU improvements are a bonus tier, not the baseline. For a single-subject capture, an atomic SOG in the low tens of megabytes is a solved problem. The moment a scene is a building rather than a doorway, plan for the streamed path instead of negotiating the budget upward.