Improvements for tileset merging

[javagl]

Some considerations that came up in the context of #200 :

• For the case that there are "many" input files, one could consider to introduce some form of hierarchy. Right now, if it received 1000 input files, then these would all be children of the root tile, but this is certainly not desirable. The "nested" calls (as shown in the PR) could already be used to build some form of hierarchy. But this requires knowledge about the intended structure, and there may be details about the refine/geometricError that have to be considered for this to make sense.
• The tileset merger currently takes the bounding volume from the input, and converts this into a boundingVolume.box. It might be desirable (not only for the 3TZ case, but in general) to introduce a special handling for the case where all inputs have a boundingVolume.region. It should be fairly easy to create a "merged region" from that. (Yeah, (anti)meridian, yadda yadda - a bit of modulo here and there should do it...)

[jo-chemla]

Really nice to see hierarchical tileset merging being introduced in this thread!
Quick pointer to a previous slightly related discussion, #168, regarding smart-merge but extending merging to even insertion/updating (but nice to see this thread being dedicated to the merging improvements)

This resonates a lot with some use-cases we faced:

• merging multiple non-overlapping tilesets into regional tilesets, or even into one single mega-tileset. For example a discrete collection of tilesets representing sparse 3D scans covering various sites somewhat close to one another, up to the city, country or even world level. (I imagine this merging would probably use a bottom-up approach, using boundingVolumes of each input tileset, deciding how to group them into a hierarchical structure for the level just above, recursively?). Merging the french Open-Data tilesets listed in the reference section would be great.
• even simpler, when one want to merge tilesets that are covering a regular, non-overlapping grid - eg tiles of the french lidar-hd program, currently COPC but that could be served as 3Dtiles. See this Giro3D example of 180 files which use their AggregatePointCloudSource API
• non-overlapping administrative boundaries like regions in a given country, where hierarchical tilting could be smart at assembling nerighboring tiles into a group, and grouping groups upper in the hierarchy.

[javagl]

The specific points here have just been small follow-ups for the 3TZ merging, but you're right that there is some overlap to the other issue where you already mentioned the demand for "(smart) hierarchical merging".

As mentioned in that issue: The whole topic is open-ended, on both sides:

• High-level: What is offered as an "API". This is related to the (still) hypothetical TilesetModel class that could allow adding and removing elements (including external tilesets), and arbitrary forms of optimizations or post-processing steps.
• Low-level: What functionality is required 'under the hood' for these steps. One of the main differentations here is whether it covers low-level geometry processing (actually merging, splitting, or simplifiying(!) meshes), or whether it treats "tile content" (i.e. a single GLB, or rather its bounding volume) as the most fundamental building block.

I think that for the really cool and fancy functionalities, geometry processing will be required.

---

An aside: The VertexProcessing class from #189 is a tiny step, but ... nearly "obsolete" already: I locally started generalizing that to a GeometryProcessing class that allows iterating over triangles and extract their vertices/texCoords/normals and such. But this is a bit 'on hold' for now. First of all, it is an unaccounted, spare-time experiment. And more importantly: I think that this also would be far to narrow case. Instead of

VertexProcessing.process(stuff, (triangle) => {
   doSomethingWith(triangle);
}

it could make sense to take the "leap" here, and try to introduce an actual Mesh class, to change that to
doSomethingWith(mesh.getTriangle(42));
This may not have to happen from scratch. There are some ~"geometry processing libraries" out there. And I assume that things like ThreeJS & Co already offer a lot of that. Investigating and integrating that is a non-trivial task either way.

---

But that said: I think that even without geometry processing, and on the level where a "tile content" is the 'atomic' element, some very useful functionality could be offered. At least, I think that it could be relatively easy to add some sort of hierarchy. The brainstorming level would be to take the 100 inputs, compute the total bounding volume, and then just build the hierarchy as a regular quadtree over that. (The child bounding volumes may overlap, that's not so much an issue).

[javagl]

A small addendum: I had a short look at the linked demo. (They are actually accesing LAZ files? That's surpising. It's a bit of an inconvenient format). In general, I'm very much a fan of 'views' in APIs, that offer "something big and complex", but as-if it was small and simple. And from my understanding, they are not creating any form of "hierarchy" or anything that could be persisted on disc. The selection of the "level of detail" seems to be happening dynamically, based on ~the number of points that are there", purely at runtime.