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

[WickedInsignia]

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.

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]

• Related to https://github.com/godotengine/godot-proposals/issues/2138.

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 https://github.com/godotengine/godot/issues/74140).

[lander-vr]

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.

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]

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 https://github.com/godotengine/godot-proposals/issues/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.