search

CesiumGS / cesium-native

Apache License 2.0
441 stars 215 forks source link

Support for 3D Tiles tileset CRS conversion #927

Open arkel-77 opened 4 months ago

arkel-77 commented 4 months ago

I’m working on a light renderer for 3D tiles I’m streaming from an external source. The issue is these 3D tiles use a vendor-specific extension to specify an arbitrary CRS, most often a UTM zone. I can easily parse this CRS from the tileset JSON, but is there any way to tell cesium-native this info? Even just a hook to allow me to specify a point conversion function from the tileset frame to ECEF would be great.

Barring that, I can manually transform the mesh vertices, but by the time the IPrepareRenderResources gets access to the tile contents it seems to have already been transformed and/or rotated, so at which stage in the pipeline should I attempt the conversion & how can I ensure it works correctly?

kring commented 3 months ago

The issue is these 3D tiles use a vendor-specific extension to specify an arbitrary CRS, most often a UTM zone. I can easily parse this CRS from the tileset JSON, but is there any way to tell cesium-native this info?

No, not currently. Cesium Native expects tilesets to be expressed in ECEF, consistent with the 3D Tiles specification.

by the time the IPrepareRenderResources gets access to the tile contents it seems to have already been transformed and/or rotated

Can you elaborate on this? The glTF given to the IPrepareRendererResources methods - especially prepareInLoadThread - should be a fairly true representation of the content of the glTF. There is some decoding of extensions (Draco, for example), but the vertices should not be modified.

arkel-77 commented 3 months ago

Can you elaborate on this? The glTF given to the IPrepareRendererResources methods - especially prepareInLoadThread - should be a fairly true representation of the content of the glTF. There is some decoding of extensions (Draco, for example), but the vertices should not be modified.

I must not be understanding the glTF spec correctly then. I tried using prepareInLoadThread to transform the vertices into ECEF using PROJ but it still didn't come out right - I thought maybe there were some unexpected transformations going on behind the scenes that could cause the model to wind up in the wrong position/orientation.

kring commented 3 months ago

The glTF itself might have a series of transformations in its nodes. And the 3D Tiles tileset.json might have a transformation in the hierarchy of tiles. There is also an implicit Y-up to Z-up transformation, explained here: https://github.com/CesiumGS/3d-tiles/tree/main/specification#gltf-transforms