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?
Primarily because the two existing solutions can no longer scale with our ambitions, or the ones of our users.
For 2021.2, UI Toolkit is recommended as an alternative to Unity UI for creating screen overlay UI that runs on a wide variety of screen resolutions. It should be considered by those who:
Otherwise, if you need UI positioned and lit in a 3D world, as well as VFX with custom shaders and materials, Unity UI is stil the recommended solution.
Here’s a few ones that come to mind:
Ultimately, our goal is for UI Toolkit to be the best solution for making UI running across all supported platforms.
I understand this is a transition phase and some aspects might not be at the level of your expectations, which is why we’re making sure to maintain existing solutions until it can fully replace them.
I hope this clarifies our intent!
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?
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:
https://www.youtube.com/watch?v=wbmjturGbAQ
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?
By the way I really appreciate this conversation, even though it’s happening in the wrong thread :P, and I think you’re raising a valid concern.
We don’t consider USS/UXML a tool per say, they’re just assets to describe the structure and properties of user interfaces. Like some mentioned, they bring familiarity, but they also allow us to build nicer authoring workflows on top of them, which is what UI designers are also looking for. But they’re implementation details. The end goal, like you said, is to serve the needs of game UI, but also non-game UI. We need to consider other use cases such as the Unity Editor and runtime applications.
Even though some early adopters have already created some beautiful UI for their games using UI Toolkit, I’ll admit it’s still missing some expected features like custom shaders and 3D UI, in order to deliver on those advanced cases. But those will come, it’s the next logical step.
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:
https://www.youtube.com/watch?v=zeCdVmfGUN0
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.