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 replies on “Unity 2019.1 の UIElements の新機能”

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.

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

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.

“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 ?

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.

@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.

Will UIElements support SVG files, without the SVG importer?

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

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

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

IntSlider slider = new IntSlider();

should be:

SliderInt slider = new SliderInt();

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

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.

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

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

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

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.

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.

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?

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

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

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.

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

Comments are closed.