Sample data for 3D Tiles Next

[pjcozzi]

The 3d-tiles-samples repo has some sample 3D tilesets for 3D Tiles Next.

What is the scope of sample 3D tilesets we would like to provide in time for #556? And how do we get there, e.g., do we need a few 1.0 to Next scripts before we write a full converter? Or can we get by on generated and donated data?

For sample 3D tilesets, perhaps at least

• Simple "unit test" models for the major new features
• Simple "unit test" models for the major types of models, e.g., photogrammetry, CAD, point clouds
• "Integration test" models that combine prominent use cases such as per-texel metadata in photogrammetry, and MESHOPT-compressed point clouds
• "Scalability test" model so developers can test their out of core algorithms

For the #556 timeline, I suggest this list be short - representative, not exhaustive.

[ptrgags]

Another example to add: a double-headed quadtree. See #512 (comment)

[javagl]

Just to have the reference here: One "unit-test-level" example (a small, sparse implicit quadtree) is contained in CesiumGS/3d-tiles-samples#34

[javagl]

An attempt of a summary:

Existing examples:

• In the 3d-tiles-samples repo:

  • TilesetWithTilesetMetadata
  • TilesetWithTileMetadata
  • TilesetWithGroupMetadata
  • TilesetWithExternalSchema
  • ImplicitTilesetWithTileMetadata
  • SparseImplicitQuadtree

• Demos mentioned in the 3D Tiles Next Blog Post

  • Photogrammetry Classification Demo
  • Property Textures Demo
  • S2 Base Globe Demo
  • CDB Yemen Demo

For the latter, is it is not always clear which new feature is showcased exactly in which demo. Some additional description for these demos might be worthwhile. Another question: In how far can the underlying data of these demos be made public, to serve as test/sample data for implementors?

New features, and their "coverage" with current sample data:

• 3DTILES_content_gltf
  This is basically already used in all the 3d-tiles-samples examples. A dedicated, minimal example of a tileset that just contains the Triangle.gltf (or glb) could be considered, but may not add much value over the existing models.

• 3DTILES_multiple_contents
  There is not much coverage for that. A simple example could be a tileset that refers to two contents, maybe even both GLB files, containing the same (artificial) "object", once as a point cloud and once as a mesh.

• 3DTILES_implicit_tiling
  The 3d-tiles-samples already contained the ImplicitTilesetWithTileMetadata. But the focus there seemed to be to show an example of how implicit_tiling and metadata can be combined. The tileset is a bit too simple to actually be considered a sensible test for implicit tiling functionality. But the SparseImplicitQuadtree covers this point a bit more (e.g. with multiple levels of subtree files). Beyond that, there could be many, many more examples. Examples of examples:

  • Using the same maxiumumLevel with different configurations of subtreeLevels
  • Using the same subtreeLevels with different maximumLevel
  • Dedicated examples for constant availability (although this is nearly automatically part of any non-trivial example)
  • Different combinations of available content and tiles (e.g. examples with many "empty" tiles)
  • ... and of course, all that also for Octrees....

  This could quickly become a long list, and the line between "test models" and "unit test models" will become blurred. I think that having one SparseImplicitOctree could be good. Whether or not a certain test coverage for different configurations should be achieved with models that are actually stored in a repo (or whether there should be a more-or-less "standalone" generator tool for the different configurations) has to be decided.

• 3DTILES_bounding_volume_S2
  There currently is only the demo from the blog post. Creating a simple, standalone tileset that uses the extension and essentially declares a simple, small hierarchy of maybe two or three bounding volume levels with S2 should be easy, though.

• 3DTILES_metadata
  The models from the 3d-tiles-samples cover pretty well the cases of data that is attached to tilesets/tiles/groups. What could be tested or offered as a dedicated example: A "trivial" tileset that contains "all" property types. (I actually created something like this today, with 99 properties, ranging from SINGLE UINT8 over MAT3 INT64 down to ARRAY STRING, but that might require a bit more validation).

• EXT_mesh_features
  Simple test examples like a single triangle with vertex feature IDs, a cube with property textures could be relatively easy to create. Similar to 3DTILES_metadata, there could be examples that cover the full range of possible property types, to make sure that loaders can properly decode all types of properties from the binary payload.

• Semantics
  Here, one could consider small standalone demos for each of the semantics that are currently defined. But maybe this should be focussed on the tile- and content bounding volumes, because they are easier to convey than the meaning of CONTENT_HORIZON_OCCLUSION_POINT...

• Combinations:
  The 3d-tiles-samples covers one combination via ImplicitTilesetWithTileMetadata. Combinations of multiple_contents with 1. metadata and 2. implicit_tiling should be added, because these are actual features in terms of the data structures, and examples should exist to make sure that implementors actually support these combinations.

[javagl]

I'd also propose that all sample models in 3d-tiles-samples should have an associated sandcastle. This does not have to be (and maybe even should not be) part of the "official" sandcastle site. But there should be sample code in the README, showing how the sample data is loaded, processed and used.

[javagl]

There are some tasks that could be summarized here (they rather refer to 3D Tiles 1.1, and not to Next, strictly speaking, but I think they fit here)

• The next samples could be removed, and replaced with 1.1 samples accordingly. While the next folder still exists in the main spec, it is un-linked and with a note that 1.1 is the new Next.. But in the sample models repo, there is hardly a reason to keep these samples around.

• There currently is a single sample for 1.1, showing all metadata granularities (Tileset, Tile, Group, Content). The next folder contains these individually (TilesetWith<X>Metadata). I think that the structure of all metadatas is so similar now that individual samples would not make much sense - at least, not for a sample that is supposed to show off the feature (in contrast to a "unit test" model - more on that below)

• The expiration sample can probably removed, as of The TilesetWithExpiration sample should be removed 3d-tiles-samples#39

• The EXT... samples from Added basic EXT_mesh_features samples 3d-tiles-samples#40 need a review and update for the latest changes in the Metadata specs

• As I mentioned earlier: I think that all samples should have a Sandcastle that shows their features. (And in In a PR that is currently open, I also added some instructions how to serve the samples with a local server). The sandacastle code should be "good" along several dimensions: Idiomatic, modern, well-formatted, documented .... The reason is simple: People will copy+paste this code, as it is (maybe without even reading it). Some snippets from open PRs will have to be polished.

One open question is that of whether this repo should contain the "unit-test-level" samples. And I think that these could be helpful (for example, like an updated version of CesiumGS/3d-tiles-samples#36 ). But at some point, one has to draw the line between a "sample", and something that goes into the Specs directory of CesiumJS....

[javagl]

Some of the points above are addressed and fixed in CesiumGS/3d-tiles-samples#45

What's still to do from this list:

• Decide on how far the samples should go into "low-level unit tests" that only show one feature or functionality. One example that is at the border is Added tileset with full metadata 3d-tiles-samples#36 (not updated for 1.1). It contains a tileset that does not "show" or "contain" anything, except for a schema that contains ALL forms of metadata that exist - originally intended as some sort of "stress test", something like this might or might not be one of the sample models. Beyond that, further, smaller, simpler models could be created or added.

• The PR Added basic EXT_mesh_features samples 3d-tiles-samples#40 has to be updated.

[javagl]

This issue is not about the 3D Tiles specification itself. Requests for additional models that should be added to the 3d-tiles-samples repo could be tracked in CesiumGS/3d-tiles-samples#64