Implement a bounding-box/volume-based approach for local environments and post-processing

[PrecisionRender]

Describe the project you are working on

A 3D project that has multiple different themed areas.

Describe the problem or limitation you are having in your project

The WorldEnvironment node and resource are global, to the entire scene. There is no way to set up a smaller area (e.g. inside a volcano) to have a different post processing setup to the rest of the scene.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Most game engines, like Unity and UE5, use a volume-based approach, where one can specify post processing settings inside of an AABB, that can modify a predefined area's post processing effects. Example:

World has XY as global ambient light

Smaller volume has WZ as local ambient light inside of predefined area

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Instead of a WorldEnvirinment node, there would be an EnvironmentVolume node, where one could specify the post processing effects that are active inside of the area. Or, one can turn off an option such as "Is Bounded" so that the EnvironmentVolume node acts as a WorldEnvironment node. Then one can put more EnvironmentVolume nodes into the Scene where one needs different post processing.

UE_1.mp4

Here is an example of a global post-process volume (left) and a local post-process volume (right).

If this enhancement will not be used often, can it be worked around with a few lines of script?

No, this system requires quite deep knowledge on how environments are rendered, and the code required to blend between them is quite complex.
Plus, having such a node built-in allows the ability for one to move the viewport camera into an EnvironmentVolume area and examine its effects in the editor, whereas if such a tool was scripted, post processing areas could only be examined at runtime, by changing WorldEnvironments dynamically through code.

And something that can't be easily achieved through GDScript or even GDExtension is having a proper fade between areas, so as not to have a sharp "pop" between different visual effects.

Is there a reason why this should be core and not an add-on in the asset library?

See above.

[mrjustaguy]

This would be very useful for games that need transitions between land and water

[Calinou]

Unfortunately, I feel this can lead to shaders being extremely complex to support this, reducing performance significantly. It's not like the renderer is too fast as it currently is 🙂

And something that can't be easily achieved through GDScript or even GDExtension is having a proper fade between areas, so as not to have a sharp "pop" between different visual effects.

Most Environment properties can be smoothly tweened over time with no performance impact. This will not work if you want different areas viewed at the same time to use different properties, but for a player travelling through a game world, it can be a good enough solution.

If you want to perform color grading based on where the player is currently located, smooth transitions could be better supported by allowing the blending of two color correction curves together. Local color grading of that kind is common in AAA games, and it's not too expensive to support. This could be worth discussing in a separate proposal, as I don't see a way to work this around currently (especially with 3D LUTs supported in Godot 4.0).

Smaller volume has WZ as local ambient light inside of predefined area

This can be achieved with a ReflectionProbe node, which can smoothly override ambient light within a defined box (that can be rotated). You can either use the environment color, or use a custom ambient color of your choice. This is available in both Godot 3.x and Godot 4.0, but Godot 4.0 offers more options in this aspect.

FogVolume nodes are also available in Godot 4.0 for local fog, and they can use custom fog shaders as well.

[PrecisionRender]

I feel this can lead to shaders being extremely complex to support this, reducing performance significantly. It's not like the renderer is too fast as it currently is 🙂

Most Environment properties can be smoothly tweened over time with no performance impact.

Then can't we just do something with tweens, like you suggested? It doesn't have to be a shader.

[PrecisionRender]

FogVolume nodes are also available in Godot 4.0 for local fog, and they can use custom fog shaders as well.

Yes, the FogVolume nodes are excellent. I was thinking of something similar for the entire WorldEnvironment. Not necissarily things like SDFGI, SSAO, SSIL, or SSR. Just things that have a greater aesthetic impact, like Skies, Ambient Light, Color Grading, etc.

[Calinou]

Then can't we just do something with tweens, like you suggested? It doesn't have to be a shader.

By "shader", I was referring to the GLSL shaders internally used in Godot to render various materials. It's important to keep those simple to improve performance and reduce shader compilation times.

I was thinking of something similar for the entire WorldEnvironment. Not necissarily things like SDFGI, SSAO, SSIL, or SSR. Just things that have a greater aesthetic impact, like Skies, Ambient Light, Color Grading, etc.

How would local skies work? I feel it doesn't make sense, at least from a background perspective. You can already use ReflectionProbes if you need custom reflections within an area. (If you want a reflection that actually doesn't reflect the surroundings, use a sphere with a texture around the ReflectionProbe and hide this sphere after the ReflectionProbe is done rendering.)

[PrecisionRender]

How would local skies work? I feel it doesn't make sense, at least from a background perspective.

I was just using it as an example. Skies don't necessarily need to change.

By "shader", I was referring to the GLSL shaders internally used in Godot to render various materials. It's important to keep those simple to improve performance and reduce shader compilation times.

That is important; something that Godot does well compared to other engines is shader compilation. I was suggesting doing the calculations in regular C++, then feeding that into a shader, like how the WorldEnvironment does.

TL;DR: The EnvironmentVolume node decides what effects and parameters to use, then those are fed into the World3D. As far as the World3D is concerned, it's just one Environment resource, keeping all the shaders the same as they are now.

[clayjohn]

I imagine we could have something like a "LocalEnvironment" Node that overrides the current WorldEnvironment. We would have to limit it to only interpolate easily interpolatable properties (other properties like sky could just snap to the new resource when in the volume). I'm sure you could manage everything in the SceneTree well enough that you could avoid doubling any calculations in the rendering code.

[PrecisionRender]

I imagine we could have something like a "LocalEnvironment" Node that overrides the current WorldEnvironment. We would have to limit it to only interpolate easily interpolatable properties (other properties like sky could just snap to the new resource when in the volume). I'm sure you could manage everything in the SceneTree well enough that you could avoid doubling any calculations in the rendering code.

This is also a good idea.

[Calinou]

Looking at the video¹, I finally understood what you mean. I was initially thinking that you'd expect different pixels to use different Environment properties, rather than affecting the entire view at once. This seems like a reasonable approach to me.

Footnotes

1. The video doesn't preview in Firefox (I get "No video with supported format and MIME type found."). I managed to view it by right-clicking it, copying the video link and opening the copied video link in a new tab. ↩

[PrecisionRender]

Ah, yes, I guess I was relying too much on the video to explain it for me. 😅 Sorry. Yes, it should effect the entire view based on the camera position.

[SIsilicon]

What if you give the already existing Area nodes an environment property?