Basic, minimal examples; sources for README figures about 3d-tiles

[javagl]

Most of the samples from the "Sample Data" section try to demonstrate specific features of 3D Tilles. When it comes to even more basic test data, one could go very far in terms of the "exhaustiveness" that should be tested. One could start with a complete and valid 3D Tiles tileset....

{
  "asset" : {
    "version" : "1.1"
  },
  "geometricError" : 2.0,
  "root" : {
    "refine": "REPLACE",
    "boundingVolume" : {
      "box" : [ 0.5, 0.5, 0.5, 0.5, 0.0, 0.0, 0.0, 0.5, 0.0, 0.0, 0.0, 0.5 ]
    },
    "geometricError" : 1.0
  }
}

and from that, explore the space that is opened up by the combinatorial explosion on the lowest technical level.

Something that should be far more useful for implementors and tests: The Specs/Data/Cesium3DTiles directory of CesiumJS contains a large variety of "real" (but usually simple) 3D Tiles data sets. These are used for the Specs (unit tests) of the CesiumJS 3D Tiles support. And it should include most of the data sets that have been used for the screenshots in the specification.

For example, the tileset that is shown in the section that you linked to is (the same or similar to) the one that is contained in https://github.com/CesiumGS/cesium/tree/main/Specs/Data/Cesium3DTiles/Tilesets/TilesetRefinementMix

Many of these spec files have originally been created with the 3d-tiles-samples-generator. This project is not actively maintained! - but it still works insofar that it can be used to create many of the files in the CesiumJS Specs directory.

(I actually just added a link to the CesiumJS spec files as part of an update of the resources list - I could imagine that many implementors are looking for a good coverage in terms of test cases, and this should be a valuable resource for these cases)

[andreasplesch]

Thanks ! Even the most minimal, valid json could be helpful to ensure that a viewer still accepts it although it probably will never occur in actual use.

https://github.com/CesiumGS/cesium/tree/main/Specs/Data/Cesium3DTiles is what I was looking for.

https://github.com/CesiumGS/3d-tiles-samples-generator is very interesting as well. Is there a way to configure the generator to always use gltf content for the generated 3d tiles, instead of b3dm et al. ? Since the 1.0 formats are deprecated, it would be great to have a full set of samples using gltf.

[javagl]

The 3d-tiles-samples-generator originally was (a sub-project of the 3d-tiles-tools/validator and) intended for generating the Specs data in an automated, programmatic, and therefore reproducible(!!!) way. And it (still) does serve this purpose. And since there are no changes to the specification, that data will usually not change, and there is no strong reason to change the generator.

Of course, your point is valid: The project could create 3D Tiles 1.1 data in a similar fashion. But right now, it is not really in an ideal shape to be extended significantly. The codebase contains some legacy aspects (e.g. a mix of JS and TS, or functionalities related to glTF 1.0 (that may even have to be retained in one form or another, to be able to still generate the current spec data, if this uses glTF 1.0 somewhere - I'm not sure about that), and some functionalities that are implemented in a more generic form elsewhere). It might need a bit of polishing/updating before it could be extended with additional capabilities. And for some aspects of 3D Tiles 1.1 (for example, implicit tiling), implementing an automated generator is fairly non-trivial...

Beyond that, I could brainstorm for hours about what else this project could do (and.... I've probably already done that, in various places 😁 ). This includes not only 3D Tiles 1.1, but also examples that contain the glTF metadata extensions, or tilesets that have certain structures that could be used for stress-testing or benchmarking. I've been addressing a few of these points, in various places. It might be that some of this eventually converges into a "revived" version of the 3d-tiles-samples-generator, or a similar project. But there are no specific plans for this right now.

[andreasplesch]

Thanks for considering updating the generator. The difficulty of generating comprehensive test coverage for 3D Tiles 1.1 points to the very large size of the 3D Tiles specification. It may therefore make sense to define a strict subset of the spec. which would be still useful, or a core spec. As an extreme example, simply having well defined geospatial glTF content without tiling/lod features could be quite useful. Were there discussions on such restricted 3D Tiles formats ? Probably a discussion for elsewhere.

[javagl]

I think this fits exactly here (well - in this repo. Not so much in this issue).

I'm not aware of specific considerations for defining a "subset" of 3D Tiles. The specification of 3D Tiles 1.0 was a lot smaller than that of 3D Tiles 1.1. And implementing the new features of 3D Tiles 1.1 (most importantly, implicit tiling and metadata support) is not trivial. But I could imagine that any discussion about possible restrictions could be pretty opinionated.,..

I think that there have been considerations for glTF extensions that carry some form of geospatial information. Very roughly, a glTF extension that just stores a latitude/longitute/height saying where this object should be located on the globe. And of course, there are several discussions (and even more or less specific extension proposals) for LOD support in glTF. And this goes so far that there are even considerations for a "Geospatial profile" of glTF ( https://www.khronos.org/assets/uploads/developers/presentations/Geospatial_Profile.pdf ). So I guess that some borders might become a bit more "blurred" in the future. But from a "top-town" perspective, 3D Tiles is bringing all this together, in a form that is time-tested and agreed upon in form of an open standard. And it could be difficult to say what exactly this "restricted" format should be.

[andreasplesch]

Interesting points. Had not heard about Leonard's geospatial glTF profile. I agree, 3D tiles really already covers these use cases. and is well established Borrowing the idea of profiles, there could be multiple 'profiles' which define restrictions/subsets, very roughly:

• glTF profle: only glTF content
• 'root tile' profile: only one tile, no children / LOD
• 'google' profile: everything necessary to load Google 3D Tiles
  ...

[chris-little]

@andreasplesch The EDR API SWG, in response to important user requirements, are considering adding a Part 3 to the OGC API-EDR Part 1: Core standard support for restrictive profiles, and we envisage that the approach may be useful across many OGC APIs, just as we have done with the Part 2: Publish-Subscribe workflow.
Is it worth exploring any overlaps/commonality of approaches (our support would be at the schema fragment level)?

[andreasplesch]

This came about from developing a sensible strategy to define priorities for implementing 3D Tiles. I believe most if not all existing non-Cesium implementations do not attempt to provide all features because they are either not needed for a use case or the resource cost of implementing is too high. It would be important for an international, ratified standard to have multiple independent implementations, especially if extensions or optional features are also standardized.

So, so far this is just exploratory thinking, and perhaps a bit too early to expand to a generic, perhaps formalized approach. I imagine that if we can line things up to do concrete 3D Tiles implementation work that this will be a better time to match implementation steps to a specific restrictive profile and to work on how to actually specify such a profile. Thanks for mentioning this OGC initiative and I will be happy to hear more about it.

Here is an example of profiles. The proposal of a geospatial glTF profile above is probably informed by how X3D defines profiles: https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/profileIndex.html

An X3D profile is approximately a subset of X3D components which are sets of X3D nodes. This shows one way how in order to define profiles it is necessary to group and encapsulate functionality, at potentially multiple levels. For X3D, the node level is most fundamental but the component level is also convenient for communicating. It is convenient to say that this X3D content requires that component or that this implementation does not support the NURBS component, for example. [Originally, the profiles were used for certification purposes but they are too outdated for that purpose].

In summary, it may be too early to compare and contrast approaches on restrictive profiles, but exchanging new ideas is always welcome.

[chris-little]

Thank you. It seems to me that the gITF profiles are better matched to OGC Conformance Classes at present. I now see how (not why!) the complexity gives rise to the need to restrict functionality in implementations.

[andreasplesch]

Right, subsets of conformance may be a more appropriate way to communicate implementation capability vs. application requirements. Let me close this issue since the initial questions have run their course.