Add support for streamed SOG

[jo-chemla]

Quick recap of the context:

• sparkjs supports 3dgs scenes encoded as Playcanvas SOG v2 format since v0.1.10 as shown on the doc and this comment

• Sparkjs 2 introduced support for tiled 3dgs scenes in the RAD format as shown in the very detailed v2 blog post, section level-of-detail. These are ~octree hierarchy with base 1.5, built via build-lod with bhatt-lod or tiny-lod modes, where each node contains a rad encoded, JSON metadata header followed by randomly-seekable chunks.

• Playcanvas team built upon the SOGv2 format to design their own version of a HLOD hierarchical LOD tiled splats format, named streamed SOG, a binary spatial subdivision where each node geometry is encoded as sog set of webp textures.

Spark 2.0 supports SOGS files via a .zip file with manifest.json and referenced .webp images, and also the new extension .sog. However, the new Spark 2.0 file loaders don't support referencing manifest.json via remove URL and fetching the relative URL images. Please download and ZIP the files together and reference that directly for Spark 2.0.

---

It would be great to extend support for tiled splats within sparkjs to not only RAD, but also the streamed SOG format/specification, which would take advantage of the hierarchical structure of streamed-sog, and the existing sog decoding implementation.

Note at some point it might as well make sense to also support the OGC-3dtiles of glTF nodes packaged with the KHR_gaussian_splatting and KHR_gaussian_splatting_compression_spz_2, because an increasing number of implementations can produce such tiled-spalts - within the Cesium/Bentley ecosystem, as well as ESRI or independent tilers).

[mrxz]

It would be great to have support for streamed SOG in Spark. Though, there's quite a few things that need to be done internally for this to be possible.

First of all Spark 2.0 dropped support for unbundled SOG files. Using a single file tended to be more convenient in most cases. But the streamed SOG format explicitly requires unbundled SOG files as its chunks. So support has to be reintroduced.

Secondly the current LoD and streaming/paging implementations are quite bespoke to Spark and differ a lot in approach. Spark uses continuous LoD rather than discrete LoD levels. To properly support streamed SOG the SparkRender would have to be able to properly traverse the LoD structure and determine which levels/chunks to render and load.

Similarly for the SplatPager it needs to be able to load and unload these SOG chunks on the GPU. With the RAD format the chunk size and thus the corresponding page size lines up perfectly. With these chunks the size might vary, so packing them could require a different approach or more complex bookkeeping which chunks map to which pages.

And of course, care needs to be taken that these work correctly with the other features in Spark. For better or for worse, Spark tries to avoid mutually exclusive features. That's why you can combine multiple RAD files in a scene along with non-LoD SplatMesh instances. If we add these streamed SOG files in the mix, some challenges arise like how to deal with the lodSplatCount budget when a scene includes both.

None of these are impossible to resolve, but just wanted to manage expectations that while Spark has support for SOG, LoD and streaming, all of them will require some work for streamed SOG.