-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels/billboards on terrain and depthTestAgainstTerrain #2694
Comments
Was this addressed by the |
Yes, it's still a problem. For example, if you have a label on the side of a mountain. Its possible to rotate so the part of the label fails the depth test with the mountain. |
Here's exactly what @bagnell is talking about. Hopefully something we can address sooner rather than later. (along with other label/depth improvements). |
Reported in this post: https://groups.google.com/d/msg/cesium-dev/mm2Xipqbp-g/AoSvaHcUAQAJ |
CC #2160 |
Also came up in this forum post: https://groups.google.com/d/msg/cesium-dev/Z68H4SHnAAY/MzQTuxkQDAAJ |
@jburr-nc no time frame for this exact fix, but check out Label.disableDepthTestDistance, which can be used to fix this. |
@pjcozzi Thanks for the tip! That worked! |
Discussed a bit offline with @bagnell today. @bagnell said he already tried this, but I still think we should re-investigate something like checking the center and corner points of a billboard/label against the depth buffer in the vertex shader, and then "passing depth" (e.g., not pushing in front of the near plane to clip it) if all (or maybe |
Unsure if this is related or not, but is anyone else experiencing 3D dome shapes distorting KML data sources? |
I'm currently combining |
I like the "whole entity" idea. I've encountered more than one project where they want an all-or-nothing test for visibility of the entity (point, billboard, and label, together). If the entity's single location is exposed to the camera, then the point+billboard+label graphics should be visible in their entirety, unfettered by depth-buffering. But if the entity is obscured, even just hidden behind a small hill, then the point+billboard+label graphics are turned off completely. At no time is a partial label or partial marker symbol (billboard) ever shown to the user, nor a marker without a label or vice-versa. Essentially, the 2D elements don't need to participate in the 3D scene at all, beyond yes-or-no knowledge of whether the object they represent is visible within the scene, and its screen-space location. Points, billboards, and labels in such a system could even be moved to a separate render pass where FXAA was not applied to them, which would be an added win. |
I had two thoughts about this. Being able to designate entities as all-or-nothing, at the top level, would be a helpful feature, for the reasons you've laid out. But I also think that certain 2D graphical elements should be excluded from individual depth testing, as you've described, either behind an option or as a global rendering engine change. I can't think of a reason anybody would ever want a billboard or label to be partially obscured by terrain (though of course I wouldn't say it's impossible), so at the very least the default behavior should be to avoid doing this. |
Yes, every time I think about this, I can't imagine a valid reason why a user would want per-fragment visibility testing of 2D elements (points/billboards/labels). They either want all fragments of all the available 2D elements for a given entity, or none. |
Came up again on the forum: https://groups.google.com/forum/#!topic/cesium-dev/73iP8rzzGuU |
Came up again on the forum: https://groups.google.com/forum/#!topic/cesium-dev/kQiuFbnTpSQ |
Congratulations on closing the issue! I found these Cesium forum links in the comments above: https://groups.google.com/d/msg/cesium-dev/mm2Xipqbp-g/AoSvaHcUAQAJ If this issue affects any of these threads, please post a comment like the following:
I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome. 🌍 🌎 🌏 |
Your billboard is not clamped to the ground. Add |
@thw0rted Awesome!Thank you. |
I am getting error normalized result is not a number while set Here are my complete code
|
Can you dump your entity definition and post it here? Like, |
Thanks for reply @thw0rted . |
I haven't tried setting this up after the fact, have you tried making an entity with constructor options for the polygon definition, rather than making the entity then altering its polygon on the fly? |
@munna can you please put together a Sandcastle example to reproduce the issue? https://cesiumjs.org/Cesium/Build/Apps/Sandcastle/ |
@hpinkos I have created here Sandcastle URL to reproduce but i am not getting same issue. but got another two issue.
|
hello, I want to ask if the problem of pickPositionSupported is not supported under IE. |
I think you want to set the polygon's height reference to be CLAMP_TO_GROUND and perPositionHeight to false, and set the extrusion's height reference to RELATIVE_TO_GROUND. Here's your example with those changes.
|
@GatorScott , Thank you very much . its working as expected. |
When labels/billboards are clamped to terrain, they require
depthTestAgainstTerrain
to befalse
so they do not sink into terrain. However, this allows 3D models and extruded geometries, for example, to come through terrain.@bagnell and I have brainstormed a few ideas like using an extra depth buffer or stenciling. We're hoping for something simpler though.
The text was updated successfully, but these errors were encountered: