input_event triggered only once in a subviewport setup for 3D

[Plofeu]

Godot version

4.1 stable

System information

Godot v4.1.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1660 SUPER (NVIDIA; 31.0.15.3179) - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz (8 Threads)

Issue description

Hi, this is my first bug report, please feel free to inquire any missing information.
I observed a regression in my game when updating to Godot 4.1 from Godot 4.0.3 stable.

With this hierarchy, hovering the mouse on the Area3D Collision Shape will only trigger the input_event function once.

Details as follow :

• Area3D has the signal input_event() connected to the following script :

func _on_input_event(camera, event, position, normal, shape_idx):
	print("event "+str(name)) 

• Subviewport has Object Picking toggled.
• SubViewportContainer mouse_filter is Ignore.

Current behavior :
Running the project and hovering your mouse on the Area3D will print exactly once the following :

event Area3D

Expected behavior : (last stable version of Godot)
The print should be triggered at every input, motion or button from the mouse.
Now correct me if I'm wrong, but I suppose this is a bug.

Additionnal behavior tested :
When Area3D is moved from the Editor while the scene runs, it resets, and allows for exactly one new print.

I found another ticket having issues with Input event #79235, but I am unsure if this is related.

Steps to reproduce

Create a SubViewportContainer, extend the size to full. Toggle Stretch. Select mouse_filter to ignore.
Create a child SubViewport. Toggle Object Picking.
Create a small 3D setup :

• Node3D as a root
• Add a child Camera3D to Node3D
• Add a child Area3D to Node3D. Move it along z to -6.
• Connect Area3D signal "input_event" to a script on Area3D.
• Add print("event") under the _on_input_event() function.
• Create a child ColisionShape3D to Area3D. Provide it with a BoxShape3D.
• Create a Meshinstance to Area3D. Provide it with a BoxMesh. (This is for visualization, but you can also toggle visible collision shapes in Debug > visible Collision shapes instead of this step.)

Run the scene, and hover the mouse back and forth over the Area3D.

Minimal reproduction project

Godot InputKey Bug.zip

[Sauermann]

Hi, this is my first bug report, please feel free to inquire any missing information.

You included all relevant info, so that will not be necessary.

In your project, please change SubViewportContainer.mouse_filter from MOUSE_FILTER_IGNORE to MOUSE_FILTER_STOP or MOUSE_FILTER_PASS. That should resolve your problem. Can you please test this change?

This change was a necessary bugfix and got introduced in #57894.
Related to #79128 which shows a different effect of that change.

#79235 is about key-events and not about mouse-events, so I wouldn't consider it related.

SubViewportContainer.mouse_filter = MOUSE_FILTER_IGNORE should now have the effect, that the SubViewport and the Nodes inside the Viewport don't receive any events. So I consider it a bug, that in the above MRP event Area3D is printed once: it should not be printed at all.

[Plofeu]

Thanks, I figured the mouse filter was part of the answer.

Now, this is an aspect of a bigger setup I had :
With 2 Viewports on top of each other, both set to MOUSE_FILTER_PASS , the first viewport in the hierarchy only recieve one event, and the second one receive them all, as expected.

Hierarchy :

I just duplicated the setup, and switched the viewports mouse_filter to pass on both. ( and move both Area3D nodes to unstack them)

Would the correct expected behavior be to have both of them recieve all the events in that case ?

[Sauermann]

In that case if you want to propagate the mouse-event to both SubViewports, please have a look at #79128. (Use Area2D instead of SubViewportContainer).

Would the correct expected behavior be to have both of them recieve all the events in that case ?

No, because only a single Control-node is supposed to be able to accept the event and SubViewportContainer as a Control-node follows this convention.

[Plofeu]

Very interesting this is exactly it, thank you very much !

[Sauermann]

Thanks for the feedback. Closing this issue accordingly. I will create a separate bugreport for the single-event, since the main issue here is resolved.