Feature Request: Per-Material Overrides for Sectioning Support

Summary

Currently, Cesium3DTileset only provides an opaqueMaterial property to override materials. This forces a single material onto all tiles, preventing the use of custom shaders (like those for 3D sectioning) in tilesets that mix Lit and Unlit data. We request the ability to provide separate material overrides for each Cesium material type.

Context and Problem

To support model sectioning (clipping planes), we have customized the Cesium shaders to discard pixels based on section plane equations passed via global shader properties. To use these, we must assign our custom material to tileset.opaqueMaterial.

The Primary Issue (Lit vs. Unlit): By using the opaqueMaterial property, we force the tileset to use one specific shading model. If we provide an Unlit sectioning shader, tiles that require lighting (like those using CesiumDefaultTilesetMaterial) lose their shading. Conversely, if we provide a Lit shader, Unlit tiles (like Google Photorealistic 3D Tiles) may render incorrectly.

The Point Cloud Issue: Additionally, opaqueMaterial does not adequately cover Point Clouds. To achieve consistent clipping across a diverse tileset, we need to be able to provide a sectioning-enabled version of the CesiumPointCloudShadingMaterial as well.

Proposed Solution

Provide separate override properties on the Cesium3DTileset component to allow for targeted customization:

  • unlitMaterialOverride
  • defaultMaterialOverride (Lit)
  • pointCloudMaterialOverride

This would allow Cesium to maintain its logic for selecting the correct material type for a tile while letting us inject our custom sectioning logic into each.

Alternative Considered: Native Sectioning Support

I initially considered suggesting that Cesium support 3D sectioning natively. However, I realize it is not easy to make a solution that works for every user. Right now we are happy to define sectioning by at max 8 section planes. But in the future we might want more of them, or we might want sectioning by complex meshes or defined by means of complex boolean operations (intersections and unions of volumes).

Given these variables, supporting per-material overrides is the most flexible path forward.

Hi, as someone who did something similar with adjusting the `CesiumDefaultTilesetMaterial` you can use different materials for different 3DTilesets by seperating the 3DTilesets. The terrain could use a lit shader variant while buildings use a unlit shader variant.

What do you mean exactly with the point cloud issue? I’m aware that it’s not as straight forward to edit the point cloud material (Although its possible, I’ve done that already) tho it’s entirely possible & working to have clipping functionality for the Point clouds, **unless you are using the attenuation property as this will use a different shader (Tho it’s possible to even edit that base shader logic to add clipping)

Hi @JanikCodes.

I have checked the materials used by CesiumIon for different Ion assets. From there I conclude that GooglePhotorealistic3dTiles uses the unlit material, and all other tilesets use the lit material.

Using that information, I hardcode the opaqueMaterial override at tileset level, based on what kind of tileset taht is (GooglePhotorealistic3dTiles => unlit, others => lit).

But my understanding is that this is not the correct approach. GLTF has a KHR_materials_unlit extension. The decision what kind of material to use is actually made at mesh level based on whether that extension is used by that GLTF mesh or not.

To be honest, I don’t know of a specific tileset that uses the pointcloud material. I had assumed it could be used somewhere, because CesiumForUnity also defines a pointcloud material.
I haven’t tried at all to make a derived material from the Cesium point cloud material.