Polyline caching for better performance?

I am rendering many entity paths over time, partly represented as geodisic polylines, and further down rendered as paths. These are being constructed through czml so eventually piping through the entity api I believe. The polylines are retained or accumulated (like a density plot over time), with about 3000 translucent lines of varying length over the continental USA. The dynamic polylines are defined via references to start and stop entity positions where stop entities are interpolating through a couple of points defining the path or the end-point of the line.

Using availability information, I implemented a set of complementary lines that become available when the dynamic polylines are realized, so there is essentially a set of static and dynamic geometry with the hope that the static polylines replacing the dynamic ones speed up performance. They do, to a point. I figure there must be some way to leverage primitive caching of lines, perhaps using primitives (I have just started researching this).

I can’t really prune anything, but can possibly do some LOD or even try to rasterize the existing lines somehow and render them as a replacement texture/imagery layer.

I can precompute the necessary geometry and splice in entities created outside of czml as necessary, if it means speeding up rendering. Has anyone else done this kind of thing? Trying to be more mechanically sympathetic to the GPU, or at least leverage cesium’s performant paths better.

1 Like

Would it be possible to reproduce something similar to what you’re doing in Sandcastle? Obviously you may not be able to provide all your real data, but if you can boil it down to reproduce your performance problems it could help find a solution.

1 Like

@James_B brings up a good suggestion. @joinr this information would also be helpful on my end.


I probably can. I am actually doing this all from ClojureScript primarily calling cesium via javascript interop, but I started off going the CZML route and generating it at runtime from some input (the learning path I happened to fall on from the existing demos). I should be able to just emit the CZML and hang it somewhere and refer to it from sandcastle, although I’m doing stuff with multiple views that requires a little syncing (I think that’s feasible though; just means I have to revert to JS, hopefully it’s minimal).

FWIW I did end up mocking up some caching using PolylineCollection(s) of the static geometry, sort of an offline cache derived from the entity collections. I replace all the of “static” line instances (instances that show up after a movement is completed, part of the accumulated set of polylines showing density), and removed the corresponding entities from the collection. Then I have a range tree of all the time intervals for availability to determine which static lines are visible at any point (to support dynamic fast forward, rewind), and use that to toggle visibility on the cached polylines in the PolylineCollection (also using some relatively efficient set intersections to compare the currently visible lineset to the proposed, so not doing naive availability queries every frame).

Seems to work in principle, but did not solve my performance woes (perhaps in isolation it would be useful).