Summary: | REGRESSION(ANGLE/Metal): z-fighting with low camera near range | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | remi from barney <remi> | ||||
Component: | WebGL | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED DUPLICATE | ||||||
Severity: | Major | CC: | dino, geofflang, gman, gsnedders, jonahr, kbr, kevin_neal, kkinnunen, kpiddington, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | Safari Technology Preview | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Attachments: |
|
Description
remi from barney
2021-09-13 06:42:07 PDT
Hi Sam, thank you for renaming my issue. Does the "REGRESSION(ANGLE/Metal)" means that you already know this bug and that it will be fixed in the future? I'm kind of confused. 😅 (In reply to remi from barney from comment #1) > Does the "REGRESSION(ANGLE/Metal)" > means that you already know this bug and that it will be fixed in the > future? I'm kind of confused. 😅 Thank you for the report! We're investigating the source with the assumption that it's a regression from OpenGL-based implementation. Submitter: it turns out this rendering artifact is happening on Chrome on macOS, too. It looks like when ANGLE is used as the WebGL backend it may be more strict about allocating depth renderbuffers with a specific precision (e.g. 16-bit vs. 24-bit). See the difference between these two runs: (artifact) /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --user-data-dir=/tmp/c1 --use-cmd-decoder=passthrough vs. (no artifact) /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --user-data-dir=/tmp/c1 --use-cmd-decoder=validating Can you provide the entire sources for this, unminified, in a way that we can easily modify them? Do you or Three.js allocate your own renderbuffers or textures? The solution will probably be to upgrade your sources to stop using DEPTH_COMPONENT and use instead the sized formats like DEPTH_COMPONENT24 in WebGL 2.0. Created attachment 438114 [details]
Sources of the buggy demo
Hello Ken, you can find the source above. I asked the ThreeJS team about the DEPTH_COMPONENT on the ThreeJS issue. 🙏 Thank you for your help. Hi Remy, and others. Got some good news for you regarding this bug. This is indeed a depth-precision issue. However, we were having issues with D16Unorm formats in other parts of ANGLE as well, mostly related to setting a depth bias. You can read more about that bug here. https://bugs.chromium.org/p/angleproject/issues/detail?id=6597 Regardless, the end result is that we've upped all depth buffers to 32 bit floating precision in more recent versions of the WebGL backend when using metal. This seems to have fixed your demo's issue. This change was included in this Webkit patch: https://bugs.webkit.org/show_bug.cgi?id=220896 *** This bug has been marked as a duplicate of bug 220896 *** |