UI Roadmap

Thank you for sharing the roadmap.
Is UIElements will get parity with uGUI by Unity 2020.3 too?

 

I love how detailed this roadmap is! Great job, please do this for all features in future.

Some questions/remarks:

- I see the DOTS features are slated for 2020.2, but the full feature set for 2020.3. As UI developer I'd prefer to get the full set of features first and then the DOTS versions of things I already have.

- What's the difference between value and data binding?

 

Data Binding's where it's at then!

With regards to expanding it to USS properties. I haven't had time to dig into the new framework yet (was kind of waiting on the runtime version to do that), but one type of binding from styles to controls that I really like WPF and would love to have an equivalent of is the TemplateBinding. This binding used in styles basically means "this property can be overridden by each control that uses the style as needed". If you don't specify anything in the control itself the value set in the style will instead be used. So for example:

Code (CSharp):

1.    <Style TargetType="{x:Type Label}">
2.             <Setter Property="SnapsToDevicePixels" Value="True"/>
3.             <Setter Property="FontSize" Value="14"/>
4.             <Setter Property="Template">
5.                 <Setter.Value>
6.                     <ControlTemplate TargetType="Label">
7.                         <Border>
8.                             <ContentPresenter HorizontalAlignment="Center"                                            
9.                                               VerticalAlignment="Center"
10.                                               TextBlock.FontFamily="/Views/Fonts/calibri.ttf#Calibri"
11.                                               TextBlock.FontSize="{TemplateBinding FontSize}"
12.                                               />
13.                         </Border>
14.                     </ControlTemplate>
15.                 </Setter.Value>
16.             </Setter>
17.         </Style>

Which in this case means each label default has the size 14, but you can overwrite it if needed. This greatly reduces the amount of almost identical styles you need to write for common and small deviations.

Just binding to stuff in the ViewModel/Model/you know the code bit from the USS, would also be super welcome.

 

Thank you for the roadmap!

Would be lovely to have some form of SVG antialiasing in screen space overlay for Unity UI or in runtime UIElements. Since SVGs only get antialiasing in forward pipelines or in Screen Space Camera, we currently don't get SVG antialiasing in:

1. Screen Space Overlay UIs.
2. Any deferred pipelines, for example built-in or HDRP deferred. Any post-process AA blurs fonts.

We can get crisp, truly resolution independent UIs in Unity (UIElements and Unity UI) if this could get addressed.

 

Where will it be announced when the Runtime UI Preview Package becomes available?

 

I'm bit confusing that there are so many packages.

UIElements for Editor Extensions
UIElements for Runtime
Simple Runtime UI
Rich Content UI

Does these packages means same updates of UIElements? or separated packages?

 

So does this mean UIElement will completely replace uGUI? If that is the case, will it be possible to extend the low-level rendering system of UIElement - like building custom mesh and using custom shader?

 

Hello! Can you say me how can I draw a table using UIElements?
I saw a TreeView in UXML ref, but I can't find any helpful examples of its usage.

 

Great! Many thanks to the UI team for working on this.

 

I love the direction you are heading.

Please also add the option to pass more UV channels to UIElements.Vertex. Otherwise what can be done with custom shader would be severely limited.

Also, can we expect UI shaders to work in any render pipeline, as it currently is?

 

And hopefully shaders created with Shader Graph, please say yes?

 

I'm sorry, I forgot that this is the UI Roadmap

 

Hi. I have feature request and question.
1) I hope UIElements for Runtime using in game UI can generate UI sprite atlas dynamically at runtime and make the UI always strike to become 1 draw call based on what is loaded inside the UI. I have the use case that I need to load a few of different UI icons based on condition meaning that I not able to generate static sprite atlas as I have a lot of UI icons that not able to combine with other UI to make it as 1 draw call.

2) I see DOTS UI - 2020.1 has been removed. Does it means I cannot get DOTS UI preview package at 2020.1 cycle anymore? I still hope I can get DOTS UI Runtime support as soon as possible as I want to start using DOTS soon. Currrently DOTS UI is one of the big blocker in DOTS development workflow.

 

Quick question about the runtime preview: Will this already be included in the beta version for 2019.3 at some point?

 

Is the ListView recycling ListItems? If not, is that on the roadmap? Also I would love to know more about StackPanel and Grid like elements

 

This is such great news. My company have a Web development team and they generate their ccs styling needed for a website from their story boards. What I want to know is what the breakdown in differences between uss and css are so that were can write a converter and reuse the same css from their Web dev in our unity apps for consistent company wide styling.

Will this be possible and would unity be providing a converter or would we need to write our own?

 

Awesome. My another concern is does it currently allows UI designer to design UI in whatever ways like using a lot of masking but UIElements for game UI still able to convert optimal performance UI at runtime? The idea is like DOTS that modify game objects at authoring and converting to entities at runtime to achieve optimal performance.

I assume UIElements for game UI will still using Monobehavior to get UIElements Components like Button to add listener to fire event when button on click to and Text to output game state such as health then I still need to fix some hacks and workarounds to bridge it nicely between Monobehavior land and DOTS lands which quite painful. Also I still didn't see any new improvement for DOTS Reactive System anymore that I think it's essential feature for DOTS UIElements for game UI. Currently seems like there's no nice API to detect reactive data changes of the components. It's using system state component but the core idea is still add/remove component to implement the reactive logic and seems like there's no way to keep detecting data changes of the specific component in reactive way as you only can do add/remove component. There is long discussion about this topic. You can just jump to post #40 https://forum.unity.com/threads/reactive-system.522776/#post-4776161. At the end, I think the use cases are how to bind UI to any event and self event. Any event means if any of the entities that has specific component change data it will update the data such as any of entities that has score component changed its data it will update UI. Self event means only one entity with specific component change its data will update UI like health of player. Other entity with the same specific component change its data will never update UI.

 

Are you planning a sort of MVVM approach for binding? And would it be possible to make binding attribute based, similar to the SerializeField attribute?

 

Hmm, I'm very curious how you plan on integrating particles/meshes into the hierarchy if the entire visual hierarchy is 1 entity. I know this hasn't been completed yet, but I saw that it was on the roadmap for 2020.3 which isn't too far away.

 

That would be amazing! Looking forward to updates on that topic - from my experience, the data pipeline can become quite the hassle if it requires a lot of boilerplate/manual wiring.

 

I'm running 2019.3.0b5 and don't see anything relating to a runtime in-game version of UIElements in package manager.
Did you mean when the final version of 2019.3 releases? Thanks.

 

Hi @uDamian,
Is Project Tiny (upcoming update) will also be using UI Elements for UI?

 

@uDamian Then which class/namespace would be compatible for making UI in Tiny3D ?

Would it be reuse the current UI in Tiny2D ?

 

Do you know if z-index is going to be supported?

 

Are there any plans to allow getting screen space coordinates of controls in a panel?
Or alternatively rebuilding the PopupWindow UIElement so it actually provides a popup rather than just a styled element?

 

Any plans to add Grid? It is pretty common misconception that flex can do everything, a lot of stuff in Grid is more robust and intuitive. I understand you wanted to make it easier for html/mobile exporting in future but Grid existed since 2007 in some form and nowadays mobile browsers support it too. There is 0 reason to limit css subset to flex in 2019.

 

Hi,

Any updates on when the UI Renderer for Runtime will be available? I don't care if it's even just an alpha version, I'm testing whether a particular project can be done in Unity at all based on this. I'm years away from production code, and to me, it doesn't matter how buggy the Panel Renderer preview is, as long as I can install it and validate the basic concept.

I've installed 2019.3.0b10 and 2020.1.0a11, and I'm not seeing anything. What is the name of the package I should be looking for?

Since you had this working in the Copenhagen YouTube video from long ago, is there any particular reason you're holding this back for so long, even just a pre-alpha? This seems perfectly suitable for testing, and I'm kind of stuck without being able to answer the question about whether it solves my problem.

 

I'm looking at the roadmap again and runtime Databinding is slated for release in 2020.3 in the verified package. Will it get a preview before that or just drop fully formed in the 2020.3 package?

 

Around when 2019.3 exits beta and releases.