Skip to content
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

Auto exposure breaks when object is too dark #13446

Closed
GitGhillie opened this issue May 20, 2024 · 2 comments · Fixed by #13562
Closed

Auto exposure breaks when object is too dark #13446

GitGhillie opened this issue May 20, 2024 · 2 comments · Fixed by #13562
Labels
A-Rendering Drawing game state to the screen C-Bug An unexpected or incorrect behavior S-Ready-For-Implementation This issue is ready for an implementation PR. Go for it!
Milestone

Comments

@GitGhillie
Copy link
Contributor

Bevy version

Tested on main commit 2aed777

Relevant system information

Windows 10

AdapterInfo { name: "AMD Radeon RX 7900 XT", vendor: 4098, device: 29772, device_type: DiscreteGpu, driver: "", driver_info: "", backend: Dx12 }

What you did

I have an object with just a base texture and a roughness map, exported from Blender to a gltf and then loaded in Bevy.
I'm using the AutoExposurePlugin with pretty much default settings.

What went wrong

If I place the camera near a dark corner of the mesh, facing the dark corner, the image becomes darker instead of brighter.
You can see what I mean in this video: https://discord.com/channels/691052431525675048/743663924229963868/1242088583108624444

Additional information

Removing the roughness map in Blender and setting the roughness to a fixed value 'fixes' the issue.
You can try it out in this fairly minimal reproduction: https://github.com/GitGhillie/bevy_repro/tree/auto-exposure

The camera will spawn roughly here:
image
Move the camera into the dark corner where the arrow is and you should be able to reproduce the effect.

@GitGhillie GitGhillie added C-Bug An unexpected or incorrect behavior S-Needs-Triage This issue needs to be labelled labels May 20, 2024
@alice-i-cecile alice-i-cecile added A-Rendering Drawing game state to the screen and removed S-Needs-Triage This issue needs to be labelled labels May 20, 2024
@alice-i-cecile
Copy link
Member

FYI @Kurble, in case you have any ideas or are interested in putting together a fix :)

@Kurble
Copy link
Contributor

Kurble commented May 21, 2024

Increasing the AutoExposureSettings::range to -16.0..=16.0 will also fix the issue for this scene. It can be quite tricky to get auto exposure right, we might need some diagnostic tools for it, such as a widget to render out the histogram.

When all samples are out of range (too dark), the shader now targets 0.0 (no correction) as exposure, I think it should maybe target range.start instead so I'll put up a fix for that.

@GitGhillie GitGhillie changed the title Auto exposure breaks when object has a roughness map Auto exposure breaks when object is too dark May 21, 2024
@alice-i-cecile alice-i-cecile added this to the 0.14 milestone May 21, 2024
@alice-i-cecile alice-i-cecile added the S-Ready-For-Implementation This issue is ready for an implementation PR. Go for it! label May 26, 2024
github-merge-queue bot pushed a commit that referenced this issue May 29, 2024
# Objective

- In particularly dark scenes, auto-exposure would lead to an unexpected
darkening of the view.
- Fixes #13446.

## Solution

The average luminance should default to something else than 0.0 instead,
when there are no samples. We set it to `settings.min_log_lum`.

## Testing

I was able to reproduce the problem on the `auto_exposure` example by
setting the point light intensity to 2000 and looking into the
right-hand corner. There was a sudden darkening.

Now, the discontinuity is gone.

---------

Co-authored-by: Alice Cecile <alice.i.cecil@gmail.com>
Co-authored-by: Bram Buurlage <brambuurlage@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Bug An unexpected or incorrect behavior S-Ready-For-Implementation This issue is ready for an implementation PR. Go for it!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants