Open rsignell-usgs opened 8 years ago
@stevage did some work on this when we met in Middleton last week.
We believe he did the work in this branch: https://github.com/TerriaJS/terriajs/tree/cesium-lighting and we experimented with this Terrain configuration in Buzzards Bay: https://github.com/TerriaJS/terriajs/blob/cesium-lighting/wwwroot/test/init/terrain.json#L37-L47
We can't figure out where @stevage deployed an instance of this branch, however.
I thought it was perhaps http://nationalmap.research.nicta.com.au/ but when I tried to load the sample terrain config thusly:
I got back the following error, suggesting this endpoint does not have this branch deployed:
Aha! Found it, thanks to the superior memory of @jiwalker-usgs who remembered that it was a bit.ly link: http://bit.ly/buzzbay
So looking at the view of woods hole with white image on top, it reminded me that currently the only lighting source we know how to specify is the Sun.
And therefore if we want nice shadows on the topography we need to specify just after sunrise or before sunset.
And therefore we should add some CZML with time near sunrise or sunset specified so that we get the desired sun angle.
Here's what it looks like near the middle of the day. You can't see any topography:
If we enable some layer with temporal resolution (e.g. Auto incidents) and move the time on the time slider to the afternoon, it looks like this:
So now we can see something, but it seems that we are not seeing the right resolution for this zoom level. The terrain should be much better resolved at this point. Here's a shaded relief view of the Woods Hole 0.5 m bathmetry data from the USGS report:
@kring ?
@rsignell-usgs, @jiwalker-usgs, and I talked about this by video chat the other day. Basically, the built-in per-vertex terrain shading isn't great for actually showing the nuance of the terrain. The best solution is to create imagery to overlay on the terrain. That can either by a static relief shading texture (i.e. high resolution greyscale image cut into a pyramid of tiles), or it can be a normal / bump map (an "image" where each pixel is a surface normal vector), again cut into a pyramid of tiles. The former is fairly easy to do out of the box; GDAL can generate such an image. The latter will take a bit of work in Cesium, but it's something I've prototyped before and it's not too crazy.
@kring, I think in addition to the per-vertex terrain shading issue, there is another issue -- far too few vertices are actually there at this zoom level. The displayed terrain doesn't even begin to resemble the actual terrain that should be seen from this view. For example, the sand waves are non-existent!
@rsignell-usgs well I can't promise there's no bug, but what you're describing sounds ok to me. If height of the sand waves is smaller than the allowed geometric error at that terrain level, it is correct that they not be rendered at all. They should still be visible in the shading, though, which is why we need a normal map that is separate from the terrain geometry.
We've got some bathymetry served up in TerrainProvider here: http://stkdesktop.agi.com/stk-terrain/Tileset.html?name=USGS_Bathymetric_Mass_Coast but if you open that using the
View on Globe
button, it's hard to see anything because Bing overlay on bathymetry obscures the terrain lighting. Here for example, is the bathymetry in Woods Hole: