SDF generation demo causes pink flashing in multiple screen regions on MacBookPro M1 (Chrome)

[utensil]

Describe the bug

SDF generation demo causes pink flashing in multiple screen regions on MacBookPro M1, even after I close the browser tab, quit Chrome, the issues persists.

It doesn't happen to my iPhone 12 Pro (Chrome).

To Reproduce

1. Go to https://gkjohnson.github.io/three-mesh-bvh/example/bundle/sdfGeneration.html in Chrome on Mac M1
2. The page shows the control UI, then massive incorrect render, then pink flashes in irregular shape in the browser bar, then the pink flashes takes more areas of the screen, particularly the apps that are likely using GPU rendering e.g. my widgets on the desktop. The render of other apps will stay normal for a few seconds, then back to pink, then back to normal, repeatedly, in a rather random frequency, location, and shape.
3. I'll have to restart the Mac to recover, but when I visit the link again, it will start all over again. I've tried to close all other apps, but it still happens.

Expected behavior

Normal render, and if the render fails, it doesn't cause issues outside the browser tab.

Screenshots

[will provide if I manage to take one]

Platform:

• Device: Desktop
• OS: MacOS 14.4.1 on Apple M1 Pro 16-inch, 2021
• Browser: Chrome
• Three.js version: the one in the demo
• Library version: the one in the demo

** Additional comments: **

It's amazing work, including the path tracer, thanks for creating them! This is issue is likely triggering some bug in Chrome or even metal, but I have no clue about why this would happen. I've read the source and the demo seems to be using special extensions which could be less stable. I've searched for this issue, but it doesn't seem to happen to other Mac users, "pink screen" leads to issues causing full screen pink and kernel panic, unrelated to this issue.

I've also looked it up in the issues if this repo, #497 and #717 seem to be related, and the solution seems to require identifying under what condition this would happen and use an alternative (possibly downgraded) rendering technique to keep it normal.

[utensil]

I have difficulty taking screenshots, as the screenshot apps seem to be unable to see the pink flashes. This is the best I can do, showing broken browser bar in gray:

Another one, showing it affects another browser tab with some WebGL on it, the WebGL canvas is also flashing, but shows black in the screenshot:

Some more observations:

1. Safari doesn't have this issue, it just fails to render
2. The pink flashes only happen when my Mac is connected to external displays, and only would it persist after quitting Chrome if it is connected to external displays; when it's not, the flashes are gray instead of pink, and it doesn't affect areas outside the browser.

[gkjohnson]

Thanks - I can reproduce it on my machine, as well. It seems to only happen when the 3d texture is above a certain size? Or a moderately complex model (it wasn't happening with another triangular test model)? And it happens with array textures, as well.

I've removed the newly-added raycasting logic from the shader to determine containment for now since that addresses the problem. But it's hard to see this as anything other than a browser issue related to 3d textures (See #497, too). If you'd like to submit a bug report to chrome that would be appreciated.

cc @zalo I'm thinking the WebGPU compute shader approach would be better if we want to generate SDF textures quickly.

[zalo]

Yeah; it probably is… I can’t wait until browsers actually have WebGPU enabled! 🫠

[gkjohnson]

I can’t wait until browsers actually have WebGPU enabled! 🫠

It's already enabled in Chromium-based browsers, including mobile, and it can be enabled via flags in Firefox and Safari. As far as I can tell the WebGPU API is stable so I'd say it's a fine time to build something with it:

https://caniuse.com/webgpu

Three.js development on a WebGPURenderer with a WebGL fallback is already well underway and a number of projects out there are already using it. I've been wanting to get something going with compute shaders in this project I just have too many other things I need to work on 😅 Happy to collaborate on a contribution if it's something you're interested in starting. The WebGPU buffer can be read back to the CPU and used in WebGL.

An alternative workaround might be to render the 3d z-layers to a grid on a 2D texture but this will limit the dimensions of the SDF and make sampling more complicated. I just checked and this doesn't cause any of the corruption issues.

[utensil]

If you'd like to submit a bug report to chrome that would be appreciated.

Chrome issue submitted as https://issues.chromium.org/issues/370153438 .

[utensil]

But then I realized that the page now is fixed by working around it, anyway I can provide a link that still reproduces the issue?

[gkjohnson]

I've added a condition that includes the lines that break the shader when #USE_SHADER_RAYCAST is included in the location hash:

https://gkjohnson.github.io/three-mesh-bvh/example/bundle/sdfGeneration.html#USE_SHADER_RAYCAST

You can use that link to repro the issue. Thanks for submitting!

[CodyJasonBennett]

As far as I can tell the WebGPU API is stable so I'd say it's a fine time to build something with it:

FWIW WebGPU specification is not a living draft yet and will be subject to breaking changes until then.

An alternative workaround might be to render the 3d z-layers to a grid on a 2D texture but this will limit the dimensions of the SDF and make sampling more complicated. I just checked and this doesn't cause any of the corruption issues.

A workaround to the DirectX issue is rendering each slice to a 2D texture and doing a GPU -> GPU copy to a 3D layer. Perhaps, that would solve both issues?

[gkjohnson]

FWIW WebGPU specification is not a living draft yet and will be subject to breaking changes until then.

Thanks - I didn't know this. I figured since it was no longer behind a flag it was considered stable. All the same any work done now I think will still be worthwhile start even if things change a bit.

A workaround to the DirectX issue is rendering each slice to a 2D texture and doing a GPU -> GPU copy to a 3D layer. Perhaps, that would solve both issues?

Interesting - didn't know this. Do you have an example of how this is done? Do you mean basically doing a render with a pass-through shader of the 2d texture to the 3d texture layer? Or a different block-copying method similar to WebGLRenderer's copyTextureToTexture (but with something like binding the 3d layer to a 2d texture using framebufferTextureLayer before copy)?

[gkjohnson]

mrdoob/three.js#29710 will allow for copying data to and from layers of a 3d texture which will enable us to work around this 3d target rendering issue in the next release - assuming this kind of copying doesn't cause problems, as well.