Reference to py3dtiles smart merge for tilesets merging / insertion / updating

[jo-chemla]

Following a discussion around giro3d COPC support, the py3dtiles team just opened a discussion thread to make their merger smarter - see below. Link to the original discussion here - note I'm not part of the py3dtiles team.

In case it's useful, I'm just referencing it here, it might spawn joint work on the subject.

Currently "py3dtiles merge" can only generates parent tilesets from child tilesets, that is all.
It could be smarter, and support more use case:

• generate more than one level if the number of tilesets / points mandates it
• insert children tilesets into a mega tileset
• update a tileset somewhere in the hierarchy, while updating all the preview tiles

Original quote:

Quick note, at the moment the ecosystem for 3dtiles production is probably missing a utility, which could fit within py3dtiles or 3d-tiles-tools, akin to a smart-merge of tilesets. This utility would insert into a mega tileset children tilesets - not simply dump all tilesets to be merged under as the root children - and either replace within the hierarchy highest resolution tiles, or merge overlapping tiles accordingly while still respecting tile constraints on max-point-count-per-tile etc.

[javagl]

There is quite some context (in the discussion, and even more so the linked PR) that I'll have to wrap my head around. And I'll have to start "nearly from scratch" with that: I'm aware of py3dtiles in general, but have not actively used it or tracked its development.

Some high-level thoughts for now:

The focus of the 3D Tiles Tools is currently pretty much on that of a command-line tool. There is no "public, stable API" to (officially) use it as a library, even though in many cases, the CLI commands have a 1:1 mapping to API calls. The current merge functionality is therefore pretty simple in terms of what it offers (similar to py3dtiles): Some inputs, one output, zero configurability. And there are many options for making the underling functionality "more powerful".

Regarding the bullet points and some of the quoted text, it might be necessary to define the use-cases more clearly. (That will likely happen in the linked discussion at some point). Very generally speaking, there are the usual trade-offs between "simple usage" and "fine-grained control" (bridging that gap with "sensible default values" where applicable).

From my current understanding, I think that some of the desired functionality would require a more powerful structure in general. Right now, the structure of something like a 'tileset' in the 3D Tiles Tools is literally contained in the structure package, where Tileset.ts is just a plain, dumb, typed representation of the JSON (generated from the schema). There are no higher-level, "model"-like classes that ensure any form of consistency, or allow any form of consistent modifications.

However, I thought about some approaches here. And I drafted some of this both in TypeScript (on top of the 3D Tiles Tools classes) and in Java (as part of some "J3DTiles" library that I'm working on). This was only done locally, as some brainstorming, off the clock. But the idea was to have some "...Model" classes that ensure consistency and allow some convenient operations, involving things like

  const tilesetModel = TilesetModels.create();
  const root = tilesetModel.getRoot();
  root.setTransformFromCartesian(-75.152408, 39.946975, 20);
  root.addContent(ContentModels.create("unitCube_0_0_0.glb"));

which could then take care of, for example, computing the proper bounding volumes from the GLB data. (Computing the bounding volumes manually is a pain in the back...).

An infrastructure like this might at the very least be useful, but is probably plainly necessary for these tasks:

• generate more than one level if the number of tilesets / points mandates it

It's not entirely clear what these "levels" should consist of. Imagine 100 tilesets where each tile contains only one GLB file of a single building. And now that should be assembled into a "city". Right now, the result of merge would be a tileset with a root node with 100 children - certainly not ideal. But "ideal" would be a tileset with multiple levels, where the root has 4 children, where each child contains a simplified representation of all the 25 buildings that it descendants will contain. This is fairly non-trivial, and requires low-level geometry processing (specifically, geometry simplification).

insert children tilesets into a mega tileset

Something like this should be simple with such a set of "model" classes - in pseudocode:

Tileset megaTileset = load("mega.json");
Tileset toInsert = load("small.json");
megaTileset.getRoot().getChild(12).getChild(23).addChild(toInsert);
megaTileset.recomputeBoundingVolumes(); // etc...

• update a tileset somewhere in the hierarchy, while updating all the preview tiles

It's not clear what "preview tiles" refers to, exactly. But in general, consistent modifications (like adding/removing/replacing tiles or contents) should be offered by that infrastructure as well.

---

Maybe related: One thing that I wanted to try out for quite a while now is the opposite of merge: There could be a function that receives a tileset.json where the tile hierarchy has, say, 20 levels, and it splits that tileset into smaller, bite-sized pieces. For example, so that within that hierarchy, every tile at level 10 becomes the root node of an external tileset. (This is, in fact, somewhat similar to the "subtree" concept of implicit tiling...)