3D Tiles Tools roadmap

[pjcozzi]

More ideas to come...

Tools

Definitely

• gzip/unzip all tiles in a tileset
• Fusion: Merge tileset with external tileset.json references into one tileset.json
• Fission: Separate a monolithic tileset.json into several tileset.json based on different criteria: e.g., n tiles per tileset.json, m levels per tileset.json, etc.
• Generate stats like gltf-statistics.
  • Given a tileset or tile, how memory is used: total memory, geometry memory, texture memory, batch table memory, other memory (e.g., JSON)
• Add the ability to apply per-tile stages to all tiles in a tileset. For example: Optimize b3dm 3d-tiles-validator#30

As Needed

• Visualize a tileset's spatial data structure, perhaps even an interactive tileset explorer using Cesium with D3 overlay
• Separate composites, i.e., separate a composite tile into several tiles
  • Separate out into separate tilesets if useful, e.g., one for buildings, one for trees, etc.
  • Combine tiles into composites
• Merge multiple tilesets into one tileset

Validator

• See 3D Tiles Validator Roadmap 3d-tiles-validator#5

[javagl]

tl;dr: Version 0.2.0 of the 3D Tiles Tools has just been released. On the CLI level, it mainly emulates the old functionality. Some of the original roadmap points have already been addressed. But under the hood, the functionality has been extended, which means that further roadmap points may be tackled, and other ideas may be added here soon.

---

Regarding the open points from the initial post here:

Fission: Separate a monolithic tileset.json into several tileset.json based on different criteria: e.g., n tiles per tileset.json, m levels per tileset.json, etc.

It should be relatively easy now to add this as a demo or a "proof of concept". Regarding the criteria for the "fission". One approach could be to just re-apply the idea of the "subtree levels" from implicit tiling: Given a tileset with n levels, split this into "subtrees" (i.e. external tilesets) that each have m levels.

Beyond that, such a demo could help to flesh out the answers to the questions of 1. how to implement that generically, based on the new functionality, 2. how to offer that at command line, and 3. how to offer that as a 'pipeline' stage operation.

In any case: We have to be careful that we don't establish a toooo gray area between 'tiling' and 'tools stuff'. There is some possible overlap here....

Generate stats like gltf-statistics.

• Given a tileset or tile, how memory is used: total memory, geometry memory, texture memory, batch table memory, other memory (e.g., JSON)

The gltf-statistics was published 8 years ago, but maybe that is a sign for it being "final and stable". It could probably even be integrated into the (tileset-level) stats generation that is supposed to be offered by the tools.

Right now, there is a TraversalStatsDemo that shows a very basic way of collecting statistics. It traverses a tileset, and generates a JSON output like this:

{
  "totalNumberOfTiles": 22,
  "totalNumberOfSubtrees": 6,
  "geometricError": {
    "count": 22,
    "sum": 52,
    "min": 1,
    "max": 8,
    "avg": 2.3636363636363638,
    "stdDev": 2.10076727423479
  },
  "tileFileSize": {
    "count": 21,
    "sum": 25296,
    "min": 1200,
    "max": 1208,
    "avg": 1204.5714285714287,
    "stdDev": 3.0948717731946425
  },
  ...
}

The exact level of detail has to be decided upon - and if this is supposed to be implented as a feature, it should be tracked in an own issue.

Add the ability to apply per-tile stages to all tiles in a tileset. For example: CesiumGS/3d-tiles-validator#30

The content processing has been generalized during the rewrite. Things like the optimizeB3dm already can be applied to all contents of a tileset now. This can either be done with a few lines of code, or as part of a 'pipeline', where the latter (i.e. all the pipeline infrastructure) is still a bit preliminary, and we still have to decide what exactly should be possible with pipelines, and how...

Visualize a tileset's spatial data structure, perhaps even an interactive tileset explorer using Cesium with D3 overlay

It's not clear what this is supposed to be (i.e. in how far that should be something else than CesiumJS - maybe with a "browsable tree structure" as a UI element?). If this is supposed to be tackled, it should be handled in a dedicated issue.

Separate composites, i.e., separate a composite tile into several tiles

• Separate out into separate tilesets if useful, e.g., one for buildings, one for trees, etc.

Most of the "content-level" operations can already be applied to all contents within a tileset. But exactly the cmptToGlb is a noteworthy exception here. There are some caveats. A low-level one is that there might be an implicit tileset that uses CMPT files as its tile content. Splitting these CMPTs into GLBs would require creating multiple template URIs, and ... one never knows how many GLBs are in one CMPT...

---

Further, possible points for the roadmap

All these are high-level points to think about. Each of them could become an issue when they are addressed.

• A function for converting implicit to explicit tilesets (there's already a draft demo for that, because it's relatively easy, and can be useful for debugging and analyzing...)
• Integrating gltf-transform or gltfpack to support meshopt compression
• (Re-)Integrating support for KTX2 compression
• Better integration of .3DTILES files that are used as external tilesets. (There already is some support for that for 3TZ, but none for 3DTILES yet...)
• Generalizing the 'pipeline' in many ways. For example, right now a pipeline can only have one input and one output, so an operation like merge can not be modeled with that, and a split operation may also hit some limits here...
• ....