fbpx

第三者もMRを楽しめる?スペクテータービューの使い方と導入方法を解説


この記事ではMagic LeapやiPad/Androidなどのデバイスを用いたスペクテータービューの導入と、その前提となるマルチプレイヤーの実装について開発ノウハウをお教えします。

スペクテータービューとは、 ARグラスなどを体験している人の視界を第3者も見れるようにする 、開発者・ユーザーどちらにとっても非常に有用性の高い機能です。

この記事では、

  • スぺクテータービューとは?
  • 前段としてマルチプレイヤー機能の導入方法
  • スペクテータービューの導入方法

を解説しています。

AR/MRソフトウェア開発者には必見の機能説明になりますので、ぜひ最後までお読みください!

スペクテータービューとは|開発環境の前提共有

本記事で定義するスペクテータービューとは、Magic Leap向けのMRアプリケーションやスマートフォンのARアプリなどに表示される、現実世界に対して仮想オブジェクトが重ね合わせた映像を、外部のディスプレイなどに出力できる機能のことを指します。

スペクテータービューの導入により、 体験者以外の第三者にもコンテンツの内容を提示することが可能 になります。

▲スペクテータービュー導入イメージ

この記事においての動作環境・開発環境の前提

動作環境

この記事で記述する実装方法等は、以下の環境を前提に動作させることとします。開発環境が異なると動作も異なるので、必ずチェックするようにしましょう。

【Magic Leap】

  •  Lumin OS 0.98.0以降(0.98.10, 0.98.01, 0.98.0でテスト済)

【iPhone/iPad】

  • iOS 13.3.1以降(13.3.1, 13.4でテスト済)

※Azure Kinectを用いたスペクテーター・ビューを実装する場合、以下の環境が必要になります。

【必須項目】

  • Windows 10 April 2018 (Version 1803, OS Build 17134) release (x64) 以降のバージョン

【推奨項目】

  •  第7世代 Intel® CoreTM i3 以上のCPU
  •  4 GB 以上の RAMメモリー
  •  専用の USB3 ポート
  •  OpenGL 4.4 または DirectX 11.0 をサポートしたグラフィックドライバ

開発環境

この記事で記述する内容は、以下のツール・パッケージで開発することを前提とします。

  • Unity 2019.3.6 (Magic Leap Unity Package 0.24.1)
  • AR Foundation 2.2.0 (preview.6)
  • Magic Leap XR Kit 0.2.0

【前段➀】マルチプレイヤー機能の実装方法・ノウハウ

本章では、Unityを使用して Magic Leap および他デバイス(iOS/Android/PC) で動作するマルチプレイヤーのコンテンツを作成する際のノウハウをお教えします。

この記事で解説するスペクテータービューを実装するためには、 マルチプレイヤーの機能を実装することが前提となります。 

マルチプレイヤー機能とは、ユーザーが使用するデバイスおよび、スペクテータービューを生成するためのPCまたはデバイス間で、コンテンツ中の仮想オブジェクトやイベントを共有する機能です。

マルチプレイヤーのコンテンツを作成する際に、異なるデバイス間でリアルタイムにオブジェクトを共有するため、以下の3つのような実装が必要となります。

  1. 座標共有
  2. オブジェクトの位置・回転・スケールの同期
  3. プレイ中に発生する各種イベント(ユーザー入力等)の相互通信

この記事では、デバイスごとに異なる座標共有について詳細を記載します。

座標共有を実装するために必要な3つの方式

まず、座標共有はコンテンツやデバイスに応じて、下記の3方式の中から選択していくことになります。

  1. 各デバイスごとの原点リセットの方法を利用して、共通の原点を定める方法
  2. 共通のイメージマーカー(QRコード・ARマーカー)を各デバイスで認識して、マーカー位置を共通の原点とする方法
  3. PCFによるマッチングを行う方法

それではその方式を1つ1つ詳しく解説していきましょう。

(1)原点リセット方式|各デバイスごとのリセット機能を活用

座標共有のうち、まずは 各デバイスごとの原点リセットの方法を利用して 、共通の原点を定める方法です。

原点リセットの場合、Magic LeapかiOS/Android によって方法が異なります。

  • Magic Leapの場合
    端末が起動した場所が原点として設定され、また起動後でもUSB接続したPCから mldb reset-headpose コマンドを実行するか、Lightwear 両端のセンサーを手などで覆い隠すことによって、強制的にその時のデバイス位置を原点としてリセットできます。
  • iOS/Android で ARFoundation を利用している場合
    UnityのAPIレベルで、原点位置を指定した位置でリセットする機能が存在します。

(2)イメージマーカー方式|専用フォーマットで空間座標を補正

 専用フォーマットによるマーカーや自然画像によるマーカーを空間中に配置して 、デバイスで画像認識を行うことによって、空間の座標を補正する方式です。

  1. OpenCVの ArUco を利用する方法
    専用のフォーマットのマーカーを使った認識方法です。
    他の方法に比べて、マーカーとして使用できる画像は限られますが、認識のパフォーマンス負荷が低く、またマーカー自体が小さくても認識しというメリットがあります。
    有償アセットである OpenCV for Unity を利用することで、Magic Leap/iOS/Android/Windows/Mac 等、あらゆるプラットフォームに容易に導入できるのも魅力の一つです。

    ▲ArUcoのマーカーイメージ

  2. Vuforia を利用する方法
    専用フォーマットのマーカーではなく、自然画像をマーカーとして使用することができます。
    特徴としては、Magic Leap標準搭載の Image Tracking よりも精度が高いことが挙げられます。
    iOS/Androidはもちろん、Magic Leapも公式にサポートされており、開発は無償で可能だが、サービス提供時に有償ライセンスを購入する必要があります
  3. Magic Leapに標準で搭載されている Image Tracking を利用する方法
    Magic Leapで開発する場合のみ使用できます。
    専用フォーマットのマーカーではなく、自然画像をマーカーとして使用できますが、上述したようにVuforiaよりも認識精度は劣ります。

原点リセット方式とイメージマーカー方式は共存可能で、たとえば一部の端末は原点リセット、残りの端末はイメージマーカー方式という構成を取ることができます。

(3)PCF方式|Magic Leap提供提供の空間アンカー

最後に、Magic Leap が仕組みを提供する、環境中で永続的な位置・回転の情報を持つ空間アンカーであるPersistent Coordinate Frames(PCF)を利用する方式です。

マーカーや原点リセットなどの作業を必要とせず、 各デバイスで周囲を見渡すだけで自動的に環境を認識し、位置合わせを行ってくれます 

このPCF方式はMagic Leap が標準でサポートしており、Magicverse SDK XR Kit を利用することによって iOS/Android デバイスでも利用可能です。

注意点としては、座標を共有するすべてのデバイスがPCF方式をサポートしている必要があり、サポートしていないプラットフォーム(WindowsやMacなど)が含まれる場合は、選択肢から除外されるので気を付けましょう。

【前段➁】マルチプレイヤー実装をネットワークライブラリで簡略化

ここまで解説した「マルチプレイヤーコンテンツによくある機能」は、 ネットワークライブラリを使用することで大幅に簡略化できます。 

ネットワークライブラリを選定する上で、まずポイントとなるのがネットワーク・トポロジー(デバイス間の端末の繋がり方)です。

代表的な方式として3つご紹介します

  1. クライアント・サーバー方式(以下C/S)
    C/Sはコンテンツが動作する各クライアント(Magic LeapやiOS/Androidなどの各デバイス)に加えてサーバーが存在し、クライアントはサーバーと通信を行います。
    ※C/Hと明確に区別するために、 Dedicated Game Server (DGS) と分類する場合もあります。
  2. P2P
    P2Pではサーバーは存在せず、クライアントはクライアント間で通信を行うため、専用のサーバーを必要としません。
  3. クライアント・ホスト方式(以下C/H)クライアントのどれか一つがサーバーとしての役割を果たし(ホストと呼ぶ)、クライアントはホストと通信するものである。
    ※便宜的にC/SやP2Pと分けて記述しているが、一般的にはクライアント・ホスト方式という用語は存在せず、C/Sの亜種とみなす場合・P2Pの亜種とみなす場合のどちらのケースも散見されます。

C/S P2P C/Hのメリット・デメリットをまとめると下記の表のようになります。

方式 メリット デメリット
C/S ・チート対策が比較的容易

・接続するノード数が多い場合でもスケールしやすい

・専用のサーバー機とそれを維持するコストが必要
P2P ・専用のサーバー機が必要なく低コスト ・接続するノード数が多い場合に、ネットワークがボトルネックになりやすい

・チート対策が難しい

C/H ・専用のサーバー機が必要なく低コスト

・(使用するライブラリにもよるが)ホストとクライアントで共通のコードベースで実装できるため、C/Sよりも開発の学習コストが下げられる・開発効率の向上が見込まれることが多い

・ホストに負荷が集中しやすい

・(使用するライブラリにもよるが)ホストとクライアントで共通のコードベースで実装するため、開発プラットフォームが限定される

 

 

【代表的なネットワークライブラリとその特徴】

ライブラリ名 特徴 開発元 方式
UNet Unityにビルトインされていたネットワークライブラリ。2020年3月現在、開発は止まり非推奨の機能となっている。 Unity Technologies C/H
Mirror 非推奨となったUNetを有志が引き継ぎ、オープンソース化したもの。使い勝手はほぼUNetと同等で、安定性や機能が強化されている。 オープンソース(MITライセンス) C/H
PUN (Photon Unity Networking) 世界的に広く使われているプロプライエタリなネットワークライブラリ。サーバーを経由するが、擬似的なP2Pとして使用できる。 Exit Games C/S
モノビットエンジン 国産のプロプライエタリなネットワークライブラリ。 モノビットエンジン株式会社 C/S
Magic Onion 日本人開発者が中心となって作られたオープンソースのネットワークライブラリ。サーバーとクライアントを共通のC#コードベースで実装可能。 オープンソース(MITライセンス) C/S
Transmission MLTK(Magic Leap ToolKit)に含まれるネットワークライブラリ。PCFなどのMagic Leap 特有の機能をサポートしている。 Magic Leap P2P
Unity Transport & Unity NetCode UNetが非推奨となった後開発されているUnity公式のネットワークライブラリ。2020年3月現在まだアルファ版。 Unity Technologies C/S

どのトポロジー・ライブラリを選択するかは、コンテンツの特性(同時接続数・チート耐性・予算・レイテンシ耐性など)など非常に多くの要素を考慮して決定しなければならないので、本記事では触れません。

Unity Forum の議論 やUnity 公式ブログ にライブラリの比較や、選択基準について触れられているので、そちらを参考にしてください。

スペクテータービューの導入方法を解説

それではマルチプレイヤーの導入が済んだところで、 Unityを使用してスペクテータービューを伴うMRコンテンツを作成する際のノウハウ についてお教えします。

スペクテータービューの2つの実現方式

スペクテータービューを表示する方法として2つの方式を取り上げます。

(1)iOS/Android方式

iOS/Android方式とは、iOS/Android上でも動くクロスプラットフォーム・マルチプレイヤーなMRコンテンツとして開発し、それをディスプレイなどに出力する方法です。

前章の通り、マルチプレイヤーをサポートするコンテンツとして開発し、スペクテータービュー用のデバイスを1プレイヤーとして参加させることで実現できます。

(2)Azure Kinect方式

そして、Azure Kinect方式は、Azure KinectをPC上でコンテンツを動かし、取得したRGB画像に対してMR上のオブジェクトを合成した映像を出力する方法です。

Azure Kinect方式は動作が少し複雑なので、事前準備から実行方法まで詳細を記載します。

Azure Kinect方式の動作原理

Azure Kinectは搭載している カメラからRGB画像とDepth画像をリアルタイムで取得することができます。 

Unity上で、メッシュに対してRGB画像をテクスチャとして貼り付け、Depth画像に応じてメッシュの頂点位置を動的に変更することによって、3D形状を持つカメラ映像をシーン上に再現しています。

▲3D形状として再現されたKinect映像と仮想オブジェクトを合成して表示している様子

Depthによるメッシュの変更は、カスタムシェーダーによる頂点ディスプレースメントで処理することにより、リアルタイムの処理を可能にしています。

Azure Kinect は Windows PC に接続しますが、この Windows PC とユーザーが使用する他デバイスとのとの座標共有は、前章で述べたイメージマーカー方式で ArUco を使用して行います。

あらかじめ物理スペース内に原点となるべき点を定め、そこにARマーカーを配置し、Windows PC側でマーカーを認識させることでその場所を原点としてリセットします。

また、Windows PCでイメージマーカー方式の座標共有を行うため、ユーザーデバイス側でも原点リセット方式・ イメージマーカー方式の座標共有をサポートしている必要があります。

Azure Kinect方式のシステム構成

以下は、Azure Kinect方式のシステム構成図です。

Azure KinectはWindows PCと接続され、ユーザーが使用する Magic Leap・iOS/Android端末と同一WiFi(LAN)内に接続されます。

▲Azure Kinect方式のシステム構成図

スペクテータービューの導入例|事前準備から導入方法まで

それでは、既にマルチプレイヤーの機能が実装されている Magic Leap 向けの Unity プロジェクトが存在する前提で、Azure Kinect スペクテータービューを適用する手順を解説します。

(1)導入前に行う事前準備

  1. こちらからAzure Kinect Library一式 ダウンロードし、Unityプロジェクトにインポートする。
  2. Unity Asset Store から OpenCV plus Unity (無償)をプロジェクトにインポートする。
  3. Project Settings->Player の Allow ‘unsafe’ Code にチェックを入れる。
  4. https://github.com/microsoft/Azure-Kinect-Sensor-SDK/blob/develop/docs/usage.md から Azure Kinect SDK 1.1.0 をPCにインストールする。
    インストールされたフォルダから以下ファイルを、プロジェクト直下にコピーする

    1.  k4a.dll
    2. depthengine_1_0.dll
  5. Azure Kinect を Windows PCにUSB接続する。
  6. Windows PCおよびユーザーが使用するデバイスを同一LAN内に接続する。

(2)スペクテータービューを既存シーンへ適用する

  1.  スペクテータービュー向けに既存のシーンをコピーして、コピー後のシーンを開く。
  2. 既存のMagic Leap用の Main Camera を削除し、Hierarchy上で右クリック->Camera を選択し、新規Main Cameraを追加する。
  3.  AzureKinectDK/Prefabs/DepthRenderer.prefab を2で追加した Main Camera の子オブジェクトとしてシーンに追加。
    この際、以下のようにDepth Rendererオブジェクトの Position が (0, 0, 0.5) になっていることを確認してください。

(3)スペクテータービューの導入方法

  1. 認識させるための ArUco マーカーを印刷しておきましょう。(マーカー画像は http://chev.me/arucogen/ から生成できます。)
    ※本例では、Dictionaryは6×6、IDは0、Sizeは180mmのマーカーを使用しています。
  2.  物理的な空間内で、あらかじめ原点としたい場所を決めておきましょう。
  3. 使用するMagic Leapデバイスを、2で定めた原点におき、USB接続したPCから mldb reset-headpose コマンドを実行するなどの方法で原点リセットを行う。
  4. Windows PC上でシーンを再生すると、以下のようにカメラ映像がシーンに映るかと思います。
    印刷したArUcoマーカーを2で定めた原点位置に置き、キーボードの”c”を押すと、キャリブレーションが行われ、マーカー位置が原点になるようにカメラ位置がリセットされます。
  5. Magic Leap コンテンツを使用すると、コンテンツ内のオブジェクトがリアルタイムで、Gameビューに反映されます。
    全画面表示にして、外部ディスプレイに出力すればスペクテータービューを作成できます。

ここまでがAzure Kinect 方式の実装までの流れになります。

iOS/Android方式とAzure Kinect方式のメリット・デメリット

最後に、iOS/Android とAzure Kinect 方式のそれぞれのメリット・デメリットは以下の通りです。

方式 メリット デメリット
iOS/Android 方式 ・追加のPCを必要としないので、設置が容易 ・カメラの性能にもよるが Azure Kinect 方式よりも画角が狭くなることが多い

・現実の物体に合わせたオクルージョンの実現が困難

Azure Kinect 方式 ・iOS/Androidよりも画角が広く取れることが多い

・現実の物体に合わせた正確なオクルージョンを実現できる

・追加のWindows PCを必要とする

・Windows PCを利用するため、PCFを利用した他デバイスとの座標共有ができない

設置の手軽さの面では、iOS/Android 方式に軍配が上がりますが、 やはり画角の広さや正確なオクルージョンなど質の部分ではAzure Kinect 方式が良い でしょう。

少し手間はかかりますが、より高度なスペクテータービューを第3者が見ることができるように、Azure Kinect 方式を取り入れてみてはいかがでしょうか。

まとめ|スペクテータービューを導入してみよう

スペクテータービュー導入にあたって、前提のマルチプレイヤー機能の設定から本体の実装について解説しましたが、いかがでしたか?

スペクテータービューは、AR/MR体験時に第三者がアプリ画面を見ることができないという問題を解決してくれる非常に便利な機能です。

アプリ開発者とユーザーが同じ視点を共有できることで、 体験⇒解説⇒フィードバックの一連の流れが行いやすくなるでしょう。 

また、オフラインのイベントの集客にも外部ディスプレイを見れば、体験内容が一目で分かりやすい状態を作ることで、そのコンテンツの楽しさ・面白さを伝えるのに活躍してくれるでしょう。

ぜひこの記事の実装方法を参考に、スペクテータービューを導入してみてください。


この記事はいかがでしたか?
もし「参考になった」「面白かった」という場合は、応援シェアお願いします!

株式会社x gardenが運営するXR-Hubの記事編集部です。

読者の皆様に役に立つ情報を発信いたします。

シェアする