Compute light attenuation using Beer's law

[issam3105]

Objective

Fix volume attenuation for glTF materials using KHR_materials_volume.

Bevy was converting attenuationColor with pow(1.0 - color, E) to reuse the existing fog math atmospheric_fog() , which under-attenuates transmitted light. This makes dark volume materials render too bright.

I first tried to keep the existing structure and only fix the coefficient passed to atmospheric_fog() (first commit). Since that function attenuates with:

transmittance = exp(-be * distance)

and KHR_materials_volume defines attenuationColor as the transmittance after attenuationDistance, solving:

attenuationColor = exp(-be * attenuationDistance)

gives:

be = -log(attenuationColor) / attenuationDistance

After discussing this with @coreh, I switched to applying the volume attenuation directly instead of routing it through the fog abstraction.

Solution

• Apply the Beer's law for transmittance from the Khronos Sample Renderer directly in the transmission path:

transmittance = attenuationColor ^ (transmissionDistance / attenuationDistance)
radiance *= transmittance

• thicknessTexture is now loaded as a linear data texture, since its G channel stores thickness rather than color.

Testing

Reviewers can test visually by loading the Khronos AttenuationTest and DragonAttenuation assets

Showcase

Before PR

After

Ref Khronos

Before

After

Ref Khronos

[coreh]

Hmm... I don't remember it exactly, but I suspect I might have wanted to reuse the existing fog math instead of implementing it separately, as the original transmission PR was already quite large

This seems more correct and if it matches the reference renderings better, I'm all for it

Edit: Actually I misread your explanation, looking at the code it's still reusing the fog math.

I'm not sure why I went with this one instead. Might have been a mistake or misunderstanding of some paper on my part?

[issam3105]

Actually I misread your explanation, looking at the code it's still reusing the fog math.

I'm not sure why I went with this one instead. Might have been a mistake or misunderstanding of some paper on my part?

Thank you for checking.

I first tried to keep the existing approach by only adapting the coefficient used with atmospheric_fog(), but I agree that tying glTF volume attenuation to the fog abstraction makes the intent less clear.

I pushed an update that applies the Khronos Sample Renderer formula directly in the transmission path. This avoids relying on fog internals and makes the code closer to the KHR_materials_volume reference implementation.

[mardzie]

The Rust code looks fine. I am not familiar with WGSL and the math, someone with that expertise should also review.

[ecoskey]

Wgsl/math looks good! Always good to catch little errors like these in our volumetrics math.

Just for context, can you explain the addition to get_linear_textures? Were we not keeping track of the thickness texture at all, or just not as a linear texture?

[issam3105]

Just for context, can you explain the addition to get_linear_textures? Were we not keeping track of the thickness texture at all, or just not as a linear texture?

We were keeping track of it, but not as a linear texture. Before this fix, I noticed that the Thickness Texture row in Khronos' AttenuationTest sample was lighter than the other rows:

[coreh]

LGTM