OBJ を GLTF に変換

現代の 3D ウェブ制作の道具はほとんどが glTF を入力として想定しています。gltf-transform は間引きや圧縮を行い、Khronos のバリデーターは仕様への適合を確認し、three.js や Babylon.js はそのまま読み込みます。OBJ はその外側にあり、まずはこれらが受け付ける形にする必要があります。

.glb ではなく .gltf を選ぶ理由は、JSON のままなら開いて手で直せるからです。GLB はパイプラインの最後、マテリアルが決まり圧縮も済んだあとに作る成果物です。このページは、そのパイプラインの入り口——エディターで開けることが、1 リクエストで配信できることより価値がある段階——のためのものです。

バージョン 2.0 を宣言する asset ブロック、シーン、OBJ のグループごとに 1 個のメッシュとノード、各メッシュに 1 個のプリミティブ、POSITION 属性とインデックスのアクセサ。そこにアクセサ、バッファービュー、1 個のバッファーが続きます。

2 スペースの字下げで整形されているため、圧縮版よりおよそ 3 割大きくなりますが、フォーマッターなしでも読めます。これから編集するファイルとしては妥当な既定であり、圧縮したければコマンド一つで済みます。

glTF が頂点データを持つ方法は、別ファイルの .bin、buffer の uri 欄の base64 データ URI、GLB のバイナリチャンクの 3 通りです。ここでは 1 ファイルにするため、データ URI 一択になります。

その代償として、同じデータをバイナリで持つ場合よりおよそ 3 割大きくなります——base64 は 3 バイトを 4 文字で表すためです。作業用の文書としては許容範囲で、gltf-transform やバリデーター、three.js はいずれも設定なしで埋め込みバッファーを読み込みます。

OBJ の MTL ファイルは読み込まれないため、この文書に materials 配列はありません。追加は 4 行ほどで済みます。pbrMetallicRoughness ブロックと baseColorFactor を持つオブジェクトを materials に加え、対象のプリミティブに material のインデックスを指定するだけです。

これでジオメトリに手を触れずに、色付きで正しく照らされたモデルが得られます。テクスチャはもっと大きな作業で、画像やサンプラー、そして何より TEXCOORD_0 のデータが必要ですが、これはこの変換では生成されません。UV が必要な場合は Blender のような専用ソフトのほうが正直な選択です。

o 行や g 行がグループの開始を示し、各グループが名前付きのメッシュになります。ジオメトリ以外で変換をまたいで残る情報はこれだけで、手で編集する文書においては、目的の部品を探す手がかりとメッシュを数える作業の違いを生みます。

名前のないグループは、メッシュにも名前が付きません。あとから手で編集する予定があるなら、OBJ の側でグループに名前を付けておくほうが、無名のメッシュを JSON の中で整理し直すより簡単です。

バッファービューは、各アクセサのバイトオフセットがコンポーネントサイズの倍数になるようパディングされています。これは推奨ではなく要件で、自作の書き出しコードでよく起きるバリデーターエラーの原因です。すべての POSITION アクセサには min と max が付き、これはビューアーがモデルをフレームに収めるために使う必須情報です。

Khronos の glTF Validator を実行すると、エラーではなく「メッシュに法線がない」という情報レベルの注記が出ます。これは事実であり、仕様はビューアーに対してフラットな法線を計算するよう指示しているので、問題ではありません。

4 頂点以上の面は、最初の頂点を起点にファン三角形分割されます。これは凸型のポリゴンには正しく、凹型の面では三角形が重なることがあります。複雑な多角形を出力するツールから来た OBJ では注意してください。

負のインデックスは読み込み時に解決されます。順序どおりに解釈できないためです。グループごとに小数点以下 6 桁で頂点が溶接されるため、4000 頂点のファイルのうち 12 個しか参照されていないグループは、glTF の中では 12 頂点として書かれます。

バッファーの base64 化に加えて、整形済み JSON の分が上乗せされます。ジオメトリだけのモデルではバッファーが支配的なので、圧縮前で GLB のおよそ 3 割増しと見込んでください。

これはパイプラインの序盤では正しい選択で、終盤では逆です。よくある流れは、まずここで glTF に変換し、編集や処理を挟んでから、変換し直すか gltf-transform に書かせて最終的な GLB を作るというものです。Draco や meshopt の圧縮もその段階に属します。

変換から納品までのあいだに何も起きないなら、GLB へ直接変換するほうが、より小さく、リクエストも 1 回で済みます。誰も開かない文書のために余分なバイト数を払う理由はありません。

マテリアルを足す、バリデーターを通す、変換パスを実行する、あるいはテキストとして差分の取れるリポジトリに置く——次の作業があるときに glTF を選んでください。どちらの変換もブラウザーの中だけで完結し、エンジンのダウンロードもありません。