フォトグラメトリとVR・HMDの相性について

 
「アパートの内見部屋をVRで紹介できないか？」

世間がコロナ禍で騒がしい中、知り合いの大家と雑談中にそのような言葉が出てきた。当時、コロナのために内見ができない状況が続いていて、不動産屋ではパノラマ写真を使うなどの試行錯誤が行われていた。そんな中で、VRちっくに内見ができるというのは、確かに方向性としては妥当で、その時は冗談として流したのだけども、個人的に興味が出たので手を出してみることにした。

このコラムでは、フォトグラメトリ（photogrammetry）を用いてVR内見部屋を作ることを目標として、試行錯誤した内容を軽く紹介しつつ、「フォトグラメトリで実写的なVR空間を作ること」に対する実用性、合理性、そして相性について、気付いたことを書いてみようと思う。

なお、結論から言ってしまえば、フォトグラメトリと「HMDを利用して自由に歩き回れる実写的なVR空間を作ること」は相性が良くないと私は考えている。

VR内見部屋

こんな感じになったらいいな、と見積もっていたコンセプトを紹介する。

• フォトグラメトリで内見部屋、廊下、そして最低限の屋外を3D化
• ウォークスルービューを画面内クリックで操作。HMDがあれば視点も操作
• Three.jsかBabylonあたりでWebベースに表示
• 領域を分割しつつ、それぞれ低解像度版を用意して読み込みスムーズ化

内見という性質上、フォトグラメトリ以外のやり方は相応しくないように思える。そして使う人を考えれば、スマホ閲覧を前提としてWebベースで構築する必要がある。この点、重いUnityではなく、もっとプリミティブにThree.jsを使ったり、またはHMDモードが用意されているBabylonを使うのもアリだろう。操作系はGoogleストリートビューをマネると良さそうだ。

もちろんこれは将来的にローンチするIFの話であって、あくまで机上の話である。ここでは、このうちフォトグラメトリについて焦点を当てたい。

フォトグラメトリ用ソフトウェア

フォトグラメトリのためのソフトウェアとしては、3df zephyr、reality capture、meshroomなどを見つけた。3DF zephyrのfree版は以前遊びで使ってみたことがあるが、上限50枚では小物しかできない。とはいえ、買い切りでは高いので選択肢から除外。質が良いとの噂を聞くreality captureは、サブスク制でひと月5000円程度。ただ個人的に乞食志向なのでこれは次点。meshroomはオープンソースで制限は無し。なのでとりあえずmeshroomを使うことに。

Meshroomは日本語では情報が少ないものの、使い方については英語のOSプロジェクト掲示板を漁ればある程度解決した。また、ビジュアルプログラミング風に操作系が組まれているので、プログラミングの経験が豊富な人にとっては、慣れるまでにそう時間はかからないだろう。

作ったもの

とりあえず試行錯誤して作ったものを紹介する。メッシュのノイズ処理（手作業）はある程度行っているが、テクスチャの補正はしていない。

補正すべき点はたくさんあるのだけど、無限に時間が溶けるてしまうので、とりあえずひと段落。

なお、このために撮影した写真は2600枚である。

フォトグラメトリの世界観

プログラム言語でもソフトウェアでも、その背景には要求される条件に対するUX的な思想があって、ユーザーたる我々がそれに則って実装を行うと、より効率よく良いものを作ることができる。そういったパラダイムなものは概して端的な言葉で表すことができないものの、その処理構造と言語からある程度感じ取ることはできる。

Meshroomはその操作系のおかげで、処理の工程が可視化されている。しかも各工程の名称がその道の専門用語であるから、学術的な面からの呼称も知ることができる。

レンズの影響を補正して写真を正規化した後、そこから特徴点を生成する。次に、前処理として写真同士のオーバーラップを軽く検証して紐づけの候補にしておき、本処理でそれらの特徴点同士を比較検証し、確度の高いものを確定させる。その特徴点の対応から三角測量の要領で、幾何学的に写真を撮影したカメラの位置と姿勢を算出する。この時点で、特徴点を疎なポイントクラウドとして生成しつつ、視差が得られる写真間のピクセル同士を総当たりで検証して、写真ごとに密度の高い深度マップを生成する。これに基づいて高密度なメッシュ化を行い、UVマップを貼り、各写真を投影することでテクスチャを得る。

以上が筆者が読み取れた限りのMeshroomにおけるフォトグラメトリのプロセスである。特徴点同士を繋ぎ合わせる手法自体は、パノラマ写真の生成技術でも良く使われるが、フォトグラメトリの場合は視差による特徴点のズレを利用する点から、「曖昧さ」を許容していることが大きな特徴のように思う。プロセスからも、段階的に絞り込んでいることがよく分かる。

以上の事に照らすと、

• 類似画像に分類されるくらいには、写真同士のオーバーラップ率が必要
• オーバーラップした写真同士の視差は大きい方が良い
• 対象物へのマーカーの設置は類似画像の候補化の処理には有効そう
• 詳細なメッシュの生成にはディテールを映し込むだけの高画質さが必要

という、巷で言われる「上手く作るためのコツ」に近いことが言える。ディテールの少ない白い壁にマーカーを設置することは、類似画像の候補化には役に立ちそうだけど、詳細なメッシュ生成にはあまり寄与しなさそうなことも伺える。また、反射や透過が、正確な形状の抽出を阻害するだろうことも予想できる。

撮影機材への要求も高そうだ。ボケないブレないは当然必須だが、深度マップの生成を考えればノイズの少なさも重要なファクターであって、高F値と高SSのためならISO値の多寡を無視して良い、という訳ではなさそうである。また、広角レンズはディテールが視野として圧縮されるので、超広角ほど良い、という訳でもないのだろう。確かに、筆者が撮影した画角12mmと48mm写真(フルサイズ換算)の処理を比較すると、48mmの方が生成精度が優れていた。

前述の3df zephyrやreality captureとの品質の違いはプロセスの各所に現れる推定の精度かと思うが、それらをそこまで使い込んでいないか、使ったことが無いので、これについてはあまり自信が無い。少なくとも、Meshroomでのフォトグラトリの生成プロセスは妥当そうである。

ちなみにMeshroomではTexturingへ送るobjデータをユーザが指定することができる。つまり、前段のMeshFilteringで処理を止め、そこで得られたメッシュデータを手作業で修正したあと、その補正後のデータをTexturingへ投げることができる。Texturingは素のメッシュデータにUVマップを生成し、写真を投影するプロセスであるから、写真に写る通りに正確に修正してあげれば、正しくテクスチャが投影されたモデルを得ることができる。参考までに、上のgifは１つめの動画と同じ部屋だが、これは穴を手作業で補正していないものである。

フォトグラメトリで得られるものとは？

ところで、上のgif画像と一つ目の動画、どちらが現実的に感じるだろうか？

個人的には、穴を補正していないgifの方が実写に近いと感じる。動画の方はどちらかというと、「3Dらしさ」が強く出ているように感じてしまう。この違いは、床の反射にあると筆者は思っている。実は動画の方で使った写真はPLフィルタによって床の反射が除去されていて、これにより正確な床形状が生成されている。対するgifの方は床に大きな穴ぼこが空いていて、正確な形状を得られていない。しかしその穴ぼこ自体が「鏡の向こうの世界」となっていて、意図的かはさておき、床に反射した壁の、視点移動による動的な変化を表現しているようである。

つまるところ、フォトグラメトリは『透過』や『反射』というマテリアルの性質を、「テクスチャ」と「形状」に落とし込むことができる訳である。これはとても面白いと思う。フォトグラメトリは観察者とマテリアルの物理的な相互作用さえも落とし込めるのである。

フォトグラメトリの役目を表現するとき、これまで筆者は『現実の三次元空間の情報を、カメラを通して3Dに落とし込むもの』と考えていたが、どうも前述の実写的な観点に基づくと『移動する視点から見える動的な景色変化を、静的な3D空間に投影して再構築する』という見方もできるのではないか。

などと考えると、フォトグラメトリの目的は以下の２つに大別できそうだ。

1. 正確な形状を取得する
2. 正確な景色（見え方）を取得する

そして、その目的に応じて、何を得るべきかの基準が変わってくる。

１の分かりやすい例は、従来からの地形測量や歴史的な史跡のアーカイブだろう。これらの用途の殆どは正確な形状抽出に重きをおき、見え方を重視しない。２は映像作品や、いわゆるVR用途が該当しそうだ。

１においては、PLフィルターなどで対象から反射や透過の要素を排除することは有効だろう。ただ、その代わり生成されたモデルからはマテリアルの性質が消え、現実味が無くなってしまう。これに鑑みれば、２の目的において、PLフィルターなどを使って正確な形状を取得することに固執するのは、あまり得策ではないような気がしてくる。

１と２を両立させた "様な" 例としては、有名どころだとスミソニアン博物館の3Dアーカイブがある。これは、数百万点もの歴史的な構造物や史料を3Dアーカイブにして公開したもので、その一部は「正確な形状」と「実写的な見え方」を兼ね備えている。しかし、これはたぶん後付けでマテリアル情報を付加しているのだろう。そこには多大な苦労が見え隠れする。

結果として、成果物の在り方は次の３つに分類される。

1. 正確な形状、不自然な見え方。
2. 不正確な形状、自然な見え方。
3. 正確な形状、自然な見え方、沢山の後処理。

VRとの相性

ここではまず、VR用途に使う事を考える。このチョイスをした人の多くは、フォトグラメトリの成果物に対して「自然な見え方」を期待していると考えられる。

VR用途では次の２種類の形態があると思う

• ルートが規定されたもの
• 空間を自由に闊歩できるもの

ルートが規定されている場合は視点の移動が限定的であるから、少ない撮影枚数でも自然な見え方を再現できる。でも一筆書きルートならパノラマ動画でも良いのであって、HMD用途や合成映像などの用途を除けば、ぶっちゃけ面倒さに甘んじてまでVRにするメリットはあまりないように思う。

一方、空間を自由に歩けるというのは、VRの利点の一つであるが、「正確な景色（見え方）を取得する」という観点に基づけば、この場合は移動可能なあらゆる地点から撮影することが要求される。言うまでもなく、これは大変な作業である。本稿で紹介した2つの動画のモデルだけで、2600枚も撮影している。

自由に歩けて尚且つ少ない撮影数に収める第三の道としては、反射や透過を抑えて、ある程度正確な形状で取得する方法がある。しかし従前の通り、後付けでマテリアル情報を与える工程が必要となる。しかも厄介なことに、フォトグラメトリの生成モデルはテクスチャが入り乱れていて、「床の部分だけ反射を加えよう」なんて簡単にできそうもない。*1

Meshroomで生成されたテクスチャ

ここまでくると、手作業で３次元メッシュを構築して、そこに数枚の写真から生成したテクスチャを張り付け、マテリアル情報を加えた方が、写真枚数、作業量、作業時間、データ量の点から適しているのではないだろうか？むしろその方がより自然に見せるモデルを作り易いんじゃないか？という考えに至るわけである。

この時点で、今回の相性問題の幸先は良くないのだ。

HMDとの相性

次に、フォトグラメトリによるVR空間内で、HMD（ヘッドマウントディスプレイ）を使うことを考える。このVR空間は膨大な写真を撮影して、マテリアル情報の追加をせずに上記の問題をクリアしたものとしよう。これは不正確な形状でもって、自然な見た目を実現している。

HMDの特徴は、ヘッドトラッキングも勿論であるが、左右の目の視差を利用してVR空間の立体感を得ることができる点にある。これらが使用者の没入感を高めてくれる。が、どうもこれはフォトグラメトリとは相性が良くなさそうである。

フォトグラメトリは『透過』や『反射』というマテリアルの性質を、「テクスチャ」と「形状」に落とし込むことができる。

『移動する視点から見える動的な景色変化を、静的な3D空間に投影して再構築する』

自然な見え方は「テクスチャ」と「形状」によって実現されている。見方を変えれば、これはVR空間上のカメラによって2D画面へ投影され、奥行きの情報が除去されることによって成立するものである。この時点で、奥行き情報を装着者へ伝えてしまうHMDとフォトグラメトリが相容れないことは明らかだろう。

HMDを使うことを前提とすると、正確な形状が要求されてしまう。正確な形状を出すには、不自然な見た目を許容するか、マテリアル情報の追加が求められる。そしてマテリアル情報の付加には膨大なリソースを割かねばならない。

ということで

今回の一連の経験を通して、「VR用途の実写的な3D空間を作ること」に対して「フォトグラメトリ」は実用性と合理性、手軽さの観点から相性が良くなく、HMDを使用するなら猶のこと相性が悪いと感じた。

地形や植物などの非ジオメトリックな形状や、小型のオブジェクトを3D化する用途としては向いていると思う。また、マテリアルの影響を受け難い遠景の3D化（例えばGoogle Earthの3D都市）では十分に有効だろう。要は適材適所であって、とにかく、全てをフォトグラメトリで構成しようとするのは、あまり上手なやり方ではないように思った次第。なお、言うまでもないが、ここでの話は将来のフォトグラメトリの伸びしろをも否定するわけではない。Unityのテクスチャから影を消す奴や、Googleによる写真内のガラス反射の検出をする奴、Adobeの写真内の環境光を後から自在に操作できる奴に鑑みれば、将来的にはマテリアル情報さえ推定して自動生成にできるかもしれない。それはそれで楽しみなことである。

その時が来るかはさておきね。

以上。

*1:まぁ3Dモデルに直接色を塗るような方法でできなくは無いんだけど