in our CesiumJS implementation we use Cesium3DTileFeature to show/hide, highlight and colour specific features.
Is support for this kind of rendering granularity on the roadmap for Cesium Native and Unreal?
I don’t see anything equivalent in the source, and see that this may be non-trivial with the mapping of GLTF primitives to static meshes. Is there any suggested approach to allow altering material properties at runtime for specific features?
thanks for your response! That’s great to know about. Styling is definitely a feature we use.
We have use of the feature references based on runtime input - user picking for example - where we have used the JS APIs to apply highlights.
This is also used in cases where the IDs to make selection are embedded in the tile feature tables, but the data to make selection is not. In these cases we cannot directly use styles but use the handles to the features to show/hide or colour individual features.
From a quick look through the PR I don’t see an equivalent to the TileContent.getFeature(batchID) or similar method, though there are a lot of commits and it could easily be in there.
Please let me know if the question or use case isn’t clear.
Yeah there’s nothing in that PR currently that directly enables that use-case, but it adds a lot of the necessary building blocks. It might even make it possible to implement in application code, with a little effort.
I can see that this adds tools which would be usable to make per-feature properties. My Unreal-fu is not strong enough to work out a good approach for that, would anyone be able to provide some direction? Happy to collaborate and submit this if it becomes useful.
On the surface it appears that we would need something that hooks into the texture utilities to generate a texture that can be indexed using the feature ID (per GLTFComponent), then build that into a material layer to override say the base colour and opacity. That might be one approach, anyway - perhaps some kind of uniform buffer might be better than a texture. The per-feature data would need to be updated for highlight colour, visibility or opacity changes with that approach, based on the featureID retrieved by raycasting.
Potentially if this could be done as part of a CustomDepthWrite pass we could allow post-process highlighting instead which would allow highlight or outline of hidden selections. Sounds like more work though!