Introducing vsgXchange::Tiles3D for loading 3DTiles 1.0 databases

[vsg-dev]

The culmination of my last 2 months work was implementing native support for 3D Tiles 1.0, as 3D Tiles builds upon glTF, vsgXchange::Tiles3D buiilds upon vsgXchange::gltf and vsg::JSONParser. For now we have support for 3D Tiles 1.0, support for 1.1 will follow but don't yet development plans in place. The 3D Tiles 1.0 loader is provided by vsgXchange::Tiles3D, this class name isn't ideal but was work around C++ requirement that class names can't be with numbers. Tiles3D is checked into vsgExamples master and adds no external dependencies beyond VulkanSceneGraph's dependencies:

include/vsgXchange/3DTiles.h.

The client funding this work only has 1.0 databases at this point so it made sense to implement 1.0 first. 3D Tiles 1.0 is a clumsy collection of file formats - tileset.json at the root and reference other .json files and .i3dm, .b3dm, .cmpts and .pnts files. vsgXchange::Tiles3D implements the .json, .i3dm, .b3dm and .cmpts formats. As the client data doesn't include .pnts files I chose to concentrate on the formats being used.

3D Tiles 1.1 moves to use of glTF extensions rather than a collection of custom file formats, which should make it more straight forward and cleaner to support. I haven't yet looked at the specs in detail so am not at the point of being able to estimate how much further work is required for 1.1 support.

[xiaoxin0214]

I'm trying to load a 3D Tiles dataset using the vsgviewer, but the model does not appear.

vsgviewer.exe Tileset/tileset.json

The only log message I see is:

info: Tiles3D::read_json(Tileset/tileset.json)

I tested loading a single .b3dm file from the same dataset, and it works fine.

[timoore]

@robertosfield are you handling RTC_CENTER in the tiles?

The metadata indexed by _BATCH_ID are interpreted by each application, but they shouldn't affect geometric position.

[xiaoxin0214]

The bound of the root is correct, but the bounds for its children seem incorrect.

[xiaoxin0214]

@robertosfield are you handling RTC_CENTER in the tiles?

The metadata indexed by _BATCH_ID are interpreted by each application, but they shouldn't affect geometric position.

You're right, the bounds of the children node are correct when accounting for the offset.

[robertosfield]

@robertosfield are you handling RTC_CENTER in the tiles?

The metadata indexed by _BATCH_ID are interpreted by each application, but they shouldn't affect geometric position.

Ooo. I wrote the parsing code for RTC_CENTER and look at the b3dm.cpp all it has is the parsing, it doesn't look to apply them. The i3dm.cpp implementation does handle the RTC_CENTER.

Will investigate now I have a good lead.

[timoore]

@robertosfield are you handling RTC_CENTER in the tiles?

The metadata indexed by _BATCH_ID are interpreted by each application, but they shouldn't affect geometric position.

I wanted to clarify this a bit. The batch IDs essentially index into rows of a database. That isn't random binary data; the format is well-defined by the 3D Tiles spec. The semantics are application-specific, but in practice they can be widely interpreted. Columns with names like Latitude, Longitude, Color, etc. don't leave much to the imagination. vsgCs uses a property named "cesium#color" to give color to OSM buildings.

3D Tiles 1.1 relies on the glTF extensions EXT_structural_metadata and EXT_mesh_features, which go a lot farther with metadata, including references to schema definitions.

[robertosfield]

Thanks to @timoore spotting that RTC_CENTER wasn't being handled I have added the check for and then assigned to a vsg::MatrixTransform when an RTC_CENTER is assigned to a .b3dm. This fix is checked into vsgXchange master with commit vsg-dev/vsgXchange@806243c.

This enables this dataset to get closer to working OK with this datasets:

When you zoom out far enough you see the tall buildings in parent.b3dm pop in replacing the smaller ones completely. What should actually be happening is the smaller buildings should appear when closer adding to taller ones, rather than replacing. There is a field in 3D Tiles that specify the LOD behavior, either ADD or REPLACE when a LOD transition happens.

The vsg::LOD/PagedLOD only has support for the REPLACE implementation so that's what I focused on up to now. The databases I had for testing against all used REPLACE so that was OK.

This dataset uses ADD so requires me to implement a handling of this case. Added support for replace to LOD/PagedLOD would complicate the API and Implementation and the extra checks would slow traversal so not a natural fit for a high performance API - we don't want to slow things down for everyone just because some unusual models want to do something different.

However, when I was implementing the parsing of the 3D Tiles 1.0 spec and wrote the code for parsing the ADD/REPLACE the issue about ADD is one I briefly brainstormed and came up with idea that if we add the low res child to the high res group then we can use LOD/PagedLOD keeping the extra complexity entirely on the scene graph building side and adding no CPU overhead to the rendering side.

With knowledge that I could probably cobble a solution for ADD I just moved on to the other more pressing 3D Tiles work, knowing that one day I'd need to return to it...

[robertosfield]

I have added a warning to vsgXchange::Tiles3D to report when Tile::refine = ADD is set in a database but not yet supported yet, so you'll see:

Warning: Tiles3D::SceneGraphBuilder::createTile(ref_ptr<N10vsgXchange7Tiles3D4TileE>(N10vsgXchange7Tiles3D4TileE 0x7bb601d5c1c8), 0) refine = ADD not yet implemented for LOD.

It's end of day here so I'll have to tackle the implementation of ADD tomorrow.

[robertosfield]

I have implemented the Tile::refine=="ADD" support in vsgXchange::Tile3D, and checked it into vsgXchange master.

Now the Tile's local content subgraph is added to the high res children of the LOD/PagedLOD, all without any mods to the core VSG classes. This is what the dataset now looks like: