Add setting for picking only top-most overlapping collision object

[mnemoli]

Fixes #29825

• Add project setting for toggling top-most object picking
• If setting is on, sort the collision objects as per Fix propagation order for 2D physics picking events #68492 and break after sending the first input_event, so only the top-most object receives an input

Personally I would prefer this to be default-on since it's much more intuitive and sensical for new users, but it's a change in behaviour and has a performance cost so better safe than sorry?

Sample project:
PickingTest.zip

[Sauermann]

I had a look at the code and it looks like the changes implement the announced feature.

My personal preference would be to remove the interaction with physics_object_picking_sort by changing it the following way: The newly introduced viewport-flag would configure only, if the event is sent to all collision objects at the mouse location or if the event is sent to just the first encountered collision object. (The physics_object_picking_sort flag would configure if the first encountered collision object is the top-most collision object)

I am not sure if a project-setting for the root viewport is strictly necessary, since it can also be changed via GDScript.

[jsbeckr]

The current behavior is quite weird tbh and makes it necessary to use workarounds for any RTS style game. Is there an update on this issue?

[mnemoli]

Sorry for somewhat 'abandoning' this PR 🙂 @Sauermann My thoughts were it should be a project setting because the default behaviour, as jsbeckr points out, is weird and confusing - I think there should be high visibility and a low barrier to setting this for new users, especially since Viewport is a non-obvious place (imo) to go looking for physics flags.

I see your point about separating concerns by changing this to a "pick first encountered" flag (rather than "pick top") but find it hard to imagine a use-case where somebody would want to pick the first randomly encountered physics object so suspect both flags would be set by users in 99% of cases? Let me know if your thoughts have changed on either of these, if you're still of the same mind I'll make changes

e: github sync fork made a complete hash of the branch so I had to reset it, excuse the force push

[AThousandShips]

@RyanGosden Please don't bump things without contributing significant new information. Use the 👍 reaction button on the first post instead.

[Sauermann]

a use-case where somebody would want to pick the first randomly encountered physics object

The use-case, that I can see is that it doesn't matter, which physics object is encountered and just a single one is wanted.

Let me know if your thoughts have changed on either of these, if you're still of the same mind I'll make changes

I personally would still prefer the approach of the separated concerns.

[mnemoli]

@Sauermann OK, have changed to "first only" rather than "top only" and separated from sorting. Have also removed from project settings since the intention there was to give new users a visible way to get an intuitive top-only picking setting. New test project attached with both flags off by default, enable them in scene.gd:_ready to test behaviour.

PickingTest2.zip

[Sauermann]

Here is a MRP to test the changes, which work fine:
BugPickingZSort.zip

Implementation makes sense to me.

Please squash the commits together as explained in the contribution guidline:
https://docs.godotengine.org/en/latest/contributing/workflow/pr_workflow.html#the-interactive-rebase

Beside my comments, this PR looks ready.

[Sauermann]

Tested PR rebased on 4e990cd.
Works as expected.
Implementation is looking good.

[akien-mga]

Thanks! And congrats for your first merged Godot contribution 🎉

[Anutrix]

Can we have some docs stating when/where(which scene or script or part of lifecycle) this can be enabled?

I currently enable it at _ready() of closest-to-root node's script. Hope this is the expected way to do this.

[AThousandShips]

At any time? Are you facing issues with this at specific times? If so please open a bug report, if not why are you asking?

[Anutrix]

At any time? Are you facing issues with this at specific times? If so please open a bug report, if not why are you asking?

No issues yet. Both work great. Really happy with it.
Just lack of docs/example.

I just came across this while implementing a simple dragging behavior for Area2D objects.
Similarly, I believe new Godot users might be expecting behavior that physics_object_picking_first_only and physics_object_picking_sort provides and come looking here.
Including who haven't yet grasped/understood viewports.

Sharing it for them:

func _ready():
	get_viewport().set_physics_object_picking_sort(true)
	get_viewport().set_physics_object_picking_first_only(true) # Added in Godot 4.3

[AThousandShips]

Nothing is missing, you can use it everywhere, and at any time, so stating that wouldn't help, and I don't think an example would be relevant either

If we were to state that nothing special is required everywhere the documentation would be flooded, if there's no notes about usage you should assume nothing special is needed :) that's basic logic

It's just a simple property and it only affects input so there's literally no example code you could add that wasn't just "this is how you set a property"

[jsbeckr]

I tried it out in 4.3-dev5 and it works for input_event(...). Just a quick question wouldn't it make sense to also work for mouse_entered()/mouse_exited() events. I updated the test project to visualize my point. After enabling both options the behavior feels quite weird (mouse_entered and mouse_exited are fired constantly when moving the mouse).

BugPickingZSort_mouse_events.zip

I think the mouse_* events should also adhere to the physics_object_picking_* options. Or am I overlooking something?

[AThousandShips]

That would require a proposal as it's a separate system I would say

[mnemoli]

The weird thing of mouse_exited/mouse_entered firing constantly does seem like a bug with this PR though. I guess because breaking early interferes with later exit checking code (in _gui_update_mouse_over?) though can't say I fully comprehend it atm. Maybe needs to continue looping with a check on whether the event was already sent, rather than breaking out.

[Sauermann]

@mnemoli do you have by chance a reproduction project, where mouse_exited/mouse_entered is firing constantly? If so, please report it as a separate bug.

[mnemoli]

@Sauermann

BugPickingZSort2.zip

I've extended jsbeckr's project above to add the shape_enter/exit and mouse motion events. If you wiggle the mouse around over two logos with sort+first_only off you get this:

With both settings on you get this, and clicking also fires spurious enter/exit events:

I think I see the problem here:

godot/scene/main/viewport.cpp

Lines 844 to 846 in fe01776

	if (mm.is_valid() && mm->get_device() == InputEvent::DEVICE_ID_INTERNAL) {
	send_event = false;
	}

If send_event == false then the break at L860 is never called. Moving L859/860 out of the send_event check makes all the events work as expected.

I'll raise a new bug.

[TheEliteCoder1]

At any time? Are you facing issues with this at specific times? If so please open a bug report, if not why are you asking?

No issues yet. Both work great. Really happy with it. Just lack of docs/example.

I just came across this while implementing a simple dragging behavior for Area2D objects. Similarly, I believe new Godot users might be expecting behavior that physics_object_picking_first_only and physics_object_picking_sort provides and come looking here. Including who haven't yet grasped/understood viewports.

Sharing it for them:

func _ready():
	get_viewport().set_physics_object_picking_sort(true)
	get_viewport().set_physics_object_picking_first_only(true) # Added in Godot 4.3

I would like this set_physics_object_picking_first_only(true) in godot 3.5 ? Is there anyway to do this since I've been working on this game for 3 years and Upgrading to 4.3 would change alot and I am not willing to go through those changes. I am creating a level editor where each instanized object of a packedscene Is Selected With an Area2d that uses a CollisionPolygon2D to detect input_event(). I need to only select objects in the highest layer. Unfortunatley, that is not in 3.5. Please Help! It is essential for my level editor since I will be allowing players to create thier own levels, thank you.

My input event looks something like this:

func _on_MouseArea2D_input_event(viewport, event, shape_idx):
	if event is InputEventMouseButton:
		if event.is_pressed() and event.button_index == BUTTON_LEFT:
			if Globals.Editor_EditingLevel:
				if get_parent().get_parent().EDIT_MODE == "DELETE":
					get_parent().get_parent().undo_redo.create_action("Delete Object From Level")
					get_parent().get_parent().undo_redo.add_do_method(get_parent(), "remove_child", self)
					get_parent().get_parent().undo_redo.add_undo_method(get_parent(), "add_child", self)
					get_parent().get_parent().undo_redo.commit_action()
				elif "SELECT" in get_parent().get_parent().EDIT_MODE:
					get_parent().get_parent().undo_redo.create_action("Select Object In Level")
					get_parent().get_parent().undo_redo.add_do_method(self, "select")
					get_parent().get_parent().undo_redo.add_undo_method(self, "unselect")
					get_parent().get_parent().undo_redo.commit_action()

[Luke9389]

Edit: I'm on 4.3.beta.3 branch

Am I blind or is there no setting for this in the Project Settings window?

I see this in the demo from above:
project.godot

[physics]

common/enable_physics_object_picking_top_only=true

But I'm not finding the actual setting in the Project Settings window. I'm sure it would work to just hard code that into project.godot but surely there's a field for it that I'm just not seeing.... right?

[akien-mga]

@Luke9389 The setting was removed following review. Instead, you should call the added method on the viewport:

get_viewport().set_physics_object_picking_first_only(true)