3D Tiles 1.1 Sandcastle Example Cleanup

[ggetz]

3D Tiles 1.1 brought additional capabilities to 3D Tiles, including further metadata support and implicit tiling support.

We used to refer to what became 3D Tiles 1.1 as "3D Tiles Next", and have several Sandcastle examples illustrating the above capabilities. At this point, all references to "3D Tiles Next" should be "3D Tiles 1.1" and the Sandcastle category should either be renamed or incorporated into the 3D Tiles tab. I'm personally a fan of the later to keep things simple.

The tilesets used in the 3D Tiles Next sandcastles are also out of date and should be updated to 3D Tiles 1.1. These should be uploaded to the CesiumJS ion account.

Potentially, we should upgrade 1.0 tilesets to 3D Tiles 1.1. Now that CesiumGS/3d-tiles-tools#41 is merged we can upgrade many tilesets to 3D Tiles 1.1 with i3dm and cmpt support planned for future PRs.

[javagl]

we can upgrade many tilesets to 3D Tiles 1.1 with i3dm and cmpt support planned for future PRs.

• I3DM should already be covered with Upgrade I3DM to GLB with EXT_mesh_gpu_instancing 3d-tiles-tools#52 , with one caveat: It (is difficult and) will not work with I3DMs that contain animated GLBs. (Omitting some details: There are configurations of I3DM+(animated)GLB that technically and mathematically cannot be converted into a single GLB with EXT_mesh_gpu_instancing...)
• CMPT could be trivial in some cases, but impossible in others. Specifically: When someone is using CMPT in implicit tiling, then this can not always be converted into GLBs, unless the CMPTs have a certain structure (also, some details omitted here).

[ptrgags]

@javagl unless the tileset with a .cmpt content uses implicit tiling, the simplest implementation would be to split it into separate glTF files and use multiple contents in the tileset file, correct? Though the downside of this is every tile now would make multiple requests at runtime.

I suppose you could also combine the separate glTF models into one asset with multiple nodes... but that probably requires quite a bit more effort to consolidate details (e.g. consolidating metadata without causing name collisions)

[javagl]

@ptrgags Exactly - some thoughts about this are in the "CMPT to GLB" section at the bottom of this (loooong) summary, but ... as a meta-summary here: You basically already mentioned the main cases:

• When there's implicit tiling, then it's not possible to update the template URIs (the CMPTs may contain different numbers and types of 'inner' tiles, and even be nested)
• When there is no implicit tiling, then multiple contents could be a workaround ... but when a CMPT contains 100 inner tiles, this is not ideal...

The most "generic" approach would be to convert the inner elements of a CMPT into GLBs, and merge them into one. Merging arbitrary GLBs is impossible without knowledge about the desired results (for example, glTF-Transform has a 'merge' functionality that IIRC just treats each input as its own scene). This isn't the main problem in our case: We know that the GLBs contain just some meshes+geometries, and that we just want to mush everything together. But there still are special cases (like the metadata) that are not trivial.

(I mean, the I3DM-to-GLB also can only do a "best effort" approach and not guarantee that it will work in all cases, but ... when it covers the CesiumGS I3DM spec files, that's a good start, and we could treat the CMPT case similarly)