[Questions/Thoughts] Unity 4.6, the new UI system

NOTE: If this is available to read about somewhere and I missed it, please post links!

To keep it simple, I'll refer to the new system as uGUI2.

After watching the overview of the new UI system I (like most of you) got the feeling that things are finally getting organised and we are getting closer to having a true, built in, solution. However, there are a few important things that were not explained in detail (since this was only an "overview"), and some left out (?). I'll go over them one by one, some of them reflecting about differences to NGUI (since the author of NGUI was a "helping hand" in the development of uGUI2).
Mainly there are some major flaws in NGUI that I hope have not infected uGUI2 (Note: I'm not trying to be a douche, NGUI is an okay product for a third party plugin, but comparing to say the iOS/Android-way of doing things it got some major design and feature-flaws which is what I hope won't make it into uGUI2).

The arguing going on below is IF it is the way I hope it's not. So if I'm wrong, I'd be more than glad to know!

The "anchor system":
Now, just the name "anchor" gives me shivers down my neck, since this sounds and looks a lot like the anchor system implemented in NGUI. That is, for me, horrible news. Not sure how to explain this in a few lines, but I'd really like a more thorough explanation (like, where are all the input values?). If I want it to half the width of another rects width, where do I input "0.5"? And if I want it to be 50% of the width + 10px, where do I input the +10 constant?). There is a mystical anchors-array visible in the video, however it is never folded out... What possible values can be altered manually? Seriously, dragging around anchors is a very bad practise for more than just "close enough", temporary, placement.

Most importantly about this anchor system: How does it compare to a REAL constraint system? A constraint system is so basic at it's core, and gives so much flexibility (and is very logical to think about). After using NGUI's anchor system for a day it just felt extremely hacked in and with loads of special-cases (just looking at all the if-statements and every-frame-updates made my heart hurt). Basically constraints work by taking one property-value from rectA (say left), run it through a linear equation, and output the new value to some property on rectB (say right). Now with a very basic, logical and readable equation rectB is placed with right edge to rectA's left edge with some easy to manipulate values. The equation is just outputValue = inputvalue * multiplier * constant (never seen that before!). Read here to get a better understanding of how apple does it. This is what I created myself for NGUI, and the speed at which you can get content in and have it automatically & smoothly handle different resolutions is... a lifesaver.

Talking about Rect Transform, what events can be expected? Not talking about the hardcoded messages (OnColliderTriggerWhatever) but actual callbacks that can be registered to to notice changes in size etc.? And a followup questions that I was actually leaning at: Is the anchor system event-based or updated every frame?

Answer: "It's event-based."

Edit.
In the video I saw no way of determining which object to anchor to (parent was default). Is it possible to set this manually? (Expecting the answer to be yes of course, just checking!)

Property Binding:
Property binding is one of the most essential components of a flexible and easy-to-use UI framework, but nothing was unveiled in the video about this... Is this implemented of some sort, or have it been overlooked? I wrote a very handy binding system for iOS once. It allowed you to, with just a small line of code, to hook up one property of some sourceObject to a property on another targetObject (with the ability to choose direction). No pulling, no expensive checking, just event-based binding. Think MVVM.
Ideally it should be possible to do it nicely in the inspector (just exposing some property through code, being the "source", and then hook it up to different "targets"/widgets which will update automatically.).

- Value Converters:
This is part of the property binding and MVVM.
Value converters are a very clean and handy way to "puzzle up" none-matching values (eg. a boolean converted into some usable int value). It's extremely flexible, and conforms to the "open/closed" principle. You'll avoid the need to add custom stuff to others code that will be replaced in a future update (which is a stronghold you never want to get into).

Empty view/widget:
Looking over the list of possible UI components, I didn't see an empty, "invisible", view. Setting up UI is not always about sprites and labels, but a lot of the setup consists of positioning, grouping and encapsulating objects to setup a logical hierarchy. Of course there is some core base-component representing a single view. Is this "Rect Transform"? Anyways, it should definitely be available in the UI-menu.

Clipping subviews:
IF Unity was smart enough to make a core component representing a single view (no graphics, just the logic behind a frame etc.), there should really be the possibility to chose "ClipSubviews = true/false", meaning that if a childView (say an image) is moved outside the bounds of the parentView, it will be clipped/culled. Now, I saw the masking ability but again, this is a core feature and should really be an option on all UI components (deriving from the core "view"-component).

Aspect/Content Mode:
This really just means the possibility to determine how the content of a view is laid out, think about an image for sake of argument. The ImageView is the UI component dragged around and determines the bounds, position etc. The "Image" is the rendered content inside the ImageView. The most common is: Fill, Aspect Fill & Aspect Fit.

• Fill: Stretch the image.
• Aspect Fill: Stretch the image until the bounds of the view are fully covered, still maintaining the aspect ratio of the raw image. This is where "ClipSubviews" comes in.
• Aspect Fit: Stretch the image until the first edges touch, making the image fit into the bounds and still maintain ratio. If the ratio differs from the bounds, there will be an empty border (think you get the point).

That is some of the things I had on my mind! Feel free to comment, but add the correct headline from the corresponding part so it's easy to follow up!

Cheers!

 

This one is easy

You create an empty GameObject with a regular transform as your 'group parent', and it behaves as expected - full 3D rot/pos/scale transforms behave just fine as part of the hierarchy.

Or you can add a Rect Transform as a component and it replaces the standard transform. A Rect Transform simply appears to be a constrained Transform with some extra parameters.

 

My foundation toolkit supports data binding using the MVVM / MVC pattern. It uses a variation of IPropertyNotifyChanged (I included the changed value in the event in order to skip a reflection call), but, other than that Is pretty identical to WPF style development.

I should have a beta using vs 4.6 up sometimes next week.

http://Unity3dFoundation.com

 

The anchor system is also easy:

You can set the anchor to a range of min (top left) - max (low right), for a basic gui you might stay within the range of 0 to 1.
You can go outside of the parents box if you set the anchor to higher or lower values.

The actual meaning of anchor represents a Scaled Rect compared to the parent's size.
The pivot is the point of fixation (in local space) around which the child is transformed (rotation, scale, etc).

So far all of this is done in a nice percentage like factor system within the ranges of 0 to 1.

If your screen is 1090 pixels then 0.5 will get you half that amount, as will 800 * 0.5.
Correcting for aspect ratio could be done with a simple aspect ratio correction script that sets the scale of the main canvas rect.

The pos vector and the width & height are where the insanity creeps in for me, as it suddenly changes into a pixel based system, with little to no translation visible for us.
You should add a 'Reference Resolution' to the root canvas as soon as you create it, this should help resize the gui when using pixel based offsets.
For me this is met with very mixed results, where I already scripted a class to autoscale the ancient UnityGUI, this 'Reference Resolution' should do the same but for some reason fails, even after toying with the width vs height slider.
I have not yet gotten it to properly resize my gui, am I crazy that I just want the root Canvas to fit the screen and then everything on it to actually remain on screen, without having to micro manage all the anchor settings?

The 'Reference Resolution' is not set to the screen-size in the editor at this point, so anything you do and or change is met with a few teething problems, dis- and then enable the script to actually update when you set the resolution (I think they might have forgotten a OnValidate in the component) and to see the results resize your Game window a bit to see it stretch and shrink.

Setting your anchors with the built in Rect Transform presets makes a lot of sense, until you start to think about multiple resolutions and orientations, then it quickly becomes your downfall as it is doing all kinds of silly things without explanations.

Try creating something like a skill tree where anchors to a specific screen corner makes no sense, I was hoping the scaling would have become a non-issue, but I hope they fix this with better explanations, sourcecode or fix the reference resolution component.
I hope they release the source (or maybe it can already be found somewhere) for the new GUI components, they are unsealed so that is already pretty great.

 

Thanks!

Alright, then I just hope unity includes it as a UI component in the list (to acknowledge that they understand the importance). Again, this is a core component for building a solid UI (readable, logical and <some more fancy words>).

______________________________________________________________________

Thanks for your answer, always nice to see valid third party alternatives! But my question/concern is more directed towards Unity implementing this into the engine itself.

A UI system goes like this (most important first):

1. Rendering the UI
2. Positioning the UI
3. BINDING THE UI

So I'll be deeply concerned if they forgot number 3!

______________________________________________________________________

Thanks for the lengthy and detailed answer! Sadly, this new "anchor system" seems to confirm my fear (multiresolution issues etc.), same issues I instantly saw with NGUIs anchor system (not saying this is the same, but the name suggest they work with similar logic)... Guess I'll have to check, but I will for sure be ready to port my constraint system the second I start seeing these issues. The beauty of a constraint system is that if setup correctly, it just works in all possible resolutions, doing exactly what you expect.

______________________________________________________________________

Any info on what events can be hooked into on the Rect Transform? If there is no "OnRectChanged"-variant, I'll be more than sad!

 

please feel free to share such a system with Unity or the community ;-)

 

I'll first check out the new anchor system before I say to much, but if I port my constraint system, I sure will!

 

Stealing this thread a bit.
In short, after reading through the docs and viewing a few videos I am left with the impression that implementing a relatively complex UI that is heavily driven by code (and uses callbacks for many types of actions such as drag/drops etc.) seems more cumbersome than with for example NGUI?
I had hoped the various events would have been more easily exposed and setting up elements through code would have been more streamlined, but perhaps I am getting the wrong impression?

I would really appreciate if someone with NGUI and 4.6 experience would weigh in a bit. Many thanks in advance!

 

> I would really appreciate if someone with NGUI and 4.6 experience would weigh in a bit. Many thanks in advance!

I just finished moving over my databinding / mvvm library to uGUI. I was able to get everything I used over easily. The only area of confusion is regarding to the "repeater controls" (Vertical Layout Group, ect) which seems to misbehave from time to time without much explanation.

That said, I have not played with drag /drop. Maybe post some code ?

 

Place a EventTrigger component on your UI object, select a trigger event from the drop down, add the gameObject to the slot for the event and from a dropdown select the component or object the event affects or a function from a script and if there is a var to pass there is a slot for that too.. No need to script the events if that ain't yer thang as this components handles all that with a nice GUI.

 

Use an EventTrigger component. OnPointerDown set a boolean such as startDragging = true in a function StartDragging() and OnPointerUp set startDragging = false in a function StopDragging(). In the Update loop if startDragging = true then send it to an UpdateDragging() function that has your code in it. Just drag and drop your scripts in the slots, choose your functions from the dropdown menu and supply any variables you may need to pass to your function.

 

Trying to reply to a few things here that were not already covered in previous replies.

It's event-based.

No. Similar to how Transform positions are always relative to the parent, the same is the case for RectTranforms.

For custom control of the layout of UI elements, you can write scripts that partially or fully control the positions and/or size of a RectTransform based on whatever logic you want. The built-in auto-layout components do this as well; for example the HorizontalLayoutGroup, VerticalLayoutGroup and GridLayoutGroup.

We don't have any property binding in the new UI system.

What you're describing is achieved just with a GameObject with a RectTransform and nothing else.

We have an entry called Panel, which usability testing showed was the term many people expected to find. It does include an Image, but that can be easily be removed if you don't want it.

Look for the Mask component.

 

What I meant was that we do use code for a lot of the UI as it is complex and driven by external factors. We want to do it that way, and the inspector workflow (while nice) will not work for us. We need efficient script access.
NGUI, while sometimes convoluted, is easy to tap into via scripts. From what I have seen this far the new UGUI seems to be the opposite - simple to set up via the inspector, but quickly gets cumbersome when you try to control / set it up via code. But that is just going by a bried read through of the docs and reading threads here. I may be wrong, and I hope I am. Comments?

 

It's designed to be fully usable by code. If you're having trouble or find something to be cumbersome, we'll need more specifics to be able to provide advise or consider revisions.

 

Thanks for the reply!
We have not jumped in yet and please do not interpret my questions as any form of criticism - I am merely seeking feedback from those that have jumped.
I do so since threads like this one makes me a bit cautious, and the percieved need to hook up the event system which is something that is fairly transparent and easy to set up in NGUI:
http://forum.unity3d.com/threads/creating-a-gui-from-code.263563/#post-1743543

 

I played about with it a bit yesterday and as I posted in this thread, http://forum.unity3d.com/threads/creating-a-gui-from-code.263563, creating UI elements from code without using prefabs seems rather cumbersome. I'm wondering if there aren't any functions to just create a button in one go, like when you create one through the Editor GUI.

If there aren't any yet, that'd be a great addition imo.

 

What is the reason you don't want to use prefabs?

There are a million different ways to create a button with different look and feel. It's unclear to me why we should have code to create a very specific type of button, when you can just create a prefab that has the look and feel you want and then instantiate that from code.

The only reason we don't also just use prefabs for the menu items in the GameObject > Create UI menu is due to some technical issues with how built-in assets in the Editor work, that doesn't apply for user-created prefabs.

 

"We don't have any property binding in the new UI system."

Actually the UI system shouldn't have it's own binding. Unity as a whole would really really (really) benefit from a generic system with editor help. I teach 100's of students and it'd be a huge help to have something in the editor to use real c# events. Events are key to good structure but Unity provides no help or guidance, especially for beginners.
Currently I use a modified (and bug fixed) version of the free Asset Store component "ZZSignalSlot". True 2 way loose coupling with real c# events is the best. It's great, but a bit cumbersome to have to add a whole component for each event listener. If components could show C# events just like they do public variables and allow drag-drop to other compatible functions elsewhere (eg start drag, grey out or remove GO's and components with no compatible functions, drop. Show from listener their subscriptions), it'd be beautiful.
Please consider for Unity 5 as every part of the engine could use it.

 

Did you check the new Event System from Unity 4.6?

 

I was thinking of how to replace our current GUI framework and integrate the new uGUI into our workflow. Right now we're very code focussed in this area, so I kind of got stuck thinking along those lines. Been mulling it over since then and I think you're right prefabs would probably be the way to go. After all, something needs to replace the old GUISkin with all its styles.

 

Since this thread appears to have Unity attention, I am crossposting.
We need to be able to render the GUI in front of everything in the scene without relying on separate cameras. Can the new UI be coerced to always appear in front (via custom shader or some setting)? This is crucial for HUD-type UIs in Rift-enabled situations (where you do not want additional cameras). TIA!

 

I have been playing around with the new GUI system for a day now. I really love how a lot of things are now easily achievable from core Unity. However there is one thing in the anchoring system I haven't found a solution for yet (but maybe I'm overlooking)

How can I scale an image with the height of the parent, while the width is following so the aspect ratio is kept. E.g. if i have a rectangle I want it to scale with the height off the screen, but it must stay a rectangle.

In NGUI I can set the aspect property of the widget to "BasedOnHeight" and then aspect to 1, any idea how to do this in uGUI2 ?

 

I'm found uGUI very easy to use too. I'm completely removing NGUI from my project as it has some bugs which drive me crazy.

Currently only one widget I found missing is multi selection widget like listbox or combobox. I'll probably create one with scroll rect and mask widgets.

 

@runevision

To be more specific. We currently have a lot of objects for which their property GUI in game is dynamically build based on an xml which tells our game which properties the object has and how they should be represented. We have well over a 1000 of these objects in our library at the moment so to create a complete prefab with the including the full panel etc would be too much work.

Hence my initial approach of simply trying to generate a button from code. I'm now thinking that considering we also need to style all the buttons, comboboxes etc it might be a better idea to prefab this smaller elements and then write a framework to reuse those.

 

The Camera Overlay mode in the Canvas always renders in front. For other modes you can achieve it by using sorting layers (see the docs).

 

Set the Image component to retain aspect ratio. Then make the rect of the image sufficiently wide that it will always be constrained by height, not width. You can move the pivot to control how the image is aligned within the rect.

 

What if I need the children of the image's RectTransform to be also sized appropriately?

Unrelated: I need to, in script, get the number of elements that were laid out in a single row by the GridLayoutGroup component. Am I missing a way to do this? This is essential for controller input because if you're making a selectable grid menu, you need to know which element to switch to if you move the selector to the next row.

 

a quick question. can I use uGUI besides IMGUI? would the z order of ugui order correctly with the GUI.depth of IMGUI (I suppose not)??

 

Thanks! But as far as I can tell, sorting layers are not documented? I searched the docs in 4.6 and came up short. The property is documented in the scripting reference, but no where do I find a description of its intended purpose or how to leverage it?

 

http://docs.unity3d.com/Manual/class-TagManager.html

If you can't find something by searching also try clicking the documentation button inside the editor. Sometimes this is faster than searching through all the results (or if there are none).

 

First of all the new UI is sick!

The 'No Data Binding' part however is a bit sad. I suppose a good plugin will eventually appear that will solve this as NDATA did for NGUI.

Although I find the attitude of Rune's answer to that a bit odd. It is somewhat of a cornerstone of any good UI system and he brushed it off as if it isn't something Unity bothered with. In fact I'm a bit shocked that there wasn't even a hackish / cumbersome / lame / etc. attempt at giving us some form of data binding.

Guys do you really think it's not important?
Imagine WPF without data binding...scary isn't it

At the very least you could have said 'Guys we are going to look into it'. A little white lie is ok now and then.

If I misinterpreted that statement then great...we have a shot at seeing in-built data binding some day

 

Just a quick questions: Is the beta an actual "Update" (like the install file suggests) or a standalone install? Just wanna double-check so live projects aren't jeopardised!

 

Actual update.

 

Zzz...
I have two installs of Unity (to support old projects in 3.5.x), does it automatically choose which one to update or do I get to do it myself? In that case I can install another one just for this version. We are in the last step of releasing an app for a client so I don't wanna get inte ugliness at this moment...

 

Dunno

 

Thanks! But based on that page, sorting layers are only relevant for solving UI conflicts (ie. wanting one canvas always in front of another), it will not help us to ensure the UI is never blocked by "normal" 3D geometry... correct? TIA!

 

WPF uses XAML by default and as such some kind of data binding is required. The new GUI on the other hand is usable without data binding. It is possible to e.g. use events to achieve almost the same.

 

Unity update installers always overwrite the folder called "Unity" in your applications folder. ALWAYS rename that folder if you want to keep the current version. I have multiple folders, Unity44x, Unity452, Unity46.
Also, turn on "always show project wizard" to ensure that you are not accidently opening the wrong project with a new version (you may not want 4.6 to touch your live project(s)).

 

I'm sorry - I can't help on that in any way since I haven't encountered that problem yet.

 

Nice, that is actually how it already is. However, when I try to install the latest Unity 4.5.3 (to later update to 4.6) it says during the install "Action: Upgrade" (See attached print)... Defudge? There is no "Unity" folder available in the Applications-folder.

I just want to install a clean version, leaving the others intact.

 

That's of course true and it's not like it's impossible to do by hand but lack of 'nativeness' if you will...is disappointing.
Anyways lets wait and see what the community is able to provide in that regard.

 

I have installed 4.6 on OSX and the only thing I did was rename my existing Unity folder in Applications to Unity45 and then installed 4.6. No overwrite and the various versions live happily ever after, side by side.

 

Here's my thoughts on the new UI system: It's superb. I am very very happy with it so far!

 

So far I love the new UI system as well.

On question that occured to me: Is masking only possible with strict alpha or is interpolated alpha masking possible to do as well?

 

The only bug I've encountered so far is with a camera transition I made. To achieve a "shutter" effect, I've been changing the X and Width values of my camera so it "closes", like a shutter (sort of). That still works fine in the editor, but when I try it on a Nexus 4 everything gets weirdly corrupted during the change. Like it's all mashed together.

The transition was only placeholder, so it's fine, but it's obviously a symptom of something.

 

Hello,
I have the following question:
I want to implement an Interface-Element which is shown by a click on a special object. The now activated UI should have a fix screen Position (bottom frim left to right). Should I implement this with the new GUI-System or with the old one (Which would let me implement this easier?)?

 

What prevents you from trying it out?

 

In fact, I already have implemented this as prototype a few months ago with the old system. I want to have some infos like the performance of the new system relative to the old one etc.., would it be easy to implement this with the new one (I have to learn how the new GUI works, but I currenntly dont know it).

 

There's probably not much in it, in terms of performance. It's still worth learning the new system, and replacing your button would be a good way to do that.