Hearing these changes from older versions has me excited to check out UI Toolkit again. I last used it when custom elements required a lot of work, so seeing how easy it is now makes me want to come back and try it again.
Thanks for this video! In my work I made a text data binder that we use everywhere for bindings, but it needs so many boilerplates and performance degrades over time if the variables increase too much. This kind of reflection workflow is very fascinating to me. Can’t wait to use UI Toolkit in production!
Unity UI design is one of those areas I have almost entirely ignored for years. As a former web developer, presentation was kind of my bread and butter but working with Unity's UI tools felt so archaic. "Can't I just do this??" I never looked at UI Toolkit. Need to go give it a try now...
Really informative and well structured video. You forgot to mentioned that layouts are handled 100000x better in UIToolkit! That alone is enough to make me want to use it more.
UI Toolkit shows great promise, but it's missing some highly requested and imo needed functionality that Unity really needs to get a move on implementing. It has no World Space UI (WIP), no depth ordering (planned), UI masking (planned), Grid layout, UI effects like gradient, glow, blur etc, SVG support, the list goes on. This is by no means "Ugh, UI Toolkit bad", it's a great step forward. Web development is often very UI focused, so taking that direction with game UI is a smart choice. I have been using it through OneJS from the asset store and it helps with getting something basic up and running really fast once set up. OneJS use Jint (js -> C# interop) and custom C# code so you can write normal web code (js/ts, html and css) and uses native UI Toolkit underneath for rendering UI. (And has a v2 in the works with huge performance boosts among other things)
As a web developer I find referencing ui elements with ids and classes to be far more practicle than adding references. It's true that names can change, but it's far less annoying to deal with than losing references to objects when copying objects or moving them around. Having to expose dozens of variables to the inspector and manually drag/drop them is also pretty annoying.
Been playing a lot with UI toolkit to make commercial tools for over a year. It is my definitive best UI tool to use. - It's quick to design visuals. - It naturally separates visuals from logic. - It's far more intuitive to handle when you get the gist of it than either UGUI or Unreal's UI system. The only real drawbacks at this point is the lack of worldspace, the abysmal documentation, the, more often than not, terrible default VisualElements, and the monstruosity that is the UXML factory (although as you showcased there is a big change for that last one, so yay!).
AINTNOWAY I just had a game jam last weekend doing UI with UITK for the first time xdd Could've used this vid then! Awesome though, keep the content flowing
What I liked about the Unity UI was its OOP based approach. Hear me out. CSS and JS are powerful in their own rights, but nothing beats OOP based UI framework when it comes to adding something procedural or automated. Your game has a long list of attachments to be added. Sure, just hook them into a ScriptableObject or DataAsset and the system will handle on its own. This is possible to some extent in CSS and JS based languages but they are nowhere near as powerful as they are in OOP UI. For the ease of use, I think UI Toolkit is fine (except for boilerplate). But when it comes to extending for a massive game, I think it would fall apart very quickly. Hopefully, Unity UI still stays around while UI Toolkit gets better and better. Also, praying that UE5 UI system gets better.
@@LtdJorge I highly respect your opinion. I think it depends more on the person, what they feel comfortable working with rather than the language model itself.
Im currently experimenting with this and one thing that would be nice is basically the way WPF handles references from cs files to (in their case xaml, here umxl) the ui code like you can give an element in the ui an ID and then just access that element without querying first. This would require some closer linking of uxml and cs since the cs file would have to know about the uxml file somehow. This brings me to another point. Creating custom elements has been greatly improved like you said, one area where its still lacking is if you want to design custom controls with uxml and c# code. For that you have to load the uxml file in the cs file and clone the tree onto the own element. This process is annoying, error prone and has some limitations. For example you would need another uxm file wrapping around your custom element when you want to use it directly in a UI Document since that need a uxml file (or you make your own custom loader script but thats also annoying). Another thing that is a bit weird with cusom elements is namespaces inside uxml. You can define them but if your item is called the same as your namespace it gets weird and you might have a lot of time spent figuring out why some stuff is not working. Thats just some of the things i struggle with, there are more but overall i still prefer this over everything we had before. In my personal project i worked around some of the stuff i mentioned by writing my own attributes and generators etc. that make some stuff for me, but i would really appreciate some good support from unity directly.
4:43 Although 'world space UI' is not supported, there is another approach that can be used for things like floating health bars, item names and so on. (1) Create normal UI in screen-space. (2) Move it every frame to follow a 3D object. Of course, this is not suitable if your UI really has to belong in the 3D scene (imaging a computer screen) because it is not blocked by 3D objects and always facing the camera. But for health bars, item names, waypoint markers and so on you often want that. For those of you interested, I created a video comparing these two approaches on my channel.
Perhaps a little off topic. In my free time I study the Custom Editor, the Draw property and the editor window. I've heard about the Odin plugin but haven't used it. Have you used this plugin yourself? If yes, could you please answer my questions: 1. Somewhere in one video or article it was said that Odin is able to replace almost completely the writing of the Custom Editor, is this true? 2. In what cases will Odin not be able to do what is possible in the Custom Editor?
It still feels like the toolkit has a long way to go but this guide was excellent. It really should have been a priority to be able to set the elements as game objects automatically but, eh, there's the roadmap for you.
I often build applications based purely on the user interface, with multiple states or pages. So far, each page is either a panel or a separate canvas with a view class that is notified by a StateModel/Manager. What would something like this look like with UIToolkit? A UIDocument for each view? Or a visual element for each view? This whole root.Q() addressing seems a bit unsuitable for that.
I've been messing around in the same boat. I have no real experience to speak from so I've no idea if it's a good approach but I've just been making a different visual tree asset for each page and swapping that out on a single UI Document. It works, I guess, for now. But I'd like to see examples of how to do it right.
The lack of a world space implementation is an absolute deal breaker for me (and it's been continually brought up in forum threads and the roadmap, there's no ETA yet on when that's coming) Be keen to see how tooltip improves over the next few years though
great job, thanks for tutorial. It looks very useful except Runtime Data Binding. just that things you writed in progressbar script looks a little bit complicated.
How do you know if the mouse pointing at a button ? To prevent mouse event that supposed to happen on a button goes to gameobject behind the button(raycast).
Can someone please tell me how can i make the elements not "stack" on top of each other in the builder? I would like th be independent and movable, even if i were to overlap them, just like in old UI
do we need unity 2023.2 for the latest UI toolkit package, it's very confusing you keep saying it is 2023.2, or package can be separated from the actual unity version?
A SIMPLE UI, makes UI Toolkit seem viable. A realistic and sophisticated UI that requires serious design and art assets, is where it falls apart and reveals it's another half baked alpha test.
Cool video but honestly im not convinced for web style technologies for UI in games. Unity UI system has its problems (dumb api, needs cumbersome workarounds, poor interfaces support) but still seems enough for simple games. What does UI Toolkit bring for real? I dont mean simple scale animations or anchoring. What about some UI panels stack system? Or tabs management, better layouts system? maybe some considerable performance boost?
Yeah so you can totally build the entire thing that way if you want. That's my approach to a lot of the editor tooling I build. You can see examples of this in my recent live sessions on Graph View.
Why would you expect that two different packages made for a professional grade piece of industry software, developed by the makers of the software themselves, should be compatible with each other?
Unity UI has been the bane of my existence for the last 10 years or so. I'm right with you when you said you eventually gain that 'arcane knowledge', and you can get stuff done with it... But it is never a fun or enjoyable experience by any means. The main drawback for me is that unlike the old IMGUI, the prefab based workflow means your UI design work is decoupled from programming... Until you then need to control the UI components, so you still have to write binding scripts. So the argument that uGUI doesn't require coding just went out the window, and I _guarantee_ by the time you are r done writing the script, you _will_ hit play before remembering to assign the inspector references. Also, the layout system with its endless barrage of anchors and rectangle containers might seem good at first, as it appears to solve the most complicated part of working with IMGUI... But that also turns out to be false. It ultimately highly complicates the process of creating even simple setups, by imposing this layouting puzzle that you _must solve_ for each and every new element. It never gets easier or less prone to errors. Then the final little death for me, is styling. It's painful enough to create even basic animated bits, but wait until you then decide your project needs a reskin. The new toolkit seems like a step in a better direction... But like everything else that comes out of unity in the last 10 years, it's still a total-replacement, forget-everything-you know new paradigm... Which is still a work in progress, so you'd have to be mad to choose that for a large multi year project. I'm not going down that road again, oh no. Unet was bad enough. I will have a look at Coherent though 👍
I used Coherent on a couple of projects I worked on back in the day and uh... Let's just say forcing UI to render via an HTML wrapper on top of your runtime wasn't without its issues 😂
@@GameDevGuide That is a good point. I do miss the old ongui sometimes. It wasn't great, and leaked memory like a sieve, but it was pretty quick to put something together, and being immediate-mode, your layout _is_ the binding already. I've been looking at a package called Noesis GUI, which looks very interesting (I'm looking for any way out of uGUI by now). Not sure if you or anyone has had any experience with it to give a 'veteran' opinion.
it's arguably more performant in exchange for the learning curve and verbose coding. Honestly speaking, most of the time, UIs aren't the bottleneck of a game so I wouldn't use performance as a benchmark to measure UIToolkit vs UGUI.
Me: Was using UIToolkit for 4 years in runtime and stopped using unity after 2023 events. Unity: Well since you've stopped using our game engine we start to implement new features there, like "partial" class support.
This goes way too fast I had to slow it at 75%. Even then I had to rewind regularly because what is going on is too quick and the explaination too late.
but is it really at the point? ugui addons and things that you still cant't do with ui toolkit.. I mean its still a subpar spec to css3 they ain't bothered with a lot of things css3 actually does and that can be done with ugui with addons with ease.... data tables anyone?" It "has no World Space UI (WIP), no depth ordering (planned), UI masking (planned), Grid layout, UI effects like gradient, glow, blur etc, SVG support, the list goes on. " ...exactly.. Unity snail time pace timeline of replacing old feature tech with new feature tech is just ridiculously slow
Hearing these changes from older versions has me excited to check out UI Toolkit again. I last used it when custom elements required a lot of work, so seeing how easy it is now makes me want to come back and try it again.
Thanks for this video! In my work I made a text data binder that we use everywhere for bindings, but it needs so many boilerplates and performance degrades over time if the variables increase too much. This kind of reflection workflow is very fascinating to me. Can’t wait to use UI Toolkit in production!
This video couldn’t have come at a better moment!
that was a lot to digest but down the line it's going to be super helpful, thanks
This dropped at a great time!
Dropped harder than my grades
Exactly what I was looking for, thank you :)
Unity UI design is one of those areas I have almost entirely ignored for years. As a former web developer, presentation was kind of my bread and butter but working with Unity's UI tools felt so archaic. "Can't I just do this??" I never looked at UI Toolkit. Need to go give it a try now...
Really nice video showing why UI Toolkit is powerful !
Perfect, just what I was looking for.
Please more!
Oh wow, this is perfect. I was thinking I have to sub and noticed I already am subbed, lol. Cheers!
Really informative and well structured video. You forgot to mentioned that layouts are handled 100000x better in UIToolkit! That alone is enough to make me want to use it more.
This video might just tip the scale for me towards using UI Toolkit now. Thanks!
Thanks for this video! UI toolkit seem pretty cool with editor too, hope you make a video about it in the future
My Live Sessions on GraphView explores the editor version in detail if you're interested in learning more there.
Nice just in time, I start to give up using UI Toolkit
Please do more tutorials on the UI Toolkit! There are - of course, since it's very new - almost 0 out there for 2023.2+!
this is perfect. thanks!
UI Toolkit shows great promise, but it's missing some highly requested and imo needed functionality that Unity really needs to get a move on implementing. It has no World Space UI (WIP), no depth ordering (planned), UI masking (planned), Grid layout, UI effects like gradient, glow, blur etc, SVG support, the list goes on.
This is by no means "Ugh, UI Toolkit bad", it's a great step forward. Web development is often very UI focused, so taking that direction with game UI is a smart choice. I have been using it through OneJS from the asset store and it helps with getting something basic up and running really fast once set up. OneJS use Jint (js -> C# interop) and custom C# code so you can write normal web code (js/ts, html and css) and uses native UI Toolkit underneath for rendering UI. (And has a v2 in the works with huge performance boosts among other things)
As a web developer I find referencing ui elements with ids and classes to be far more practicle than adding references.
It's true that names can change, but it's far less annoying to deal with than losing references to objects when copying objects or moving them around. Having to expose dozens of variables to the inspector and manually drag/drop them is also pretty annoying.
Been playing a lot with UI toolkit to make commercial tools for over a year.
It is my definitive best UI tool to use.
- It's quick to design visuals.
- It naturally separates visuals from logic.
- It's far more intuitive to handle when you get the gist of it than either UGUI or Unreal's UI system.
The only real drawbacks at this point is the lack of worldspace, the abysmal documentation, the, more often than not, terrible default VisualElements, and the monstruosity that is the UXML factory (although as you showcased there is a big change for that last one, so yay!).
AINTNOWAY I just had a game jam last weekend doing UI with UITK for the first time xdd Could've used this vid then! Awesome though, keep the content flowing
What I liked about the Unity UI was its OOP based approach. Hear me out. CSS and JS are powerful in their own rights, but nothing beats OOP based UI framework when it comes to adding something procedural or automated. Your game has a long list of attachments to be added. Sure, just hook them into a ScriptableObject or DataAsset and the system will handle on its own. This is possible to some extent in CSS and JS based languages but they are nowhere near as powerful as they are in OOP UI. For the ease of use, I think UI Toolkit is fine (except for boilerplate). But when it comes to extending for a massive game, I think it would fall apart very quickly. Hopefully, Unity UI still stays around while UI Toolkit gets better and better. Also, praying that UE5 UI system gets better.
I think OOP puts a limit to scalability. Doing UI with Unity UI for a AAA game would make me go insane. Declarative > pocedural/imperative any day
@@LtdJorge I highly respect your opinion. I think it depends more on the person, what they feel comfortable working with rather than the language model itself.
You don’t need to use editor at all to work with Ui toolkit, just creating the buttons in code and using the styles. Counts as oop?
Try NovaUI, it has the "OOP" workflow but it crazy performant, and the underlying systems are put together really well.
@@LtdJorgeIn which perspective? Visual or coding?
Im currently experimenting with this and one thing that would be nice is basically the way WPF handles references from cs files to (in their case xaml, here umxl) the ui code like you can give an element in the ui an ID and then just access that element without querying first. This would require some closer linking of uxml and cs since the cs file would have to know about the uxml file somehow.
This brings me to another point.
Creating custom elements has been greatly improved like you said, one area where its still lacking is if you want to design custom controls with uxml and c# code. For that you have to load the uxml file in the cs file and clone the tree onto the own element.
This process is annoying, error prone and has some limitations.
For example you would need another uxm file wrapping around your custom element when you want to use it directly in a UI Document since that need a uxml file (or you make your own custom loader script but thats also annoying).
Another thing that is a bit weird with cusom elements is namespaces inside uxml. You can define them but if your item is called the same as your namespace it gets weird and you might have a lot of time spent figuring out why some stuff is not working.
Thats just some of the things i struggle with, there are more but overall i still prefer this over everything we had before.
In my personal project i worked around some of the stuff i mentioned by writing my own attributes and generators etc. that make some stuff for me, but i would really appreciate some good support from unity directly.
Great video, thanks!
How did you implement the repeating background (orange squares) in your main menu, please?
4:43 Although 'world space UI' is not supported, there is another approach that can be used for things like floating health bars, item names and so on. (1) Create normal UI in screen-space. (2) Move it every frame to follow a 3D object.
Of course, this is not suitable if your UI really has to belong in the 3D scene (imaging a computer screen) because it is not blocked by 3D objects and always facing the camera. But for health bars, item names, waypoint markers and so on you often want that.
For those of you interested, I created a video comparing these two approaches on my channel.
Perhaps a little off topic.
In my free time I study the Custom Editor, the Draw property and the editor window. I've heard about the Odin plugin but haven't used it. Have you used this plugin yourself? If yes, could you please answer my questions:
1. Somewhere in one video or article it was said that Odin is able to replace almost completely the writing of the Custom Editor, is this true?
2. In what cases will Odin not be able to do what is possible in the Custom Editor?
Great video, thanks 🙂 Does it have any impact on FPS and have you tried using a controller with it rather than a mouse?
It still feels like the toolkit has a long way to go but this guide was excellent. It really should have been a priority to be able to set the elements as game objects automatically but, eh, there's the roadmap for you.
I often build applications based purely on the user interface, with multiple states or pages. So far, each page is either a panel or a separate canvas with a view class that is notified by a StateModel/Manager. What would something like this look like with UIToolkit? A UIDocument for each view? Or a visual element for each view? This whole root.Q() addressing seems a bit unsuitable for that.
I've been messing around in the same boat. I have no real experience to speak from so I've no idea if it's a good approach but I've just been making a different visual tree asset for each page and swapping that out on a single UI Document. It works, I guess, for now. But I'd like to see examples of how to do it right.
The lack of a world space implementation is an absolute deal breaker for me (and it's been continually brought up in forum threads and the roadmap, there's no ETA yet on when that's coming)
Be keen to see how tooltip improves over the next few years though
Dont understand how works the new UI. I added a Progress bar and i cant modify any of the style properties of the child objects, all are greyed out
I must learn ui toolkit, new Input system and shader graph... when will it end😢
great job, thanks for tutorial. It looks very useful except Runtime Data Binding. just that things you writed in progressbar script looks a little bit complicated.
Video idea: recreate the Persona 5 UI using UI Toolkit
Great video. Gonna show this to the people in the office.
How do you know if the mouse pointing at a button ? To prevent mouse event that supposed to happen on a button goes to gameobject behind the button(raycast).
I'm new, can I please have github link for this ? because I try copied the codes in the C# script and it contains error
Can someone please tell me how can i make the elements not "stack" on top of each other in the builder? I would like th be independent and movable, even if i were to overlap them, just like in old UI
Set the position to Absolute instead of relative. 🙂
@@GameDevGuide Thank You!
do we need unity 2023.2 for the latest UI toolkit package, it's very confusing you keep saying it is 2023.2, or package can be separated from the actual unity version?
You need 2023.2, its not a separate package, but part of the core editor.
In the early mid of video you have leave resources for flex, but I cannot find them...
A SIMPLE UI, makes UI Toolkit seem viable. A realistic and sophisticated UI that requires serious design and art assets, is where it falls apart and reveals it's another half baked alpha test.
May you please make more?
how did you get that new menu when you right click? Is it new with unity 6?
As mentioned in the video, this is unity 2023.2.
@@GameDevGuide im in 6000.0.0b13 I guess they removed it, thanks for the help.
LET'S GOOOOOOOOOOOOOOOOOOO
Cool video but honestly im not convinced for web style technologies for UI in games. Unity UI system has its problems (dumb api, needs cumbersome workarounds, poor interfaces support) but still seems enough for simple games.
What does UI Toolkit bring for real?
I dont mean simple scale animations or anchoring. What about some UI panels stack system? Or tabs management, better layouts system? maybe some considerable performance boost?
Is there a possibility you look into doing this with pure C# or building the UI with a UXML/C# hybrid?
Yeah so you can totally build the entire thing that way if you want. That's my approach to a lot of the editor tooling I build. You can see examples of this in my recent live sessions on Graph View.
does UI Toolkit works with safezones/ mobile notches ?
Does anyone knows what the game on the first second of video? With leonis planet...
Can't bind Entities?
Why would you expect that two different packages made for a professional grade piece of industry software, developed by the makers of the software themselves, should be compatible with each other?
Unity UI has been the bane of my existence for the last 10 years or so.
I'm right with you when you said you eventually gain that 'arcane knowledge', and you can get stuff done with it... But it is never a fun or enjoyable experience by any means.
The main drawback for me is that unlike the old IMGUI, the prefab based workflow means your UI design work is decoupled from programming... Until you then need to control the UI components, so you still have to write binding scripts.
So the argument that uGUI doesn't require coding just went out the window, and I _guarantee_ by the time you are r done writing the script, you _will_ hit play before remembering to assign the inspector references.
Also, the layout system with its endless barrage of anchors and rectangle containers might seem good at first, as it appears to solve the most complicated part of working with IMGUI... But that also turns out to be false. It ultimately highly complicates the process of creating even simple setups, by imposing this layouting puzzle that you _must solve_ for each and every new element. It never gets easier or less prone to errors.
Then the final little death for me, is styling. It's painful enough to create even basic animated bits, but wait until you then decide your project needs a reskin.
The new toolkit seems like a step in a better direction... But like everything else that comes out of unity in the last 10 years, it's still a total-replacement, forget-everything-you know new paradigm... Which is still a work in progress, so you'd have to be mad to choose that for a large multi year project.
I'm not going down that road again, oh no. Unet was bad enough.
I will have a look at Coherent though 👍
I used Coherent on a couple of projects I worked on back in the day and uh... Let's just say forcing UI to render via an HTML wrapper on top of your runtime wasn't without its issues 😂
@@GameDevGuide That is a good point.
I do miss the old ongui sometimes. It wasn't great, and leaked memory like a sieve, but it was pretty quick to put something together, and being immediate-mode, your layout _is_ the binding already.
I've been looking at a package called Noesis GUI, which looks very interesting (I'm looking for any way out of uGUI by now). Not sure if you or anyone has had any experience with it to give a 'veteran' opinion.
What asset is it at 9:57?
but what about performance? is ui toolkit more performant than unity ui?
Yes, much more, the UI toolkit editor can lag a little bit if there are many many elements, but the runtime speed is much better
it's arguably more performant in exchange for the learning curve and verbose coding. Honestly speaking, most of the time, UIs aren't the bottleneck of a game so I wouldn't use performance as a benchmark to measure UIToolkit vs UGUI.
CabsOfCHaos ;) I see you.
👀👀👀
I wonder how viable it is to use UiKit
Timberborn was built using it, so it's certainly usable in production and that's quite a UI heavy game.
It was also using the old version. Which is an absolute feat 😂 This newer version is much easier to work with by comparison
Me: Was using UIToolkit for 4 years in runtime and stopped using unity after 2023 events.
Unity: Well since you've stopped using our game engine we start to implement new features there, like "partial" class support.
This goes way too fast I had to slow it at 75%. Even then I had to rewind regularly because what is going on is too quick and the explaination too late.
1:11 which game is that
This looks a lot like WPF (Windows presentation framework)
There's a actually a WPF for Unity, it's called Noesis, and it's miles ahead of UI Toolkit...
but is it really at the point? ugui addons and things that you still cant't do with ui toolkit.. I mean its still a subpar spec to css3 they ain't bothered with a lot of things css3 actually does and that can be done with ugui with addons with ease.... data tables anyone?" It "has no World Space UI (WIP), no depth ordering (planned), UI masking (planned), Grid layout, UI effects like gradient, glow, blur etc, SVG support, the list goes on. " ...exactly.. Unity snail time pace timeline of replacing old feature tech with new feature tech is just ridiculously slow
First 😮 (edit: I'll actually watch the video not just a useless comment here 😅)