Property Textures Demo

Hi all,
I am learning about 3D Tiles Next and looking at the Property Textures demo:
https://demos.cesium.com/property-textures

Is this demo + data available?
It would be a very informative example.

Thanks!
Dan

I think that exact data set is not publicly available.

But maybe you’ll find the SimplePropertyTexture sample from the 3d-tiles-samples repository helpful. The is inspired by the Property Textures section of the specification (it might not be 100% equal, but it’s very similar).

Great. Thank you! I did find that example and was looking into it that right now. One functionality that is not int he 3d-tiles-samples example is the ability to click on a point in the dataset and see the texture property value at that position. Can you point me to an example that shows something similar? I think even the demo code without the data would be useful in showing that. Thank you very much!

The 3d-tiles-samples examples does show properties values as tool tips so I think I am all set. Thank you.

The other examples show how to display metadata values in tooltips. But I think that the functionality to directly access property texture values (based on picking/texture coordinates) was a special implementation for that particular demo, and might not be available in the standard API yet. (I’ll have to confirm that internally…)

To confirm the latter: Picking property texture values directly is not yet possible. The progress for this is tracked in Supporting picking properties from property textures · Issue #9852 · CesiumGS/cesium · GitHub

Oh, I see. Thanks for the information. I’ll keep an eye on that issue.

@Marco13 I tried to modify the SimplePropertyTexture example to have a FLOAT32 property instead of four UINT8 property. When I try to use the custom shader to render the float texture I get:

[Cesium WebGL] Fragment shader compile log: ERROR: 0:3: 'rtdata' :  no such field in structure
ERROR: 0:3: 'constructor' : a struct cannot be used as a constructor argument for this type

[Cesium WebGL] Fragment shader translation failed.
An error occurred while rendering.  Rendering has stopped.
RuntimeError: Fragment shader failed to compile.  Compile log: ERROR: 0:3: 'rtdata' :  no such field in structure
ERROR: 0:3: 'constructor' : a struct cannot be used as a constructor argument for this type

Do you know if the shader works with FLOAT32 properties? Thanks!

Until now, only UINT8-based types are supported for custom shaders. (One could try to “emulate” a 32bit float value with that, but that might be a bit quirky…). The issue for tracking the support of other types in property textures is at Handle remaining types for property textures in custom shaders · Issue #10248 · CesiumGS/cesium · GitHub

Thanks for the pointer. Is there any other way to show FLOAT32 properties stored in a texture or one has to wait for one of these two issues to be implemented? (or as a workaround just store things as UINT8) Thanks!

It could be a bit unfortunate to create actual models with workarounds. These workarounds would have to be applied at two places:

  • in the model itself, by using UNIT8 where FLOAT32 should be used
  • on the client side, when trying to read this data

Maybe @ptrgags : Is there a rough estimate for the support of other types, or a workarodund that does not have to be applied to the data itself?

Seems like ‘normalized’, ‘offset’ and ‘scale’ work correctly, so I can just quantize the floats onto the UINT8 and display that using the custom shader. Indeed, I’ll have to know the min, max of the float in the client as well. Is there is a way to read that from the data? Thanks!

The question about how this information can be made accessible for the client in a sensible way still has to be sorted out.

It is technically possible to access this information now, but this makes some assumptions and requires accessing private API - so it really should be considered as a preliminary workaround as well. It could therefore makes sense to carve this out into a small helper function, with a prominent note that this is using an internal API:

function getProperty_INTERNAL(content, className, propertyName) {
  if (!Cesium.defined(content._model)) {
    return undefined;
  }
  const metadata = content._model.structuralMetadata;
  if (!Cesium.defined(metadata)) {
    return undefined;
  }
  const cls = metadata.schema.classes[className];
  if (!Cesium.defined(cls)) {
    return undefined;
  }
  const property = cls.properties[propertyName];
  return property;
}

With this function, you can access the required information at runtime like this:

  // Assuming that the relevant glTF is in the root node:
  const content = tileset.root.content;

  const property = getProperty_INTERNAL(content, "buildingComponents", "insulation");
  console.log('min ' + property.min);
  console.log('max ' + property.max);

The requirement for proper access functions is already on the radar. This is usually mainly related to picking (e.g. as in Streamline the API for accessing tileset/tile metadata when picking · Issue #10015 · CesiumGS/cesium · GitHub ), but it should also be possible to access the schema in a programmatic way. If you have specific ideas derived from your use-cases, feel free to share them here or in the respective issues.

I’ll add one more detail, we do have a table showing what types of metadata are supported where: 3D Tiles Next Metadata Compatibility Matrix · Issue #10480 · CesiumGS/cesium · GitHub

@Marco13 @ptrgags Thank you very much for the detailed information!