Closed turban closed 9 years ago
Yes, height values are scaled to fit into an unsigned short int (https://github.com/geo-data/cesium-terrain-builder/blob/master/src/TerrainTiler.cpp#L48) as per the terrain tile specification. However, by itself this shouldn't produce the effect you are showing. It looks like your data may be oversampled: did you manually specify a maximum zoom level (using --start-zoom
) or did you let ctb-tile
decide? If the former and you specified a zoom level significantly greater than the native DEM resolution then the oversampling may generate the terracing artifacts.
I let ctb-tile decide. See this blog post: http://blog.thematicmapping.org/2014/10/3d-terrains-with-cesium.html
I got the same effect in three.js when I rounded the height valuses to the nearest meter.
I see from the heightmap-1.0 specification that "Each height is the number of 1/5 meter units above -1000 meters." Rounding to the nearest 20 cm should be sufficient at this scale.
So you don't see any blocks or terraces on your maps?
A very interesting blog post, thanks!
I don't see any blocks or terraces in my maps, but I have been mapping around Langstone Harbour, UK, which doesn't quite compare to Norway's rather impressive relief! For comparison I have been using 10cm aerial photography draped over 1m LIDAR data.
I agree that rounding to 20cm should be fine and doesn't account for the terracing that you are seeing. It would be interesting to get the terrain data into a GIS and do some comparisons between various processing steps to see where any error is introduced (if indeed it is, as it could still be a browser side Cesium issue). I would recommend loading the same problem area from three sources for comparison:
ctb-tile
generated terrain tiles from the maximum zoom level. These can be converted to GeoTIFF using the ctb-export
utility.ctb-tile --output-format VRT source-dem.tiff
.Comparing the different data in the GIS will hopefully help narrow down the problem.
@turban Did you make any further progress narrowing down this problem? If not it may be worth trying the latest docker image which includes some bug fixes which might affect your issue. Otherwise I'd be able to look into the problem further if you can provide a minimal dataset which replicates your problem.
I tested the latest docker image, and the problem still appear:
Top image is with terrain tiles from Cesium Terrain Builder (10 m resolution). Bottom image is using the quantized mesh tiles from AGI (30 meters resolution).
I'll try to narrow down the problem.
Sorry to hear it's still a problem. I'm not sure of the scale of the screenshots, but it looks like the terracing might be occurring at the native DEM resolution of 10m? It might be worth trying oversampling and interpolating a test area to a higher resolution (say 0.5m) and running that through ctb-tile
to see if that makes a difference.
I'll try running some tests on data covering mountainous terrain and see if I can replicate the problem.
Hi homme, I have the same problem. I built terrain using the latest docker image and using 1" DEM of Swiss Alps (http://www.viewfinderpanoramas.org/dem3.html#alps), letting cbt-tile
decide on the maximum zoom level.
Is there any way I could help debugging the issue?
I tested upsampling the underlying dataset as follows
gdalwarp -tr 0.0001 0.0001 combined.vrt combined2.vrt -of VRT -overwrite -r cubic
(this should give a precision around 0.4 arc second) and generated the tiles from this new dataset limiting the maxzoom to 14. So far the results look promising and it should be a decent workaround.
@homme would it be possible to add a native support for (cubic) interpolation when building the tiles?
@ppershing many thanks for taking the time to test this. Your workaround sounds good. I'm adding a command line option to ctb-tile
to enable the resampling algorithm to be specified, which will hopefully mean that we won't need your workaround. At the moment the resampling algorithm is 'nearest neighbour'. It was suggested by the GDAL maintainer (Even Rouault) that we use 'average' as he thinks this should work better when resampling to lower resolutions: this will be the new default. If one of the other methods, such as 'cubic', proves to produce better results then I can always change the default.
The resampling options are available in the homme/cesium-terrain-builder:latest
docker image.
I can confirm that the 'average' resampling option has produced good results with no more blocky terrain artefacts.
Great! I can also confirm that my terrain is no longer blocky. Sometimes average is best :-)
@turban Definitely! And I will be paying much more attention to resampling algorithms in the future :)
The terrain rendered with Cesium Terrain Builder gets a bit blocky. See the mountain terraces in the hillside.
Are the height values rounded?