Unity UI vs NGUI

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

1 Like

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.

1 Like

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)

5 Likes

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?

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.

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)

3 Likes

Beyond me that uGui is a few years old now and still has problems like this…

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.

2 Likes

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

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 :slight_smile:

17 Likes

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.

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.

6 Likes

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 shit 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.

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.

3 Likes

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.

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.

https://forum.unity3d.com/threads/unity-ui-extensions-collection-v1-0-0-1-released.295930/

I think there are some others as well.

1 Like

That sounds super useful, thanks a lot!

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.

1 Like

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.