Skip to content

Renderable entities with non-renderable parents can break z-order for unrelated entities #6366

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jabuwu opened this issue Oct 25, 2022 · 4 comments
Labels
C-Bug An unexpected or incorrect behavior

Comments

@jabuwu
Copy link
Contributor

jabuwu commented Oct 25, 2022

Bevy version

0.8.1

Relevant system information

Bug appears on both OS X and Windows. Does not occur on WASM.

`AdapterInfo { name: "Apple M2", vendor: 0, device: 0, device_type: IntegratedGpu, backend: Metal }`
`AdapterInfo { name: "NVIDIA GeForce GTX 1050 Ti", vendor: 4318, device: 7298, device_type: DiscreteGpu, backend: Vulkan }`

What you did

I have a red SpriteBundle (with the default texture), and a black MaterialMesh2dBundle (with Quad/ColorMaterial).

commands.spawn_bundle(SpriteBundle {
    sprite: Sprite {
        custom_size: Vec2::new(300., 75.).into(),
        color: Color::RED,
        ..Default::default()
    },
    transform: Transform::from_xyz(0., 0., 1.),
    ..Default::default()
});

let mesh = Mesh::from(Quad::new(Vec2::splat(100.)));
let mesh_handle = meshes.add(mesh);
commands.spawn_bundle(MaterialMesh2dBundle {
    mesh: Mesh2dHandle(mesh_handle),
    material: materials.add(ColorMaterial::from(Color::BLACK)),
    transform: Transform::from_xyz(0., 0., 0.),
    ..Default::default()
});

The red sprite has z of 1.
The black mesh has a z of 0.

The expectation is that the sprite will render above the mesh.

Screen Shot 2022-10-25 at 2 12 19 AM

What went wrong

Adding a seemingly unrelated hierarchy causes the z ordering of these two entities to become unpredictable.

commands
    .spawn_bundle((
        Transform::from_xyz(0., -200., 0.).with_scale(Vec3::ONE * 0.5),
        GlobalTransform::default(),
        Visibility::default(),
        ComputedVisibility::default(),
    ))
    .with_children(|parent| {
        parent.spawn_bundle(SpriteBundle {
            sprite: Sprite {
                custom_size: Some(Vec2::new(32., 32.)),
                color: Color::BLUE,
                ..Default::default()
            },
            ..Default::default()
        });
    });

Now, sometimes, the black mesh will appear above the red sprite. The order doesn't change at runtime and requires restarting the application, occurring about 50% of the time.

Screen Shot 2022-10-25 at 2 15 52 AM

Adding a SpriteBundle to the parent, or removing the SpriteBundle from the child causes the bug to disappear. Changing the child to use a mesh instead of a sprite also fixes the issue.

Additional information

Repro: https://github.com/jabuwu/bevy_z_issue

@jabuwu jabuwu added C-Bug An unexpected or incorrect behavior S-Needs-Triage This issue needs to be labelled labels Oct 25, 2022
@alice-i-cecile alice-i-cecile added A-Hierarchy and removed S-Needs-Triage This issue needs to be labelled labels Oct 25, 2022
@tim-blackbird
Copy link
Contributor

This is a weird one! Can definiteley reproduce.
It happens when adding the blue sprite on its own, so I think it's unrelated to the hierarchy.

@jabuwu
Copy link
Contributor Author

jabuwu commented Oct 25, 2022

Oh yeah, you're right. I did try that but it's sort of random so I guess I missed it. The original title isn't correct then, and this seems to have more do with sprites and meshes not ordering properly.

@rparrett
Copy link
Contributor

Could you please test on bevy main? I think this was likely fixed by #5942

@jabuwu
Copy link
Contributor Author

jabuwu commented Oct 25, 2022

Oh, good call, yes it seems to be fixed in main 👍

@jabuwu jabuwu closed this as completed Oct 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-Bug An unexpected or incorrect behavior
Projects
None yet
Development

No branches or pull requests

4 participants