[Feature Request] Add a "Mode" property to the PostProcess node

[caiquesassis]

One thing that is useful when working with Post Processing is to have the ability to confine certain effects to specific local areas in space, similar to how it's handled in Unity. We have the ability to set a "Global" volume, which affects the entire scene regardless of camera position, and "Local" volumes, which, through setting the boundaries via a collider, let us define a custom area for the effect to be applied only when the camera enters it, on top of having a "Blend Distance" parameter that smoothly blends between the previous Volume being applied and the new one to be switched to (or blending both together when both are active).

Outside the Local Post Processing Volume's boundaries

Inside the Local Post Processing Volume's boundaries (a box collider was used but different collider shapes are also supported)

Since Godot has the Node-based approach, I guess this would probably need to be a different type of node altogether (perhaps a LocalPostProcess node or something) since it would probably need an Area node as its child.

Would something like this be possible / viable to do? I know it's early days for the plugin (and it's amazing so far) but having those options (if possible) to bring the workflow closer to how Unity handles those Post Processing volume would be interesting, considering it was one of the inspirations as far as I understand for creating the plugin and it's really straightforward there and works nicely too.

[Loufe]

Thanks for another great write-up, @caiquesassis. Interesting idea, too.

I like the idea of simply having to add a child node defining an area2d/Area3D to make this work. While the types don't inherit from "CanvasLayer" (which the plugin does), that doesn't prohibit them being added as children.

While that's easy enough, I'm unsure how we'd implement detection of the player. In my game I'd think to configure it using physics layers, as I have one configured exclusively for the player's node. The code would be fairly easy to implement, but I wonder if we can support that this approach would work for everyone. It wouldn't be difficult to allow a property to define the physics layer to use, but I don't know enough about how others' games work, Godot's flexibility for how to implement the main player (if there even is one) might harm us there.

In my use of the plugin, I add it only via code. Adding child nodes would mean I need to configure areas without visualizing them in the editor, which I'd disfavour. For me I wouldn't gain from adding this system, instead I'd stick with in-game codeto switch the post effect on-off via direct functional calls to the plugin based on criteria I define.

That said, I do think the approach is ok. If you choose to imlpement it, I'll happily review the PR or answer any questions as best I can. If you want to get the blending working, we would be wise to finish #22 first. One approach to implementing the blending would be then to define an "outer" area where the effect gets enabled, and an "inner" area where you fully enable the blend (like a weight of 1 according to #22). You could then blend according to a linear/quadratic function according to the "distance_to" value. If the "outer" area and "inner" area don't have an even thickness, you could maybe make % between function where you grab the "distance_to" each and do something like weight = 1 - distance_to_inner / (distance_to_inner + distance_to_outer).

[caiquesassis]

While that's easy enough, I'm unsure how we'd implement detection of the player. In my game I'd think to configure it using physics layers, as I have one configured exclusively for the player's node. The code would be fairly easy to implement, but I wonder if we can support that this approach would work for everyone. It wouldn't be difficult to allow a property to define the physics layer to use, but I don't know enough about how others' games work, Godot's flexibility for how to implement the main player (if there even is one) might harm us there.

Yeah, a game might not have a main player indeed, but in theory a game will always need at least a main camera, so that could be used instead - we end up falling into the same problem though, as we'd need to have a way to identify if the camera is inside the bounding box and whatnot, so we'd need to resort to areas once again... of course, this feature would only be useful for "spatial" 2D and 3D games, as I don't think UI-Based games would really need it.

In my use of the plugin, I add it only via code. Adding child nodes would mean I need to configure areas without visualizing them in the editor, which I'd disfavour. For me I wouldn't gain from adding this system, instead I'd stick with in-game codeto switch the post effect on-off via direct functional calls to the plugin based on criteria I define.

Yeah, this could also work - to be fair, except for the blending part (which could also be worked on "manually") you can kinda already achieve this by doing it manually and just interfacing with the plugin's scripts (given that two PostProcess node work together without problems, which I'm not sure). As for doing it code-only instead of having a visual way of handling it, I think it's also a "per-game" issue, as setting this up via code only could be troublesome in some games (for instance, a game I made in Unity made extensive use of this feature to blend between different post process "volumes" depending on the area or room the player was in the level, so indeed, being able to see the bounding box / area in the editor is a must). This is kinda janky, and not really a clean way to deal with it, but a player could also just enable the "Editable Children" checkbox by right clicking on the Node in the scene to get access to the Area node...

That said, I do think the approach is ok. If you choose to imlpement it, I'll happily review the PR or answer any questions as best I can. If you want to get the blending working, we would be wise to finish #22 first.

I do agree that one step at a time is the better way to handle things - but as I mentioned on #22 , I'm unfortunately not confident I'd be up to the task of helping with the code here. I really just brought up some points and requests mainly from the standpoint of an "end user" so I'm really sorry about it 😅