Evaluating a `StyleExpression` using an adhoc `Cesium3DTileFeature`

Hi,

I’m trying to execute this sample code:

    const exp = new Cesium.Expression('(${Temperature} > 90) ? color("red") : color("white")');
    const feature = new Cesium.Cesium3DTileFeature();
    feature.setProperty("Temperature", 100);
    const color = exp.evaluateColor(feature); 

It throws 'Cannot read properties of undefined (reading ‘batchTable’) on the call to feature.setProperty.

Looks like I my feature object is not correctly created, but not find anywhere how this should be done.

Any suggestion?

Tx

Hi @mdastous-bentley ,

Thanks for your post.

It appears that error is being thrown here in the setProperty function cesium/packages/engine/Source/Scene/Cesium3DTileFeature.js at cf47252a333e6bcf6b2eef51c20daf23f9f24bdd · CesiumGS/cesium · GitHub It looks like this._content gets set in the constructor and your sample code does not pass content to the constructor …

… however, in case you are not aware, in the docs for the Cesium3DTileFeature class Cesium3DTileFeature - Cesium Documentation is this note Do not construct this directly. Access it through Cesium3DTileContent#getFeature or picking using Scene#pick.

I believe this class is primarily exposed for the purposes of picking from a 3DTileset. You can see some examples of this in Cesium Sandcastle examples like this one Cesium Sandcastle. For more you can drop Cesium3DTileFeature into the search bar in sandcastle.

Hope that helps clarify. Please let us know if you have more questions.
Best,
Luke

Any way to create an “ad hoc” feature without having to read a 3d tiles data source?

Hi @mdastous-bentley, would you mind telling us more about your use case? There may be a different API that could be more applicable.

As a bit of a hacky workaround, you could create a mock feature like we do in ExpressionSpec.js for the purposes of testing.

We would like to re-use Cesium’s expressions in iTwin.js without having to read features using Cesium’s engine.

The actual design of the StyleExpression class seem to support that, except it requires a feature to be passed.

I think it it would be quite convenient to have a single expression format across different platforms, that said we are only at the prototyping phase.

Got it, that makes sense.

I agree it would be a good architectural decision to allow expressions to be evaluated outside of a rendering use case. We’d certainly be open a minor refactoring here to allow it.

Would you have any interest in contributing @mdastous-bentley?