Search Unity

UIElements roadmap update

Discussion in 'UI Toolkit' started by benoitd_unity, Nov 27, 2019.

  1. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    153
    Hi everyone, here’s an important update regarding the UIElements roadmap.

    We were very excited at the idea of sharing our early progress with UIElements for runtime with you all, working very hard at releasing a preview package around the 2019.3 timeframe, but we decided to delay it until 2020.1 instead. Let me walk you through the thinking that lead to this decision.

    First, a bit of context. When the development for UIElements began, with the goal of providing a single UI framework for both extending the editor and building runtime UI, the Unity features landscape was somewhat different: Packages and DOTS where not a thing and features had to be shipped with the Unity engine. This comes with a few but considerable restrictions:
    • Iteration - Updates are released either via official builds, which happens roughly every 3 months, or by dropping custom builds, which is time consuming for us to produce, and tedious for users to deploy.

    • DOTS - It’s currently impossible for us to provide a version of UIElements that will be compatible with the DOTS runtime, or to leverage DOTS capabilities in order to increase performance.

    • Packages - Unity features are either moving, or being created, into packages, contributing to a constantly growing ecosystem, which UIElements can’t be part of. Some features, such as Addressable Asset Bundles, are particularly appealing but out of reach.
    Yikes.

    Moving UIElements itself into a Package is inevitable, and we’re confident it should be done sooner rather than later, for a few reasons:
    • Stability - This change will most likely impact anyone using UIElements. Doing this while in Preview will preemptively avoid a lot of disruption.

    • Quality - UIElements for runtime is still in an early stage of development and it is critical that we iterate tightly with the community in order to ship a product that you really want to use.

    • Visibility - Distributing into a package also means we’ll be able to share a more granular roadmap and publish updates at a higher frequency.
    Meanwhile, we've decided to release the Runtime implementation seen in the Unite Copenhagen 2019 demo as part of the demo project itself.

    The demo project repo, along with the Runtime implementation, can now be found here, and requires Unity 2019.3:

    https://github.com/Unity-Technologies/UIElementsUniteCPH2019RuntimeDemo

    This is a temporary and unsupported early preview of UIElements Runtime support. It is meant as an evaluation tool that you can use until we ship the official implementation. It is only meant as an evaluation tool. Any APIs in the project might change. That said, the general workflow should not change much going forward.

    We welcome any feedback you have and will use it to inform the official package implementation as we work on it.

    To see how you can use UIElements at runtime, here's the Unite talk recording:


    We know some of you will be initially disappointed by this change but we strongly believe it’s the best thing to do, which will ultimately result in a higher quality UI framework.

    Cheers,
     
    EirikWahl, Seb-1814, Mauri and 11 others like this.
  2. one_one

    one_one

    Joined:
    May 20, 2013
    Posts:
    522
    Awesome! Was a bit sad at first about the delay but seeing a runtime version was released along with the demo project definitely made up for it. And I'm glad UI elements will be moved into a package with more frequent updates. Looking forward to where the runtime system is going in the next few months - keeping my fingers crossed for news on data binding!
     
    benoitd_unity and OndrejP like this.
  3. Creepgin

    Creepgin

    Joined:
    Dec 14, 2010
    Posts:
    362
    Totally understand the decision. The demo you guys gave at Unite looked solid. So I know it should be on the right track and is certainly what people want. One thing I want to ask though: how do you envision the DOTS compatibility is gonna work out? What are you looking to leverage from DOTS?
     
  4. OndrejP

    OndrejP

    Joined:
    Jul 19, 2017
    Posts:
    78
    Great news with the package! Will it depend on Unity 2020.1 or will it run on 2019.3 as well when it's released?
     
  5. StephanieRowlinson

    StephanieRowlinson

    Joined:
    Jul 23, 2014
    Posts:
    116
    Welp, there goes my planning for next week.

    The interaction between package versions and editor versions is still a bit unclear to me, but if I understand correctly:
    - The first version of the package will be built against 2020.1 and released when that comes out of beta.
    - Because it's a package, it'll then be able to get updates between Editor versions.
    - With the eventual verified one being verified against a specific versions of the Editor again.

    Is that correct?
     
  6. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    153
    Compatibility is something we're still discussing but the high level objectives is to use UIElements for making UI in all DOTS related scenarios: A project using current Unity but with ECS to optimize certain systems (generally referred to as Hybrid), a project targeting the DOTS runtime only, a project targeting the Tiny subset. In all those cases, UIElements should work well with features like Live Link and DOTS Conversion workflows.

    As for leveraging DOTS, we're mostly looking at Burst and Jobs, to optimize certain updaters that are frequently running on the entire tree.
     
    Creepgin and one_one like this.
  7. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    153
    It will depend on 2020.1
     
  8. LPhilipp

    LPhilipp

    Joined:
    Apr 27, 2018
    Posts:
    15
    Nice! The example contains everything in package layout. So one could easily build an npm package or just import from disk... Just did, and now started prototyping with UI Elements and Runtime :D:cool:
     
  9. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    153
    Yes that's nicely summarized. A package is verified against a version of the Editor, but we can then branch a new preview version. For example we could release a verified version of UIElements 1.0 against Unity 2020.2, and then branch 1.1 in Preview to continue development in the open.

    Sorry about your planning :(
     
    Last edited: Nov 28, 2019
  10. StephanieRowlinson

    StephanieRowlinson

    Joined:
    Jul 23, 2014
    Posts:
    116
    Nice, I did get it then. Considering the roadmap for UIElements rolling out the new features as part of preview packages makes much sense and should make the process easier all round. So I'm happy to see a package for UIElements. :)

    I'll just have to change it to evaluating the demo project and doing preliminary design work based on that. It was just a bit of an emotional rollercoaster this morning: Yay release candidate 1 for 2019.3! :D Noooo, UIElements is delayed. :eek:
     
    uDamian and benoitd_unity like this.
  11. jGate99

    jGate99

    Joined:
    Oct 22, 2013
    Posts:
    989
    Does it mean you guys started considering using UI Elements in Tiny too?
     
  12. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    153
    Yes. Tiny needs a solid UI solution and we'd like to avoid making yet another UI framework :)
     
    jGate99 likes this.
  13. jGate99

    jGate99

    Joined:
    Oct 22, 2013
    Posts:
    989
    that'd be awesome :)
     
  14. LyndaChan

    LyndaChan

    Joined:
    Jul 27, 2018
    Posts:
    2
    I'm disappointed. It made things much worse for me. I think you shouldn't do this.
     
  15. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    587
    Sorry to hear that. Can you elaborate on how this makes things worse for you?
     
  16. LyndaChan

    LyndaChan

    Joined:
    Jul 27, 2018
    Posts:
    2
    I don't find your comment funny. My work and my roadmap depends on your work and your roadmap. And I do take my work seriously. just wanna say you souldn't announce this delay at the last moment.
     
  17. Creepgin

    Creepgin

    Joined:
    Dec 14, 2010
    Posts:
    362
    If your roadmap depends on what they showed at Unite, then good news! Everything they showed during the talk is available on github: https://github.com/Unity-Technologies/UIElementsUniteCPH2019RuntimeDemo

    If your roadmap depends on the less concrete details and rough timeline items mentioned during the talk, then I'm afraid you're gonna need to wait a bit longer.

    Now, this post is intended to be funny, uDamian's was not.

    But in all seriousness, last minute delay happens. We vent our frustration when it's happening in an unreasonable manner. But in this case, they a) released the runtime code (also in a nice package-friendly setup), and b) gave reasonable points for their decision (desire to go the package route, etc).
     
    arcbox likes this.
  18. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    587
    I didn't mean to be funny. I'd just like to know how this impacts you so we can see how we can help.

    This change was inevitable. If we waited longer it would have impacted people even more than it does now. We have a lot of internal users that will also be impacted by this, including the UI Builder itself. But we think it's worth it for the long term.
     
    satchell, Vharz and florianhanke like this.
  19. jGate99

    jGate99

    Joined:
    Oct 22, 2013
    Posts:
    989
    True, its better to wait for the right tech in stable form than using something which agains get replaced.
     
  20. oltranzista

    oltranzista

    Joined:
    Jul 21, 2015
    Posts:
    2
    Since Unity has been buzzing about DOTS for a long time now it makes sense that Unity would want UIElements to be DOTS compatible. Saying it's currently impossible to provide a version of UIElements compatible with DOTS is a little unsettling. How much investigation has been made to see how feasible it is to support DOTS by 2020.1?
     
  21. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    153
    A lot of investigation has been made to figure out how to best leverage DOTS but I don't think we'll make it for 2020.1.

    To be clear though, if you're currently using DOTS in conjunction with MonoBehaviours, AKA hybrid, UIElements will work fine in the Object Oriented side of things. What it won't do is participate to the ECS conversion and work with Live Link.

    Where it hurts the most though is if you're making a full DOTS game, targeting the DOTS or Tiny runtimes, then you're completely out of luck.

    So when we refer to UIElements to be DOTS compatible, we refer to all those scenarios.

    Cheers,
     
    oltranzista and jGate99 like this.
  22. Digika

    Digika

    Joined:
    Jan 7, 2018
    Posts:
    17
    Wait what, minimum version now 2020.1?
     
  23. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    153
    That's correct.
     
  24. Jawsarn

    Jawsarn

    Joined:
    Jan 12, 2017
    Posts:
    121
    Hi! A bit sad as I thought it was already meant to be a package from start, but nice that the demo was released with runtime part! I'm wondering if I can already now create my UI in the builder and it will be supported in the future package version, as in the layout etc? Or do you think this will break/not be upgradable as you continue forward? I don't mind setting up the logic behind it again, but don't want to redo the layout.
     
  25. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    556
    Is that possible to make it happens at 2020.2 or 2020.3 cycle?
     
  26. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    587
    This is not a rewrite, just a migration. The biggest change might be a namespace change. So anything you build with the UI Builder now, or just in UXML, that should all continue working in the package UIElements after some minor tweaks.

    We also plan on releasing migration tools to make the transition as automatic and easy as possible.
     
    Lahcene and Jawsarn like this.
  27. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    587
    Can't say for certain when DOTS support will come. It's just one of topics we will focus on during 2020.
     
    optimise likes this.
  28. strich

    strich

    Joined:
    Aug 14, 2012
    Posts:
    288
    Will this affect the roadmap published in August in the Roadmap thread? Previously it appeared that feature parity with UGUI was going to be achieved around 2020.3. Is this still true, or has that been pushed back one release as well?
     
    JakHussain and jGate99 like this.
  29. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    153
    I'll publish an update soon but it's fair to assume that UGUI parity should be around the same time frame, at least in Preview.
     
  30. strich

    strich

    Joined:
    Aug 14, 2012
    Posts:
    288
    No worries. I think we'll have to stick to uGUI for our next title in 2021 then. It's a pity but it is what it is. ;)
     
    Last edited: Dec 16, 2019
    unity_IpxdANggCs1roQ and Peter77 like this.
  31. kvfreedom

    kvfreedom

    Joined:
    Mar 30, 2015
    Posts:
    27
    It is difficult to replace UGUI before UIElements support adding GameObject to the panel. Game UI contains VFX and models are common requirements.
     
    Sabso, Kender and benoitd_unity like this.
  32. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    153
    Couldn't agree more :)
     
    Ofx360 likes this.
  33. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    153
    The roadmap has been updated to reflect what has been discussed in this thread.

    Cheers,
     
    EirikWahl likes this.
  34. efeb

    efeb

    Joined:
    Jul 9, 2018
    Posts:
    3
    does the 2020.1a currently have runtime support?
     
    Phlegma likes this.
  35. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    153
    No the package is not released yet.
     
  36. TJHeuvel-net

    TJHeuvel-net

    Joined:
    Jul 31, 2012
    Posts:
    454
    Just because i cannot wait to use it i'm starting to add some hacks to get it to work on Android. Add this script in the UIRuntime/Runtime folder, and attach it to the panelrenderer to get the ScrollView to work with touch input!

    Code (csharp):
    1.  
    2. using Unity.UIElements.Runtime;
    3. using UnityEngine.UIElements;
    4. using UnityEngine;
    5. using System.Collections.Generic;
    6. using System.Collections;
    7. using System.Linq;
    8.  
    9. public class MobileHacks : MonoBehaviour
    10. {
    11.     [SerializeField] private PanelRenderer panelRenderer;
    12.  
    13.     private Vector2 uiToScreen(Vector2 uiPos) => new Vector2(uiPos.x, Screen.height - uiPos.y);
    14.     private Vector2 uiToPanel(Vector2 uiPos) => panelRenderer.ScreenToPanel(uiToScreen(uiPos), out var panelpos) ? panelpos : Vector2.zero;
    15.  
    16.     Vector2 mousePosDown;
    17.     List<ScrollView> scrollViews;
    18.     List<float> initialValues;
    19.     void Update()
    20.     {
    21. #if UNITY_ANDROID && !UNITY_EDITOR
    22.         for (int i = 0; i < Input.touchCount; i++)
    23.         {
    24.             var touch = Input.GetTouch(i);
    25.  
    26.             switch (touch.phase)
    27.             {
    28.                 case TouchPhase.Began:
    29.                     mousePosDown = uiToPanel(touch.position);
    30.  
    31.                     scrollViews = panelRenderer.visualTree.Query<ScrollView>().Where(s => s.worldBound.Contains(mousePosDown) && !s.verticalScroller.worldBound.Contains(mousePosDown)).Build().ToList();
    32.                     initialValues = scrollViews.Select(s => s.verticalScroller.value).ToList();
    33.  
    34.                     break;
    35.                 case TouchPhase.Moved:
    36.  
    37.                     Vector2 mousePos = uiToPanel(touch.position);
    38.  
    39.                     for (int j = 0; j < scrollViews.Count; j++)
    40.                         scrollViews[j].verticalScroller.value = initialValues[j] - (mousePos.y - mousePosDown.y);
    41.                     break;
    42.             }
    43.  
    44.         }
    45. #else
    46.  
    47.         if (Input.GetMouseButtonDown(0))
    48.         {
    49.             mousePosDown = uiToPanel(Input.mousePosition);
    50.  
    51.             //over but not on the scroller
    52.             scrollViews = panelRenderer.visualTree.Query<ScrollView>().Where(s => s.worldBound.Contains(mousePosDown) && !s.verticalScroller.worldBound.Contains(mousePosDown)).Build().ToList();
    53.             initialValues = scrollViews.Select(s => s.verticalScroller.value).ToList();
    54.  
    55.         }
    56.         else if (Input.GetMouseButton(0))
    57.         {
    58.             Vector2 mousePos = uiToPanel(Input.mousePosition);
    59.  
    60.             for (int i = 0; i < scrollViews.Count; i++)
    61.                 scrollViews[i].verticalScroller.value = initialValues[i] - (mousePos.y - mousePosDown.y);
    62.         }
    63. #endif
    64.     }
    65. }
    66.  
    67.  
    Currently if you set the rendering mode to Gamma the UI is rendered twice, so you have to keep it to Linear. This means you have to select OpenGLES3 as Graphics API.
     
    Last edited: Dec 21, 2019
    ZeFirestarter likes this.
  37. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    4,628
    JakHussain likes this.
  38. mansiva2000

    mansiva2000

    Joined:
    Jul 2, 2013
    Posts:
    9
    Yo! I've been playing with UIElements for the past couple of weeks and very happy so far with the approach and workflow in general.

    I've managed to build a section of our web platform using UIElements and it works pretty well in an Editor window so it's something we'll definitely include as part of our Unity SDK in the future. It's actually much faster to build and iterate compared to typical frontend/javascript development.

    So now I'm curious about the possibility of actually replacing our frontend and what it would take. Ideally a Tiny build with UIElements sounds like the best option but since that's going to take a while before it's available would a WebGL build using UIRuntime work?

    I don't think making a web authoring tool was part of the objectives you had when creating UIElements, but since it's definitely inspired from web UI authoring it would definitely be a nice fit.

    Happy Holidays!
     
  39. TJHeuvel-net

    TJHeuvel-net

    Joined:
    Jul 31, 2012
    Posts:
    454
    One more hack. In the talk Damian says its probably not possibe to render something on top of UI, but with an ugly hack it currently is. I tried a few different things, like unregistering the panel but that would also make it not respond to events.I also tried setting a custom render texture and blitting this to the screen, but alpha blending seems to be bugged with rendertextures at the moment. I ended up with this:

    Code (csharp):
    1.  
    2. using Unity.UIElements.Runtime;
    3. using UnityEngine;
    4.  
    5. class RenderBeforeCamera : MonoBehaviour
    6. {
    7.     [SerializeField] private PanelRenderer panelRenderer;
    8.  
    9.     private Event repaintEvent => new Event() { type = EventType.Repaint };
    10.     private RenderTexture rt;
    11.     void Start()
    12.     {
    13.         rt = new RenderTexture(2, 2, 2);
    14.     }
    15.  
    16.     void OnPreCull()
    17.     {
    18.         InternalBridge.SetTargetTexture(panelRenderer.panel, null);
    19.         InternalBridge.RepaintPanel(panelRenderer.panel, repaintEvent);
    20.         InternalBridge.SetTargetTexture(panelRenderer.panel, rt); //with rendertexture assigned they dont draw, yay!
    21.     }
    22. }
    23.  
    I observed that you need to manually call Repaint when a rendertexture is assigned, so by assigning one we can effectively stop drawing. The rendertexture we assign is never used, the UI is really only rendered once.



    Drag this script on a camera and the UI will be rendered just before it. My setup has two camera's, one only set to clear and then the maincamera with this script that only clears depth.

    Now i just have to figure out how to draw multiline text, since the new texthandler doesnt seems to handle that properly.
     
    Last edited: Dec 26, 2019
    ZeFirestarter likes this.
  40. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    153
    Peter77 likes this.
  41. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    153
    UIElements will work in the WebGL target of the Unity runtime. I don't believe it's the best tool for making a web frontend but it should definitely work.

    Thanks, I hope you had a great holiday season!
     
  42. efeb

    efeb

    Joined:
    Jul 9, 2018
    Posts:
    3
    I'd love to hear some of the reasons behind not going with Unity for web frontend work with UIElements, might give some insight on the differences.
     
  43. polerin

    polerin

    Joined:
    Apr 11, 2013
    Posts:
    7
    Played with it tonight, got it working ..ish? Do you have a dedicated runtime feedback thread?

    Regardless... oh my god it's so much nicer.
     
  44. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    153
    Glad to hear! And yes we know that what we shared is very rough, but we felt it would be great to let you try it so you get an idea of the direction we've taken.

    We don't have a runtime dedicated section, feel free to share your thoughts in the UIElements forum section.

    Cheers,
     
    TJHeuvel-net likes this.
  45. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    980
    Maybe I didn't catch it in the talks or I just don't remember that part well, but does this new UI Builder / UI Elements support the new CSS "grid" setup? -- I really think it should. This part of CSS should have been there from the start, and would make Unity layouts MUCH easier in most cases -- especially where screen resizing might be concerned (for automatic adjustment for various platforms and devices).
     
    benoitd_unity likes this.
  46. zoltanbigitec

    zoltanbigitec

    Joined:
    Jan 3, 2020
    Posts:
    5
    https://docs.unity3d.com/Manual/UIE-LayoutEngine.html
     
  47. StephanieRowlinson

    StephanieRowlinson

    Joined:
    Jul 23, 2014
    Posts:
    116
    I've been playing around with the flex layout system and I really do like it how it handles resizing, but sometimes I just want to layout things in a grid and it's a fight to do that with flexbox. So I really want the grid to supplement the flexbox layouting.
     
    benoitd_unity likes this.
  48. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    587
    To confirm, no, USS does not support grid layout currently.

    We know how useful grid support would be and it's just a matter of prioritization among other important features. Something the might come sooner is grid layout support in the UI Builder (via UX, but still using flexbox underneath).
     
  49. PassivePicasso

    PassivePicasso

    Joined:
    Sep 17, 2012
    Posts:
    67
    @uDamian I've been using the UI Builder a lot as well as custom controls, and one thing I noticed is that I can't reliably get custom fields on my custom contorls to show up in the UI Builder.
    What are the requirements for making new fields show up there?
     
  50. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    587
    Ya, this are is a bit lacking at the moment. Our custom Attribute system has not fully accounted for the UI Builder (several years in the future) so the Builder has to jump through some hacks to emulate their "editability". Normally, attributes are assumed to be only set at construction time and never set again, but the Builder obviously needs to change values on those attributes post-construction of the element.

    To do this, the Builder relies on some assumptions that are valid for "the majority" of our own custom controls:
    1. Type of attribute is one of the existing
    Uxml*AttributeDescription
    types, and is not a custom unknown T as a
    TypedUxmlAttributeDescription<T>

    2. In order for the Builder to read the value of this attribute after element construction, it assumes there is a C# property by the same name. So if your custom attribute is called
    my-custom-attribute
    , the Builder expects your custom element to have a C# property called
    MyCustomAttribute
    (case insensitive)

    We're still working on proper attribute declaration system which is why the Builder hacks its way in at the moment. This is not meant as a permanent solution users should use.
     
unityunity