【ゲーム制作】3DモデルはなぜGLBが良いのか｜FBX・OBJ・glTFと徹底比較

今回は、ゲーム制作でよく迷う「3Dモデルのファイル形式は結局どれがいいのか」について解説していきます。

「FBX？OBJ？glTF？どれを使えばいいの？」
「モデルを読み込んだらテクスチャが真っ白…」
「アセットのファイルが多すぎて管理がつらい」

こんな疑問はありませんか？

結論から言うと、個人開発で自作エンジンやDirectXを触るなら、私はGLBをおすすめします。理由は「アセット管理がシンプル」「ロードが速い」「業界標準」の3点です。

この記事を読み終えると、あなたは主要なモデル形式の違い・GLBを選ぶ理由・GLBの中身の仕組み・初心者がハマりやすいミスをしっかり理解できると思いますので、ぜひ最後まで読んでいただけると嬉しいです。

主要なモデル形式を比較
GLBを選ぶ理由①：アセット管理がシンプル
GLBを選ぶ理由②：ロードが速い
GLBを選ぶ理由③：業界標準
【重要】私が実際にモデル形式で困った体験談
GLB使用時のよくある失敗例と対処法
注意点
まとめ
関連記事

主要なモデル形式を比較

まず、よく使われる形式を並べてみます。

形式	中身	スケルトン	テクスチャ	特徴
OBJ	テキスト	×	別ファイル	単純だがアニメ不可
FBX	バイナリ	○	別ファイル参照	DCC間の定番だが仕様が非公開
glTF	JSON＋別ファイル	○	別ファイル	中身が見えて編集しやすい
GLB	バイナリ1個	○	内包	1ファイル完結。実行時向き

GLBはglTFのバイナリ版です。glTFが「JSON＋バイナリ＋テクスチャ画像」と複数ファイルに分かれるのに対し、GLBはそれを1つのファイルにまとめたものだと思ってください。

GLBを選ぶ理由①：アセット管理がシンプル

最大のメリットがこれです。GLBはメッシュ・スケルトン・マテリアル・テクスチャが1つのファイルにまとまっています。

【FBXの場合】バラバラ
assets/
  player.fbx
  player_albedo.png
  player_normal.png
  player_metallic.png   ← どれか消すと壊れる

【GLBの場合】1個で完結
assets/
  player.glb            ← 全部入り

FBXやOBJは、テクスチャを「このパスにある画像を見てね」と参照しているだけです。そのため、フォルダ構成を変えたりファイルを移動しただけでテクスチャ参照が切れて真っ白になります。

GLBなら参照ではなく中に入っているので、そもそも切れようがありません。ファイルを1個コピーすれば移植完了です。

GLBを選ぶ理由②：ロードが速い

2つ目の理由が、読み込みの速さです。ここがGLBの構造の巧いところで、JSON部分とバイナリ部分がきれいに分離されています。

┌──────────────┐
│ ヘッダ        │ magic / version / 全体サイズ
├──────────────┤
│ JSONチャンク  │ どこに何があるかの情報（構造・マテリアル）
├──────────────┤
│ BINチャンク   │ 頂点・インデックス・テクスチャの生データ
└──────────────┘

JSON側には「頂点データはBINチャンクの何バイト目から何バイト分」という情報だけが書かれています。つまり読み込み側は、

JSONを読んで位置とサイズを把握する
BINチャンクの該当部分をそのままGPUバッファへコピーする

という流れで済みます。数値を1つずつ文字列から変換する処理が要らないのが効きます。

比較すると分かりやすいです。OBJのようなテキスト形式は、v 1.0 2.0 3.0 という文字列を1行ずつ解析して数値に変換しなければなりません。頂点が10万個あれば、その変換を10万回です。GLBはその工程がまるごと不要になります。

// GLBならイメージとしてはこう（位置とサイズが分かればコピーするだけ）
const uint8_t* src = binChunk + accessor.byteOffset;
memcpy(vertexBufferPtr, src, accessor.byteLength);

// テキスト形式だと1行ずつ解析が必要
// v 1.0 2.0 3.0  →  文字列を数値に変換 → 配列に詰める（頂点数だけ繰り返す）

GLBを選ぶ理由③：業界標準

3つ目は標準規格であることです。glTF / GLBはKhronos Groupという団体が策定したオープン規格で、仕様が完全に公開されています。

仕様が公開されているので、自作ローダーを書ける
Blender・Unity・Unrealなど主要ツールが標準対応
ライブラリが充実（cgltf、tinygltf など）

対してFBXはAutodeskの独自形式で、公式SDKを使わないと正確に読めません。「3Dのやり取りにおけるJPEG的な立ち位置」を目指して作られたのがglTFで、実際そうなりつつあります。

【重要】私が実際にモデル形式で困った体験談

自作エンジンで最初にFBXを採用したとき、Blenderでは正しく見えるのに、自分のエンジンだとモデルが真っ白という状態に何度もなりました。

原因はほぼ毎回テクスチャの参照パス。FBXの中には「C:Users...Desktoptexbody.png」のような作った人の環境の絶対パスが埋まっていて、当然こちらの環境には存在しません。アセットをフォルダ整理するたびに壊れるのも地味に効きました。

GLBに切り替えたら、この手のトラブルが丸ごと消えました。テクスチャが中に入っているので、参照が切れる余地がないんです。「1ファイルにまとまっている」ことの価値を実感した出来事でした。

もう一つ。GLBに変えた直後、モデルの色がなんとなく濃いのが気になったことがあります。これはテクスチャの色空間（sRGB）の扱いを間違えていたのが原因でした。ベースカラーはsRGB、法線マップはリニア、と使い分ける必要があります。

GLB使用時のよくある失敗例と対処法

①編集しづらいのに編集しようとする

GLBはバイナリなので中身を直接見て直せません。デバッグ中はテキストの glTF（.gltf）で確認し、完成したらGLBに書き出すという使い分けが便利です。

②テクスチャを共有したいのに全部内包する

1ファイル完結は裏を返すと、同じテクスチャを複数モデルで使っても、それぞれに入ってしまうということです。容量が気になる規模なら、共有テクスチャは外に出す構成も検討しましょう。

③色空間（sRGB / リニア）を間違える

体験談のとおり、色が濃くなったり薄くなったりします。ベースカラーはsRGB、法線・メタリック・ラフネスはリニアで読み込むのが基本です。

注意点

制作中は .gltf、配布・実行時は .glb の使い分けが快適
DCCツール間のやり取りではまだFBXが必要な場面もある
自作ローダーを書くならcgltf / tinygltf を使うと早い

まとめ

GLBはメッシュ・スケルトン・テクスチャが1ファイルに完結
テクスチャ参照が切れないのでアセット管理がシンプル
JSONとバイナリが分離され、パース後すぐGPUへコピーできて速い
Khronosのオープン規格で仕様が公開・ツール対応も広い

迷ったらGLB、で大きく外しません。まずはBlenderから .glb で書き出して、自作エンジンに読み込ませるところから試してみてください。