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.
This is a bug in the UI Builder. Thanks for reporting it! I was looking for a better repro steps.
Worth clarifying that UIDocuments are not equivalent to PanelRenderers. UIDocuments are more or less equivalent to VisualElements in the scene. That’s why they references a PanelSettings Asset in your project. This PanelSettings is actually the “Panel”. This was done exactly to limit the cost of having many UI Toolkit components in the scene. But that was just the main first step. We still have lots to optimize.
1 Like
Have you tried a newer version of 2020.2? Like 2020.2.0a17?
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?
1 Like
Just to clarify:
-
UI Builder package (com.unity.ui.builder) remains a discoverable Preview package in the Package Manager. In 2020.1+, you need to enable Preview packages via the Project Settings > Package Manager section. It’s no longer a setting in the Package Manager window itself.
-
UI Toolkit package (com.unity.ui) is a preview package but not a discoverable Preview package. So for now, you will need to manually edit the manifest.json file and add:
"com.unity.ui": "1.0.0-preview.3"(but afterwards, you will be able to see updates and update via the Package Manager UI.
1 Like
The UIDocument represents the bridge between UI Toolkit world of VisualElements and the world of GameObjects. The goal of UI Toolkit was indeed to separate UI from the scene and that’s where the tooling we build will focus (ie. the UI Builder).
You will have the freedom to compose UI however you’d like. You can have each menu screen a GameObject with a UIDocument and manage screen transitions they way you did with uGUI (enable/disable GameObjects). Or you can have all menu screens in a single UIDocument/GameObject and manage transitions via the display style (hide/show a VisualElement).
That said, we will tend to build tooling that favors more of the UI being composed and managed within UI Toolkit. For example, if you build the entire menu system inside a single UIDocument, you’ll be able to test the transitions between the screens directly inside UI Builder without having to go into playmode. If you split the menu system up into GameObjects, you will need to use playmode every time.
There will still be plenty of need for splitting the UI into many UIDocuments on many GameObjects. For example, floating health-bars above units or eventually world space 3D UI. And this is why we will support both workflows.
3 Likes
The sample was built for a larger resolution in-game. The default UI Builder canvas size is a bit small. Try making the Builder’s canvas larger (and zooming out).
We’ll have ways to sync the two automatically in future updates.
3 Likes
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?
One UIDocument does not mean you need to create all elements inside the VisualElement tree at the same time. You can use C# to selectively CloneTree() different screens as you switch to them (just as you would hide/show them if they were already cloned) - or just new different complex elements as needed.
The main cost is new calls for each element, so it might make sense to avoid creating some elements at first. But you have to profile your specific case. I would definitely keep things simple and create everything at once and use display to show/hide them. Only optimize when you need to.
From a purely academic standpoint, it will always be cheaper to have one UIDocument/GameObject over multiple UIDocuments/GameObjects, just by the weight of a GameObject. That is, if you had 10,000 elements, and compared putting each one into a GameObject/UIDocument vs. a single UIDocument, the single UIDocument would be much faster. This is why we moved away from using GameObjects for UI in the first place.
2 Likes
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 :
public class ReactToSliderChange: MonoBehaviour
{
private void Start()
{
Slider slider = GetComponent<UIDocument>().rootVisualElement.Q<Slider>();
slider.RegisterValueChangedCallback(CallBackMethod);
}
private void CallBackMethod(ChangeEvent<float> evt)
{
// React to value change.
}
}
8 Likes
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.
6 Likes
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?
Yes, please wait for preview-4, which should be available in a time frame measured in weeks, not months. Also, preview-4 will still be compatible with 2020.1 so you won’t be forced to upgrade to 2020.2. The goal is to support 2020.1 for all future preview releases of the package until it goes verified in 2021.1.
3 Likes
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?