Labels clipping by earth

[rileyhowley]

Hey cesiums,

With the latest 1.136.1 release I am still having issues with my labels. Now my labels are being clipped by the earth.

Here is the sandcastle link

Sandcastle | CesiumJS

Reproduction steps:

• Load the sandcastle example and run the code
• Find the cluster with the label
• Zoom in and tilt the earth until the label is clipped
• –”I find it easier if the cluster is over land, shows the issue more clearly”–

If I am doing something wrong please let me know as this is blocking our google maps release

Cheers

[mzschwartz5]

Hi @rileyhowley,

This is tricky… see, this is sort of the intended behavior. After all, this point is right on the ellipsoid’s surface, so half of it is embedded in the globe and should be occluded. But, obviously, that’s not ideal visually.

If you were using terrain or 3D tiles, the answer would be “set the vertical origin to BOTTOM and clamp the entity to ground.” That way the bottom of the label/billboard would be on the ground, and it wouldn’t clip. But with the plain ellipsoid, there’s no concept of clamping to ground.

What you can do with the plain ellipsoid, though it’s a bit more magic-number-y, is just give the entity a slight height offset. Of course, for that to work well at all zoom scales, that offset would need to be dynamic based on the camera’s distance… not a great option.

I don’t think this is a new issue. We have some ongoing threads discussing how to overhaul billboards (or at least provide a new, separate API) in a way that’s easier to use and more consistent with other 3D libraries.

[mzschwartz5]

(Looking into this a bit more, it seems like there’s something else going on here as well - even if I move up the label’s height, it can still blink out of existence some times… I’m not even sure if this is a depth bug. Will reply when I learn more)

edit- ah, that would be the eye offset pushing the label past the camera’s near clip plane.

[mzschwartz5]

Here’s a simplified version of your sandcastle that’s a little better:

• Uses disableDepthTestDistance with a small value so when you’re within that distance to the billboard, depth testing is disabled and clipping will not occur.
• Uses a small camera offset so that the label doesn’t clip behind the point primitive.

The camera offset does mean that if you get too close to the primitive, it will prematurely get clipped by the camera’s near clip plane. You could programmattically remove that offset when the camera is close.

Hope that helps. We know this isn’t the simplest API and, as I said before, we’re thinking about how to improve it.

[rileyhowley]

Hmm interesting, the reason I raise this is because it was working the way I intended before I did the update

I tried your example and found little to no difference unfortunately

In my real use case I am clamping the entity to ground however it does this with the label

I would put a video but it doesnt let me

cheers

[mzschwartz5]

1. Are you clamping the label and point primitive to the ground individually?
2. What happens if you set both the label and the point primitive to have VerticalOrigin to BOTTOM?
3. What happens if you remove the point primitive entirely? (Just curious if the glitchiness is due to an interaction with the point primitive and label, or label and ground. I should mention that point primitives have a different pipeline that labels and billboards, and the fixes that were recently applied to the latter were not applied to the former)

[rileyhowley]

This was the result of `VerticalOrigin.BOTTOM`

When I remove the PointPrimitive the label hides behind the terrain unless I look birdseye view then it gets clipped.

So the Issue, I believe may be the Point not being clipped behind terrain, so thats why it looks like the label is being clipped But the label also clipped in birdseye view

Is there a way to make the Point do what the label does, or can you recommend something better to achieve what I am doing

Cheers

[mzschwartz5]

Hmm - without the point primitive, the label itself seems OK to me.

Also the text size seems to make a difference.

Also, I don’t know if this is feasible for your use case, but here is a completely different option:

PinBuilder approach.

[rileyhowley]

Hmm with the text size I am still able to reproduce the error. Can I ask why the Point Primitive works differently then the label?

Is there any hack I can make to the label so that it ignores the terrain overlap, so my clusters labels
are not hidden when the circle is still visible.

We don’t use the Pins as that doesn’t match the designs. Bit stumped atm

[mzschwartz5]

Can I ask why the Point Primitive works differently then the label?

If you find out the answer to this, I’d love to know as well. It’s a separate but parallel pipeline with lots of overlapping functionality.

Even so, I don’t think the differences between them are a factor here. What’s going on is (simplified a bit): at close proximity, the whole point or label has to be occluded for any of it to be occluded. Since the point is bigger than the label, the label crosses the full-occlusion threshold before the point does.

That’s unfortunate here and I can’t think of a way around it. (I can think of settings we can expose to change that behavior, but that doesn’t help much here and, overall, this API needs to be easier to get what you want from it..)

Could you maybe open up an issue in the CesiumGS repo?

[rileyhowley]

Yeah I will, manage to by pass it with a random depth test for like 40000, still buggy but would at least let us move forward potentially. I will raise an issue