-
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
pickPosition isn't accurate when depthTestAgainstTerrain is false #8179
Comments
Initial attempt using the primitive color framebuffer is here. I'm abandoning this approach since it doesn't support depth-only commands: https://github.com/AnalyticalGraphicsInc/cesium/tree/fix-pick-position Started a second approach that executes the globe depth copy during a second depth plane pass here: https://github.com/AnalyticalGraphicsInc/cesium/commits/fix-pick-position-2 |
Hello, any update on this ? Is there some workaround ? Thank you very much ! |
This came up on the forum as well: https://community.cesium.com/t/scene-pick-returning-point-inside-the-globe/18940 |
Any update? |
This is a duplicate #4368. Closing to consolidate reports. |
When
globe.depthTestAgainstTerrain
is falsepickPosition
will pick the depth plane instead of the globe. You can test it out in this sandcastle.The discrepancy will get even worse once we push the depth plane to fix #7879. I have some ideas for getting
pickPosition
to work regardless ofdepthTestAgainstTerrain
...GlobeDepth
will need to get composited intoPickDepth
.GlobeDepth
stores the globe depth before it gets cleared whilePickDepth
stores the depth after all passes have been rendered. We'll need a command that writes globe depth back into pick depth but only where pick depth isn't set. So if someone does pick position on an object under terrain it will still pick that object but everywhere else it will pick terrain.This would normally require a copy texture because the pick depth is both read/write, but we may be able to use the stencil bit being added to #4381 to avoid that. In this case the framebuffer's depth attachment would be
GlobeDepth
's depth-stencil texture, its color attachment would be the pick depth (which is not actually a depth texture), and it's texture uniform would beglobeDepthTexture
, which like pick depth is not a depth texture but a color texture with packed depth values. The shader would be a passthrough shader and the render state would be color writes, no depth writes, and stencil test. With this approach I'm hopinggl_FragDepth
is not involved.I'm a little concerned about translucent objects. Those objects will write the stencil bit to avoid getting overdrawn in #4381 but it actually should overdraw in this depth compositing. Maybe there need to be two stencil bits (color overdraw vs. depth overdraw) based on whether the command writes depth.
The text was updated successfully, but these errors were encountered: