Draw order being bound to transform hierarchy issues.

So, I'm working on a property editor style control in uGUI and am having lots of issues caused by the fact that the transform hierarchy is the draw order.

One example of this: I have a combo box which is a prefab'd control. It contains a scroll rect to hold the items which comes up when the user clicks on it.

When you open the combo box, the items in the menu after the combo box control draw over the drop down list panel because they are later in the transform hierarchy (and must be for the layout group to order them correctly.)

To fix this, I added another rect which draws after the entire property editor draws, and reparent the drop down panels to it. However, now that the drop down panel has a new parent, it doesn't move or scale correctly.

Is there any way to change the draw order without changing the transform hierarchy? The coupling of hierarchy == draw order == layout is convenient, but an extremely tight coupling since you often want those to be different, as in this case.

 

here's a screenshot with hierarchy, for reference..

 

I agree 100%. Dummy parents a decent work-around, but it feels a bit dirty. Personally, I think a "priority" setting would be nice, so that for all elements of the same priority the hierarchy is used to determine the drawing order. That way we could easily set the odd ones out the be drawn either earlier or later.

 

In many GUI systems, dropdown boxes (and things like them, such as tooltips) are implemented as separate windows. That approach should work for you here; create a new canvas (Screen Space - Camera), ensure it's in the same sorting layer as your main panel, but with a smaller 'Order In Layer' value, and use that to hold your vertical list of elements. It should render on top of the rest of the GUI as you require. The potentially tricky part then is to get it to go away when clicked on (and potentially even harder, get it to go away when you click somewhere else entirely).

 

There really should be a sorting order for GUI components. Dropdowns of various types and information dialogs currently need a lot of special attention to go in front of everything. A simple priority setting like the sprite system already has would be much better. It would be even better if the root object had its sorting order in such a frontmost dialog case, and the rest of the hierarchy inherited that and added 1 for each step down.

So a reusable infobox could have a priority of 100, making sub-elements 101 etc., similar for a dropdown (but starting at 10, 20, whatever makes sense). Just expose one simple setting and make children inherit

 

@orb I am finding this exactly. I have a persistent popup window setup in the first scene. With Screen Space - Overlay the next scenes Canvas is then on top of the previous. It doesn't seem obvious how we manage the z order of the canvas in Screen Space - Overlay.

 

That won't actually work here, because moving the object to a different canvas means it will have a different parent, and thus move/scale differently as the screen is resized. And even if it could be made to work through hackery (possibly by having a dummy object in each canvas and copying the vertex positions from one to the other - ugh), it certainly wouldn't be a robust solution able to work with different types of canvas's, etc..

 

@phil-Unity
added:
http://feedback.unity3d.com/suggestions/ability-to-decouple-draw-order-from-transform-order-in-ugui

 

I just needed to prototype a GUI with multiple panels, some draggable, that needed to be clickable to front. I came up with a solution that feels sort of dirty, but it works for now.

• Each panel is on its own canvas
• Dragging changes the canvas Z coordinate to -10
• End drag moves it back to 0 (order is preserved)
• Each canvas has a component that changes the depth to -10 and back to 0 on click (this strangely works fine, and only responds to clicks on actual controls)

I need a shower now

 

@phil-Unity I seem to remember looking at this, although I couldn't move a screen space - overlay in z unless I make it a child. Thanks for the info and I should add, obvious

@orb seems workable also, thanks.

 

NGUI currently uses "depth," which is similar to the priority system used for the sprite renderer. For UIs of moderate to high complexity, I find using numerical priorities to be much more painful than relying on the hierarchy order. Often is the time I have found myself reordering dozens of prio values yet again, all the while wishing for this feature (we shipped our game on 4.2). So I wouldn't want to lose that.

As for the original problem, wouldn't the use of sorting layers address that?

 

I'd like to raise my hand here in support of this. It is *incredibly* obnoxious to have to choose between "render tooltip on top" and "use all the powerful anchor/pivot features for auto-layout".

Right now the only way to do what I want is 1) create tooltip, 2) Canvas.ForceUpdateCanvases, 3) reparent with SetParent(true), and if I wanted to have a tooltip that moves with resolution changes, I have to do that again every time the resolution changes, and if I want to have a tooltip that follows an object around the screen (like a talk bubble), I have to do that every FRAME. Augh.

We just need an "always on top" checkbox on a canvas renderer or canvas group, and all it has to do is pop those element renderings out of the normal sequence and stick them at the end.

I was hoping the Z of the rect transform would have this effect, since it is exposed, but no. :-(

 

Thank you again for your responsiveness. I look forward eagerly to the day I can graduate to my pro license: You all have made me feel confident that it is a safe investment for the future.

 

Is there an ETA on when this will be implemented? I just downloaded 4.6 RC 1 and don't see any sort controls.

 

What's the correct workflow for adding a Canvas to a UI component? I have run into issues when I copy the Canvas component from my base canvas and add it via Paste Component.

When I use that process to add a Canvas component to a UI element (in this case a Panel, i.e. an object with a Canvas Renderer and Image script on it), I get four instances of this error when I run the game:

m_TransformInfo.localAABB.IsValid()​

And when I exit play mode, I get four instances of this:

IsFinite(outDistanceForSort)
UnityEditor.DockArea:OnGUI()​

The panel (and its parent canvas) are in world space, if that matters.

 

Cool, I'll try to reduce my current project down to a reasonable standalone repro case and try to get you guys a reliable instance.

Also, what is the proper path for adding a Canvas component? I don't have it in my Components menu.

 

I've tried to isolate the elements that are causing problems, but for whatever reason the issue goes away when I pull the problem GameObjects into an isolate scene.

Is there some other way I can help track this down? Or is there a more appropriate way to add a Canvas element?

 

Actually, I just discovered something that hopefully will help you track down the bug: it only happens in my case if Canvas is enabled at game start.

If I have the Canvas component toggled off in the inspector and then enable it on the first frame that the game starts, the error does not show up. There also aren't any errors when play mode is exited, either.

So my guess is that it's some sort of timing issue, where on game start the Canvas script is trying to pull in some sort of bounding values for its in-world object (the object I see the bug on is the child of a World Space UI element), but the in-world object hasn't fully instantiated yet so it's grabbing all 0s or something. If you wait for scripting to kick in, then whatever the Canvas component is waiting on has had time to initialize.

For reference, I'm using uScript to enable the component, using the On Graph Start event and the Toggle Component action.

 

Heya! I am still having this issue on 4.6.7f1! The frustrating part is that it seems to only actual cause the rendering to fail under certain conditions. I will try to come up with a reproducible version, but I am seeing behavior where nested canvases (with forced draw orders) are causing things to not render.

 

UP just to remind devs that this is a feature asked since the beginning of the UI ...

 

Just another reminder about this.

UGUI has always been a major failure point of the engine for us. We've had to manually recreate every high-level UI component to work around scaling issues, ridiculous garbage allocation, etc., and are finally at rebuilding the dropdowns to prevent the default allocations (i.e. instantiating an instanced template for every single dropdown), which is made more difficult by the fact that we can't just override the draw order. I will be scrapping all of this before long and just replacing the whole thing with manual drawing on quads- it would be far lass hassle than trying to box everything into UGUI.

 

Bump!

Please at least add an extra Z-order sort, so we could manually sort our objects while keeping a sane logical object hierarchy and use of prefabs in the canvases!
An additional "[X] Also use Z-order" on a canvas can't be a lot of work, but would be a huge improvement! If objects have the same Z value, sort by hierarchy order, otherwise sort by Z value.
This would allow us to quickly and mostly painlessly fix batching problems caused by hierarchy order...

 

up

 

Are there any new solutions for this as of today?

I have a complex UI with lots of effects, and the effects are usually bigger than one button and overlap with other buttons. They are attached to UI elements and move with them, but are intended to be shown on top. Like an outline or shine. As a result, they break batching dramatically because it has to draw one overlay before drawing the next UI element.

I really feel like any tool to affect the layering of children would be extremely useful to manage batching.

 

I forgot I posted here a couple of years ago, was still subscribed and just received a notification from above. It may not be immediately helpful, but, to follow up from what I posted back then, I finally gave up with UGUI and started building my own UI library for Unity, which may be of interest to some here.