Why is Unity creating yet another UI System?

Why is Unity creating yet another UI System?

What are the benefits (at this moment) of using the new system over the existing systems in Unity?

What is it that's hoped to be beneficial about this new system in the future that couldn't have been done in the existing systems?

 

Whilst it's true that some UI designers and artists have some familiarity with CSS, you'll be hard pressed to find designers and artists who are primarily designers and artists that enjoy using CSS, or would ever prefer it over good WYSIWYG tooling for the creation of UI.

To that end, what are you planning that's beyond the existing visual constraints system, where CSS benefits? I haven't seen a world of CSS design that's superior to how constraints work for complex, scaling UI creation and editing, have you?

In fact, CSS barely meets the label of being a tool, let alone artist and designer friendly... it's code based creation and editing... right?

And code

     that nests

            and nests

                   and nests

                          and nests

                                 and nest...

                                        before finally getting something done...

                                 then

                           un-nests

                     just

               as

        pain-

fully

How is that artist and designer friendly?

 

Here's a quite amazing demonstration of how to think and operate in a manner that's highly suited to complex and large UI system design and development, perhaps one of the best talks on Unity, ever, too:

In contrast with the enormous wealth of info about using UGUI, optimising it and thinking in its terms, and several other game engines using a similar constraints based, canvas oriented system...

How should a reader believe the existing 2021.2 (beta) UI Toolkit (Preview) with UI Builder (Very early Preview) help them produce a significant amount of user interfaces given all the demos seem to show 2 buttons, on a top level pause menu?

 

I don't have a major stake here, but I know a *lot* of designers/developers who love CSS as a tool. They tend to come from the web design world, naturally. CSS is the lingua franca of UI design for millions of developers already out there -- it's doing something right.

You should give UI Toolkit a try -- it's.. dramatically better than UGUI. I've built lots of UI in both, and I can confirm that it's a major leap forward. Even just having a real automatic layout solver is a huge breath of fresh air. It's especially great for UIs with thousands of little components, where a GameObject-based workflow is really awkward.

 

As I said... designers and artists that are primarily designers and artists... not website developers who consider themselves designers and artists.

CSS, as a tool... is great for coders. It's not barely a tool, or even really a tool, for designers and artists that are primarily artists and designers. It's a coding framework that was odd from the get go.

If you've had some great success with the UI Toolkit, why is it better than UGUI?

Can you show something complex that you've made with it?

 

With all due respect, it's because I've "given a try" to lots of different parts of Unity that I'm not willing to give them more of my time.

It's now, for me, upon them to sell the truths of usage before more of my time is used up experiencing (what are very often) dark alleys of gotchas, caveats, broken bits, dead end streets and speed bumps in the name of "giving it a try".

My time may not be valuable to Unity, but it is to me, and it's not free.

 

Have you looked at this thread? Share your UI Toolkit projects

 

Have a look at Yousician's app, as deeply described in the video above, from Unite 2017.

It's fast, complex, deep and very, very fluid, even on old iPads at a very steady 60fps, with quite a bit of UI movement.

It's genuinely impressive. And the guy is able to break down exactly how they got there, in 2017.

I'm not seeing anything there that's nearly that performant, nor deep.

 

Here's my take on converting presenter's GitHub project to UITK. So I don't get what's your problem. Posted a GIF in this thread.

 

Did you at least open the app to see what he's actually talking about?

And that it's a speech from 2017, about what they'd done in years past?

 

UI Builder is the Tool, CSS/UXML are tool friendly definition/markup formats. UI Toolkit is not the only one that use XML/Styles for GUI, like WPF, Xamarin.

 

And the objective is to make game UIs.

Not forms for entering data. Nor boring, traditional or flat websites.

How does CSS/UXML exceed the existing paradigms of constraints as used in UGUI for the purposes of creating, placing, animating and crafting UIs that are wowing, cool, amazing, dynamic, engaging and incredibly appealing game UIs?

 

One should also ask here, what is a game UI for you? A game UI is also basically there to enter and display data. There are a lot of UI games out there, actually not much different from "boring flat websites". For example, Genshin Impact, I like the UI, even if it tends towards flat design.

 

No, anyone involved in designing tools should never ask about one's self, or one.

The role of a tool's product designer is to consider the common at the expense of the general.

To design products which are tools for the greatest benefit of the most common usage.

This level of abstraction is not something just anyone can do.

Here, the common has been sacrificed for the general, not just in terms of game ui design, but also in two fields that would be best served if the most common usages of game ui creation excluded all other considerations.

You can see that here:

This is the general destroying the common, cubed.

Unfortunately.

 

Maybe it's because of my lack of English, but I don't understand what you're trying to say with this post. At least it has nothing to do with what I wrote.

I don't understand your problem either. Personally, I find fiddling around with GameObjects for GUI rather cumbersome and not intuitive. In fact, it is very common nowadays to use a UI design tool. Unreal doesn't do it any differently either.

 

This is.. a confusing statement, because UI Toolkit is dramatically more performant than the GameObject workflows. This is one of the primary reasons it has been designed. This is a great talk on the subject:

Imagine you are making EVE Online, with hundreds of thousands of little text elements all over the screen. The workflow in the talk you linked will choke very quickly under that kind of requirement.

I think it's correct to say that UIToolkit is more complex than UGUI, but it's important to remember that Unity has to build a solution that works for everyone, no matter what they're building. They don't have the luxury of building something simple, if the goal is to support any AAA game.

 

If you look back at the last few years of Unity development, it becomes apparent that few things get finished, and even fewer get polished, and it's even rarer that their claims match reality. With that skepticism firmly in place, it's right to take a very critical look at why UIToolkit and UIBuilder are being pushed forward as a Game UI system when a few bits of focused endeavour on top of and around Canvases and Constraints could yield vastly better results in a much shorter time span with much more certain outcomes (I'm not saying anything about it for Editor UI).

On the surface, and if you take Unity at their word, URP, The New Input System, UIToolKit and various other new additions are significantly better than what they seek to replace.

A little testing reveals this to be largely theoretical claims, rarely borne out in reality.

It might be true one day. But it's certainly not now.

Some minor tweaking of BuiltIn makes it vastly faster than URP, and Builtin is significantly more capable. URP is a long way from feature parity with Builtin, years after becoming "Production Ready" and requires new work to create many shaders and effects in new ways, and is often simply incapable of matching Builtin's abilities, let alone optimised performance in the MANY ways it's possible to fine tune Builtin.

Builtin, like Canvases and Constraints, are getting ever new leases of life because of a combination of user experience sharing optimisation and usage strategies (as per the 2017 talk above) and Moore's Law.

URP started life as LWRP, a template designed (apparently) to demonstrate the 'ease' of making Scriptable Render Pipelines. To this day, it's VERY difficult to make a Scripted Render Pipeline of your own, and the two templates originally meant to help promote making SRPs are now "Render Pipelines", that users are being cajoled into choosing between as if they're things in their own right, not merely templates, because they're very silo-like environments.

Asset Store creatives making post processing features, shaders, materials and lighting setups have triple the work to do in supporting these behemoths, before version issues compound the silo issues.

The New Input System apparently makes sophisticated input config creation possible, but Unity struggles to explain it, and a couple of very minor tricks with the old system make it do just as well, with far easier to understand code, whilst adding ReWired to your project (for a very modest fee) provides an almost infinitely better version of the The New Input System. The New Input System is nowhere near finished, despite being "production ready". Which forces the question... why does it exist?

Unfortunately, regardless, Builtin and the old Input System have been abandoned, not getting updates for years.

The Canvas/Constraints based system, with a few concessions to how it's used, as per the 2017 speech linked, is incredibly performant and absolutely controllable and (dare I say it) somewhat intuitive and instinctive to use.

No matter what you might think of CSS and its approaches, it will never be intuitive and instinctive. And any claims Unity makes about performance need to be tested against the efficient use of Canvases and Constraints.

Keep in mind, the 2017 talk is well before Nested Prefabs were suited for use with the Canvas/Constraint system (you could make a case that the inability to reorganise nested objects is still a huge pain when using Nested Prefabs with UGUI, and I'd agree).

Oddly, I was going to use the speed with which you could make an Eve-like layout within the Canvas/Constraint system as an example, but thought it too old and static to make a good case. These days, I think The Division has set a new benchmark for all games (not just AAA), as it's just a great interface, in a million little ways.

Interestingly, it will be (likely) years before the in-world anglings and animations of The Division's interface will be possible with UIToolkit/UIBuilder, whereas it can all be done today with Canvases and Constraints and Nested Prefabs. Yet UGUI, like Builtin, is being abandoned.

I dearly wish Unity would do a round of Optimisation of Constraints and Canvases, and then Jobify and Burstify the performance of Canvases and Constraints, in one last round of updates, before putting it out to pasture. This would add at least a decade's more usefulness to this wonderful little system. Kind of like how Legacy Animation lives on, and just works, for so many things, and Shuriken will go on for at least as long for basic particle effects.

As for Unity and AAA... be nice if Unity would focus on the common, majority of the market that not only needs it but uses it most. We'd happily pay royalties for the kinds of artisanal care and crafting that'd make making games with Unity less of a Package Manager vs Version lottery and take the onus of the testing and bug reporting timesink back into Unity's QA department.

 

I was much faster experimenting with UI toolkit and got better results. But I'm a web developer so I have an advantage there. There are some things that you can do quite easily with the UI Toolkit, but that are much more complex in UGUI. E.g. a button with rounded corners and a border with a soft hover transition. And by exchanging the style class, you can change the button style with little effort.

 

9 slice scaling called, and told us we can have every single kind of rounded corner we like in UGUI. And it's easy and performative and (dare I say it) FUN! And infinitely more creative than the CSS limitations of rounded corners via their rendering system, plus as easy to update as changing the graphics file in Photoshop, or swapping the file used.

As for soft hover transitions, and the like, and all manner of rollover effects... that's where the Legacy Animation system shines. With UGUI you're not limited to the lack of imagination prevalent in CSS-World. You can do ANYTHING, including particle effects. And it's as quick as making AnimationClips, and as customisable as you can imagine (infinitely) because this is all builtin to Unity.

I'm not a fan of UGUI, nor CSS. But one is suited to game UI creativity, can very happily exist in world space and be easily attached to game world objects, and one is well suited to making forms for web data entry and basic web dashboards and maybe Unity's Editor UI.

 

But you need a texture. For simple buttons / panels you have to change / exchange the texture each time. With UI Toolkit you only need to change one inspector variable in UI Builder (or the border-radius property in USS). And for graphically complex buttons / panels you can stil use 9-slice sprites in UI Toolkit (Unity 2021.1+).

 

You only have to change ONE texture.

It's as portable and single pointed as the changes to the single variable in UI Builder, but it's way more powerful, and renders faster/lighter, because it's a texture, which can be batched with any number of other visual elements, etc.

And it's in Screen Space, World Space and every other space known to Unity's universes, so is infinitely capable of being game-fied.

 

I don't know how UI Toolkid renders something like that. Maybe a 9-slice texture is generated? or that is completely calculated in the shader, so the question is what is faster, the sampling of a 9-slice texture, or the parametric rendering?

 

UI Elements renders without textures -- the rounded corners are calculated in the shader. This is important for because if you want to support 4k (or higher), you'd need massive textures to avoid aliasing. Textures aren't sufficient for all use cases.

 

I think this is the crux of the issue here. I agree that some of the new systems have left folks behind, because they're either too complex, or too unfinished.

But I think it's important to recognize that there are many folks (like myself) that are very happy with all of the above tools you've mentioned. Our game could not be built without the New Input System or the URP. It relies on them.

So I do think your points are valid, but remember it's not the only point of view. It really depends on the games you're trying to make.

 

Yet the absolute inverse of this is also true, removing the hubris/egoistic part about complex. Please put this kind of talk away, as it's pointless, and incorrect. Allow me to dismantle and hopefully prevent this kind of claim in the future:

URP is not more complex than Builtin. Builtin is both more complex and more capable.

UIToolkit and UIBuilder are vastly less capable and less complex than UGUI.

The New Input System is less capable. It's complexity is merely in poor API design, not in what it does. It is not nearly as capable as ReWired, and seems to have stalled in terms of sophisticated touch and other non-controller based input handling compared to even Unity's old/existing input mechanics.

I can't poll as accurately or quickly with the new Input System as I can with the old.

As to the idea that they've left anyone behind... there's a grain of truth in this, but perhaps not in the manner you're trying to insinuate.

Builtin isn't getting updates and is being deprecated, despite it being better and more capable than URP in just about every way.

I can't do what I'm doing with Builtin in URP... and this is a mobile first game.

UGUI exists in all the spaces Unity can create, and is significantly capable in terms of animation and rendering options in the far off dreams of UIToolkit, and has an innate and natural object relationships that it's unlikely UIToolkit and UIBuilder will ever be able to close in on. Yet it's probably now not going to see any significant updates.

It's going to be a very long time before any of what I'm doing with UGUI is possible in UIToolkit, and I tend to doubt it will ever get there.

And that's the real crux of the issue. Long before URP and UIToolkit and the New Input System reach parity with what they shouldn't be replacing, those older, tried and tested and heavily and well documented (externally) systems have begun atrophying and aren't seeing significant updates and maintenance.

 

All the above presumes everything was going smoothly, merely at the glacial pace these things seem to move at.

I forgot one other huge problem with this 'move' to new...

BUGS.

https://forum.unity.com/threads/button-text-size-in-doesnt-work.1037551/

When new bugs are factored into the move forward, in each new system and approach, and the ever changing APIs and the bugs they bring in our own endeavours with the new systems, the question of "Why is Unity creating yet another UI system?" rings out just a little louder.

 

I'm definitely not insinuating anything here. I think the messiness and the length of Unity's transition *is* a real problem for a lot of folks.

Here are two things I can't do with the old input system or the old built-in render pipeline:
- Our entire game is based on recording input buffers, and playing them back. We do this for hundreds of input devices in the game. The old input system does not allow accessing the raw input buffers, and would be a mess to try to record and play back in a generic way. The new input system makes this trivial.
- We modified URP to render the entire post processing stack inside of the forward pass Lit shader, within the fragment shader. We removed the additional PostProcess and XRBlit passes in the rendering pipeline - both of which are too slow on Oculus Quest.
- We added subsurface scattering to the default Lit shader in the URP.

Now don't get me wrong, I agree that the new systems need a lot of love, and they have required us to implement features that just worked in the old ones. But for us, we're very happy to take that trade-off, because the new packages give us lower-level access to the underlying systems. It allows us to make the games we want to make.

See I think this is a *great* point and I agree that this is the source of the problem. Unity expected DOTS to be done much, much sooner, so they moved most of the team onto it. That meant the 'old ways' have stopped receiving updates. I agree that is frustrating.

 

Please divert one person to Jobify and Bursterize UGUI.

 

UI Toolkit is in an interesting place. The difference between editor UI and runtime UI is *vast*. Here are some of the things I worry about with runtime UI:

• Use by non-tech-savvy users
• Discoverability
• Control by mouse, keyboard, controller, touch, and possibly others
• Maybe switching between control methods on the fly (if you have a controller plugged into a PC, you may want to play the game with a controller but menus with the mouse)
  
• Scalability to various device and screen sizes
• Accessibility (eg colorblind mode)
  
• Performance on lower-end hardware
  
• A much higher bug bar
• Testability
  
• Better handling of inconsistent/unexpected state
• Handling state changes not caused by user action (eg an enemy appears on screen)
  
• Animation
• Looking sharp and fitting into the design of the game
• Having visual flair that's not common in modern web design trends (glows, stylized buttons, gradients, skeuomorphic designs)
  
• Particle effects -- try opening a menu in a JRPG and seeing how much is flying around the screen, just done subtly enough not to distract
  
• Many "non-standard" controls (eg a minimap)
• 3D elements inserted into a 2D UI
  
• 2D elements (eg health bars or tooltips) inserted into a 3D world
• High information density (depending on the game of course, but look how much is on screen at once in Dark Souls)
• Not being distracting or getting in the way of the actual game

Most of these things don't matter or matter very little for a UI that's integrated into an editor meant to be used by a small number of people, all of whom are equipped with mouse/keyboard and likely with tech knowledge, strong computers, and a willingness to accept the occasional stack trace in the logs.

Neither UGUI nor UI Toolkit has impressed me in those areas. In particular, I used to work with WPF and XAML UIs, which handle data bindings, styling, vector drawing, templates (eg for list items), and animation in a way that far exceeds UI toolkit. UI toolkit feels so entrenched in replicating web technology, perhaps because there are so many web developers who would be familiar with it. But web technology is not the pinnacle of design; it was cobbled together over the years by innumerable committees and browser implementations.

The mere existence of USS is a concession to web developers, not a decision made based on the merits of CSS. For example, in XAML, there's no distinction between what's part of the style vs an object property. It's all data-bindable, animatable and can have styles applied. You can have a "style" for the text property of a label for example, and swap it out at runtime. You can react to a trigger (built in like a mouse hover or custom event) and play an animation or transition -- all without writing a line of C#.

That's what can be achieved with a UI framework built from scratch instead of trying to ape another technology. And one reason Microsoft considered it a failure was because it was too complex and required too much domain knowledge, so it's back to web technology for now and ever.

Anyways, enough rambling.

EDIT: sorry this sounds really negative and combative. I actually like UI Toolkit a lot and think it is better positioned for runtime than UGUI, but I think it could be better if it wasn't tied so strongly to web technology and web metaphors.

 

@benoitd_unity regarding that discussion of feature comparisons between UI Toolkit and UGUI, I would like to point out that one particularly important point is the flexibility of UGUI.

If I had to summarize the approach of UGUI, in a nutshell, is "it's just a bunch of Quads that get merged, if you need other meshes in your UI just use them directly or build them on the fly". This in turn means people can

• combine 2D and 3D objects and meshes freely,
• use effects in UIs,
• apply postprocessing where needed,
• world space and spatial UIs becomes trivial,
• styling is trivial (it's just textures + vertex colors),
• animate with known tools, and since everything is GameObjects, combine game animation and UI animation (e.g. in Timelines, top-level animators,...),
• create and destroy objects on-the-fly with existing tools,

... it's very flexible. Yes, it can be slow if used wrong, and if you want a lot of flexibility it's not fast anymore.
Example: "a world-space inventory UI for a VR game, where the items are arranged in a scrollable grid, and where the individual inventory items are rotating 3D objects. Hovering the items animates their scale and the item's background color." - uses a good amount of the above flexibility. Add "the UI is curved" for bonus points.

What I've seen from UI Toolkit so far is that it trades that flexibility with speed, and that's it. A lot of things become non-trivial -
All of the items in the list above are now hard or (currently) impossible
Bindings are the new big thing, but those could have been added to UGUI as well, that's not a technical limitation of UGUI.

My favorite example of that crazy inflexibility is dropdowns in UI Toolkit.
If you have a good mood and want to tone that down a bit, I encourage you to try and

• make a dropdown in UI Toolkit
• that has a red background with orange border and white font
• where the opened up dropdown list also has a red background with orange border and white font, but half the font size.
• now, add a blue dropdown that also has a blue dropdown content.

I really look forward to the day where that (very simple! basic! beginner!) use case is easy in UI Toolkit.
Happy to test it out if you have strategies there.

Also, a general question for our internal planning around this: when would you say the example VR UI above can be built with UI Toolkit? (as in, what's the ETA for "feature parity")

 

I disagree with your views on XML/CSS, but I agree with the general abandonment of core/built-in Unity features. It's been a very sad 5 years with no end in sight. I am a big fan of built-in, or at least what it would be now, if it hadn't been abandoned. It should support Shader Graph and the old input system should have been updated to support key remapping.

I think most of those game UI's you mention are probably done with separation between layout and style, but I admit nested prefabs have solved some of the styling problems UGUI had, because now you can change the entire font from one "BaseText" prefab. But remember that UGUI cannot be used in the editor/inspector, and with the WYSIWYG editor, UIToolkit could hide the CSS "complexity" if it wanted to.

UGUI would support procedural shapes if Unity hadn't abandoned it, or actually made games themselves. It's laughable that you can't even make a circle...

• https://github.com/thisotherthing/ui-shapes-kit - Works, but no longer updated and therefore random console errors, and dodgy prefab support.
• https://assetstore.unity.com/packages/tools/gui/procedural-ui-image-52200 - Excellent, but paid, and therefore you will not be able to use in open source projects. Shout out to their other package, UI Gradients too. These should be in UGUI by default.

 

sorry for not reading thru the mile long posts in this thread

will a UI made in unity 2019/ 2020.1 work when we open it in 2020.2 or higher ?

will this become the new why is my project pink of the future ?

 

Frankly, you (the Unity you, not the you you) haven't been investing in UGUI for many years. Since it released actually. When UGUI released it was pretty slow and kinda awkward to use.

Then 7 years later, it's practically the same.

The fear for UI Toolkit is that it will have a similar fate. It will release and it will have some problems that instead of getting fixed and improved over time, will remain exactly the same, until it is replaced by a completely different UI System, that will have a whole new set of problems to deal with.

I think most people would instead like you to iterate and make your systems good before abandoning them. I'd prefer if instead of UI Toolkit, you'd be working on UGUI 2.0 (and I never really liked UGUI), which would keep the good of UGUI, fix the bad, add a feature or two based on community feedback and have a clear upgrade path from v1.

Instead, as with most modern Untiy features, it feels (emphasis on feels, it might not be the case, but as an end user that's what I think I'm receiving) like you don't have any interest in having mature features and would rather chase modern design trends that contain buzzwords that sound good on paper.

To make a food metaphor: Unity made a pasta dish, it was a bit undercooked and needed more salt. Then Unity, unhappy with the results, instead of adding some more salt and cooking for a few more minutes (and maybe add a sauce), is now preparing a salad.

 

thank you
my goal is more about asset creators in that we commonly publish in 2019.4 and don't really wish to make a entire new UI set just for 2020.2 and higher... it not so much about the workload as it is about bloating the project size with even more files, we already have to do this for so many other unity tools and this just adds one more item to the growing list

it would be wonderful if any changes do not need users to open the package the managers and add dependency's when you could just have it preloaded on open new project

Note Unity asset store has no way to add the dependency per a specific api level and only has add for everything or nothing

cheers

 

I’m pretty sure that UITK, for editor and runtime, come with the engine and aren't a package. So every project after whatever release would have UITK guaranteed

 

the trick is "after what ever release"
we shall see, nothing i say will help perhaps as they do as they please
would be nice just one time they think about this before breaking stuff

cheers

 

I think there are some very valid points here. It feels like Unity are falling for a common trap. Take any moderately complex software which has been used by customers for a few years, introduce some developers to it and say you want to add major new x, y, z features, and the developers will almost always tell you the best plan is to rewrite it so that it will be designed towards x, y z from the start. Sounds good, and goes well for the first half of the project, but then the edge cases start coming out of the woodwork, your new code base is getting more complex, development of new features slows down and feature parity with the gnarly old system (which was gnarly because it was mature) starts looking harder and harder to achieve.

The product managers at Unity should be aware of this pitfall but with the number of brand new systems that have been introduced and then stalled when the complexity increases, I fear they weren't. I think it is too late to go back at this point so the important thing now is to persevere. With enough effort these new systems will eventually mature, cover more edge cases and become useful in a wider range of scenarios. Unity just need to avoid falling into the same trap again, else they will abandon UI Toolkit, the new input system, URP, etc to chase more false dreams of the next new system which surely will magically do everything without getting complex...

 

Will custom tags be supported natively or would we need to create a hacky solution?
https://forum.unity.com/threads/feedback-wanted-new-text-engine.1007585/page-2#post-7356359

 

Here here!