Blocky terrain #4

Closed
turban opened this Issue Oct 12, 2014 · 13 comments

Projects

None yet

3 participants

@turban
turban commented Oct 12, 2014

The terrain rendered with Cesium Terrain Builder gets a bit blocky. See the mountain terraces in the hillside.

screen shot 2014-10-12 at 12 36 51

Are the height values rounded?

@homme
Member
homme commented Oct 13, 2014

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.

@turban
turban commented Oct 13, 2014

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?

@homme
Member
homme commented Oct 14, 2014

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:

  • The source DEM at its native resolution
  • The ctb-tile generated terrain tiles from the maximum zoom level. These can be converted to GeoTIFF using the ctb-export utility.
  • Try creating GeoTIFF (or GDAL VRT) files directly from your source DEM. This will check whether the GDAL resampling is introducing any errors. This can be done using a command along the lines of ctb-tile --output-format VRT source-dem.tiff.

Comparing the different data in the GIS will hopefully help narrow down the problem.

@homme
Member
homme commented Nov 24, 2014

@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.

@turban
turban commented Nov 25, 2014

I tested the latest docker image, and the problem still appear:

heightmap
quantized-mesh

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.

@homme
Member
homme commented Nov 26, 2014

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.

@ppershing

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.

image

Is there any way I could help debugging the issue?

@ppershing

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?

@homme
Member
homme commented Apr 15, 2015

@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.

@homme homme added a commit that referenced this issue Apr 15, 2015
@homme homme Enable GDAL resampling options to be passed to `ctb-tile`
The `--resampling-method` flag enables this.  It should be useful in addressing
the blocky/stepped terrain artefacts described in issue #4.
7a081d3
@homme
Member
homme commented Apr 15, 2015

The resampling options are available in the homme/cesium-terrain-builder:latest docker image.

@homme
Member
homme commented May 29, 2015

I can confirm that the 'average' resampling option has produced good results with no more blocky terrain artefacts.

@homme homme closed this May 29, 2015
@turban
turban commented May 29, 2015

screen shot 2015-05-29 at 23 30 04

Great! I can also confirm that my terrain is no longer blocky. Sometimes average is best :-)

@homme
Member
homme commented Jun 1, 2015

@turban Definitely! And I will be paying much more attention to resampling algorithms in the future :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment