I’ve done some experiments with generating different LODs on a 3D volumetric mesh that has vector data associated with it (varying scalar data) using the 3D pipeline. The scalar data is attached to the vertices/nodes of the mesh. I use a batched table to map the mesh’s vertex ids to property data. E.g. Lets say my property is called value than:
vertex id | value
0 | 4.5
1 | 6.7
2 | -4.2
3 | 12.2
…
The properties on the generated LOD geometries are scrambled. I have attached 3 screenshots to illustrate the problem: 1) Original3DMeshInCesium.JPG shows the original volumetric mesh in Cesium with the scalar data on the vertices shown, 2) LoD3DMeshInCesium.JPG is the generated LOD geometries with the scalar data shown - not the values are all ‘scrambled’ with respect to the original data (1), 3) CloseUpLoD3DMeshInCesium.JPG is just a close up of the problem of the scalar data being ‘scrambled’.
I assume I am doing something wrong and there is a solution to displaying varying vector data attributed to vertices of a mesh on all LODs.
Currently the Photogrammetry Tiler is used since it generates the intermediate LODs for the geometry. Perhaps that is the source of the problem?
The BIM & CAD Tiler wasn’t used since it didn’t look as though it generated the intermediate LODs.
The input data format is originally VTK geometry formats (volumetric meshes) which I then convert to gITF file formats (.gltf, .glb). Those gITF files are inputs the tiling pipeline (photogrammetry in this case) which generates the tileset’s .json file along with the .b3dm files for the tileset’s hierarchy. The tileset json file and .b3dm files are exported/loaded into cesiumJS.
I think the issue here is that the photogrammetry tiler tries to average out the vertex attributes, which may not be the correct thing to do here. One workaround could be to embed this data into a texture instead of into vertex attributes, which should produce a more correct LOD representation. The other thing I can think of is to avoid tiling the texture entirely, and add it separately in CesiumJS as a textured polygon draped over the geometry.
This sounds like a use case we can support better, so if you are able to share some sample data we can use to test with on our side, you can reach out to support@cesium.com, link to this thread, and we’d be happy to take a look.
We have tested both the on-premise (trial) and cesium ion for the tiling.
I am not sure if embedding that data as a texture is optimal. This is because most of the 3D models we want to bring into Cesium represent volumes and not just surfaces or the boundaries of volumes (e.g. like buildings). Ultimately, the plan would to develop some filters that would slice through these volumes where we can explore the varying of these properties inside the 3D models. So, I don’t think the texture approach would work in this case, although I would be wrong.
