A beautiful Gaussian scene is much less useful if sending it to someone means asking them to download a gigabyte. File size changes who can see the work, how long they wait and whether the scene belongs inside a web page at all.
That is why the Spatially Ordered Gaussians format from PlayCanvas interests me. SOG packages the representation into a single container and compresses its data with attention to spatial order. The announcement includes a reduction from roughly 1 GB to 42 MB for one example. That is a vendor example, not a universal ratio I would expect from every scene.
A Gaussian scene contains more than positions and colors. Each primitive also has shape, orientation and opacity, and richer appearance models include directional information. A convenient interchange file can store all of this in a form that is straightforward to read but expensive to deliver.
The opportunity is to encode the same useful structure more economically. Nearby points often share properties or change in predictable ways. Ordering them spatially can make the data more coherent before compression.
Why order matters
Morton order is one way to arrange spatial coordinates so that nearby locations tend to remain nearby in a one-dimensional sequence. It does not perfectly preserve every neighborhood, but it gives a compressor more useful locality than an arbitrary ordering.
Quantization is a separate decision. Instead of storing every quantity with unnecessarily fine precision, the format can use a smaller set of representable values. The cost is approximation. The goal is to spend precision where losing it would be visible and avoid paying for distinctions that do not improve the rendered result.
This makes the evaluation more interesting than a file-size comparison. I would inspect thin structures, silhouettes and subtle color changes. I would also move the camera. A scene can look acceptable from one angle while compressed directional appearance becomes less convincing from another.
Delivery has several stages, too. A smaller file reduces transfer, but loading also includes parsing, decoding, memory allocation and getting data into a form the renderer can use. A compact container is most helpful when the surrounding tools make those steps predictable.
The open conversion tools and documented format are therefore part of the appeal. They make compression something that can be integrated into a workflow rather than a one-off trick tied to a demonstration. WebGPU-based conversion is also relevant to portability, although support still depends on the environment running it.
For a small site, I would treat the scene as an asset with a budget. How much should download before the viewer can move the camera? What happens on a phone with limited memory? Can the page show useful context while the scene loads? A smaller representation gives better answers room to exist.
I do not need every compressed scene to match the announcement's most striking ratio for SOG to be useful. A meaningful reduction with acceptable quality can change whether a project is practical to share. The most valuable optimization may be the one that lets another person reach the scene at all.