Volumetric fog overblown on TPS demo (regression from #111998)

[akien-mga]

Tested versions

• Reproducible in 4.6.dev3 (9d84f3d)
• Reproducible in merge commit of Revise fog blending to fix over-darkening/borders. #111998 (94df7a1)
• Not reproducible in direct parent commit of the Revise fog blending to fix over-darkening/borders. #111998 merge (ea381ac)
• Not reproducible in 4.6.dev2 (7864ac8)

System information

Fedora Linux 42 (KDE Plasma Desktop Edition) on Wayland - X11 display driver, Multi-window, 1 monitor - Vulkan (Forward+) - integrated AMD Radeon 780M Graphics (RADV PHOENIX) - AMD Ryzen 7 8845HS w/ Radeon 780M Graphics (16 threads) - 60.60 GiB memory

Issue description

The TPS demo in 4.6.dev3 looks like this:

And in 4.6.dev2, it looks like it used to:

I confirmed it to be a regression from #111998, CC @shakesoda @clayjohn.

Steps to reproduce

• Run https://github.com/godotengine/tps-demo

Minimal reproduction project (MRP)

I don't have time to investigate further to make one, just reporting the bug.
The TPS demo is big but should allow reproducing the bug easily.

[fire]

Theres a suggestion from @shakesoda that it’s related to the division by res.a

[Calinou]

I can confirm this on 4.6.dev cb3af5a.

Note that the issue is much less prominent on the main menu. Here, only the floor is brightened somewhat:

4.6.dev2	4.6.dev cb3af5a

Disregard the issue with broken character animation, it's unrelated (but is also seen in the 3D platformer demo).

[clayjohn]

I found our problem

Looking through the lights in the scene, the lowest value I found was 5000. That is completely absurd. The slider only goes up to 16 which is already an extremely high value.

It seems like an extremely low density was used along with a super high volumetric fog energy on the lights to basically allow for having almost no fog in dark areas and a faint fog in light areas. I'll see if we can recover the same look using proper blending equations and reasonable values for volumetric fog energy

[clayjohn]

Alright, after doing some more investigation and fixes, everything makes sense now.

The problem with the old method is that we were multiplying the volumetric fog color by its opacity twice. For very heavy fog, that wasn't a problem, but for very sparse fog it resulted in it being way too dark (and hence having the dark borders around the edges of fog volumes as reported in #101514)

In the TPS demo, we have the fog density set to an extremely low value: 0.0001. This results in a very low opacity value, which gets multiplied twice which fully suppresses the fog. To counteract that, the demo used extremely high light energy multipliers making lights 5-15 thousand times stronger in volumetric fog than they are in the scene. This was required just to make the fog visible.

Using a higher density value and weaker light multipliers can achieve the same effect (see godotengine/tps-demo#212).

My suggestion to fix this bug is to update the TPS demo with more reasonable volumetric fog values and to clean up our Volumetric Fog blending code further to use the correct values everywhere.

Ultimately, this will change behaviour for some users. When using default values it should look roughly the same. For most users the difference will not be very noticeable. The only people who will be severely impacted are people like us who have pushed the values to the extreme. But IMO this is a spacebar heating situation (https://xkcd.com/1172/) and we need to prioritize fixing the bug over maintaining 100% compatibility.

[akien-mga]

Yeah if the TPS demo was doing something extreme to exploit a bug, it makes sense to me to fix that demo instead of reverting a bugfix.

We should make sure that the compat breakage is documented in the migration guide, so users who may have done similar hacks understand why their projects break and how to fix them. I put #112494 on the documentation tracker so we don't forget.