ErixenCruz
commented
3 years ago With replacement refinement, contents in multiple contents that aren't defined for deeper levels while the other contents defined in the extension are end up being replaced with nothing. Refinement is a tile property, and because datasets in CDB are not defined in the same levels and tiles at each other, multiple contents will not work. Thus, we are abandoning 3DTILES_multiple_contents for CDB. I will adapt this PR to not use multiple contents. Instead, it will make one tileset per dataset/component selector pair as vanilla CDB to 3DTiles does. Tiles at level 0 and up will still be implicitly defined.
sanjeetsuhag
@sanjeetsuhag This is ready for review. This PR adds support for using
3DTILES_multiple_contentstogether with3DTILES_implicit_tiling. When a b3dm or cmpt file is written to disk during conversion from CDB to 3D Tiles, the appropriate availability bit for the dataset, component selectors, level, UREF, and RREF of the tile is written. The availability buffers are organized in one big map into subtrees. The map goes from dataset (Elevation, GSModel, RoadNetwork etc) to component selector pair to subtree root level, x, y, to the subtree object, which has buffers for node and child subtree availability. The CDB input is split into 3 "dataset groups": elevation, GSModels, and everything else (GTModels and vectors). This was done because GSModels use additive refinement while the other datasets use replacement refinement. The dataset groups are combined as external tilesets in the root tileset json. For each group, we write the subtree files for the availability buffers that were created when writing the b3dms and cmpts. Then, we write the tileset json for the geocell, using the multiple contents extension to combine datasets within the same group. Explicit tiling syntax is used for the negative levels, and implicit for the nonnegative.