many imagery layers

CesiumJS
1

Hi,

Can you offer any advice on working with larger numbers of tiled imagery layers? I have some tiled weather radar imagery recorded at various times. When you go to a specific time on the timeline in Cesium I want to display a classic loop anim e.g. the last hour at 10 min intervals. Currently I’m doing this by creating 6 layers and cycling the alpha values. Some problems I’m having…

Trying to set up too many imagery layers runs into problems, presumably related to WebGL resources running out. e.g. if I try to load 20 frames instead of 6, or if I want to cycle other layers as well (e.g. satellite IR etc). I assume this will vary between clients as well.

If I do a lot of create/destroy I run into issues. Should I be trying to re-use providers or layers?

When zoomed in on a city and the user selects another time there is a large delay before the imagery is visible again as 6 layers simultaneously work their way down from tile level 0. I think skipping coarser tile loads has been covered in another thread and might be on the roadmap. Is there a way I could preference layers such that I could get one frame to resolve before another starts requesting tiles?

Any other ideas?

Cheers,
Chris

2

Hi Chris,

WebGL only guarantees that 8 texture units will be available to the fragment shader (though most implementations seem to have 16). When the terrain and imagery tiling schemes don’t line up, each layer can be 2-3 textures. So with a lot of layers, you’re likely to run into that limit. It’s on the roadmap to make Cesium work correctly in this situation, by rendering in multiple passes, but it’s not done yet.

The most efficient way to manage lots of layers, and avoid hitting this limit, is to toggle the layers’ show property instead of changing the alpha. Layers that are not shown will not count against the texture limit. On the other hand, layers that are not shown will not be loaded, either (and will be unloaded, in fact), so when you toggle a layer back on it will probably take longer than you’d like for it to appear.

It probably wouldn’t be too difficult to change the behavior of the show property so that non-shown layers are still downloaded but not rendered. Optionally, maybe? And load queue processing code could be easily changed so that non-shown layers are loaded, but their presence is not required for rendering the tile. Does that sound like it would do what you need?

If this sounds like something you might try implementing, I can give you some more detail on how to do it.

Kevin

3

Hi Kevin,

Yes these sound like they could address the issues I’m having. Would either of the following be useful in other situations?

  • optimise the alpha=0 case so it doesn’t use up textures rather than optionally change behavior of show

  • expose a layer load priority (e.g. integer) rather than behind the scenes logic

Either way, I’m happy to have a poke around…

Thanks,
Chris

4

Hey Chris,

I like the idea of optimizing alpha=0. In fact, that may be all you need to do. Try modifying addTileToRenderList in CentralBodySurface.js to not count (don’t increment readyTextureCount) textures with an alpha of zero, and modify createRenderCommandsForSelectedTiles to skip (don’t increment numberOfDayTextures) textures with an alpha of zero.

If you try adding a layer priority, let me know how it goes. I think you’ll probably need to do multiple passes over the tiles in the load queue in order for that to work optimally.

Kevin