Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Unity UI vs NGUI

Discussion in 'General Discussion' started by claytoncurmi, Jan 10, 2017.

  1. claytoncurmi

    claytoncurmi

    Joined:
    Jul 6, 2010
    Posts:
    168
    Hi all,

    Our company is going to revamp an existing 2D project. This project makes use of two major third-party 2D systems namely NGUI for UI and 2D Toolkit for gameplay elements. The project also makes use of some features available in Daikon Forge. I don't like having multiple third-party systems all doing more-or-less the same thing. A big chunk of non-gameplay code will most probably be recoded and I was wondering if I should replace these third-party systems with Unity's 2D and UI features or just retain one of them. How does Unity UI compare to NGUI? Are there any major issues with the current versions of NGUI or Unity UI?

    Thanks for your input,

    Regards,
    Clayton
     
    Martin_H likes this.
  2. Rin-Dev

    Rin-Dev

    Joined:
    Jun 24, 2014
    Posts:
    574
    If you're just gonna write all the code again, then use UGui. Ngui is good and perfectly acceptable to use, however with what you've said about multiple third party systems, I say make the switch.
     
    Joe-Censored likes this.
  3. bluescrn

    bluescrn

    Joined:
    Feb 25, 2013
    Posts:
    642
    UGUI does most of what NGUI did, and with more flexibility and nicer workflow. Don't expect significant speed gains though, UGUI isn't super-fast, much of it is written as C# scripts.

    UGUIs biggest weakness is text rendering. TextMesh Pro is pretty awesome though, filling the gaps in functionality there (although if you need to do localisation to Chinese/Japanese, things get more complicated, and it might not be the right solution)

    I do kind of miss NGUIs methods of dealing with texture atlases, though - especially as you could mess with the source code if you wanted to do something special (such as generate separate RGB and alpha textures for better compression on mobile)
     
  4. claytoncurmi

    claytoncurmi

    Joined:
    Jul 6, 2010
    Posts:
    168
    Hey guys thanks for your input, much appreciated! @bluescrn yes localisation to Chinese/Japanese is required at some stage. What are the text rendering problems I can encounter when using UGUI?
     
  5. arkon

    arkon

    Joined:
    Jun 27, 2011
    Posts:
    1,122
    I use NGUI for the UI and 2d sprites in game, no need for tk2d or other sprite engine, just use NGUI for all your 2d needs.
     
  6. bluescrn

    bluescrn

    Joined:
    Feb 25, 2013
    Posts:
    642
    Mostly the usual stuff - identifying which glyphs are used in your game text, building fonts containing that set of glyphs, and handling font swapping across the game when needed.

    Which works if your text is all static and included with the game... but if you ever need to display text downloaded from elsewhere, it may contain glyphs not included in your fonts, and you might end up having to use a dynamic font (and a big TTF with a complete set of glyphs) for certain text (e.g. leaderboards with chinese names)
     
    Arsonistic, drawcode and angrypenguin like this.
  7. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    Beyond me that uGui is a few years old now and still has problems like this..
     
  8. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    To be fair, isn't that an issue for everyone displaying character based languages? Unless you plan on shipping a font with 4000 unique characters with your game, you'll always run into this problem.

    There is a reason why the alphabet is considered as significant to written language as the zero was to mathematics.

    Unless there is something I'm missing here.
     
    phobos2077 and Martin_H like this.
  9. bluescrn

    bluescrn

    Joined:
    Feb 25, 2013
    Posts:
    642
    Localisation issues are issues with TextMeshPro or any other bitmap/SDF font system. UGUI's dynamic font system is good for localisation, but it's weak at everything else (limited formatting control, no inline images, can't do nice outlines/dropshadows/gradients, etc)

    An ideal solution would probably be one with all the TextMeshPro formatting/effects control, but with the ability to dynamically generate extra glyphs on demand from a TTF, but in signed distance field format. You'd still want to pre-bake all the frequently-used glyphs, though, as creating the SDF data is rather slower than just rendering a glyph to a bitmap
     
  10. Stephan-B

    Stephan-B

    Joined:
    Feb 23, 2011
    Posts:
    2,269
    Just chiming in to share how some of my users are handling localization for Chinese, Japanese and Korean and Latin based languages.

    Most Studios will have language files which contain all the text / known characters used in their project and for each given language / groups of languages. Using the "Characters from File" option in the TextMesh Pro Font Asset Creator, they will then create the necessary font assets which will contains these characters for those languages or groups of languages.

    For Latin based languages and given their character set is limited, users will typically create a single (Primary) font asset for each of the fonts they plan on using (ie. Helvetica, Arial, Impact, etc.). Sometimes, users will break up Cyrillic and Greek into another or two additional font assets and assign them as Fallback to the Primary.

    For Chinese, Japanese and Korean and given their character sets are much larger, users will create one Primary Font Asset which contains all the known characters used in the project for each of those languages. Although the Chinese language contains over 60,000 characters, even text heavy games rarely contain more than 1,000 to 1,500 characters. Most of the time between Simplified Chinese and Traditional Chinese, you end up with less than 1,000 characters which easily fits into a single font asset.

    Handling the known text for any project and Latin based languages is usually as described above and fairly straightforward. Handling user input / unknown characters for Chinese, Japanese and Korean is where it gets more complicated.

    Prior to the introduction of the Fallback system in TextMesh Pro which allows characters to be distributed into multiple font assets, many TextMesh Pro users would create their font assets as described above for the known text and actually continue to use Unity's Dynamic Font System for the unknown text where user input is required. Given the known text tends to be larger and more stylized where the improved text rendering and dynamic styling capabilities of TextMesh Pro shine most, this worked great and given user input text tends to be smaller and plain in terms of style and formatting, using Unity's font system worked fine for them.

    Now since the introduction of the Fallback system many users now use the Fallback system to handle even the unknown characters. For example, in the case of Chinese support, users will still create a Primary font asset which contains all the known Simplified and Traditional Chinese characters used in the project. Then for the unknown text (user input), they will create potentially 3 additional font assets which will be used as Fallback and assigned to the Primary Chinese font asset. Again although the Chinese language contains over 60,000 characters, the Chinese government has published a list of 8,105 characters which is known as the Table of General Standard Chinese Characters which are essentially all the characters found in electronic media. This table is split into 3 groups of 3500, 3000 and 1605 characters. So, again the Primary font asset will contains all the known characters, the first fallback will contain the 3,500 minus those in the primary. The 2nd fallback will contains the 3,000 minus those in the primary and lastly, the third fallback will contain the remaining 1,605 minus those in the primary. Depending on how many characters the primary actually contains, it might be possible to only need two fallbacks instead of 3 to handle the Chinese language text.

    The process for Japanese and Korean is similar although for Korean you will want to include all 11,272 Hangul characters which can easily fit into (1) primary and 2 to 3 Fallback. Again note these fallbacks are only needed to support user input / unknown text.

    Like I mentioned before, when you look at the actual number of characters used in a project even if it supports Chinese, Japanese and Korean, it is surprising how few unique characters are actually used.

    Basically everything I covered in this post is covered in the following video about the Font Asset Creation process in TextMesh Pro. The following video covers the Fallback system and how you can also use icon / symbol font libraries like Font Awesome as well. The Fallback system has also been improved since those videos were created where it is not possible to assign Fallback font assets to the fallback themselves. Sprite Assets can now also be used as Fallback.

    Anyway, this is a pretty long post so I'll stop there. Should you have additional questions about any of this, please feel free to ask :)
     
  11. 00christian00

    00christian00

    Joined:
    Jul 22, 2012
    Posts:
    1,035
    IMHO NGUI is still much more advanced than uGUI,easier and more importantly faster(like night and day).
    That said, I still went for uGUI cause who know how long NGUI will be supported yet and I would like to avoid another extra package. If you have an heavy GUI I would say go with NGUI otherwise stay with uGUI.
    What bother me about uGUI is that it seem there is no development at all other than few bug fixes here and there. They don't even bother to integrate the improvements the users made since it's one of the few open source part.
     
  12. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    4,044
    I made a full switch to uGUI.

    Personally, I prefer NGUI still. It just felt more empowering and natural.

    uGUI is easier to use and has more widespread support.

    Performance wise, uGUI is very bad compared to NGUI. Enabling and disabling large numbers of images (inventory screen for example) is very, very heavy in uGUI.

    At a high level, I personally very much dislike uGUI design decisions and code architecture. I really wish they stayed truer to NGUI's philosophy. But some of the uGUI visual improvements are really pleasant to use.
     
  13. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,436
    I'm using uGUI and I naively thought I can just make some info text in the hud by updating a bunch of text components every frame. But holy S*** do these string operations cause insane amounts of gc allocs (20+ kb per frame in editor 0_o), and I'm already using the stringbuilder class. In case someone knows something that could display numbers with bitmap fonts, but without the string conversions, let me know.
     
  14. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    9,042
    There are a lot of tricks and practices you can employ to get uGUIs performance on par with NGUI, it just takes a while. That was certainly a nice thing about NGUI, it just handled that stuff behind the scenes.

    I haven't touched NGUI now in a couple of years, and wouldn't go back. The flexibility and deep integration with Unity as whole. Plus there are some great features and tools developed by the community.
     
    Arsonistic, Yukichu and Kiwasi like this.
  15. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,436
    Has anyone ever compiled a list of the features and tools that the community made?
    I'm asking because I know there are some gems on github for other things that are easy to miss if you only look at the assetstore. And I wouldn't even know what exactly to search for.
     
  16. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    4,044
    I haven't really profiled since 5.3 so this may have changed or improved, but dealing with the immense overhead of masked image oneable/disable (both huge memory allocation and general performance overhead) was kind of jaw dropping.

    IIRC (and I might be misremembering or maybe i didn't properly read all the code) uGUI implemented a pooling system behind the scenes ondisable. Maybe that helped some people, but in my use cases, especially when doing stuff like rapidly enabling/disabling hundreds of images it was really bad.
     
  17. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    9,042
    Martin_H likes this.
  18. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,436
  19. kaiyum

    kaiyum

    Joined:
    Nov 25, 2012
    Posts:
    686
    How do you guys ensure screen independent UI layout on NGUI? It is very easy in uGUI, plus in uGUI all anchoring is done on relative basis, rather than pixel offset scheme used in NGUI. Also as an official tool, I would go with uGUI if I were you. We have been using uGUI ever since a year(or more probably). Yes uGUI has a problem with text rendering sometime, a glitch which would go away soon I think.
     
    Martin_H likes this.
  20. 00christian00

    00christian00

    Joined:
    Jul 22, 2012
    Posts:
    1,035
    Don't know if it's always the same, but people have been reporting text glitches since uGUI came out...
    I only saw it in the editor(quite often), don't know how serious it is in playback.
     
  21. 00christian00

    00christian00

    Joined:
    Jul 22, 2012
    Posts:
    1,035
    I solved it by making a counter digit by digit and preallocate the string for each digit, then at runtime just assign the corresponding preallocated string of the digit.
    This is some code snippet to give you an idea, can't share the whole class as I would have to strip a lot of personal code. I am using dynamic fonts, but you can adapt it to bitmap.

    Code (CSharp):
    1.  
    2.     Text _text;
    3.     string ptrString;
    4.    
    5.     string[] numbers = {"0", "1", "2", "3", "4", "5", "6", "7", "8", "9" };
    6.     int[] power = { 1, 10, 100, 1000, 10000, 100000, 1000000, 10000000, 10000000};
    7.  
    8. void Initialize() {
    9.         if (UseReference) digits++;
    10.         Digits = new Text[digits];
    11.  
    12.         Digits[0] = transform.GetChild(0).GetComponent<Text>();
    13.  
    14.         for (int i = 1; i < digits; i++) {
    15.             Digits[i] = (Text)GameObject.Instantiate(Digits[0]);
    16.             Digits[i].transform.SetParent(this.transform, false);
    17.             Digits[i].rectTransform.anchoredPosition = Digits[0].rectTransform.anchoredPosition - i * new Vector2(Digits[0].rectTransform.sizeDelta.x, 0f);
    18.             Digits[i].rectTransform.sizeDelta = Digits[0].rectTransform.sizeDelta;
    19.             Digits[i].rectTransform.localScale = new Vector3(1f, 1f, 1f);
    20.             if (HideZeroDigits) Digits[i].enabled = false;
    21.  
    22.         }
    23.         isReady = true;
    24.     }
    25.  
    26.    void  DisplayDigits(int number, int ten,bool NotZero=false)
    27.     {
    28.         if (number < 0) number = 0;
    29.         int digit = (number % power[ten+1]) / power[ten];
    30.  
    31.         Digits[ten + (UseReference ? 1 : 0)].text = numbers[digit];
    32.         if (digit > 0 || NotZero || ten==0) {
    33.             Digits[ten + (UseReference ? 1 : 0)].enabled = true;
    34.             NotZero = true;
    35.         }
    36.      
    37.         if(ten>0)
    38.             DisplayDigits(number % power[ten], ten - 1, NotZero);
    39.  
    40.     }
     
    Martin_H likes this.
  22. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,436

    Awesome, thanks a lot for sharing that! I was thinking about preallocating number strings and then using them in the string-builder but you've gone one step further. I'm having quite a few numbers on screen. Do you know if the uGUI stuff gets batched, or if it's one drawcall per text component. In total I would need roughly ~100 digits or more. So if that's 100 draw calls the GC might be the lesser of two evils maybe?
     
  23. 00christian00

    00christian00

    Joined:
    Jul 22, 2012
    Posts:
    1,035
    If I remember correctly should be batched and if you have a big UI is not quite fast to batch.
    But even if it isn't drawcalls are way overrated. It doesn't make sense pay attention to it, unless you are way overusing them. Even an iphone 4 can handle a big amount of draw calls.
    Anyway you could change the code and preallocate up to 9999 or more and make slices of 4 or more digits each.
    Anyway are you sure you meant 100 digits? It's a lot and would be hardly readable, plus you are on desktop then( cause on mobile you'll never read 100digits easily) so GC is less than a concert for you.
     
    Martin_H likes this.
  24. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    You can blame C# for that. In C# strings are immutable. Meaning all string operations the produce strings also produce garbage.
     
    angrypenguin and Martin_H like this.
  25. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,436
    I guess that's another thing that was different in Obj-C ^_^.

    This is the current HUD and I'm only targetting desktop:


    With drawcalls I'm already hitting performance bottlenecks because I have so much dynamically instantiated stuff on screen. I'll experiment a bit, first step would just not update the HUD on every frame and only update if the text actually changes. Then I can timeslice the interval for checking if it changed. Thanks for your suggestions!
     
  26. claytoncurmi

    claytoncurmi

    Joined:
    Jul 6, 2010
    Posts:
    168
    Hey guys thanks for all your responses... much appreciated! I am still designing the game and I haven't arrived to the point were I can say which UI system to use but with your feedback I will be able to make a more informed decision.
     
    Martin_H likes this.
  27. Inter-Illusion

    Inter-Illusion

    Joined:
    Jan 5, 2014
    Posts:
    598
    I'm sorry for clearly advertising a plugin here, but I think it is very relevant to what is been discussed in this thread!

    I recently released I2 SmartEdge. It is not a replacement for uGUI or NGUI, instead, it is an script that integrates with either of them and enhanced them with lots of extra features.

    One of the features of I2 SmartEdge is that you can use SDF and MSDF fonts to render pixel perfect texts at any size while using just a fraction of the memory. It also adds text Justification, better wrapping and faster best-fit, per-character animations, more RichText tags, and a lot more.

    Besides, SmartEdge removes lot of the lag and spikes in uGUI because it handles in a different way the bestfit and wrapping. I'm also working on better caching, which will increase the performance even more! See here the roadmap.

    Regarding localization, I2 SmartEdge can either use a premade SDF/MSDF font, or it can use any dynamic font. Which means, that for most languages, you could bake a custom font, and fallback to a dynamic one for Chinese and other big languages. The drawback is that while using a dynamic font, you wont get the pixel perfect rendering, but you will still have the other features (animations, justification, etc).


    Also, if you want to go a bit further, I'm also the creator of I2 Localization, which could handle all the location for you, I mean: switching the fonts based on the languages, organizing all your translations into spreadsheets, automatically translating your texts, etc.

    But again, you can do your UI in either uGUI or NGUI and then add the I2 SmartEdge component to save memory (smaller font that looks even better) and fill in some of the features missing in both uGUI and NGUI.

    Sorry for the shamelessly advertising, but it was relevant to how making uGUI and NGUI better and localizable.
     
    Korindian, kaiyum and ZJP like this.
  28. bobbytrill

    bobbytrill

    Joined:
    May 19, 2017
    Posts:
    4
    I have spent more then a year using uGUI and I found myself working on a project using NGUI.
    I heard a lot of nice about NGUI so I was initially trilled by the opportunity to actually evaluate this package.
    After a month of intense development, my feeling of working with NGUI can be summoned up by the words "BOGGED DOWN"
    I literally felt that I was previously riding a Mercedes and then literally ending up driving a bloody Lada!!
    The usability of NGUI compared to uGUI is just abysmal. If you're looking for rapid application development, uGUI is the only choice you have.
    Let me give specific reasons:

    Anchoring System: uGUI anchoring system is simple ,intuitive and flexible. NGUI's anchoring system is slightly more flexible but requires more setup. Life is too short for us to individually choose each anchor point transform. uGUI's use case is simple, everything anchors to its immediate parent. uGUI also allows you to specify layout elements which allows objects to have minimum sizes, preferred sizes and flexible size. uGUI is full of helpers that allows you to arrange items (Horizontal and vertical grouping and grid). NGUI has a UIGrid and UITable component and I guarantee that you will hit a wall and end up arranging elements programmatically. uGUI's anchor snapping in the scene view is a work of art.

    Sprite depth. NGUI requires you to set the depth for each Widget. We're talking about setting a number for each piece of UI element. This has it upside but soon enough it will reach an unmanageable situation. You will soon arrive in a situation where Its hard to keep track of what is on top and what is on the bottom. uGUI uses the hierarchy to determine sorting which is what photoshop does. You simply look at your hierarchy and slide into nirvana.

    Editor usability. uGUI is responsive when you are editing out of playmode. NGUI for example requires you to "execute" the UIGrid to order its children and see them aligned correctly in the editor. if the grid is parented to the scrollview, you then need to go to scrollview component and refresh it according, Life is too short for that sort of thing.

    ScrollView. I think NGUI's scrollview is a living nightmare. Yes, I am totally emotional about it. It literally made me cry, tears actually came out of my eyes.

    Masking. NGUI's only mask feature that I know of is found in the UIPanel. for the rest you need to find or built your own shaders. uGUI offers you an almost full blown masking solution which is very similar to flash. uGUI allows you to use any rect/image to mask anything else. Ask an NGUI user to mask a tileable sprite with a sliced image, he'll be stuttering for the next two hours.

    Atlas System. In my honest opinion NGUI's atlas system compared to uGUI is like comparing a neolithic stone wheel to a Boeing 747 jet engine. uGUI takes care of atlases for you, it packs them automatically for you. It splits them up in additional atlases if the need arises. All this happens under the hood. You deal with sprites and the only thing you need to do is tag them so that unity knows in which atlas to put them. uGUI also makes sprite assetbundles super simple. tag your sprites and unity will create the atlas and put only those in your asset bundle. uGUI has one of the best sprite atlas systems on the market, fullstop. NGUI? this error message pretty much sums it all up: "Can't fit sprite in current Atlas"

    Performance. People say NGUI is faster. Yes it is theoretically faster but at the cost of making my life miserable. uGUI performance is good if you follow simple rules such as using canvases to group your layout in order minimise redraws. I have created complex UIs using uGUI for mobile and speed was never an issue.

    Animation. NGUI has its own buildin animation system. I think DOTween offers more speed and usability and can be seemlessly integrated in uGUI.

    Sound: NGUI has its own build in sound component but it is useless as it literally ignores the features of the new Unity Mixer.

    P.S Some people are suggesting that Unity does not update its UI system. this is simply not true. Just look at the release notes and bug fixes in the new 5.6 release.
     
    Last edited: Jun 21, 2017
    phobos2077, Yukichu, Aurigan and 5 others like this.
  29. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,436
    Interesting read, thanks for your sharing your thoughts on this.
    Can you link some guide on these "simple rules" or elaborate a bit what one needs to take care of to get good performance out of uGUI? Thanks.
     
    phobos2077 likes this.
  30. bobbytrill

    bobbytrill

    Joined:
    May 19, 2017
    Posts:
    4
    phobos2077 and Martin_H like this.
  31. bobbytrill

    bobbytrill

    Joined:
    May 19, 2017
    Posts:
    4
    phobos2077 and Martin_H like this.
  32. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    @bobbytrill Thanks for the wonderful writeup. I've been using NGUI only because it's been familiar to me, I paid for it a couple of years ago, and it's been the standard for so long, but your points make it worth my time to schedule my own thorough evaluation of uGUI and potentially convert my current project to it.

    You really hit the rough points of NGUI, most notably the ScrollView. I've been battling that thing forever, having to add in my own hacks to get child components sized properly, and positioned properly such that lists obey the min and max bounds. And the layer index management is another point, although it's not too much of a problem once you spend some brain power on it, it seems a lot more intuitive to have it tied to the scene hierarchy.

    One major feature that I'm using the NGUI camera for is 2D/3D collisions, and I'm hoping that it's not that big of a problem in uGUI. It's the classic problem of allowing/disallowing 2D UI elements to intercept input from the 3D world. I thought NGUI handled this pretty nicely. If I have to struggle with this in uGUI, it could be a deal breaker.
     
  33. bobbytrill

    bobbytrill

    Joined:
    May 19, 2017
    Posts:
    4
    I am not sure about the use case you are trying to define. If you have a real world example I can even try to reproduce it in a scene and send it to you. I am not in any way trying to be an evangelist for unity. I am basically ranting about the need for UI developers to be thoughtful of their users by creating friendly workflows. I'd rather concentrate on game mechanics rather then struggling with the UI. My best wishes in all of your endeavours.
     
    phobos2077 likes this.
  34. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    No need to kick out a test example just for me, but it's a rather classic UI problem, but in particular, the issues show up in games like RTSs, TBSs, etc, which require you to click in the 3D world and also on the 2D UI. The way NGUI handles this is that each UI element has a collider assigned to it, and the objects in the 3D world obviously have colliders assigned as well. Mouse input is then determined by which collider is underneath the mouse. However, some UI elements should allow pass through (event not handled) to the 3D world, so that it can be handled by there. And other times, the UI should consume the event.

    In NGUI, this all depends on UICamera. You assign delegates to its various input events (mouse, keyboard, drag, etc), and those events carry along with it, the object that had focus at the time of the event.
     
  35. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    uGUI handles this quite nicely... once you figure out how to do it. Its actually fairly poorly documented on how to combine UI interaction and world interaction.

    The key is to drive all of your mouse input through the EventSystem using GraphicsRaycasters and PhysicsRaycasters.

     
  36. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,084
    It does once you implement one of these things, but... honestly? It should be a matter of clicking an option on a component instead of code based considering how rudimentary it is.
     
    phobos2077 and theANMATOR2b like this.
  37. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    I agree it definitely could have been much simpler. Unity currently has four distinct ways that you can process mouse input. None of them work nicely with each other by default.

    That said, you don't have to go code based for this. Using the EventTrigger you can do a lot of basic stuff without needing to write a line of code.
     
    frosted and theANMATOR2b like this.
  38. xxhaissamxx

    xxhaissamxx

    Joined:
    Jan 12, 2015
    Posts:
    134
    i'm new to NGUI i bought because it's use less batches targeting mobiles so less batches is better is that's right ?
     

    Attached Files:

  39. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,617
    To a point, yes. Like any optimisation you want to measure actual performance and bottlenecks before deciding on a solution. Chasing less draw calls by making things more expensive elsewhere might end up with worse performance.
     
    phobos2077 and xxhaissamxx like this.
  40. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    It's not always true I'm afraid, but generally can be.

    Regarding Unity UI, it's good but there's a whole lot of overkill happening with it so don't be afraid to use some bits and other bits can be bespoke. Same for anything really... you do not need a solution to cover everything if doing game dev, because games are pretty unique creatures at times.
     
    Martin_H and xxhaissamxx like this.
  41. MaxGuernseyIII

    MaxGuernseyIII

    Joined:
    Aug 23, 2015
    Posts:
    315
    It's really hard to tell from this thread which one is the "winner". Does that mean it's close to a tie, right now? Does it mean that one is good for some things and the other is good for other things?

    I came to this thread looking for an answer and it's now clear that there isn't one, yet.

    I'll add my observations which, admittedly, are drawn from a little experience with NGUI, a fair amount with UGUI, and decades as a software developer. Hopefully, it will help someone else synthesize a conclusive answer at a later date.

    Surprise
    My level of surprise with NGUI is generally higher than it is with UGUI. That is, if I find out something new about how UGUI, my internal response is generally "Oh. That's how that works." An example of this was when I first found out how you set up the anchoring in UGUI.

    On the other hand, a discovery of how something in NGUI works periodically elicits the response "OH! THAT'S HOW THAT WORKS?!?!?" My favorite example is the advice from the NGUI tutorial videos: Don't use a screen resolution with odd numbers of pixels or your text won't be crisp.

    Innovation
    NGUI is built by a small organization with an impetus to come across as cutting edge. It seems like a lot of the things in UGUI are "inspired by" NGUI. Or possibly, they share a common inspiration but NGUI got to them first. I don't have hard examples of that - just an inkling. I've seen the pattern a lot throughout the software development industry as a whole; anyone who's been doing this for a while has. The little guy gets to the new features fast. The big guy comes in later but with (what they believe is) a more complete solution or one that has a broader appeal.

    Focus versus Breadth
    NGUI seems to have a very focused intent. The goal seems to be supporting a one-off project and making execution of the resulting game as efficient as possible. An example of this kind of thinking is the "everything gets a number so I can sort its depth" way of deciding what to do draw when. It might be something you can get to work for a limited amount of scope but it's not the kind of thing you could hope to sustain over time as new features emerge.

    Unity is backed by a large organization that seems to divide its efforts while still focusing on meaningful chunks. Sometimes they make things easier. Sometimes, they enable engineering practices. Sometimes they improve execution efficiency. Sustainability is an important factor to them (but not the only one). An example of enabling engineering practices is their addition of SortingGroup. You can decouple the sorting position the parts from that of the containing whole.

    Breaking
    I don't haven or can I find a good account of how often NGUI or Unity released breaking changes to their API. Does anybody have experience with that either way?

    Longevity
    We don't know how long NGUI will be supported but we can assume, based on its past success, that it will probably survive for a while. That said, we can be reasonably certain that it will not outlive UGUI itself. The only way I could imagine that happening is if Unity decides to pivot and give us something better than UGUI. In which case, they would almost certainly provide migration tools to ease the cost of upgrading and there would likely be a controlled phaseout of the UGUI API.

    Performance

    I still can't get a conclusive read on whether one of them is generally faster than the other. Maybe they are close to each other or sometimes one is faster and sometimes it's the other? I don't know. Anyway, performance is a problem that can be solved by optimization.

    Since (from our perspective) Unity controls everything between our code and the underlying platform (Windows/Android/et cetera), they have the power to solve any architectural problem in their way. NGUI can only solve the problems between our code and the Unity code.

    Opportunity varies between NGUI and UGUI but so does motive. It seems like Unity is reasonably interested in keeping performance high, so I would hope they will keep improving performance without us having to do anything. NGUI will, too, I'm sure and, while the opportunity is more limited, the wherewithal might be greater.

    It doesn't seem like you can really safely count performance into your decision without first running some tests to get some hard numbers around the kinds of things that you want to do and then considering the ramifications of how you expect UGUI and NGUI to evolve over time. Or maybe someone can provide clarity on this point.
     
    dyupa, phobos2077 and Ryiah like this.
  42. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,965
    To be fair the majority of this thread is at least eight months out of date.
     
    Last edited: Sep 22, 2017
    frosted and angrypenguin like this.
  43. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Yeah, well I use Unity UI. I also use TextMeshPro. Which has Unity UI integration, so it's a no brainer. Pretty much everyone wants that.

    For me there is no purpose to NGUI any more.
     
    phobos2077 and Ryiah like this.
  44. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,617
    That's generally how things go. It's rare when comparing good products for one to be objectively superior across the board than the other.

    Unity hired the NGUI developer for early development of UGUI.

    Me too. I previously used NGUI quite successfully for a number of projects, so it's definitely a capable set of tools that can get the job done.

    I use UGUI now, mostly because it's a standard toolset that comes with Unity. Fewer external dependencies mean easier life as a developer, doubly so when you're doing stuff with clients. So far I've been able to achieve all of the same things with it and, personally, I find it easier to make custom stuff with UGUI than I did with NGUI - I've so far always managed to do it by combining things, where with NGUI a few times I had to change things. Of course it's entirely possible that NGUI has advanced significantly since I last used it.

    I did a couple of times have forward-compatibility issues with NGUI. I can't remember if it's because things changed in Unity or in NGUI or because I'd had to customise stuff. Pragmatically speaking, though, I've never had that issue with UGUI (possibly because of the customisation stuff mentioned last paragraph), and Unity in general do a fantastic job of managing compatibility when moving forward.

    I hear that UGUI is less performant than NGUI. However, I've never found either to be a performance bottleneck for a project.
     
    phobos2077, Martin_H and hippocoder like this.
  45. MaxGuernseyIII

    MaxGuernseyIII

    Joined:
    Aug 23, 2015
    Posts:
    315
    To be honest, I was hoping to spur it along a little so I could get an useful answer for myself. ;)

    So far, I'm going with "use the thing that is familiar", since I can't see compelling evidence either direction.

    If I change my mind later, it's cheap to make the changeover...one of the many benefits of encapsulation.
     
  46. phobos2077

    phobos2077

    Joined:
    Feb 10, 2018
    Posts:
    350
    I wonder how these too are compared as of 2018. I see a lot of jobs listing NGUI as a requirement, so it seems to be very popular. From reading every previous post my understanding is that anyone should use built-in Unity UI + TextMeshPro (both free and part of Unity now) from this point on, except for rare case when you have a short-lived one-off project with overcomplicated UI and you need to squeeze every bit of performance out of UI system.
     
  47. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    9,042
    I don't know how much nGUI is used for new games, but there are a lot of games that were created using it, so a lot of games that still need supporting. My last SW game is celebrating its 4th year in release and still going strong. Development started on it around 2012, and makes heavy use of nGUI. For games like that, that are successful and stable, there isn't a practical need to replace the entire UI. The number of live games using nGUI will probably go down over time, but it is still out there being used.
     
    phobos2077, Ryiah and angrypenguin like this.
  48. BlackPete

    BlackPete

    Joined:
    Nov 16, 2016
    Posts:
    970
    Last time I looked at NGUI, Unity 4.x was still the major version, and Unity 5.0 was just being released. uGUI was still in its infacy, and needed more work to fully flesh it out.

    That was only 3 years ago. Just putting that into perspective.
     
    Ryiah and angrypenguin like this.
  49. mmvlad

    mmvlad

    Joined:
    Dec 31, 2014
    Posts:
    98
    Not 100% sure of the current state of uGUI but last year in official Unity talks they suggested basically to rewrite most of the uGUI if you wanted it to be performant. E.g. all layouts were rebuilding canvas every frame, later antialiasing stopped working, default font is still epic trash and the only way is to use TextMeshPro.

    So if you have a complex UI then nGUI is the best way to go.
    uGUI is like everything Unity makes - nice for a quick prototype but not suitable for quality release. And it is not even funny how true is that - UI is bad, terrain is awful, default character controller is bad, I mean 90% of ready components shipped with the engine are suited only for prototyping. To get quality you need to rewrite everything or use 3rd party solutions.

    Of course, there are ways to make uGUI work ok, but that will require no less time than with nGUI, and a lot of work writing custom code that you should also know how to do.

    I believe most of those who suggest going with uGUI are talking about PC games, where all these problems still exist, they are just not that noticeable.
    But when you start doing something for mobile and you make a complex uGUI ui - you will just want to cry. While with nGUI you'll get like 1-2 drawcalls and excellent performance.
     
    BAIZOR, Lu4e and AcidArrow like this.
  50. bluescrn

    bluescrn

    Joined:
    Feb 25, 2013
    Posts:
    642
    Last time I looked at NGUI was about the same time. But after working on a couple of mobile projects where UGUI performance was disappointing (to put it mildly), I'm certainly open to considering other options (or maybe just using a non-UGUI approach for the very common case that utterly destroys UGUI performance - scrolling lists/grids of non-trivial UI prefabs).

    Is NGUI still being updated, and are there any other serious contenders out there?