Custom InputEvent order (especially for scenes with 2D, 3D and Control nodes simultaneously)

[jkvastad]

Currently input is handled via input event in an 8 step process, where control nodes are handled in step 4, unhandled input in step 7 and object picking in step 8.

In games using 2D, 3D and GUI simultaneously this is currently limiting in a few ways:

• Imagine a card game (2D cards) with a 3D world and a HUD (e.g. Terraformers). In such a game it is possible to have a HUD (e.g. player stats or a pause menu) in front of a card (a 2D node) in front of a world item (3D node, e.g. a planet/city).

Now consider which behaviors Godot can support when clicking this stack of three different types of nodes:

1. GUI Control nodes can consume or pass event forward to object picking, but not the other way around (maybe in some game the 2D foreground should come before the HUD - perhaps you want to play cards directly onto the HUD to change it)

2. There is no way for 2D nodes to occlude 3D nodes, since they are done with different simultaneous ray casts in step 8. Thus clicking on cards clicks "through" them, inadvertently selecting world objects e.g. zooming in on planets/cities in a Terraformers style game.

3. Let's say i want to release a card in unhandled_input, e.g. if someone drops a card (left mouse up) on empty space -> return it to hand. But I only know if a position is empty after object picking, which is after unhandled_input. How are we supposed to deselect things?

The closest solution to these i have found is event polling in _physics_process, which handles point 2 and 3, but introduces problems with Control nodes - I have not seen any way to check if my 3D/2D nodes are occluded by Control nodes when using event polling.

I am not sure what the solution should be, but these are problems causing me much headache. Perhaps a possibility to reorder InputEvent, or inject custom events in the event chain?

[Sauermann]

1. This is a limitation of the current implementation. For an input event, physics-interaction (2D and 3D) happens asynchronously in the next frame while the interaction of input events with Control nodes happens synchronously. So it is not possible to wait synchronously for an asynchronous result. A user mentioned a workaround for this: Change unhandled InputEvent propagation #1058 (comment)
2. Implementing a boolean viewport variable called something like "2d_nodes_occlude_3d_nodes" would be relatively easy to do and could look like this:

diff --git a/scene/main/viewport.cpp b/scene/main/viewport.cpp
index 5999b85988..f5ca4f00d7 100644
--- a/scene/main/viewport.cpp
+++ b/scene/main/viewport.cpp
@@ -867,6 +867,10 @@ void Viewport::_process_picking() {
                        }
                }
 
+               if (2d_occludes_3d && is_input_handled()) {
+                       return;
+               }
+
 #ifndef _3D_DISABLED
                CollisionObject3D *capture_object = nullptr;
                if (physics_object_capture.is_valid()) {

However implementing the option to support all cases (2d occludes 3d / 3d occludes 2d / no occlusion in both directions) is more tricky.

3. Can you please check, if Add an additional input stage after physics picking godot#79826 would solve this problem.

[jkvastad]

Thank you for the reply! :)

1. Interesting workaround, I tried something similar with call_deferred where I interrupted gui_control actions based on setting flags in unhandled_input.
2. Mathematically there are 6 cases right? 3 choices -> 2 choices -> 1 choice = 6, perhaps just do the same approach as you mentioned but with all the cases? Then again one might want certain elements of the same kind (Control/2D/3D) to overlap others... I guess the problem lies in how the user views the game and wants to click on the "closest" item (as mentioned in Change unhandled InputEvent propagation #1058), but the situation is more similar to three different parallel worlds. Perhaps this is the core problem I run into - I want the input chain to (easily) allow for this user abstraction.
3. Yes, Add an additional input stage after physics picking godot#79826 would solve it if the ray trace results are available, one could check "if nothing clicked" and deselect things.
   3.1. On a side note, leading up to #79826, it is mentioned in Change unhandled InputEvent propagation #1058 (comment) that: "...the only way to check if the user clicked on nothing is to perform a raycast in _unhandled_input", which I believe is not reliable since physics space may be locked outside of physics_process (see last paragraph of Ray-Casting).

[Sauermann]

Currently I don't see a way how to implement all 6 cases, because Control input is evaluated synchronously, while 2D/3D physics happens asynchronously. So Control always comes first.
Is there a way that you could restructure your project to only use 2D and 3D nodes?

The idea of #79826 is that the newly introduced function gets called only, if the input event has not been set to handled previously. So you would need to set_input_as_handled() during the 2D/3D-input-event-callbacks, to make sure, that the new function is not called.
I agree with your side note, that the mentioned method is not reliable.

[jkvastad]

2. Alright, Control is in control then! :P I could completely skip control nodes. Feels like a shame though to skip all the nice features with layouts, themes, containers, etc. Perhaps I can get away with polling for input in physics_process and doing some manual logic for occlusion checks. This will probably also mean doing e.g. pause menu with Node2D which feels weird... but games are all smoke and mirrors in the end anyways 😄
3. Aha ok I peeked into the commit now godotengine/godot@a7c976d. So if we click on something with object picking, that event could set input as handled (similar to current InputEvent behavior), or just leave it be and we could interpret it as "no one wanted the object picking input - deselect object", analogous to how unhandled_input and object picking is now. Sounds good!