Philosophy behind "who-gets-the-click": interaction of raycasters/canvas/groups/buttons/ect

[Note: I posted this Question before, but it seems to have been swallowed up during the latest forum-troubles. Oddly, it still appears in the search, but the link in the search does lead to a quite different thread.]

Like many other people, I have trouble with “which item receives a click”.

My scene has 3d-objects that have a Collider and are clickable thanks to a RayCaster on the camera.
It has the typical UI-Buttons.
It has UI-Panels (=Images) that implement drag&drop with the help of IBeginDragHandler / IDragHandler / IEndDragHandler.

Problem is (like usually) that the clicks are not received by the element that should receive the click.

I found answers/solutions to the problem, mostly along the line of “insert a Canvasgroup here and there, switch the BlocksRaycast-Setting and the IgonoreParentGroup-Setting to true on that one and…”

That might work in a specific instance. But I found it points to a much bigger problem:
I have no idea why these solutions (should) work.
What is the general philosophy behind that? How is the “hierarchy” of click-receiving defined? In which case does one object receive the click, In which case does the other, in which case do both and in which case does neither? How do Raycaster, Colliders, Buttons and other methods (like IBeginDragHandler) interact?

I would be glad if someone could tell me about some kind of resource about this. An article would be great, but something clear in the documentation or a video would also be good.
Of course I am also happy about people who could explain the “big picture” right away.

I believe I responded to this thread before the reset; I’ll try to write a similar response, again.

I’m pretty sure there are methods to return multiple hits from your raycast. So, if you ever need more that’s 1 way to do it.
Normally, I think just the first one gets it in many situations for interfaces.
That ties in with CanvasGroup setting (for the UI) where you can stop blocking raycasts - for instance, when dragging an item in UI , you can disable ‘blocks raycasts’ so that you can receive notices from elements “under” the item you’re dragging. The same idea can be found in the world by setting an object to a layer that is ignored by the raycaster.

There are times where writing a small script can help you “pass on” the pointer information in one way or another.
I helped someone write a small script to scroll a child ScrollRect vertically, while it was inside a horizontally scrolling one, for instance. :slight_smile: