UI Toolkit Update - Q3 2022

Unity Engine
,
1

Hi folks,

It has been a while since we reached out with an updated message about a general overview of the UI Toolkit’s direction.

The landscape of UI systems at Unity

First of all, we want to reiterate our commitment to make UI Toolkit the singular UI solution in the Unity product. This is a long term aspiration but we still firmly believe in this direction.

We are in a continuous process to find and document parity gaps and assign the most intelligent priorities in our roadmap. Our insights come from conversations with internal stakeholders and customers, and of course from this little corner of the Unity forums.

We are aware that UI Toolkit is not yet capable of fully replacing IMGUI and UGUI, but we are getting there. In this post we will talk about what we have been working on for Unity 2022, what to expect in Unity 2023 and what will be coming only in future releases.

As a side note, we have updated this comparison page in our User Manual as a guide through the process of choosing which UI system to use or start a project with:
https://docs.unity3d.com/2022.1/Documentation/Manual/UI-system-compare.html

This page will be updated for each Unity version.

UI Toolkit improvements in Unity 2022

In Unity 2022, we have made leaps forward in closing the gap between what can be achieved with IMGUI for Editor UI. UI Toolkit is now in a better position to receive wider adoption both inside and outside Unity:

  • The Inspector Window now uses UI Toolkit to generate default Inspectors while falling back on IMGUI only for existing IMGUI PropertyDrawer and Editor implementations
  • All the main Unity attribute and type PropertyDrawers have been ported to UI Toolkit
  • The ListView now supports the same features as the IMGUI ReorderableList
  • We have added the TreeView and MultiColumnTreeView controls
  • We have added new Vector drawing APIs for programmatic shape rendering
  • We have improved the documentation by adding more topics about the UI Toolkit feature set as well as explaining the migration path from IMGUI

We have also improved the performance of the core systems. Many of these improvements benefit the Editor use case as well as the Runtime UI use case:

  • Layout and styles

  • Lower overhead from GeometryChangedEvent

  • Updating styles on an element should no longer cause unnecessary invalidations of the layout or geometry

  • Rendering

  • Turning the USS styles of a VisualElement into a mesh is now faster, expected gain is in the order of 10x

  • Usage Hints are now set automatically when using USS Transitions, leading to better performance when animating VisualElement styles

  • Font textures are now bound through one of multiple textures slots from the UI shader (instead of a single one before) which means it’s possible to achieve a lower number of draw calls

With these improvements, UI Toolkit becomes the recommended solution for making extensions to the Unity Editor.

Plan of intent for 2023

Our goal for 2023 is to improve the efficiency of UI Toolkit, both in terms of performance and workflows.

The data binding feature set is currently limited and not very easy to use. We are hard at work on a generic data binding workflow for both Editor and Runtime UI. This system is built on top of the Unity.Properties system, which is being promoted to core Unity. Once the core of this workflow is in place, we are going to review the current SerializedProperty-only binding system and improve how it will be supported alongside the more generic one.

Also in spite of our performance improvements in Unity 2022, UI Toolkit still imposes a high initialization cost for even moderately complex UI. We are in a situation where it is very difficult to extract more CPU performance from the current C# implementation of UI Toolkit core systems. There will therefore be a more fundamental shift in the UI Toolkit implementation which we intend to make an order of magnitude faster. This will apply to the performance of core features that are CPU intensive, such as processing layout changes and style changes, computing transforms and preparing the geometry of a VisualElement.

Lastly, we want to dedicate some time to improving the UI Builder. Because it plays such an important role in a majority of workflows, and based on a lot of the feedback we received, we will review the architecture of the UI Builder in order to improve its level of stability and extensibility, and to make it easier for us to add new features to it down the line.

Under this general direction, we hope to provide a robust foundation that allows us to evolve UI Toolkit in a sustainable way, as well as improving the experience of using it for both tools and game UI developers.

Stay connected
As always, keep sharing feedback, asking questions and reporting issues so we can build a better UI solution for you. Also, remember to visit our Unity platform public roadmap to engage with us and submit new ideas.

Cheers,

35 Likes
2

Great news! Looking forward to seeing all the new stuff coming up.
Just as a request on the comparison page: Could you make it alternate background color? It became a bit difficult to see which went to what value in the rows :stuck_out_tongue:

2 Likes
3

Nice!

4

Good call - I’ll bring it up to the documentation team. Thanks!

1 Like
5

So this is going to come out as way meaner as it’s supposed to, but I’m genuinely confused and want to understand the current situation. I’m really wondering why the development on this is so slow. Are you running into problems with the underlying engine? Are you understaffed? I mean, I’ve read that you’re planning to start working on the in-game UI in 2023 again, and that will probably take years to be at parity with uGUI. What is the estimated time of release? 2024? 2025? 2030? By the time there’s supposed to be a working version of this the technology will be outdated again. Smaller teams will have released 2, 3 or even 4 entire games before the system will be production ready. Unreal Engine 6 with photorealistic graphics that run at half the processing power will probably be here. How can this be?

As far as I know UI Toolkit has already been in development for years at this point. If you gave me the task to develop a modern successor to uGUI on my own, I’d probably give you a timeframe of about 1 year max until full release. While I’m probably extremely wrong on this, I’d be kind of disappointed in myself if I didn’t manage to do that. How can the development cycle on this with a full team be twice or even three times the length of the development of an entire game?

I really want a new UI solution, but at the rate development is going this will never be production-ready. Just imagine if it takes until 2025 for this to be at LTS status, which is probably an optimistic estimate. By then we’ll be three years older, a new generation of consoles will probably be on the horizon, and we’re just then getting an UI system that has been in the works for 8 (?) years. UI Toolkit will be outdated the minute it is released and you could pretty much start working on an entirely new system again right away.

I really don’t want to come off as an asshole, but development just needs to speed up. By a lot. There shouldn’t be a plan to get back to in-game UI in 2023, but the plan should be to have parity for both editor and game UI by the end of 2022. I would love to understand what exactly is taking so long. We’re waiting months for an update and then the updates are a few things most developers would probably have been able to do solo in a week. I don’t see how a project like this takes more than a year in total to get into maintanance mode. As I said - small indie studios develop 30 hour long games in like 2 years. But developing a UI solution somehow takes more than 5. I just don’t get it and I’m afraid that we’ll never get out of this cycle of deprecating packages and developing new solutions that take so long to come out that they’re oudated by the time they do.

I realize how this post sounds, but I want you to know that, as a user, I’m getting really frustrated, and have observed the same sentiment with my colleagues. We’re just waiting and waiting and waiting and nothing is happening. At this point I’m not even sure I’ll be alive by the time UI Toolkit comes out. But I’d love to finally replace uGUI. I don’t know if this post helps in any way, but maybe it at least gives you some insight into how your users might perceive the pace of development. I’m sure there are various issues that I have absolutely no idea about and that’s fair. But in the end all I’m seeing is the package in the package manager and I want to desperately get away from uGUI, but I just can’t. So I’m still holding my breath that UI Toolkit becomes available before I lose my mind trying to design something nice with uGUI.

Thank you for reading my rant and I’m sorry if I offended anybody.

39 Likes
6

What is Mask clipping in the system compare list? Do I need to wait for that before I can make round buttons? I have no experience with UI Toolkit.

7

You can do round buttons already. You can also do masking (see https://discussions.unity.com/t/833007 ), but not based on e.g. transparency values of a png.
Hope that answers your question!

8

Don’t be sorry! Posts like this are helpful. As any company Unity needs to balance investment between different areas and the community can influence what gets the most attention. So thanks for that. We understand and acknowledge your frustration.

Something I wanted to clarify that when we are saying “2023”, we’re talking about Unity version 2023. The development for 2022 is already over internally at Unity, it will be just in stabilization mode until 2022 LTS releases. Which means that new feature development is already focused on Unity 2023.

To get to your main point, all I can do is offer some perspective about why it takes more time than you would imagine.

First of all, UI Toolkit is already released since version 2019. It is used extensively for building Editor Workflows which comes with quite a few unique requirements compared to game UI. As you can imagine we have to maintain and support the existing feature set. A sizeable share of time goes towards this. As mentioned in the first post, replacing IMGUI is also our goal - and this is a huge effort.
Since version 2021 it’s also possible to use UI Toolkit for game UI. For your needs, it may not need be ready to replace UGUI but some users have started to adopt it. Which further increases the amount of support required.

On top of that, I’d make the claim that building a UI system on top of Unity is a different story than building a UI System for Unity. Our velocity is nowhere near as a fast as some individual/team working on a UI system in an external environment. What I mean is that contributing to Unity comes with a bunch of practices that you simply don’t have to care about when you’re outside of our organization. It’s not that this will necessarily lead to a better outcome - it’s just the overhead of working in a large organization on a large scale codebase/product.

Finally, I don’t think using game development timelines as a comparison is entirely fair. We deliver a framework that can be used in different contexts with many different possibilities for things to go wrong. We spend a lot of time designing, documenting and maintaining APIs for the long term. Having worked in the games industry I don’t think these are concerns in a game production.

Again I understand your frustration. We feel it too. We would like to get there faster. Please trust that your goals are aligned with ours and that any time there is an opportunity to go there “faster”, we’ll take it.

21 Likes
9

Hey,
would you mind clarify something for me please.

Are Editor tools created with UI toolkit in 2021 LTS fully functional in future versions?
Also, are tools created in later versions fully backward compatible to 2021?

So is the package “seperate” and shared between Unity versions?

Thanks!

10

There is no “package” (anymore). UI Toolkit, UI Builder, and runtime support are all part of core Unity. For the brief period where UI Toolkit was also in a separate package, specifically for Editor UI, it was always a mirror of what was in core Unity (it just gave you the option to override the module in core Unity). Even in 2021, you should not be using the package for creating Editor UI.

So regarding your questions around forward/backward compatibility, you can assume the same rules apply to UI Toolkit public APIs and asset formats as all other public APIs and asset formats. Generally, nothing should break moving to a newer version, but move from 2022 back to 2021 is not guaranteed to work (2022 will have newer features not in 2021).

3 Likes
11

Still no support for custom shaders? :frowning:

4 Likes
12

Hey, just wanted to say I’m unable to use UI Toolkit runtime without worldspace support :confused:

7 Likes
13

Where ideally we would get it all in a single tool, at least, we can combine UI Toolkit features with UIGui to get worldspace and custom shaders.

14

But at the same time, any changes made to the package version that enable custom features, like:

  • custom ui builder editor for your custom components
  • play sound uss property on set or remove (this means things like playing a sound on :hover)
  • force render VisualElement to RenderTexture so I can drag and drop the element without a care in the world.

These and some other things I’ve changed on the package version but can’t remember right now or using internals access are not possible on the ‘core’ version of UI Toolkit, so I don’t see any reason for me to ever update.

15

+1 editable source access is better for everyone.

Some points made by Unity dev in comparison to NuGet (compiled code packages):

16

If you rename enough namespaces and APIs, you might be able to continue to use the Runtime package in newer versions of Unity. But it’s a stretch.

Main reason to update is to get new features, fixes, and workflow improvements. And while it may not be as seemless or extensive, you can still customize the behaviour of UI Toolkit quite a lot without the need to edit source code.

Those points do not apply as nicely to a core Engine (and Editor) dependency like a UI framework. The reason we went back into the core product is because much of the Engine/Editor has a dependency on UI. Our current package ecosystem does not support this setup. While we did have a package/core duality for a little bit, this was not sustainable in terms of support burden and stability/quality.

Furthermore, the way the package worked to override the built-in UI module (used by the Editor itself), meant that you could crash/break the whole Editor if you changed package source code in a way that broke public (and sometimes internal) APIs. So it wasn’t a very nice experience even when it was a package with source code.

We’ll get back to a world of packages some day. But we have to wait until we break up the monolithic Editor a bit more. UI Toolkit tried to be a package too soon.

1 Like
17

Would love to see some of the more basic issues solved before new features

  • Exposing some internal properties, for example Node OnConnect and OnDisconnect as well as the DefaultEdgeConnectorListener, cant understand why these are internal and private
  • InspectorElement just plainly not working - the accepted solution right now is to use a
    IMGUIContainer with an Editor
  • Image not supporting any kind of binding, why?
  • Lack of z-index support - I know this is technically a feature but it feels like a bug as it requires really weird workarounds for simple stuff like tabs and drag&drop functionality
18

[quote=“uDamian, post:16, topic: 892659, username:uDamian”]
Those points do not apply as nicely to a core Engine (and Editor) dependency like a UI framework. The reason we went back into the core product is because much of the Engine/Editor has a dependency on UI. Our current package ecosystem does not support this setup. While we did have a package/core duality for a little bit, this was not sustainable in terms of support burden and stability/quality.

Furthermore, the way the package worked to override the built-in UI module (used by the Editor itself), meant that you could crash/break the whole Editor if you changed package source code in a way that broke public (and sometimes internal) APIs. So it wasn’t a very nice experience even when it was a package with source code.

We’ll get back to a world of packages some day. But we have to wait until we break up the monolithic Editor a bit more. UI Toolkit tried to be a package too soon.
[/quote]I see but let’s be honest the longer runtime part of UI Toolkit isn’t decoupled from code required by the editor the tougher it will be to do in the feature. Maybe it wasn’t “too soon” but something wrong with the architecture to begin with.

Anyway that’s the past that can’t be changed. Hopefully Unity understands how important source access is. Unfortunately “some day” doesn’t sound very promising.

19

These are GraphView APIs. GraphView never got out of the experimental/unsupported stage. It’s being kept alive for now because it’s used by ShaderGraph (and other internal products) but there are no plans to make any non-bug-fix improvements. That said, there’s a dedicated team working on a replacement for GraphView that will be released as a proper graph UI framework. No ETA on that yet though.

2022 LTS (or 2022.2 if you open to betas/non-LTS) has a lot of improvements and fixes around nested InspectorElements. I recommend a look if you get the chance.

Image has always been an odd element. It goes a bit against UI styles driving layout and instead has the content (the image) driving the layout. Unless you’re making an image editor of some sort, it’s recommended to set the size of your VisualElement “images” from USS or from C# (which could still read the dimensions from the image asset first).

Don’t get me wrong, I don’t think it was good to introduce the Image element and then leave it untouched for so long. I’m just adding some context on why this controls has not seen a lot of updates. Could change in the future.

We are aware. It will come. It’s slowly making its way up the backlog.

2 Likes
20

Hey all, thanks for your work on UI Toolkit. Here’s a bit of feedback - why is there no care put into the default look for custom inspectors?

Here is an image taken from this page of the documentation:

Why is there no padding at all?
Shouldn’t the UI look nice by default?