Fast billboards scaling

I’m trying to resize a lot of entities on every rendering cicle. To do that I need the fastest access to the variable size.

For the point entities I have used:

  myEntity.point.pixelSize._value = size;

In this way the access is a lot faster than simply use

myEntity.point.pixelSize = size;

and I can resize 30000+ entities without any performance issue.

But I can’t do the same thing with billboards.

By writing

myEntity.billboard.scale = k;

the access is very slow and I can’t resize more than 300 billboards per iteration.

Is there a way to speed up this process?

Have you tried using a ReferenceProperty for your scaling?

You could also look into using the CallbackProperty

Let me know if either of those helped speed things up

Thank you for your answer.

The first suggestion is not useful in my case, because all my entities are indipendent.

The second suggestion does not give me any performance boost.

I’ve got the CPU profile for both the situations (with and without modifying the scale property). Before submitting you the results, I want to punctualize that I also change the position of all the entities during every rendering cycle without any performance issues.

If and only if I change the Billboard scale property, the createProperty() function from createPropertyDescriptor.js is called (in particular the element “set” from this function).

This function is the most CPU expensive operation and it is the cause of my problem.

Matteo, you should never read or write a property that starts with an underscore. This indicates an implementation detail and is not part of the public API. There’s no guarantee that your code won’t suddenly break in a future release if you rely on these types of properties.

Can you explain in more detail what you are doing? If you use a CallbackProperty, you should only create it and assign it to the billboard one time during set up. You should not be assigning it to the scale property every frame. This is true of the entire property system. If you can share some code to illustrate what you are doing, I can make more specific suggestions. As a quick example, here’s some code that generates 20,000 billboards and assigns a random scale to each one every frame. (Note they all share the same scale property here, but they don’t have to).

var viewer = new Cesium.Viewer(‘cesiumContainer’);

var scaleProperty = new Cesium.CallbackProperty(function(time) {

return Math.random() * 2;

}, false);

for(var i = 0; i < 20000; i++) {


position : Cesium.Cartesian3.fromDegrees((Math.random() * 360) - 180, (Math.random() * 180) - 90),

billboard :{

image : ‘…/images/facility.gif’,

scale : scaleProperty




thank you for your answer. The CallbackProperty is very useful!

Now I’m trying to create a big number of moving rectangles, but I don’t really know how to face the problem. I’m creating a CPU-based particle system to visualize 3D weather conditions. I created particles based on billboards to show clouds, snow and other things, but I also want to create particles based on rectangles (with a texture when required) to show other things like the rain.

This rectangle should have the same properties of billboards, but I want the ability to rotate them in the direction of the particle velocity. Is there a structure that allow me to do that (with a performance impact similar to billboards)? I tried with rectangles, polygons and walls, but I have both performance and ‘leeway’ problems.

Thank you for your support.

Unfortunately, Rectangles and other geometry that depends on the curvature of the earth are currently much slower than single point visualization (such as billboards) when being used dynamically. Objects that don’t conform to the earth (like Ellipsoids) are still very fast. This is a known issue that we will eventually fix with dynamic buffers, but we’re most focused on 3D Tiles and vector data on terrain right now. If your rectangles are moving every frame, then their might be some improvements we can make in the short term, but if they are moving every frame that’s a much tougher problem to solve.

You might be able to write some lower level code that uses scaled BoxGeometry and simply modifies the modelMatrix instead of recalculating it every term. But for large boxes they won’t conform to the curvature of the earth, so if you need that it’s a non-starter.

Ok, thank you Matthew.
It is not a priority so I will wait for the dynamic buffers.