Why doesn't Unity's GUI work for you?

News & General Discussion
1
  • What’s wrong with Unity 3D’s UI?
  • How will the new GUI fix those problems?
  • Why not use 3rd party UI?
  • Do 3rd party UIs have their own problems, or is being 3rd party a problem?

There’s a fair amount of harping on Unity’s UI, to the point of necessitating the “Is the new GUI out yet dot com” announcement. But I can’t seem to find many rationals.

I’ve tried Unity’s UI, looked at 3rd party packages, and I don’t find them to be particularly pleasant to work with myself. What doesn’t work for you? Why?

Or is it a case of “why can’t the GUI just make itself already?”

EDIT: confessional time - I’m making a UI middle-ware for Unity: uiink.com

2

#1
it lacks features, doesn’t have that good performance and is not that comfortable to use
#2
It will address all of the issues (hopefully)
#3
Because people don’t want to pay extra

3

It’s lacking loads of features, it’s slow, it eats up draw calls like nobody’s business, it’s ridiculously awkward to use, and I DO use a third party tool but I shouldn’t have to when we’ve been promised a new GUI system since the 3.X cycle began. At this point we have to use third party solutions to get around the deficiencies in Unity’s “features” at almost every step.

4

It’s extremely slow, it results in horrible code and code flow, isn’t extensible, it lacks many features that you’d expect, it’s oververbose for the task at hand… then we get onto the niceties that you want with a modern system such as some form of WYSIWYG editor, the ability to save/load in layouts in a markup of some sort and so on.

It’s just a very intensive way to do something that from the perspective of a user/scripting it should be a lot simpler and quicker. Look at stuff like Qt, Flash, even HTML and compare that to the GUI development process in Unity, everything is far too explicit there’s no sense of templating or convenience use of callbacks, the code itself can’t reflect the nature of the layout either, in most GUI systems you can completely separate function code from layout code and make use of anonymous coding, doing so makes it so much less painful to do layout, have a workflow between artists and developers when creating layouts, reuse function code, build dynamic layouts, create editors, write clean clear code that visually reflects heirarchies and grouping within your layout in a more succinct way, create import/export functions to dynamically create layouts from e.g. xml files edited elsewhere by your design team.

There’s a lot that can be done to improve the design strategy of the GUI within Unity.

Third party solutions aren’t much of a solution either, not that they can’t be good, but you’re making yourself dependent on a third party with whom you only have a tenuous contract, they may simply stop developing their product, maintenance and support in general can be flaky and is an unknown quantity. Not through any fault of those developing or selling those products, but just the fact that if it’s some guy on his own working away in a room somewhere life can happen to that guy, family problems, health problems, anything, and then as a customer you’re kinda stuck which may be a problem if you’re mid project. If UT develop an in house solution then you’re going to feel that little bit more secure about using it, and that it’ll be around for some time to come.

5

The two things that kill it for me is that it overloads drawcalls, and none of the widgets are set up to be used with touch input very well.

If it had lower drawcalls and it felt like actual native iOS UI, I would be good with everything about it.

6

The newer mobile devices arent really draw call limited anymore.

7

I find it quite hard to make anything complex or dynamic. I don’t find it as bad as some people are making it out to be, but I don’t feel as if it should take over 1000 lines of code to make an upgrade/store menu.

1 Like
8

I don’t use it because the limitations in the framework of the thing are dramatic. Coming from a modern programming background, Unity’s GUI is a train wreck. Let’s start with the obvious reasons why: it’s buggy, slow, eats memory like a poor, overweight New Yorker eats McDonalds, is not extensible, and hasn’t gone anywhere or undergone any major revisions.

But there are other reasons as well. First of all, it produces lengthy code (a modern setup will be 1k lines or longer) and it encourages bad programming practice by mixing GUI drawing code with event handling code, which you should never do. Which brings me to my next point - no callback support, which means clutter like nobody’s business.

At this point, virtually everyone is using a third-party tool to cover Unity’s definicies. So jump on board - forget about using Unity GUI at all and use NGUI or similar - you’re in good company. :wink:

9
  1. Performs too slowly, no visual editor
  2. I can only hope
  3. What I’m doing currently
  4. Rare for the fast 3rd party GUI’s to have simple textbox operations like selecting areas of text or copy+paste
10

So what exactly is ‘wrong’ with the 3rd party packages? Have you used NGUI? What is wrong with it that you don’t like it?

11

Because it isn’t the 3.5 GUI.

12

…where do you draw the line? A lot of phones out there still have 512mb of ram. I use a couple devices with 512mb to test with as that’s my baseline. In the past, going up to 100+ draw calls would crash depending on what they were and whether code/physics was affecting objects.

13

That doesn’t change its overall slow performance and it doesn’t excuse inefficiency at all.

14

First, I’m going to be a detractor. So far, I like the Unity GUI system, I haven’t had any problems with it, and I’m honestly not sure what all the fuss is about.

While the Unity GUI set provides basic controls only, I wrote myself a few wrappers that vastly improve the usability of those assets, with abilities including tweening location and color, and built-in tooltip support for hoverable elements (PC/Mac Only, obviously). I have further improvements planned to simplify the usage of this enhanced Unity GUI further with audio and possibly built-in execution of a remote function via the delegate types introduced in .NET 3.0.

The ‘new’ GUI may or may not remove the need for me to do this work, but I hardly feel it wasted. The only obligation Unity Tech has is to bring us the tools to do the job with, not the ‘would be nice’ features that we’re all more than intelligent enough to implement ourselves, or sell on the Asset store for those who have pursued other paths (which, makes you smarter than me, because Arts are hard!) Even then, I may attempt another project which takes my GUI assumptions and totally blows them out of the water, which means I will have to be extra-smart with whatever non-standard GUI setup I will need to implement in that exceptional project.

3rd Party Tools may or may not expand on Unity GUI, or go a totally different capability. If I need that totally different capability, there is no doubt the 3rd party tool is correct for the job; if I just need a basic way to present a player with information that is stylish and customizable, there is no reason the default Unity GUI isn’t sufficient for the job. This can be mitigated, however, if the 3rd Party tool is either easier or more difficult to work with; a worse workflow will push me back towards doing what I can with the Default GUI, while a more permissive tool will push me towards that other tool if the situation requires it. Not all situations are created equal. So far for my needs, the Default GUI is more than sufficient for what I need.

For the final question, being third party is not a problem; ease of implementation, flexibility, and suitability to the problem at hand are what make me consider or reject a tool. A game is a software package, among other things, and I need every edge I can get with building it quickly and correctly, and being able to understand what I’ve done six months after the project is done and I have to go look at it again for some reason.

EDIT: Reading the thread, I see a lot of what the OP is trying to cut through - lots of snarling about the Default GUI, but no substance to the responses on why Unity’s Default GUI sucks as much as one would be persuaded to see from all the responses. Even the argument about iDevices with 512MB of RAM is at best a half-argument, because no one appears to have even tried to obtain benchmark data between Unity Default GUI, NGUI, and any other popular options out there for this worst-case configuration, let alone more standard ones. I’d like to see this data myself; if the honestly-procured data is good enough, you could even convince me to change my stance. Being an engineer, I do love to see efficiency…

15

^^ you don’t develop for mobiles do you?

16

Show me the metrics, pretty please. Obviously if mobile is your target, show me your benchmarks against mobile; if your assertions are true, it will undoubtedly appear in the data you reveal.

Unity Pro has a profiler that comes with it for those of you rich folk, and for everyone else, fortunately a good benchmark is not too difficult to accomplish [C#]

Note: the given link involves an external framework and runs in Visual Studio; something similar could easily be cooked up in Unity, and data written to a file using simple System IO commands.

Note II: While in my post I disagree with the anti-Default-GUI position, I do not necessarily deny that it has performance problems, either. I want to see metrics backing your position up. All I ask is that you back your arguments with data. I have already said my opinion, whether accurate or otherwise, and since that is out of the way, I am open to civilized discourse backed by evidence as to whether my ideas are valid or not.

17

I do a bit of editor scripting work (for example my Editor Charts package in the asset store) and quite like working with Unity GUI.

My original motivation for moving away from it was draw calls, I don’t know about hard data, but I do know a few (mobile) generations ago I had some pretty major performance issues due to draw calls. I expect thats not so much an issue now, but I also expect if you have complex graphics or a complex UI that the draw calls will still be an issue.

Another issue is the time it takes to set up GUI, for example heres a UI (free on the asset store) that I built for NGUI and Unity GUI: http://jnamobile.com/samples/ColorableFantasyUI.html. I got the NGUI demo done in about 30 minutes. The Unity GUI skin took about 90 minutes (excluding the colouring code). Note that I didn’t try to make them exactly the same erring on the side of whatever was easier to set up in the given framework.

Layout and advanced controls in Unity GUI are still hard. I’ve written multiple GUIs and editors but I still run in to issues. Some simple obvious layout or control will sometimes cost hours of research and experimentation instead of minutes. Obviously frameworks will help with this (in house or from the asset store), but its still something I run in to too often.

I’m hoping the new GUI will be similar to the old one; a few key improvements and it could be quite good :slight_smile:

PS Excuse the asset store advertising :slight_smile:

18

I didn’t say there was anything “wrong” with them per say. What I’m mostly interested in is what works for people and what is preventing solutions from working for people. Singling out NGUI; I understand it solves many of the issues people have with the built-in GUI - and I’m interested in what those are. I haven’t tried using it, only having watched the official video tutorials. From my point of view personally, coming from working with GUI’s provided by platforms (Android, iOS, Qt, GTK etc), it doesn’t mesh well with how I’m used to building UIs.

I don’t want to bash on 3rd party GUIs or even the current built-in GUI - what I do want is to find out what works, what doesn’t and what people want. Each GUI system for Unity brings something to the table, I would like to be able to sort out what the pieces are (both good and bad).

19

@JohnnyA Have you tried bench-marking the two versions of your UI on mobile? You said they weren’t exactly the same, but the results could still be interesting. @Asvarduil makes a good point regarding actual testing of performance.

What about draw calls? Did NGUI help with reducing the count?

20

There’s little doubt that Unity GUI is draw call hungry. Create a UI with a bunch of components and you will get a bunch of draw calls.

This is an only an issue if draw calls are a limiting factor on your performance. In the past on mobile this was very common. Its less so these days but still could be an issue.

CPU usage for Unity GUI tends to be a high because you run through your code each frame. To some extent you can code around this, but it requires more through/effort. Performance on the scene I mentioned earlier for NGUI is approximately*:

NGUI - CPU: 0.5ms per frame GPU: 1.5ms (Draw calls 10**)
Unity - CPU: 1.5 ms per frame GPU: 1.5ms (Draw calls 22**)

I did notice both had a few spikes at start up NGUIs were longer although not larger. Note that both these GUIs do nothing if not interacted with.

Interestingly I did a strategy game where the entire game was rendered with NGUI. Because there were a massive number of widgets (10k+) I had to make some updates to NGUI to stop it recalculating things it didn’t need to. Applying this to even the simple scene reduces CPU by about half (in the case of the game it was the difference between 10fps and 60fps… NGUI does an awful lot of calculation it doesn’t need to).

  • Don’t consider this hard data, if you want to check it out yourself just set up a GUI with 20 or so elements in Unity GUI and NGUI.

** Draw calls wouldn’t be affecting performance here. Note NGUI draw calls could be further reduced by using less panels.

EDIT: @Cake - Funny you asked I just did that.