Looking at some initial profiling with around 3K lines/billboards. I played around with caching static polylines in a polylinecollection and got some benefit, but I’m getting pressed elsewhere. I noticed that there’s a decent amount of time spent removing billboards from entity clusters. It looks related to availability. I defined all of these with CZML, and just used availability as a synonym for visibility. Does anyone know if making entities permanently available, but with an interval for the show property, would be more performant? It seems like it would avoid what appears to be unnecessary removal from certain datastructures.
It seems like you are experimenting with the right things. Making your entities permanently available and then setting an interval for the show property is a reasonable solution that would certainly be more permanent. Do the entities have physical properties that might be “disrupted” if other entities overlap them when they are hidden? What is your use case?
Thanks. Basically playing back a history of entities moving over time, represented as a pair of billboards per entity, which disappear when they stop moving. There are dynamic polylines representing the path that accumulate over time as well (swapped out with static polylines after the movement completes) so you get kind of a density plot. Overlap is not a concern in this case.
I actually have 2 views, a main 3d view of the continental US, and a secondary “inset” view (another cesium canvas) of us → europe coasts. Once entities leave the US for transit, they show up on the inset and their path is tracked using a Path instead of polylines (I may switch to cached polylines to see if this helps performance too; for now I just reduced the % of paths that are actually rendered or accumulated to help with performance). So the billboards exist in 2 entity collections.
I am trying to find any resources to get an idea of the performance model in Cesium. It looks like there’s quite a bit going on with just determining entity availability via binary search on intervals somehow as well, rather than having some kind of schedule to toggle visibility over time. There may be some costs with property references and interpolation too. I’m also curious if I could take control back from Cesium and just render stuff in three.js, or do more primitive rendering. I have the ability to precompute a lot of stuff and schedule things explicitly. I really like the high-level API though, although I think performance is being limited. Staring at flame graphs and reading source code.
Thank you for the details. It is good for me to know that overlap is not a concern in your use case. I also have a better idea of why the billboards that you are using exists in two entity collections. I do not think that there is a simple way to use Cesium while relying on three.js for more primitive rendering. However, this community forum discussion touches upon some of the rendering differences between CesiumJS and three.js:
Let me know if you have any other questions or concerns!