macOS intel with integrated gpu - strange shadows artefacts

[mockersf]

Bevy version

Current main de8edd3

Operating system & version

macOS on an intel mac with an integrated GPU
not reproduced on an intel mac with a AMD Radeon Pro 5300M or on an arm mac

What you did

cargo run --example 3d_scene_pipelined --release

What you expected to happen

To have it display properly

What actually happened

shadows-macos-intel-integrated.mp4

Additional information

I captured a gpu frame on the intel mac, loading it on the arm mac removes the artefacts from the frame

[adsick]

looks kinda nice tho

[superdump]

The lines kind of seem to be related to the edges of triangles, as if they have something to do with rasterisation or MSAA or something. The shadow maps don't use MSAA though... What happens if you disable MSAA?

[superdump]

I poked cwfitzgerald (wgpu) about this and it's apparently similar to an issue filed against the wgpu shadow mapping demo but that seems to be a driver issue when using array textures for shadow maps: gfx-rs/wgpu#103

[Davier]

There is another MSAA issue with an intel integrated gpu (but on linux) in #3593

[luisbg]

I can repro this issue. Let me know if I can help by triaging or testing a fix.

I've reproduced it in up to date in the latest and main branches.

[nfagerlund]

Here's something interesting:

• I get this bug on a 2013 13" macbook pro with "Intel Iris Graphics".
• I DON'T get it on a 2020 13" macbook pro with "Intel Iris Plus Graphics".

Both machines are running MacOS Big Sur 11.6.5. This is with the "lighting" example from Bevy's v0.6.1 tag.

[DerKarlos]

I do have the same bug (also Issue #3423)
2018 13" MacBook Air with "Intel UHD Graphics 617"

There is no bug if I use crate rend3, also using wgpu. (may not be the same version)

[DerKarlos]

Correction: I also have trouble with rend3 and shadows, since some days/weeks. So it may have been caused by a macOS update.
The "funny" thing: This bug is NOT with WebGL/WebCPU Wasm build, only native OpenGL or what ever is used.

[Jacob-JB]

I've got the same issue and my research found this [https://github.com/gfx-rs/wgpu/issues/103] if that helps anyone.

[preland]

I can also confirm that I have this issue, although the results look..... slightly different than the original
This could be because I slightly modified the example code so that it would compile with my version of bevy, but I am unsure

AdapterInfo { name: "Intel(R) Iris(TM) Plus Graphics 645", vendor: 0, device: 0, device_type: IntegratedGpu, backend: Metal }

3d.scene.pipeline.mac.intel.integrated.graphics.mov

[preland]

Ok, some interesting developments upon further analysis:

As a quick note, I switched to using the most up to date example version, which has slightly different results than the comment above, but has very similar artifacts (video below):

lighting.control.mov

While these issues seemed to be caused by driver bugs before, I am less certain that this is the case now. I can render the wgpu example projects without issue, which was surprising to me. I tried to render some of the other example Bevy projects, and those..... also worked fine! (Specifically, load_gltf, update_gltf_scene, and pbr)

This was quite confusing, to say the least, but I quickly figured out that the issue is, as far as I can tell, completely isolated to the PointLightBundle implementation, but only the blue and red channels. The green channel is ok.

The below videos, in order, are lighting.rs with 1. the point lights removed (I don't see any issues here), 2. The red point light added back in, 3. The blue point light added back in, and 4. The green light added back in (again, I don't see any issues with this channel!). Note how the red and blue channels have their own "flavor" of glitchy-ness.

I don't personally know what to do to address this, but the issue now seems to be much better scoped than before, so hopefully someone will know what needs to be fixed.

lighting.no.point.lights.mov

lighting.red.channel.mov

lighting.blue.channel.mov

lighting.green.channel.mov

P.S. There may also be issues with the ambient lighting, but since I don't know what the ambient lighting is supposed to look like, I can't be sure

[preland]

Update: The issue actually has nothing to do with the green channel color. After some more testing, the green channel is also bugged. The example lighting project has the green light implemented as a spotlight instead of as a pointlight. None of the color channels in spotlight are bugged, as far as I can tell. The issue is entirely related to the pointlight, and the graphical bug is so bad, that it entirely renders the PointLight entity useless for Intel integrated graphics Mac.

I am considering opening a separate issue for this, as this bug seems to be an entirely different issue. However, I am hesitant to do so, as new issues relating to integrated graphic shadow issues tend to be closed quickly, referring back to this issue.

[mockersf]

If you're very convinced there are two unrelated issues, you can open a new one 👍 Though it may look different from the first message mostly because Bevy changed a lot since.

But I'm not sure it will help... to my knowledge, not many people on rendering are trying to fix it or even have a Mac with an integrated graphic card around

[preland]

I spent some time looking at the code myself, and I’m still not sure what’s causing it. I think that it has something to do with garbage info being sent into the shadow rendering function for point lights (fetch_point_shadow, I think).

Though, it’s really weird. Tinkering with the function either results in the shadows not rendering or them rendering in extremely buggy ways.

[alinanorakari]

I'm adding to this as an affected dev. With Bevy 0.10.0 it looks even wilder on my Intel(R) Iris(TM) Plus Graphics 655 than the above examples

The shadow map from the circling light source rotates with its motion and seems to collect ghost images like a buffer that's not being cleared before the next frame is drawn

Also in animated_fox

… as if there were gradient masks (based on distance from a light source?) that uncover even more broken shadow maps.

I hope somebody finds a solution because Bevy otherwise looks like what I want and I have no other computer for game dev

[preland]

Until this gets fixed, the only real solution is to avoid using point lights in your projects (I haven’t looked at this issue for a while, so I’m assuming that the issue is still isolated to point lights)

This doesn’t just apply for Intel Mac developers either—any game designed to be playable on non-M1/2 MacOS should avoid using point lights, or else your game will suffer from the same rendering artifacts as the ones seen in this issue thread.

Alternatively, if someone were to take the code from one of the other light sources and modify it to work as a point light, that would also work as a fix.

[superdump]

The circling light in the lighting example is a directional light. I think the light in the animated_fox example is also a directional light. Just noting this as I’m not sure why not using point lights would help with directional light issues.

[superdump]

Could someone retest on macOS 13.3?

[alinanorakari]

I tested on macOS 13.3 and didn't see a change. Still the same artifacts in lighting and animated_fox.

[donkey-donkey]

Tested on 13.3.1
Same lighting and shadow artifacts running the 3d example files.

[teoxoy]

Could someone try to repro this with one of wgpu's examples (for gfx-rs/wgpu#103) and share their findings in that issue?