PLY を OBJ に変換

PLY はスキャンデータの置き場所で、OBJ はモデリング作業の置き場所です。スカルプトやアニメーションのソフトはほぼすべて OBJ を何も考えず読み込みますが、PLY への対応は Blender や MeshLab のように良好なものから、まったく対応していないものまでさまざまです。

リトポロジーや手作業での間引き、スカルプトの下地として使いたい場合、最初の一歩として形式を変える必要が出てきます。両方とも頂点のリストと面のリストで面を表現しているという点で近い設計なので、変換自体は小さな作業で済みます。

フォトグラメトリーや構造化光によるスキャンは、見た目を各頂点の赤・緑・青の値として保存しています。テクスチャも UV も画像ファイルもなく、色はジオメトリの属性そのものです。

この変換が書き出す OBJ には v 行と f 行しかなく、mtllib への参照も付属の .mtl ファイルもありません。頂点カラーを保持できるマテリアルの仕組みも OBJ にはありません。両方のファイルを残しておき、ジオメトリの作業は OBJ で行い、色は PLY 側から別途取り出す、という進め方が現実的です。

PLY ファイルは1つの頂点要素と1つの面要素を持つだけで、オブジェクトやグループという概念も、表面そのものの名前もありません。そのため変換は必ず1つの o グループを作り、名前がない代わりに mesh_1 という生成された名前を書き込みます。

1つのスキャンだけを扱うなら問題になりませんが、複数のスキャンを1つのプロジェクトにまとめる場合は、取り込みのたびに同じ名前のオブジェクトができてしまいます。取り込み時にリネームしておくと後で扱いやすくなります。

STL や OBJ を読み込む際には、重複した頂点が小数点以下6桁の精度で結合されますが、PLY を読み込む際にはそのような処理は行われません。ファイルが持つ頂点配列と面のインデックスは、そのままの形で OBJ に引き継がれます。

これはスキャンデータにとって正しい振る舞いです。すでにメッシュ化のソフトウェアが接続関係について意図的な判断をしているためです。ただし、これは変換のあいだに何かをきれいにしてくれるわけではないことも意味します。重複頂点や参照されない頂点があれば、そのまま OBJ にも残ります。

頂点しか持たず面を持たない PLY は点群であり、この変換では変換対象になりません。点群を面に変えるのは復元という作業であり、単純な変換ではなく、パラメーターやプレビュー、承認を伴う作業だからです。

MeshLab や CloudCompare のポワソン再構築、ボールピボット再構築といった機能でメッシュ化してから、その結果を変換してください。

PLY の面リストは任意の数の頂点を持てますが、3頂点を超える面はすべて最初の頂点を基点に扇状に三角形分割されて書き出されます。凸な多角形では正しく分割されますが、凹んだ多角形では意図しない三角形が生じることがあります。

スキャンから得られるメッシュはほとんどが三角形なので、通常はこの問題に直面しません。

バイナリの PLY では1つの座標がわずか数バイトで記録されますが、OBJ では小数のテキストとして書かれるため、同じメッシュでも数倍の容量になります。数百万三角形規模のスキャンをそのまま変換すると、テキストエディターが開くのも苦労するような巨大なファイルになります。

変換の前に MeshLab の quadric edge collapse などで間引いておくほうが、その後の作業全体が速くなり、モデラーが気にするような品質の劣化もほとんど生じません。

vn 行は書き出されないため、取り込んだ直後は面ごとのフラットな法線が計算され、面が目立つ見た目になります。スムーズシェーディングや自動スムーズ角を適用すれば、スキャンらしい見た目に戻ります。マテリアルも付属しないので、まず適用してから作業を始めてください。

そのあとは、背景から拾ってしまった浮遊ジオメトリの除去や、見えなかった部分の穴埋め、アニメーションや細分化が必要ならリトポロジーといった、通常のスキャン処理が続きます。これらはいずれも変換の作業ではなく、それぞれの操作が1コマンドで済むツールで行うべき作業です。

OBJ は派生ファイルです。形状は持っていますが、色も、スキャナーが記録した頂点ごとの信頼度も、法線を持っていた場合のその情報も持っていません。いずれも OBJ からは復元できません。

PLY を正本として扱い、OBJ を作業用の複製として扱うのが実務的です。この変換はブラウザーの中で行われ、何もアップロードされません。取引先の物や人物のスキャンを扱う場合には、この点が安心材料になります。