Entities plotted above a translucent 3D Tileset (b3dm) lose visibility on zoom-out as tileset opacity is reduced, how to decouple entity alpha from the underlying tileset?

CesiumJS
1

We have a 3D Tileset (.b3dm, photogrammetry of a city) added to the scene, and several entities plotted above it, dashed polylines.

We expose an opacity slider that lets the user “see through” the buildings:

When the tileset opacity is 1.0, everything renders correctly. As soon as we drop opacity, the entities above the tileset start fading along with it, especially the dashed polylines. The effect gets dramatically worse on zoom-out: dashed lines lose alpha until they are nearly invisible, even though their own material alpha is still 1.0.

The expected behavior: an entity plotted above (or near) a translucent tileset should keep its own alpha and not be coupled to the underlying tileset’s translucency.

Sandcastle Link: Sandcastle | CesiumJS

3

Hi Vishant_Shah,

I’ve checked out your sandcastle, to me it appears that the dotted lines persist with full transparency while you’re adjusting the tileset opacity. Only until you get to 0 do the lines adjust, given that 0 transparency on a tileset disables it from rendering altogether.

Please forgive the graininess of this gif, in the rendering the dotted lines for me preserved opacity.

2026-05-29_14-42-01

Are there other entities that you’re experiencing a fading opacity issue with?

4

I think this mainly referred to the case where the “2D” (top down) view is selected.

Selecting a non-100% opacity causes the lines to disappar or become semi-transparent as well. But that also depends on the zoom level.

Cesium Dashed Lines

Could be some sort of “z-fighting” issue, where the lines are drawn ~“1 pixel behind the geometry” or so, but that’s a very wild guess…

5

yes in 2d view its getting semi-transparent on zoom out

6

if u can switch to 2d view u will be able to notice the transparency difference

7

how can we solve this then?..any suggestions for the fix?

8

I spent some time reproducing this locally and narrowing it down. Here’s what I found:

It’s specific to orthographic/2D projection. In a standard 3D perspective view, the dashed polylines render correctly regardless of tileset opacity. The issue only manifests when using the orthographic frustrum.

It’s not related to classification type or ground clamping. I tested with ClassificationType.TERRAIN (no tile classification) and also with non-clamped polylines rendered at explicit heights above the tileset. Both are still affected by the tileset’s alpha in ortho mode.

This points to a rendering pipeline bug in how CesiumJS composites polyline primitives against semi-transparent tilesets in orthographic projection. It looks like the tileset’s alpha value is incorrectly affecting polylines that should be rendered independently (or on top).

I don’t have a client-side workaround to offer at this point. I’d recommend filing a GitHub issue at Issues · CesiumGS/cesium · GitHub with your reproduction steps/sandcastle so the team can investigate the ortho compositing path. You can reference that the issue is isolated to orthographic projection and is independent of classification type or clamping.

As a short-term workaround, if your use case allows it, rendering in perspective 3D (even with a very flat/high camera angle) avoids the problem entirely.