[Official]New UI System.... coming in Unity 4.6

Yes, but with the way NGUI does it, there's no need to drag things around. You can put the gameobjects wherever you want in an organised fashion then just change the draw order. Unity's way seems like it could make a mess of things by forcing you to put gameobjects in certain positions.

Also, if we instantiate some buttons that have to overlap in a certain way, we might have to instantiate them backwards or something, so the last button is at the top of the hierarchy? Rune mentioned you can change the order through code, so maybe not.

 

I don't see how having yet another layering system makes less of a mess of things...

 

Something tells me that they are more likely to be web developers than programmers then. From the looks of it, with the new gui system I could be finished with the flow and layout of the entire UI in an hour tops, and it would then be ready for content to be dropped on top of it.

From what I'm seeing, it would be so easy to prototype in unity and functionally have it done, even if I had to make some scripts.

 

That's an amazing job you've done there, guys. Looks really nice, and the anchor workflow looks great!
I have a few questions.
1. The button has a "On Click" event. Is there a way to add "On Pressed" and "On Released" events as well?
2. Does alpha work as expected for child objects (parent alpha affects child alpha)? Is there a way to circumvent this for a single child object (example: a background image has a text label as it's child. I want the background to always have 0.75 opacity. By default this will affect the text label's alpha. Is there a way to make this specific text label have 100% opacity, ignoring the parent's alpha?)

 

This looks really interesting so far.
What I'm wondering however is if old scripts using the current GUI API will still work after the update?

 

It'd be nice if these were added, but if they aren't, you could use animation events to accomplish the same thing.

It looks like the canvas alpha can be used to affect all the children, instead.

 

Including drag-and-drop reordering?

 

The other question is if it is possible to reorder the UI elements at runtime? So if I wanted to have a canvas appear behind another slide out and then slide on top of the one that it appeared behind of? There aren't a lot of help method on the current Transform class. Are there going to be things like Transform.InsertAt(transform, index) and GetIndexOf(transform)?

 

+1

With NGUI for example you can change the UIPanel (= Canvas) depth by script and also there is NGUITools.BringForward(GameObject go);, NGUITools.PushBack(GameObject go); and stuff like that.

 

Looks awesome. Anyone have info on handling different textures for different resolutions?

usually it's been the case that you need 1x, 2x and even 4x textures.

 

... and also no possibility, right? Last time I used NGUI its layering system was the main reason why "last time" is a while back.

The hierarchy sorting order for the new Unity GUI is absolutely awesome and a lot of fun to work with. It also keeps things tidy and clean in the scene.

 

would be great to be able to take SVG formats created in illustrator, or even XAML (UI prototyping) and have import capabilities.... for true resolution independence.

 

One question about this. If I don't use any of the OnGUI system, will the default GUI skin (including the fonts and such) be included in my build? Or is it only included if it's actually getting used?

 

Oh, that's fine then. I was afraid that some mumbo-jumbo was required for it to work.

That's a real bummer. So you can't create a "panel" (parent game object) with content (children), fade that panel out and have all the content fade out automatically? Doing it by hand is a REAL pain in the ass: we'll have to create additional scripts for each widget in the hierarchy. This script will have to somehow update the widget's actual alpha to include their parent's alpha (which will also be affected by it's own parent). And that script would have to be executed last in the execution order, to take into account any other scripts which might modify that widget's alpha.
I think this needs to be a part of the rendering pipeline and work automatically.
Really guys, I can't believe you or any other beta tester, didn't run into this problem.

 

I suspect the solution is to use a "Canvas" for each window that you want to fade in. Since a canvas's alpha DOES affect its children.

 

Usually in GUI you want parent-child relationship to work in a way that parent is behind the child. For example window to be parent of all its buttons and the Window would also render behind them.

What you are describing is that hierarchy view is always sorted bottom-up. This would mean that parent-child would also be reversed. Parent would be below the child and when you expand a parent, it would awkwardly expand children on top of it (?)

Other option I'm seeing is that you want some kind of zig-zag where siblings are ordered bottom-up, but parental relations top-down.

Personally I don't see neither of these options as being superior to what we have now, but maybe I completely misunderstood. Can you provide some insight?

 

That does sound like something masks should be capable of, or at the very least makes more sense for that kind of parent/child relationship to be the domain of masks. I could see issues with trying to structure the hierarchy for programming purposes, so I would be wary of that relationship in some way that wasn't a hundred percent explicit.

 

What if I have a button with a child label/icon I want to fade to 0.25 opacity when it's disabled? Or I have an complex objects, that has multiple labels and a button with a child icon and I want to be able to fade out the button to 0.25 opacity, and then fade out the whole complex object?
How many canvases can I have in a scene and is there a performance hit for using multiple canvases? Can I nest canvases? Are they really supposed to work for the kind of situations I mentioned?

 

This is great. Absolutely wonderful. More standard c# and less messages and other hidden stuff!
It really seems like Unity is going in the right direction in general on this matter; more correct and standardized programming APIs. Big thumbs up.

 

It seems like it should be very simple to create a "RecursiveAlpha" component to easily fade in/out groups of components.

 

It might seems so but it's not.
There is a multitude of problems of different complexities related to this problem.
You have a button which is basically a background sprite + child text label. You set your text to 85% opacity. You want to fade out your button and then fade it in again. So the buttons alpha goes to 0 and than back to 1. If you have a script on that button that recursively changes alpha of the child label, than when the button reaches alpha=1, the text child will also be alpha 1. But I need it to have 85% opacity. Okay, then we need to store the initial text alpha before applying the button alpha. That might solve the problem, until we have a really complex object with multiple widgets and we have to store the initial alphas for every widget. Or there's another script that changes the label's alpha at the same time as the button. Or the button has another parent that is also changing alpha.
This might look like a made-up example, but I've had to deal with this before, and it is a pain in the ass if it's not integrated into the system.

Multiplicative color is not something you might need for UI design so often. Alpha on the other hand is used extensively to create fade-ins/fade out, disabled states, etc. It is a really useful feature.
If you want, I can come up with a few real examples, with screen shots or even a real project using NGUI, to demonstrate a few cases and why I think this is important.
Thanks!

 

This is looking a lot better than I had anticipated! A big thumbs up!
I realize that it won't be 'complete' in 4.6, but it looks like a solid foundation.
One concern is the text-handling. I'm still on 4.3, so I don't know if this has already been fixed in 4.5, but the dynamic fonts are buggy at times. Upon re-building their textures to fit more characters, they sometimes fail to signal this to dependant controls which leads to jibberish characters (wrong uv).
Please stress-test the dynamic font system before release, especially on mobile platforms.
As it stands, we've had to resort to using bitmap-fonts or distance-field fonts since we can't trust the dynamic fonts.
Note that this of course happens more often when you use a lot of different character sizes for the same font.

 

Looks fantastic! I have a very GUI heavy app I was building a while back that I stopped work on due to difficulties with the instant-mode GUI (and I lost interest...) and this looks to be a fantastic improvement. Glad to see that it'll be a very open API as well. I look forward to seeing how text input boxes work, and I wonder how easy it will be to create complex interfaces with resizable, dragable windows and tabs (something nearing the complexity of an editor like Unity's). I hope that some higher-level standard GUI elements (like drop-downs, etc) are included as well, but I'm pleased to hear that they'll be easy to make ourselves.

Great work (you've been working on it long enough... ) and thanks for keeping the community updated with progress. Can't wait for "summer"....

 

Good god, it's real... it exists...

 

I have 3910 lines of old Unity GUI I stopped work on waiting for this and I was dreading porting it. Now it looks like via drag drop building in the hierarchy what I spent a month building (with problems still) can be done in 30 minutes.

My question is, and I've watch all 3 videos and read all the posts but can't remember this being asked directly and directly answered:

When I set up a old Unity GUI I noticed that even when I made icons at the correct scaled size for various game view port resolutions the icons were not scaled in the Unity 'Game' window, they were full size, although the 'Game Window' was scaled (I manually created Game view ports at various common device screen sizes). So now when I do this in new uGUI will the icons (sprites / menus) be scaled down as the game view port was?

 

This is a must have for a GUI system. When you want to fade out a panel which contains children, you don't want to dig into all the children to make them fade out.
It is like when GameObject disabled state was not herited into children, it was a pain and a miss conception.

Btw can you create some invisible widget used for placement ? like an invisible rectangle.

 

@goat,

The anchoring system should handle re-sizing elements based on the resolution of the target screen. "Stretch" ,discussed in the overview video, is one option for doing dynamic re-sizing. Based on the positioning of the anchors on your element you should be able to make sure something like a button always takes up the same relative screen space. Hope that makes sense.

 

Thanks.

That makes sense if they are scaled correctly to begin with. The 'Game' viewport I created at 1920x1020 that Unity scaled down should also scale the sprite at the same ratio as soon as the sprite/icon hits the Canvas.

So it does quacks like a duck and looks like a duck and walks like a duck so I hope it's a duck. Or that saying goes something like that.

 

Looks good, got a couple of questions.

1 ) Will there be a table/cell/div/grid GUI element for things like inventories, crafting or dynamic lists? (maybe even optimized with culling)

2 ) How much of this is scriptable? I mean can you create layouts on the fly? Do you have to use the GUI event system or can you attach events using scripting?

3 ) Does the canvas also support non 2D elements, e.g. could you use the GUI's mouse events system to turn some real 3d buttons into functioning buttons? Or have the GUI texture on a more complex shape than a rectangle.

4 ) Does the system support spline drawing? If not, is it planned?

5 ) How fast is the text rendering? e.g. full large block of EULA text rendering on an IOS device, is that feasible? Or what about lots and lots of smaller text elements rather than a single large element?

and

6 ) Can you set formatting styles within a block of text, e.g. emboldening just one word?

Which leads to...

7 ) Are there plans for an HTML rendering element?

and

8 ) Input Fields... I didn't spot it, but is there a checkbox to enable text editing/input field within game? Ideally inline edit rather than specific input field as input fields always force their own formatting which is often ugly and it would be nicer to just drop a text field, have an enable editing checkbox (scriptable), and give it your own border/background, or even overlayed button (rather than giving the user a caret on hover always).

 

I want to add my "vote" for having some kind of simple alpha control for children. Even if you don't feel like it should be present in every component derived from "base" UI component, you should provide some light-weight "Panel/Container" component with that functionality as I doubt that having multiple Canvases just to fade buttons (with text and/or icons) here and there is a good idea.

 

Per managed to post just minutes before me with some of the points I wanted to make, but I'll make them again so it's clear how much demand there is.

1) What sort of support is there going to be for grids, lists, and other dynamic layouts? The anchor system looks very flexible but without some higher level logic it looks like it will be a nightmare trying to create a scrollable list box in code containing an arbitrary number of contents, never mind a grid or table view. The video was 90% about static GUI layouts where all that changes is relative size whereas probably 90% of the GUI problems I've ever faced have involved dynamic GUI elements, where the content changes significantly. Ideally there would be some sort of object similar to the GUILayout Horizontal/Vertical system which takes ownership of the anchoring of its children. I'm also hoping that there would be some intelligent comparison of content size to parent size and automatic creation of scrollbars. Any comment on this?

2) How practical is it going to be to use this from script? In particular, let's say my artist/designer creates a list box for me. Is it possible for him or her to set it up so that I can basically write one or two lines of code to add a new line of text or a new image to it? I can have this in HTML, and in pretty much any non-game retained mode GUI made in the last 20 years, but for some reason game UIs tend to make this harder than it needs to be, and the video here is not too encouraging in this regard.

3) Input - How is it detecting mouse clicks? Does it prevent clicks passing through to items in the scene view? And text - is there any support for text input at all? And if so, does it consume keypresses?

 

I like this a lot so far. I went into the video thinking "How is this better than NGUI?" and the video then spent a lot of time talking about the anchoring system which is by far my biggest complaint with NGUI, and also one of the things Aren is most stubborn about being willing to change. This anchoring system looks far better, so I'm excited about that. I also like the simple screen-sized canvas and the event binding as well. The rect transform looks very useful. I like being able to move the pivot point in the editor (can we please get that on regular 3D objects as well?). The one thing I kind of prefer in NGUI is being able to use Tweens for animation instead of using the actual animation window. For simple things like button expand or OnHover color, I prefer just typing in a tween value and duration rather than needing to use the Animation window. But I can probably integrate that on my own.

 

Hey guys, I was just thinking, generally I draw my UIs on photoshop using a fixed resolution as base (generally 800x480 for android) and I always make small borders for my windows/boxes/buttons/etc because if I make thick borders for my windows/boxes/etc when the OnGUI draw them on 320x240 devices almost half of the window could be taken by these borders, I was thiking if the new system has anything to handle this, I thought about it because I saw a component called "Reference Resolution" with width and height inputs... I don't know if you will understand what I mean but, here goes my question...

edit: also, because the padding/border and other GUIStyle attributes doesn't scale down with the resolution..

 

Yes! That means the code I stopped work on last November will be about 500 lines not 5000 lines. This will do more to help programming good games as just about any other new feature.

 

I made the background invisible on my menus to avoid such hassles...my GUI is like floating 'pictograms' (also because I don't want to translate languages)..,but in your case with the new uGUI it should scale the borders and such proportionately I think.

 

wow from what ive seen in the video where u demonstrate new gui is soo amazing it looks like its done right, exactly what we all need / needed. great thread, very nice, keep up the communications it really great to see you all creating all these official threads and being here in the trenches with the soldiers...

oh is there anyway to get access to unity 4.6 beta ( mean honestly anyone developing using unity needs it) cause who in their right mind wants to use the current ui when u could be developing it using the new most amazing / easiest / looks the greatest way...

honestly after seeing the video. im sold ship the thing. i dont want to write another line of code for existing ui.. why make me throw it all away after 4.6 comes out. make beta 4.6 accessible to those who want it. at least they could be using it (and giving u feedback)...

 

This looks outstanding. I have been wanting to create some business applications with Unity and the layout engine you demonstrated will take me a long way. Bravo.

I may have missed this, but what is the length of beta and expected release for 4.6? Thank you.

 

How's the event system looking? I'm really hoping that Unity helps clear up the various event systems around the place. It seems that everyone and their dog has their own, it'd be nice if there's a single standard one we could all work to.