3Dモデルはなぜこんなに重いのか？

あなたのモデルは密かに太っている

GLBファイルをエクスポートした。10MB、まあ許容範囲だ。スマホに転送して開いてみる——白画面、カクつき、最悪の場合クラッシュ。

PCでは問題ないのに、スマホだと爆発する。これはコードのせいではない。3Dモデルには直感に反する特性がある：ディスク上とVRAM上では、サイズがまったく違うのだ。

JPG画像はディスク上で200KBしかないかもしれない。しかしGPUはJPGを知らない。GPUが理解できるのは生のピクセルデータだけだ。そのため、VRAMにアップロードされる前に、画像は完全に解凍される。2048x2048のテクスチャは、解凍後におよそ22MBのVRAMを消費する。6枚のテクスチャ（albedo、normal、roughness、metallic、AO、emissive）を使えば、マテリアル1つで132MBになる。

スマホのVRAMは合計2〜4GB程度。1つのモデルのテクスチャだけで3〜6%を消費する。シーンに10モデルあったら？

分解してみる——サイズの内訳

典型的なGLBモデルは主に3つの要素で構成される：頂点データ、テクスチャマップ、そしてメタデータとアニメーションだ。

実際のPBRモデルで見てみよう：

構成要素	具体的な内容	典型的な割合	説明
テクスチャマップ	albedo、normal、roughness、metallic、AOなど	70-85%	ほぼ常に最大の容量要因
頂点データ	position、normal、UV、tangent、色	10-20%	モデルの複雑さに依存
アニメーションデータ	ボーン、スキニング、キーフレーム	0-15%	アニメーションがある場合のみ
その他	マテリアル定義、シーン構造、カメラ	< 2%	無視できるレベル

テクスチャマップが約80%を占めている。最適化すべきは頂点だと思いがちだが、実際に場所を取っているのはテクスチャなのだ。

「ディスクが小さい」≠「VRAMが小さい」

3Dパフォーマンスを理解する上で、これが最も重要なポイントかもしれない。

PNGとJPGはネットワーク転送用に設計されている——ディスク上では小さく、ダウンロードが速い。しかしGPUはそれらを直接使えない。必ず生のピクセルデータに完全解凍する必要がある。計算方法：

VRAM使用量 = 幅 * 高さ * 4バイト(RGBA) * 1.333(mipmap込み)

4096x4096のRGBAテクスチャの場合：

指標	数値
PNGファイルサイズ	~8MB
JPGファイルサイズ	~1.5MB
VRAM使用量（mipmap込み）	~87MB

1.5MBのJPGが、VRAM上では87MBになる。

Mipmapとは？ GPUはテクスチャの段階的に縮小されたバージョンを生成する。元のサイズから1x1ピクセルまで、各レベルは前のレベルの半分だ。これにより遠くのオブジェクトのレンダリングが高速かつクリアになるが、VRAMを約33%余分に消費する。ほぼすべての3Dアプリケーションがmipmapを使用するため、このオーバーヘッドは標準的なものだ。

つまりPNG/JPGは旅行用圧縮袋のようなものだ——圧縮すれば小さくて持ち運びに便利だが、目的地ではすべて広げなければならない。ダウンロードは速くなるが、VRAMはまったく節約できない。

VRAM不足で何が起こるか

「VRAM不足」というダイアログボックスは表示されない。実際の状況はもっと悪い：

• モバイル：白画面、またはOSがタブを強制終了
• VRヘッドセット：フレーム落ち。VRでのフレーム落ちは「ちょっとカクつく」ではなく、吐き気を引き起こす
• デスクトップ：テクスチャのちらつき、品質低下、レンダリングの遅延

Redditのある開発者はWebXRギャラリーを作り、Questに60枚のステレオ画像を詰め込んだ。最初は正常だったが、次第に不安定になり、最終的にクラッシュした。彼は数日かけてコードを調べたが、最後にVRAMのことを真剣に考えたことがなかったと気づいた——ただひたすらGPUにJPGを詰め込んでいただけだった。

圧縮の2つのアプローチ

3Dモデル圧縮には主に2つの方向性がある：

頂点圧縮——頂点座標、法線、UVなどのジオメトリデータをよりコンパクトな形式で格納する。例えば32ビット浮動小数点数を16ビット整数に変換する（これを量子化、quantizationと呼ぶ）。代表的なソリューション：Draco、MeshOpt、KHR_mesh_quantization。

テクスチャ圧縮——テクスチャをVRAM上でも圧縮状態に保つ。GPUはサンプリング時に個々のピクセルをリアルタイムでデコードするため、パフォーマンスのオーバーヘッドはほぼない。代表的なソリューション：KTX2 + Basis Universal。

	頂点圧縮	テクスチャ圧縮
削減対象	ジオメトリデータ	テクスチャ
典型的な効果	50-90%削減	ディスク50-70%削減、VRAM 75%削減
非可逆か	はい、精度低下	はい、画質低下
適したシナリオ	頂点密度の高いモデル	ほぼすべてのPBRモデル
詳細	第2回	第3、4回

よくある誤解：Dracoで頂点を圧縮すれば万事解決だと思うこと。しかしテクスチャがモデルの80%を占めているのに、頂点を半分に減らしても、全体では10%しか軽くならない。両方を管理する必要がある。

すべてのシナリオに効く万能薬はない

これがシリーズ全体の核となる主張だ：

プラットフォーム、デバイス、使用方法が異なれば、必要な圧縮戦略も異なる。

シナリオ	主要なボトルネック	重点的に注目すべき点
デスクトップWeb表示	ダウンロード速度	ファイルサイズ
モバイルブラウザ	VRAM	テクスチャ圧縮
VRヘッドセット	VRAM + フレームレート	テクスチャ圧縮 + 頂点簡略化
モバイルアプリ	パッケージサイズ + 互換性	軽量ソリューション（MeshOpt）
大規模シーン	VRAM + draw call	全方位圧縮 + LOD

以降の各回では「Xを使えばいい」とだけ言うのではなく、Xがどのようなシナリオに適しているのか、いつ逆効果になるのか、どのような場合にYを使うべきなのかを明確に説明する。

次のステップ

今回は問題を明確にした。次回は実践だ——頂点圧縮の3つのツールを紹介する：量子化、MeshOpt、そしてDracoだ。