I know that it is not possible to adding or removing batch of labels in primitive api for cesium. You need to one by one use add/remove method of collection. Collections have add method but don’t get array or something. However the documentation says:
" Calling add is expected constant time. However, the collection’s vertex buffer is rewritten; this operations is O(n) and also incurs CPU to GPU overhead. For best performance, add as many billboards as possible before calling update ."
or
" Calling remove is expected constant time. However, the collection’s vertex buffer is rewritten - an O(n) operation that also incurs CPU to GPU overhead. For best performance, remove as many labels as possible before calling update"
How to use update method at once? Afaik, the render loop controls the preparing objects to send the gpu. Wouldn’t be better if add and remove methods could get also primitive arrays or there could be addMultiple, removeMultiple methods created?
When you try to remove 70k labels and 45k billboards, that blocks the main thread and takes so much time. The documentation also suggest that it is less time consuming just to hide and show primitives. So, if I hide all the objects in the map and achieve removing operation asyncronously in future time by small batches, then the time for newly added primitives increase since there are 100k primitives on the map already waiting to be removed.
To sum it up my question is how to remove massive batch of labels and billboards from cesium then execute update operation at once? The documentation is not clear about how to achieve this. Note that there could be some other label and billboard primitives already existed and removeAll method is not an option because of that.
When you try to remove 70k labels and 45k billboards,
Could you elaborate on your use case a bit? I’d like to understand why its needed to remove so many at once.
Overall the best thing to do would be to avoiding adding and removing primitives as much as possible. Instead (as you mentioned) hiding the primitives and then re-purposing them for new labels. It sounds like you are removing some billboards and labels and adding other back later. It would be best to reserve primitives in a pool and re-use them.
One thing to consider with that many labels is if they are all needed on screen at one time. It’s bad for performance, but users might have a difficult time parsing all those labels. Clustering will group labels together until zoomed in. It’s available in the entity API, but you could consider an implementation to the same effect for Primitive labels, which would require far fewer being rendered at one time.
Thanks for the answer,
Yeah, at that day, I ended up something like your suggestion after realizing there is no way to reduce the remove time, probably will leave em to object pool some other time. I know it is hard to understand that much labels but this is another story that unfortunately I cannot change atm. I already tested label performances on other gl driven libraries and saw labels are problematic mostly. No one likes to see labels labels labels in games maybe but people like to see labels labels labels on other kinds of applications. Since GPU’s are being made for games right now, I don’t think this problem will be solved soon.
As an addition, in my free time when I’ve done some tests for 5000 labels the results are:
Test1: Adding 5000 labels from zero: 11 ms
Test4: Removing labels by using ‘remove’ method of collection: 613 ms
When it is on 1000 labels:
Test1: Adding 1000 labels from zero: 3 ms
Test4: Removing labels by using ‘remove’ method of collection: 46 ms
The more primitives exists in cesium, the time increases non linearly on removing objects. I believe that happens because of searching the components of labels in arrays or such since time increases by the number of features. Not sure how cesium side works on that matter. Although, I will implement a way to bypass this problem, I believe that can be helpful to provide feedback to improve cesium stack. Maybe it is already on the roadmap, I am not sure.