[CityTiler] Tiling with textures creates many more tiles

[jailln]

Running the city tiler with the --with-texture option results in a tileset with a lot more tiles. From my tests, from 32x to 64x more tiles are generated with the --with-texture option for the same input dataset. Do you know where this come from and if it is an intended behavior ?

I think this has an impact on the tileset size and on the visualization performances.

[LorenzoMarnat]

When we create textured 3DTiles from CityGML, the CItyTiler split the surfaces to be able to apply the textures. Consequently, we will have one ObjectToTile per surface (instead of one ObjectToTile per CityGML CityObject).
Since the kd_tree puts a maximum of 500 ObjectToTile in a tile, it will put only 500 surfaces per tile if the surfaces are split (and 500 complete CityObjects per tile otherwise).
So if we have for example 500 buildings with a total of 10 000 surfaces, in a case we will create one tile of 500 buildings (case surfaces merged), and 20 tiles of 500 surfaces in the other case.

The solutions are:

• Offer the possibility to set the kd_tree limit as an argument.
• Limit the size of a tile in another way (as discussed here, with triangles, texture size, etc)

[jailln]

Thanks for the precision. I agree with both solutions (that seems complementary). We could also add a third one: actually use the number of features to create a tile when tiling with textures (and not the number of surfaces) even if the features are split for texturing (this probably means keeping a list of initial objects and a link to their surfaces). I think this would make more sense with a kd_tree based on a number of features per tile since features are usually defined according to their semantics for this type of data (citygml): e.g. we refer to a building, a bridge, a roof, etc. and so it is easier to create a tileset with n features per tile than with n surfaces per tile IMO (at least until other ways of limiting tiles size are used as proposed in your second item). Doing so would also avoid having "semantically defined" features (e.g. buildings, bridges) scattered across multiple tiles.

[LorenzoMarnat]

With tile by tile PR, the features are split into surfaces after the kd-tree distribution. Also, the kd-tree max PR allows to choose the number of features per tile. So, we will always put n features per tile (instead of n surfaces).

By default, each tile can contain 500 features (max). When creating a textured tileset, this default value is divided by 20 to reduce the size of the texture atlases. So, creating a textured tileset will still create more tiles than a non-textured tileset. The user can choose to create tiles of 500 textured features by using --kd_tree_max 500.

Work will be done to reduce the size (in memory) of textured tiles and to compress the images/geometries.