共同のAR体験を構築する

(音楽)

(拍手)

皆さん　こんばんは セッションへようこそ 今日はARKit 3の Multiuser ARについて話します 私はクエン･ハン ARKitエンジニアです ARKit 3の強化点をお見せし Multiuser ARアプリケーションの ビルドが 簡単で直感的になるようにします そうすれば皆さんもアプリケーションの コンテンツに集中できます ARの世界に仲間を増やしたいですか？ それならぜひお聞きください 始めましょう

共有AR体験を作るには同期が重要です このSwiftStrikeの動画のように ピンの位置だけでなく ユーザの位置と ボールとの接触も 追跡しなくてはなりません しかし追跡は時に複雑で 正しく行うのが難しい場合もあります ARKit 3はそれを解決します ARKit 3では Collaborative Sessionを紹介します 3Dコンテンツの位置の共有が 簡単になります RealityKitを使えば― ゲームの設定や物理情報が自動で同期し あなたはコンテンツに集中できます 今日の議題を見ましょう

まずCollaborative Sessionを 紹介します ARKit 3でMultiuser AR アプリケーションを作る新しい方法です 次にARAnchorの ベストプラクティスを紹介します Multiuser ARを中心にです 最後にデヴィッドが SwiftStrikeを紹介します ARKit 3とRealityKitを活用し― SwiftStrikeは新たなレベルの Multiuser ARゲーム体験を提供します ではCollaborative Sessionから 始めましょう

最初に去年紹介したARKit 2の Multiuser AR機能のおさらいを Map Save and Loadです ARKit 2ではMap Save and Loadで 持続可能なAR体験を提供しました ユーザは現在のAR体験を記録し マップをロード後 再開できます 同じ機能が Multiuser ARでも使えます この機能の中でARWorldMapという データ構造を紹介しました そこにはカメラの位置追跡に使う 3Dランドマークのマップと 仮想コンテンツの3D座標を示す ARAnchorのリストが含まれています 例えばこれはテーブル上の映像で― その上にARWorldMapをロードしました 3Dランドマークがいくつかと ARAnchorが２つあります

Multiuser ARでこの機能を使うと 各ユーザが同じARWorldMapから ロードすることになります そしてARKitが ARWorldMap内の3Dランドマークを使い マップ上で デバイスの位置を特定するのです それに成功すると― ユーザは同じ仮想コンテンツが 見えるようになります 環境を事前にマッピングし 必要なアンカーがある場合は― 優れたMultiuser AR体験を提供できます しかしARKitが後から集めた 新しい情報は共有されません

例えばユーザの１人が テーブルの片側を調べてアンカーを置き もう１人が同様にしたとします これらの新しい情報は 全ユーザには見えません マッピング済みのエリアから先の 未知の環境では 最適化されていない 一時的な共有AR体験です それをCollaborative Sessionで 解決します

Collaborative Sessionはライブの Multiuser AR体験用に設計されました 集めたマップ情報とアンカーは セッション中すべて共有されます どのユーザがいつアンカーを 追加しても画面に反映されます マップを探索する全ユーザにとって― 一貫したトラッキング体験ができて お互いのためになります 未知の環境にも向いています マップがなくてもこの機能は使えます またこの機能は分散型設計でP2Pの コミュニケーションパターンを使います MultipeerConnectivityに似ています そのためセッション内に ホストは存在しません 他のユーザのAR体験を 邪魔することなく― どのユーザも好きな時に セッションに出入りできます 例を見てみましょう

２人のユーザが Collaborative Sessionをしています それぞれAR体験を始めます まず２人とも少し探索し ARAnchorを設置しました 探索を続け 他のユーザが探索したエリアに来ると 他者が追加したアンカーが見えます 左のユーザは黄色のキューブ 右のユーザは紫のキューブが見えます 追加したアンカーは 瞬時に他のユーザの画面にも現れます ライブで共有されるので ユーザのAR体験は邪魔されません 既存のMultiuser ARアプリケーションの 多くはホストユーザが必要ですが Collaborative Sessionなら 分散型のMultiuser AR アプリケーションを作ることもできます 次にこの分散型設計をさらに掘り下げ 現行システムに どう影響するのかを見ましょう

この分散型設計では セッション内にホストユーザがいません つまり各ユーザは互いに認識する前に それぞれAR体験を始められます ユーザは各自で ARワールド座標を持つことができます この例では ２人のユーザが Collaborative Session中です 各ユーザが探索し それぞれ テーブルの端にアンカーを置きます するとCollaborative Session内で ARKitがARWorldMap情報の一部 Collaboration Dataを 他のユーザに送信し 外部マップとして保存します ユーザが探索を進め 他のユーザが見たエリアに来ました ARKitはエリアの3Dランドマークを使い 外部マップで自身の位置を特定します それに成功すると 外部マップが 各ユーザのローカル座標と統合されます この時点では 各ユーザのワールド座標は別々です しかしARAnchorが マップに付いているため― ユーザは仮想オブジェクトを 正しい位置に見ることができます だからCollaborative Sessionでは ARAnchorが重要になるのです ではARKit 3での Collaborative Sessionの― 使い方を見てみましょう

Collaborative Sessionを使うには― まず全ユーザが 同じネットワーク層にいるか確認します ネットワーク層は MultipeerConnectivityでも― 他の信頼できる ソリューションでも構いません 同じネットワーク層に入れば 互いに情報を送信できます 次に自身のARセッションで Collaborationを有効にします 有効にすればARセッションが定期的に Collaboration Dataを生成します それをアプリケーションが 他のユーザに送信します

ARKit 3でCollaborative Sessionを 使うのに必要な 新しいコードはそれだけです 見てみましょう

まずARWorld TrackingConfigurationを作ります 次にisCollaborationEnabledを trueに設定します そしてsession.runで ARセッションを実行します RealityKitを使っているなら 新しく必要なコードはこれだけです RealityKitを使っていないなら Collaboration Dataを送信するために デリゲート関数を２つ追加します １つ目はARSession, didOutputCollaborationDataです Collaboration Dataは生成後 全ユーザに送信しなくてはなりません ここではMultipeerConnectivityを 使った例です あなたのネットワークが 送信に失敗と応答したら― アプリケーション側で もう１度送信し データを届けなくてはいけません

データを受け取ったら デリゲート関数arSession.updateを呼び そのデータをARセッションに渡します この２つのデリゲート関数で Collaboration Dataを 送信するフローができます

Collaboration Dataの送信が 設定できれば― 送信はセッションを通じて行われます 各ユーザは 先ほどのようにAR体験を始められます

先述のように― 共有AR体験はユーザが相手のマップで 自身の位置を特定できれば始まります そうすると あなたのARセッションが 他者が追加したARAnchorを受信し― それが共有AR体験の始まりを示します Collaborative SessionでのARAnchorの 新しいプロパティを見てみましょう

Collaborative Sessionでは ユーザが作ったARAnchorの ライフサイクルが同期されます 誰かがアンカーの追加や削除をすれば それがすぐ全ユーザに反映されます また各ARAnchorに セッションIDを追加し あなたのアプリケーションが 正しく対応できるように ARAnchorを作ったのが 誰かを示します 最後に 共有されるのは ユーザが作ったARAnchorだけです サブクラスのARAnchorは除外されます ARImageAnchor ARPlaneAnchor ARObjectAnchorなどです ユーザの サブクラスARAnchorも除外されます Map Save and Loadでユーザデータを アタッチするのに使われたものです 最初はこれがCollaborative Sessionの 難点だと思うかもしれません でもご安心を ここでCollaborative Sessionと RealityKitがうまく連携します RealityKitを使えばユーザデータを Entity-Componentにアタッチできます user entityを 対応するARAnchorにアタッチすれば 情報が同期されます 物理シミュレーションや シーンチェンジやSEも含みます 詳細は火曜の“Introducing RealityKit and Reality Composer”でご確認を

ではCollaborative Sessionで ARAnchorを使うためのコードを 見ていきましょう

Collaborative Sessionで didAdd anchorsデリゲート関数を 受け取ったら セッションIDを確認しましょう アンカーを誰が追加したか分かります didRemove anchorsでも同様に 誰が削除したか確認して アプリケーションが 適切に対処するようにしましょう 仮想オブジェクトの3D座標システムを 示すARAnchorについては以上です ただCollaborative Sessionでは 他のユーザの位置を知ることも重要です そこで新たなアンカーを紹介します ARParticipantAnchorです

あなたのワールド座標で 他のユーザの位置を示すものです フレームレートは高く 他のユーザの ARフレームレートも同様です ARParticipantAnchorは 他のユーザのマップで自身を特定後― あなたのARセッションで 自動生成されます ARParticipantAnchorも― 共有AR体験の始まりを示します ARAnchorと ARParticipantAnchorを使えば― あなたのワールド座標で他のユーザの 3Dコンテンツを正しく表示できます

以上がARKit 3での Collaborative Sessionの使い方です ではCollaborative Sessionを使った 共有AR体験の始め方を説明します

先述のように― 共有AR体験はユーザが他のユーザの マップで自身を特定すると始まります 他のユーザが見たエリアが 見えなくてはなりません ユーザの動作によっては 時間がかかります より早く共有体験をさせるため ２つ助言があります まず同じカメラ視点を持つために ユーザが他のユーザに近づくことです 例えばこの場合 ユーザ２人が テーブルを交差して見ています これだとARKitが共有体験を始めるのに 自身を特定しづらいです しかし２人が 並んで同じ方向を見ていれば― ARKitが自身を特定し 共有AR体験を始めやすいでしょう 次に この間 片方のユーザは― マップトラッキング状態に しておくといいでしょう ARFrame.World MappingStatus.mappedです これによりそのユーザは― ARWorldMap内に保存された 3Dランドマークを見ることになります これで他のユーザが接近すれば 3Dランドマークを使って自身を特定し 共有AR体験を始めやすくなります 例を見てみましょう

２人のユーザが Collaborative Sessionをしています 最初のユーザが探索し ARAnchorを追加し― マップトラッキング状態でいます もう１人が接近し同じ方向を向くと― 同じARAnchorが見えます 共有AR体験の始まりを示します

これは去年の Map Save and Loadにも言えます この助言を アプリケーションに適用して― ユーザに動作を推奨し より早く共有AR体験を始めましょう

以上がCollaborative Sessionの紹介と お勧めです 我々のAPIはシンプルで直感的です RealityKitで 数行加えるだけで体験できます ぜひARKit 3で新しい Multiuser AR体験を試してください 次にARAnchorを使った ベストプラクティスを紹介します

先述のように― ARAnchorはCollaborative Sessionで 仮想コンテンツを共有する主要方法です ARAnchorの使い方で シンプルかつ 有効なお勧めを３つ紹介します まずARWorldMapに戻りましょう

先述のようにARWorldMapは いくつかの3Dランドマークと― ARAnchorのリストから成ります さらに Camera posesも保存されます これは3Dランドマークを 最初に観測した時のカメラビューです この例ではCamera Posesが５つ 3Dランドマークが最初に作られた時に 生成されます このカメラビューで― 3Dランドマークをグループに分け マップを分けることができます

ビューがあれば ユーザがARAnchorを１つ追加すると ユーザはこのARAnchorの Global positionを提供します しかし実際に ARWorldMapに保存されるのは― このARAnchorの ビューに対する相対位置です この相対位置を ARWorldMapで保存し― Collaborative Sessionで送信します 各ユーザが 異なるワールド座標を持っていても― 正しい位置に ARAnchorを見ることができます だからCollaborative Sessionで ARAnchorを使うことは重要です これを念頭に ベストプラクティスを見てみましょう

まず常にARAnchorのアップデートに 対応しましょう ARKitはマップ探索が進むと― Camera posesの位置を微調整し 3Dランドマークの位置を最適化します そうすると ビューにアタッチされた ARAnchorの位置も変わります アップデート関数に対応し― 仮想オブジェクトの位置を変えましょう 次に― 仮想オブジェクトはARAnchorの 遠くではなく近くに置くのが一番です 理由は先ほどと同じです アンカーがアップデートされた時 仮想オブジェクトが遠いと― 仮想オブジェクトに 望まない大幅な アップデートが行われるかもしれません だからARAnchorの近くに置きましょう トラッキング品質が上がります 最後に 複数の 仮想オブジェクトがある場合― ARAnchorも 複数使うことをお勧めします マップの異なる場所にアタッチさせ 仮想オブジェクトと 対応するARAnchorの距離を短くします しかし複数の仮想オブジェクト間の 相対距離を保ちたい場合は― １つのARAnchorに すべてアタッチさせるのがいいでしょう ARAnchorから遠くない場合に限ります

以上がARAnchorを使う上での ベストプラクティスです これに従えば最高のトラッキング品質を アプリケーションに活用できます

次はデヴィッドから SwiftStrikeの話です (拍手) ありがとう

こんにちは　デヴィッドです SwiftStrikeを紹介します WWDC 2019で披露するため開発した 新しいマルチプレーヤーAR体験です 去年のSwiftShotを参考に― RealityKitとARKit 3を活用して 新たな体験を届けたいと思いました 今はテーブルトップバージョンが 入手可能で 現在フルバージョンのリリースに向け 頑張っています 興味があれば ぜひ去年のSwiftShotのセッションを 今日の話でも SwiftShotとの比較が出てくるので 見てみてください

SwiftStrikeを作る上で 考えるべきものは多いです サウンドデザイン アセットデザイン アニメーションなど さまざまです 今回は３つに注目します 共有体験を実行するための RealityKitのネットワーク機能 ゲームを楽しむための 物理シミュレーション それからRealityKitとARKit 3の― 新しい機能を生かした設計について 少しお話しします

まずネットワーク機能について これはRealityKitのEntity-Component architectureに基づいています コンポーネントの追加や変更は 自動的にネットワークで同期されます 物理ステータスもです コードを書く必要はありません 自分のアプリケーションや ゲーム用に― カスタムコンポーネントを定義できます これも自動で同期されます ネットワーク層は MultipeerConnectivity どのiOSやmacOSデバイスにも 組み込まれていて簡単に設定できます ネットワークセッションを作り ARビューオブジェクトに渡せば― あとはやってくれます クエン･ハンが話した― collaborative mapping dataの 移動も含みます

MultipeerConnectivityやRealityKitは ホストがないP2Pシステムです しかしSwiftStrikeでは― １つのデバイスを ホストに定義するのが有効でした ゲームの状況や 物理ステータスを把握するデバイスです 他のデバイスはインプットを提供し― ホストから必要な情報を受け取ります

カスタムコンポーネントですが 設定は簡単です 構造体を定義します ARビューのインスタンスを作成する前に コンポーネントを登録し― Codableのプロトコルを実行します これで必要な情報が提供でき― 構造体がシリアル化され ネットワークに送信されます

ゲームでどう使うか見せましょう

ゲーム開始時に 両プレーヤーがスタート地点にいること これがSwiftStrikeでは重要です 一方のプレーヤーが ボールの近くにいると有利だからです match objectは― プレーヤーがスタート地点にいるか 把握し ボールを出すか判断します 状態はクライアントに同期され― UIKitを通じて プレーヤーに立ち位置を指示できます コンポーネントには 状態のログも保存されます 各クライアントが 状態を把握するのを助けます

例を見てみましょう プレーヤーが位置につくまで待ちます 位置についたら ボールが現れゲームが始まります

これがコードです まずは定義するコンポーネント MatchStateComponentです

RealityKitの コンポーネントプロトコルと Codableのプロトコルに従います

トランジションを定義します 各デバイスに match stateのログが渡るので 適切に応答できます

始める前に 同期するための準備として― コンポーネントを登録します これで― ホスト上でのコンポーネントの変更が 自動的にクライアントと同期されます

クライアントはそれを使って― MatchObserverオブジェクトを 作成します コンポーネントの変更を監視し― それを関連するパーティに送信します これには複合フレームワークを使います デリゲートの代替に便利で フレキシビリティが高まります 今年の複合セッションを参照ください

SwiftStrikeの多くのコードは SwiftShotから来ています 去年のセッションでかなり話しました 物理データの同期　エンコード そして圧縮などの方法についてです こちらはそれを実行するための クラスやタイプのリストです でも今回はRealityKitが 物理の同期をしてくれます カスタムコンポーネントで ゲーム状況も同期できます なので削除しました もう必要ありません 残されたものを見ると― これらはcollaborative mappingか ワールドマップ共有かを選ぶだけ 設定は１度です だからエンコードも不要です 残念ながら BitStreamコードは削除しました

これでざっと 1500行のコードを削除できました RealityKitの ネットワーク機能のおかげで皆さんも これらのコードを書かずに済みます (拍手)

物理シミュレーションの話をしましょう 同期はRealityKitが 内蔵の物理エンジンを使って行います コンポーネントの設定で 物理プロパティを構成できます Rigid bodiesはオブジェクトの形を 定義します Collision maskは― オブジェクトが他のどのオブジェクトと 衝突するか設定します そしてオブジェクトの物理プロパティ 質量　摩擦　回復 最高の体験になるよう適切に設定します

ホストデバイスが シミュレーションを所有し クライアントが 各プレーヤーの位置情報を提供します 後で説明します

オブジェクトは単純です ボールは球体で― プレイエリアの表面は平面です ボールが飛び出ないよう 側面に壁があります ただ１つだけ 少し複雑なオブジェクトがあります ボウリングのピンです

面白くするには ピンの挙動と音が重要になります これは我々のテクニカルアーティストが 作った3Dモデルのワイヤフレームです レンダリングするには 適切なデータですが― 物理シミュレーションにとっては データが多いです もっとシンプルにしつつ― ボウリングのピンらしさを維持したい

そこでこうしました 上部と中央にRealityKit physicsの プリミティブの球体を配置し ピンの周囲には凸包を作りました ピンが立ち 衝突時に跳ね返るようにです 物理シミュレーションには なるべくプリミティブを使います 無理なら凸包が簡単でしょう 一番 効果的です 時間をかけて最適な形にしました

こちらが最終的なデータです コート上では― きれいなピンが表示されます RealityKitのレンダリングにより きれいな輝きに いい感じですね ありがとうございます (拍手)

最後にゲームデザインの話です ３つあります People Occlusionのデザイン オンサイト体験の作り方 ゲームの制御メカニズムの定義です

People Occlusionの話を聞き― 今年のゲームは フルサイズの体験に決めました まず最初にPeople Occlusionが 見えるようにデザインしました スタート位置ではボールが前にあり― 対戦相手がいて その後ろにピンが見えます まずオクルージョンを体験できます これまでのAR体験では― カメラとコンテンツの間に 人を置かないことが重要でした だからSwiftShotは テーブルトップゲームでした People Occlusionのおかげで― ゲームでの仮想コンテンツの使い方も 可能性が広がります

フルサイズでやるには場所が必要です そこでコンベンションセンターに― 施設チームと協力し ゲーム用のフロアを用意しました 木目はボウリング場を思わせますし― トラッキングの特徴点も提供します ディスプレイも安定します

また コート中央のロゴを使い― ゲームボードを正しく配置します ARKitImageAnchorを使って 位置を探し― 始めるたびに 正しく位置取りできるようにします ARの位置特定には― ARWorldMapと Collaboration Dataの両方を使います プレーヤーはデバイスのマップを ロードして迅速に位置を特定します その後 Collaboration Dataを 共有し始めます 素早く立ち上げた後― データを共有し そのままワールドを維持できるのです

最後に制御メカニズムについて SwiftShotでも 単純な制御メカニズムでした タップするとつかみ 引くと放します さらに簡単にしました 画面に触れず 動かせばボールを押せます テストプレイで分かったのは― より速く押すとより強くボールが飛べば 素晴らしいということです ボールが飛び跳ねていくように

他に分かったのは たまにボールが人を通過することです これはよくありません そこでプレーヤーの位置に 透明の物理的ボディを追加しました 走り回れば ピンを倒せてしまうことも分かりました そこでCollision maskで フィルターしました ボールは ピンやプレーヤーと衝突しますが ピンとプレーヤーは衝突しません ネットワークシステムと 物理情報を使って最高の体験にしました

次の問題は動き回るデバイスから どうやってインプットを受け取り いつパドルをアクティブにするか― ホストに加える力を どう制御するかでした これはRealityKit内の Ownershipサポートで解決しました

ホストがARセッションを始めると AnchorEntityを作成します RealityKit内のコンテンツは すべてAnchorEntityが親であり ホストが所有しています クライアントが加わると 別のエンティティが追加されます PlayerLocationEntityです RealityKitのサブクラスサポートを 使用します これはクライアントが所有し 位置のアップデートが可能になります AnchorEntityを親にすれば 他のデバイスに送信されます さらにPaddleEntityを追加します PlayerLocationEntityを親にします プレーヤーが動くとPlayerLocation Entityがアップデートされ― PaddleEntityが動きます ホストはPaddleEntityの アクションを制御できます オンオフを制御し― 楽しいゲームを維持します

これらにより 最終的にできたものを見ましょう 最高のゲームプレイ体験の完成です

これは月曜の“Platforms State of the Union”の動画の一部です

みんなでプレイを アダムが勝ちました

開発中に 今年 他にどんなものが出るのか― 情報がいろいろ入ってきました その１つがiOSのダークモードです 我々も負けないように― Cosmic Modeを実装しました アセットを替え ビデオフィードを暗くし― カードを使い 光る感じを出しました 見てみましょう

いかがです？

１発で勝つのに何度か かかりました (拍手)

以上がSwiftStrikeです おさらいをしましょう ARKit 3のCollaborative Sessionを 使えば位置特定が楽になり― 新たな共有体験が可能になります ARAnchorを使い コンテンツを配置する最適な方法 そして新しいゲーム SwiftStrikeを紹介しました Reality Composerを使って作った― テーブルトップバージョンが 入手可能です “Building AR Experiences with Reality Composer”セッションで詳細を そしてこの先 フルバージョンをリリースする予定です

詳しくはセッションのサイトへ クエン･ハンと私は ARKit and RealityKitラボにも出ます SwiftStrikeが得意な人は― 金曜に12時半から大会があります ぜひ参加してください ありがとうございました (拍手)