Materials not displaying correctly in `wireframe` example

[rparrett]

Bevy version

main, bisected to #16799

Relevant system information

SystemInfo { os: "Windows 11 Home", kernel: "22631", cpu: "13th Gen Intel(R) Core(TM) i7-13700KF", core_count: "16", memory: "31.8 GiB" }
AdapterInfo { name: "NVIDIA GeForce RTX 4080 SUPER", vendor: 4318, device: 9986, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "560.94", backend: Vulkan }

What you did

cargo run --example wireframe

What went wrong

Cubes and plane are all red. They should be different colors.

Additional information

This seems to be vulkan specific or perhaps intermittent. The issue isn't present with WGPU_BACKEND=dx12 or on my m1 mac.

First spotted by bevy-example-runner in this run.

[pcwalton]

I investigated this and found that this is because of some strange semantics we were relying on. If you have multiple Material types on a mesh, then it will be drawn multiple times, one for each material type. The Wireframe component exploits this by adding a wireframe material to a mesh, regardless of other materials it might have already had. This breaks the assumption, used throughout rendering, that each main entity maps to at most one mesh instance. The failure we noticed is just the first time it broke, but Wireframe has been fundamentally broken for some time.

There are two main ways I can see to solve this:

1. Change everywhere we key off main entities in rendering to key off a (main entity, material type ID) pair instead.

2. Specify that including Wireframe at the same time as a material is undefined behavior. If you want to fill and draw a wireframe, apps must duplicate the entity, once for the fill and once for the wireframe.

I prefer (2), because (a) I don't want to slow down and bloat rendering just for this one use case; (b) fill-and-wireframe mode is usually used for debugging and so a little pain on the user's side is preferable to slowing down rendering; (c) the current semantics is incompatible with the long-term direction we want to go with for materials, where different shaders map to the same dynamic material type instead of having a separate type for each material. But opinions are welcomed here.

[hukasu]

video on a modified anisotropy example

Screencast_20250204_075622.webm

[JMS55]

@alice-i-cecile how should we handle this for 0.16? Restoring the previous behavior of multiple materials on the same entity is going to be a big change that would need a lot of discussion.

[alice-i-cecile]

I'm okay with simply noting this as a breaking change and fixing the example so it's no longer relying on this behavior.