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
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:
/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --user-data-dir=/tmp/c1 --use-cmd-decoder=passthrough
/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.