Flickering when using AlphaMode::Blend in Bevy

1

I'm creating a 3d model in Bevy from a list of triangles (of predefined colours, some of which have transparency). I'm spawning a PbrBundle for each colour of triangle as follows:

commands.spawn(PbrBundle {
    mesh: meshes.add(mesh),
    material: materials.add(StandardMaterial {
        base_color: color,
        cull_mode: None,
        double_sided: true,
        alpha_mode: if color.a() < 1. {
            AlphaMode::Blend
        } else {
            AlphaMode::Opaque
        },
        ..default()
    }),
    ..default()
});

However, using AlphaMode::Blend means that when looking through a translucent material into another translucent material, there is constant flickering (no matter if the camera is moving or not). This can be fixed by using AlphaMode::Multiply or AlphaMode::Add, but these produce effects I don't want (too bright or too dark).
When I was researching this problem I found a forum post which mentions that this is an inherant issue with alpha blending, so I'm wondering if there is a workaround that doesn't make things too bright or dark and removes the flickering.

2

The usual workaround is sorting meshes so they draw back-to-front. This avoids the issue with depth (or lack of) and transparent meshes. The process is described here: Tutorial 10 : Transparency (opengl-tutorial.org)

The search keyword of interest is "order independent transparency". Some of the results I found are below:

The relevant bevy issue is Transparency improvements · Issue #2223 · bevyengine/bevy (github.com)

1 Like
3

Depth sorting of meshes and order-independent transparency are two different techniques.

  • Sorting meshes is done before rasterization, and is insufficient when the meshes might overlap in complex ways, but only needs to be computed once per frame. It's the older technique, as it (or implicit sorting via BSP trees) was used in CPU-driven renderers (that did not have cheap depth buffering/testing) to figure out what order to draw things in.

  • Order-independent transparency refers to a variety of techniques, but what they have in common is that they don't require sorting the meshes (hence “order-independent”); instead they take in the per-pixel information produced by triangle rasterization, in whatever order those triangles might be drawn, and compute the desired blended result from only that information.

1 Like
4

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.