API of Cesium3DTileStyle

Currently you create a Cesium3DTileStyle like this:

tileset.style = new Cesium3DTileStyle({

color: ‘vec4(1.0, 0.0, 0.0, 1.0)’,

pointSize: 2



To adjust e.g. I like to expected a syntax like:

tileset.style.color = ‘vec4(0.0, 1.0, 0.0, 1.0)’;


But currently you need to write;

tileset.style.color = new Expression(‘vec4(0.0, 1.0, 0.0, 1.0)’);


You could also have the idea to do this:

tileset.style.style.color = ‘vec4(0.0, 1.0, 0.0, 1.0)’;


But this will have no effect, because it is only a getter (Not sure how defineProperties works, but maybe we should throw an exception in case someone try to set a value but not setter is available).

This is a bit confusing. Maybe we should change API:

Current properties:

  • style (getter)

  • show (expression getter/setter)

  • pointSize (expression getter/setter)

  • color (expression getter/setter)

New API:

  • style (getter)

  • show (String/Number/Object getter/setter)

  • showExpression (expression getter)

  • pointSize (String/Number/Object getter/setter)

  • pointSizeExpression (expression getter)

  • color (String/Number/Object getter/setter)

  • colorExpression (expression getter)

In case e.g. color will be set it will create an expression like in constructor now. With this change it is not anymore possible to create an expression from outside and set it directly to style - or we need a way to read plain expression from (Condition)Expression.

What do you think about this breaking change?

This sounds pretty useful and probably how most people would intend to use the API. I’d be ok with a breaking change like that.

And by the way, the plain expression can be retrieved from a ConditionsExpression with .conditionsExpression and from an Expression with .expression.

I’m not sure this needs to be a breaking change. We can just allow style.color (and other properties) to take a string and automatically create the Expression. Basically the color setter would take a string or Expression but the getter would always return the Expression. This is consistent with what we do for Entity properties, so it will better fit with the rest of the API.

Also, assigning to a readonly property does throw an exception, but you need to enable strict mode in your JavaScript (which you should always be doing as a matter of good practice).