GLB を glTF に変換 — 読めるジオメトリだけを取り出す

GLB からジオメトリを読み出し、それを囲む新しい glTF を書きます。これは再パッケージではなく作り直しです。再パッケージを行うツール——gltf-pipeline の --binary=false や gltf-transform——は元の文書をそのまま保ち、バッファーをバイナリの入れ物から外へ移すだけなので、マテリアル定義もテクスチャ参照もアニメーションチャンネルもそのまま渡ります。

ここでは違います。この変換機はシーングラフをたどり、頂点座標と三角形の索引を取り出し、プリミティブごとに 1 つのメッシュ、メッシュごとに 1 つのノードを持つ新しい文書を組み立てます。baseColorFactor を編集して保存し直したいなら、これは違う道具で、gltf-transform が正しい道具です。ファイルの中身を見たいだけなら、続きを読んでください。

どちらも glTF 2.0 で、Khronos Group が 2017 年 6 月に公開した仕様に最初からバイナリの入れ物が含まれています。.gltf は JSON で、頂点データは隣の .bin ファイルか、データ URI として埋め込まれます。.glb は同じ JSON と同じバッファーを、先頭 4 バイトが glTF と綴られる 12 バイトのヘッダーの後ろに 1 つのバイナリファイルとして連結したものです。

GLB の中では内容はチャンクとして並びます。JSON というタグの付いた JSON チャンクと、BIN というタグの付いたバイナリチャンクで、それぞれ 4 バイト境界まで詰められ、そのパディングも宣言された長さに含まれます。有効な GLB のすべてのチャンク長が 4 の倍数になるのはそのためです。これが 2 つの拡張子の違いのすべてで、モデル自体は変わりません。だからこそ、このツールのようにモデルを作り直す変換機は、拡張子の変更が示唆する以上のことをしています。

常に 1 つのファイルです。頂点データはただ 1 つのバッファーエントリに base64 で符号化されたデータ URI として入るので、失われる .bin のサイドカーもなく、移動したときに壊れる相対パスもありません。1 回の変換で 1 つのダウンロードになり、出力を 2 つのファイルに分けてしまうとこの前提が崩れます。

base64 はバイト 3 つにつき文字 4 つを消費するので、埋め込まれたバッファーは元のバイナリよりおよそ 33 パーセント大きくなり、その上に JSON は 2 スペースのインデントで整形されます。エディタで開くファイルとしては妥当な代償です。ブラウザーに配信するファイルとしては割に合わず、その用途にはすでに手元にある GLB のほうが優れた成果物です。

その一覧は長く、全部読む価値があります。PBR のメタリック・ラフネスマテリアル、ベースカラー、法線、遮蔽、発光、メタリック・ラフネスの各テクスチャ、サンプラーと画像、UV 座標、頂点法線、頂点カラー、接線、モーフターゲット、スキンとジョイント、アニメーションのサンプラーとチャンネル、カメラ、ライト、ファイルが宣言するあらゆる拡張機能です。

残るのは頂点座標、三角形の索引、メッシュの名前です。シーン階層は効果としてのみ残ります——次の項で説明します。これは glTF 形式の限界ではなく、この変換機の限界です。glTF はこれらすべてを問題なく持てますが、この変換機はほとんど共通点のない 6 つの形式間でジオメトリを運ぶことに特化しています。

glTF のシーンでは、1 つのメッシュを異なる行列で何度も配置することがよくあります。1 つの車輪のメッシュを 4 つの車輪が参照する、というのが典型例です。この変換機は既定のシーンからシーングラフをたどり、各ノードの行列を親のものと掛け合わせ、その結果のワールド行列を頂点に適用してから書き出します。

結果として、見た目の形は正しくても構造は正しくありません。4 つの車輪は、1 つのメッシュを 4 回インスタンス化したものではなく、それぞれ独自の位置に頂点を持つ 4 つの別々のメッシュとして届きます。平行移動・回転・拡大縮小が別々の TRS プロパティとして与えられている場合も、glTF が定義するクォータニオンの順序で先に行列へ合成されるので、明示的な行列で組まれたモデルと同じ場所に着地します。

Draco 圧縮されたジオメトリは、壊れたファイルではなく名前の付いたエラーで止まります。KHR_draco_mesh_compression は頂点データを専用の復号器が必要な圧縮ストリームに保存しており、その復号器はここには同梱されていません。Blender から Draco なしで書き出し直すか、Draco を無効にして gltf-transform を実行すれば正常に読めます。

三角形のリストでないプリミティブは、壊されるのではなく静かに飛ばされます。glTF のモード 4 は三角形で、モード 0 から 3 は点、線、線のループ、線のストリップ、モード 5 と 6 は三角形のストリップとファンです。線だけのジオメトリ——ワイヤーフレームのオーバーレイやデバッグ用のパスなど——しか持たない GLB では、「三角形のジオメトリが見つかりませんでした」というメッセージが返り、これは正確な報告です。

出力を開けば、accessors の配列が、GLB を変換した人がたいてい知りたいことのほとんどに答えます。各メッシュは頂点座標用の VEC3 float アクセサーと、索引用の SCALAR unsigned-int アクセサーを持ちます。索引数を 3 で割れば三角形数になり、頂点数は座標のアクセサーからそのまま読めます。

POSITION アクセサーは仕様が要求する min と max も持ち、ビューアーはそれでモデルを画面に収めます。この 6 つの数字が境界ボックスで、誰かから送られたモデルが本来の 1000 倍大きい、あるいは原点からまったく離れた場所に置かれていることに気づく最速の方法です。メッシュの名前はソースから引き継がれるので、複数パーツのモデルでも判読できます。

ファイルがウェブページに載るなら GLB のままにしておいてください。より小さく、1 回のリクエストで済み、three.js、Babylon.js、model-viewer はどれも直接読み込めます。配信のために glTF に変換すると、ファイルは大きくなり、この変換機を通せば見せる価値を作っていたマテリアルも失われます。

何かを変更して保存し直したいなら gltf-transform か Blender の glTF エクスポーターを使ってください。何もインストールせずファイルをすばやく確認したい、あるいは別の書き出しと差分を取るためのテキストの成果物が必要なら、このページが近道です。すべての GLB が glTF になるべきだとほのめかすより、この境界をはっきりさせておくほうが役に立ちます。

この変換は普通の JavaScript がページ内で動くだけで、ダウンロードすべき WebAssembly モジュールも、アップロードも、待ち行列もありません。ファイルは FileReader 系の API で読まれ、結果は Blob として組み立てられ、そのまま保存します。無料の上限は 100 MB で、ウェブ向けとしては非常に大きな GLB に相当します。

出力は整形された JSON の中に base64 でバッファーを埋め込むので、マテリアルが落ちた後でも元の .glb より .gltf のほうが大きくなると見込んでください。ジオメトリはたいていのモデルの中身の大半を占め、base64 はそれを膨らませます。ジオメトリが 9 MB を占める 12 MB の GLB は、テクスチャなしでもおよそ 12 MB の glTF になります。