UI Roadmap

Hi everyone,

We’re finally ready to share our roadmap about UI. It is centred around UIElements and gives an overview of our vision for UI, what has been already shipped and what you can expect for next year.

Please keep in mind that the content for each milestone is not set in stone and is subject to change. Your feedback at this stage is very important, and might actually steer the roadmap, so please let us know what you think.

Cheers,

Edit: Roadmap update for 2020

4903466–531186–UI Roadmap.pdf (385 KB)

16 Likes

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. :wink:

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?

Yes that’s the objective.

1 Like

Oops, that slide was meant to be removed, exactly for the reasons you stated. Let me fix that.

For the moment, we allow only the binding of the main value property of a Control, like the text property of the Label type for example.

Data Binding would allow you to bind more properties. We’re considering expanding the system to USS properties.

3 Likes

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:

   <Style TargetType="{x:Type Label}">
            <Setter Property="SnapsToDevicePixels" Value="True"/>
            <Setter Property="FontSize" Value="14"/>
            <Setter Property="Template">
                <Setter.Value>
                    <ControlTemplate TargetType="Label">
                        <Border>
                            <ContentPresenter HorizontalAlignment="Center"                                             
                                              VerticalAlignment="Center"
                                              TextBlock.FontFamily="/Views/Fonts/calibri.ttf#Calibri"
                                              TextBlock.FontSize="{TemplateBinding FontSize}"
                                              />
                        </Border>
                    </ControlTemplate>
                </Setter.Value>
            </Setter>
        </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.

If I get what you mean, USS style sheets should behave in a similar fashion, with styles being applied based on the precedence rules of selectors.

1 Like

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.

2 Likes

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

3 Likes

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?

That’s the goal!

Custom meshes are already supported via the Mesh APIs. See:
https://docs.unity3d.com/2019.3/Documentation/ScriptReference/UIElements.VisualElement-generateVisualContent.html

Custom shaders will also be possible in the future.

1 Like

These are just updates to UIElements, not necessarily individual packages. Either way, the final state will be fairly plug-and-play, even if it’s split between multiple packages. Unity will manage these packages for you via default packages, including updates.

To be more specific:
UIElements for Editor Extensions is not a package. This is all in core Unity already.
UIElements for Runtime is and will likely stay a separate package but may become default when it comes out of preview
Simple Runtime UI and Rich Content UI are just capability goals (that span over all UIElements), not packages.

3 Likes

Should be when 2019.3 ships, so around early November.

The team is working on something regarding antialiasing for Screen Space UI. Will update the roadmap once we have an ETA.

2 Likes

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.

Please start a separate thread. This thread is just about general roadmap questions.

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?