Map crashes when loading a large number of WMS layers

CesiumJS
1

I'm not sure if this is a Chrome/WebGL problem or a Cesium problem, but I've noticed an issue when trying to load a large number (approximately 10) of WMS layers on the globe. I'm using the following code to load the layers (nothing fancy):

widget.centralBody.getImageryLayers().addImageryProvider(new Cesium.WebMapServiceImageryProvider({
  url: wmsUrl,
  layers: wmsDataName,
  parameters: {
    transparent: 'true',
    format: 'image/png',
    version: '1.1.1'
  }
}));

The two errors I get (both in Cesium.js) are: "Warning: D3D shader compilation failed with prefer flow control flags." and "Uncaught TypeError: Cannot call method 'raiseEvent' of undefined"

2

Hi,

WebGL only guarantees that a single draw call can use up to 8 textures, though some hardware supports 16 or more. With lots of overlapping layers, a single terrain tile can end up needing more textures than are supported, and shader compilation will fail, as you’re seeing.

In theory we can work around this by rendering in multiple passes, but this comes at a significant performance cost, and we haven’t implemented it yet. A much better solution is to do the compositing on the server side. Can you set up a single WMS layer which is a mosaic of all 10 of your other layers?

Another thing to check is that your WMS layers have as limited an extent as possible. So if your layer only covers a small part of the globe, make sure it doesn’t advertise that it covers the entire globe and then return transparent pixels for the part that’s not really covered, because Cesium will be forced to render all those transparently pixels.

Kevin

3

Kevin,

Thanks for following up. Unfortunately, one of the features of our application is for users to be able to selectively turn layers on and off and do comparisons so compositing the layers wouldn't allow for this. I will check to make sure that our layers aren't causing the transparency case you mentioned, but the layers do have lots of overlap so it may just be that what we are trying to do won't be possible.

4

If it helps, only layers that are shown and that have a non-zero alpha count against the limit, so if you have a bunch added but only a few active at a time you may be ok.

Otherwise, it sounds like you need the multi-pass rendering, even if it reduces performance. I don’t think I’ll personally be able to get to it soon, but I’d be happy to guide someone else in implementing it.

Kevin

5

I've talked with my team some and I think we might try to do some layer composition at the zoomed out levels (where we have a larger number of layers on the map) and see if that helps. I think we'd definitely be interested in at least seeing what the multi-pass rendering could do, but we understand that it might be a while before you guys can get to it. Thanks.

6

Would it help if you could disable layers entirely at low zoom levels? So when you’re zoomed out looking at the whole globe, a tiny area that might just be a few pixels anyway wouldn’t show up at all?

Kevin

7

We don't really have any layers that are that small even when looking at the entire globe. Our layers correspond to time stamped events (in our particular test case we're using hurricane patterns) and we allow users to drag a time slider to determine what timeframe of events (layers) to show. So the layers are roughly the same size and have some considerable overlap.