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

Unshaded materials don't compensate for autoexposure, only manual exposure #75128

Open
WickedInsignia opened this issue Mar 20, 2023 · 3 comments

Comments

@WickedInsignia
Copy link

Godot version

4.0 Stable

System information

Windows 11, Nvidia RTX4070ti, AMD Ryzen7700x

Issue description

The 3D gizmo becomes too bright when Auto Exposure is used via a Camera Attributes Practical/Physical resource and the brightness of the scene is low (interior lighting or moonlight). This washes out the colours of the gizmo's axis into white and interferes with scene legibility when Glow is enabled.
This doesn't occur when the ISO exposure slider is used to bring the scene up to a similar exposure as it would be when Auto Exposure is enabled.

GizmoExposureBug

Steps to reproduce

  • Set lights to dim physical values (1000 lux for example)
  • Add a Camera Attribute Practical/Physical to the World Environment node
  • Turn on Auto Exposure

Scene with all appropriate values already provided in the MPR.

Minimal reproduction project

Overexposed_Gizmo.zip

@Calinou
Copy link
Member

Calinou commented Mar 20, 2023

Unlike glow and depth of field, it may be possible to fix this by dividing gizmo material brightness by exposure using a custom shader (similar to #74140).

@lander-vr
Copy link
Contributor

lander-vr commented Apr 22, 2024

Just wanted to note for the case of a bright scene (High EV100 values) all gizmos turn to black. I assume this is part of the same issue.

image

I'm building a 3D debugging panel using 3D labels, the behavior I would expect from those labels is that when their "Shaded" flag is set to false that they would be unaffected by the cameras exposure, since they're supposedly unlit, but that doesn't appear to be the case.

I've also seen 3D labels (And regular gizmos I believe) influence auto exposure when set to unlit and when dealing with low exposure values, making the auto exposure fluctuate.

@Calinou
Copy link
Member

Calinou commented Apr 29, 2024

I've also seen 3D labels (And regular gizmos I believe) influence auto exposure when set to unlit and when dealing with low exposure values, making the auto exposure fluctuate.

I'm not sure how this issue should be handled without godotengine/godot-proposals#2138 (which is pretty difficult to implement). If an unshaded object is rendered onto the color buffer on the base opaque (or transparent) pass, it'll naturally affect how bright the viewport appears to the shader that calculates the autoexposure value.

The division trick might work to an extent but I don't think it'll work in 100% of cases due to the potential for feedback loops.

@Calinou Calinou changed the title 3D Gizmo Too Bright in Low Auto Exposure Unshaded materials don't compensate for autoexposure, only manual exposure Aug 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants