Official UI Toolkit 1.0-preview available

So, instead of

"com.unity.ui.runtime": "0.0.4-preview"

hidden package, it's now

“com.unity.ui”: “1.0.0-preview.3”

?
Or those are not related? If they are, what changed besides "officializing" into a 'not-hidden' package?

 

Is it possible to use (even an old version) of UI Toolkit in 2019.4.3f1 for rendering in game? I installed UI Builder tonight and am really enjoying it but can't figure out how to do this, probably I'm just being dumb. In the Unite 2019 demo I can see a Panel Renderer component was used, but I don't seem to have that.

 

On Unity 2020.2.0a12.1591 I am getting the following errors:

Code (CSharp):

1. Library\PackageCache\com.unity.ui@1.0.0-preview.3\Core\UIElementsRuntimeUtility.cs(142,44): error CS0117: 'UIElementsRuntimeUtilityNative' does not contain a definition for 'UpdateRuntimePanelsCallback'
2.  
3. Library\PackageCache\com.unity.ui@1.0.0-preview.3\Core\UIElementsRuntimeUtility.cs(150,44): error CS0117: 'UIElementsRuntimeUtilityNative' does not contain a definition for 'UpdateRuntimePanelsCallback'
4.  

 

Thank you! I can't seem to find it in package manager (including preview packages). I'll just jump up to 2020.1 beta, worth it! By the way, loving it so far! Really intuitive (for me at least, have a fair bit of web dev experience), and just generally awesome. I'm able to build UIs faster and better than stuff I spent much longer on in the current system. Super exciting!

By the way, is there a way to outline to text? Like, outlining the text itself, each character, not the rectangular text object.

 

I hate to say it but after upgrading to Unity 2020 beta, I still can't find the UI Toolkit package in package manager. I no longer see an option for including preview packages, is this option not available (and presumably default to on) in beta builds?

 

Thank you, I've got it installed now. Very excited to dive in.

 

Hmm, could I ask for advice from experienced Unity people: I'm a couple months into seriously (but as a non-professional) learning C# and Unity. I've worked with the current UI on a practice game with my partner already.

Is this system ready enough that I should just focus on learning it instead? We're almost ready to start our next real game, a color puzzle game targeting touchscreen Windows as well as mobile devices (because we're masochists I guess).

 

For inexperienced devs making their first game, I personally always recommend going with the older systems first since your primary objective should be learning which boils down to gaining more general experience with the engine and widening your "vocabulary" of terms and ideas that you pick up as you use the existing unity systems. You'll progress much faster with UGUI thanks to the wealth of learning resources, existing open source code you can use and asset store assets made on the current UI system to help you out with animations, particle effects, performance and anything else you need to know for your game.

 

What's the ETA of adding DOTS support?

 

Will other types of elements be added to the runtime. It does not seem that the ProgressBar is available for runtime.
This type of component could be usefull for scene loading screen of even healtbar.
Also if I may ask, the tank demo first shown with the previous package showcased the tank healthbar as worldspace circular progress bar on each tanks if I'm not mistaken.

From the new demo I can already see that we could manage billboarded worldwpace ui.
Are there plan to :
1 ) include the progress bar as a runtime ui element ?
2 ) allow for different shape of progress bar (linear and circular) ?
3 ) "real" worldspace ui (like the tank demo health bar), were the UI can be rendered and masked by 3d object (wichi is not the case with the unity royale demo)

 

Does UI toolkit support rendering massive amount of health bar UIs following each unit use case with high performance?

 

I did a quick dirty (and ugly) test by cloning the Gameobject that does the rendering of my ability cooldown.
Diplicating it 100 times does seem to have an big impact on preformance as the Panel.Update function take 20+ms wehn it take 0.6 ms with only one of them.
As you can see beloow when not updating ui data (phase of casting the ability that is not represented in UI) there is no spike.

Now to be fair i think the spike are because 1 ) I duplicate the UIDocument (so I probably have 100 panel) 2 ) All update happen at the exact same frame (same underlaying ability) so in case of health bar they probably won't be updated at the same time although updating their position in world space ma impact that asesment...

 

Bug report submited under case number 1261951.
In the Unity Royal demo, if you open the HealthUI.uxml in the UI Builder and proceed to add the .health-bar--hidden to the HealthBar element, then remove that class from the element's inspector, you'll have the class .health-bar--hidden duplicated in the USS file. This happens for every style class.

 

Really excited that the preview package is finally out! As a webdev I really like the idea of UXML/USS.
Another reason I was really waiting for this is to stop my scenes from being cluttered with a lot of UI related GameObjects which also creates unneccessary performance overhead. I checked the royale demo and it seems that you are using a lof ot UI Documents nested as GameObjects there. Is this the recommended workflow? Or is there any reason not to use a singular UI Document which will include the base UI template into which we could include sub-templates via scripting based on user interactions?

 

Looks like a bug. I'm not sure why UI Builder viewport is not identical to actual UI at runtime.

 

Thank you for your reply! Definitely understand the world space UI scenario and reasoning behind multiple UI Documents there. Also glad to hear the workflow I intended to use is a valid one and in some ways beneficial.

Considering that, what is the computing/memory overhead for hidden elements? Let's say I'll build the entire main menu and its submenus into singular UI Document (and using UXML subtemplates for options menu etc.) - will there be any noticeable cost?

 

Yeah, using the display attribute approach seems the most reasonable to me as well and have the elements pre loaded so the menu works smoothly.

 

I'm sorry but I just realised I don't quite understand one of the features coming later down the line. What exactly does "data binding" mean?

For runtime UI to be suitable for me, I'd want to be able to adjust text in labels in run time as well as set and receive values from sliders and things like that. But "data binding" coming later in the year tells me that the features I described aren't there yet. So is runtime UI only good for static UIs in the current preview?

And if what I just described is possible, then what does data binding translate to in terms of use case?

 

You can do data binding today but it's 'manual' you'll have to attach a monobehavior to the game object with the UIDocument and query the tree to get the visual element you want to update or for which you want to register a change event.

 

I see so if I wanted my code to respond to a slider value changing, I'd need to poll the value every frame to see if it changed?

 

No you'd need to make a monobehavior that on start query the UIDocument tree and register to the value change event of that slider by providing a delegate method. (At least that what I would do from my experiance with the UI Toolkit in custom editors)

Something like that :

Code (CSharp):

1. public class ReactToSliderChange: MonoBehaviour
2. {
3.      private void Start()
4.     {
5.         Slider slider = GetComponent<UIDocument>().rootVisualElement.Q<Slider>();
6.         slider.RegisterValueChangedCallback(CallBackMethod);
7.     }
8.  
9.     private void CallBackMethod(ChangeEvent<float> evt)
10.     {
11.         // React to value change.
12.     }
13. }

 

I like how Unity packages are now being distributed into core Unity. This allows Unity to treat these features as first class, and thus the editor will assume these features will always be installed, and this will help improve support of essential packages in the future. It's having the best of both worlds. Unity features being distributed as open source packages, and also having first class support all integrated into the core Unity experience.

I believe this was the major flaw with ProBuilder. Because it was an optional feature, it was never fully integrated into Unity. Many Developers ended up not using ProBuilder, and support for the asset has been very slow.

Please do this for all essential Unity features moving forward. This isn't making Unity more bloated. It's adding essential features that help evolve the engine, and makes everything easy to use without requiring a constant internet connection and going through package hell.

 

This is great news, thanks for the new package! One small question regarding the new input system: Previously (using the old runtime 0.0.4 package) I was able to use a custom InputWrapper to override input (as I'm no longer using legacy Input in my project), but apparently this doesn't work properly anymore in the 1.0-preview. More specifically, the mouse position isn't queried from my wrapper apparently, and as a result, hover effects don't work (although clicks still work, but that doesn't seem to be coming from the InputWrapper?)...

Did I miss something? Or is it better to just wait for the 1.0-preview-4 (which will have actual support for the new input system, according to the original post)? Will the preview-4 be available sometime in the 2020.1 cycle?

 

Quick clarification: In the first post, in the section "What Will Ship Later", are those items (animation, data binding, shaders, etc.) coming later after the 2021.1 release, or after the preview 4 release sometime in 2020?

 

Hi!
Do you plan to add new controls to the package? Something like tables/grids, viewtrees, charts, etc? Can you share with us the controls that you are planning to add?

Thank you!

 

I just try UI Toolkit a little bit and found that it's quite different from current Unity UI. Is there any plan to bring back the smooth authoring experience nearly identical to current Unity UI? Currently I found there are 2 authoring experience I hope can return back to UI Toolkit. First is hold mouse then drag left and right to tweak value at UI Builder Inspector and second is select the item eg. Button to author its position directly by just holding the item and drag it.

 

After adding “com.unity.ui”: “1.0.0-preview.3” to my manifest.json file. It installs the package but I have no option to add UIDocument to a game object.

UI Toolkit is listed in the package manager. I already had UIBuilder installed, for making custom editor windows, custom editors and drawers.

Not sure if I did something wrong. I have no options anywhere for UI toolkit expect for the asset->create->UI Toolkit menu that lists Style Sheet, UI Document(creates uxml file) and Editor Window.

 

Sorry for all the question but it might help debug things.

Are you using Unity 2020.1.0b14 or higher ?
Can you post the full content of your dependencies in package.json ?
If you had the previous com.unity.ui.runtime package, did you make sure to remove it form your dependencies ?
Do you have any compilation error ?

 

Code (CSharp):

1. {
2.   "dependencies": {
3.     "com.unity.2d.animation": "4.2.4",
4.     "com.unity.2d.pixel-perfect": "3.0.2",
5.     "com.unity.2d.psdimporter": "3.1.4",
6.     "com.unity.2d.sprite": "1.0.0",
7.     "com.unity.2d.spriteshape": "4.1.2",
8.     "com.unity.2d.tilemap": "1.0.0",
9.     "com.unity.addressables": "1.8.4",
10.     "com.unity.collab-proxy": "1.3.8",
11.     "com.unity.ide.visualstudio": "2.0.2",
12.     "com.unity.inputsystem": "1.0.0",
13.     "com.unity.test-framework": "1.1.14",
14.     "com.unity.textmeshpro": "3.0.0",
15.     "com.unity.timeline": "1.2.14",
16.     "com.unity.ugui": "1.0.0",
17.     "com.unity.ui.builder": "1.0.0-preview.1",
18.     "com.unity.modules.ai": "1.0.0",
19.     "com.unity.modules.androidjni": "1.0.0",
20.     "com.unity.modules.animation": "1.0.0",
21.     "com.unity.modules.assetbundle": "1.0.0",
22.     "com.unity.modules.audio": "1.0.0",
23.     "com.unity.modules.cloth": "1.0.0",
24.     "com.unity.modules.director": "1.0.0",
25.     "com.unity.modules.imageconversion": "1.0.0",
26.     "com.unity.modules.imgui": "1.0.0",
27.     "com.unity.modules.jsonserialize": "1.0.0",
28.     "com.unity.modules.particlesystem": "1.0.0",
29.     "com.unity.modules.physics": "1.0.0",
30.     "com.unity.modules.physics2d": "1.0.0",
31.     "com.unity.modules.screencapture": "1.0.0",
32.     "com.unity.modules.terrain": "1.0.0",
33.     "com.unity.modules.terrainphysics": "1.0.0",
34.     "com.unity.modules.tilemap": "1.0.0",
35.     "com.unity.modules.ui": "1.0.0",
36.     "com.unity.modules.uielements": "1.0.0",
37.     "com.unity.modules.umbra": "1.0.0",
38.     "com.unity.modules.unityanalytics": "1.0.0",
39.     "com.unity.modules.unitywebrequest": "1.0.0",
40.     "com.unity.modules.unitywebrequestassetbundle": "1.0.0",
41.     "com.unity.modules.unitywebrequestaudio": "1.0.0",
42.     "com.unity.modules.unitywebrequesttexture": "1.0.0",
43.     "com.unity.modules.unitywebrequestwww": "1.0.0",
44.     "com.unity.modules.vehicles": "1.0.0",
45.     "com.unity.modules.video": "1.0.0",
46.     "com.unity.modules.vr": "1.0.0",
47.     "com.unity.modules.wind": "1.0.0",
48.     "com.unity.modules.xr": "1.0.0",
49.     "com.unity.ui": "1.0.0-preview.3"
50.   }
51. }
52.  

I had the old runtime at one point, but I removed it.
I am using 2020.1.0b15 and have no compilation error.

 

UI Toolkit is great. Cannot wait to get v1 final.

I have a couple questions:

1. Any news/ETA regarding attribute support? (I don't see mentioned in the roadmap), and

2. What's the recommended approach to handle special fonts for localization?