Search Unity

UIElements は Unity の新しいリテインドモードの UI フレームワークで、現在は Unity 2019.1 のパブリック API として提供されています。現在の形は、Unity エディターの拡張を容易にするツールです。今後のリリースで、ゲーム内サポートやビジュアルオーサリングが追加される予定です。

これまで、Unity でカスタムエディターウィンドウやインスペクターを作成するには、イミディエイトモード API である IMGUI を使用する必要がありました。IMGUI を使用すると、ユーザーインターフェースの作成を簡単に開始できますが、複雑なアプリケーションを作成するときにスケールすることができません。また、ユーザーが現在のフレーム内の任意のタイミングで UI の構造を大幅に変更できるため、システムによるレンダリングの最適化が困難です。さらに、すべての UI が C# で宣言されるため、将来出てくる、視覚的に UI をオーサリングするツールでも C# コードを生成する必要があり、これはやっかいな問題となっています。

リテインドモードの API である UIElements では、開発者がオブジェクトの UI ヒエラルキーを作成すると、システムによってそれがレンダリングされます。このようにして、システムによって描画の内容とタイミングが最適化され、全体的なパフォーマンスが向上します。このパラダイムではほかにも、ヒエラルキーとスタイリングが機能から切り離されます。これにより、より適切に関心の分離が行われ、アーティストとプログラマーの両方がより気楽に UI のオーサリングをできるようになります。

リテインドモード

UIElements の基本的なビルディングブロックは VisualElement クラスです。すべての要素は、VisualElement クラスであるか、それを継承したクラスです。個別の VisualElement は、互いの親子関係を設定して、UI ヒエラルキーを形成できます。レイアウトやスタイリングなどのシステムがこのヒエラルキーを走査して、UI を適切に画面にレンダリングします。

エディターには、それぞれの EditorWindow に、ヒエラルキー内最上位の VisualElement を表す rootVisualElement プロパティーがあります。システムに要素のことを知らせ、描画させるには、このルートの子として要素を追加する必要があります。

その要素がヒエラルキーに存在する限り、開発者からの入力がなくても、要素が継続して、描画、更新、ユーザーイベントの消費を行います。これが、リテインドモードとイミディエイトモードの最も大きな違いです。開発者の側で必要な作業は、処理の内容とタイミングの宣言だけで、フレームごとにレンダリングを管理する必要はありません。

要素の描画を停止するには、このスライダーのように、スタイリングの変更で一時的に非表示にするか、ヒエラルキーから完全に削除します。

リテインドモードでは、(UXML を使用して)ヒエラルキーとスタイリング(USS)の宣言を個別のアセットに分離できるドキュメントモデルも利用できます。C# では、組み込みのクエリシステムとイベントシステムを使用して、自分が宣言した UI と機能やデータのバインドだけに注力できます。

ヒエラルキーとスタイリングのアセットを分離すると、視覚的な UI のオーサリングが可能になります。これにより、すべてのユーザーが簡単に Unity で UI を微調整したり、オーサリングしたり、デザインしたりできるようになります。

再利用可能なテンプレート(UXML)

C# では要素のヒエラルキー全体を組み立てることができます。しかし、スタイルと同様に、ヒエラルキーの大半は UI の使用期間中に大きく変化することがありません。したがって、UXML と呼ばれる個別の XML ベースのアセットにヒエラルキーを定義して、UI をモジュール化することをお勧めします。

タグ名は C# の型に対応しており、VisualElement から継承したユーザー定義型も完全にサポートされています。属性は作成時に新しい要素に設定されます。ネストされたタグは親タグの子になります。

この .uxml アセットは他の Unity アセットと同じようにロードでき、そのプロセスで VisualTreeAsset オブジェクトを構築できます。その後、この VisualTreeAsset を任意の要素の下で、必要なだけインスタンス化(または複製)できます。

UXML で作成したばかりの要素の取得は、この後すぐ説明するクエリシステムで行います。

共有スタイル(USS)

スタイルは、C# でプロパティーを通じて VisualElement に直接設定できます。しかし、ほとんどのスタイルは静的に定義されるので、C# でスタイルの記述を UI ロジックと分離するのが賢明です。UIElements では、USS と呼ばれる Unity 固有のスタイルシートアセットを使用します。USS では、CSS 標準のサブセットを使用しています。CSS でお馴染みのセレクターと同じものを使用してどの要素をどのスタイルにするのかを特定することができますが、スタイル自体はキーと値のペアです。

この .uss アセットは他の Unity アセットと同じようにロードでき、そのプロセスで StyleSheet オブジェクトを構築できます。その後、これを目的の要素に割り当てると、その要素とその要素の子にスタイルが自動的に適用されます。後から子を追加した場合も同様にスタイルが適用されます。

スタイルは名前属性や C# 型を使用して適用できますが、スタイルの再利用性を高めるために、要素に 1 つ(以上)のスタイルクラスを割り当てて、そのクラスを USS 内のスタイルと一致させることもできます。それらはタグと考えることができます。

同じ要素に複数のスタイルシートを追加したり、同じ要素に合致する複数のルールを設定したりすることもできます。USS を使用して複雑なオーバーライドルールを設定し、スタイルをできる限り再利用するようにします。共有スタイル(汎用ボタンの色など)を繰り返し利用すると作業が簡単になります。C# の再コンパイルを待つ必要がなくなるのが大きな理由です。スタイルシート(USS)アセットに対する変更は、ファイル保存時にエディターに自動的に適用されます。

UQuery

UIElements のクエリシステムは UQuery と呼ばれます。これは、名前属性、現在割り当てられているスタイルクラスリスト、および C# の型の組み合わせを使用してヒエラルキー内の要素を検索するという点で、ウェブの jQuery に似ています。

動的なヒエラルキーに対してクエリを複数回実行する必要がある場合に再利用しやすいように最適化した、Query オブジェクトを作成することもできます。

イベント

UIElements にはイベントシステムが含まれています。イベントは通常、特定の要素に送信され、そのイベントが消費されるまで UI ツリーの上下に伝達されますが、この伝達動作はカスタマイズ可能です。MouseMoveEvent などの基本イベントはシステムによって送信され、開発者はそのイベントの受信登録ができます。独自のカスタムユーザーイベントを定義して送信することもできます。

イベントは、UI の状態が変化したり、ユーザーが何らかの操作をしたりしたことを知るための主な方法です。以下の例では、ユーザーがスライダーの値を変更したタイミングを検出し、ラベル要素に新しい値を表示しています。

デバッガー

UI がおかしく表示されたり、画面に存在するべき要素が表示されなかったりする場合には、UIElements Debugger が役立ちます。Chrome や Firefox のウェブサイト用のデバッガーを使用したことがある人にとっては、親しみやすいでしょう。

このデバッガーで UI の要素をデバッグするには、要素の選択を有効にし、要素の上にカーソルを合わせるか、要素を右クリックして、「Inspect」を選択します。デバッガーの左ペインに現在のウィンドウのライブヒエラルキーがすべて表示され、右ペインにスタイルインスペクターが表示されます。このスタイルインスペクターで、要素にどのスタイルが割り当てられているか、各スタイルの値が何(どのスタイルシートのどのセレクター)に由来しているかを調査できます。それから、スタイルの値をライブで追加したり編集したりして、その変更が UI に与える影響を確認することもできます。

その他の機能

  • バインディング:多くのコントロールは SerializedObject にバインドして、UI とアセットデータをリンクすることができます。IBindable インターフェースを実装している要素は(すべての組み込みのフィールドと同様に)、SerializedProperty への文字列バインディングパスを受け取ることができます。その後、Bind() を使用して要素のヒエラルキーを SerializedObject に明示的にバインドすることができます。
  • IMGUIContainer:IMGUI で記述した既存のエディター UI が多数ある場合は、IMGUIContainer という特別な要素を使用して、IMGUI UI を単に別の要素として UIElements UI に埋め込むことができます。IMGUIContainer は、OnGUI() ループとして機能するコールバックを受け取り、通常通りに外部からすべてのイベントを受け取ります。
  • スケジューラー:UIElements にはシンプルな組み込みスケジューラーが含まれています。このスケジューラーを使用すると、コールバックを所定の時間遅延させたり、所定の間隔で繰り返し実行したりできます。

今後のリリース

現在、ゲーム内 UI に UIElements を使用できるようにするための取り組みを精力的に進めています。さらに、UIElements を中心とした視覚的なワークフローを用意して、C# コーディングをほとんどまたはまったく行わずに機能的な UI をデザイン、作成できるようにする予定です

その間にも、インスペクター、専用のエディターウィンドウを使用する新しいツール、ツールバーなど、Unity 自体の開発に UIElements を使用する傾向が強まることが予想されます。

IMGUI と uGUI に関しては引き続きメンテナンスを続け、場合によっては改良を加えていきます。近い将来に廃止する予定はありません。そうは言っても、Unity 2019.1 の Unity エディター以降、Unity で UI を作成する方法としては、UIElements が最も幅広くサポートされることになるので、そちらの利用をお勧めします。

使用を開始するには

まず、Unite LA 2018 の UIElements に関する講演をご覧になることをお勧めします。サンプルプロジェクトをダウンロードしておけば、話の流れに沿って実際の機能を確認できます。また、この講演では IMGUI と UIElements の主な相違点と共通点についても説明しているので、実際の例を通じて UIElements の主な機能の大半を知ることができます。

サンプルプロジェクトは、GitHub からダウンロードできます。

この API の詳細については、Unity 2019.1 マニュアルを参照してください。

49 コメント

コメントの配信登録

コメント受付を終了しました。

  1. I would really like to have a visual editor for this where I can design the UI by simply placing components on an artboard without having to code the layout.

    1. Damian Campeanu

      6月 20, 2019 5:17 pm

      We are working on a visual editor. Should have something for you to try around the 2019.3 release.

  2. david limkys

    6月 3, 2019 9:19 am

    Great work, I wonder what are the reason you decided to build a new xml, css and javascript implementations instead of using html css and js allowing us to use existing frameworks?

    Also I would love a hint on when will this be possible for in game UI

    1. Damian Campeanu

      6月 3, 2019 7:40 pm

      We aim to be CSS, FlexBox, and XML complaint as much as possible. Definitely not trying to invent new languages or formats. However, in terms of implementation, we needed something that was integral to Unity and was able to run both in Editor and on all the platforms we support.

      We also wanted to freedom to not support all features of a standard, and potentially go against the standard, if we need to meet performance or usability requirements.

      As for support for game UI, we are aiming for a preview (package) later this year (2019), with full support in 2020.

  3. Kevin Karsopawiro

    5月 15, 2019 10:27 am

    Amazing progress but in my opinion the Unity team should focus on getting this system working for in-game UI as soon as possible. Since the game we’re working on is quite UI heavy we have been trying all sorts of approaches to make our UI development easier. We’re currently using the Chromium Embedded Framework that has been implemented into our game with all sorts of hackery just so we’re able to have the modularity and ease of development we needed. This UIElements system changes all that and makes our CEF implementation obsolete. No more compute heave Chromium running in front of our game. Please please please make this a priority for the sake of not just my team of developers but for all Unity developers that struggle with the current UI system.

    1. Damian Campeanu

      5月 15, 2019 3:31 pm

      In-game UI is definitely a priority going forward. Thank you for the detailed info on your pipeline. We should have something for you to try soon!

  4. Alexis Pautrot

    5月 13, 2019 8:14 pm

    “In its current form, it’s a tool that makes it easier for you to extend the Unity Editor.”
    Sorry, but I can’t see how this could be true. Node based declaration (UXML) is the worst solution when iterating a UI, a use case where IMGUI can’t be beat. And style sheets are at best a time-wasting toy for real production tools.
    I can’t see another usage than for in-game UI. But then what about the UnityEngine.UI stuff ?

    1. Damian Campeanu

      5月 13, 2019 8:28 pm

      I recommend a look at the Unite LA 2018 presentation (linked at the end of the blog above). It goes into great (probably too much) detail on how UIElements is different from IMGUI, including iteration speeds.

      As for UnityEngine.UI, it will continue to exist for a long time, however, UIElements will become the new API runtime UI once it is ready.

      1. Arnaud Jamin

        5月 15, 2019 12:02 am

        For an in game UI, UnityEngine.UI seems to fit better with overall Unity GameObject/Component philosophy. It also work nicely with the nested prefabs feature because you can now edit nested UI components. So what are the reasons UIElements will deprecate UnityEngine.UI framework for an in game UI? Thanks!

        1. Damian Campeanu

          5月 15, 2019 7:21 pm

          We wanted to have a common UI framework for both runtime and Editor. UIElements was the end result of this want and it is why we are moving forward with it for both Editor and Runtime. In addition, as we move into the DOTS world, we cannot be so closely tied to GameObjects. UIElements is independent of GameObjects or Entities (DOTS) so it can work on top of either system.

          As for the current GameObject world and prefabs, as part of our runtime support work, UIElements will enter the GameObject world and start existing in the scene like uGUI. It just won’t be exactly the same mapping as before.

          That said, UIElements does have a prefab system of sorts within, namely, UXML templates. You can embed templates within templates and override styles and attributes on them. It’s similar to the prefab system but sepcifically optimized and designed for UI workflows.

        2. Arnaud Jamin

          5月 16, 2019 12:27 am

          Thanks for the answer.
          I think you had a great workflow with UnityEngine.UI. Begin able to add UI elements in the scene view, and reference them directly in a .cs file by exposing a member is very straightforward in a good way. It makes the process very fast, and still leave the possibility to have a separation of roles (programmer & designer).
          The new workflow seems to follow the html/xaml trend. This is probably more ‘standard’ but it come at the cost of editing multiple files outside of the scene view. The editor will remove the need to edit the uxml and uss files by hand. However, using queries to find your fields is less elegant than the uGui method.
          I hope the lifetime of UIElements will be greater than uGui.
          Thanks.

  5. Damian Turnbull

    5月 3, 2019 2:54 am

    I’m really excited about this. I am hoping to build a node-based editor tool and I’d love to get my hands on the GUI code for the Shader Graph or even a demo class for node-based interfaces using UIElements.

    1. I second this!

  6. @Ashkan — Take a look at Noesis. It’s a XAML runtime for Unity. It is pretty much WPF but it works in Unity3D and it works *amazingly* well.

  7. Patrik Nordberg

    4月 27, 2019 11:42 am

    Will UIElements support SVG files, without the SVG importer?

    Thinking icons, and other graphical assets you want to have in your UI.

    1. Damian Campeanu

      4月 30, 2019 4:34 pm

      Yes. We are currently looking at SVG support in UIElements. We’ll share more on this in the future.

      1. Patrik Nordberg

        4月 30, 2019 6:35 pm

        That is great to hear. If you combine that with CSS *cough* I mean USS animations ;) then that could be really useful for in-game UI.
        Thinking it could be much easier to create a responsive UI, supporting all resolutions with crisp graphics. Just the way we’re used to browsing.

        Just out of curiosity, do you use something like chromium or other engine to render the UI, or would that be overkill?

        1. Damian Campeanu

          5月 1, 2019 10:18 pm

          We have our own optimized UI renderer that plays well with the rest of Unity’s render pipeline. UIElements will eventually be the UI system for in-game UI so we have to integrate well with the runtime.

  8. I do like how clean the fonts look in those screenshots and the revamped “maximize window button” is absolutely fabulously too!

  9. There’s a bug in your documentation for Retained Mode.

    IntSlider slider = new IntSlider();

    should be:

    SliderInt slider = new SliderInt();

    1. Damian Campeanu

      4月 30, 2019 4:32 pm

      Thanks for the note. It will be fixed soon.

  10. How can I implement my component UI without creating a new UXML?

    1. Nvm. Got it.

  11. Michael Nischt

    4月 24, 2019 10:31 pm

    Old but still great arguments for an immediate API: https://youtu.be/Z1qyvQsjK5Y 🙃

  12. Why not a WPF and XAML like thing instead of this? seriously curious to know

    1. Konstantin Khaldin

      4月 25, 2019 7:27 am

      What wpf features are you missing, exactly?
      Awkward styling?
      Obscure binding semantics?
      Ugly dependency/attached properties declaration?
      Tons of generated back code?

    2. Dave bacher

      6月 7, 2019 12:52 am

      Noesis (https://www.noesisengine.com/) has a drop-in XAML with close to the full feature set for Unity..

      If you use a XAML user control for a unit tile in user interface, a mod or DLC can copy the XAML file and add features to it – and so it’s a lot more flexible. Data Triggers, in particular, can be awesome for mods and DLC = and can be combined with Storyboards.

  13. Emil "AngryAnt" Johansen

    4月 24, 2019 1:05 pm

    Looking forward to authoring systems as a blend of this and IMGUI. Seemingly a very nice case of both worlds bestness.

  14. Christoph Dolar

    4月 24, 2019 11:39 am

    That’s _exactly_ what we’ve hoped to come along. And the main question is: when will this be availably in-game :)

    1. Damian Campeanu

      4月 24, 2019 9:51 pm

      No set dates for runtime UI yet but we should have a preview of runtime later this year.

  15. I was hoping Unity will come up with something like WPF/XAML, and yet here we are, restudy everything, again…

  16. Does it support tables?

    1. Damian Campeanu

      4月 24, 2019 9:53 pm

      No tables yet, but the capability to build your own custom elements (like tables) is fully supported. You can also continue to use IMGUI solutions for specific controls or elements that have no good equivalent in UIElements.

  17. Barış Dayak

    4月 24, 2019 6:34 am

    Perfect contents and codes . Thank you.

  18. Gotta love how so many developers love to bash on web development, and yet more and more of native desktop applications are steering towards similar paradigms to that of web development.

    1. Andrew Ackerman

      4月 24, 2019 8:05 am

      Web development sucks because it’s a chaotic wasteland of lawlessness and non-standardized practices. Take paradigms made common in web development and apply them to other disciplines and they suddenly become bearable to use.

  19. Awesome. This looks like the silver bullet, but also sounds like having 3 different systems for UI may end up being a hard to solve puzzle… some will have to let go sooner rather than later…
    On a side note, I was wondering if recent controls like Treeview will be ported to this new system?

    1. Damian Campeanu

      4月 24, 2019 9:56 pm

      More complex controls like TreeView will come in a future release. That said, there’s enough flexibility in the current public API, along with more basic controls like a virtualized ListView, that you can use to build your own TreeView control.

  20. Patrik Nordberg

    4月 24, 2019 3:12 am

    Will UIElements support the box-sizing property of CSS, with the border-box value?

    1. Russ Painter

      4月 24, 2019 8:12 am

      Hopefully Border-Box is the default. It’s the obviously sensible option which SHOULD have been the default in html/css.

      1. Christoph Dolar

        4月 24, 2019 11:39 am

        Yes.

      2. Damian Campeanu

        4月 24, 2019 10:22 pm

        Actually, box-sizing: border-box is already the *default* in UIElements (like CSS should have been). We just don’t support the actual “box-sizing” property because we ONLY support border-box.

        1. André B. Amundsen

          5月 3, 2019 11:04 am

          <3

    2. Damian Campeanu

      4月 24, 2019 9:58 pm

      We are focusing on visual UI authoring and runtime support for the immediate future. However, more advanced CSS features will trickle in over time.

  21. Nicholas Ventimiglia

    4月 24, 2019 1:40 am

    Just wow. What year is this, I feel like I have gone back in time to 2006. Im terrified of this new paradigm and how branched it is from ugui and ecs.

  22. Alan Mattano

    4月 23, 2019 9:53 pm

    So many changes and improvements. Is incredible how fast this engine is growing! Thx Unity Awesome team!

  23. Next feature – UReact ?

  24. Gustav Olsson

    4月 23, 2019 9:11 pm

    Thank you, I’ve waited a long time for something like this.