Accessing point attributes for dynamic re-coloring (declarative styling)

[JordanMakesMaps]

I'm interested in doing declarative styling so that we can manipulate the color of individual points within a point cloud (i.e., 3D tileset).

Currently my process involves converting existing file formats into a .laz file and then uploading to Cesium via REST API. When using one of the Sand Castle examples I see how specific variables (height, temperature, etc.,) can be accessed, and through conditional logic their color or "style" can be altered on the front-end. However, when trying the same example with our own assets I'm unable to access these variables (likely because we did not set them).

My question is, at what point in the uploading, tiling, and viewing pipeline do I need to provide the necessary information to the Point Cloud asset so that I can perform declarative style?

[lilleyse]

@JordanMakesMaps what properties does your point cloud have? If your points have color it will be available as the ${COLOR} built-in property. If they have classification or intensity it will be available as ${Classification} and ${Intensity}.

Hopefully this helps. If you have other questions feel free to open an issue in the Cesium community forum: https://community.cesium.com/.

[JordanMakesMaps]

@lilleyse thanks, I see that now. With regards to {POSTION}, are the attributes (.x, .y, z.) in the same format as they were before uploading? I'm uploading .laz files that have negative values Z-values, but in the {POSITION}.z doesn't seem to reflect that.

Thanks.

[lilleyse]

${POSTION} is the cartesian position as stored in the tile, and not the original position since there are a series of coordinate transforms that happen in-between. The original positions would need to be stored in the tile separately which ion doesn't support right now.

While it's not exactly what you're looking for, you can style based on ellipsoid elevation by using ${POSITION_ABSOLUTE} like in this sandcastle (though note the precision caveats). We're also considering making the elevation accessible to custom shaders: CesiumGS/cesium#9735.

[JordanMakesMaps]

@lilleyse okay, the ${POSITION_ABSOLUTE} definitely makes more sense in my situation; my point clouds are large and using just the ${POSITION} attribute seemed to based on the position of points in whichever tile was currently rendered (independently of the others).

A few more questions if that's aright:

• LAS/LAZ files have the ability to store a set number of channels (x, y, z, intensity, NIR, classifications, etc.): by default does Cesium retain these channels and store them in the tile when uploading the LAS/LAZ files using the REST API? If so, can you point me to the documentation that describes how to access these attributes?
• I saw in some examples that there are attributes like {Temperature} and {Height}? I know these are not native to LAS/LAZ files so how are they being added to the tiles on Cesium? I'm assuming these are baked into the tiles using the Feature Table (as described in section 10.4 of the reference card). Is that correct? If so, would I need to tile the assets myself to bake whatever attributes?

[lilleyse]

• Cesium ion automatically retains x, y, z, red, green, blue, intensity, and classification if they exist in the LAS/LAZ. In the future we may give finer grained control over this process and support other attributes.
• The tilesets with Temperature and Height were generated synthetically with https://github.com/CesiumGS/3d-tiles-validator/tree/main/samples-generator. If you want full control over which attributes go into the feature table you would need to tile the data yourself. We're hoping to provide more control over this in our tilers as well by supporting LAS 1.4 extended variable length records.