glTF を GLB に変換 — 1 つのバイナリファイルに

世の中には 2 種類の .gltf があり、ここで使えるのはそのうち 1 つだけです。テキストエディタでファイルを開き、末尾近くの buffers 配列を探してください。uri が data:application/octet-stream;base64 で始まっていれば、モデルのすべての頂点がその 1 つのファイルの中にあり、変換は正常に動きます。uri が scene.bin や model.bin のようになっていれば、ジオメトリは 2 つ目のファイルにあり、単一ファイル用の変換機はそれを見ることができません。

後者の形のほうがよくあります。多くのエクスポーターが既定でそちらを出力するからで、このページが確認をおまけではなく冒頭に置いている理由です。バッファーが別のこの種の glTF をここに置くと、ジオメトリが別の場所にあることを明示するメッセージとともに、.glb 版を使うよう提案されます。これは本物の提案です。.gltf を作ったソフトはたいてい .glb も直接書き出せるからです。

外部リソースを持つ glTF は、相対パスでつながった小さなファイル群のグラフです。JSON、.bin、テクスチャごとに 1 枚の画像。そのパスのそれぞれが、モデルが壊れる原因になり得ます。JSON だけを隣のファイルなしで移動すれば何も読み込まれず、CDN で違うディレクトリ構成で配信すればバッファーが 404 になり、メッセージに添付すれば 4 つのファイルのうち 1 つしか届きません。

GLB にはそうした失敗の様式が一切ありません。失うものが何もないからです。HTTP のリクエストも複数回ではなく 1 回で済み、モデルが訪問者の目的そのものであるページでは重要です。この単一ファイルという性質こそ、バイナリの入れ物が glTF 2.0 に、JSON 形式とあとから継ぎ足すのではなく最初から並んで仕様化されている理由そのものです。

出力は glTF 2.0 のバイナリです。マジックナンバーが glTF と綴られた 12 バイトのヘッダー、バージョン番号と全体の長さ、そのあとに JSON チャンク、続いてバイナリチャンクが並びます。JSON チャンクはスペースで、バイナリチャンクはゼロバイトで 4 バイト境界まで詰められます。これは仕様が単に許容しているのではなく要求していることで、逆順にパディングされたファイルを拒否するローダーもいくつかあります。

内部では、頂点座標は例外なく VEC3 アクセサーの float32 として、三角形の索引は SCALAR アクセサーの uint32 として書かれます。小さいモデルではより狭い索引型を使えば数キロバイト節約できますが、65,535 頂点の境目で挙動が黙って変わる条件分岐が必要になり、変換機にとっては割に合わない取引です。すべての座標アクセサーは仕様が求める min と max を持つので、ビューアーはモデルを画面に収め、拡大しすぎて何も見えない状態を避けられます。

この変換機はジオメトリを移すものです。ベースカラーテクスチャ、法線マップ、発光マップを持つメタリック・ラフネスマテリアルを宣言した glTF は、頂点座標、三角形の索引、メッシュの名前だけを含む GLB に変換され、マテリアルブロック、画像、サンプラー、テクスチャ座標は単純に書かれません。

これは変換する理由と照らし合わせて考える価値があります。テクスチャを 1 つの配布可能なファイルにまとめることが目的なら、このページはそれを行わず、gltf-transform か Blender のエクスポーターが行います。自己完結した JSON から単一のバイナリ成果物を取り出すこと——サイズテスト、ジオメトリだけのプレビュー、シーンのプレースホルダーなど——が目的なら、結果はまさに正しく、ずっと小さくなります。

アニメーションのチャンネルとサンプラーは読まれず、スキンとジョイントの階層も読まれず、カメラとライトも読まれません。リグとアニメーションを持つキャラクターは、頂点データが表すポーズの静的なジオメトリとして GLB に届き、動かす手段はありません。

静的な小道具や建築物、スキャンされたオブジェクト、印刷用の部品にとってこれは何のコストもありません。失うものが何もなかったからです。キャラクターや機構にとっては、これがモデルのすべてです。ここに部分的な結果や、それを変える設定はありません。誠実な助言は、変換の後ではなく前に glTF の中身を確認することです。

元のシーンは既定のシーン索引からたどられ、各ノードの行列は親の行列と合成されてから頂点に適用されます。平行移動・回転・拡大縮小として別々に記述されたノードは、先に glTF が定義するクォータニオンの形で行列に変換されるので、どちらの記述方法も同じ場所に着地します。

出てくる GLB は平坦な構造を持ちます。1 つのシーン、メッシュごとに 1 つのノード、親子関係なし、再利用なしです。元の glTF が 1 つのボルトのメッシュを階層を通じて 40 回配置していたモデルは、40 個の頂点セットを持つ 40 個のメッシュになります。見た目は同じでファイルは大きくなり、インスタンス化を持たないすべての形式が強いる取引です。

Draco 圧縮されたジオメトリは、Draco を名指ししたメッセージとともに止まります。KHR_draco_mesh_compression は普通のバッファービューを圧縮ストリームに置き換えており、それを復号するにはここに同梱されていないライブラリが必要です。Draco なしでの再書き出しは、Blender ではチェックボックス 1 つ、gltf-transform ではフラグ 1 つです。

三角形ストリップ、ファン、線、点として保存されたジオメトリは変換されず飛ばされます。三角形のリストである glTF のモード 4 だけが対象だからです。それ以外を何も含まないファイルは、三角形のジオメトリが見つからなかったというメッセージで終わります。壊れた JSON ファイル——たいていダウンロードの途中で切れたことが原因です——は、何か適当なものに解析されるのではなく、読み込めないと報告されます。

埋め込まれた glTF はバッファーを base64 で保存しており、バイト 3 つにつき文字 4 つを消費します。同じジオメトリを GLB のバイナリチャンクへ移すとその上乗せがなくなるので、自己完結した glTF はたいてい変換だけで 4 分の 1 ほど縮みます。それ以外の計算をする前の話です。

そこからこの変換機が運ばないものすべてを差し引いてください。中身の大半がテクスチャだったモデルなら、GLB は元のごくわずかな一部になり、それに応じて中身が乏しくなります。変換後の妥当な確認方法は三角形数です。索引アクセサーの数を 3 で割った値が、元のソフトが報告した数と一致するはずで、一致しなければ元データは飛ばされた形式でジオメトリを持っていたことになります。

どこへも行きません。この組み合わせはページ内の普通の JavaScript として動き、取得すべき WebAssembly モジュールもモデルを運ぶ通信もありません。解析、変換行列の焼き込み、バイナリの組み立てはすべてあなたの端末で行われ、だから待ち行列もファイルごとの待ち時間もありません。

無料の上限は 100 MB で、自己完結した glTF はここで最もその上限に近づきやすい形式です。base64 が同じメッシュを保存する方法の中で最も膨らませるからです。その境界に近いなら、モデルを作ったツールから直接 GLB を書き出すほうがほぼ確実に良い結果になります。