テクスチャリングに最適な（最も人気のある）画像形式[非公開]

さて、OpenGLでC ++を使用しています。3Dゲームのテクスチャを読み込むローダーを作成します。（ただし、テクスチャは2Dです）。使用しないことにしたとしても、透明性のオプションが必要です。最高の品質である必要はありませんが、適切な品質が必要です。フォーマットについて何を提案しますか（PNG、TGAなど）。また、ローダーを簡単に作成できるものにすることもできます（作成済みのローダーは使用しません）。また、ローダーを支援するためのリンク/ヒントがあれば、それを歓迎します。

既製のローダーを使用したくない理由がわかりません。たとえば、PNGは形式に適していますが、汎用ローダーを作成するのは複雑です（おそらく、気になるPNG形式の特定のサブセットのみを読み込むものを作成する労力はありません）。

やや珍しい要件を考えると、おそらくTGAが最善の策です。TGA 2.0にはアルファチャネルがあり、PNGと比較して比較的単純です。

画像テクスチャ形式もパフォーマンスの選択肢です。可能な限り圧縮テクスチャを使用することをお勧めします。モバイルプラットフォームでは、パフォーマンス（40％以上）、メモリ使用量、ロード時間を大幅に改善できます。

テクスチャ1024 * 1024を考えます：

• RGBまたはRGBA（16ビット）：2Mo（SGSに読み込むには0.5秒）
• RGBA（32ビット）：4Mo（1秒でSGSにロード）
• PVRT（4bpp）：512ko（SGSにロードするには.125秒）
• ETC1 + Alpha：1.5Mo（SGSに読み込むには0.4秒）

ゲームには、さまざまな形式のアセット（テクスチャ）があります。

• DXTCテクスチャのDDS形式（デスクトッププラットフォーム：OS X、Linux、WindowsおよびTegra）
• ATCテクスチャ（Andreno GPU）のDDS形式
• PVRT形式のPVR形式（PowerVR GPU）
• ETC1テクスチャのPKM形式（すべてのOGLES 2.0デバイスと互換性あり）

最後に、互換性のために生のフォーマットを使用しますが、それは互換性またはGUI要素のためです

• 生のテクスチャのPNG形式。RGBA 16、24、または32ビットテクスチャ用です（MITライセンスローダーを使用します）。非圧縮テクスチャです。

ETC1テクスチャにはアルファチャネルがないため、2つのテクスチャ（rgbテクスチャとアルファテクスチャ）を持つ特別なシェーダーを使用します。圧縮形式は非常に簡単にロードできます（100または200 loc）。

デスクトップでは、多くのカードにDXTC（S3TC）が存在します。だから、あなたはそれを使用する必要があります。

圧縮テクスチャ

プロ

• テクスチャ塗りつぶしの改善
• テクスチャの読み込み（4x以上）
• 簡単にロード

コン

• すべてのプラットフォームでサポートされていない
• アーティファクト

テクスチャは、1つ以上の画像のコレクションです。つまり、テクスチャは TGAまたはPNGで表現できますが、どちらの形式もテクスチャのすべての機能を表現することはできません。どうして？

それぞれが単一の画像しか保持できないためです。ミップマップはありません。可能な3Dテクスチャはありません。配列テクスチャなし。キューブマップはありません。これらの各ファイルは、単一の2D画像です。これらはテクスチャの一部になることができますが、ミップマッピングを使用していない限り（および特定のニーズがない限りミップマップを使用しないことを強くお勧めします）、これらの形式の単一の画像ファイルはテクスチャにはなりません。

これらは優れた画像形式ですが、質の低いテクスチャ形式になります。

DDSは、テクスチャが必要とするものを実際にサポートしているため、テクスチャフォーマットのトップランナーです。ミップマップとキューブマップをサポートしています。3Dテクスチャをサポートしています。DDSv10は配列テクスチャをサポートしています。PNGまたはTGAではできない方法で、DDS内に単一のテクスチャをパッケージ化できます。

DDSは、非圧縮および圧縮テクスチャデータをサポートしています。圧縮テクスチャ形式がDXT / BCテクスチャ形式の1つである限り。

PKMは、ETC1で圧縮された画像のパッケージ化に役立ちますが、PNGと同様に、実際のテクスチャ機能をサポートしていません。

PVRファイルはDDSのモバイル版と思われます（DDSを使用できない理由はわかりませんが）。さまざまな圧縮技術をサポートしていますが、配列テクスチャなどの高度なDDSv10機能や3Dテクスチャサポートがありません。

したがって、DDSは包括的なテクスチャサポートの点で勝ちます。

Khronos Groupは、OpenGLおよびOpenGL ESアプリケーションのテクスチャを保存するためにKTXファイル形式を推奨しています。この形式での作業にはlibktxを使用できます。

特徴：

• KTXファイルからOpenGLテクスチャをインスタンス化する
• ハードウェアがETC1をサポートしていない場合、ETC1圧縮テクスチャイメージを解凍します。
• テクスチャのロード時にKTXファイルからキーと値のペアのハッシュテーブルを作成します
• ソースイメージの配列とキーと値のペアのオプションのハッシュテーブルからKTXファイルを作成します。
• キーと値のペアのハッシュテーブルを構築してデータを入力します。

それはのように思えるDDS（DirectDrawのサーフェス）現時点でのテクスチャのための最も人気のある選択肢です。異なるピクセル形式、透明度、および圧縮があります。OpenGLでは、GL_ARB_texture_compression拡張機能を通じてサポートされています。

たとえば、ここにはOpenGLローダーがあります。

ここには多くの考慮事項があります。

1. ディスクからシステムメモリにテクスチャを取得する速度。
2. システムメモリからGPUにテクスチャを取得する速度（ケースではglTexImage2Dを使用）。
3. 予算内のディスク容量とビデオRAMストレージの量。
4. パフォーマンスと品質。

TGAは、24ビットおよび32ビットの非圧縮の場合、単一の読み取り/読み取りでデータを読み取り、それ以上処理せずに結果をglTexImage2Dから直接送信できるため、適切な選択です。ファイルサイズが最大になる可能性があり、ディスクI / Oがボトルネックの場合、読み取りが遅くなるため、これは悪い選択です。

PNGは、適度に小さいファイルサイズで画像の品質を保持するため、適切な選択です。PNGは解凍に時間がかかる場合があるため、これは悪い選択です-もしそれがあなたのボトルネックであるなら-よく、あなたは知っています。

通常、JPGはファイルサイズが最小であり、ディスクから非常に高速に削除されるため、ネットワークにファイルを送信する必要がある場合に最適です。中間ソフトウェアの解凍手順と品質低下のため、これは悪い選択です（ただし、品質設定を調整してこれを軽減できます）。アルファチャンネルもありません。

DDS（または他の圧縮形式）は、ファイルサイズが小さく、作成済みのミップマップチェーンを含めることができるため、適切な選択です。ハードウェアでネイティブにサポートされている形式の場合（およびDDSはほとんどのコンシューマPCハードウェアでネイティブにサポートされています-長い間もそうでした）、TGAと同じ利点が得られます-理解するためにヘッダーを少し突く一部の画像プロパティは、中間ステップなしでデータを直接送信します。また、圧縮されたテクスチャは、プログラムの実行を高速化し、使用するビデオRAMを減らします。これらは非可逆圧縮を使用するため（これは非常に目立つ場合があります）、すべてのハードウェアでサポートされていない可能性があるため、悪い選択です。

私なら、これら4つの形式すべて（TGAとDDSはローダーを書くのは非常に簡単で、JPGとPNGでは画像ライブラリを使用します）のサポートを構築して、コンテンツ作成者が最も適切な形式を選択できるようにしますテクスチャごと。

そしてもちろん、本当に簡単にロードできる古い32ビットBMPを使用できます（特に、サイズが2のべき乗（実際、8バイトの倍数IIRC）の場合）。

それ以外の場合、1つのフォーマットのみが必要なのは奇妙に思えます、jpgは実際の高解像度テクスチャ（jpegはディスクスペースと（ダウン）ロード時間で驚異的です）、透過性のpngと制御テクスチャの時折の32ビットBMPには本当にクールです（スクリプトまたは「高速でダーティな」ツールから簡単に作成できます）。