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: NEW ---    
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   
Description Flags
Sources of the buggy demo none

Description remi from barney 2021-09-13 06:42:07 PDT

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
Comment 1 remi from barney 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. 😅
Comment 2 Kimmo Kinnunen 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.
Comment 3 Kenneth Russell 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:

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --user-data-dir=/tmp/c1 --use-cmd-decoder=passthrough


(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.
Comment 4 remi from barney 2021-09-14 01:39:28 PDT
Created attachment 438114 [details]
Sources of the buggy demo
Comment 5 remi from barney 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.
Comment 6 Radar WebKit Bug Importer 2021-09-15 10:01:20 PDT