UIKeyNavigation directional filter logic

[BeShifty]

I'll keep this short:

UIKeyNavigation should be comparing direction vectors relative to the camera, instead of world space. Currently the system breaks down if your UI/Camera heirarchy has a non-zero rotation, if your UI is 3D, or if your buttons have different Z-depths (for whatever reason). Here are the necessary changes:

1. static protected Vector3 GetCenter (GameObject go)
2. {
3.         UIWidget w = go.GetComponent<UIWidget>();
4.         UICamera cam = UICamera.FindCameraForLayer(go.layer);
5.         Vector3 center = go.transform.position;
6.  
7.         if (w != null)
8.         {
9.                 Vector3[] corners = w.worldCorners;
10.                 center = (corners[0] + corners[2]) * 0.5f;
11.         }
12.  
13.         center = cam.cachedCamera.WorldToScreenPoint( center );
14.         center.z = 0;
15.         return center;
16. }
17.  

While I'm at it, a layer mask would be cool to restrict navigation between buttons on different layers. Sometimes we have a map screen and a UI overlay and we don't want to be able to navigate between them freely. This would just involve adding a public LayerMask field, and throwing out targets that aren't in the mask in the Get() loop. Let me know what you think.

[ArenMook]

Not sure what UI being in 3D has to do with this, to be honest. Whether your UI is 2D or 3D, you should be using a separate camera to draw it, not the world camera. If you're using a world camera to draw your UI, then you want to use custom navigation anyway, not UI navigation. The UI camera doesn't move, whether it's 2D or 3D -- so this change isn't needed. Still, no harm in your change -- just not sure why you need it.

[BeShifty]

I think the change would simply decrease the possibility for user error due to say placing different UI elements at different Z-depths, as well as expanding the out-of-the-box capabilities of NGUI for 3D map screens, center on child effects with 3D scrolling effects, etc. You can of course cache some of this data for efficiency, although I'd say once per nav input isn't a big hit.