Disable depth test against a specific asset for Primitives

[jjspace]

This primarily stems from an observation I've made of the behavior of billboards at the horizon. Ideally billboards usually should be drawn "on top" of everything else until they are on the opposite side of the globe.

By default in Cesium this happens "for free" out of the box as can be observed in the Billboards sandcastle

When it's near the horizon but on "this side"

When the globe is turned slightly so the billboard is on "the other side" of the globe it gets clipped off

However, when using a global 3d tiles tileset like the Google photogrammetry tiles this behavior is not the same. The billboard is always drawn "under" the tileset
"In front"

"Behind"

The behavior of the 3dtiles can be replicated with terrain if you set globe.depthTestAgainstTerrain to true.

I think the default behavior of terrain is normally the expected result out of the box (given issues like #12396) however this requires some new architecture to add a way to ignore depth tests against a specific asset or tileset like we do with the terrain.

Workaround

The best solution right now is to control the value of disableDetphTestDistance on the billboard itself. Setting this to Number.POSITIVE_INFINITY "works" to always show a billboard on top of 3d tiles as terrain but it also allows you to see billboards on the other side of the globe.

A niave workaround I used for the Moon sandcastle is to set this distance based on the position of the camera which lets you approximately achieve the same cutoff at the horizon but it's not perfect. Check out this sandcastle showing this off

disableDepthTestDistance: new Cesium.CallbackProperty(() => {
  return Cesium.Cartesian3.magnitude(viewer.scene.camera.positionWC);
}, false),

[ggetz]

We have a fix for this behavior, but it is only implemented for terrain(originally in #6621, with follow-ups in #6781 and #6844).

As an aside, the fix is only applied when the camera is close enough to the billboard, with "close enough" being an arbitrary distance (2000m). It may make sense to revisit that distance, depending on performance implications.

[mzschwartz5]

I'm actually more curious why this bug doesn't occur even when depthTestAgainstTerrain is false.

Look at this image - with a terrain provider and depthTestAgainstTerrain true:

It's clear to me (at least after exploring this bug for a while) that what's happening here is that the part of the billboard behind the globe itself. But why does this only happen when depth testing against the terrain is on? Even with it off, I'd still expect part of the billboard to render behind the globe, and thus be occluded. After all, that's what happens when you rotate the globe so the billboard is on the other side (it gets occluded - even with depth testing off).

[mzschwartz5]

Proof of concept fix (note that the "fix" is only applied to the label here, not to the billboard icon)

The idea is to dynamically set the eyeoffset of the billboard / label based on its world space size. So if the billboard is very large (compared to the Earth, not necessarily in screen space), it gets a larger offset towards the camera. If it's small in world space, it has a smaller offset. This handles varying camera zoom levels very well, and very naturally.

This may seem arbitrary, but I think it has some intuition to it. A mountain peak that pokes through a billboard ought to occlude the billboard if the billboard is small compared to the mountain, but if the billboard is on the scale of the globe, that mountain peak is really just noise, comparatively. The scale that matters is the billboard's world scale. All adjustments / offsets should be relative to that.

Now, while users could directly use the code in the above sandcastle (it only uses the public API), I think we could add this directly to the source code around here. Basically, replace this constant 1.005x multiplier eyeOffset with the calculation in the example above.

edit- actually, replacing that constant there wouldn't work, because it's not updated every frame / on camera changes. I think this dynamic offset could / should be applied at the vertex shader level.
edit 2- also, I think this adjustment works for 3D tiles as well as terrain, so that's a bonus.

[mzschwartz5]

Here's another example with a billboard in the grand canyon, showing how it works well at small scales, too.
Same example but with 3D tiles.

And an example with a label amidst fine-structure models

[jjspace]

This approach does seem better on many scales, especially around the grand canyon. However, one of the most important instances where this issue happens is global scale near the "tangent horizon". With this new approach the labels are getting cut off early before the "anchor point" of the billboard is actually on the far side of the globe. This is not what I would expect, see my first post.

[javagl]

Just a drive-by-comment (and without knowing exactly what the expected behavior is): Even for the "baseline" of a standard billboard with terrain and without depth testing, there is a tiiiny range where this happens:

(Not sure whether this helps or distracts)

[mzschwartz5]

To both @jjspace's and @javagl's comments, I think this is sort of expected behavior, given how billboard's currently work. If any sort of depth testing occurs, there will be a point - either on one side of the globe or the other, depending on the billboard's anchor - where the billboard points into the globe.

I'm wondering if it maybe makes sense to dynamically change a billboard's anchor. Let the user specify the desired anchor point, but allow it to shift as the billboard approaches a globe edge?

[javagl]

It's clear to me (at least after exploring this bug for a while) that what's happening here is that the part of the billboard behind the globe itself. But why does this only happen when depth testing against the terrain is on? Even with it off, I'd still expect part of the billboard to render behind the globe, and thus be occluded. After all, that's what happens when you rotate the globe so the billboard is on the other side (it gets occluded - even with depth testing off).

My interpretation of depthTestAgainstTerrain is exactly that: When this is true, then everything behaves normally, and billboards are obstructed by terrain that is in front of them. When this is false, then billboards that are on "this side of the globe" are always rendered in front of the terrain (without depth test), even if they are (partially) behind the terrain.

There probably is a good reason why this flag exists in its current form. And I'd really like to know what that reason is. Websearches indicate that this has caused an astonishing amount of trouble in the past. It may sound naive, but the first thing that I'm wondering about is why this is a Globe-al setting, and not one that is per-object. Independent of that, but still ~"related" in view of the issue, and specifically for billboards: I could imagine that for many use-cases, people don't even want a "half-obstructed" billboard. This sounds rather like some "all-nor-nothing" situation.

However, I used the term "this side of the globe" above, and this begs the question of what this means, exactly. If I understood this correctly, then the "workaround" that was suggested above, as

disableDepthTestDistance: new Cesium.CallbackProperty(() => {
  return Cesium.Cartesian3.magnitude(viewer.scene.camera.positionWC);
}, false),

defines this as "The position of the object is closer to the viewer than the center of earth", which sounds reasonable.

It was said that this is "not perfect" - does this only mean that it "switches" at a different point than the depthTestAgainstTerrain-behavior?