Hi.
I’m developing a custom 3d tiles terrain-only generation workflow.
(In case the topic is too complicated to read and understand, I’m open to any direct suggestions about handling vertex positions at earth scale, like using double typed calculation instead of single, or using CESIUM_RTC etc. Something obvious for you may be something new for me)
I have a problem at the connected edges of the tiles I generated. Until now, no matter I’ve tried I’m not able to make any vertices at the edges ‘equal*’ wrt its closest counterpart in the other tile. In my latest attempts, the error is between 10-30 cm. See my latest enhancement, the difference between the tiles relative to default cube size, which is great but not sufficient at the same time
When I visually analyse Cesium World Terrain, the error is much more less, almost not visible in any edges between tiles in same LOD. So, there should be a solution to my problem…
…
I was initially using ‘translate’ of glTF meshes to translate the vertices to earth surface. However, it only support float/single operations. Hence, I switched to using CESIUM_RTC extension, instead of using ‘translate’ property. The result is better, as seen in the image.
Skipping how I generated the tiles from heightmaps and textures, my latest relevant step in my workflow is to bring vertices at the connected edges together for the same LOD levels :
- Import 2 connected gltf tiles into the Blender
- Take the difference of CESIUM_RTC fields and translate the 2nd tile wrt this difference. I’m still close to origin, so less floating point errors
- Now, the tiles are connected as expected, as if they are on the earth surface.
- For each edge vertex in mesh1, I compare the vertex position against mesh 2’s related vertex, and make them equal.
- Not touching CESIUM_RTC during the process
- Before saving the result, I translate mesh2 to its initial position than save the gltf meshes.
Shortly, I’m temporarly translating the 2nd tile, making snap operation then translating back the 2nd tile to its initial position.
During the snapping process I explained above, I report the distances between the vertices and the result is satisfactory enoughs (units are in meters):
Dist= 0.000061 | Mesh1 ([ 400.17355 9198.144 -5480.696 ]) ↔ Mesh2 ([ 400.1735 9198.144 -5480.696 ])
Dist= 0.000183 | Mesh1 ([ 387.7054 9219.322 -5479.6772]) ↔ Mesh2 ([ 387.70523 9219.322 -5479.6772 ])
Dist= 0.000214 | Mesh1 ([ 375.70593 9240.812 -5478.2256 ]) ↔ Mesh2 ([ 375.70572 9240.812 -5478.2256 ])
Dist= 0.000153 | Mesh1 ([ 363.25732 9262.004 -5477.189 ]) ↔ Mesh2 ([ 363.25748 9262.004 -5477.189 ])
Dist= 0.000183 | Mesh1 ([ 349.0721 9282.043 -5477.756 ]) ↔ Mesh2 ([ 349.07193 9282.043 -5477.756 ])
Dist= 0.000183 | Mesh1 ([ 335.50082 9302.489 -5477.756 ]) ↔ Mesh2 ([ 335.50064 9302.489 -5477.756 ])
However, when I render the tileset in Unreal Engine or Blender, I see those ~30 cm openings between the tiles, and I’m almost out of ideas…
- Is there another field like CESIUM_RTC, that can be used to support 64bit operations during the process. Maybe ‘matrix’ field in glTF or RTC field in 3D Tiles?
- My meshes have ‘rotation’ applied (by blender), could be a problem
- I may need to update ‘CESIUM_RTC’ value after the snapping process I described above
- Any other suggestions to check?
I’m attaching my 3dtiles, also the blog post about the precision problem:
Precisions, Precisions | DME Component Libraries for .NET 2024 r3
tdtiles_yy.zip (17.3 MB)