Oculus Unity Integrationクロスプラットフォーム開発ドキュメンテーション 私家訳版


この記事はOculus Rift Advent Calendar 2018の4日目です。

はじめに

先日11月15日、Oculus SDKの一部であり、Oculus公式のUnity統合であるOculus Integration (Oculus Utilities for Unity)の最新版1.31が公開されました。このバージョンの大きな新機能が、Oculus Integrationを使ったままHTC Viveの動作がサポートされる、クロスプラットフォーム開発機能です。

以前からSteamVR SDKはViveにネイティブ対応しているのに加えRiftをサポートしていましたが、今回の対応により、Oculus側のSDKを使用した場合も、両方のヘッドセットに向けた開発が(少なくともUnityにおいては)可能になります。

前述の通りSteamVR SDKはViveとRift両方に対応していますが、問題なのが、SteamVR SDKを使用した場合はそのままではOculus Storeへの提出ができないという点です(その逆、つまり今回のOculus SDKのクロスプラットフォーム機能を使って実装したアプリをSteamに出すのは問題ないはず)。また、注目度の高いOculus Goや今後登場するOculus QuestはOculus SDKでしか動作しないため、これらにも対応したい場合いずれにしてもOculus SDKを避けて通ることはできません。もちろん、移植は色々な要素が絡むため、こういった機能があってもボタン一発とまではいきません。しかし、なるべく同じ機能の再実装を避けながら、PC・スタンドアローンを含む多くのプラットフォームに対応するという点においては、本機能は便利に使えるのではないでしょうか。

以下はOculusデベロッパードキュメンテーションのクロスプラットフォーム開発についてのページの私家版翻訳となります。


Unityでのクロスプラットフォーム開発について

※クロスプラットフォーム開発は現在試験的機能です。機能は変更または削除される場合があります。

開発者が複数のプラットフォームやデバイスをターゲットしたい場合、Oculus Integration (Oculus Utilities for Unity)を使ってOpenVR向けのビルドを作成する事ができます。本記事では、クロスプラットフォーム開発で使用できるAPIについて、また通常のOculus向け開発と異なる点について解説します。APIの通常の使用方法や開発プロセスについてはドキュメンテーションの別ページで解説されていますので、本記事ではカバーしません。

開発者はクロスプラットフォーム開発機能を使うことで、OculusまたはSteamVRプラットフォームに向けて、追加工数を最低限に抑えながらそのまま動作するアプリを開発することができます。クロスプラットフォーム機能は、入力周りでは、6自由度のヘッドマウントディスプレイとコントローラー、即ちOculus Rift+Touchや、HTC Viveとそのコントローラーに対応しています。現時点では、この2つのみがサポートされています。

カメラ – OVRCameraRig

基本的にはOculus Utilities for Unityガイドに書かれた手順通りに進めます。既存のアプリをアップデートする場合、OpenVR HMDおよびそのコントローラーをトラッキングするには、既にあるカメラを削除し、改めてOVRCameraRigのPrefabをシーンにドラッグして入れる必要があります。

OVRCameraRig Prefabをシーンに入れる際、Tracking Originは必ずFloorLevelに設定してください。クロスプラットフォーム開発時は、EyeLevelはサポートされていません。

クロスプラットフォーム開発時は、コントローラーの動きに追随するオブジェクトはLControllerAnchorまたはRControllerAnchorの子になっている必要があります。

HMDトラッキング – OVRDisplay

以下のAPIで、トラッキング空間内でのHMDの加速度を取得することができます。これらのAPIはクロスプラットフォーム開発に対応しています。

  • OVRDisplay.velocity()
  • OVRDisplay.angularvelocity()

入力 – OVRInput

Oculusコントローラー使用時の使用方法はOVRInputのガイドページをご覧ください。クロスプラットフォーム開発時には、以下のAPIを使うことができます。

個別のボタン

以下のボタンは、Get(), GetUp(), GetDown()に対応しています。Get()はボタンの入力状態(押されていればtrue)、GetUp()はそのフレームにボタンが離されたかどうか(離されていればtrue)、GetDown()はそのフレームにボタンが押されたかどうか(押されていればtrue)を調べます。OculusコントローラーのマッピングについてはOVRInputページをご覧ください。

  • Button.PrimaryIndexTrigger
  • Button.SecondaryIndexTrigger
  • Button.PrimaryHandTrigger
  • Button.SecondaryHandTrigger
  • Button.PrimaryThumbstick
  • Button.SecondaryThumbstick
  • Button.Two
  • Button.Four
  • Axis1D.PrimaryIndexTrigger
  • Axis1D.PrimaryHandTrigger
  • Axis1D.SecondaryIndexTrigger
  • Axis1D.SecondaryHandTrigger
  • Axis2D.PrimaryThumbstick
  • Axis2D.SecondaryThumbstick

既存アプリとの下位互換性維持のため、これらのAPIのなかではOculus TouchとViveコントローラーの両方が“Touch”として扱われます。左のXRコントローラーはLTouch、右はRTouchとなります。

ボタンや各種入力の状態は、以下のいずれかに対して求めることができます。

  • Controller.LTouch
  • Controller.RTouch
  • Controller.Touch

[訳注: 上記API群は、原則的に(取得したいボタン名, 問い合わせたいコントローラー名)という引数の構造を持っています。OVRInputで指定できるボタン名には“Primary” “Secondary”という指定があり、左手か右手どちらに対する問い合わせなのかを明示的に指定せずにPrimaryボタンの状態を取得した場合、「左手コントローラーが有効であれば左手側についている方、無ければ右手側の方」に問い合わせる挙動となります。細かい対応関係一覧はOVRInput内のButton enumを確認してください。次の段落はこれを踏まえています]

クロスプラットフォーム開発でOVRInputを使う場合、第二引数で問い合わせ先のコントローラーを明示的に指定したうえで、第一引数でPrimaryのボタンを指定する事をお勧めします。第二引数のコントローラーの左右の指定は必須ではありませんが、多くの場合指定しておいた方が簡単になります。以下にいくつか例を示します。

  • OVRInput.Get(Button.PrimaryHandTrigger, Controller.LTouch) – 左手のXRコントローラーの「グリップ」トリガーまたはボタンが握り締められている間trueを返します。
  • OVRInput.GetDown(Button.Two, Controller.LTouch) – 左手のXRコントローラーの「上の方のボタン」が現フレームで押し込まれた場合trueを返します。これはOculus Touchの場合はYボタン、Viveコントローラーの場合は横棒が3つ入ったメニューボタンとなります。
  • OVRInput.Get(Axis1D.PrimaryIndexTrigger. Controller.RTouch) – 右手のXRコントローラーの人差し指トリガーが押し込まれている度合いを0.0-1.0の間で返します。

コントローラーの姿勢と加速度

以下のAPIでトラッキング空間内でのコントローラーの姿勢および加速度を取得することができます。これらのAPIはクロスプラットフォーム開発に対応しています。

  • GetLocalControllerPosition()
  • GetLocalControllerRotation()
  • GetLocalControllerVelocity()
  • GetLocalControllerAngularVelocity()

対応OpenVRコントローラーのボタンマッピング

HTC Viveコントローラーは、上記で紹介したOVRInputの各種APIにおいては、以下のボタン名に対応する形で扱われます。

  • Button.Two – メニューボタン
  • Axis2D.PrimaryThumbstick – 静電容量式トラックパッド
  • Button.PrimaryThumbstick – トラックパッドの押し込み
  • Axis1D.PrimaryIndexTrigger – トリガー
  • Axis1D.PrimaryHandTrigger – コントローラー側面のグリップボタン

ハプティクス(振動) – SetControllerVibration()

クロスプラットフォームでのコントローラーを振動させる場合は、SetControllerVibration APIを使用してください。OVRHapticsおよびOVRHapticsClip APIはクロスプラットフォーム開発に対応していません。
本APIの使用方法については、OVRInputガイドをご覧ください。クロスプラットフォーム開発デバイスの場合は、第一引数の周波数は1.0で固定、第二引数の振幅は0.0-1.0の範囲で指定する事が可能です。以下に例を示します。

  • OVRInput.SetControllerVibration(1.0f, 0.5f, Controller.RTouch) – ピーク振幅の半分で、右のXRコントローラーを振動させます。この振動は、新たに振動が指定されるか、0を指定されて停止するかするまで続きます。また、新たに振動を指定せずに2秒経過した場合はタイムアウトで自動的に停止します。
  • OVRInput.SetControllerVibration(1.0f, 0.0f, Controller.RTouch) – 右のXRコントローラーの振動を停止します。

境界線・プレイエリア – OVRBoundary

OVRBoundaryを使用する事で、ユーザーのプレイエリア情報を取得・設定する事ができます。詳しくはOVRBoundaryガイドをご覧ください。以下のAPIがクロスプラットフォーム開発に対応しています。

  • GetDimensions()
  • GetGeometry()
  • SetVisible()
  • GetVisible()
  • GetConfigured()

GetGeometry()は実行時に小規模なガベージコレクション割り当てが発生するため、毎フレーム実行するのではなく、一回実行して取得したものをキャッシュしてください。

クロスプラットフォームアバター

Unityにおいて、Oculusアバターはクロスプラットフォーム開発に対応しています。クロスプラットフォームでのアバター使用について詳しくは、Unityクロスプラットフォームアバターサンプルシーンの解説ページをご覧ください。

Oculus Rift/Gear VRアプリでローディング画面の視界端に見える黒枠を別の色にする


Oculus RiftやGear VRのVRアプリにおいて、ローディング画面などでレンダリングがリフレッシュレートに間に合わず、Asynchronous Timewarp (ATW)処理で擬似的に生成されたフレームが表示されることがあります。このような時、ATWが前の絵の位置をずらしているため、ずれた分だけ表示領域の端に黒い枠が見えてきます。

現状こちらの色を一発で変更する方法はないのですが、Compositor Layerという機能を応用することで色を変えることが可能です。Oculus Utilities for UnityではOVROverlayというコンポーネント名、Unreal EngineではStereo Layersという名前で組み込まれています。

「Compositor Layer (Timewarp Layer)」はOculus SDKに内蔵されている、一部のオブジェクトを通常のレンダリングと別枠で、出力直前に合成して表示することができる機能です。Compositor Layerを使って表示できるものは板ポリゴン(Quad)やキューブマップ、円筒など形状が限定されます1が、レンダリングのフレームレートではなくコンポジターのフレームレートで動作するため、通常のレンダリングが間に合っていない時であっても常時滑らかに表示されます。(名前が似ていますが、Unityのレイヤー機能とは無関係です。)

例えばUnityでは以下のように:

  • Main Cameraの子としてQuadオブジェクトを作成(位置は0,0,0
  • Quadオブジェクトのマテリアルとして白一色の画像テクスチャ(ここではwhitesquare)を貼り付けたマテリアルを指定
  • QuadオブジェクトにOVROverlayコンポーネントを貼り付ける
  • OVROverlayCurrent Overlay TypeUnderlayCurrent Overlay ShapeQuadに指定。これにより、通常のレンダリングが行われていない(はみ出した)領域にのみ、このQuadが表示されます。
  • OVROverlayの中にあるTextures変数に先程と同じ白一色のテクスチャを2箇所とも指定する

こうすると、ATWで生成されたフレームが見えている間も、普段ならはみ出して黒い背景が表示されている部分に白いQuadが表示されるため、背景の色が白に見えるようになります。2
なお、挙動の確認のためにわざとレンダリングの処理落ちを起こすには、Update()内にSystem.Threading.Thread.Sleep(500);などを入れたコンポーネントをどこかに貼っておくと起こせます。

このほか、Compositor Layerは処理落ち中でもガタつかない注視カーソルの実装や、画質が高いことを活かしたUI/テキスト/画像などの表示、またそもそもローディング画面自体をCompositor Layerで作るといった使い方もできます。Compositor Layerについてより詳しくはこちら。

Unity: https://developer.oculus.com/documentation/unity/latest/concepts/unity-ovroverlay/
Unreal: https://developer.oculus.com/documentation/unreal/latest/concepts/unreal-overlay/


  1. 使える形状はPCとモバイルで多少異なります。QuadやCubemapは両方で利用可。 
  2. ただし、白色は人によってはチラツキを視認しやすくなるためお勧めしません。実際に変える場合は暗めの色をお勧めします。 

Oculus RiftとLiveViewRiftで全方位パノラマを再生する


2016/10追記: LiveViewRiftは現在更新されないまま大分古くなっており、現在のRift製品版やOculus Softwareに追随できていません。現在は全天球動画などを再生する場合、他のソフトの使用をお勧めします。

最近見つけたLiveViewRiftというソフトが非常に強力だったので紹介したいと思います。

LiveViewRiftはMac/Windows用の、Oculus Riftを使って動画や静止画、全方位・全天球映像等の再生ができるソフトです。

こういったソフトは他にも

等いくつかありますが、LiveViewRiftは非常に設定項目が柔軟で、およそどんな形式でデータが作られていても調整次第で表示が可能である点が大きな特徴です。RICOH THETA等で撮影された全天球画像はもちろんの事、例えば立体視でデータが左目と右目のファイルに分かれている場合や、パノラマが床・空・それ以外のファイルに分かれている場合であっても、複数のファイルをレイヤーとして同時に表示再生する事ができるので対応可能です。

なお、このソフトは現在Oculus RuntimeのExtendモードにのみ対応しています。Windowsの場合、Open Broadcaster Software等を併用しないと表示内容のミラーリングが出来ないので、ご注意ください。

スマホ差込形HMD Durovis Diveを使う


はじめに

ここのところは相変わらずOculus RiftをはじめとしたVRヘッドマウントディスプレイにご執心な日々ですが、最近はOculusに加えてDurovis Diveにも手を出しました。

Oculus Riftに見た目も構造も似ていますが、開発元が異なる別のHMDです。正確には、この枠の中にスマートフォンを差し込むことでHMDとして機能するようになるマウントパーツということになります。

マウント部を開いたDurovis Dive

マウント部を開いてスマホを外すとこんな感じ。

Oculus RiftとDurovis Dive

左がOculus Rift、右がDurovis Dive

利点と欠点

Oculus Riftを開発したPalmer Luckeyは、かつてFOV2GOというスマートフォンを活用したHMDの研究プロジェクトに関わっていました。その後彼は専用ハードを作る方向に転じ、掲示板などでもスマホの性能の限界を指摘していることからも、体験のクオリティを重視するのであればそれに合わせた専用のハードウェアを作らなければならないという意見のようです。

確かに、Durovis DiveはOculus Riftに比べて

  • 視野が80〜90度程度とやや狭い
  • 次期Oculus Riftの売りであるポジショントラッキングやLow Persistenceモードの搭載は望めない
  • 加速度計やジャイロのトラッキング頻度・精度は低い1
  • 実行環境がモバイルアプリなので、リッチな表現はできない
  • 本体がそのまま頭の前に来るので、首の向き以外での操作ができない

といった欠点があり、基本的にRiftよりも体験の質は劣ります。とはいえ、このアプローチはOculus Riftに勝る点もいくつかあります:

  • PCやケーブルいらずで単体稼働できる
  • スマホ次第で高解像度な画面が使える
  • 実行環境がモバイルアプリなので、Unity3D Free版でも開発できる2
  • なにより既にスマホを持っていればそのまま使えるので安い

特に最後の2点は重要です。実際、Oculus Rift本体やらゲーミングPCやらUnity Proやら3DCGソフトやらで、出費がとんでもない事になってる人を知っています。w
極端な話、Durovisを買わなくとも、FOV2GO方式のレンズとボール紙の即席HMD + Unity Freeで超低コストに最低限の開発スタートが可能です。


  1. iPhone 5Sでも加速度センサの更新頻度は秒間100回程度ですが、頭の動きに低遅延で追随することにこだわったOculus Riftのセンサ更新頻度は秒間1000回と桁違いの高さです。 

  2. Oculus Riftの場合はPCから外部ハードウェアに直接アクセスすることになるため、Unity Pro版ライセンスが必要です。 

VRネトゲの作り方:Mikulus Kinect OnlineにおけるPhoton Cloudの活用


この記事はOculus Rift Advent Calendarの4日目です。

はじめに

こんにちは。Oculus Rift Advent Calendar 12/4担当のNeedleです。

先日11/9に開催された第一回Oculus Game Jamで作ったMikulus Kinect Onlineの、特にネットワーク部分について書こうと思います。

Mikulus Kinect Onlineとはこんなソフトです。


なお現在、第五回ニコニコ学会β 研究してみたマッドネスセッションの投票受付中です。投票は本日12/4 23:59までですので、もし良ければこちらのページから投票をよろしくお願いいたします!

Mikulus Kinectとは

Mikulus Kinect Onlineの話の前に、まずその元となったMikulus Kinectについて説明します。

Mikulus Kinect

Mikulus Kinectは、Oculus RiftとKinectとUnity3Dを組み合わせて、プレイヤーが自分の手足や体がVR内で見える状態でミクさんと握手や頭を撫でるといったコミュニケーションが取れるアプリです。

Oculusを着けて最初に感じたのが頭の角度に対する映像の追随の滑らかさでしたが、一方で感じたのが、頭の位置移動が反映されないことや自分の体が見えない事による違和感でした。そのときKinect登場時に話題になったNao_uさんの動画を思い出し、自分でもやってみようと思ったのがきっかけです。「VR内でAIキャラの目を見る」という体験は、モニタ越しのゲームとは全く違ったものとして感じられました。

ここで作ったMikulus Kinectはあくまで 人←→AI というシングルプレイヤーのデモでした。これをマルチプレイヤー化し、複数の人が同じVR空間内に入れるようにしたのが、Mikulus Kinect Onlineになります。

オンライン化にするにあたっての課題

オンライン対応にはネットワークミドルウェアのPhoton Cloudを使いました。以前ワークショップで少しだけ触ったことがあったからというのもありますが、ゲームジャムの会場がPhotonを日本展開されているGMOさんのオフィス内で、中の人に質問をしやすかったからでもあります。Unity用のPhoton CloudはUnity自身の内蔵ネットワーク機能に似た形で使えるよう作られているので、そちらを使う場合も同じ手法を応用できると思います。

ここからはMikulus Kinectをオンライン化する際に直面した課題について書いていきます。

アバターキャラの出現(○○さんがログインしました)

シングルプレイのMikulus Kinectではプレイヤーが操作するアバターキャラを最初からHierarchyの中に置いていましたが、ネットワーク環境では誰かがログインする度にその人のアバターキャラを出現させる必要があるため、Hierarchyにおいておくわけにはいきません。アバターキャラのGameObjectはPrefabにして、ProjectのResources内に置いておきます。

ログイン時のコードはこんな感じです。
(アバターキャラPrefabの名前はここではMKMotionCaptureContainerとなっています)

void OnJoinedRoom(){
    // 参加者全員の世界に新規プレイヤーのアバターが出現する。
    // PhotonNetwork.InstantiateでInstantiateできるのはResourcesフォルダの中身のみ。
    // インスペクタでGameObjectメンバ変数にPrefabを割り当てて使ったりは出来ないので注意
    GameObject character = PhotonNetwork.Instantiate("MKMotionCaptureContainer",
        Vector3.zero, Quaternion.Euler(new Vector3(0,180,0)), 0);

    // こっちの内容は参加者全員ではなく自分の世界でだけ反映されるので、
    // 自分のアバターキャラにモーションキャプチャ&ヘッドトラッキングの関連付けを行う
    character.name ="MKMotionCaptureContainer(Me)";
    mocap.EngagedUsers[0] = character;
    character.GetComponent<HeadFollowsEyeSmoothed>().enabled = true;
    character.GetComponent<SetZigBias>().enabled = true;
    myPhotonView = character.GetComponent<PhotonView>();
    character.transform.parent = meObject.transform;
}

photonviewdetailモーションキャプチャ関節の共有

Photon CloudにはPhotonViewというスクリプトがあります。基本的には、ネットワーク越しにプレイヤー間で共有したいGameObjectにこのスクリプトを貼っておくことで、そのGameObjectの位置・角度・パラメータといった状態を共有できるようになります。キャラクターの動きを共有するにはこれを使います。

通常のオンラインゲームでは、一人のプレイヤーが動かせるのは基本的に自分のプレイヤーキャラ1体です。つまり一人あたりのPhotonViewは1個で十分でした。

これがMikulus Kinect Onlineにおいては話が変わります。全身の関節をKinectでキャプチャし、MMDモデルの関節に割り当てているため、位置・角度をPhotonViewで共有するのも、キャプチャしている関節全てで行わなければなりません。1

mikuwithskelparts2任意のキャラクターモデルへの対応

以上を踏まえて、単にミクのモデルだけを動かしたいのであれば、ミクモデルの各関節のGameObjectに黙々とPhotonViewを貼っていけばOKです。

しかし将来的にはKAITOやリン・レンなどアバターキャラ(モデル)の切替を可能にしたいので、決め打ち対応はなるべく避けたいところです。Kinectでキャプチャされる関節は24もあるので2 、モデルを変える度にPhotonViewを貼る作業を24回繰り返すのは生産的ではありません。一方で、モデルによっては関節の数が違い3 、24個全部を使わないこともありえます。

よって、PhotonViewの割り当ては初期化時に自動的に行えるとベストです。

PhotonViewスクリプトの自動割り当て

これらの問題を解決するため、当初は以下のような手順を考えました。

  • アバターキャラPrefabのInstantiate時にモーションキャプチャで動かせる関節GameObjectの一覧を作る
    • その関節GameObjectの配列をforeachでループし、それぞれにAddComponent()PhotonViewスクリプトを生成して貼り付ける

しかしこれだと動作しません。

調べて分かったのですが、PhotonViewスクリプトはPrefabのInstantiate時点であらかじめ共有したいGameObjectに貼られていなければならず、初期化時に生成するのでは間に合わないようでした。

しばらく悩みましたが、発想を逆転し、結果として以下の様な手順になりました。

  • Unityエディタを使い、PhotonViewが貼られた空GameObjectを24個作って入れておく
    jointphotonviews

    • アバターキャラPrefabのInstantiate時にモーションキャプチャで動かせる関節GameObjectの一覧を作る
    • その関節GameObjectの配列をforeachでループし、それぞれに先ほど作っておいたPhotonView付きGameObjectを関連付ける
    • モデルの関節数が24個未満だった場合、PhotonView付きGameObjectが関連付けられずに余るので、余った分はDestroy()して始末する

要は初期化時に生成するのがダメでも、初期化時に破壊するのはOKという性質を利用しています。

以下は該当部分のソース。

using UnityEngine;
using System;

public class NetworkPopulator : Photon.MonoBehaviour {
    public GameObject jointPhotonViewContainer;

    void Start () {
        MatchZigfuSkeletonToMMDModel zigfuMMDModel =
            GetComponent<MatchZigfuSkeletontoMmdModel>();
        if (!zigfuMMDModel) {
            Debug.LogError("No MatchZigfuSkeletonToMMDModel found");
            return;
        }
        // skelTransformsにはトラッキングが有効な関節の一覧が入っている
        Transform[] skelTransforms = zigfuMMDModel.trackedMMDBodyParts;

        MKNetworkCharacter[] jointPhotonViews =
        jointPhotonViewContainer.GetComponentsInChildren();

        foreach (ZigJointId jId in Enum.GetValues(typeof(ZigJointId))) {
            int joint = (int)jId; // 毎回キャストしないよう
            if (skelTransforms[joint]){
                // 該当関節があるならPhotonView割り当て
                jointPhotonViews[joint].transform.parent = skelTransforms[joint];
                jointPhotonViews[joint].transform.localPosition = Vector3.zero;
                jointPhotonViews[joint].SetTargetTransform();
            } else {
                // ないなら破壊
                Destroy(jointPhotonViews[joint].gameObject);
            }
        }
    }
}

その他参考資料

2013/12/4現在、Photon公式のドキュメンテーションページが落ちてるようです。
公式ではないですが、こちらのスライドがPhotonの基本概念を理解するのに役立ちそうです。

まとめ&今後の展望


こうしてなんとかゲームジャム終了までに動作する形にまとめる事ができ、その後のデモやTwitterにおいても好評を得ることが出来ました。(一緒に開発した@sinkukkuさん、ありがとうございます。)

Mikulus Kinectで実装した「VR内でAIキャラの目を見る」という体験も不思議な感覚でしたが、「VR内でネットワーク越しに他の人間の目を見る」というのは、生身の人間がアバターキャラの中にいると知っているだけに、また更に違う体験に感じられます。これについては、また別の機会に書ければと思います。

ただ、粗はまだまだ多いですし、当初やってみたかった事もできていないことは沢山あるので、今後少しずつやっていきたいところです。今後考えているところとしては

  • 新規に入ってきた人の立ち位置や向きを重ならないようにずらす
  • その為にPhoton, Kinect (Zigfu), Oculusそれぞれで向いている方角を揃える
  • モーションキャプチャの動きを記録し、後から再生できるようにする
  • 人間が動かすキャラとAIが動かすキャラを混在させる
  • MecanimのIKを活用して肘関節などの位置・角度情報の共有を省き、通信量を減らす
  • 表情制御(HMDかぶってるのにどうやって…?w)
  • 公開する!

などなど。

長いエントリに最後までお付き合いいただき、ありがとうございます。再度になりますが、現在、第五回ニコニコ学会β 研究してみたマッドネスセッションの投票受付中です。投票は本日12/4 23:59までですので、もし良ければこちらのページから投票をよろしくお願いいたします!

Oculus Rift Advent Calendar、明日は@blkcatmanさんです。


  1. 余談ですが、各関節に使うPhotonViewState Synchronizationタイプは、「頻繁に位置が変わる」「送信失敗したデータを再送する必要はない」事から、Unreliable On Changeにしておくのが良さそうです。 

  2. Kinect v2ではキャプチャされる関節数が更に増えているはずです。 

  3. シテヤンヨとかゆっくりとかMogg式ミクとか…