Quantized Mesh support

[BossensM]

I noticed Quantized Mesh support is on the roadmap. It would be a very interesting feature to make the elevation rendering more performant.

What is the current timeline for Quantized Mesh support?

[gchoqueux]

This feature isn't planned at this time.

[AugmentedGeoBae]

@gchoqueux I started working on quantized mesh/ Cesium terrain format support, I have a parser but would need some advice on how the modules should flow.

• should it use existing TMS provider or new ?
• should the geometry be treated more like 3d tiles or map tiles are? -what stage should the satellite image material texture be mapped on?

[gchoqueux]

@AugmentedGeoBae Thanks to contribute!

should it use existing TMS provider or new ?

The building tile mesh process is based in TiledGeometryLayer and TileProvider. The tree tiles is quadtree. The tree root is added TiledGeometryLayer#object3d.

Tile mesh Process steps:

1. TiledGeometryLayer.update decides if a visible tile must be divided in four sub-tiles.
2. if a subdivision is requested, a command is sent to TileProvider.
3. so it builds tileMesh returned by the function TiledGeometryLayer.convert.
4. this new tileMesh is added to parent tileMesh.
5. satellite image material texture are mapped on new tileMesh with ColorLayer.update or ElevationLayer.update

You could add your parser in new converter to TiledGeometryLayer.convert. Like this:

// requester is parent tile and extent is the extent of the new tile
// convert returns THREE.Mesh 
convert(requester, extent) {
    return this.quantizedTileMesh : 
           convertToQuantizedTileMesh.convert(requester, extent, this) ||
           convertToTile.convert(requester, extent, this);
}

should the geometry be treated more like 3d tiles or map tiles are?

the Tile are THREE.Mesh so they are more 3d tiles. But I'm not sure to understand your question.

what stage should the satellite image material texture be mapped on?

Textures are mapped onto the tile after it has been added to its parent tile. (see 5. step )

[AugmentedGeoBae]

The parser itself is done and seems to be ok, tested on individual tiles with "normals" extension but couldn't find a "watermask" extension. In terms of inserting the whole flow of code into the existing architecture for tiles, the convertToTile function I agree is probably a good place to place the parser, however it doesn't really match the flow of how other data types like 3Dtiles and Vector tiles are handled.

Also I'm thinking it would make sense to make a different class extending "TMSSource" to handle whether or not to request the extensions in the request header, similar to VectorTileSource.

Lastly, it seems like the pre-computed edge geometry for the QuantizedMesh tile is a replacement for the "skirt" of a DEM tile.

[gchoqueux]

it doesn't really match the flow of how other data types like 3Dtiles and Vector tiles are handled.

Each data is managed by the combination of a layer and a source.

Also I'm thinking it would make sense to make a different class extending "TMSSource" to handle whether or not to request the extensions in the request header, similar to VectorTileSource.

Yes, it's indeed necessary to extend TMSSource to handle quantized mesh extention. This source will be added to TiledGeometryLayer (which layers it Terrain)

Lastly, it seems like the pre-computed edge geometry for the QuantizedMesh tile is a replacement for the "skirt" of a DEM tile.

Yes