Canvas を使用したボリュメトリック UI — MRTK3
注意
これは、ハイブリッド Canvas ベース UI の構築方法の概念的な概要です。 個々の UX プレハブに関するドキュメントについては、UX コンポーネントに関するドキュメントを参照してください。
MRTK3 には、Unity の RectTransform および Canvas システムと統合されたボリュメトリック UI が導入されています。 このシステムは、これまでは主に 2D フラット UI に使用されていましたが、3D ボリューム UI をレンダリングしてレイアウトすることも可能です。 これにより、デザインのイテレーションを高速化し、ボリュメトリック UI で作成できるデザインの忠実性を高めることができます。
注意
Canvas ベースのコンポーネント ライブラリは開発中であり、新機能、外観、レイアウト、アーキテクチャによってすぐに変更されます。
MRTK 2.x の Canvas 以外の UI システムは、インターフェイス デザイン システムで期待される基本的な機能の多くが不足していたため、設計が非常に困難でした。
- ✘ 物理以外の設計ユニットがない
- ✘ 配置がない
- ✘ 余白やパディングがない
- ✘柔軟なレイアウト、またはレスポンシブ レイアウトがない
- ✘ レイアウト、サイズ、構成の 1 つの順列ごとの個別のプレハブ
- ✘ コレクション レイアウトのサポートが非常に限られている (水平または垂直の構成可能なレイアウト)
- ✘ 絶対サイズの丸い角の半径やストローク幅などの基本的な設計機能がない
- ✘ スケール を使用して UI 要素のサイズを調整し、破壊的に子を変更する必要がある
- ✘ マウスとキーボードのサポートが制限されている
- ✘ ゲームパッドをサポートしていない
これらの制限の結果、ボリュメトリック UI は、これまで、その設計はよりプリミティブであり、美しいレイアウトを作成するには、技術デザイナーによる非常に多くの手作業が必要でした。
MRTK3 では統一されたアプローチが導入されています。 すべての XR 操作をサポートする優れたボリュメトリック UI コントロール (多関節ハンド トラッキング プレスや視線入力ピンチなど) を Canvas-RectTransform コンテキストで作成できます。 コントロールは、適切な余白、パディング、レスポンシブ Flex、およびデザイナーが期待するすべての機能を使用して、自動的にレイアウトできます。 さらに、UGUI イベントを XRI にルーティングできるため、まったく同じ UI プレハブが 2D コンテキストだけでなく、ゲームパッドなどのアクセス可能な入力を含む 3D でも同様に機能します。
次の利点があります。
- ✔ さまざまな物理的コンテキスト (3D 現実、2D 画面、テレビ/デスクトップ/モバイル/Web) に対応する柔軟な設計ユニット
- ✔ 統一感のある親子関係を持つレスポンシブ レイアウトに RectTransform の配置をフル サポート
- ✔ UnityUI AutoLayout グループを使用した RectTransform マージンとパディングのフル サポート
- ✔ UnityUI AutoLayout グループを使用した優先度と余白を含む Flex レイアウトのサポート
- ✔ コントロールの種類ごとに 1 つのプレハブ。任意のコンテンツやコンテキストに合わせてサイズを変更および調整できます。
- ✔ UnityUI AutoLayout グループの水平、垂直、グリッドのレイアウト。 Unity レイアウト インターフェイスの拡張機能を使用したカスタム レイアウトが可能です。
- ✔ Mixed Reality グラフィックス ツール パッケージの高度な UI シェーダー機能により、絶対サイズの丸い角の半径、ストローク幅、余白など、各種の高度なデザイン機能を実現できます。
- ✔ スケーリングなし: すべてのサイズ変更とレイアウトは、RectTransform のサイズとオフセット メトリックによって実現されます。 親では、子はスケーリングされません。
- ✔ UGUI イベントと
UGUIInputAdapterを通じた、マウスとキーボード、CanvasProxyInteractorをネイティブにフル サポート (詳細については、Interactable のアーキテクチャに関するドキュメントを参照) - ✔ ゲームパッドと方向/相対ナビゲーションのサポート
この機能と柔軟性にはコストがかかる可能性があり、Canvas ベースの UI では、パフォーマンスの一般的な落とし穴を避けるために慎重な管理が必要です。
- UI の "移動部分" は、それぞれ個別の Canvas ノードである必要があります。 Canvas の階層の変更に関連する
O(tree_height)コストがあるため、複数の可動パーツ/再利用可能なコンポーネントに複数のキャンバスを使用することを強くお勧めします。 - シーン全体に 1 つのグローバル キャンバスを使用しないでください。
- Canvas と RectTransforms の移動と回転は、パフォーマンスに影響を与える可能性があります。 Canvas を直接移動するのではなく、移動する RectTransform 以外の "ホルスター" 変換の下に Canvas を入れ子にすることを強くお勧めします。
- マスキングとクリッピング コライダー ベースの UI のストーリーはまだ開発中です。 クリック可能なコンテンツを含むスクロール ビューを回避することを検討してください。
- 既定の Unity 方向ナビゲーション システムでは、一部の 3D コンテキストで、奇妙な動作をします。 通常とは異なる 3D レイアウトでより堅牢に動作するカスタム ナビゲーション システムについては調査しています。
さまざまなデバイスでより詳細なパフォーマンス テストを実行するため、Canvas ベースのレイアウトを最適化するためのより具体的なガイダンスをリリースします。
セットアップ
当社のコンポーネントは、物理コンテキスト用に、1 つの設計単位 : 1 mm の比率で作成されています。 イマーシブな 3D アプリケーションでの表示を目的としたボリュメトリック UI で使用する Canvas を設定する場合:
- Canvas がワールドスペースであることを確認します
- Canvas のスケールが、すべての軸でグローバルに 0.001 であることを確認します
2D ディスプレイにレンダリングするアプリケーションの場合は、指定した、ユーザビリティのメトリックと最小タッチ ターゲット サイズに合わせてスケールを自由に調整できます。
UGUIInputAdapter (Canvas ベースの UX など) でインタラクタブルを使用する場合は、シーンの (できれば空の) GameObject に CanvasProxyInteractor があることを確認します。 これにより、XRI を介して UGUI イベントが転送され、インタラクタブルが適切に動作するようになります。
UX 以外のコンポーネントで UGUI 入力を試す場合は、XRI Interactable に UGUIInputAdapter を追加します。 UX に関連しないインタラクタブルに対する UGUI 入力は実験段階で、いくつかの未公開のバグが発生しています。
実行中の開発
現在も、サポートされているさまざまなプラットフォームで優れた UI を構築するための開発ストーリーが進行中です。 現在はまだ、ほとんどの UX コンポーネントで 2 つのバージョンが出荷されています。1 つは MRTK 2.x でこれまで提供されていたような、Canvas を使用しない、静的で応答しないレイアウトのもの、もう 1 つは統合された Canvas ベースのアプローチで構築されたバージョンです。 構築するコンポーネントが増え、設計ライブラリの実装が具体化してくれば、一貫性と保守性のために Canvas 以外のコンポーネントが非推奨になると想定しています。
統合された状態の管理
状態/対話式操作とビジュアルが厳密に分離されているため、同じ状態と対話式操作のスクリプトが Canvas と Canvas 以外のコンテキストとの間で共有されていることがわかります。 これは仕様です。同じ対話式操作のスクリプトをビジュアル コンテキストまたはレイアウト コンテキストで再利用できるため、API サーフェスが低下し、対話式操作の一貫性が向上します。 たとえば、Slider は Canvas と Canvas 以外のスライダーの両方のスライダー操作コンポーネントで、PressableButton は Canvas と Canvas 以外のボタンで同じスクリプトです。 将来、新しいレイアウトやプレゼンテーション フレームワークが採用された場合、同じ対話式操作のロジックとシステムを引き継ぎ、一貫性と保守性を確保できます。
次のアーキテクチャ図は、さまざまな入力イベントとインタラクタブルの種類が連携することで統合された対話式操作の状態が実現するしくみを詳しく説明しています。 図をクリックすると拡大版が表示されます。
