Image tile refresh problem

When operating mouse by double click or zooming in to make viewpoint quickly fly from a high position (eg. pyramid level = 1) to a low position (eg. pyramid level = 15), the tiles on each level of pyramid spanned by the track will be called and draw. When the viewpoint has arrived at the endpoint for a while, the tiles are still refreshing and the high resolution tiles cannot be drew quickly, which make operators feel the refreshing is not very smooth.
I find cesium calculates the current tile id by quartering its father node, instead of calculating it by the level of endpoint and the range of the window. So all the tiles along the track will be calculated and refreshed, which delays the appearance of last tiles who has the highest resolution in the track.
I am wondering whether my guess is right. If it is, why cesium choose such a method to schedule tiles. Does anyone knows the way to refresh the tiles on the level of endpoint directly (like google earth’s or skyline’s way), without schedule and draw the tiles in the middle.


I face the same problem. Does anyone find a good solution (show the tiles on the level of endpoint directly) ?

GHT於 2015年7月27日星期一 UTC+8下午12時54分41秒寫道:

Same problem here. I compared with others Cesium versions loaded in a webview (Iframe) and it seems that the tile loading is a lot higher since the 1.17 (the 3D tiling i guess ?).

Here are the numbers (only the Cesium version changed) :
- 1.14 => 20 secs
- 1.15 => 32 secs
- 1.16 => 30 secs
- 1.17 => 1 min 15 secs
- 1.18 => 3 min 20 secs

Kevin, it’s on our long term roadmap to overhaul the tile selection system to avoid the top-down drilling that currently happens; but there’s no ETA on when that will get done.

Raphael, we haven’t seen anything like that on our end. Does it happen in a desktop application as well? Can you provide a sample so we can reproduce the issue? Things should have gotten better, not worse, since 1.14.