OBJ を GLB に変換

ブラウザーは OBJ を読めませんし、GLB もネイティブには読めません。.glb に直接アクセスするとレンダリングではなくダウンロードになります。違うのはライブラリの生態系です。three.js、Babylon.js、model-viewer の Web コンポーネントはどれも GLB を主要な入力として、1 回のフェッチで読み込みます。OBJ 対応はサイドローダーで、MTL とすべてのテクスチャを別々のリクエストで必要とします。

ですから実際の問いは、ブラウザーがどの形式を理解するかではなく、これから組み込むランタイムがどれを期待しているかです。2018 年以降に公開されたものはたいてい GLB が答えです。モデルがコンテンツそのものである商品ページでは、4 つ 5 つのリクエストを 1 つにまとめることが、スマホでは実測できる差になります。

OBJ ファイル自体にはマテリアルが含まれていません。mtllib 行が隣の .mtl を名指しし、usemtl 行がそのファイル内の項目を切り替えます。.mtl には拡散色や鏡面反射の値、テクスチャ画像へのパスが入っています。この変換器は v、o、g、f の行だけを読み、それ以外は無視します。

結果ははっきりしていて、あらかじめ計画に入れておく価値があります。GLB には形状とグループ名だけが入り、ビューアーは持っている既定のマテリアルで描画します。テクスチャ込みで表示するつもりだったモデルなら、経路は Blender です。MTL ごと OBJ を読み込み、glTF バイナリとして書き出せば、画像が GLB の中に取り込まれます。このページは、形が納品物である場合のためのものです。

12 バイトのヘッダー、4 バイト境界にスペースで埋められた JSON チャンク、その後にゼロで埋められたバイナリチャンクが続く glTF 2.0 バイナリです。JSON の中には OBJ の各グループにつき 1 メッシュ、各メッシュに 1 ノード、それらを一覧するシーンが 1 つ、資産バージョン 2.0、そして各メッシュに float32 の VEC3 位置アクセサーと uint32 の SCALAR インデックスアクセサーがあります。

すべての位置アクセサーは最小値と最大値を持っています。これは仕様上の要求であると同時に、読み込んだ瞬間にモデルが現れるかどうかを分ける実務上の違いでもあります。model-viewer も three.js も、その範囲から初期カメラ距離を計算するので、これらが書かれていないファイルは、見かけ上空のシーンになる典型的な原因です。

読み込み側は o 行や g 行のたびに新しいグループを開始し、書き出し側はグループごとに glTF メッシュを 1 つ出力し、それぞれ独自のノードとプリミティブを持ちます。CAD から書き出された、面のパッチごとにグループを持つ OBJ は数百のグループを含むことがあり、GLB はそれを忠実に数百のメッシュとして持つことになります。

ページ上ではこれは本物のコストです。プリミティブごとに描画コールと GPU バッファーの結び付けが別々に発生し、ミドルレンジのスマホでは数百個あるだけでフレームレートが落ちます。OBJ を書き出す前に Blender でオブジェクトを結合するか、グループに意味がなければテキストエディターで g 行を取り除くのが、そのあとの作業のどれよりも見合う二分間の修正です。

NORMAL 属性は書き込まれません。glTF の仕様は、ビューアーがその場合に何をすべきかを明確に定めています。平面の面法線を計算するのです。モデリングソフトで滑らかに見えた球体は、ブラウザーではすべての三角形が別々の面として見える形でレンダリングされ、意図したローポリ調に見えてしまい、たいていそれは意図したものではありません。

すっきりした解決策が二つあります。three.js では読み込んだジオメトリに computeVertexNormals を呼び出すと、面法線を頂点ごとに平均します。これは頂点が正しく結合されている必要があり、変換の際に小数点以下 6 桁で位置が統合されているため満たされています。あるいは Blender の側で法線パスをかけてから glTF を書き出せば、マテリアルも一緒についてきます。

glTF は両方を固定しています。右手系で Y 軸が上、単位はメートルです。OBJ はどちらも固定していません。ヘッダーもなく単位もなく軸の規約もない数値の羅列で、書き出すアプリケーションごとに独自の癖があります。

ここでは変換は適用されないので、Z 軸が上の OBJ は仰向けに倒れた GLB を生み、センチメートル単位で作られた OBJ は 200 メートルの高さのモデルを生みます。どちらか分かってしまえばすぐ直せます。X 軸まわりにマイナス 90 度回転させる、または一様スケールをかける。しかしファイルを読み込むまでは見えません。知っている寸法とバウンディングボックスを照らし合わせるのが、いちばん早い診断です。

四角形以上の面は最初の頂点からファン三角形分割されます。これは変換元によく含まれる凸な四角形や n 角形には正しく、凹んだ面では三角形が重なることがあります。負のインデックス——直前の頂点から逆にたどる指定——は、その意味がファイル内の位置に依存するため、後回しにせずファイル読み込みの最中に解決されます。

その後で位置が結合されます。小数点以下 6 桁で一致するものは 1 回だけ保存し、20 個の三角形に現れる座標は 1 回保存して 20 回参照されます。これはバッファーを縮めると同時に、ブラウザーに本物の隣接関係を持つメッシュを渡すことになり、それが computeVertexNormals による滑らかなシェーディングを可能にしています。

位置には頂点あたり 12 バイト、インデックスには三角形あたり 12 バイト、それに小さな JSON ヘッダーが加わります。20 万三角形、10 万頂点のモデルはおおよそ 3.6 MB になり、圧縮は一切かかっていません。インデックスは例外なく uint32 で、65,535 頂点未満なら 2 バイトで済むところを 4 バイト使い、しきい値で動作が黙って変わる分岐を取り除いています。

ページにとってその数字が大きすぎるなら、答えは前後の工程にあります。ここではありません。Blender や MeshLab でメッシュを間引いてから、gltf-transform で Draco や meshopt の圧縮をかけてください。どちらもブラウザー側に対応するデコーダーの読み込みを要求し、それ自体が 1 モデルを表示するページにとってのコストになることも忘れないでください。

モデルにテクスチャが必要なら、MTL と画像を持ってこられる Blender 経由で変換してください。モデルが数十万の三角形を持つなら、書き出す前に間引いてください。滑らかに見せたいなら、ビューアー側かエクスポーター側で法線を処理してください。この経路はそのどれも与えません。

このページが向いているのは、正直な中間の場合です。部品や小道具、スキャンのきれいな OBJ が、モデルをどこにもアップロードすることなく、1 つのファイルとして形として表示される必要がある場合です。この変換はすべてブラウザーの中で完結し、エンジンのダウンロードもなく、上限は 100 MB で、現行のあらゆるウェブビューアーが受け入れるファイルを作ります。