I am trying to render a large amount of line segments (polylines) on the cesium map and the performance is very poor. At 25k line segments I’m at best getting 3fps. Looking at the render source the culprit seems to be this loop (in polylineCollection.js) :
for (var s = 0; s < polylineLength; ++s) {
}
This is called every single frame and loops through every single polyline, extracting it’s material information to create a new webgl draw class for each material (which makes sense). What I don’t get is why this needs to be done every single frame if the polylines have not changed materials or relative earth positions. Such an update should only occur upon a change to the polyline collection, and previous draw commands/vertex buffers should be able to be re-used each frame.
Am I missing something? By removing this continuous update I go from 3fps to 60 fps (with a few weird graphical artifacts like overlays behind the globe getting rendered in front of the globe). Why can’t the polylines be rendered as normal with z-buffering to hide the overlays in back?
I’m very new to webGL and computer graphics in general, so any help would be greatly appreciated.
I went ahead and did some optimization testing on my own. I noticed that this call:
createCommandLists(colorList, boundingVolume, modelMatrix, this._vertexArrays, this._rs, true);
always returned the same colorList as long as the materials didn’t change (IE it was irrespective of camera, zoom,spin,ect). By storing the returned colorList and re-using it instead of doing the massive calculation each frame, I went from 3fps to v synced 60fps. Testing with 4x as many segments(100k vs 25k) still yields 60fps.
You are welcome to just continue with your changes, but we introduced a new lower-level interface for graphics objects that allows you to get better performance based on your use-case. The abstraction of the PolylineCollection makes it too hard for us to optimize for all cases; it is just OK for most cases.
In particular, if you have a lot of static polylines that only each need a different color, you can checkout the SimplePolylineGeometry in b19. See the draft tutorial and Sandcastle example. On Windows, only a line width of one will work.
We are now working on moving more of the PolylineCollection functionality to this new system. We’re starting with materials and wide lines, and will eventually do dynamic buffers for efficient partial updates.
What's the current recommended way to draw a large Polyline (with glow material), which updates often (adding / showing elements at the end of the line)?
I know this is an old thread, but across the forum / github / SO I still see quite some people with related issues. Is good performance for this use-case still dependent on https://github.com/AnalyticalGraphicsInc/cesium/issues/932?
I'm looking for the best way in terms of performance to add points to a path / polyline. The use-case is indeed similar to the example you sent. The coordinates are known beforehand, so a solution could also be to hide the line initially, and change points to "visible" on-the-fly.
I've experimented with several ways, but so-far all of them are quite CPU-intensive.
2. When directly updating a Polyline (not a path), so similar to Randie's solution in this thread, many cycles are spent in PolylineCollection.update -> createCommandLists - similar to what Randie describes.
Most of these threads are quite old, and the solutions proposed look more like "workarounds"; bringing the performance to a reasonable, but far from optimal level. Therefor, I'm wondering what the current recommended way is, or whether there's something we can contribute (without having deep knowledge of the Cesium engine).