読者です 読者をやめる 読者になる 読者になる

野生のはてなブログ

twitterに書くには長すぎQiitaやサークルサイトに書くには雑多過ぎる話題を書いていきます

Oculus PC SDK 0.7がリリース。Windows 10の暫定サポートも追加

多少延期されつつも公開

前回の記事 

yaseino.hatenablog.com

 を書いたあと、直前になってバグが発覚したとのことでリリースが延期されてしまいましたが、日本時間の今日Oculus PC SDKの0.7がリリースされました。

developer.oculus.com

 

 

Windows 10も暫定サポート

Oculus PC SDK 0.7の主な更新点は以下の通りです。Direct Driver Modeの追加とそれによる最新ドライバの要求、Extended Modeの廃止などほぼ前回の予告通りの内容で、新しい点としてWindows 10上での動作が暫定的にサポートされたことが挙げられます。

  • Direct Driver Modeのサポート(以下の最新ドライバが必須)

Oculus 0.7 SDK Driver Support

AMD Catalyst™ Software Suite with Oculus 0.7 SDK Support

  • 0.6より前のSDKで開発されたアプリは0.7ランタイムで動作しないため、0.7 SDKでの再ビルドが必須
  • Windows 10を暫定サポート。Direct Driver Modeと推奨ドライバでの動作が必要
  • Extended Modeを廃止。ユーザーがOculus Riftを外部モニターとして管理する必要はもうありません。これにより0.6より前のSDKで作られたゲームに影響があります
  • Extendedの廃止によりモニタを使わずOculus Riftのみを使うスタンドアローン動作はもうできません
  • 32bit Windowsではランタイムが動作しません。64bit Windowsが必須となります。32bit アプリケーションはまだ動作します。

 

APIの変更点

0.7 SDKではC++ APIもほぼ一新されました。主なもののみを挙げますが、0.7が1.0リリースに向けた最初のバージョンであるとの予告通りCV1やGear VRに向けた変更と整理も含まれていることが分かります。

  • ovrHmd_XXX系の関数をovr_XXXに置換。これによりモバイルとの内部的な一貫性が向上しました。
  • ovrHmdDesc::DefaultHmdCapを追加し、HMDデフォルトのCapsを取得できるようになりました。またovrHmdDesc::HmdCapsがovrHmdDesc::AvailableHmdCapsにリネームされました。
  • ovrHmdDesc::DefaultTrackingCapsを追加し、トラッカーデフォルトのCapsを取得できるようになりました。またovrHmdDesc::TrackerCapsがovrHmdDesc::AvailableTrackerCapsにリネームされました。
  • ovrHmdDesc::DisplayRefreshRateが追加されました。これにより新たに作られたHMDのリフレッシュレートを取得できます。
  • ovrHmd_Createのindexパラメータが削除されました。現在は1回の呼び出しで単一のHMDをサポートします。
  • LowPersistensとDynamicPredictionのCapsが削除され、デフォルトで有効になりました。
  • 以前からObsoleteになっていたD3D9とD3D10のRenderTypeが削除されました。
  • ovrHmd_CreateDebugが削除されました。HMD実機がひとつも無い時はRiftConfigUtilでバーチャルのHMDを有効にできます。

追記:実際に入れてみて

不運にも私が所有するGT650M搭載Macbook Proではソフトウェア環境のせいかGT650Mのせいか分かりませんがDK2に画面が表示されない症状が起きています。(GT750M搭載Macbook Proユーザーの方が正常に動いているのでOS環境が壊れているかGT650MがnVidiaから切り捨てられたのだと思います)

そのため0.7ランタイムで追加されたDirect Driver Modeの使用感の感想は後日ドライバが修正されるか新PCの購入待ちですが、0.7ランタイムで追加されたデバッグ用のバーチャルHMD機能が面白かったので紹介します。

f:id:yaseino:20150829014457p:plain

左がDK2、右がCrescent Bayのスクリーンショットです。DK2は見慣れた通り画面上下端一杯まで表示領域が描画されていますが、Crescent Bayの方は上下が圧縮され非対称となっており、視野内のオブジェクトもDK2より大き目に描画されています。DK2では描画されていても実際の目には見えない端の領域が多いため無駄があるのですが、Crescent Bayではそれが改善されています。これはDK1/DK2のように汎用パネル1枚を横2つに割って描画するのでは無く、専用設計のパネル2枚を配置していることが功を奏していると思われます。また、画像を拡大してみると分かりますが、DK2の方は照明スタンドの土台やトランプタワーなど画面端に近い部分の色がギラついています。これはレンズによって生じる色収差を補正するためのものですが、Crescent Bayのレンダリングではそれが大きく抑えられており、色収差も少ないレンズを使っていることが見て取れます。6月に発表されたOculus Rift製品版では去年9月に公開されたCrescent Bayよりも更に改良が加えられていることが予想されます。

Crescent BayとOculus Rift製品版は解像度が2160x1200と、DK2の1920x1080やGear VRの2560x1440に比べて解像度の上昇幅が控えめなためもっと高解像度の方が良いのでは?と言われがちですが、画像の通り実際の見え方を向上させる様々な工夫が加えられており、単に解像度を上げる以上に画質を向上させることを実現しています。

来月のOculus Connect 2でOculus Rift製品版とGear VR製品版の詳細が発表されると思いますが、ジョン・カーマック氏がOculus Connect 2までスマートフォンは買わないことを勧めているのを見ると、Gear VRの製品版も同じようにNote4/S6版とは比べ物にならない画質を実現するために大幅な改良を加えているのかも知れません。

 

追記2(2015/8/30)

0.6ランタイムの推奨だったnVidia350.12ドライバと、最新安定版の355.60をクリーンインストールしたところ、0.7ランタイムでも正常にDK2の画面が表示されました。やはりnVidiaの355.83ベータドライバのバグだったようです。Windows 10ではDirect Driver Modeが必須になったため355.83で不具合が出るこのPCでは動きませんでした。とりあえず次の0.7対応安定版ドライバの更新を待ち、Radeon R9 Nanoが来月発売なのでDirect Driver Modeはそちらでも試そうかと思います。