I was looking into the number of maximum of billboards that Cesium will support given a 30fps goal. I found the following page and found the a comment about 50000 unique billaboards and texture memory. This is an old post so I was hoping that there was a updated post given this type of information.
We’re going to adding possibly 100K billboards with images generated from the milsymbol library. Many of the billboard images will be repeated, and I’m not concerned with texture memory. I’m more concerned with any test information given pushing cesium to it’s limits of the billboard count.
I’m also displaying billboards using milsymbol. I’m interested to see what you come up with. Our billboards are around 32px (the size varies based on symbology decorations selected) and we start having serious performance problems over about 30k – the number varies by system of course, but degradation is not linear and tanks sharply as more are added. For our applications this is usually sufficient but I do wonder if there’s something we could be doing differently that would help. I’ve tried to dig around in the browser performance tools to see what I could optimize but I always get lost somewhere inside BillboardCollection.
TJ, on my laptop (i7-8650U, Intel HD 620) that demo sits around 5-7 FPS when you zoom to where all billboards are showing. I took it down from 100k to 20k and it hovers between 29-30 FPS.
I checked Task Manager and the default (100k) was pegging my integrated GPU, so I thought I’d try switching the browser over to the dedicated GPU (GeForce 1060) instead. At 100k entities, even the dGPU is maxed out, showing 100% in task manager, but it can manage 24-26 FPS. It can juuuuust about make it up to 30FPS with 80k entities, but often dips below even when doing nothing with the map – panning or zooming significantly drops the framerate.
It’s interesting to note that adding 100k entities then zooming in to look at, say, 1k of them, results in a lower framerate than only adding 1k entities in the first place, but a much better framerate than looking at all 100k. Offscreen entities do have a “cost”, but not as much as onscreen.
To the OP: I’d say this means that the framerate you get is likely to be a function of entity count and GPU horsepower. If you want 100k entities, you might get a decent framerate if you buy a (very) beefy video card. For our needs, I took a hybrid approach. We do suggest a dedicated GPU to our users, if possible, but I’ve also taken steps to dynamically load entities based on the current viewport. We wait for the user to zoom in, then query the back end based on the visible region and only create onscreen billboards. We hook the camera moveEnd event and load more entities after they pan/zoom. We have a configurable entity ceiling, and each time we add more entities, if it would exceed the threshold, we look for offscreen entities to cull. We keep the entity data (symbol code and position, at least) in memory but only “render” it to Cesium if it’s actually visible after a camera pan. The “pop-in effect” isn’t too bad, similar to zooming in on a new place in Google Maps – first the current baselayer tile expands, then a more detailed tile set replaces it, then “points of interest” (symbology) comes in over top.
We are working on further optimizations to get things even more efficient. Note: this version is not available yet, so if you download c137.js you will see the usual performance.
