Too many tiles requested by imagery layer leads to poor performance

[ezze]

Hi, guys!

Some time ago we decided to replace NASA World Wind working as Java Applet in browser by Cesium in order to display multiple imagery layers (I mentioned it in #2047). Our application allows a user to specify filter parameters (such as time range, geographic region, satellites, sensors and type of products of interest) and display found raster data (set of segments grouped by orbits) on the globe. I overlay each orbit of processed data as a separate imagery layer. To demonstrate it here is a screenshot of the application:

Initially plain WMS was used to send imagery tiles but in order to increase performance we are switched to WMTS. Unfortunately, it helped a little. I started to look at source code and found that some work to choose tiles for rendering is done here. It's very difficult to understand what's going on there at a glance but I stated that many tiles starting from zero level of detail up to current level of detail are analyzed and prepared for requesting/rendering constantly in short time interval. Probably, something is wrong with detection of which tiles on lower-detail levels should be used 'cause, for example, when I enable imagery layer on 7th level of detail I see a lot of tile requests (at least 250-300), and most of them are empty (they are outside of current viewport):

If I enable all imagery layers per page (no more than 20) and zoom in I end up with browser hanging...I guess, that all these things happen in main JavaScript thread, and there are too many tiles! This fact seriously limits Cesium application in our case that's why I open the issue.

I look at terrain and imagery roadmap, but didn't find anything related to this there.

What can we do? Any ideas? Do you plan, guys, some improvements on this? Is it possible to use some another algorithm to filter tiles (is it called culling?), probably, to skip some levels of detail (even all excepting the current one) or improve existing algorithms by limiting to only really visible tiles (which are in viewport and are not covered by tiles of other imagery layers).

I'm also ready to try to do something but don't know where to start. Is there any tutorial describing in details how imagery layers are loaded?

[pjcozzi]

@ezze you may want to post on the forum if you haven't already to get some ideas from the community.

What version of Cesium are you using? We improved culling last summer. Have you also tried fog?

For the Cesium roadmap, 3D Tiles will eventually help in this area since they know about child bounding volumes and can cull more efficiently. The ability to not request layers that are completely under other layers will also help.

[jbo023]

Ho,

we also observed this problem. I think the problem ist that cesium loads the whole image tree, starting with the 0/0 tile. Maybe it would be possible to restructure the selection algorithm to not load the whole tree, but only the tiles which are visible at the current view ?

[ezze]

@pjcozzi, I use recent Cesium 1.20 and update it with each new release. So all these improvements that you have mentioned doesn't help (I guess that fog is enabled by default).

I didn't try 3D Tiles due to, as far as I know, it's in development yet and will be applied to 3D models first, is it right?

As with terrain, since Cesium already streams imagery well, we are not focused on this in the short-term.

Unfortunatelly, this is fine right now when you use single imagery layer only.

[jsalankey]

The team I work on is having problems with the same issue. The tile requests appear to be getting tiles at every zoom level between the maximum and current in addition to a great many tiles that are nowhere near the view. With several layers, this can amount to thousands of requests that choke up even the best browsers to get 95% images that aren't even used.

This is a severe problem for our use cases in WMS.

[jfinnessy]

As a back-end service provider of WMS, this causes significant issues in responding to requests for Cesium-based clients. The browser has it's own set of challenges, but if the backend has to respond to 500 different requests, and only a fraction get used, it's putting a completely unnecessary load on the services side of things.

Loading the pyramid is great for caching tiles as you zoom up and down that pyramid, but if your WMS tiles change based upon date, you just requested a ton of stuff that will never be used.

[ezze]

Any news or plans on this, guys?

[jsalankey]

I'm gonna second that. It continues to be a problem for us and is very noticeable for users of our tool.

[pjcozzi]

There are a few branches with terrain improvements by @kring:

• Requests: 3d-tiles...terrain2
• Reprojection: https://github.com/AnalyticalGraphicsInc/cesium/compare/terrain3

The precise timeline is TBA.

[eborovenskiy]

This issue also heavy affects us!

[jsalankey]

Bit of an update, I'm not sure which work/commits did it, but this is significantly better in version 1.30. I've seen up to 80% reductions in number of tiles loaded compared to 1.21 (which we were on before).

[NaderCHASER]

I continue to see too many tile requests being made at multiple levels outside of the current view. As a time-based overlay provider, unnecessarily loading the entire rectangle extents is a hindrance when the next "frame" in an animation attempts to load and gets queued behind the tiles from the previous frame that weren't even in the view extent.

[zbennett10]

I'm in the same boat, - is anything being done about this?

[mramato]

As @jsalankey the static use case has improved a lot since this issue was written. There will be further improvements when 3d-tiles comes into master this month, thanks to tile prioritization, throttling, and cancellation.

@NaderCHASER we are adding direct support for time-dynamic imagery tiles in the next release or two, so that should help your use case tremendously.

Even with the above improvements (which will help a lot), the major feature left to do would be level of details (LOD) skipping for terrain and imagery (or having terrain and imagery re-implemented in terms of 3D Tiles which would have the same effect). That is on our long term roadmap, but we don't have a concrete timeframe for it.

[NaderCHASER]

@mramato The request scheduler over H2 has improved tile loading performance for my use case.

However, as you mentioned, I'm really looking forward to the time-dynamic imagery. I noticed it was being implemented for WMTS, but I imagine the underlying code (Imagery / ImageryProvider) could be adapted to integrate into UrlTemplateImageryProvider? My main concern is not having tiles load for imagery that's not currently visible (alpha = 0).

Is the wmts-t branch the branch I should be testing if I were to help contribute? Also, is there an issue for this?

Thanks as always.

[kring]

Re: "My main concern is not having tiles load for imagery that's not currently visible (alpha = 0)." That's actually a feature, allowing you to preload layers that aren't visible yet but will be soon. If you don't want it loading, set show=false too. Kevin On Jun 16, 2017 4:08 AM, "Ryan Hickman" <[email protected]> wrote: @mramato <https://github.com/mramato> The request scheduler over H2 has improved tile loading performance for my use case. However, as you mentioned, I'm really looking forward to the time-dynamic imagery. I noticed it was being implemented for WMTS, but I imagine the underlying code (Imagery / ImageryProvider) could be adapted to integrate into UrlTemplateImageryProvider? My main concern is not having tiles load for imagery that's not currently visible (alpha = 0). Is the wmts-t branch the branch I should be testing if I were to help contribute? Also, is there an issue for this? Thanks as always. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3857 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA4a1pKCnc8yB4PclmQTLyUuZpbPwb3kks5sEXMPgaJpZM4IIoAk> .

[NaderCHASER]

I have 80 layers (time series for a single meteorological dataset) that are hidden. There is no way of knowing which layers are "layers that aren't visible yet but will be soon." The point here is to be able to animate meteorological datasets that span multiple days. When animating, I don't need "out of view" tiles loaded and I really don't need a zoom/pan leading to 80 layers fetching new tiles.

In my opinion, there should be a middle-ground option here that doesn't destroy the GPU resources used by the layer, like when show is set to false does, but ensures that the layer doesn't get thrown into the request queue due to map movements (zoom, pan).

I'd be glad to provide you with a URL to my Cesium application if it would help explain this better.

[ghost]

Hi everyone!
Could you find a solution to this problem?
In my application, you select a geographic starting point, like a city, and fly to it with a high zoom level, like 13.
I'm using Cesium v1.49, and still see every tile being loaded, from zoom level 0 to zoom level 13.
Thanks!

[mramato]

@juanfkt93 this is actually a non-trivial problem to solve. The good news is that it is being actively worked on and we expect the solution to be in Cesium within the next few months (though we don't have an exact timeframe yet).

Work is being done in the https://github.com/AnalyticalGraphicsInc/cesium/tree/fill-tiles branch but I don't think that branch is ready to be played with yet. We'll update this issue when a PR is open if you want to try it out.

[OmarShehata]

For anyone following, this is the PR mentioned in the comment above:

#7061

[ezze]

Any progress on this, guys?