NGUI 3.6.1-3.6.2 depth issue

[frarees]

Hi there,

I have a scroll view with a grid inside. My hierarchy looks as follows:

• Scroll View
• Grid
• Row 1 (collider)
• Row 2 (collider)
• Row 3 (collider)
• Drag Area (collider)

Every collider is a box collider 2D (trigger). The "Drag Area" has a widget at depth 5, and a drag scroll view.
Rows are at depth 7.
The scroll view has a panel, with depth 2 (the only panel at that depth, and the topmost). Only the "cull" option is active on that panel. All the widgets have anchors to other objects, executing at OnEnable.

When I enable debugging with UICamera, it tells me it's colliding with Drag Area, but I thought the object to be hit is the one with the highest depth.

Last week I had this working properly, but today I've opened Unity again and it wasn't working.
I've updated to 3.6.2 with no success. I'm running Unity3D 4.5.0f6 on MacOSX 10.9.3.

[ArenMook]

There is no reason why this wouldn't work, so I'm not sure what to tell you. The only odd thing I see in your hierarchy is that the Drag Area is a child of the scroll view. It should be outside the scroll view (so that it's stationary and doesn't move when you scroll).

[frarees]

I posted it wrong, the drag area is actually outside. I had to disable it completely (losing that functionality of course) to make my grid able to work again.

If you get to find something about this, I'm interested. Seems like a bug with 2D colliders and clipping panels.

Thanks for support!

[Lari]

I'm using NGUI 3.6.5 but I have the same issue as described above, although a bit more complex structure overall. We're using 2D UI with the following structure, disregarding elements that don't overlap or not causing conflicts at all:

• "UserInterface" gameobject with a script to handle much of the UI interaction
• UIRoot
• UICamera
• "Windows" gameobject to sort the hierarchy more nicely
• Inventory Window Panel (depth 100)
• UIWidget set to provide a desired position and maximum size for the windows, BoxCollider2D (depth 0)
• UITexture background (depth 0)
• UIWidget set to the desired size of the inventory window (depth 0)
• UIWidget container for other inventory window stuff (depth 0)
• UIWidget container for inventory list and scrollbar (depth 0)
• UIWidget container for scrollbar (depth 0)
• UIWidget container for inventory list (depth 0)
• UIWidget with a container script for draggable items and a BoxCollider2D (depth 10)
• UISprite background for the list area (depth 11)
• UIPanel with soft clip on and a UIScrollView component (depth 101)
• UIGrid for all the inventory items
• UIWidget inventory item with a drag-enabling script and BoxCollider2D (depth 200)
• ...more of the items above

All this works just fine on the rendering side. Always has. However, draggable widgets inside the scrollview panel don't get UICamera hits at all if, and only if, the scrollview panel is using soft clip. In that case one of the colliders of the parents get hit even though they're in a panel with a lower depth and their widgets have depth 0 and 10. If I use any other clipping mode the widgets get hit just fine, although it will ruin our inventory window by rendering the item cards all over the screen of course.

I'm quite certain it's some type of a conflict because there would be a bigger commotion if this were to happen in many projects. I did actually make a new project solely to test this but couldn't reproduce it sadly. I've tried fiddling with depths but nothing has worked so far.

I've tried putting the draggable panel outside of the above hierarchy but still this happens. I also tried disabling or removing colliders that get hit instead of the items and while it does work, it lets mouse go through the UI and we use UICamera.hoveredObject to detect if (it's not null) we should not cast rays to the world on clicks.

I don't have time for it right now but I can try to make a repro case or just pack our UI scene into a package or something. I did check that it picks up a lot of fluff that is not needed to test it though.

[ArenMook]

This issue should be already fixed in the latest Pro version. If you want to test it, send me your OR# to support at tasharen.com.

[Lari]

That is good to hear despite us being on Standard license for now. I sent the mail despite the license mismatch, just in case you want to verify the fix like that.

Anyway, for now, we tested the issue with the UI converted to 3D UI and it works fine. Of course it only required me changing all colliders to non-2D ones and setting the camera event types accordingly.

[arun02139]

I wonder if this is related to this issue?  Not sure, so sorry in advance for not starting a fresh thread..

I have a prefabbed menu that contains a scroll view using soft clipping.  The hierarchy looks like this:

-(some nested widgets)
--Scroll View (depth=9)
---Grid
----Button 1 (depth=10)
-----Label (depth=11)
----Button 2 (depth=10)
-----Label  (depth=11)
----Button 3 (depth=10)
-----Label (depth=11)
----Button 4 (depth=10)
-----Label (depth=11)

The goal is that only 3 buttons should be visible within the scroll view at a time.  The first time I instantiate the prefab everything works as expected, but the next time I load this menu, I get the behavior that the (UI sprite) buttons are not clipped, but strangely the UI Labels nested below them are (see attached image).

FYI I've also been using my own pooling system to keep these UI prefabs disabled but in memory when I don't need them, which has been working fine for several months as far as I can tell.

In the Unity editor, If I disable/enable the offending (UI sprite) button's Collider 'auto-adjust' check-box, it temporarily fixes the problem until then next time I close and open the menu.

Using NGUI 3.6.7.

Cheers,
Arun

[ArenMook]

Pooling system is likely the culprit. NGUI elements must be disabled when they are not in use. Reason being, active NGUI's elements must be underneath the UIRoot or some other panel. If they aren't, then NGUI forcefully makes them be a part of the root, and if you later change the parent you need to tell NGUI that you did that -- NGUITools.MarkParentAsChanged.

[arun02139]

Spot on, Aren.

I added 'MarkParentAsChanged' when retrieving a pooled object (after re-enabling it) in my PoolManager class and this issue disappeared like a puff of smoke

Thank you kindly ~

Arun