How to improve tile/terrain download speed

CesiumJS
1

Hello everybody,

using the latest cesium build I have noticed slow terrain tiles download performances and I hope someone can help me.
For some reasons it seems that cesium is first downloading imageries and only after that the elevation data. Is there a way to give priority to the terrain tiles download?
My current setup has the following set of layers:

  • A custom terrain of (19 levels) handled by a CesiumTerrainProvider
  • A first layer based on BingMapImageryProvider
  • A second layer based on WebMapServiceImageryProvider
  • A third layer based on WebMapServiceImageryProvider which I am using as a mask to highlight a specific area

When I am flying (flyTo fuction) to a specific mountain on the terrain, Cesium creates a huge number of requests on the download queue, which is fine, but they are mainly imagery requests resulting in a flat terrain for several seconds (and really bad user experience) until almost all the imagery data has been downloaded. Only after that the elevations are updated. Things are getting worse if I apply a camera movement following a path around a mountain. Imagery requests never stop and the terrain elevation is never updated unless I stop the animation. I have gone through several parts of the source code trying to understand the cesium behaviour and trying to adjust parameters like:

throttleRequestByServer.maximumRequestsPerServer
globe.tileCacheSize
globe.maximumScreenSpaceError

without success. I only mitigated the requests amount during the continuous camera animation by increasing the tileCacheSize, but the terrain issue is still there. I can exclude bandwith issues as I am on a 100Mbit connection and servers are on Google cloud. From what I can understand network requests are handled by throttleRequestByServer promise which has a maximum of 6 parallel connections which are correcly executed by looking at the Google Chrome network inspector. What I would expect is to have the same number of parallel requests for each provider or at least an equal distribution of them among the avavilable slots. So here are my (more detailed) questions:

  • Is there a way to tell cesium to give priority to download and visualization of elevation data?
  • Is the current cesium implementation still requiring the download of all the tiles from the root to the LOD corresponding to the camera position on the map? or is cesium downloading only the visible tiles?
  • Do you think that moving the terrain data on a third level domain would increase the amount of parallel requests?
  • Do you recommend any DiscardPolicy to implement?
  • I was considering the option to use the HTTP2 protocol. Do you think that this will increase the amount of multiple downloads? In this case should I set maximumRequestsPerServer = 1 since the multiplexing is part of the protocol?

Any suggestion is more than welcome, thanks!

2

Hi maglio,

are you sure this is a bandwidth/request throttling issue?

what may also be happening here is that the quantized meshes take
significantly longer to decode/process than the imagery; this will
result in the imagery tile detail "overtaking" the geometry, and in
order to render the imagery at full resolution, cesium will resort to
upsampling the geometry, often from very coarse levels of detail,
resulting in the flat terrain you see.

Two things which might help alleviate the symptoms, (but which would
require some modifications in the rendering core):

  - Only permit upsampling of geometry tiles below (or near)
    the leafs of the terrain quadtree - this will keep the
    geometry and imagery SSE from diverging too much, and limit
    the work "wasted" on upsampling/traversal - see
    GlobeSurfaceTile.js, specifically prepareNewTile, where you
    can control whether upsampledTerrain is constructed

  - Priorize tile requests by screen space error (currently, they
    are requested in breadth-first fashion), to make better use
    of your limited "geometry decoding" budget. This would
    require modifying QuadtreePrimitive.js (e.g. by
    sorting the request queue according to SSE)

Manuel