HMD + Kinect =拡張仮想性



この記事では、現実世界のオブジェクトを仮想現実に追加するアイデアと概念実証についてお話したいと思います。



私の意見では、説明されたアイデアはすべてのVRマーケットプレーヤーによって近い将来に実装されるでしょう。 私見、これがまだ行われていない唯一の理由は、完璧なソリューションを展開したいという願望ですが、それほど単純ではありません。



長年にわたり、MechWoinシミュレーターの油圧キャブの設計について考えてきました。



もちろん、私はそれを決してしません。
なぜなら これにはかなりの投資が必要であり、プロジェクトへの関心がすぐに失われることは明らかです。 受け取ったバンドゥーラを保管する場所がありません。また、誰かに販売/レンタルするための商業的な手段がありません。



しかし、これはあらゆる種類の設計オプションを定期的に検討することを妨げません。

以前は、タクシー内に多くのディスプレイを配置する予定でしたが、その一部は意図したとおりに機能し、2番目の部分は「窓」/抜け穴をエミュレートします。



しかし、現代の世界では、VRヘルメット(ヘッドマウントディスプレイ)という別のソリューションが思い浮かびます。 次のように、ヘルメットで作業するときに高品質の液浸を達成するのがはるかに簡単です 実際のキャビンの内部を慎重になめる必要はありません。 はい、そして時にはデザインをやり直しますが、しかし、あります。



通常のファーコントロールパネルは複雑で興味深いものです。 最も単純な本物のコントローラーは次のようになります。



画像



本格的なシミュレーターで何かをすること(たとえば、ゲームパッドからの制御)は選択肢ではありません。

コントロールパネルをシミュレートしてVRの世界に配置することは問題ではないと仮定します。

ただし、タッチで非常に多くの小さなトグルスイッチを管理することは非常に悪い考えです。

しかし、ユーザーはVRの世界で手を見ていないため、どうすればよいでしょう。



もちろんあります



特別な手袋
画像



しかし、今日はそれらについてではありません...



現在、深度カメラは積極的に開発されています。 Microsoftは、Kinektでそれらを発表した最初の企業です。 残念ながら、MSはKinektが経済的に正当化されないと判断し、プロジェクトを終了しました。 しかし、考えられるように、この事件は死ななかった。 Appleは最新のiPhoneに深度カメラを導入しました。所有者の顔を認識するのはこのカメラです。

MSはこのテクノロジーを放棄しませんでした。WindowsMixed RealityプラットフォームのVRヘルメットは、深度カメラに基づくインサイドアウトトラッキングテクノロジーを使用します。



明らかな解決策は、深度カメラをVRヘルメットにねじ込み、結果のジオメトリをVRの世界に適用することです。 しかし、何らかの理由で誰もそれをしません。



ZED Miniは3Dワールドを構築でき、ヘルメットに取り付けられているように見えますが、私はそれらをライブで見ませんでした。すべてのプロモーションビデオは、3Dモデルをオーバーレイするためだけにワールドに関する情報を使用します。 問題は、結果として得られるモデルの品質が低いことだと思います。これは、レンダリングしようとするとすぐに表示されます。



残念ながら、Kinektをヘルメットに固定する機会はありません。 キネクトは巨大で重く、ヘルメットの構造に侵襲的な介入がなければ、通常の締め付けはできません。 しかし、ヘルメットは貸されており、私はそれを台無しにすることはできません。



そのため、このミニプロジェクトでは、テーブルの上にキネクトを垂直に配置しました。

このオプションは完全に私に合っています、なぜなら 仮想毛皮のコックピット内にキネクトを配置する場合、それはプレイヤーの手のみによって検出され、他のすべてのオブジェクトを遮断するためにコントロールパネルの上にも配置されます。



プロジェクトに移りましょう(コード解析はなく、理論といくつかの写真があります)



libfreenect2とOpenNIを使用して、高さマップを取得します。

この高さマップを視覚化する方法は?

Unreal Engineには3つの明らかなオプションがあります。



頂点のZオフセットを指定する高さマップを持つメッシュ。



明白で最速のオプション。 メッシュは完全に静的で、テクスチャのみが変化します(非常に高速です)。



残念ながら、この方法には重大な欠点があります:物理学を固定できないことです。 物理学の観点から見ると、このようなメッシュは完全に平らで固体です。 シンプルな長方形。 頂点の一部を持っているという事実は透明であり、アルファテストによって遮断されています-物理学は見えません。 頂点がZ座標によって変更されるという事実-物理学は見えません。



低レベルで手動でメッシュを構築します。



これを行うには、UPrimitiveComponentをオーバーライドし、SceneProxyを使用して新しいコンポーネントを実装する必要があります。 これは、速度を向上させる低レベルのアプローチです。

主な欠点は、実装がかなり複雑であることです。

完全に完了した場合、選択する価値があるのはこのオプションです。

しかし、以来 私はそれを迅速かつ簡単にするタスクに直面しました、私は3番目のオプションを使用しました。



UProceduralMeshComponentの実装



これはUEに組み込まれたコンポーネントであり、メッシュを作成し、衝突を計算するためにオブジェクトをすぐに読み取ることさえ簡単かつ簡単にします。



なぜこのオプションではなく、2番目のオプションを使用する必要があるのですか?



このコンポーネントは動的ジオメトリで動作するように設計されていないためです。 彼は投獄されているので、一度(または少なくとも非常に頻繁ではなく、できればリアルタイムではない)彼にジオメトリを与え、ゆっくりと考慮し、すぐに作業します。 これは私たちには当てはまりません...



しかし、テストのために行います。 さらに、シーンは空であり、コンピューターにはこれ以上考慮する必要がないため、十分なリソースがあります。



カメラ画像でオブジェクトを視覚化することは、良い選択肢ではありません。 実際の写真は、仮想世界の背景に対して際立っています。



したがって、SteamVR-ラインとの類推によって視覚化することにしました。 塗りつぶさずに青いメッシュのテクスチャをオーバーレイします。 さらに、輪郭に沿ってストロークを作成しました。 それはまったく受け入れられるものでした。 確かに、完全に透明なため、手は少し悪く感じられたので、正方形を塗りつぶすと、わずかに青みが目立ちました。







スクリーンショットは、ジオメトリの「流出」の影響を示しています。 これは、カメラに対して90度に近い角度の顔を通常処理できない深度チャンバーのせいです。 Kinektは、値0のピクセルを明示的に縮退しますが、残念ながら、すべてのピクセルと一部のピクセルが縮退せずに「ノイズを発生させる」わけではありません。 メインノイズを除去するために一連の簡単な操作を行いましたが、「流出」を完全に取り除くことはできませんでした。



この効果は横から見たときに非常に顕著であることに注意してください(テーブルの前に座って、キネクトが上にあります)。 深度カメラが視線に平行に向けられ、ユーザーの実際の視覚器官に近い点から進む場合、この効果は前方に向けられ、目立たなくなります。



ビデオでわかるように、実際の手はVRの世界で非常にうまく機能します。 唯一の重大な欠点は、動きの離散性です。



メッシュはスムーズに新しい状態に変化しませんが、削除されて再作成されます。 そのため、鋭い動きで物理的な物体が落下するため、ゆっくりと慎重に動きます:





私は暗いビデオをおizeびします-私は仕事の後の夜にプロジェクトに従事しました、ビデオプレビューでは正常に見えました、すべての機器がすでにビデオを撮影してコンピューターに転送していました-非常に暗いことが判明しました。



自分を感じる方法
HMD(オプション)、Kinect、UEと連携する能力、このプロジェクトを試してみたいという願望の両方を持っている人は非常に少ない(まったくない)ことを教えてくれます。 したがって、ソースコードをgithubにアップロードする理由はありません。



プラグインのソースコードをアーカイブとしてアップロードします。



UEプロジェクトに通常のプラグインとして追加します。

相対パスを使用してlibファイルを接続する方法を理解できなかったため、OpenNI2CameraAndMesh.Build.csにOpenNI2.libへのフルパスを記述します。

次に、ADepthMeshDirectを適切な場所に配置します。

レベルの開始時に、UToolsからstartOpenNICameraメソッドを呼び出します。

libfreenect2がkinektの操作に使用されることを忘れないでください。つまり、libfreenect2ページの指示に従って、kinetsのドライバーをlibusbKで再定義する必要があります。



UPD:

記事の冒頭で、そのようなシステムはすべてのVRヘルメットにまもなく搭載されると述べました。 しかし、執筆の過程で、彼はどういうわけかこの瞬間を見失い、それを明らかにしませんでした。



したがって、このトピックを拡張するために以下に書いたコメントを引用します。

私たちが言うなら-なぜそのようなシステムがすべてのVRシステムで例外なく必要なのか-これはセキュリティです。



これで、プレイエリアの境界が条件付きキューブでマークされました。



しかし、まれに、VRの下で絶対に空のスペースを割り当てる余裕があります。 その結果、オブジェクトは部屋に残り、時には危険です。

主に行われると確信しているのは、プレイヤーの目の前の部屋全体をほとんど識別できない幽霊の形で仮想表示することです。これにより、ゲームの認識を妨げず、一方で、つまずいて死なないようにできます。


PS:

この企業に経営陣からこのプロジェクトに取り組むための技術的基盤を提供してくれた<企業ブログ以外からは呼び出せない>ことに深く感謝したい。



All Articles