Styling based on metadata is not applied

[javagl]

When serving the 3d-tiles-samples with a local server, and looking at the MetadataGranularities sample (using the sandcastle that is included there), it shows the different metadata granularities in a tooltip:

For example, it contains the priority property in the group metadata, which has different values for the buildings and the trees.

I'd expect to be able to set a style for the tileset and use this metadata value, like this:

const style = new Cesium.Cesium3DTileStyle({
    color: {
        conditions: [
            ["${priority} === 1", "color('red')"],
            ["${priority} === 2", "color('blue')"],
            ["true", "color('magenta')"],
        ],
    },
});
tileset.style = style;

However, this does not have an effect.

From quickly zooming into the code, this seems to be caused by the applyColorAndShow function that passes undefined to the evaluation function: style.color.evaluateColor(undefined, this._color)

The evaluation function would need a Cesium3DTileFeature to access property values, but here, it does not have anything that it could obtain property values from. I tried to quickly and hackily create a "dummy" Cesium3DTileFeature there:

  const testFeature = new Cesium3DTileFeature(this._content);
  this._color = hasColorStyle
    ? style.color.evaluateColor(testFeature, this._color)
    : Color.clone(Color.WHITE, this._color);

and this seems to work in principle....

But here is where it's getting wierd: When returning not blue but white as the color for the trees, then... this is the result:

It looks like the color from the style is "mixed" (like AND-combined) with the actual color. (It may be worth noting that the colors in the tree models are looked up in a texture, whereas the colors in the house models are just fixed base color factors).

I haven't investigated what is causing that last point. However, if this can be resolved, then maybe creating a Cesium3DTileFeature for the model content (as an instance variable, probably - not each time that the color is applied...?) could solve this quickly...

---

This was brought up in the context of https://community.cesium.com/t/gltf-feature-extensions-support-in-cesium-ext-mesh-features/29121/7

[javagl]

This may, in fact, be one "cell" of the matrix at https://github.com/CesiumGS/cesium/issues/10480 , but this matrix suggests that it is implemented, and from the test above, it looks like this is not the case.

[ggetz]

@ptrgags Do you know if this worked at any point and is a regression? or was this a limitation of the initial implementation?

[ptrgags]

@javagl @ggetz I'll admit I'm a little hazy on the details, it's been a while and Sam S was the one that did the bulk of the CPU styling implementation.

Here are a few more details from briefly looking at the code:

• We certainly supported some level metadata based on styling, e.g. that was the point of https://github.com/CesiumGS/cesium/pull/9896.
• However, I don't remember why we explicitly passed in undefined there... that does seem off to me if that parameter is the feature to evaluate the color with.
• In theory it should support tileset/tile/group metadata in styling correctly, provided Cesium3DTileFeature.getPropertyInherited() is called rather than Cesium3DTileFeature.getProperty() (which only includes metadata scoped to that tile). That should happen as long as you have a feature, see this line in Expression.js
• In regards to the color being mixed in, I believe that's intentional, see this line in CpuStylingStageFS.glsl where it multiplies the diffuse color. This is based on the old (pre 1.97) Model behavior.

[ChrisClsg]

@ggetz & @ptrgags Any updates on this? This would really, really simplify metadata-based styling.

[ggetz]

Hi @ChrisClsg, no updates.

If you'd like to add more information about your use case, that may help us prioritize. If you are interesting in contributing, please let us know and we'd be happy to discuss implementation or review a PR. Thanks!