A few days ago we merged what is perhaps the most significant update to terrain and imagery streaming in Cesium since support was added way back in February of 2013 (version b14 for the curious).
Conservative estimates show terrain and imagery loads at least 1.4x to 2.3x times faster, requests 40% less tiles, and uses ~33% less bandwidth. Not only are apps faster, but this puts less strain on your servers as well. The best part is that these improvements are completely transparent to your applications, all you have to do is upgrade Cesium.
Since this is a significant refactor in a complex area of the code, we are asking you, our awesome community, to help test things out ahead of time to ensure everything is rock solid for the release. There are several ways you can try out a pre-release build depending on how you prefer to get Cesium:
I have deployed the preview to test it with my developments and my own imagery and terrain.
I didn’t make some comparison with the 1.54, but perhaps there are also some benefits on the memory footprint due to the reduced number of requests.
On the fly terrain sampling done on my side seems now more responsive.
I have seen some artefacts at terrain loading that I didn’t have before but it disappears after the streaming is completed (I didn’t succeed to do a screen capture). But as it is transient and random, it doesn’t matter from my point of view.
Thanks for reporting your experience Pascal! Glad to hear you’re seeing improvement.
Do the artifacts tend to be around the edges of the screen? I think that might be due to this change “filling in” terrain tiles on the fly temporarily until they finish loading.
By using a low bandwidth network (3G), I got a screenshot. The triangles seems sharing same point at early stages of streaming when details are low and decimation high, but after completion it is ok.
I don’t have in mind that I got such things before (i will next week switch back to 1.54 to check it)
But it is transient and the result at the end is ok.
Yep, that’s a fill tile. Cesium is rendering that totally fake geometry because that area just became visible and it doesn’t have anything better to render there, because the real data hasn’t loaded yet.
Thanks for the comment, I didn’t have in mind this can lead to such transient rendering where some triangles from the fake mesh seem sharing a same point (or close points) on one of the edge.
Map/terrain performance seems slower for us on 1.55. I don’t know if it’s because of our suboptimal corporate network or what. Terrain tile requests seem to come in slower on our browsers’ network tabs. Is there any area of code we could focus on to debug 1.54 vs 1.55?
One is that because the new engine loads fewer intermediate tiles, it can sometimes appear to load slower because there is less action along the way. The detail is more likely to appear all at once after a delay rather than refine through each level. Have you measured the load time to confirm that it’s really slower, rather than just feels slower? In any case, feeling slower is still a step backwards, so you can try tweaking the loadingDescendantLimit property on Globe (make it smaller, at 0 Cesium will refine through the levels one-by-one):
The other difference is that Cesium will no longer upsample tiles (that is, use a lower resolution tile where a higher resolution tile is desirable) that are known to be available from the server. Previously Cesium would aggressively upsample - which is CPU intensive but not network dependent - in order to provide some geometry to hang the imagery on. The tradeoff in the new engine is a very positive one unless your terrain source is much slower than your imagery source, in which case it will probably make things slower overall.
Finally, if you’re using a custom terrain source, is it providing tile availability in the layer.json file? If not, Cesium will refine through the levels one-by-one unnecessarily.
Kevin thanks for your reply! I tried out the globe.loadingDescendantLimit and I saw its effects and I think it can help but I don’t think it totally fixes the issue.
Attached is a link to an animated image showing what I see on my home/open network. This is just panning around the DrawingOnTerrain public Sandcastle. I move my mouse in circles around areas which don’t seem “fully loaded”. On the corporate network I see the same issue but it’s much more explicit. Larger areas of low detail…sometimes they areas load eventually and sometimes they don’t. If I keep panning a bit here or there, eventually it will load but it’s not as consistent as 1.54 and prior. I still have issues even with globe.loadingDescendantLimit=0.
And here is a static image that shows the issue fairly well where it is done loading. We generally use public Bing Maps Aerial with Labels and Cesium Ion terrain. Sometimes the Bing labels make the issue appear more explicit.
Sorry, but your video and image look totally normal to me, I don’t think 1.54 would have behaved any differently. At some distances from the globe, it’s common for the center of the screen to be rendered at a higher level of detail than the edges because the center is closer to the camera. If you zoom in a little bit, you should see the edges refine as well. Am I missing something?
Kevin I believe you are right about the images I posted. I was trying to rush out some info and thought I could reproduce some of it in Sandcastle. Sorry for confusing the issue.
My issue is probably a speed/loading issue caused by our corporate network like you had mentioned or an issue with our custom app. I will try to post better info when I get a chance.
Here is a video of our actual issue. This is running Cesium 1.56 with no customizations to Cesium. Cesium 1.53 will load this area of maps in ~5seconds while Cesium 1.56 takes over a minute sometimes. This may be something on our end but historically we have run from Cesium b04 to Cesium 1.53 with no instances of this slowdown.
I upgraded to Cesium 1.57 and without terrain the maps load fast. However with Cesium Ion terrain coupled with Bing I still get the tile rendering slowness.
As a possibly related issue, I get this error a lot when panning around such that it interrupts my navigation quite often. Not sure if the slowness issue and this may be related somehow?
TypeError: Cannot read property ‘center’ of undefined
at addDrawCommandsForTile (Cesium.js:217494)
at GlobeSurfaceTileProvider.endUpdate (Cesium.js:216351)
