Skip to content
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

log depth interpolation not handled correctly for large geometries #6573

Closed
likangning93 opened this issue May 8, 2018 · 16 comments · Fixed by #8600
Closed

log depth interpolation not handled correctly for large geometries #6573

likangning93 opened this issue May 8, 2018 · 16 comments · Fixed by #8600

Comments

@likangning93
Copy link
Contributor

likangning93 commented May 8, 2018

Our "big" geometries aren't tessellated enough for log depth to interpolate correctly right now, which causes issues that look kind of like near-plane problems but don't present as a planar cut:

ezgif com-optimize

On Sandcastle

I'm pretty sure it's the "minimum tessellation" problem (described here: http://outerra.blogspot.sk/2009/08/logarithmic-z-buffer.html) because adding #define ENABLE_GL_POSITION_LOG_DEPTH_AT_HEIGHT to the top of vertexLogDepth.glsl seems to fix the problem.

@mramato
Copy link
Contributor

mramato commented May 8, 2018

@bagnell was this a problem pre-log depth? (even if for different reasons). If not, looks like a regression we should fix sooner rather than later.

@likangning93
Copy link
Contributor Author

likangning93 commented May 8, 2018

@mramato I think this was "less" of a problem with multifrustum but it presents like the near-plane issues that log depth was supposed to fix. So I guess it's not technically a regression but it looks like one? heheh...

We've already had at least one other bugfix for log depth and "big" triangles, so this shouldn't be difficult beyond some philosophical questioning.

@themikelester
Copy link

I believe this is also contributing to a problem that I've posted about: https://groups.google.com/d/topic/cesium-dev/kMZIgIa6lqQ/discussion

@likangning93
Copy link
Contributor Author

Related, with depthTestAgainstTerrain:
https://groups.google.com/forum/#!topic/cesium-dev/NZwZnQnmC2U

@hpinkos
Copy link
Contributor

hpinkos commented Aug 9, 2018

@likangning93 that's an issue with polylines, not geometry, so I added a comment to #6741

@ggetz
Copy link
Contributor

ggetz commented Aug 9, 2018

Same for vector tiles.

Brought up on the forum here: https://groups.google.com/forum/#!topic/cesium-dev/WhCZhIUaJIQ

Specifically how you can see this in https://cesiumjs.org/Cesium/Build/Apps/Sandcastle/?src=3D Tiles Terrain Classification.html when zoomed in.

@lilleyse
Copy link
Contributor

This can also happen in the BIM demo. Note how only the floor is getting clipped.

bim-clipping-2

@lilleyse
Copy link
Contributor

Brought up again in #7488.

@mramato
Copy link
Contributor

mramato commented Mar 11, 2019

I run into this constantly with building size BIM/CAD models (floors clip in most views). How hard of a fix is this and can we prioritize it anytime soon?

@OmarShehata
Copy link
Contributor

This has come up again in the case of creating a large clipping plane, see forum thread here. Notice the big missing chunk close to the camera.

clipped_clipping_plane

@OmarShehata
Copy link
Contributor

Another case reported here, trying to simulate flood levels with a large polygon: #7918

flood1
flood2

@likangning93
Copy link
Contributor Author

simulate flood levels with a large polygon

coooooool

@JiaoJianing
Copy link
Contributor

@likangning93 Hi! Sorry to distrub.
How is going now about this bug? I knew Cesium uses log depth buffer from this blog.In this blog it mentions two log depth algorithm version: version 1: Logarithmic Depth Buffer

version 2: Logarithmic Depth Buffer Optimizations and Fixes.
Version 2 seems fix the big geometry issue.
Now Cesium seems to use version 1. Am I missing something?

@likangning93
Copy link
Contributor Author

Hi @JiaoJianing, we still need to take the time to quantify the performance impact for the recommended changes for writing log depth in the fragment shader. This is important since Cesium has to run on so many different platforms, and since we also use the depth buffer for many other effects and features in the engine. In the meantime logarithmic depth is easy to deactivate if it's causing problems for your use case, just use scene.logarithmicDepthBuffer = false; in your code.

@OmarShehata
Copy link
Contributor

@kring kring mentioned this issue Feb 7, 2020
7 tasks
@cesium-concierge
Copy link

Congratulations on closing the issue! I found these Cesium forum links in the comments above:

https://groups.google.com/d/topic/cesium-dev/kMZIgIa6lqQ/discussion
https://groups.google.com/forum/#!topic/cesium-dev/NZwZnQnmC2U
https://groups.google.com/forum/#!topic/cesium-dev/WhCZhIUaJIQ
https://groups.google.com/d/msg/cesium-dev/hsPdXyBATS4/zNF17JkFCAAJ
https://groups.google.com/d/msg/cesium-dev/fXHvE2psXD4/t181NoF1AgAJ

If this issue affects any of these threads, please post a comment like the following:

The issue at #6573 has just been closed and may resolve your issue. Look for the change in the next stable release of Cesium or get it now in the master branch on GitHub https://github.com/AnalyticalGraphicsInc/cesium.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants