Loading 3D Tiles of France buildings takes long

[bertt]

I'm trying to load a 3D Tileset of France buildings (https://storage.googleapis.com/ahp-research/maquette/ign/buildings/beta.3/1.0/tileset.json) in ITowns (latest commit main branch), but loading takes forever.

Demo: https://bertt.github.io/itowns_issues/france_buildings/issue/examples/index.html

In CesiumJS there is no problem loading this tileset see https://storage.googleapis.com/ahp-research/maquette/ign/buildings/beta.3/index.html

[jailln]

Hi, thanks for your issue and sorry for the late reply.

By looking at the network pane, we seem to load all tilesets before loading b3dms. I haven't find a quick fix yet.

We are currently deprecating our 3D tiles implementation and migrating to 3DTilesRendererJS (see this branch and #2225). This migration should land in the coming month. However it doesn't work on this branch either but with different symptoms 😅 We'll keep it in mind during this migration and try to fix it.

[gkjohnson]

This should be addressed in 3DTilesRendererJS, now, as of NASA-AMMOS/3DTilesRendererJS#672 NASA-AMMOS/3DTilesRendererJS#670. This is a fairly oddly-structured tile set, though, with no hierarchy. It's basically a flat list of tiles with 0 geometric error under a root (or two) with geometric error of 2000. That means that it will just load everything in the frustum immediately once the camera is close enough - easily up to thousands of child tiles. It's inevitable that you'll get performance degradation with 30,000+ tiles check visibility for.

[gkjohnson]

I've been doing some testing and the "optimization" required for this tile set can cause some issues with rendering elsewhere - ie tile gaps when turning the camera. I've described the problem here and discussed it with someone from Cesium: CesiumGS/3d-tiles#776

Bottom line is I feel this tile set isn't formed well and should be using the "ADD" refinement rather than "REPLACE" if it's going to use such a flat structure with no intermediate levels of detail. The fact that it works in Cesium is due to more of an implementation quirk in my opinion. Happy to explain more if there are questions but I'm going to revert the optimization made so this tile set will load the 30,000+ tiles again until it's been adjusted / regenerated to use a more appropriate tile structure.

[bertt]

Hi, ok thanks for the investigations.

So far I understood the ADD/REPLACE is only relevant when there are 2 models (one with more detail, one with less) at the same place like in the dragons demo https://github.com/CesiumGS/3d-tiles-samples/tree/main/1.0/TilesetWithDiscreteLOD . When the camera get's closer the less detailed model is ADD(ed) to or REPLACE(d) by the more detailed model.

In the case of the buildings there are no overlapping tiles, so the choice of refine:REPLACE was arbitrary. If somehow refine:ADD will work better in 3DTilesRenderer I will create another version using refine:ADD instead.

Btw there is some hierarchy in this tileset:

• root tileset.json references all b3dm tiles level 0-8 + tileset.json files at level 8

• level 8 tileset.json files :referencing all tiles b3dm level 8-16

All b3dm tiles have maximum 1000 buildings. Will this work (using refine:ADD) you think, or do you recommend another hierarchy?

[gkjohnson]

Generally "REPLACE" refinement means that all renderable children must be loaded before a tile is replaced by it's children because notionally it's used for contiguous sets of terrain and to avoid gaps when moving the camera. In the case of this tile set that means loading the thousands of renderable children that meet the error requirement (which is all of them since it's 0 everywhere). This is the case in Cesium, as well - it's just a quirk of the implementation that that doesn't apply to empty root tile sets which can cause rendering artifacts in more typical cases. From the above referenced issue Cesium would also consider disabling this behavior by default which will mean your tile set will also not really load in Cesium, as well:

Probably what CesiumJS should do is disable this optimization unless skipLevelOfDetail is true.

"ADD" refinement does not wait for all renderable children to load before rendering the children. I agree it's not super clear from the spec but this is the behavior in both engines.

All b3dm tiles have maximum 1000 buildings. Will this work (using refine:ADD) you think, or do you recommend another hierarchy?

Using "ADD" will get the behavior you're seeing in Cesium work in 3DTilesRendererJS - and will continue to work if cesium changes the above behavior, as well. However looking at the tile set there are still almost 30,000 children in the root. That's 30,000 bounding volumes that have to have their frustum checked, etc. This is going to heavily impact performance no matter what. It would be best to have a deeper quadtree-like hierarchy that allows frustum checking to cull larger parts of the tree earlier to prevent unnecessary calculations.

[bertt]

I've created a new version beta.4 of this tileset, refinement method from replace to add and geometric errors changed. Hopefully it works better... See https://storage.googleapis.com/ahp-research/maquette/ign/buildings/beta.4/index.html , https://storage.googleapis.com/ahp-research/maquette/ign/buildings/beta.4/1.0/tileset.json