String lookups are a huge problem. Rider has a nice feature where they'll throw a warning when a scene string is not found in the current scene list... This would go some of the way to alleviate the downside. Another option would be a generator to create an enum list or something, but that would require script compiling for each new element, which is ew. Frameworks like WPF do it really well by providing instant IDs on the view backing script, seemingly instantaneously. Maybe something to look into.
Saying the following from someone already testing out UI Toolkit in Unity version 2023.1 Alpha. For the string look up it is a lot better. They already have an initial release of the new Properties system. There is a thing called property paths that helps make this a lot less annoying. Property paths will be implemented by Unity behind the scenes, but can be added for making custom serialization of things that normally can not be serialized. You can use a property container to associate any type of .net object whose system.type is associated with a property bag. Property bags are a collection of properties that can be lazily loaded in editor or using source generators. Using the combine functionality of the property system you can get values from objects a lot easier without using string look ups. Examples scenes in the scene list would be a group of properties in the scene property collection. You can grab, check if they exist, retrieve any data from scenes in the scene property collection via the property values like int of index in scene list, name of string, or serialized yaml value. Due note this is not just for UI Toolkit. It can work for a lot of stuff. Been using it for in test projects mainly for the Property Visitors and Property Adapters. Made a custom save and load system that can serialize Visual Element properties so I can save graph tool data in a scriptable object. Using it for dialogue, AI Behavior Trees(WIP), and a graph based cut scene system(Also WIP).
@@ShatterFantasyStudio went to ♥ this comment and realised it wasn't my channel. Thanks for the info mate! That might be enough to push me into giving it a shot
@@Tarodev Just a little warning the only true downside I found so far is a lack of documentation and I do mean a lack for better of the meaning for properties version 2.1 and newer. Properties version 2.0 had a huge refactor and that changed a lot of how it worked so the documentation is being reworked. It has been around for a while just not publicly used and only been for Unity eyes. Just some things to look into if you want to use it. PropertyCollection is a struct that can be used to enumerate properties with no allocations in almost all situations. Really good for grabbing a list of properties in any .net object and enumerating over them with a lot of generic typing support. I use this to grab a list of properties from scriptable objects an enumerate over them in an editor window to bind the data values to UI elements. This is a major key point for getting away from the string based binding paths. Due note PropertyPath is not a string it is a struct that implements the IEquatable interface making use of values equality checking. The struct has appending support function for dynamically creating new paths from one already made or adding paths to one. The PropertyPath struct sets it's path in parts that can be referenced by an index, key, or string to grab a certain part of the path. The power of the above mentioned is PropertyPathParts are also structs that have a key value that can be any object not just a string. That previous statement is what erases the issue of the heavy string look up system allowing anything to be used for a path. Int, Scriptable Object, T, basic System.Type and so forth. Note I am talking about .net object not unity.object allowing for a huge amount of wiggle room and customization. Example of this is grabbing the values in Item Scriptable Objects in my RPG editor and binding the data fields to an item editor. Overload for IPropertyBag.GetProperties for customizing how properties are retrieved from property bags. I use this for making a custom serialize system that can save and load data of objects Unity doesn't normally support serializing. Anything related to PropertyVisitors and PropertyAdapters. They have a built in TypeConversion system that can pass values back with ref types. The TypeConversion system has a TryConvert function as well for those that like try,catch, and finally. It also can be used to return a bool if it fails just like TryGetComponent allowing for clean up if a conversion works or not. Sorry for the long response, but I know documentation is lacking so I wanted to give you a nice detailed description for a place to start if you want to look it up yourself. Hope this gave some good information.
@@ShatterFantasyStudio But how do you find UI object by type? how can you drag a UI element in the inspector. The whole ID thing will be really slow and hard to manage if you are building a very complex UI.
@@leeoiou7295 Not really you can use UXML documents to drag UI Elements into the inspector and also design them with them. To find an object by type you can search the UI by their control types. Controls are the cs classes that make up the UI Elements that you can drag and drop inside of the UI Builder. When you do something like root.Q you are querying the control type Button. You can add filters for Buttons with a certain ID (name inside of Unity), classes, values and so forth in code. You can do the same thing with other UI Objects. For searching non UI Objects by type you can search by system.type and check use the IS keyword to make sure an object is of type and enumerate through them. Enumerations can be filtered and step through quite easily after that. There are several other ways that are simpler than this way they added recently I just haven't played with them enough to go into a detail explanation about them yet.
I'm using UITK for 2 years now on a huge project and honestly, the pro and cons that you give are straight on point. My main issue right now is related to animation, for the rest of it I find it really amazing to use it. The fact that you can override VisualElement and make your code run in Editor and runtime is truly amazing. I would just add one thing on your "Should you use UITK / UGUI / Nova UI", it would be "Do you need a Visual Tool ?". The fact that UITK is WYSIWYG was an amazing thing for me because I'm working with artist that needed visual feedback. Whereas UGUI is quite static and you need to play your game to get proper feedback.
hello, im new to it and i cant find out how to display a dynamic list of buttons from a list, i dont know how to "instantiate" buttons, i was wondering if you could help me as i couldnt find anything on docs or forums
Personally I love ui toolkit. But I'm also coming from web development. I can imagine for those that aren't it's an entirely new skill to have to learn. I just hope this doesn't turn into another deprecated unity solution because of the mixed reviews.
Great video. I put UI Toolkit back away quite quickly. For example I opened up a UI Document, create an element. Tried to set the relative position to 10% left and 10% right...and the element is off the screen (i tried negative 10% too just in case)....if something so simple as setting a % position of an element is difficult then this thing is going to be an absolute chore. The perform also seems to be shocking; am adding a copy of test UI documents to my game the performance tanked.
The lag in UI Builder is probably redrawing the element(s) when you change its opacity or whatever else you are change. Not exactly reasonable but it does make more sense in that case.
You're point about whether or not you are familiar with web development is so true. I watched another toolkit video and they described it as being so simple, but all the web terminology just threw me through a loop and a few minutes in I had no idea how the things they were doing were connecting or where the things they were referring to were in relation to a game space, and I couldn't figure out how to break apart the visuals and customize them with my own, etc.
I tried learning UI Toolkit for 2.5 weeks now... my conclusion is... ppl should stay away from it... i come from a web dev background... and stil find the workflow of ui builder to be excessive. i found that i always have to go back and forth from the builder to unity main window, and to rider...(if you dont have a huge monitor, you will cry) I get random warning while using it, and after a few hours it bugs out, and i have to restart unity. its just a nightmare to work so now i'm trying out doozy ui cuz its on sale ...i wonder how it will go..
At least with the new input system Unity can generate a C# class so everything can stay strongly typed - if you push the right buttons. I've managed to avoid strings this way. Makes me wonder if they could do something similar with UI Toolkit.
@@OneWheelStudio I've had no problems with UIToolkit. There is no need for strings at all if you build from C#, which I find much more convenient anyway. I use UIBuilder to prototype, then build reusable custom controls in C#. You can generate the UXML document, populate it with controls, add stylesheets and assign styles, all from C#. You can even generate world space UI but it's not as straight forward as UGUI at the moment. My experience has been pretty positive. There is also a UGUI container which will allow you to host UGUI controls if you need to. As far as changing the width of the slider, that is simply a matter of using the debugger to find the name of the Unity style and overriding that in your stylesheet. I usually inherit from the Unity controls and style my own. The learning curve is a little steep at the moment but it is really flexible and powerful. Just my two cents in defence of UIToolkit 😉
one thing that is...frikken hard to find but really useful is the debugger for the ui toolkil. it can be a pain in the ass sometimes to see why something is the way it is (like in my case my entire ui was only taking up about a third of the screen, in the ui builder it seemed fine, but in game view it was 1/3 of the screen. what happened was i had a selector for "TemplateContainer" and i guess the whole thing must be in a templatecontainer when added to the game. and my selector had a width of 33% no matter what system i use i struggle making UI because i'm just not that good at art and by extension ui. im more of a functional kinda person a "i need a thing that will call this function" sorta person. i want it to look good but have no idea how to do that and little idea when i've accomplished it.
I tried porting a menu from my game to UI toolkit as an experiment and decided two things: I think it is great for what it can offer, though I think it is not ready for production yet.
I have mixed feelings about both the old UI methodology and this newer one. I love the speed at which i can do my layout and the most basic stuff using UI Toolkit. I have very little webdev experience, mostly coming from my university years, but i felt it was enough. I don't however like the way you can use a scrollable container. It feels needlessly convoluted. I also don't like the way user input is handled. I've had a disabled UI pop back into existence because the events taking certain inputs were still hooked. Took me like a week (i'm a newbie hobbyist) to figure that stuff out. I hope they work on it a bit (a lot) more and make it more user friendly AND hopefully allow it to play nice with the old way of doing things. It has a lot of potential and despite the different workflow from the standard Unity one, i feel like once people get the hang of it it will really make stuff better UI-wise. Faster to draft a UI (probably the same to get the nitty gritty stuff going), decoupling of the UI from the game itself, all that stuff is really nice. But it's not exactly the perfect system right now and this IMO hurts it in the long run because it slows transition to it. Maybe to the point of stopping it altogether if they keep delaying development of it.
i tried using UI Toolkit, coming from a web dev background i though it'd be a breeze to use. and it was! i was creating react like components in code using classes with constructors. that stuff is great! but then came the USS (css) styling and it was a terrible experience, genuinely unusable. it lacks so much functionality that you'll end up needing to implement yourself in c#. i ended up finding it too slow to use for production. there isn't even a 'aspect ratio' styling, so good luck creating a perfectly scalable UI without breakpoints using % sizings. i returned back to nova UI, even though that's not perfect either.
One thing I hate about ui toolkit is the buggy "constant pixel size" panel setting, otherwise if fits well into my workflow and I'm from web development.
Well, it design to replace IMGUI to built custom editor first. You shouldn't use it in game runtime right now. For the custom editor, the api is stable enough to adopt UIElement (fallback to IMGUI with imgui container when you can't do something that require IMGUI quirks). As for UIBuilder, it barely functional. API of exposing custom core control stuff to UIBuilder is not stable right now.
I use ui toolkit mainly for Editor Custom Tool creation. Nothing else. Since I can visually see how I am creating them and easily adapting them it makes it worth it.
i dont mind separating world ui from overlay ui. its definetly a tool i wuld learn and recently they announced that they will release like a complete ui toolkit
One of the things I liked with the UGUI over the newer UI Toolkit is that UGUI is not static. It constantly refreshes making updates to the UI much more fluid and easy to deal with. But, that is also a problem as it can lead to slower performance and bloat if not done correctly.
UI Toolkit is a definite NO for me. I was starting a new, heavily, UI dependant app and considered UI Toolkit but seriously struggled to get started. Working away from the scene view felt wrong and suddenly I was supposed to know web design 😕
I really enjoyed this video, I do however think your slider issue is related to your hardware or something. I loaded it up on mine and changed that slider without any issue or lag spikes. I think I faced a lot of the same issues you did with UITK Figuring out how to edit premade styles is something I still haven't worked out and the severe lack of documentation makes it really hard to google.
I wouldn't be so sure. If you look at the release notes from the many versions of Unity where they've implemented fixes to the Ui Toolkit, a lot of them look a bit silly. I personally had an issue where I was drawing a custom control for each element in a list in a c# file, and it was drawing element 0 twice... Some of these problems are THAT silly/strange.
IMHO UI Toolkit is great when it comes to develop Editor tools because you are comparing it against IMGUI which actually sucks. At runtime, UGUI is, at this time, far better and easier to understand. Unity has a lot of work to improve in UI Toolkit if they want it to become the replacement for UGUI.
Okay this is kind of funny, but technically yes you can import the stuff from Figma. Just not 100% accurate, but slowly getting there funnily and I don't think Unity meant for this to be possible. Also before stating this I would like to say I wouldn't recommend it yet. This method is messy and was done for a fun experiment. In Figma you can export almost entire set ups as SVGs. Depending on what version of Unity you are using you can actually use SVG inside of Unity. It has to be one of the more recent newer Unity's though for the UI Toolkit. When exporting the elements from Figma make sure the include ID attribute is on. Export via SVG and take the SVG into Unity. Using the data from the SVG you can actual read if it was a text file, shape, or so forth. I created a small editor script that can read if the exported piece of the SVG has a rect type in it. If it does it converts that into a visual element. Note frames and sections exported from Figma in most cases are created as a rect type in the svg export process. For text I would just type it out inside of Unity UI Toolkit Editor after designing it in Figma. Shapes would be kept as a svg object and displayed like a normal image in the UI. Same with image assets. So you can actually do it, but at the moment unless you plan to do it for a commercial set up and are okay writing a custom editor script I wouldn't yet. For the custom editor script it isn't even a custom window. Unity has API system called AssetPostprocessor that let's you hook up into the import pipeline. You can use it to create the UXML asset from an SVG exported from Figma on importing the SVG file into Unity. This can also be used to import the styles and automatically create a style sheet asset for you from Figma style data. This basically makes it where the second you import the file into Unity it just auto creates the UXML, stylesheets, and data structure. It was a fun experiment and honestly if you use Figma a lot the small time it takes to make it really would save you time in the long run, but yeah that is the process. There are others ways to import Figma into Unity that might be easier. I just did a way to auto create UXMl and style sheet assets for me while auto assigning the SVG and other image files at the same time. Hope this helps or gives someone a crazy idea.
You also forgot that UI toolkit does not update in real time. The con you mentioned for UGUI is actually a pro. The reason UGUI is performance intensive is the same reason games are more performance intensive than regular apps. UGUI refreshes in real time. This allows you to create UI objects like mobile joystick, really responsive animations, shaders on UI, real-time world space UI, charts, etc. The problem with UI toolkit is that it is solving a problem that is not a big deal in the game world. We are not app or website devs that are building static/non-interactive apps. Imagine building a flight simulator or a regular video game, How would you use UI toolkit for the HUD? How would ui toolkit help me if I need to create a game where a user interacts with an in-game computer (like deus ex).
youre showing how uitk is 82x speed while the others around 25x speed, however the video shows how you are still researching docs in between, not sure how usefull that comparasion is
UI toolkit is absolutely unusable with images. If you want anything more than rgb value solid colours/gradients then don't touch it. Correct as of today. After 2 long days of trying.