I’m trying to use the CZML Path object to leave a trail behind a visualisation of some tracking data. When I just track the object and have it rotate based on bearing information - this works fine and performance is fantastic.
However, adding a path immediately yields two problems:
(1) The path doesn’t display in 2D view (only in 2.5 and 3D).
(2) As soon as I add a path, the performance of Cesium as a whole becomes choppy (panning + zooming etc).
Are these expected behaviours? I know polyline rendering wasn’t very efficient in the past but I thought that that had been improved in newer releases?
Does anyone have any suggestion on a faster, easy way to render trails in CZML.
I’ve attached an example CZML file illustrating the problem. If there’s any more information I can provide that can help, please let me know.
Path visualization will be dramatically improved at some point, it’s on our roadmap but we have higher priority items right now.
The reason you are seeing poor performance is because you have the trail time set to 600000 but are using the default resolution of 60 (by not setting it). This means that every frame we end up generating a path with over 10000 points in it, which is going to be slow no matter what. I was getting about 15 fps with your original file. I added “resolution” : 600 to the path settings and it jumped to 55 fps. Over 1000 points for the track is still a lot, but not unreasonable depending on the use case. Of course the problem with a high resolution for an object on the ground is that the trail line will start to cut through the earth. We plan on fixing this eventually, but it’s probably a few months away as well. Of course this can be mitigated by having more points in the CZML file because we always sample at the user-defined points when generating the path.
Finally, do you really have a single track that goes for 5 months? Or is this a track comes in and out of existence over the course of 5 months? If it’s the later, you would be better served by splitting the position over multiple intervals (and setting the availability to match). It can still be one object/id, but having it over different intervals will prevent weird interpolation artifacts due to the huge amount of time between points. and should also produce less points overall and improve performance.
Thanks! Makes sense. Increasing the resolution helped, although this will still mean we can only use trails in certain very specific circumstances (for one or two objects, rather than a few hundred - although I guess this is enough for now :).
Out of curiousity - what kind of changes are coming the roadmap for this?
Hi Matt,
I have also problem with performance, I am working with cesium1.29 running 1000 targets with trailTime 60. For any resolution I tried, the screen is stuck or targets disappear.