GLB を OBJ に変換

glTF とそのバイナリ版は、多くのエンジニアやアーティストが実際に使っているソフトより 8〜9 年若い形式です。Wavefront が OBJ を発表したのは 1992 年で、いまも最大公約数の位置にあります。Blender、MeshLab、Maya はもちろん、ほとんどの CAD インポーター、メッシュ修復ツール、スライサーが読めます。Web パイプラインから出てきた GLB を、そうした世界で開くには OBJ にする必要があります。

これは品質の劣化というより、種類の違う変換だと考えたほうが正確です。GLB はシーンです——ノードの階層、材質、テクスチャ、アニメーション、カメラを持ちます。OBJ は点とその間の三角形のリストに、材質ファイルへのポインターを添えただけのものです。幾何情報以外はどこかに行き場を探すことになり、この変換ではその行き場が用意されていません。

3 種類の行しかありません。書き出しツール名のコメント行、メッシュごとに GLB の名前を引き継いだ o 行、頂点ごとに 3 つの小数座標を持つ v 行、三角形ごとに 3 つのインデックスを持つ f 行です。vt 行も vn 行も、s のスムージンググループも、usemtl も、mtllib もありません。

つまずきやすいのはインデックスの数え方です。OBJ のインデックスは 0 ではなく 1 から始まり、各グループでリセットされずファイル全体を通して数えられます。自分でパーサーを書く人がよく間違える部分です。この変換ではメッシュを走査しながらその通算オフセットを追跡しているので、2 つ目のオブジェクトが自分自身の最初の頂点を参照していても、それまでの合計を足したインデックスで書き出されます。ここを誤ると、開けはするのに違う三角形が表示される OBJ になり、開けないより厄介です。

OBJ 自体は材質を持ったことがありません。材質は mtllib 行が指す別の .mtl ファイルに書かれ、色や光沢、テクスチャマップのパスはそちらに入ります。この変換は mtllib 行を書かず .mtl も作らないので、OBJ は材質的には空白で、読み込む側のソフトが既定のグレーを割り当てます。

これは幾何情報だけを読む変換の当然の結果です。GLB のメタリック・ラフネスのパラメーター、ベースカラー、法線テクスチャ、UV 座標は一切取り出されないので、MTL に書けるものが最初からありません。もっともらしい既定値だけの MTL を作るほうがかえって悪い結果になります。それは元の材質だったという誤った印象を後工程の担当者に与えるからです。

glTF のメッシュ名はそれぞれ、そのグループの OBJ の o 行として書き出されます。筐体、ブラケット、カバーのように名前の付いた部品で組まれたモデルなら、Blender や Maya には 1 つに融合した形ではなく、3 つの名前付きオブジェクトとして読み込まれます。名前のないメッシュには生成された名前が付き、グループ構造は見失われません。

これは見た目以上に重要です。幾何情報だけの変換では、名前だけがほぼ唯一残る意味情報で、後工程の担当者が正しいパーツに材質を割り当て直せるのも名前があるからです。GLB のメッシュが無名で、あとで区別が必要になりそうなら、書き出す前に、読み込んだあとではなく、名前を付けておいてください。

glTF は 1 つのメッシュを複数のノードから異なる行列で参照することで、何度も配置できます。OBJ にはこれに相当する仕組みがありません。この変換ではシーンを走査し、各ノードの行列を親のものと合成して、書き出す前に頂点座標へ焼き込むことでこの差を解消しています。

つまり、1 個のネジのメッシュが 60 回インスタンス化された GLB は、60 個のグループと 60 個分のネジの完全な複製を持つ OBJ になります。見た目はこれで正しくなります——これ以外に正しく保つ方法がないからです——が、その部分だけファイルサイズはインスタンス化されていた元の 60 倍になります。読み込み先のソフトがインスタンス化に対応しているなら、読み込んだあとにインスタンスを組み直す手間は、たいてい割に合います。

スケール変換は一切行われません。GLB が持っていた座標値は、JavaScript が出力する精度のまま OBJ に書き写されます。これは正しい振る舞いであると同時に落とし穴でもあります。2 つの形式は「数値」の意味が違うからです。

glTF 2.0 は線形単位をメートルと定義しているので、実寸で作られた椅子の座標はおよそ 0.9 になります。OBJ には単位の宣言がなく、読み込むソフトごとに慣例が異なります——Blender では多くがメートル、古い CAD ツールではセンチメートルやインチのことが多いです。あとで印刷した部品や組み立てで係数の取り違えに気づくより、読み込み直後に既知の寸法とバウンディングボックスを一度突き合わせておくほうが確実です。

そのまま渡ります。glTF はすでに三角形を共有された位置配列へのインデックスとして持っているので、再構成する必要がありません。アクセサーの各要素が同じ順番で 1 本の v 行になり、各インデックスが 1 本の f エントリになります。この経路では何もマージしません。座標の重複をまとめる処理は、重複が当たり前の STL や OBJ の読み込みで働くもので、ここでは働きません。

これは実在のエクスポーターから出た GLB で意味を持ちます。glTF は頂点ごとに UV と法線を 1 組しか持てないため、テクスチャの継ぎ目やハードエッジ上の頂点は、属性を変えるために同じ位置にもう 1〜2 個の複製が作られます。その複製は OBJ にも引き継がれますが、複製の理由だった属性のほうは引き継がれません。結果として、本来閉じているはずのモデルが、継ぎ目に沿って境界エッジを報告することがあります。Blender の「距離でマージ」や MeshLab の「近接頂点のマージ」で 1 コマンドで解決できます。

いずれも設定なしで読み込めます。すぐに面取りされたような見た目になることを見込んでおいてください。vn 行がないので、各ソフトが平坦な面法線を計算し、三角形分割された曲面はポリゴンの殻そのものに見えます。Blender の「シェード：スムーズ」や、30 度前後のオートスムーズ角度で、GLB にあった見た目に近づけられます。

材質は付かないものと見込んでください。3 つのどのソフトでも割り当ては数クリックで済み、モデルをビューポートの背景から見分けやすくするために最初にやっておく価値があります。モデルがまったく表示されない場合、原因はたいてい読み込み失敗ではなくスケールです。選択範囲へズームして寸法パネルを確認してください。

読み込み先が glTF に対応しているなら変換しないでください。Blender、three.js、Babylon.js、Unity、Unreal、Windows の 3D ビューアー、macOS のプレビューはどれも材質を保ったまま GLB を開けます。OBJ を経由すると、それらすべてを何の見返りもなく失います。

変換すべきなのは、読み込み先が本当に glTF を読めない場合や、目視やコマンドで検査・比較できるテキストファイルが欲しい場合です。OBJ は 1 行に 1 頂点、1 行に 1 面という単純さがあり、この 6 つの形式の中でいちばん目で確認しやすい形式です。忠実さではなく、この読みやすさこそが、新しい形式に対して OBJ が今も持っている強みです。