Closed rparrett closed 1 month ago
That's very odd. I can't reproduce on either my Intel or nVidia GPU machines. Have you only reproduced it on an Apple GPU?
There are two possibilities, as I see it, either on some frames the stencil isn't being drawn or on some frames the depth test with the stencil is going wrong.
Can you try something for me? Add the component OutlineMode::RealVertex
to the torus and see it that makes the issue go away. If it does, that suggests it has something to do with the depth.
Is there something in the MacOS world like RenderDoc?
I have access to a 4070 that I can test with later.
Is there something in the MacOS world like RenderDoc?
Yeah, there's a metal debug tool. I am not very good at using it, but if you can help me out with what to generally look for I might be able to figure something out.
Can you try something for me? Add the component OutlineMode::RealVertex to the torus and see it that makes the issue go away. If it does, that suggests it has something to do with the depth.
Adding OutlineMode::RealVertex
to the torus seems to reliably stop the flickering.
I rented an M1 Mac from Scaleway and can reproduce. The remote desktop connection is very slow and laggy so the artefact more pulses on and off intermittently rather than flickers, but it must be the same thing. Crucially, watching the full orbit of the torus, it only seems to happen when path is close to the camera and this cemented in mind that it must be something to do with the depth values.
I traced the problem with the depths back to the value of instance.origin_in_world
fluctuating. The local variable instance
is assigned the data from the correct element of the mesh
array at the top of the vertex shader and it's then referred to it throughout. I theorise something like the lifetime of instance
causes it to be spilled into lower precision storage, but I haven't dug into any low-level Metal debugging tools. If I change the shader to index the mesh
array at each site where instance data is needed then the artefact goes away.
Does f644e869e353544a2136af3b4340d244530919fb fix it for you too?
Dang, that's above and beyond.
Does https://github.com/komadori/bevy_mod_outline/commit/f644e869e353544a2136af3b4340d244530919fb fix it for you too?
Indeed, yes. Looks good.
I don't really know what I'm doing in here, but I did find some scary looking red stuff.
The main_texture view in the attached screenshots show the torus' transparent outline appearing on top of the mesh (the bug under discussion). Does this mean you managed to reproduce the bug even with the latest code, or are you running the older version again under the Metal debugger?
Regarding the red stuff in your screenshots:
i) It is expected that the origin_in_world
vector is set to NaN when the OutlineMode
is RealVertex
, which it is for the cube in the shapes example.
ii) I'm not sure why attribute index 231 is displayed as being out of bounds. The buffer only has 231 valid entries and so that last index should be 230. This attribute index is not referenced in the index buffer. This same message appears when looking at the draws in Bevy's main opaque_3d pass, so it is not specific to bevy_mod_outline. It might be normal behaviour, or indicative of a bug in Bevy, WGPU, Metal, or the Metal debugger. I've tried digging into it a bit and it's not really become any clearer.
or are you running the older version again under the Metal debugger?
Oh, sorry! Yeah, just running the older version out of curiosity. We're good here.
Released in 0.8.2.
Version tested
Noticed when upgrading from Bevy 0.13 -> 0.14 (
bevy_mod_outline
0.7 -> 0.8) bisected to 8e7bbdb0807e1b63ffe1961600707d72a7535946What I did
cargo run --example shapes
What went wrong
https://github.com/user-attachments/assets/a9c382bb-a891-4a56-aa71-0cf50fa0f37f
Torus is flickering when it is on certain parts of its path
Additional info
I thought this might be related to https://github.com/bevyengine/bevy/issues/14295, but I tested with the linked PR and still saw the flickering.