Loading
Research · Thread 02
Web renderer selection
Which renderer can actually hold a nine-million-splat scan in a browser.
Training a scan and displaying it are different problems, and the second one decides what a client sees. So one capture went in front of every web renderer that would take it, on an identical camera path, with the settings that decide the picture pinned in code rather than in a spec document. The useful result was not a winner: it was that the winner changes with the scene, that one engine fails silently rather than erroring, and that the study had to retract its own measurements eight times before the numbers meant what they appeared to mean.
Finding
Which renderer holds nine million splats?
7 web renderers, one 9,173,511-gaussian capture, one camera path, parity pinned in code. Five draw it at full density. Babylon.js renders two million, then returns a black frame with no error thrown, which is the failure mode that matters: nothing to catch, nothing in the console.
The winner flips with the scene, so there is no single right renderer.
Paper to shipped
Reference
antimatter15/splat, the reference WebGL splat viewerThe implementation most later web viewers are measured against. Reads a flat .splat file and holds every gaussian resident, which is the opposite trade to a streaming LOD viewer.
Benchmark
7-renderer controlled comparison at 9,173,511 gaussiansOne capture, one camera path, and every renderer's settings pinned in code, so a difference in the output is a difference in the renderer rather than in how it was set up.
Shipped
The renderer decision behind Barnes VantageThe advantage measured outdoors did not transfer to interiors, where the streaming viewer costs less to deliver than the engine that beat it outside. A swap would have won one scene type and lost the other, so the answer was per-scan and the viewer stayed put.