terrain error

[Crab-Tang]

#

when i load a terrain( not the cesium ion) it has some tile err.

[Crab-Tang]

[baothientran]

hi @Crab-Tang if you don't mind, can you please share the asset with us for debugging purpose? If it can't be shared with the public, you can send it to support@cesium.com

[Crab-Tang]

hi @Crab-Tang if you don't mind, can you please share the asset with us for debugging purpose? If it can't be shared with the public, you can send it to support@cesium.com

I sent the data to your email, please check it

[Crab-Tang]

hi @Crab-Tang if you don't mind, can you please share the asset with us for debugging purpose? If it can't be shared with the public, you can send it to support@cesium.com

hi， did you have some clue , Maybe there is something wrong with the up sampling？

[baothientran]

Hi @Crab-Tang

This looks like the imagery doesn't map correctly to the upsampled tile, especially when the high level tile (level 15) is upsampled from very low tile (level 0). For example, this tile below only has two imagery tiles mapped to it. @kring do you have any hints of what may be the cause for this one? FYI the tile in the image below is upsampled from a tile level 0

@Crab-Tang I took a look at the data, and it seems like the binary quantized mesh doesn’t contain the metadata for availability, which makes Cesium Unreal only display the very top level.

To provide you some context, in the past, the availability was embedded in the layer.json, which your asset is currently storing in the available field. However, it doesn’t work well with high resolution terrain dataset which covers a very large area because at the highest LOD, the quadtree can store more than thousand tiles, which may affect system’s memory. So we work around that by placing the availability within the tile binary content. That availability doesn’t cover the whole subtree to the leaf. Rather, we may only specify the availability for every next 5 (or smaller number if you want) level child tiles. For example, in the tile level 0, the availability will be specified up to tiles level 5. Then for every tile level 5, there will be availability up to tiles level 10, and so on.

CesiumJS provides backward combability with the availability in the layer.json, but it will be deprecated soon. Unfortunately, Cesium Native doesn’t provide that functionality. The workaround currently is to move the available field in the layer.json into the quantized mesh’s metadata extension. The format is the same as the available field in the layer.json. In other word, you can embed the below json into the binary quantized mesh:

{
    "available": [
        [
            {
                "endX": 1,
                "endY": 0,
                "startX": 0,
                "startY": 0
            }
        ],
        [
            {
                "endX": 3,
                "endY": 1,
                "startX": 2,
                "startY": 0
            }
        ]
    ]
}

This section from quantized mesh specification has more information about storing metadata into the quantized mesh content.

I also link this cesium-native code that is used to parse the quantized mesh’s metadata in case it helps to adjust your asset

[Crab-Tang]

Hi @Crab-Tang

This looks like the imagery doesn't map correctly to the upsampled tile, especially when the high level tile (level 15) is upsampled from very low tile (level 0). For example, this tile below only has two imagery tiles mapped to it. @kring do you have any hints of what may be the cause for this one? FYI the tile in the image below is upsampled from a tile level 0

@Crab-Tang I took a look at the data, and it seems like the binary quantized mesh doesn’t contain the metadata for availability, which makes Cesium Unreal only display the very top level.

To provide you some context, in the past, the availability was embedded in the layer.json, which your asset is currently storing in the available field. However, it doesn’t work well with high resolution terrain dataset which covers a very large area because at the highest LOD, the quadtree can store more than thousand tiles, which may affect system’s memory. So we work around that by placing the availability within the tile binary content. That availability doesn’t cover the whole subtree to the leaf. Rather, we may only specify the availability for every next 5 (or smaller number if you want) level child tiles. For example, in the tile level 0, the availability will be specified up to tiles level 5. Then for every tile level 5, there will be availability up to tiles level 10, and so on.

CesiumJS provides backward combability with the availability in the layer.json, but it will be deprecated soon. Unfortunately, Cesium Native doesn’t provide that functionality. The workaround currently is to move the available field in the layer.json into the quantized mesh’s metadata extension. The format is the same as the available field in the layer.json. In other word, you can embed the below json into the binary quantized mesh:

{
    "available": [
        [
            {
                "endX": 1,
                "endY": 0,
                "startX": 0,
                "startY": 0
            }
        ],
        [
            {
                "endX": 3,
                "endY": 1,
                "startX": 2,
                "startY": 0
            }
        ]
    ]
}

This section from quantized mesh specification has more information about storing metadata into the quantized mesh content.

I also link this cesium-native code that is used to parse the quantized mesh’s metadata in case it helps to adjust your asset

hi ,

I have Send the Second Email , That data contains "available“， and I found that.If I only give the data of level 0, the upsampling on the one level is correct, and the second level is wrong

[baothientran]

I can confirm that this happens even with Cesium CWT if I disable the metadata all together and only use the first levels

[kring]

It could be a symptom of https://github.com/CesiumGS/cesium-native/issues/93. Level zero terrain tiles of course stretch all the way to the North and South poles. Which means that some of the texture coordinates are going to be dodgy. In the most extreme case, texture coordinates at the poles will be undefined, and so interpolating new texture coordinates at tile boundaries from those undefined values will not go well.

Or it could be a totally unrelated bug.

[baothientran]

That's a good point! I definitely see some weird boundary of upsampled tiles, which indicates some problems with texture coordinates

[Crab-Tang]

@kring It may not only be related to texture coordinates, Tile mesh may also have errors；The first figure does not add Bing Maps aerial, and the second one adds Bing Maps aerial

[kring]

When your imagery resolution exceeds your terrain resolution, as is definitely the case here, we create more detailed geometry tiles by subdividing the coarse ones. This involves interpolating vertex positions, and that interpolation is done using texture coordinates. So yes, bad texture coordinates can lead to bad geometry.

[kring]

This is caused by a combination of CesiumGS/cesium-native#292 and CesiumGS/cesium-native#93. Closing as a duplicate.