Official UI Update - Q1 2021

Is there a better place to follow updates on if/when world space UIToolkit UIs will be released than these quarterly threads?

 

Will it onlycover UI Toolkit, or all the stuff like ECS, Kinematica, etc..?

 

Will the product boards for URP, HDRP, ShaderGraph, and VFX Graph migrate their content to the new website as well? :3

 

Please tell me if this error occurs during installation UI Building. Unity 2020.3.0

 

We've already got a thread.

 

I can't wait to hear what Unity's next direction is with code sharing.

I've been really confused these past few years (since 2018 or so?) with what's in a package vs. not a package.
There's a lot of different workflows (kind of too many sometimes?), so I guess it just doesn't feel like "unity", if that makes sense?

 

Does 2021.2 release mean that we can expect the default inspector to be drawn using UI Toolkit by that time? Or is that a separate goal?

 

Sure! Apologies for the amibiguousness.
I was referring to @benoitd_unity 's comment regarding how Unity will develop updates to existing and new features in Unity.



For example, I love that some new packages like 2D Extras have sprung up in Github and are open-source, and let us contribute.
Makes me think I should be contributing more when I encounter bugs/issues, rather than submitting bug reports and hoping Unity QA has enough bandwidth to address my 1 problem out of everyone's requests!
(I believe UI Toolkit may be released open-source sometime soon too so we can help? Maybe?)

But not every part of Unity (understandably) is released open-source like that.
So maybe I wish I knew what the plans were for what will/will not be released in which ways (Core engine, package, open-source, Github, etc.).

In some areas, I heard that maintaining a Unity package has a lot of overhead.
Is there any way to improve that (or something we could help with? Editor workflows, custom inspectors, automation, etc.?)

But perhaps this is a very loaded question.
Maybe a cheatsheet of the various options and pros/cons would be handy.

 

Can someone explain why the changelog for compatible versions is so weird:
https://forum.unity.com/threads/ui-builder-latest-version-1-0-0-preview-13.823545/#post-6945668

`2020.117f or newer` implies it is 2020.17+ from that moment, why is there explicit mentioning of 2020.2 and 2020.3? Is there some UnityPlayer functionality that is literally removed in-between incremental versions that makes it incompatible? This is just bizzare.

 

To be completely fair - no, the explanation added even more confusion. But then again, this is in the order or all Unity things, so.

 

"sometimes even within minor versions there can be necessary changes done to the Unity code to have the package be compatible"
So something could for example work in the package with Unity 2019.4.17 but not with 2020.1.1 : therefore they also warn us which minimum minor versions are compatible.
EDIT : just clarifying for Digika, not meaning to be hostile

 

The problem is that does not resolve confusion in any way. The statements are:
```

• 2019.4.17f1 or newer
• 2020.1.17f1 or newer
• 2020.2.1f1 or newer
• 2020.3.1f1 or newer
• 2021.1.0b1 or newer

```
"or newer" by default includes "up to that version". So we have ranges:
1. from 2019.4.17f1 to 2020.1.17f1
2. from 2020.1.17f1 to 2020.2.1f1
3. from 2020.2.1f1 to 2020.3.1f1
4. from 2020.3.1f1 to 2021.1.0b1

You can literally write [2019.4.17f1 to 2021.1.0b1] and absolutely no meaning changes here. But we know for a FACT there are incompatible version. Yet we can't naturally inherit the knowledge as to which from that list. The only thing we can know for sure is that below 2019.4.17f1 is not supported because it is the lowest supported value here, so anything older is not supported. But anything newer HAS to be because it literally says and we cant apply the same logic for 2nd entry - "anything older than 2020.1.17f1 is not supported".

 

You being intentionally daft?

2019.4.17f1 or newer
2020.1.17f or newer

The only way to read that that makes sense is "2019.4.x where x >= 17f1, or 2020.1.x where x >= 17f1". That's basic semver stuff. Go be pedantic somewhere else.

 

So 2020.x.x is not newer than 2019.x.x version wise, got it. It all makes sense now. This is why SemVer was invented, to reach its culmination here and fail.

 

No one else claimed this, only you... your argument is invalid.

 

What form will bug fixes to preview.15 take? Will the first bug fix update be a .16 or something else?
For reference I am on 2020.3 and preview.14 at the moment. I don't really want to move my whole game to an alpha version of Unity just to get a new version of UIToolkit, so it sounds like I am working around issues or forking and fixing the bugs in the package until sometime late fall. I'm not planning on shipping this year so that's OK, but some things still have to work just to continue development.

 

2021.1 (both 2021.1.0f1 and 2021.1.1f1) are missing the UIDocument class under the UnityEngine.UIElements namespace. I cannot reference the class in my scripts, and I cannot add the component to my GameObjects. This strikes me as a major issue.

Edit: especially since the 2021.1 release removed the UITK from the package manager.

 

It is experimental package. Select "add package by name" and type "com.unity.ui".

 

Do NOT do this, as this will render your whole Unity project completely broken (no Editor UI, almost all blank) until you reset all packages.

Use the latest 2021.2 instead, word of warning though, the UXML and perhaps even USS reset for no discernable reason.

Better option, wait until UI documents is out of pre-pre-alpha-experiment non-sense phase. Unusable.

 

IDK. It works for me. Obviously if you are in an existing project you always use version control and if something goes wrong, you can go back to previous state...

 

Well, that sort of depends on who you mean by "ours". I'm not sure I agree with @Muchaszewski when he calls for almost full HTML/CSS support.

My concern is that those web standards are notoriously complex. Opera (who had the arguably best HTML engine at the time) and Microsoft (who have all the resources in the world) have both given up on developing their own HTML engine and just switched to the same one Google is using. Meanwhile Chrome and its memory usage have become a running gag on the Internet. And Electron apps (a framework to create desktop apps with what's basically Chrome) are also known to be massive memory hogs.

I think that the bloat is justified for website development and even app development, because you're given many tools to ease the development of said websites and apps.
But for every game that's not a spreadsheet simulator, the UI is just a small part of something much more complex. Most Unity games will be dealing with 3d models, textures, shaders, animation, physics, audio, AI, gameplay logic and perhaps networking. And I don't want the UI system to have hundreds of MB of overhead on top of that.

(It's a particular concern for me, because I currently work for a company that specializes in porting other studios' games between platforms. We've done a bunch of Nintendo Switch ports of bigger games and memory is always a problem. And guys making games for phones will have it even worse.)

 

I agree that not all games are UI-heavy, but you will still need a UI for a lot of things if you are doing a game.
- Main menu
- Settings (which is a big one usually)
- Inventory
- HUD
- Quest
- Dialogs
- Payments (usually for mobile)
- Probably more...

And all of those things need to be made for a lot of games, which takes a loooot of time. If you will have a tool that will allow for this to be made 50% quicker and more up to design - I would take all the megabytes it would take to do that.

Also no matter how complex the UI system would be, 99.9% of the UI size would be images that compose the Canvas, not the complex code behind it - as it would be at most 2-3MB compiled at most.

Actually not. Times, when you needed to fit your apk in 30MB, are long over. Most of the games I was involved with for Android and iOS were between 500-900MB, and with each project we cared even less about it, because we can download the content in the runtime with "small" 150MB client. We had never run into memory issues if I recall correctly. Alaway not optimized UI system that eat up all CPU cycles, with not-performant shaders that consumed GPU were the problem. Not memory or storage or apk size.

 

Will controls that are available for editor-only (like for example vector3) be available for runtime anytime soon?

 

@Muchaszewski I wasn't talking about how much storage it uses, but how much of your memory (RAM) it uses while running. You can compare something like VS Code, which is an Electron based app (so it's essentially a browser app with a standalone version of Chrome) to Notepad++, which is a proper, native app. VS Code (without any plugins) takes up ~220 MB of RAM without any files open. Notepad++ takes up 6.2 MB, while having a lot more features than a naked install of VS Code. And once we add plugins to give VS Code some much needed features, you're easily in the +300 MB range.

 

@JuliaP_Unity , please verify my understanding about the UIToolkit roadmap.
I am using 2021.1.x, so I am mainly concerned with support with this version (and future updates)

• "Official" Runtime UI support is pushed to 2021.2, but available in "preview" via the com.unity.ui package in 2021.1
• Runtime UI Binding is pushed until [??] (hopefully as soon as 2021.2, but since general Runtime UI support has been pushed, I presume that binding support will be pushed even farther...?)

Thanks!

 

What I gather from @benoitd_unity, @Baste & co is that UI Toolkit is far from being ready at the quality level of UGUI.
My hunch is that it won't make 21.LTS
So, could a subset of your team work on UGUI, optimize it a little and fix outstanding bugs?

 

I don't think there's much to be gained from us from polishing that turd.

It's not been deprecated, though, so they're supposed to fix bugs if bug reports show up and the bugs seem important.

 

I agree, let uGUI slowly meet its maker.

I can't say that UI Toolkit is production ready per se, but so far I was able to do most of the things I needed it to do in our current game project and the workflow is just so much better.

2Unity: Please finally add Dropdown to runtime, it's easy to make but I don't wanna waste my time on it since you will eventually introduce it. It's a really basic control component that is required pretty much in every project imaginable.

 

Examples of how the workflow is so much better?

 

Are you familiar with UI Builder?

 

yes.

 

Where would I begin...

- Flexbox. Designing layouts with it is super easy and intuitive. The uGUI anchor/pivot atrocity is just meh.
- CSS. You create a class, you apply it to all necessary elements, done. You want to change the style of all buttons? No problem - you change one line in CSS, boom, all buttons have new style. No weird copying/prefab override nonsense.
- Designing. You want to have something done quickly? Just open up UI Builder, fiddle with it a bit and you have a decent result in seconds/minutes.

And I could go on. Sure, it's not 100% production ready, but I feel like it's already way better than uGUI ever was.

 

Aside from what was already said, not using GameObjects with Components is a huge step in the right direction.

It allows you to have a dedicated UI designer that's not also showing you things that are completely irrelevant to UI design.
You also don't need to repurpose existing tools and make them do things they were never designed to do. The way UGUI repurposed the transform system is such a pain. (Boy do I love making responsive UI layouts with UGUI's layout group and fitter components.)

Transform hierarchies work great for scenes, because all your objects need is a translation, rotation and scaling in relation to their parents. And transforms are just points (i.e. they don't have a size). And this is true for all transforms all the time.
But when dealing with UI, not only do you need sizes, you also need to contend with different "modes of placement". Absolute positioning? You want to modify a position. Vertical list? You want to modify a list index. Grid layout? You want to modify row and column indices and spans.

Oh, and then there's the long-standing bug where nesting auto layout components can cause the scene to be dirtied when you open it. The components recalculate stuff and some values change from 0.000013 to -0.00007 and back again. It's not supposed to dirty them, but git doesn't lie about the files having changed.

 

Very useful, thanks but... so far I'm not convinced.
You guys sound like early adopters who either rationalize the time you spent on the tool or found this to think the way you do. Doesn't mean it's bad or good, certainly doesn't make the tool superior.
The problem with such uniform opinion is that the resulting echo chamber only consolidates feedback within the purview of the tool's philosophy, not accounting for those like me who will have to learn it and may struggle through it.
My philosophy is that I'd rather work on gameplay than waste my time with another Shuriken, VFX graph, Input System, URP or PPv2 (some of which are still a struggle for the vast majority) - if relearned has to be done it must be So I'll be the contrarian voice:

how? the UIT designer has hierachy, last time I checked it has the equivalent of component where you can stack up things to modify your text/button/whatev, I think what you mean is that the UI to add component doesn't get mixed with the rest of your project's classes. There are ways around it by prefixing components with UI which is what I ended up doing.

I don't see your point, all these are available in UGUI. Indexing is done with transform.SetChildIndex which is nice because it's the same toolset as gameplay gameobjects + the knowledge that UGUI elements that sit above others are rendered behind.

totally, it's retarded, a bug and should be fixed, that's what I was suggesting a subset of this team work on.

if it's an atrocity it should be worse that meh so make up your mind
I disagree that rect is bad, it's efficient reuse of reflexes we acquired when working with transforms, plus gameobjects gained rect tool in the process. that said I can see how a little more focused tool can improve work. Is that what you mean?

like styles? ok that's cool but... you can do something similar by using nested prefabs and the benefit of that is, again, that you re-use the reflexes gained in other areas, and UI prefabs are buggy this needs to be fixed.

Same with UGUI, Create>UI>button, plus I can drop a UI onto the agent itself (like a text bubble above a character.

Here are things that were either super clunky to me or that I was unable to do and since tuning materials and transitions account for 50% of the time I spend doing UI, I'll slap that in even if animation ain't supported yet:

1. drop in a tween component on a ui element
2. stack tweens to create a transition sequence (move here, wait a second, rotate there and if another tween interrupts transition from the current transform)
3. drop a ui element in a gameobject's script to gain direct control (like changing text, sliding a healthbar, things that take 2 line in UGUI and no special binding stuff a-la vfx graph)
4. have a ui element follow a character
5. make a button glow when I click on it
6. have a glint animation shine through a label
7. have a label start in screen space then transition to character space
8. reading any value of a ui element in code, like screen position, slider value etc... (2 lines in UGUI, no special exposing setup)

 

I am very happy that the team doesn't waste its time on hammering that abomination called uGui. I hope they can put out the new system in a more or less usable format as soon as possible with proper infrastructure.
I don't want to document ever again which UI element goes onto which canvas because they are close together in refresh frequency...

 

In CSS/USS you have variables, so you can with change only on variable change update the colors/Fonts and more for multiple components at once. With switch the css you can change the entire theme. I Think with UGUI its not that easy.

 

I don't think that just because the UI uses the "same workflow as gameobjects" that it is necessarily an advantage. UI is a beast on its own and has different requirements than working with gameobjects.The prototyping, layouting and designing in UI Toolkit is just way faster for us. Noone on our team wanted to work on the UI with uGUI anymore after having to deal with it for some time. Once we switched to UITK, this changed a lot.

Trust me, the CSS approach is way faster and easier to do than dealing with prefabs and overrides. A single line of code instead of creating a prefab, setting up the style via inspector, then duplicating the prefab. Then when you need to change the style, you have to go to the original prefab, tweak it there and hope it gets applied to all instances.

I agree UITK is definitely not production ready nor on feature parity with uGUI. Worldspace UI is not available at all. But you can do animations, for now, via code only, but Unity stated it will support CSS animations which are super easy to use.
Regarding referencing your elements via code, it's really easy:

Code (CSharp):

1. UIDocument doc = GetComponent<UIDocument>();
2.  
3. Button button = doc.rootVisualElement.Q("myButton");

 

I'm not using UI Elements for my side project, precisely because it's not ready yet. My day job is working for a company that also ports other companies' games across platforms. I worked on a bunch of different Nintendo Switch ports back to back now.
The one I'm working on right now was made in Unity. Before that, I worked on a port if a bigger game made with a custom engine of the studio that developed it. And before that, I worked on a port of a huge game made in Unreal 4. I spend months working on each project, which means that this job forces me to sit down and properly learn a great deal of different tools.

That's what I base my opinion on: the perspective gained from having to work with different tools and also not being a stupid engine fanboy. I'm under no obligation to make excuses for sub-part tools. Why would I pull punches when talking about the quality of an engine that has been around for so many years?

I was talking about hiding things that don't matter when designing UI. I'm just going to go over Unreal's UMG UI designer. UMG has its flaws, but the designer isn't one of them.

Spoiler

Before we go over the sections I highlighted, I want you to understand that notice that everything (even the menu bar on top) is filtered. There's nothing unrelated to UI design here.

1. This is like your project window, except that it only shows UI elements (built-in and your own)
   Why does Unity clutter my menus and context menus with options l like adding a terrain collider to a UI button? Why can I add a cloth component to a canvas?
2. This is your hierarchy, except its only the UI element you're working on. You can now get something similar-ish in Unity with the prefab edit mode.
   One difference is that UMG encapsulates the "prefabs", so it hides the hierarchy of the "prefabs" you add. When editing a layout that composes a bunch of buttons into a menu, you can't unfold a button to see what its made out of. This keeps the hierarchies you see in the editor reasonably flat. If you think that's a limitation, I can assure you that it's not. UGUI and UMG work very, very differently, even though they look similar on the surface. That's why I put "prefabs" into quotation marks when talking about UMG. UMG widgets aren't the same as Unity prefabs, GameObjects or components.
3. UI animation tool built right into the UI designer. It's also simplified a lot compared to the big, fat animation tool of Unreal. Stuff like IK and ragdoll physics don't apply to UI, so why not have a streamlined UI animation tool?
   It even embeds the animations you create directly inside the UI element, rather than creating separate animation controller and animation clip files like Unity does. You're never going to add your button controller to your character or vice versa, so why should they both show up in the same context?
4. The slot system of Unreal's UI system is what I was getting at with the second point I made in my post. It is a clean solution to what Unity hacked together with the RectTransform.
   In the hierarchy you can see that the "TitleLabel" is added to a "Vertical Box". On the right, you can see that the slot is a "Vertical Box Slot", which just gives you limited options (e.g. you cannot set the position or the anchors). If you put it into a canvas, the children have a "canvas slot" instead and you can set position and anchors, but not fill. If you put it into a grid, you get different tools yet.
   In Unity, you always have a RectTransform, even if its settings aren't available to you. Some things may be greyed out depending on whether you added a layout component to the parent and what its settings are. Of course, it changes the settings uniformly for all children, so if you want to change settings per-child, you then have to add a "LayoutElement" to the child. So you're adding a component to basically turn off the RectTransform and automate it, but then you add a LayoutElement to selectively cancel that out.
   It's a giant hack.
5. The viewport. 2D and automatically centered on the UI. Also gives you tools for previewing resolutions, dpi scales and quick 2D snapping options.
6. One click and you're scripting the UI element, because like with the animations, the script of the UI element is directly embedded into it. Again, why would you make it a separate script file that shows up outside of the UI designer? In Unity, adding a Button component to a terrain doesn't work, so why does it show up in the first place?

Trying to declutter your editor with naming conventions and folder structures is a workaround. It's not reliable (especially when you're working with a team of programmers, artists and designers). And it also proves my point that there's a problem. After all, if there's no problem you wouldn't need a workaround, because there wouldn't be anything you'd have to work around.

I'm talking about designing UI, not programming. See the above list.

Didn't you say that you're someone who'd "rather work on gameplay than waste his time"? Because building your own styling system with prefabs sure doesn't fall under working on gameplay. And if you're working with artists, then you also need to take care of an artist-friendly editor workflow that can compete with swapping out style-sheets in a WYSISWG UI editor.

That's not a real benefit. All it means is that you'll be a bit quicker to pick up the UI, because it uses tools you already know. Unless your dedicaded UI tools are garbage, using the regular hierarchy, prefabs, GameObjects, componenents and transforms will save you a few hours of learning at most. And any but the smallest projects are going to take you hundreds, even thousands of manhours. Over the course of a project, all the inefficiencies of using repurposed tools are going to waste you a lot more time than you saved initially.

 

Mhh. The same can be argued about anything unity offers. Possibly any tools in general. Anything not legacy is not yet production ready , or at least the margin is damn razor thin. I mean you could go and use 5.4 and get some stuff done with imgui , but for someone familiar with frontend dev , it's one of those very rare occurrence where a new thing actually offers a significant productivity boost an makes sense. At least if you have a past in web frontend.
I will use it in production simply because i refuse to go back. Aiming for a year and a half production cycle , it's worth the potential pain/ trouble of having an unstable ui branch.

 

When you manage to push out a stable version, PLEASE make a setting up tutorial, because after browsing your documentation for weeks, I personally still haven't got a clue if my UI Toolkit package isn't working because I set it up wrong, or because the package is broken.