最終更新: 2026年9月21日

ゲーム開発者向け画像ファイル形式:DDS、TGA、PNG、KTX
ゲーム開発において、テクスチャは実行時メモリ消費とインストール時のビルドサイズの両方で最大の割合を占めます。インディーのスタイライズドプラットフォーマーを作る場合でも、AAAオープンワールドRPGでフォトリアリズムを追求する場合でも、テクスチャデータの保存、処理、取り込み方法がフレームレート、ロード時間、ハードウェア互換性を直接左右します。
初心者がよく犯すミスは、ゲームのテクスチャをウェブ画像のように扱い、ディスク上の軽量ファイルがゲームエンジンでの軽量パフォーマンスにつながると想定することです。GPUの世界では、実行時の現実は全く異なります。
この深掘りでは、現代のゲーム開発において最も重要なテクスチャ・画像ファイル形式4つ、DDS、TGA、PNG、KTX を分解して解説します。これらがどのように機能し、アセットパイプラインのどこに位置し、いつ使用すべきかを検証します。
黄金律:ディスクストレージ vs. ビデオRAM(VRAM)
個々の形式を解析する前に、開発者は ディスクストレージ圧縮 と GPUハードウェアブロック圧縮 の根本的な違いを理解する必要があります。
1. ディスク圧縮 (PNG, JPEG, WebP)
PNG のような形式は、ロスレスエントロピーエンコーディング(DEFLATE)を使用します。PNG は SSD やダウンロードサーバー上で膨大な容量を節約できますが、最新の GPU は PNG ファイルを直接サンプリングできません。ゲームエンジンが PNG をロードする際は次のようになります:
- CPUはファイルを生の、非圧縮の32ビットRGBAピクセルにシステムメモリ上でデコードしなければなりません。
- 非圧縮のビットマップがVRAMにアップロードされます。
- 2048×2048のテクスチャは、ディスク上のPNGが1 MBであろうと3 MBであろうと、約16 MBのVRAMを消費します。
2. GPUブロック圧縮 (BCn, ASTC, ETC2)
専用GPUフォーマットは、固定サイズのピクセルブロック(通常は4×4ピクセルブロック)をより小さなビット表現に圧縮します。グラフィックスハードウェアは、CPU側でのデコードなしにこれらのブロックをVRAM内で直接サンプリングします。
- 実行時のデコードオーバーヘッドがゼロの、VRAMへの直接ランダムアクセス。
- 同じ2048×2048テクスチャをBC7/ASTCで使用すると、約4 MBのVRAMしか消費しません(75%削減)。
- ミップマップはコンテナファイルに直接埋め込むことができます。
DDSやKTXのようなコンテナは、これらGPUネイティブフォーマットをラップするために特別に作られています。一方、PNGやTGAはパイプラインの前段階で別々の役割を果たします。
1. DDS (DirectDraw Surface)
MicrosoftがDirectX 7と共に導入した、DirectDraw Surface (.dds) フォーマットは、PC、Xbox、コンソールゲーム開発における疑いの余地のない業界の主力です。
技術的特性
- コンテナタイプ: ネイティブGPUテクスチャコンテナ。
- サポートされる圧縮: BC1からBC7(ブロック圧縮 / DXT ファミリー)、非圧縮 RGBA、フロート形式(HDR 用 BC6H)。
- 主な機能: 事前生成されたミップマップ、キューブマップ、テクスチャ配列、ボリューム(3D)テクスチャ。
開発者がDDSを使用する理由
DDSは本質的に、グラフィックスハードウェアが必要とするものの直接メモリダンプです。事前生成されたミップマップを持つDDSテクスチャをロードすると、エンジンはCPUでのデ圧縮を完全にスキップし、Direct3DまたはVulkanのメモリコピーをGPUに直接発行します。これにより、ストリーミングやレベルロード時のCPUボトルネックが排除されます。
長所
- 驚異的に高速なロード時間: ランタイム時にデ圧縮CPUサイクルは不要です。
- 事前生成されたミップマップ: オフラインでのミップマップ生成により、アーティストがフィルタリング、シャープ化、LOD間の法線マップ正規化を制御できます。
- VRAM効率: 業界標準のBC圧縮アルゴリズムをネイティブに使用します。
欠点
- DirectX/Windows バイアス: 歴史的にMicrosoftエコシステムに結びついていますが、現代のデスクトップエンジンでも広くサポートされています。
- 非可逆圧縮アーティファクト: ブロック圧縮(特に法線マップのBC1)は、BC5/BC7を使用しない限りブロック状のノイズが生じる可能性があります。
- 限定的なモバイルサポート: モバイルGPUは通常、デスクトップのBCフォーマットよりもASTCやETC2を好みます。
2. TGA (Truevision ターガ)
1984年に作成された TGA (.tga) は、非圧縮またはランレングスエンコード(RLE)されたラスタ画像ファイル形式で、30年以上にわたりパイプラインの定番として堅持されています。
技術的特徴
- コンテナタイプ: 非圧縮のオーサリング/交換ビットマップ。
- ビット深度: 8、16、24、32ビット/ピクセル(RGB + 専用8ビットアルファチャンネル)。
- 圧縮: なし、または基本的なRLE(ランレングスエンコーディング)。
開発者がTGAを使用する理由
TGAは、その純粋な構造的シンプルさからテクニカルアーティストやエンジンプログラマーに好まれています。PNGがアルファチャンネルを複雑なフィルタリングマトリックスに埋め込むのとは異なり、TGAはカラー データとアルファチャンネルを完全に分離し、手を加えません。
カスタムマスクを作成する際(例:ラフネスを赤チャンネル、メタリックを緑チャンネル、アンビエントオクルージョンを青チャンネル、ハイトをアルファチャンネルにパックする場合)、TGA はチャンネル間で微妙なアルゴリズム的ブレンドや色のにじみが発生しないことを保証します。
利点
- 純粋なデータ忠実度: チャンネル値のビット単位での正確な保存;チャンネルパックされた ORM(Occlusion‑Roughness‑Metallic)テクスチャに最適です。
- 簡単なパース: 社内パイプラインツール、カスタムエクスポーター、そして自動スクリプトは、最小限のコード行で TGA ファイルの読み書きが可能です。
- 汎用 DCC サポート: Maya、3ds Max、Blender、Substance 3D、Photoshop は、ネイティブで手間のかからない TGA エクスポートを提供します。
欠点
- 巨大なファイルサイズ: Git/Perforce リポジトリでの膨大な容量と、分散チーム間での遅いダウンロード速度が問題です。
- ランタイムには不適切: 圧縮形式として GPU が直接使用できず、エンジンがクック時に変換する必要があります。
3. PNG (ポータブル・ネットワーク・グラフィックス)
PNG (.png) は世界で最も認知されたロスレス画像フォーマットで、zlib/DEFLATE 圧縮を利用して豊富な 24 ビットおよび 32 ビット画像を驚くほど小さなファイルにパックします。
技術的特徴
- コンテナタイプ: ロスレスの作成および配信フォーマット。
- ビット深度: チャンネルあたり最大16ビット(48ビットRGB、64ビットRGBA)。
- 圧縮: ロスレスDEFLATEアルゴリズム。
開発者がPNGを使用する理由
PNGはUIアセット、スプライト、プロモーション素材、そして中間ソーステクスチャの主要配布フォーマットとして機能します。Unity、Godot、またはUnreal Engineで作成された2Dゲームにおいて、PNGは鮮明なピクセル忠実度と完璧な透過マスクを提供します。
長所
- コンパクトなリポジトリフットプリント: 圧縮されていないTGAに比べてプロジェクトのチェックアウトサイズを大幅に削減します。
- ロスレスカラー品質: 高コントラストのエッジやベクタースタイルのイラストで圧縮アーティファクトがゼロです。
- ネイティブアルファ透過: 複雑な半透明UI要素やパーティクルシートに対してクリーンな8ビットアルファチャンネルをサポートします。
短所
- 重いCPUデコード: 実行時に大きなPNGを解凍すると、フレームレートが低下し、GPUアップロード前にメモリ使用量が急増します。
- 事前乗算アルファの落とし穴: 一部の画像エディタは完全に透明なピクセルのRGBデータを破棄し、テクスチャのブリーディングを壊し、スプライトに暗いアウトラインを生じさせます。
- ゼロVRAM節約: エンジンのテクスチャクッカーで取り込まれない限り、GPU内部でフル32ビットの生メモリにデ圧縮されます。
4. KTX(Khronos Texture)とKTX 2.0
Khronos Groupによって開発され—Vulkan、OpenGL、glTFの背後にいる統括組織—KTX (.ktx) と KTX 2.0 は、クロスプラットフォームGPUテクスチャのための最新のオープン標準を表します。
技術的特徴
- コンテナタイプ: 標準化されたオープンGPUテクスチャコンテナ。
- 圧縮サポート: Basis Universal(ETC1S と UASTC)、ASTC、BCn、ETC2。
- 主な機能: ユニバーサルテクスチャのトランスコーディング、ミップマップ、キューブマップ、配列テクスチャ、glTF統合。
開発者がKTXを使用する理由
KTX 2.0 は、断片化されたクロスプラットフォーム圧縮の課題を解決します。従来、開発者はデスクトップ/コンソール向けに DDS(BCn)を、モバイル/タブレット向けに ASTC/ETC2 を配布しなければなりませんでした。
KTX 2.0 と Basis Universal を使用すると:
- テクスチャをコンパクトでユニバーサルに圧縮可能なフォーマットで保存します。
- 実行時に、クライアントハードウェアはファイルをローカルGPUが好むブロック形式に直接トランスコードします(例:GeForce RTX の BC7、iPhone の ASTC、古い Android デバイスの ETC2)。
- スーパー圧縮(Zstandard)は、ディスク上で JPEG よりも小さいファイルを生成し、ミリ秒単位でネイティブ VRAM ブロックにトランスコードします。
長所
- 真のクロスプラットフォーム標準: Vulkan、WebGL、WebGPU、そしてモバイルデバイス上でシームレスに動作します。
- Basis Universal トランスコーディング: 1つのアセットビルドでデスクトップ、モバイル、ブラウザを対象にし、テクスチャの重複エクスポートが不要です。
- ファーストクラスの glTF コンパニオン: 現代の 3D Web エクスペリエンス、メタバースエンジン、オープンレンダリングパイプラインに不可欠です。
短所
- パイプラインツールの成熟度: 現代的なビルドチェーン(例: KTX-Software スイートの
toktx)が必要です。古い独自エンジンは標準での統合が欠けている場合があります。 - トランスコーダーのオーバーヘッド: 実行時のトランスコード遅延は僅かです(ただし、フル PNG ソフトウェアデコードに比べて桁違いに高速です)。
ヘッド・ツー・ヘッド比較
| 機能 / 基準 | DDS | TGA | PNG | KTX / KTX 2.0 |
|---|---|---|---|---|
| 主な使用例 | PC/コンソール ランタイム | ソースオーサリング & マスク | 2D スプライト & ソースアート | クロスプラットフォーム & Web ランタイム |
| ダイレクトGPUサンプリング | はい (ネイティブ) | いいえ | いいえ | はい (ネイティブまたはトランスコード) |
| VRAM圧縮 | はい (BC1–BC7) | いいえ (非圧縮) | いいえ (非圧縮) | はい (ASTC, BCn, Basis) |
| 事前ベイク済みミップマップ | はい | いいえ | いいえ | はい |
| ディスクサイズ | 中程度 | 非常に高い | 小さい | 極めて小さい (Basis + Zstandard) |
| エコシステム | DirectX / デスクトップエンジン | DCC ソフトウェア / ソースパイプライン | ユニバーサル Web & 2D エンジン | Vulkan、WebGPU、glTF |
実践ガイド:理想的なアセットパイプラインの構築
商業制作パイプラインでこれら4つのフォーマットをどのように整理すべきでしょうか?以下はトップスタジオがテクスチャパイプラインを構築する方法です:
[DCC & Authoring] [Engine Ingestion / Cook] [Runtime GPU Target]
Substance / Photoshop / Blender Unreal / Unity / Custom Toolset VRAM Memory Blocks
• TGA (Clean packed masks) ──────► Build Engine Texture Cooker ──────► DDS (DirectX / Windows / Xbox)
• PNG (UI & 2D Sprites) ──────► Generates Mipmaps & Block ──────► KTX2 (Vulkan / WebGPU / Mobile)
• PSD / EXR (HDR & masters) ──────► Compression Automatically
- Source Assets: マスターファイルとチャンネルパックされたデータをプロジェクトリポジトリ内の TGA または PNG で保存し、色情報の破損を防ぎます。
- PC & Console Builds: ソーステクスチャを DDS ファイルに変換し、ハイディテールのアルベド/ノーマルマップには BC7、シングルおよびデュアルチャンネルマスクには BC4/BC5 を使用します。
- Cross-Platform, Web & Mobile Builds: ランタイムの 3D アセットを KTX 2.0 にパッケージ化し、Android、iOS、WebGPU 間でユニバーサルなトランスコーディングを活用し、別個のアートブランチを維持しないようにします。
- User Interfaces: ランタイム UI テクスチャは、鮮明な非圧縮フォーマットか、高解像度 PNG ソースファイルから派生したロスレスエンジンアトラスのいずれかで保持します。
よくある質問 (FAQ)
Q1. ゲームエンジンはビデオメモリから直接PNGをサンプリングできますか?
A1: いいえ。GPU は PNG 圧縮を解析できないため、エンジンは PNG ファイルをメモリ内の生の 32 ビットビットマップにデコードしてから VRAM にアップロードする必要があります。
Q2. テクニカルアーティストがマスクパッキングにPNGよりTGAを好む理由は何ですか?
A2: TGA は、個々の RGB およびアルファチャンネル全体で、色のにじみや破壊的なエッジ透明度フィルタリングなしに、純粋で非圧縮のチャンネルデータを保存します。
Q3. 法線マップ用のDDSコンテナ内でどのブロック圧縮アルゴリズムを使用すべきですか?
A3: 法線マップには BC5(2 チャンネルタンジェント空間圧縮)を使用し、標準的な BC1 ブロックアーティファクトなしでクリーンな表面曲率を保持します。
Q4. クロスプラットフォームゲームにおいてKTX 2.0がDDSより優れている点は何ですか?
A4: KTX 2.0 は Basis Universal をサポートしており、単一ファイルが起動時にデスクトップ向け BCn フォーマットまたはモバイル向け ASTC/ETC フォーマットへオンザフライでトランスコードできるようにします。
Q5. DDSまたはKTXファイルでミップマップを事前ベイクするとディスクサイズが増加しますか?
A5: はい、完全なミップマップチェーンを含めるとファイルの生データが約 33% 増加しますが、実行時のシマーリングを排除し、キャッシュ局所性を向上させ、GPU のレンダリング性能を向上させます。