Z-fighting is not stable and causes flickering

[stepancheg]

Bevy version

0.11.3

Relevant system information

AdapterInfo { name: "Apple M1 Pro", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal }

What you did

Add three planes of different colors at exactly the same location.

use bevy::app::App;
use bevy::app::Startup;
use bevy::prelude::shape::Plane;
use bevy::prelude::*;

fn setup(
    mut commands: Commands,
    mut materials: ResMut<Assets<StandardMaterial>>,
    mut meshes: ResMut<Assets<Mesh>>,
) {
    commands.spawn(Camera3dBundle {
        transform: Transform::from_xyz(3.0, 3.0, 3.0).looking_at(Vec3::new(0., 0., 0.), Vec3::Y),
        ..default()
    });

    let red = materials.add(Color::RED.into());
    let green = materials.add(Color::GREEN.into());
    let blue = materials.add(Color::BLUE.into());

    for color in [red, green, blue] {
        // Intentionally spawn 3 planes in the same place.
        commands.spawn(PbrBundle {
            mesh: meshes.add(Plane::from_size(2.0).into()),
            material: color,
            ..default()
        });
    }
}

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

Compiled with -O1.

What went wrong

Rectangle is constantly changing color.

I suspect that's because order of rendering is not deterministic.

If it not always easy to make sure that triangles never occupy the same place, so it would be convenient if Bevy rendered these meshes in some deterministic order, regardless of what's that order is. At least if entities did not change.

Attaching screen recording.

Screen.Recording.2023-10-23.at.23.28.51.mov

[alice-i-cecile]

This is an extremely common effect known as "z-fighting". I'm not sure if this problem can or should be automatically be solved: presumably there's a performance cost to doing so?

[alice-i-cecile]

[7:37 PM]pcwalton: I feel like the bug here is not z-fighting per se but rather that our rendering order isn't deterministic
[7:37 PM]robswain: it's because of EntityHashMap i guess
[7:37 PM]robswain: right
[7:38 PM]robswain: the phase needs to also sort by entity index as a tie breaker
[7:38 PM]robswain: then it should be stable

Disussed on Discord by @pcwalton and @superdump.

[robtfm]

you can add a depth bias to control the order:

let red = materials.add(StandardMaterial {
    depth_bias: 1.0,
    ..Color::RED.into()
});

reference

[stepancheg]

@robtfm TIL, thanks!

This partially solves the issue with simple colors (I can just assign random bias to colors), but I believe the issue still exists when textures are used (two planes with the same texture in the same "plane", but one is slightly shifted so planes intersect).

[robtfm]

It should work for texture materials too

[stepancheg]

@robtfm I don't understand.

Users cannot assign different depth_bias to different pixels of texture. So if two planes share the same material, they have the same depth_bias. And I think users are not supposed to create a new material instance per each new mesh.

[robtfm]

If you want to separate two instances you have to give them some different information. So you can either give them slightly different translation depths with respect to the camera, or you can create a different material with a different depth bias for each instance - note that doesn’t mean making a separate texture, so the impact isn’t that bad (and will be close to nothing with material batching for reasonable numbers of entities).

Adding a stable entity-based render order would also work to disambiguate but you lose control over the order unless you also carefully manage your entity creation, which sounds undesirable to me, and adding more sorting won’t be free either.

[stepancheg]

#11248