Closed ettiSurreal closed 8 months ago
The issue with adding more built-in fog options is that it has a performance cost, even if you don't use the feature. This is because the core material shader has to be more complex to support all those additional use cases, which in turn increases the shader's VGPR occupancy.
https://github.com/godotengine/godot/pull/66030 reimplements distance fog, but I wonder if there are real world use cases to exponential non-volumetric fog. Most games with realistic visuals will want to rely on volumetric fog, and games with stylized visuals (including retro games) will want to rely on distance fog instead.
While specialization constants make it possible to support both with a performance penalty, the size of the specialization constant map is finite. We'd like to make greater use of SCs in other parts of the renderer, so we need to make sure each use of a specialization constant is well-justified.
Cylindrical fog is interesting, but I'm not sure how often it would be used in practice. I know Minecraft uses this kind of fog as chunks are infinitely tall, but that's the only use case I can think of. Also, cylindrical fog can be emulated using volumetric fog by creating a FogVolume with a FogMaterial that has its density set to -1
, then moving this FogVolume to follow the camera position.
The only thing I'd support readding for now is the ability to use a different depth fog color and height fog color in non-volumetric fog.[^1] This was indeed removed in the 4.0 fog implementation (in the name of simplicity), but there are many good use cases to using different fog colors for both. For instance, you want to use a depth fog color that matches the sky for open world fading, but you want to use an entirely different color for height fog (to simulate smoke accumulating in volcanos, toxic wastelands, etc).
[^1]: Volumetric fog can be used as a workaround, but it's not available in the Vulkan Mobile and OpenGL backends.
For future reference, distance fog was implemented in 4.3 by https://github.com/godotengine/godot/pull/84792. Sky affect was also implemented earlier (in 4.1 or 4.2 IIRC). Cylindrical fog is however not implemented so far, so please open a new proposal for that if you still need it for a project.
Describe the project you are working on
Mostly just messing around, i guess possible projects people could need this for are horror games with low field of vision, retro style games, and open-world games with distance cutoff.
Describe the problem or limitation you are having in your project
The new fog implementation doesn't offer nearly as much artistic freedom, and is a harder to set up for specific needs and distance. A different take of https://github.com/godotengine/godot-proposals/issues/4619.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Bring back an implementation of the 3.X fog, as either dropdown options for the regular fog or separate tabs in Environment, i'll continue with the latter.
The current fog would be renamed to Exponential Fog There would be two new options called Distance Fog and Height Fog. The idea is that these could be stacked as the user wants, although i am not sure how feasible/practical that is, like in case the different fog types have different colors. If anyone knows how it could be handled let me know!
Distance fog would works the same was as depth fog works in 3.X, possible improvements i could see are:
Height fog would also work the same way as height fog in 3.X, with:
If stacking different colored fogs isn't possible, Exponential, Depth and Height fog could be under the same dropdown, each individually toggle-able, although sharing some common settings as they need them.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
It would work like in 3.X, with some extra features.
If this enhancement will not be used often, can it be worked around with a few lines of script?
Could probably be made as a shader, but they are a quite advanced topic, especially for beginners.
Is there a reason why this should be core and not an add-on in the asset library?
Missing functionality from previous versions.