Bug 230216

Summary: REGRESSION(ANGLE/Metal): z-fighting with low camera near range
Product: WebKit Reporter: remi from barney <remi>
Component: WebGLAssignee: 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 Flags
Sources of the buggy demo none

remi from barney
Reported 2021-09-13 06:42:07 PDT
Hi, I'm currently working on a ThreeJS viewer and got a big z-fighting problem using iOS 15 beta and Safari Technology Preview on MacOS. To make this as clear as possible, I created a minimalist example: https://demos.barney-technologies.com/webkit_metal_zfighting/example/index.html On older webkit versions it works well, but on the preview version we got this kind of z-fighting: https://imgur.com/a/vPtIMMi We tried disabling WebGL2, but it doesn't change anything. This only disappears when disabling METAL. The problem is mostly visible when using a small camera FOV (here 13), and a low camera near (here 0.01). The more you get away from the model, the more it appears. Using a basic (noop) ThreeJS shader causes the bug to be really more visible. Only thing we could do is increase the near range but it doesn't suit all of our use cases. Is this normal? Is it something you've already see? I feel that it might break a lot of projects already online. :/ A ThreeJS contributor recommended posting the issue here. If it helps, here is the ThreeJS-specific thread: https://discourse.threejs.org/t/rendering-bug-with-metal-ios-macos/29812
Attachments
Sources of the buggy demo (9.46 MB, application/x-zip-compressed)
2021-09-14 01:39 PDT, remi from barney 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
remi from barney
Comment 1 2021-09-13 07:53:35 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. 😅
Kimmo Kinnunen
Comment 2 2021-09-13 11:21:47 PDT
(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.
Kenneth Russell
Comment 3 2021-09-13 11:36:54 PDT
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.
remi from barney
Comment 4 2021-09-14 01:39:28 PDT
Created attachment 438114 [details] Sources of the buggy demo
remi from barney
Comment 5 2021-09-14 01:40:47 PDT
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.
Radar WebKit Bug Importer
Comment 6 2021-09-15 10:01:20 PDT
<rdar://problem/83155657>
Kyle Piddington
Comment 7 2022-02-03 15:41:40 PST
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 ***
Note You need to log in before you can comment on or make changes to this bug.