Support => NGUI 3 Support => Topic started by: SteBee on October 10, 2012, 09:36:40 AM
Title: Shouldn't raycasting honor camera depth?
Post by: SteBee on October 10, 2012, 09:36:40 AM
NGUI stores all UICameras in a scene in a static array sorted by camera.depth--that is to say, in the order they're drawn in. When raycasting to interact with a widget, the code runs through this array in the exact same order, bailing when it finds the first hit. This means that a widget in a background UICamera will intercept hits meant for a widget in a foreground UICamera that's actually drawn on top of it.
This is definitely wrong for my purposes, but it's an easy fix I can make myself. (Hooray open source!) My question is whether this draw-order hit detection is correct for anybody's purposes, or whether it should be reversed in master.
My fix was simply to change line 391 of UICamera.cs from
for(int i =0; i < mList.Count;++i)
to
for(int i = mList.Count-1; i >=0;--i)
Title: Re: Shouldn't raycasting honor camera depth?
Post by: ArenMook on October 10, 2012, 09:39:28 AM
Look closer at the sorting function.
Title: Re: Shouldn't raycasting honor camera depth?
Post by: SteBee on October 10, 2012, 01:09:01 PM
Well then I'm at a loss to understand what's going on. In default array order--which, you're right, was already front-to-back, my mistake--clicks are going to the rear widget. In reverse array order, clicks are going to the front widget. I'm using three UICamera layers (a background, a foreground and an interface overlay), with FingerGestures active on the bottom two layers, so there must be something weird about this configuration that's breaking things. Reversing the loop completely solved my problem, but now I guess I better dig deeper to fix it the right way.
Thanks for the reply.
Title: Re: Shouldn't raycasting honor camera depth?
Post by: SteBee on October 10, 2012, 07:08:51 PM
Okay, found it: The event receiver masks for each camera were set to the layer of the next camera in the stack, so the background layer was actually doing the event processing for the foreground layer. That's why reversing the loop (incorrectly) "solved" the problem. So, there's the lesson for others: Double-check your event receiver masks.