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

ゲーム制作
2026/7/28

FBX、OBJ、glTF。3Dモデルのファイル形式は、結局どれを選べばよいのでしょうか。モデルを読み込んだらテクスチャが真っ白になった、アセットのファイルが多すぎて管理がつらい、という悩みも、形式選びと深く関係しています。

結論から言うと、個人開発で、自作エンジンやDirectXを触るなら、私はGLBをおすすめします。理由は、「アセット管理がシンプル」「ロードが速い」「業界標準」の3点です。この記事では、主要なモデル形式の違い、GLBを選ぶ理由、GLBの中身の仕組み、初心者がハマりやすいミスを解説します。

主要なモデル形式を比較

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

形式中身スケルトンテクスチャ特徴
OBJテキスト×別ファイル単純だがアニメ不可
FBXバイナリ○別ファイル参照DCC間の定番だが仕様が非公開
glTFJSON＋別ファイル○別ファイル中身が見えて編集しやすい
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個コピーすれば移植完了です。

DirectXでsowrd.glbを読み込んで描画した3Dモデル
実際に自作のDirectXプロジェクトで asset/model/sowrd.glb を読み込んで描画した結果。メッシュもマテリアルも1ファイルに入っているので、この.glb1つを置くだけで表示できます。

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

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

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

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

  1. JSONを読んで位置とサイズを把握する
  2. 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\...\Desktop\tex\body.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は、テクスチャ参照が切れないので、アセット管理がシンプルです。JSONとバイナリが分かれていて、パース後すぐGPUへコピーできるので、読み込みも速くなります。Khronosのオープン規格で、ツール対応も広いので、迷ったらGLB、で大きくは外しません。

関連記事