問題タブ [dxt]

DXT/S3TC 形式 (具体的には DXT5) を使用して圧縮する必要がある複数の画像を扱っています。

リアルタイム圧縮を提供する DXT 圧縮の実装 (できれば C# または .Net フレームワークを使用) を知っている人はいますか? 私のアプリケーションは、一度に 10 ～ 20 個の 512x512 画像を圧縮するので、比較的高速な実装があれば、それが必要です。検索して検索しましたが、見つからないようです。何らかの理由で、独自の実装を作成するのに十分な DXT5 形式に頭を悩ませることができません。

XNA フレームワークが DXT 圧縮をサポートしていることは知っています。それがかなり速いかどうか誰かが知っていますか？私のアプリケーションを使用するために、人々は XNA をインストールする必要がありますか?

ご協力いただきありがとうございます。:)

私は現在Imagesを使用しており、一部はDXT圧縮されています。これらのファイルを、Pythonで解凍および圧縮する簡単な方法が必要です。残念ながら、私のためにそれを行うライブラリを見つけることができませんでした。

Python用の優れたDXT-Compressionライブラリ、または圧縮ライブラリへのインターフェイスを知っている人はいますか？

--dav1d

編集：

libsquishがここに行く方法でしたが、残念ながらPython-Bindingsは機能しないので、ここで解決策を示します。

libsquishに内部的にアクセスする関数をエクスポートするC++でsquish-Wrapperを作成します。

ダイナミックライブラリ（Windowsではdll、Linuxではdllなど）を作成し、libsquishc.soで開きますctypes。

私のアプローチ（必要な関数をエクスポートするだけです）：

コンテキスト: DXT 圧縮テクスチャ データを読み取り、Unity でさらに使用するために GPU にアップロードするネイティブ C++ Unity 5 プラグインを開発しています。目的は、オンザフライで画像データを更新する高速な画像シーケンス プレーヤーを作成することです。テクスチャは、オフライン コンソール アプリケーションで圧縮されます。Unity はさまざまなグラフィック エンジンで動作します。私は DirectX11 と OpenGL 3.3+ を目指しています。

問題: DirectX ランタイム テクスチャ更新コードは、マップされたサブリソースを介して、さまざまなグラフィックス ドライバーでさまざまな出力を提供します。このようなマップされたリソースを介してテクスチャを更新することは、ポインタをテクスチャ データにマップし、RAM バッファからマップされた GPU バッファにデータを memcpy することを意味します。そうすることで、ドライバーが異なれば、バイトをコピーするときに行ピッチ値に異なるパラメーターを期待しているように見えます。テストしたいくつかの Nvidia GPU で問題が発生したことはありませんが、AMD と Intel GPU は動作が異なるようで、下に示すように歪んだ出力が得られます。さらに、DXT1 ピクセル データ (0.5bpp) と DXT5 データ (1bpp) を使用しています。これらの DXT テクスチャの正しいピッチ パラメータを取得できないようです。

コード: d3d11 テクスチャを生成し、初期テクスチャ データ (イメージ シーケンスの最初のフレームなど) で埋めるための次の初期化コードは、すべてのドライバで完璧に機能します。プレーヤー ポインターは、すべてのファイルの読み取りを処理し、現在読み込まれている DXT 圧縮フレーム、そのサイズなどのゲッターを含むカスタム クラスを指します。

新しいフレームごとに実行される次の更新コードには、どこかにエラーがあります。NVIDIA ドライバーでうまく機能する行ピッチを指定せずに単純な memcpy を使用する方法 1 を含むコメント行に注意してください。
方法 2 で、さまざまな行ピッチ値をログに記録していることがわかります。たとえば、1920x960 フレームの場合、バッファ ストライドは 1920、ランタイム ストライドは 2048 になります。この 128 ピクセルの差はおそらくパディングする必要があります (下の例の写真に見られるように) が、その方法がわかりません。4 で割らずに（ビットシフトで）mappedResource.RowPitch を使用すると、Unity がクラッシュします。

例 pic 1 - AMD/INTEL で個別の行ピッチを使用せずに memcpy を使用してバッファ全体をコピーすると、出力が歪む (方法 1)

例の写真 2 - 上記のコードを AMD/INTEL で mappingResource.RowPitch と一緒に使用した場合 (方法 2)、より良いが、依然として誤った出力。青いバーはエラーのゾーンを示しており、すべてのピクセルが適切に整列して 1 つの画像を形成するように非表示にする必要があります。

ご指摘ありがとうございます。ベスト、ヴィンセント

OpenGL4.x の別々のチャネルで異なる圧縮アルゴリズムを使用して RGBA テクスチャを作成して読み取ることは可能ですか?

本当の意味のない例 A:

1. RGチャンネルは、3Dc でエンコードされた法線マップを格納します
2. Bチャネルには、エンコーディングを使用したテッセレーションなどの高さの値が格納されます
3. チャネルは未加工のMaterialID を圧縮せずに保存します

例 B:

1. RGBは DXT1 で圧縮されたマテリアル パラメータを保存します
2. Aは MaterialID を圧縮せずに保存します

バックグラウンド：

15 ページと 18 ページのPhysically Based Rendering PBR (PDF)の Frostbite 実装で、著者はマテリアル パラメータをさまざまなテクスチャ チャネルにどのように構造化したかを説明しています。彼らはまた、一部のチャンネルでテクスチャ圧縮を回避したことにも言及しており、それが意味するチャンネルの詳細については触れていません。

15ページ

ディファード デカールをサポートするには、すべての基本属性 (Normal、BaseColor、Smoothness、MetalMask、Reflectance) をブレンド可能にする必要があります。MaterialId などのブレンド不可能な属性は、アルファ チャネルに格納されます。また、ブレンドの品質に影響を与える可能性のある圧縮およびエンコードのメカニズムも回避しました。

18ページ

この場合、いくつかの属性で圧縮を回避し、単純な線形補間アルファ ブレンディングに依存することを選択しました。

DX10 では、Y 値をグリーン チャネルに配置し、X 値をアルファに配置して法線マップを圧縮し、DXT5 圧縮を適用するのが一般的です (その後、Z コンポーネントがシェーダーで再構築されます)。Vulkan で対応する形式は何ですか? 最も近いのは VK_FORMAT_BC5_UNORM_BLOCK で、これは DXT5 の署名なし RG チャネルです。これは同等ですか？もしそうなら、R: X と G: Y として保存しますか、それともその逆ですか? それとも、より良い仕事をする新しい圧縮形式はありますか?