AR/VR入門書

このチュートリアルでは、GodotゲームエンジンのARとVRの世界への踏み台を提供します。

AR / VRサーバーと呼ばれる新しいアーキテクチャがGodot 3に導入されました。このアーキテクチャの上に、特定の実装がインターフェイスとして利用できます。そのほとんどはGDNativeに基づくプラグインです。このチュートリアルは、コアアーキテクチャによって抽象化されたコア要素にのみ焦点を当てています。このアーキテクチャには、VRエクスペリエンス全体を作成してさまざまなインターフェイスに展開できる十分な機能があります。ただし、多くの場合、各プラットフォームには抽象化が不可能な独自の機能がいくつかあります。このような機能は、関連するインターフェースで文書化され、この入門書の範囲外になります。

AR/VRサーバー

Godotが起動すると、使用可能な各インターフェイスがAR/VRサーバーに認識されます。 GDNativeインターフェースはシングルトンとしてセットアップされます。プロジェクトのGDNativeシングルトンのリストに追加されている限り、サーバーに認識されます。

関数 get_interfaces() を使用して使用可能なインターフェイスのリストを返すことができますが、このチュートリアルでは、例に native mobile VR interface を使用します。このインターフェイスは、電話機の3DOFセンサーを使用して向きを決定し、立体画像を画面に出力する簡単な実装です。また、Godotコアで利用可能であり、プロトタイピングやこのようなチュートリアルに最適なデスクトップ上の画面に出力できます。

インターフェイスを有効にするには、次のコードを実行します:

var arvr_interface = ARVRServer.find_interface("Native mobile")
if arvr_interface and arvr_interface.initialize():
    get_viewport().arvr = true
var arvrInterface = ARVRServer.FindInterface("Native mobile");
if (arvrInterface != null && arvrInterface.Initialize())
{
    GetViewport().Arvr = true;
}

このコードは、使用するインターフェイスを見つけて初期化し、それが成功した場合、メインビューポートをインターフェイスにバインドします。この最後のステップにより、ビューポートをインターフェイスに制御できるようになり、ビューポートでの立体視レンダリングなどが自動的に有効になります。

モバイルVRインターフェイス、およびメイン入力が画面に直接表示されるインターフェイスの場合、メインビューポートは、arvrtrue に設定されているビューポートである必要があります。ただし、外部接続デバイスでレンダリングするインターフェイスの場合、セカンダリビューポートを使用できます。後者の場合、画面に出力を表示するビューポートは、デバイス上で完全に処理された立体視出力を表示しながら、左目の歪みのないバージョンを表示します。

最後に、インターフェイスを一度だけ初期化する必要があります。シーンを切り替えてインターフェイスを再初期化すると、多くのオーバーヘッドが発生します。ヘッドセットを一時的にオフにする場合は、ビューポートを無効にするか、ビューポートで arvrfalse に設定するだけです。ただし、ほとんどのシナリオでは、VRになってからヘッドセットを無効にすることはありません。これはゲーマーを混乱させる可能性があります。

新しいAR/VRノード

GodotでARとVRをサポートするために3つの新しいノードタイプが追加され、特にAR用に1つの追加ノードタイプが追加されました。これらは:

  • ARVROrigin - 世界の原点
  • ARVRCamera - ポジショントラッキングされるカメラの特別なサブクラス
  • ARVRController - コントローラーの位置をトラッキングする新しいSpatialクラス
  • ARVRAnchor - 実世界の位置を仮想世界にマッピングするAR実装用のアンカーポイント

AR/VRが機能するには、シーンに最初の2つが存在する必要があります。このチュートリアルでは、純粋にそれらに焦点を合わせます。

ARVROrigin は重要なノードです。シーン内のどこかにこれらのうちの1つだけが必要です。このノードは、現実世界の追跡空間の中心を仮想世界の場所にマッピングします。他のすべては、この地点に関連してポジショントラッキングされます。この地点がどこにあるかは実装ごとにまったく異なりますが、このノードがどのように機能するかを理解する最良の例は、部屋の規模の場所を調べることです。デフォルトでプレイヤーの中心にポイントを調整する機能がありますが、原点はあなたがいる部屋の中心位置になります。物理的に部屋を歩き回ると、HMDの位置はこの中心位置に関連してトラッキングされ、仮想世界にそのトラッキングがミラーリングされます。

物事をシンプルに保つために、部屋を物理的に移動するとき、ARVRの原点は現在の位置にとどまり、カメラとコントローラーの位置は動きに応じて調整されます。コントローラー入力を介して、またはテレポートシステムを実装して、仮想世界を移動する場合、原点の位置を調整する必要があります。

ARVRCamera は、常にシーンの一部である必要があり、常に起点ノードの子ノードである必要がある2番目のノードです。 Godotの通常のカメラのサブクラスです。ただし、その位置は、HMDの物理的な方向と位置に基づいて各フレームで自動的に更新されます。また、HMDへのレンダリングまたは現実世界のカメラでのARオーバーレイのレンダリングに必要な精度のため、標準のカメラプロパティのほとんどは無視されます。使用されるカメラのプロパティは、ニアプレーンとファープレーンの設定のみです。 FOV、アスペクト比、投影モードはすべて無視されます。

ネイティブモバイルVRの実装では、位置の追跡は行われず、電話の向きと、ひいてはHMDのみが追跡されることに注意してください。この実装では、カメラを人工的に1.85の高さ(Y)に配置します。

結論: ARまたはVRを機能させるためのシーンの最小設定は次のようになります:

../../_images/minimum_setup.png

And that's all you need to get started with the native mobile interface. Obviously, you need to add something more into your scene, so there is something to see, but after that, you can export the game to your phone of choice, pop it into a viewer and away you go.

Official plugins and resources

As mentioned earlier, Godot does not support the various VR and AR SDKs out of the box, you need a plugin for the specific SDK you want to use. There are several official plugins available in the GodotVR Repository.

  • Godot Oculus Mobile provides support for the Oculus Go and Oculus Quest. The Quest will require additional setup documented here.
  • Godot OpenVR (not to be confused with OpenXR) supports the OpenVR SDK used by Steam.
  • Godot Oculus supports the Oculus SDK (desktop headsets only).
  • Godot OpenHMD supports OpenHMD, an open source API and drivers for headsets.
  • Godot OpenXR supports OpenXR, an open standard for VR and AR software. This plugin is early in development, only supports Linux and requires extra setup described in the repository.

These plugins can be downloaded from GitHub or the Godot Asset Library.

In addition to the plugins, there are several official demos.

考慮すべきその他のもの

この入門書では、知っておくべき重要なテーマをいくつか簡単に説明します。

The first are our units. In normal 3D games, you don't have to think a lot about units. As long as everything is at the same scale, a box sized 1 unit by 1 unit by 1 unit can be any size from a cub you can hold in your hand to something the size of a building. In AR and VR, this changes because things in your virtual world are mapped to things in the real world. If you step 1 meter forward in the real world, but you only move 1 cm forward in your virtual world, you have a problem. The same with the position of your controllers; if they don't appear in the right relative space, it breaks the immersion for the player. Most VR platforms, including our AR/VR Server, assume that 1 unit = 1 meter. The AR/VR server, however, has a property that, for convenience, is also exposed on the ARVROrigin node called world scale. For instance, setting this to a value of 10 changes our coordinate system so 10 units = 1 meter.

Performance is another thing that needs to be carefully considered. Especially VR taxes your game a lot more than most people realize. For mobile VR, you have to be extra careful here, but even for desktop games, there are three factors that make life extra difficult:

  • 2つのステレオスコピックを1つの代価でレンダリングしています。作業負荷が正確に倍増するわけではありませんが、新しいMultiView OpenGL拡張機能のサポートなど、パイプラインのことを念頭に置いても、両眼の画像のレンダリングにはまだ余分な作業負荷が残っています
  • 通常のゲームは30fpsの実行で十分で、理想的には60fpsで処理します。これにより、ローエンドハードウェアとハイエンドハードウェアの両方でプレイできる範囲が広がります。ただし、ARまたはVRのHMDアプリケーションの場合、60fpsは絶対最小値です。安定した90fpsで実行するようにゲームをターゲットし、ユーザーがすぐに乗り物酔いしないようにする必要があります。
  • 高いFOVとそれに関連するレンズの歪み効果のせいで、2倍の解像度でレンダリングする必要があるので多くのVRエクスペリエンスを必要とします。そう、VIVEの解像度は片目あたり1080x1200です。なので、それぞれの目は2160x2400でレンダリングされます。これは、ほとんどの AR アプリケーションでは問題ではありません。

全体として、通常の3Dゲームと比較してGPUの処理負荷がかなり高いです。MultiView や foveated レンダリングなど、これを改善するためのパイプラインが導入されていますが、これらはすべてのデバイスでサポートされているわけではありません。これが、抽象的スタイルを多用しているVRゲームを数多く見かける理由であり、リアリズムを追求しているVRゲームでも細心の注意を払うと、おそらく効果が少し保守的であるか、古き良き光学トリックを使用していることに気付くでしょう。