UICamera Event occlusion

[Maxii]

I have a mostly transparent plane with a trigger collider in 3D space that I use to detect onScroll events, allowing me to scroll in/out to/from it. It has no other purpose besides this.

There are other 3D gameObjects with colliders behind the plane that I want to be able to detect onClick/onSelect/onHover, etc. As is right now, the plane collider intercepts these events, but does nothing with them of course. The only way I've been able to figure out how to get the gameObjects behind the plane to get the onClick/... event is to detect it on the plane, then do a raycastAll to see if another object is behind the plane where the cursor is located, then relay the event to that object.

While this will work, I wanted to ask whether you know of another way to accomplish the same thing with the event system that would avoid needing to repeat a raycast?

EDIT: Looking for further insight, you've mentioned in the past that for Windward you exclusively sent all events to the fallThrough (mask = nothing) and then sent them where you wanted them to go from there (using UICamera.Raycast and UICamera.Notify I presume), thereby allowing some routing judgement (like I'm referring to above) to be applied before forwarding them. In looking at the UICamera code, doesn't that result in 2 slow SendMessage() calls for EVERY event?

With your addition now of event delegates, have you changed the approach any? I guess I'm looking for insight into how to use the event system for best performance as you add more flexibility to it.

[ArenMook]

What I'm currently doing in Windward is this:

1. UICamera's fallThrough is set to the UICamera's game object itself.
2. I use UICamera.onClick, UICamera.onPress, etc delegates, subscribing to them as needed. They work as long as fallThrough has been set to something.

This way I don't need colliders, and everything works as expected. Events go to their proper objects, as well as to my delegates.

[Maxii]

I think I'm missing something here.

How do all the delegate-subscribing script instances figure out which of them is the target of the raised delegate when the included GameObject is always the fallthrough? Without a collider associated with the subscribing script, Raycast returns nothing and therefore the gameObject included in the raised delegate will always be the fallthrough, won't it? It has been my assumption so far that each subscribing script instance would have to compare its gameObject to the delegate's included gameObject to determine that it was the object clicked on...

When Notify is called to run through the delegate invocation list, doesn't that also generate an unused SendMessage to the fallThrough?

[ArenMook]

Fallthrough object is irrelevant. UICamera.onClick, UICamera.onPress etc delegates are just that -- static delegates. You subscribe to them from wherever you like to receive a copy of all events. There is nothing to know.

This is only for generics, a copy of events. The actual events will still go to their proper target like they always had. Before NGUI 3.7 you had to set UICamera.genericEventHandler to achieve the same effect, and there could only be one, and it would receive all events. Now it's selective, and you can have multiple listeners.

[Andresfdezb]

What I'm currently doing in Windward is this:

1. UICamera's fallThrough is set to the UICamera's game object itself.
2. I use UICamera.onClick, UICamera.onPress, etc delegates, subscribing to them as needed. They work as long as fallThrough has been set to something.

This way I don't need colliders, and everything works as expected. Events go to their proper objects, as well as to my delegates.

I'm bumping this because I'm trying to achieve something similar and I can't get it done. Is there a way to make the fallthrough object ignore the events while the mouse is on a ui element that has no collider?

[ArenMook]

That's not what Fallthrough is for. Fallthrough means nothing else hit it, so you are now over a background object. It's the last resort. If you want something to prevent the event from reaching to the fallthrough object, then that object must have a collider.

[Andresfdezb]

The reason I'm using a fallthrough object is because even if I attach a UICamera script to my world camera it doesn't get the onScroll event (I'm not sure why it doesn't get it because it gets the other events perfectly). So I set the fallthrough objecto to the world camera and if i scroll on a ui object then the UI gets the event, and if I scroll outside the UI then the world camera gets the onScroll event. If I click on a ui object with a collider, then the ui gets the event, and if I click outside the UI then the world camera gets the event. But If I click on a ui element that has no collider, then it is the world camera (i.e. the fallthrough object) that gets the event.
So in order to prevent this, I must attach a collider to the ui elements that have no collider, right? Sounds terrible (I would need to attach colliders to a lot of objects that don't get interaction with the user), maybe instead I need to figure out why the world camera doesn't get the onScroll event when it has the UICamera script on int.
Thanks.

[ArenMook]

I generally simply attach a collider to a widget covering the window, and adjust its depth so that it's behind everything else. ALT+SHIFT+W, ALT+SHIFT+C, ALT+SHIFT+-.