My application currently has approximately 200 moving entities with a model defined. Performance and movement has been reasonable thus far.
I now tried adding an additional entity related to the base entity, so I would go from approximately 200 to 400, and these entities move as well with a position offset from the base entity.
In the final solution, I plan on using a model, but temporarily, I am defining these entities with the "box" option with length, width, height dimensions and a color material.
When I run this, the viewer becomes very slow and the camera movement becomes very choppy and delayed. The imagery tiles load extremely slow.
I thought maybe I have reached too many entities for Cesium, which was a disappointing discovery, because I have plans to add many more
I tried replacing the "box" definition with the Cesium_Ground model to see if there would be a performance difference, and there certainly was.
What causes the box entities to impact performance so much? I would have expected a box to have less of an impact than a model. Is this intentional? Am I doing something wrong?
FYI, all the entities are defined with SampledPositionProperty for position and SampledProperty for orientation and have interpolation set. New samples are added every few seconds.
Maybe you were making 200 different box instances instead of just one box instance shared by the 200 entities. In http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=Box.html&label=Geometries each entity has it’s own box instance, but I think you can define one box, then have each entity use that same box. With primitives you can combine multiple already defined geometry instances using the geometryInstances property, you can probably do the same with entities.
I did try creating a BoxGraphics instance on startup and then during creation of each entity, defined box: boxGraphicsVariable, but it did not change the performance. I'm not sure if it still creates 200 new instances internally.
The number of Entities is not a factor here. It’s actually a problem due to the nature of our current Geometry system, which is largely geared towards static data. There’s overhead in taking geometry definition and turning it into a geometry instance for visualization. We have a roadmap item to add support for dynamic buffers, which will allow us to eliminate this overhead and should make everything much faster.
In the short term, we have some areas of the code that have customized fast paths under certain situations (for example, if you used Ellipsoids everything would have been fast in 3D). Boxes are a candidate for one of these fast paths, we just haven’t coded it yet. These fast paths are only applicable if the object is not reliant on the curvature of the earth (for example, ellipses and polygons have to be recomputed every time something changes, spheres and boxes do not) and only work in 3D (because it relies on the modelMatrix which currently only works in 3D).
We’re going to look into adding a equivalent fast-path into the 1.10 release next month.
