Some meshes not rendering in 0.16-rc.1

[alec-deason]

Bevy version

0.16-rc.1

[Optional] Relevant system information

Linux, wayland (sway) and maybe also xwayland, intel gpu

2025-03-25T20:49:12.292198Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "Linux (Arch Linux rolling)", kernel: "6.13.8-arch1-1", cpu: "Intel(R) Core(TM) i7-8650U CPU @1.90GHz", core_count: "4", memory: "23.2 GiB" }
2025-03-25T20:49:12.634849Z  INFO bevy_render::renderer: AdapterInfo { name: "Intel(R) UHD Graphics 620 (KBL GT2)", vendor: 32902, device: 22807, device_type: IntegratedGpu, driver: "Intel open-source Mesa driver", driver_info: "Mesa 25.0.2-arch1.2", backend: Vulkan }

What you did

Updated to 0.16

What went wrong

After updating to 0.16 some meshes from gltf models began to intermittently appear and disappear. I also saw some other glitches (#18542 ) which may or may not have the same root cause. In my full game the flickering meshes seem to respond to camera motion. They will be present when the camera is in one position and absent in another. Changing window size also seems to trigger the flicker. In the attached minimal example there is no camera motion but the missing meshes are repeatably missing. In my full game I have seen this issue when running directly on wayland and also under xwayland but in the minimal example I have only gotten it to reproduce when running directly in wayland.

Additional information

This screenshot demonstrates the issue. All the eyes are the same gltf model, the only difference is the x-y coordinates they were spawned at. There is a clear pattern in which ones are missing the eyelids and which ones aren't which wasn't noticable in the program this was extracted from, likely because things in that version are spawned in a more or less random order.

A minimal example that reproduces the issue for me when run on wayland is attached.

example.zip

[alec-deason]

I still can't get the minimal example to reproduce the problem in xwayland and I can't get renderdoc to capture frames under native wayland but here is an example frame from a somewhat minimized version of the full game showing the issue in xwayland.

example.rdc.zip

I don't fully understand what's happening here but I see that the scene has rendered as I expect it to in event 129 on the timeline but then in 134 if reverts back to the way it looked in 128, erasing the eyelid mesh that rendered in 129.

[kristoff3r]

I was able to reproduce on Linux/X11 with the given example, and I have bisected the problem to #17698.

[alec-deason]

I poked at it a bit more and found that removing the morph targets from the mesh makes the symptoms go away. When the morph targets are present the correct meshes are still drawn they just aren't in the right locations.

[tychedelia]

Did some investigation, and was able to discover some things.

First, what's basically happening is that when meshes are getting culled on the CPU, but the mesh instance that's getting removed on the GPU is seemingly incorrect. For example:

I've dragged the window here to cover the bottom row, but 2 of the eyelids that get removed are on the top row. You can replicate this with any row size, for example with 10x10 we'd see 10 eyelids getting removed. However, importantly, this seems to be pretty deterministic. When I restart the program, the same eyelids are always removed.

This suggests there's some kind of indexing error in how our mesh instances are getting written out to the GPU. I've confirmed that the instances we keep on the CPU are correct, and so I'm not totally sure what's happening.

It's also possible to break things more extremely:

This happens when resizing the windows such that all of the meshes are culled. Even when moving pretty slowly, they can be left in states with weird broken transforms.

Have to stop here for tonight.

@alec-deason Would you mind uploading the version without morph targets?

[alec-deason]

Sure. This is exactly the same model except that I deleted all the shape keys in blender and reexported it.

eye.zip

[extrawurst]

just came out of my rabbit hole to realize I ran into the same issue: #18736 let me know if you need more example meshes for this :)