Spawning a PbrBundle causes gizmo to disappear or flicker

[Seldom-SE]

In this project (using bevy_vector_shapes 0.8)

use std::f32::consts::FRAC_PI_2;

use bevy::{
    color::palettes::css::{RED, WHITE},
    prelude::*,
};
use bevy_vector_shapes::{painter::ShapePainter, shapes::DiscPainter, ShapePlugin};

fn main() {
    App::new()
        .add_plugins((DefaultPlugins, ShapePlugin::default()))
        .add_systems(Startup, setup)
        .add_systems(Update, draw_gizmo)
        .run();
}

pub fn setup(
    mut cmds: Commands,
    mut meshes: ResMut<Assets<Mesh>>,
    mut mats: ResMut<Assets<StandardMaterial>>,
) {
    cmds.spawn(Camera3dBundle {
        transform: Transform::from_translation(Vec3::Y * 10.).looking_at(Vec3::ZERO, Dir3::Y),
        ..default()
    });
}

fn draw_gizmo(mut painter: ShapePainter) {
    painter.rotate_x(FRAC_PI_2);
    painter.hollow = true;
    painter.color = RED.into();
    painter.circle(2.);
}

the gizmo shows up correctly

but if I add a PbrBundle

cmds.spawn(PbrBundle {
    mesh: meshes.add(Cuboid::default()),
    material: mats.add(Color::from(WHITE)),
    ..default()
});

the gizmo disappears

or flickers

2024-07-08.13-36-26.mp4

Here's a repro: https://github.com/BraymatterOrg/bloom_bug_repro/blob/843f674ce2a124ec8592953396e6bcc866eb25c5/src/main.rs
This did work in bevy_vector_shapes 0.7. We've reproed on Linux, Mac, and Windows.

[james-j-obrien]

Very interesting, there were a large amount of renderer changes as part of 0.14 so I'm sure it's related to those changes.

Will take a look when I have a chance, thanks for the report!

[Braymatter]

I wonder if this could be related to the new anisotropy fields/bindings added to the StandardMaterial?

I remember having issues with conditionally compiled stuff in another project and bindings were conflicting on the (new at the time) tessalation fields.

The fact that the gizmo stops working correctly after a StandardMaterial is added to the scene makes me think it's related to something conditionally compiled

[james-j-obrien]

Interestingly your repro doesn't actually show an issue for me which explains how this got released broken.

I'm running windows on this GPU:
AdapterInfo { name: "NVIDIA GeForce RTX 2080 SUPER", vendor: 4318, device: 7809, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "546.01", backend: Vulkan }

That will make this a little tricky for me to diagnose. I'm not sure at the moment why usage of a PbrBundle would affect the rendering at all given that I'm using my own pipelines so my best shot right now is scanning the code for something common I am relying on.

[Braymatter]

Here is my machine's info which has the issue, this is also an issue on iOS/Android as well:

2024-07-10T20:19:10.349554Z INFO bevy_render::renderer: AdapterInfo { name: "Apple M3 Max", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal }

I suspect there might be some binding conflict somewhere, but looking over the .14 migrations I didn't see anything obvious.

To be clear are you saying the provided repro is working as intended?

[Seldom-SE]

Here's my info on Linux: AdapterInfo { name: "AMD Radeon RX 570 Series (RADV POLARIS10)", vendor: 4098, device: 26591, device_type: DiscreteGpu, driver: "radv", driver_info: "Mesa 24.1.3-arch1.1", backend: Vulkan }
and on Windows: AdapterInfo { name: "Radeon RX 570 Series", vendor: 4098, device: 26591, device_type: DiscreteGpu, driver: "AMD proprietary driver", driver_info: "22.20.27.09", backend: Vulkan }

If there's anything I can do to help, lmk

[james-j-obrien]

To be clear are you saying the provided repro is working as intended?

Yes, for me the shape shows up and displays properly, no flickering at all. You're probably right that it's some kind of binding conflict, but it's very hard to find blindly unfortunately.

[james-j-obrien]

Seems to be a bevy issue, the reason it wasn't repro-ing for me is it requires the multi-threading feature to cause non-deterministic system ordering, otherwise they run in an order that hides the bug.

[james-j-obrien]

Fixed in 0.14.1