Currently I’m working with polygons consisting of 246 vertices that move over time. The polygons do not change in size or shape, only position. Currently the project accomplishes this by separate CZML polygons that define the positions of each vertex for every second the polygon needs to appear, like so:
// color stuff here
14.763680326900012, 27.029629646718668, 0,
15.04683390517481, 27.080578360029904, 0,
// color stuff here
14.743772057474061, 27.089709345645197, 0,
15.02706418867925, 27.140718219843077, 0,
This is resulting in very poor performance with only a handful of polygons visible at a time. What’s the best way to improve the performance here? Is there any difference between specifying a polygon for each interval like we do now vs. specifying on polygon and just using references to refer to the dynamic vertices? Any other possible tips I could try?
I think defining a different polygon for each time step is going to be significantly slower, if that creates all those polygons/keeps them in memory so they appear quickly when needed etc. It would be worth trying a single dynamic polygon. There’s an example of this here, using a CallbackProperty that returns a list of vertices: https://sandcastle.cesium.com/index.html?src=Drawing%20on%20Terrain.html.
What kind of application are you working on? Welcome to the Cesium community by the way!
It’s a satellite orbit viewer/predictor. These polygons represent the FOV shown on the ground as the satellite moves through its orbit.
Does it have to be CZML? If you can create the needed entities programatically, the values can be a
CallbackProperty that computes the values dynamically. I’ve used this successfully for simpler geometry like rectangles and ellipses – the effect is very smooth. I’m not sure how it will perform with a 200+ point polygon, but it’s worth a try.
You could also look at the
Corridor graphic representation. I’ve used it as an approximation of sensor FOV, with
positions are a curved line across the middle of the sensor arc, from one side to the other, and the width is the distance from the near/bottom to far/top edge.