Quantcast

Holes in elevation model caused by returning nullptr from createHeightField

classic Classic list List threaded Threaded
1 message Options
Pierre Hallot Pierre Hallot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Holes in elevation model caused by returning nullptr from createHeightField

This post was updated on .
Hi,

We have class inheriting from osgEarth::TileSource, that re-implements createHeightField so that we can load our own elevation data.
Sometimes, for some reasons (like internet disconnection), the load fails and we thus have no elevation data for a given tilekey. We then return a nullptr in the overridden "createHeightField".

This results in nice square holes for the tiles where we could not load the elevation data, which is a bit of an issue, we'd rather do some interpolation with the neighbouring tiles and reload them when possible.

From what I've seen, by default, osgearth is supposed to do interpolation for an elevation layer. We do not overwrite this setting as far as I can see.
However, given the observed result, either we should not return nullptr in this case, or the interpolation is inside the tile, and not across the elevation layer. Any idea on how to process to interpolate those holes away?

I've also played with the "osgEarth::ProgressCallback" "setNeedsRetry(true)", which seems to improve the situation for instance when switching from ethernet to wifi (usually this results in holes).
I have a couple questions:
- how does this retry work: is it a one time shot sometimes later (when?), or continuously until we have some valid data?
- do I need to set it back to false when we have a valid tile again?

Lastly, it seems we load the same tile several times. I am not sure if this there is something wrong on our side, or this is how it is supposed to happen.
Is it an issue if we return nullptr after having loaded a valid tile once, will this override the previous data with a hole?
A sample of the debug output from createHeightField showing this behaviour.
Heightmap valid: X:  30 , Y:  48 , LOD:  7
Heightmap valid: X:  30 , Y:  48 , LOD:  7
Heightmap not valid: X:  30 , Y:  48 , LOD:  7
Heightmap not valid: X:  30 , Y:  49 , LOD:  7
Heightmap not valid: X:  30 , Y:  49 , LOD:  7
Heightmap not valid: X:  30 , Y:  49 , LOD:  7
Heightmap valid: X:  30 , Y:  49 , LOD:  7

Thanks a lot.
Loading...