Does Cesium load more tiles than needed?

CesiumJS
1

Premise: I’m quite noob with Cesium so if I’m way off base or it’s already a known behavior or (more likely) it’s by design please forgive me.

I’ve created a very simple Sandcastle demo for the thread “3d terrain polygonal complexity”, to explore the behavior of Cesium with different values of heightmapTerrainQuality, because it does something not expected (at least by me):

with low values (default is 0.25) Cesium actually loads less terrain tiles (less detail, so it’s OK) but tons more of imagery tiles (with lower values you should stop because it seems an infinite loop).

Deepening further I found the opposite behavior with high values of heightmapTerrainQuality (1 or 2):

you have a lot of terrain tiles to load but the numbers of imagery tiles Cesium needs fall considerably (i.e.: with heightmapTerrainQuality = 1 you have 36 requests / 0.8MB).

I took two screenshots (heightmapTerrainQuality 0.25 and 1) to compare them with Photoshop and they were identical, so I can exclude that Cesium loaded imagery tiles at different resolutions between the two tests.

There is more. I took a look at imagery tiles loaded and I found that a big part of this 36 requests are useless for the area that is rendered (Australia, I love you but you I don’t need you to render a valley of north Italy - thanks).

I tried to understand what Cesium does and it seems that it always loads global tiles and then nearby tiles (less with higher values of heightmapTerrainQuality, more with lower values) so, if you look around, you can already see something with good detail.

WHAT I’D LIKE

  1. two new parameters to specify indipendently the quality of terrain and imagery (so I can have a very low poly terrain but with a full resolution imagery)

  2. that Cesium loads first only the strictly needed tiles (for imagery actually loads first the global ones, for terrain I don’t know because it’s harder to debug) and then, eventually, preloads the nearby tiles (specified by a parameter: 0 -> no preload, 1 -> actual behavior, >1 -> more aggressive preload)

  3. eventually: to specify the “decay” of the geometry / imagery resolution with the distance, so I can sacrifice the quality of the far entities to focus better on the quality of nearby ones.

WHY I’D LIKE IT

I think everybody whould appreciate a lighter, speedier and less data hungry Cesium;

less if you have a dual xeon / dual GPU workstation with a 100 mbit/s data connection,

A LOT if you are on a (maybe old) mobile devices without a wifi connection.

Thank you!

2

Thanks for posting your investigations and suggestions! This is definitely something we’ve been wanting to improve for a while. If you haven’t already stumbled on it, I believe Kevin is making some big strides in this PR to overhaul the terrain and imagery loading systems:

I’d take a gander, and perhaps @ him in that issue with a link to this thread, to see if he’s already considered some of these solutions. I don’t think we’ve considered making separate parameters for imagery/terrain.

3

Thank you Omar;
Kevin kindly replied here with a lot of details.

Thanks again!