We have successfully integrated Cesium Native into our custom 3D engine. Rendering works as expected with both Google 3D Photorealistic Tiles and Cesium World Terrain, including correct occlusion handling.
However, we are encountering issues with OSM Buildings. While the tiles render correctly, they do not appear to behave consistently with other tilesets. Specifically, instead of being culled and occluded based on the camera frustum and our custom occlusion algorithm (implemented via TileOcclusionRendererProxyPool), the buildings remain visible.
The problem is that buildings are rendered even when they fall outside the frustum. From our observations, it seems that Cesium is loading all buildings from the visible tiles, regardless of the current LOD. Or even worse, loading all buildings with a center and radius.
This behavior might not be critical in sparsely populated areas, but in dense urban environments it has a catastrophic impact on performance, leading to excessive resource consumption, unnecessary network requests, and a significant drop in FPS.
We would like to confirm whether this is the expected behavior for OSM Buildings, or if it could be an error on our side. If this is unintended, we can open a GitHub issue to track it more formally.
Below is a screenshot captured from outside the frustum view, which illustrates the issue:
Sometimes, tiles in OSM Buildings have bigger bounding volumes that span buildings that are relatively far from each other, which can look like unintuitive selection behavior. It might be worth double-checking this location in Cesium for Unreal / Unity, or even our web-based Sandcastle, to see whether this behavior happens in those engines. Each one has it’s own Freeze Frame / Suspend Update setting to pause the tile selection at any given view.
If you see the same buildings appearing out-of-frustum, then it’s probably expected.
Thanks @janine. I can confirm that the issue is caused by the OSM Buildings having larger bounding volumes. The behavior we’re seeing is consistent with what happens in CesiumJS. It would be great if this could be investigated further to see whether the resolution can be improved to avoid loading such large tiles. This isn’t an issue with the asset ID you were using in the Sandcastle example (which only loads Manhattan I think), but it does occur when using the full OSM Buildings tileset
A key difference between Cesium OSM Buildings and the other tilesets you mentioned is that OSM uses “additive refinement”.
With the other tilesets - which use what’s called replacement refinement - there’s one large tile covering the entire world. But if you’re zoomed in close enough that that single worldwide tile doesn’t have enough detail, then we hide the one tile and display its smaller / more detailed child tiles instead.
However, with Cesium OSM Buildings / additive refinement, when that root tile is deemed not detailed enough, we instead add the geometry in the child tiles. We continue rendering the one large tile, too.
In Cesium OSM Buildings specifically, the largest buildings are in the least detailed tiles. So it is common and expected that large buildings outside the view frustum are visible.
There are tradeoffs here, of course. Starting with the usual tension between culling and batching that is pervasive in 3D graphics. But usually additive refinement is used with tilesets like Cesium OSM Buildings were the geometry is relatively simple, so the rendering load of the large buildings outside the frustum is not too high.
By the way, I’m excited to see you have some success integrating cesium-native into a new rendering engine. We’d love to hear some more details if you’re willing to share!
