Split Environment and WorldEnvironment into 2D and 3D versions

[aaronfranke]

Describe the project you are working on

I'm working on Godot, including helping users learn the engine.

Describe the problem or limitation you are having in your project

The Environment resource, and the WorldEnvironment node, are fairly confusing. Most of the settings are only applicable for 3D, but this node can also be used for 2D. The duality of this node is hinted at by its icon being a split of red and blue, but most users don't seem to know that this node can be used for 2D. Even if they do, it's not at all obvious which of the features of WorldEnvironment are applicable to 2D, in a sea of 3D-only options.

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

The proposal is to split Environment and WorldEnvironment into 2D and 3D versions.

Environment2D and WorldEnvironment2D would only have features that are applicable to 2D.

Environment3D and WorldEnvironment3D would only have features that are applicable to 3D.

This would likely also involve splitting CameraEffects into CameraEffects2D and CameraEffects3D, and adding a CameraEffects2D property to Camera2D just like how we already have CameraEffects on Camera3D.

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

This will involve a lot of refactoring.

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

This will be used very often. The workaround is to just deal with how it's confusing.

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

Environment and WorldEnvironment are already in core.

[h0lley]

to illustrate this further, as mentioned already the confusion begins with WorldEnvironment being the only node with both Node3D and Node2D coloring in the icon:

when an user building a 2D game tries using this node, they'll first find that it doesn't seem to have any effect no matter which effects they enable. this is because the background_mode need to be set to Canvas first. not at all intuitive - the only option that could be said is obviously for 3D and not 2D is Sky:

then after having figured this out, there's still a plethora of options having no effect with the few that do mixed in between:

the effects highlighted in the Node3D color are 3D exclusive, and those highlighted in the Node2D color are both usable for 2D and 3D. if the user is up for it they can figure this out in a lengthy process of trial and error.

so I agree it would improve the UX a lot if the irrelevant options were hidden.
but on top of that, I think it makes sense to set this up for 2D post-processing effects to be possible to diverge from the 3D effects.

another thing that should be mentioned is that when compiling Godot with the disable_3d flag, then this disables the WorldEnvironment node entirely, meaning that currently 2D games that make use of these post-processing effects are required to be shipped with the 3D engine. ☹

[smix8]

You are all so more eloquent than me ... I agree that WorldEnvironment is a confusing clusterfuck node but what about reacting to the current 2D or 3D use, maybe with a dropdown enum, and hiding invalid options?

I often combine 2D and 3D in the same world and I cannot split this into two worlds in two different viewports that use "own_world" setting so two different WorldEnvironment can coexist.

[aaronfranke]

@smix8 That's certainly a valid option, though I'm still in favor of separate nodes. Note that if WorldEnvironment2D and WorldEnvironment3D were separate, you could have one of each in a scene - it would be silly otherwise.

[reduz]

The main issue is that WorldEnvironment is for 3D and its used in 2D to do glow and HDR. IMO what we need to implement is HDR 2D viewports that handle this as pure 2D without requiring WorldEnvironment.

[h0lley]

The main issue is that WorldEnvironment is for 3D and its used in 2D to do glow and HDR. IMO what we need to implement is HDR 2D viewports that handle this as pure 2D without requiring WorldEnvironment.

which I think is still very much in alignment with this proposal. whether it's a node that's called WorldEnvironment2D, another Resource that somehow interfaces with the Viewport, or anything else, I'd say that's more of an implementation detail - point is it should be separated from 3D.

hopefully it'll be possible to get close to what was available and how the effects looked like in Godot 3. if it were to be implemented purely in 2D, would one or several of the options I marked above likely be lost?

[MegadronA03]

WorldEnvironment should be changed to WorldLight or LightSettings (because suggested implementation literally deconstructed Environment resource into multiple vertex shaders), that controls light settings within the engine.

I partially reposted it from #2196, so for detials on Prep and Post shaders read there.

I think its better to approach shader typing is like godot does it with its objects (like we have some Main empty shader class, that have Sky, CanvasItem/2D, 3D, Prep, Post childern that are extending from it with their own uniform hints and also could be converted/extended into your custom shader class for editing, just like objects in godot).

the base hierarcy that I thought of:

• Main
• • Prep (pre depth processing)
• • Post (post processting)
• • • Environment (just has compilation of multiple shaders used for the same things as in Environment resource)
• • • LightSettings (ambient and reflected light modifiers)
• • • Tonemap
• • • • Linear
• • • • Reinhard
• • • • Filmic
• • • • ACES
• • • Adjustments (contrast, brightness, saturation and color correction, tho I think to split it into different classes)
• • • Screen Read (this shader reads from provided textures, that should be screen texture, but not limited to it)
• • • • SSR
• • • • SSAO
• • • • SSIL
• • • • Bloom/Glow
• • • • • FFT based
• • • • • Blur based (idk how its called)
• • • • Depfh Effects
• • • • • DOF Blur
• • • • • FogLinear (literally the cheapest fog that only rely on depth value)
• • • • • FogRadial (radial fog, without complex shapes)
• • • • Volumetric (used for smoke or advanced volumetric fog)
• • CanvasItem/2D (transforms)
• • Sky
• • • Box
• • • Physical
• • • Procedural
• • • Cylinder
• • • Panorama
• • • Layered (for using skyboxes with transparency, so part of the skybox could be changed)
• • Backbuffer (used for Screen Reading shaders)
• • Frame (used for Screen Reading shaders)
• • Color
• • • Unshaded
• • • • StandartMaterial (the one with different material rendering stuff)
• • 3D (transform)
• • • MultiMesh
• • • • GPUParticle

Each shader will have "next pass" and "prep pass" that allow to construct desired shader using other shaders. this could be more flexible in terms of adding obscure functionality, like drawing 2D elements directly In 3D or the other way around (3D on 3D) without limitation of the SubViewport node.

The current system not only makes rendering process much more transparent to the end user, but also will makes "next pass" much more usefull than curently it is, and also solves the problem with post and pre process shaders, and the problems they are causing with transparency.

P.S. Im aware thats literally changes the entire underlying rendering system, so Its probably gonna be released in like Godot 5.