Unity Mars：シンプルで柔軟な AR オーサリングのためのフレームワーク設計

Unity では今、クリエイターが理想的な方法で AR アプリケーションを作成できるようにするためのワークフローを構築しようとしています。その方法とはつまり、コンテキストアウェアで、柔軟で、カスタマイズ可能で、あらゆる種類のデータを使ってどこでも機能する AR アプリケーションを、大量のコードを必要とせずに開発できる方法のことです。 今年予定されている Unity Mars のリリースが近づいているため、当社がこの作業環境とコンパニオンアプリを構築している方法と理由の背景情報をお伝えしたいと思いました。私たちは、これが、体験レベルを超えた次世代の空間、コンテキストコンピューティングの導入に向かう大きな一歩であると考えています。

「Unity で AR をよりわかりやすくするにはどうすればよいのか。」現実世界とアプリケーションの座標フレームが一致することはほとんどありません。開発者は、不確実な世界に対して正確なオーサリングができるツールを求めています。そしてそのツールは、"ファジー"な配置ルールによってさまざまな状況に対応できるものである必要があります。

これを実現するために私たちが出した答えは、大規模な座標系を、一連の小規模な座標系に分割するというアプローチです。それぞれの座標系は、既知の空間を表します。そしてそれらの空間は、プロシージャルな方法で現実に適合されます。このソリューションは共生型のソリューションです。コンテンツのベースとなる現実世界の各側面においても、座標系の境界が定義されます。

私たちは、Unity Labs のハックウィーク期間中にこのアイデアをテストし、マルチプレーンのエクスペリエンスを作り出すことに成功しました。これは数年前にはまったく聞かれなかった技術であり、現在でも MARS 以外ではほとんど存在しません。

このソリューションはとても効果的だったので、私たちはこれを使って、さらに高度な AR エクスペリエンスを作り出せるようにしたいと考えました。ただし、その先にはさらなる課題が待っています。Unity Mars の開発は、質問と答えの 2 つのステップを開発の単位として進められてきました。私たちはそのステップごとに Unity Mars を進化させ、プラットフォームの開発を前進させています。

私たちは、最初のハックウィーク中に AR 開発に関するいくつかの大きな課題を確認しました。

• 世界をデジタルに表すには、依存関係グラフの作成が大きな課題となります。これをクリアするには、継続的に成長しながら、新しいデータタイプを増やしていくリアルタイムなデータベースが必要となります。
• ゲームコードとプラットフォームの管理は、効果的に統合することができません。これらの要素ははっきりと分けて管理した方が、より効果的に管理できます。
• 私たちは、ユーザーが AR シーンの全体について知らなくても、AR シーン全体のレイアウトに影響するスクリプトを記述できるようにしたいと考えています。

さらに、私たちは Unity Mars によって次のコアバリューを実現したいと考えました。

• Unity と同様の感覚で使用できる – 私たちのチームのモットーは、「現実をビルドターゲットにする」ということであり、私たちは本気でこれに取り組んでいます。Unity Mars は Unity を拡張し、現実を描き出すためのエディターを提供するものですが、Unity の基本的な性質は維持されます。
• 安全 – 空間コンピューティングは新しい分野ですが、ユーザーはその分野を安全に探索し、実験できる必要があります。したがって、ユーザーが抵抗なく導入できる開発パターンを提供する必要があります。
• すべての開発者にとって使いやすい – Unity Mars のすべてのパーツを、対象ユーザーとなる開発者の技術レベルに応じたものにする必要があります。

これらの課題は、複雑かつ包括的なものです。これらをクリアするには、そのソリューションも包括的である必要があり、かつアプリケーションロジックから分離されたものにする必要があるため、その全体像はなかなか見えてきませんでした。この課題をクリアするために作られたのが、Unity Mars Data Layer でした。

Unity Mars Data Layer は 4 つのパーツに分けることができ、それらを組み合わせることで、現実を柔軟に抽象化することができます。

まずベースとなるのは、現実世界のデジタル表現です。セマンティクスは、ユニバーサルな AR 言語の基盤となるものです。「床」や「木」など、サーフェスに適用される特性は、シンプルなセマンティクスの例です。 空間セマンティクスでは、現実世界のさまざまなバリエーションに適合できるジェネリックがモデリングされます。たとえば、顔を例に考えてみましょう。顔にはさまざまな形やサイズがあります。顔の AR コンテンツをオーサリングするには、体のどの部分が顔であるかや、目がどこにあるかがわかっている必要があります。顔は人それぞれに異なりますが、これらのデータピースをターゲティングすることで、コンテンツを適合させることができます。Unity Mars（および AR）の真のパワーは、具体的なデータを、このように抽象的なセマンティック体系へと置き換えたときに発揮されます。 次の階層に位置するのが、データ所有権です。デジタルコンテンツを現実世界と共存させるには、どのデータが利用可能かについての明確な境界を定める必要があります。データ所有権を使用すれば、現実世界の各側面をコンテンツに対して自動的に予約することができます。デジタルコンテンツに対する現実世界データの理想的なアレンジメントを管理することは、アプリケーション開発者にとって不可能な場合もありますが、その問題は Unity Mars Data Layer によって解決されます。 Unity では、AR でのデータアクセスにおいて、一貫性のあるパターンが使用されます。イベントは、データの検出時、更新時、または喪失時に生成されます。「問合せとデータイベント」のシステムは、このコンセプトをさらに高レベル化したものです。ユーザーは、データと値の組み合わせを指定して、問合せをセットアップします。その後、Unity Mars Data Layer が、取得、更新、および喪失のイベントを生成します。つまりユーザーは、単に何らかの平面が見つかったことを知るのではなく、指定したサイズ、向き、および光量の平面が検出されたことを把握できるということです。Unity Mars のデータストレージは、新しいカスタムタイプのデータを動的に操作できるよう設計されているのです。要するに、ユーザーは状況の複雑さに関係なく、事実上すべてのシナリオに対応してイベントを取得できるということです。 そして、この構造の最上部の階層を成すのが、プロキシシステムです。プロキシシステムは、現実世界を Unity オブジェクトで表します。プロキシシステムでは、このネイティブな Unity 表現が自動的に問合せへと変換されます。AR プロキシオブジェクトはデータイベントに結び付けられ、その結果、デジタルの Unity コンテンツと純粋に一致する、オブジェクトライフサイクルが提供されます。

Unity Mars のデータは、すべての AR 開発者にとって役立つものである必要があります。そこで私たちは、開発者を 3 つのコアグループへと整理しました。

• デザイナー：データについて細かなことは気にせず、現実世界のセマンティックとビジュアルという観点から、新しい AR アプリを作り出そうとする開発者です。
• プロバイダー：ハードウェアとソフトウェアを使用した最新のテクニックを通じて、AR のエコシステムに新種のデータを追加する開発者です。
• エンジニア：データの使い方を工夫し、他のグループとやりとりしながら、デザイナーのビジョンとプロバイダーのデータとの間にあるギャップを埋める役割を果たす開発者です。

各グループは、それぞれの目的に特化した方法で Unity Mars Database を操作します。これにより、各タイプの開発者が他の開発者とやりとりしながら、自身のニーズとワークフローに合ったエクスペリエンスを享受できるようになります。

プロバイダーは、Unity Mars Data Layer の「データ表現とストレージ」機能だけを使用して作業します。上記のアーキテクチャを見てわかるように、Unity Mars では外部のデータや機能が多く使用されます。プロバイダーには、あらゆるタイプのデータを追加、更新、削除するためのいくつかの機能だけで構成された、シンプルな API が提供されます。プロバイダーは、向き、位置、回転、色、ライト、ラフネスなど、複数のタイプのデータを追加し、それらを相互に関連付けることができます。 ここで、AR Foundation の平面が Unity Mars にどのようにパイピングされるかについて例を示します。

void AddPlaneData(MRPlane plane)
{
     var id = this.AddOrUpdateData(plane);
     this.AddOrUpdateTrait(id, TraitNames.Plane, true);
     this.AddOrUpdateTrait(id, TraitNames.Pose, plane.pose);
     this.AddOrUpdateTrait(id, TraitNames.Bounds2D, plane.extents);
     this.AddOrUpdateTrait(id, TraitNames.Alignment, (int)plane.alignment);
     if (planeAdded != null)
         planeAdded(plane);
}

ここで重要なのは、プロバイダーのインターフェースで、ある機能投入パターンが使用されるという点です。私たちは、実装環境から API を切り離すことで、データソース間の切り替えを簡単に行えるようにしました。これは、オーサリング中にデータのシミュレーションと再生を行ううえで、きわめて重要です。 プロバイダーは、システムにどのデータを追加するかを、クラス定義内でリストする必要があります。これが、Unity Mars の平面プロバイダー用の特性リストです。

static readonly TraitDefinition[] k_ProvidedTraits =
{
     TraitDefinitions.Plane,
     TraitDefinitions.Pose,
     TraitDefinitions.Bounds2D,
     TraitDefinitions.Alignment
};

このデータをコンパイル時に利用できるようにすることで、各プラットフォームのアプリケーションにどのデータが利用できるかを正確に把握できるようになります。またこれにより、アプリケーションが機能するかどうかや、推論 API の形式で追加のサポートスクリプトを提供する必要があるかどうかがわかります。

AR エンジニアは、不完全なデータや予期しないデータがある場合に、現実世界について推論を行わなければならないことがよくあります。シンプルな例として、彫像の周りに教育用のグラフィックを表示する、あるアプリケーションのケースを考えてみましょう。彫像に対するオブジェクト認識機能は、一部のデバイスで利用でき、その他のデバイスでは画像マーカーが使用されるとします。また、彫像の位置があらかじめオーサリングされた空間への再ローカライゼーションは、さらに別のプラットフォームで提供されるとします。 こうなると、もはやシンプルとは言えそうにありません。これをさらに複雑にしてみましょう。ユーザーが彫像の写真を見た場合はどうなるでしょうか。また、縮小サイズのレプリカを見た場合はどうでしょうか。さらに、機能を使いたくても彫像にアクセスできないユーザーはどうなるでしょうか。VR のユーザーはどうなるでしょうか。 このような場合、これらすべてのシナリオや偶発性をサブセットにして処理するアプリケーションを作ることは可能です。かつては、このような AR エクスペリエンスを提供したい場合、この方法が唯一のソリューションでした。しかし、これは優れたソリューションとは言えませんでした。アプリケーションロジック、プラットフォーム抽象化、および環境分析がすべて一緒に導入されるため、生成後のシーンでは、オブジェクトと不安定なフォールバックが複雑に混在する結果となります。その結果、プラットフォーム固有の問題が頻発し、デバッグは、できたとしても非常に困難となります。 これを解決するソリューションが、推論 API です。これらの API は、複合的なシナリオをすべて処理するためのパワーとナレッジをエンジニアに提供する、スクリプティングインターフェースです。Unity Mars では、これらのスクリプトがいつ必要になるかについてのロジックが処理されます。利用可能なプロバイダーによって提供された特性リストは、Unity Mars のコンテンツに必要な特性のリストと結合され、その結果、そのギャップを最も効率的埋める推論 API が決定されます。適切な推論 API がない場合は、そのことを知らせるアラートが開発者に送られます。 推論 API インターフェースは、Unity Mars の「データ表現とストレージ」機能とやりとりをします。推論 API では、Unity Mars データのリスト全体に一度にアクセスできるようになっています（たとえば、垂直にソートされた平面のリスト全体）。 推論 API では、データの追加、更新、および削除に、データプロバイダーと同じ関数呼び出しが使用されます。つまり、Unity Mars では、推論 API からのデータとハードウェアプロバイダーからのデータを、組み合わせて処理することができるのです。機能のギャップは、アプリケーションで変更を加えることなく、シームレスに埋めることができます。

私たちは、Unity 内の現実世界のプロパティを、ユーザーが参照できるオブジェクトとして表したいと考えています。 これによりユーザーは、ビジュアルを通じてデジタルコンテンツをすばやくオーサリングし、検証できるようになります。オブジェクト参照によって、追加のスクリプトを記述することなく、Unity のスクリプトやイベントを既存のゲームコードと連携させられるようになります。これはきわめて重要なポイントです。私たちは、アセットストアのすべてのパッケージやその他のユーザーパッケージを、変更作業を必要とすることなく、Unity Mars で取り扱えるようにしたいと考えています。この相互の互換性は、ワークフローが Unity のベストプラクティスに準拠している場合に、最も効果を発揮します。

私たちのオブジェクトシステムは、シンプルさを重視して設計されています。複雑な構造は、それらのシンプルなオブジェクトをさまざまな方法で組み合わせることにより作成できます。またそのオブジェクトは、自己完結型となるように設計されています。通常の Unity オブジェクトと同じ方法で動作するので、シーンビューやあらゆるタイプのプレハブで直接動作させることができます。 Unity Mars のコンテンツは、Proxy、ProxyGroup、および Spawner という 3 つのコンポーネントで構成されます。これらのオブジェクトについては、こちらでさらに詳しく説明しています。 Proxy は、AR の単一のオブジェクトを定義します。多くの AR ツールセットでは、これが機能の限界となっています。ProxyGroup では、現実世界にある複数の物体が何らかの方法で関連するシナリオを記述できます。他の AR オーサリングエクスペリエンスでは、この機能は提供されません。これは、アルゴリズムによって解決するのが難しい、きわめて複雑な問題です。私たちは、これを処理できるようにするために、Unity Mars Data Layer を開発しました。最後のコンポーネントは、Spawner です。Spawner は、Proxy または ProxyGroup を含むオブジェクトです。それらを繰り返し複製することで、現実世界全体をリスキンするルールセットを生成します。

各コンポーネントがどのように連携するかを、先ほどのレイヤー図に沿っておさらいしたいと思います。

• すべての Proxy、ProxyGroup、および Spawner コンポーネントは、デザイナーによってオーサリングされます。これらのコンポーネントは、問合せを作成し、イベントに応答します。
• 問合せは、データベースから一致する項目を検索し、所有権を制御します。
• 推論 API とプロバイダーは、データベースのデータを追加したり、削除したりします。

データレイヤーの各側面が連携することにより、すべてのプラットフォームで最善のエクスペリエンスが提供されます。

• シーン内の Unity Mars プロキシオブジェクトは、アプリケーションの実行に必要な特性の必須セットを定義します。
• プロバイダーは、アプリケーションで利用できる特性のセットを定義します。
• 推論 API は、利用可能な特性のセットと、アプリケーションに必要な全コレクションとの間のギャップを橋渡しする役割を担います。

私たちは、ユーザーの皆さんが Unity Mars を使って革新的なアプリケーションを作成できるようになることを楽しみにしてます。皆さんのご協力を得ながら、私たちは空間コンピューティングをさらに進化させていきます。Unity Mars について学習したい方や、より広範囲のリリースに向けての最新情報を受け取りたい方は、サインアップして更新情報を入手するとともに、新しい Unity Mars のウェブページをチェックしてください。