Hey folks, I just wanted to give an update on the implementation of streaming terrain rendering in Cesium.
Scott Hunter and I have combined his imagery layers effort and my streaming terrain effort into one effort, since there’s so much overlap between the two, and we’re making great progress on both. Take a look at the attached screen shot, which was generated today using the version of Cesium in the ‘imagery_layers’ branch. Not too bad, right? The imagery and terrain in the screen shot are both from ESRI and streamed from their public servers.
Ok, so I carefully took that screen shot so as to hide many of the remaining rendering problems. but still it’s coming along nicely.
With some of the foundations in place, we’re quickly getting to the point where we’d love to see more folks get involved in the development. In particular, I’d love to see someone implement a “TerrainProvider” to stream terrain from a WMS server like GeoServer instead of from ESRI. Any takers? With any luck, it shouldn’t be too difficult.
Here are some (but probably not all) of the problems and things remaining to be done:
The ESRI terrain is not georeferenced quite right. The tiling scheme is based on a web mercator projection, but heights within each tile are incorrectly mapped to vertices using a geographic projection.
The system is architected to allow imagery to be tiled differently from terrain, and for different imagery sources to use different tiling schemes. However, the code to support that is not done yet, so things will currently go very badly if terrain and imagery tiles are not aligned.
Tile culling is overzealous in some cases (see the black spot in the lower-right of the screen shot) and not aggressive enough in other cases (too many tiles over the horizon).
The frame rate is not what it should be. I suspect it’s a combination of less than ideal culling (see above), rendering more terrain detail than needed (the tile selection algorithm needs tweaking), and an inefficient fragment shader.
Cracks between different levels of detail are visible in some cases. We’re still using the screen space, gaussian-blur-based crack filling technique that was used pre-terrain, but sometimes the cracks are too big. We may be able to use the same technique with a bigger kernel, or we may end up dropping skirts from the tiles.
We’re using a LOT of GPU memory. There are probably multiple factors here.
The ESRI elevation data is accessed using a token that expires every day. I’ve been refreshing it daily, but we need a better solution.
Let me know if you try it out in the imagery_layers branch, and if you’d like to get involved.