Glad to hear you were able to getting it working before.
Let me address each of your bullets:
1. WMS performance. I have loaded our standard WMS layers into Cesium and, although it works, the view takes quite a long time to load (30 seconds or so). My initial debugging points toward two potential performance issues: a) Cesium seems to load a lot more tiles than is necessary for the current view port. b) Tiles are not cached.
One thing that jumps out at me is how you’re setting up the WebMapServiceImageryProvider. You’re forcing it to load 512x512 images, while Cesium expects the images to be only 256x256. Since Cesium selects the LOD based on the smaller image size, it’s going to load a lot more images than it needs. The 256x256 expectation is built into the WMS provider here:
This should be an easy change.
Another reason Cesium may be loading more tiles than we’d like is because it currently determines which tiles are in view by computing a simple bounding sphere to wrap each tile, and determining which spheres are in view. There’s quite a bit of error in this, so I suspect we could reduce the number of tiles by ~20% (made up number, but probably in the ball park) by using tighter-fitting bounding volumes, at the cost of a bit more time to compute which tiles are visible. We’d welcome pull requests from anyone that experiments with this and gets good results.
This is just speculation, but one thing to check… The World Wind WMS server might be optimized for a particular pattern of requests, or may have certain classes of requests cached. If Cesium isn’t generating the same pattern, the server may simply be taking a long time to serve images. If you confirm that this is the case, and can determine what pattern is cached, it’s probably possible to make Cesium use the same pattern.
Regarding caching… there actually is caching, in two places. One is that the browser automatically caches downloaded images. The other is that Cesium itself caches loaded tiles in memory. The problem with this second cache is that it’s small - 100 tiles or the number of tiles rendered last frame, whichever is greater. The number is easily changed, so it might be worth experimenting with:
Unfortunately WebGL doesn’t give us any way (to my knowledge) to determine the amount of GPU or system memory available, which makes it hard to pick a good cache size. 100 is definitely conservative.
2. No support for editing polygons.
I know of several groups that have implemented this feature on top of Cesium. For example, check out Raytheon’s Vega: http://cesiumjs.org/demos/vega.html
Unfortunately none have been so kind as to contribute it back to core Cesium yet. I suspect it’s not terribly difficult to do, though.
3. Periodically memory/CPU usage goes through the roof.
Can you tell me more about when you see this? The memory usage could be this:
Regarding CPU usage, Cesium currently tries to render as fast as it can, only limited by the browser’s maximum requestAnimationFrame rate and possibly by vsync. Partially this is because Cesium is tuned for dynamic data visualization, where it’s reasonable to assume something is changing every frame, but also in part just because we haven’t gotten around to doing anything better, yet.
4. To support some of our views and animations, WMS tiles need to be pre-cached.