Blockkomprimierung (Direct3D 10)
Die Blockkomprimierung ist eine Texturkomprimierungstechnik zum Reduzieren der Texturgröße. Im Vergleich zu einer Textur mit 32 Bits pro Farbe kann eine blockkomprimierte Textur bis zu 75 Prozent kleiner sein. Anwendungen sehen in der Regel eine Leistungssteigerung, wenn die Blockkomprimierung aufgrund des geringeren Speicherbedarfs verwendet wird.
Die Blockkomprimierung funktioniert zwar verlustbeend, funktioniert aber gut und wird für alle Texturen empfohlen, die von der Pipeline transformiert und gefiltert werden. Texturen, die direkt dem Bildschirm zugeordnet sind (Benutzeroberflächenelemente wie Symbole und Text), sind keine gute Wahl für die Komprimierung, da Artefakte merklicher sind.
Eine blockkomprimierte Textur muss in allen Dimensionen als Vielfaches der Größe 4 erstellt werden und kann nicht als Ausgabe der Pipeline verwendet werden.
- Wie funktioniert die Blockkomprimierung?
- Verwenden der Blockkomprimierung
- Komprimierungsalgorithmen
- Formatkonvertierung mit Direct3D 10.1
- Zugehörige Themen
Wie funktioniert die Blockkomprimierung?
Die Blockkomprimierung ist eine Technik, mit der die Menge an Arbeitsspeicher reduziert wird, die zum Speichern von Farbdaten erforderlich ist. Indem Sie einige Farben in ihrer ursprünglichen Größe und andere Farben mithilfe eines Codierungsschemas speichern, können Sie den zum Speichern des Bilds erforderlichen Arbeitsspeicher erheblich reduzieren. Da die Hardware komprimierte Daten automatisch decodiert, gibt es keine Leistungseinbußen bei der Verwendung komprimierter Texturen.
Sehen Sie sich die folgenden beiden Beispiele an, um zu sehen, wie die Komprimierung funktioniert. Im ersten Beispiel wird die Menge an Arbeitsspeicher beschrieben, die beim Speichern von nicht komprimierten Daten verwendet wird. Im zweiten Beispiel wird die Menge an Arbeitsspeicher beschrieben, die beim Speichern komprimierter Daten verwendet wird.
Speichern von nicht komprimierten Daten
Die folgende Abbildung stellt eine unkomprimierte 4×4-Textur dar. Angenommen, jede Farbe enthält eine einzelne Farbkomponente (z.B. Rot) und wird in einem Byte Arbeitsspeicher gespeichert.

Die nicht komprimierten Daten werden sequenziell im Arbeitsspeicher angeordnet und erfordern 16 Bytes, wie in der folgenden Abbildung dargestellt.

Speichern komprimierter Daten
Nachdem Sie nun gesehen haben, wie viel Arbeitsspeicher ein nicht komprimiertes Bild verwendet, sehen Sie sich an, wie viel Arbeitsspeicher ein komprimiertes Image speichert. Das BC4-Komprimierungsformat speichert 2 Farben (jeweils 1 Byte) und 16 3-Bit-Indizes (48 Bits oder 6 Bytes), die zum Interpolieren der ursprünglichen Farben in der Textur verwendet werden, wie in der folgenden Abbildung dargestellt.

Der zum Speichern der komprimierten Daten insgesamt erforderliche Speicherplatz beträgt 8 Byte, was gegenüber dem nicht komprimierten Beispiel eine Speichereinsparung von 50 Prozent darstellt. Die Einsparungen sind noch größer, wenn mehr als eine Farbkomponente verwendet wird.
Die erheblichen Speichereinsparungen durch die Blockkomprimierung können zu einer Leistungssteigerung führen. Diese Leistung geht auf Kosten der Imagequalität (aufgrund der Farbinterpolation). die niedrigere Qualität ist jedoch häufig nicht wahrnehmbar.
Im nächsten Abschnitt erfahren Sie, wie Sie mit Direct3D 10 die Blockkomprimierung in Ihrer Anwendung ganz einfach verwenden können.
Verwenden der Blockkomprimierung
Erstellen Sie eine blockkomprimierte Textur genau wie eine unkomprimierte Textur (siehe Erstellen einer Textur aus einer Datei),mit der Ausnahme, dass Sie ein blockkomprimiertes Format angeben.
loadInfo.Format = DXGI_FORMAT_BC1_UNORM;
D3DX10CreateTextureFromFile(...);
Erstellen Sie als Nächstes eine Ansicht, um die Textur an die Pipeline zu binden. Da eine blockkomprimierte Textur nur als Eingabe für eine Shaderphase verwendet werden kann, möchten Sie eine Shaderressourcenansicht erstellen, indem Sie CreateShaderResourceViewaufrufen.
Verwenden Sie eine komprimierte Blocktextur auf die gleiche Weise wie eine unkomprimierte Textur. Wenn Ihre Anwendung einen Arbeitsspeicherzeiger auf blockkomprimierte Daten erhält, müssen Sie die Speicherauffüllung in einer Mipmap berücksichtigen, die bewirkt, dass die deklarierte Größe von der tatsächlichen Größe abweicht.
Virtuelle Größe im Vergleich zur physischen Größe
Wenn Sie über Anwendungscode verfügen, der einen Speicherzeiger verwendet, um den Speicher einer komprimierten Blocktextur zu durchgehen, gibt es einen wichtigen Aspekt, der möglicherweise eine Änderung im Anwendungscode erfordert. Eine blockkomprimierte Textur muss ein Vielfaches von 4 in allen Dimensionen sein, da die Blockkomprimierungsalgorithmen für 4x4-Texelblöcke ausgeführt werden. Dies ist ein Problem bei einer Mipmap, deren Anfangsdimensionen durch 4 teilbar sind, aber nicht durch unterteilte Ebenen. Das folgende Diagramm zeigt den Unterschied im Bereich zwischen der virtuellen (deklarierten) Größe und der physischen (tatsächlichen) Größe der einzelnen Mipmapebenen.

Die linke Seite des Diagramms zeigt die Mipmapebenengrößen, die für eine nicht komprimierte Textur mit 60×40 generiert werden. Die Größe der obersten Ebene wird aus dem API-Aufruf übernommen, der die Textur generiert. jede nachfolgende Ebene ist halb so groß wie die vorherige Ebene. Bei einer nicht komprimierten Textur besteht kein Unterschied zwischen der virtuellen (deklarierten) Und der physischen (tatsächlichen) Größe.
Die rechte Seite des Diagramms zeigt die Mipmapebenengrößen, die für die gleiche Textur mit 60×40 mit Komprimierung generiert werden. Beachten Sie, dass sowohl die zweite als auch die dritte Ebene über Speicherauffüllung verfügen, um die Größenfaktoren auf jeder Ebene auf 4 zu setzen. Dies ist erforderlich, damit die Algorithmen mit 4×4 Texelblöcken arbeiten können. Dies ist besonders offensichtlich, wenn Sie Mipmap-Ebenen betrachten, die kleiner als 4 sind×4; Die Größe dieser sehr kleinen Mipmapebenen wird auf den nächsten Faktor von 4 aufgerundet, wenn Texturspeicher zugeordnet wird.
Die Stichprobenhardware verwendet die virtuelle Größe. Wenn die Textur entnommen wird, wird die Speicherauffüllung ignoriert. Bei Mipmapebenen, die kleiner als 4×4 sind, werden nur die ersten vier Texel für eine 2×2-Karte verwendet, und nur das erste Texel wird von einem 1×1-Block verwendet. Es gibt jedoch keine API-Struktur, die die physische Größe verfügbar macht (einschließlich des Speicherabstands).
Achten Sie zusammenfassend darauf, dass Sie beim Kopieren von Bereichen, die blockkomprimierte Daten enthalten, ausgerichtete Speicherblöcke verwenden. Um dies in einer Anwendung zu tun, die einen Arbeitsspeicherzeiger erhält, stellen Sie sicher, dass der Zeiger die Oberflächenhöhe verwendet, um die größe des physischen Arbeitsspeichers zu berücksichtigen.
Komprimierungsalgorithmen
Blockkomprimierungstechniken in Direct3D untergliedern unkomprimierte Texturdaten in 4×4-Blöcke, komprimieren jeden Block und speichern dann die Daten. Aus diesem Grund muss die Komprimierung von Texturen texturdimensionen aufweisen, die ein Vielfaches von 4 sind.

Das obige Diagramm zeigt eine Textur, die in Texelblöcke partitioniert ist. Der erste Block zeigt das Layout der 16 Texel mit der Bezeichnung a-p, aber jeder Block weist die gleiche Datenorganisation auf.
Direct3D implementiert mehrere Komprimierungsschemas, von denen jedes einen anderen Kompromiss zwischen der Anzahl der gespeicherten Komponenten, der Anzahl der Bits pro Komponente und der verbrauchten Arbeitsspeichermenge implementiert. Verwenden Sie diese Tabelle, um das Format auszuwählen, das am besten mit dem Datentyp und der Datenauflösung funktioniert, die am besten zu Ihrer Anwendung passt.
| Quelldaten | Datenkomprimierungsauflösung (in Bits) | Wählen Sie dieses Komprimierungsformat aus. |
|---|---|---|
| Farbe und Alpha aus drei Komponenten | Farbe (5:6:5), Alpha (1) oder kein Alpha | BC1 |
| Farbe und Alpha aus drei Komponenten | Farbe (5:6:5), Alpha (4) | BU2 |
| Farbe und Alpha aus drei Komponenten | Farbe (5:6:5), Alpha (8) | BC3 |
| Einkomponentenfarbe | Eine Komponente (8) | BC4 |
| Farbe mit zwei Komponenten | Zwei Komponenten (8:8) | BC5 |
BC1
Verwenden Sie das erste Blockkomprimierungsformat (BC1) (DXGI _ FORMAT _ BC1 _ TYPELESS, DXGI _ FORMAT _ BC1 _ UNORM oder DXGI _ BC1 _ UNORM _ SRGB), um Dreikomponentenfarbdaten mit einer 5:6:5-Farbe (5 Bits Rot, 6 Bits Grün, 5 Bit Blau) zu speichern. Dies gilt auch, wenn die Daten auch 1-Bit-Alpha enthalten. Wenn eine 4×4-Textur mit dem größtmöglichen Datenformat verwendet wird, reduziert das BC1-Format den erforderlichen Arbeitsspeicher von 48 Byte (16 Farben × 3 Komponenten/Farbe × 1 Byte/Komponente) auf 8 Bytes Arbeitsspeicher.
Der Algorithmus funktioniert mit 4×4 Blöcken von Texeln. Anstatt 16 Farben zu speichern, speichert der Algorithmus 2 Referenzfarben (Farbe _ 0 und Farbe _ 1) und 16 2-Bit-Farbindizes (blockiert a–p), wie im folgenden Diagramm dargestellt.

Die Farbindizes (a–p) werden verwendet, um die ursprünglichen Farben aus einer Farbtabelle nachzuschlagen. Die Farbtabelle enthält 4 Farben. Die ersten beiden Farben – Farbe _ 0 und Farbe _ 1 – sind die minimalen und maximalen Farben. Die anderen beiden Farben, Farbe _ 2 und Farbe _ 3, sind Zwischenfarben, die mit linearer Interpolation berechnet werden.
color_2 = 2/3*color_0 + 1/3*color_1
color_3 = 1/3*color_0 + 2/3*color_1
Den vier Farben werden 2-Bit-Indexwerte zugewiesen, die in den Blöcken a–p gespeichert werden.
color_0 = 00
color_1 = 01
color_2 = 10
color_3 = 11
Schließlich werden alle Farben in den Blöcken a–p mit den vier Farben in der Farbtabelle verglichen, und der Index für die nächstgelegene Farbe wird in den 2-Bit-Blöcken gespeichert.
Dieser Algorithmus eignet sich auch für Daten, die ebenfalls 1-Bit-Alpha enthalten. Der einzige Unterschied besteht darin, dass Farbe _ 3 auf 0 (was eine transparente Farbe darstellt) und Farbe _ 2 eine lineare Mischung aus Farbe _ 0 und Farbe _ 1 ist.
color_2 = 1/2*color_0 + 1/2*color_1;
color_3 = 0;
| | | Unterschiede zwischen Direct3D 9 und Direct3D 10:
Dieses Format ist sowohl in Direct3D 9 als auch in 10 vorhanden.
- In Direct3D 9 wird das BC1-Format als D3DFMT_DXT1 bezeichnet.
- In Direct3D 10 wird das BC1-Format durch DXGI_FORMAT_BC1_UNORM oder DXGI_FORMAT_BC1_UNORM_SRGB dargestellt.
BU2
Verwenden Sie das BC2-Format (DXGI _ FORMAT _ BC2 _ TYPELESS, DXGI _ FORMAT _ BC2 _ UNORM oder DXGI _ BC2 _ UNORM _ SRGB), um Daten zu speichern, die Farb- und Alphadaten mit geringer Koherität enthalten (verwenden Sie BC3 für hochgradig konsistente Alphadaten). Im BC2-Format werden RGB-Daten als 5:6:5-Farbe (5 Bits Rot, 6 Bits Grün, 5 Bits Blau) und Alpha als separater 4-Bit-Wert gespeichert. Bei einer 4×4-Textur mit dem größtmöglichen Datenformat reduziert diese Komprimierungstechnik den erforderlichen Arbeitsspeicher von 64 Bytes (16 Farben × 4 Komponenten/Farbe × 1 Byte/Komponente) auf 16 Bytes Arbeitsspeicher.
Im BC2-Format werden Farben mit der gleichen Anzahl von Bits und Datenlayout wie das BC1-Format gespeichert. BC2 benötigt jedoch zusätzliche 64 Bit Arbeitsspeicher, um die Alphadaten zu speichern, wie im folgenden Diagramm dargestellt.

| | | Unterschiede zwischen Direct3D 9 und Direct3D 10:
Dieses Format ist sowohl in Direct3D 9 als auch in 10 vorhanden.
- In Direct3D 9 wird das BC2-Format als D3DFMT_DXT2 und D3DFMT_DXT3 bezeichnet.
- In Direct3D 10 wird das BC2-Format durch DXGI_FORMAT_BC2_UNORM oder DXGI_FORMAT_BC2_UNORM_SRGB dargestellt.
BC3
Verwenden Sie das BC3-Format (DXGI _ FORMAT _ BC3 _ TYPELESS, DXGI _ FORMAT _ BC3 _ UNORM oder DXGI _ BC3 _ UNORM _ SRGB), um hochgradig konsistente Farbdaten zu speichern (verwenden Sie BC2 mit weniger konsistenten Alphadaten). Im BC3-Format werden Farbdaten mit 5:6:5 Farben (5 Bits Rot, 6 Bits Grün, 5 Bits Blau) und Alphadaten mit einem Byte gespeichert. Bei einer 4×4-Textur mit dem größtmöglichen Datenformat reduziert diese Komprimierungstechnik den erforderlichen Arbeitsspeicher von 64 Bytes (16 Farben × 4 Komponenten/Farbe × 1 Byte/Komponente) auf 16 Bytes Arbeitsspeicher.
Im BC3-Format werden Farben mit der gleichen Anzahl von Bits und Datenlayout wie das BC1-Format gespeichert. BC3 benötigt jedoch zusätzliche 64 Bit Arbeitsspeicher, um die Alphadaten zu speichern. Das BC3-Format verarbeitet Alpha, indem zwei Verweiswerte gespeichert und zwischen diesen interpoliert werden (ähnlich wie BC1 RGB-Farben speichert).
Der Algorithmus arbeitet mit 4×4 Blöcken von Texeln. Anstatt 16 Alphawerte zu speichern, speichert der Algorithmus 2 Verweis alphas (alpha _ 0 und alpha _ 1) und 16 3-Bit-Farbindizes (Alpha a bis p), wie im folgenden Diagramm dargestellt.

Das BC3-Format verwendet die Alphaindizes (a–p), um die ursprünglichen Farben aus einer Nachschlagetabelle nachzuschlagen, die 8 Werte enthält. Die ersten beiden Werte – Alpha _ 0 und Alpha _ 1 – sind die Minimal- und Höchstwerte. Die anderen sechs Zwischenwerte werden mithilfe der linearen Interpolation berechnet.
Der Algorithmus bestimmt die Anzahl der interpolierten Alphawerte, indem die beiden Alpha-Verweiswerte untersucht werden. Wenn Alpha _ 0 größer als Alpha _ 1 ist, interpoliert BC3 sechs Alphawerte, andernfalls 4. Wenn BC3 nur vier Alphawerte interpoliert, werden zwei zusätzliche Alphawerte festgelegt (0 für vollständig transparent und 255 für vollständig deckende Alphawerte). BC3 komprimiert die Alphawerte im Texelbereich 4×4, indem der Bitcode gespeichert wird, der den interpolierten Alphawerten entspricht, die am besten mit dem ursprünglichen Alpha für ein bestimmtes Texel übereinstimmen.
if( alpha_0 > alpha_1 )
{
// 6 interpolated alpha values.
alpha_2 = 6/7*alpha_0 + 1/7*alpha_1; // bit code 010
alpha_3 = 5/7*alpha_0 + 2/7*alpha_1; // bit code 011
alpha_4 = 4/7*alpha_0 + 3/7*alpha_1; // bit code 100
alpha_5 = 3/7*alpha_0 + 4/7*alpha_1; // bit code 101
alpha_6 = 2/7*alpha_0 + 5/7*alpha_1; // bit code 110
alpha_7 = 1/7*alpha_0 + 6/7*alpha_1; // bit code 111
}
else
{
// 4 interpolated alpha values.
alpha_2 = 4/5*alpha_0 + 1/5*alpha_1; // bit code 010
alpha_3 = 3/5*alpha_0 + 2/5*alpha_1; // bit code 011
alpha_4 = 2/5*alpha_0 + 3/5*alpha_1; // bit code 100
alpha_5 = 1/5*alpha_0 + 4/5*alpha_1; // bit code 101
alpha_6 = 0; // bit code 110
alpha_7 = 255; // bit code 111
}
| | | Unterschiede zwischen Direct3D 9 und Direct3D 10:
- In Direct3D 9 wird das BC3-Format als D3DFMT_DXT4 und D3DFMT_DXT5 bezeichnet.
- In Direct3D 10 wird das BC3-Format durch DXGI_FORMAT_BC3_UNORM oder DXGI_FORMAT_BC3_UNORM_SRGB dargestellt.
BC4
Verwenden Sie das BC4-Format, um Einkomponentenfarbdaten mit 8 Bits für jede Farbe zu speichern. Aufgrund der erhöhten Genauigkeit (im Vergleich zu BC1)eignet sich BC4 ideal zum Speichern von Gleitkommadaten im Bereich von [ 0 bis 1 ] im _ DXGI FORMAT _ BC4 _ UNORM-Format und [ -1 bis +1 ] im DXGI FORMAT _ _ BC4 _ SNORM-Format. Bei einer 4×4-Textur, die das größtmögliche Datenformat verwendet, reduziert diese Komprimierungstechnik den erforderlichen Arbeitsspeicher von 16 Bytes (16 Farben × 1 Komponenten/Farbe × 1 Byte/Komponente) auf 8 Bytes.
Der Algorithmus arbeitet mit 4×4 Blöcken von Texeln. Anstatt 16 Farben zu speichern, speichert der Algorithmus 2 Referenzfarben (rot _ 0 und rot _ 1) und 16 3-Bit-Farbindizes (rot a bis rot p), wie im folgenden Diagramm dargestellt.

Der Algorithmus verwendet die 3-Bit-Indizes, um Farben aus einer Farbtabelle nachzuschlagen, die acht Farben enthält. Die ersten beiden Farben – Rot _ 0 und Rot _ 1 – sind die minimalen und maximalen Farben. Der Algorithmus berechnet die verbleibenden Farben mithilfe der linearen Interpolation.
Der Algorithmus bestimmt die Anzahl der interpolierten Farbwerte, indem die beiden Verweiswerte untersucht werden. Wenn rot _ 0 größer als rot _ 1 ist, interpoliert BC4 sechs Farbwerte, andernfalls 4. Wenn BC4 nur vier Farbwerte interpoliert, werden zwei zusätzliche Farbwerte festgelegt (0,0f für vollständig transparent und 1,0f für vollständig deckend). BC4 komprimiert die Alphawerte im Texelbereich 4×4, indem der Bitcode gespeichert wird, der den interpolierten Alphawerten entspricht, die am besten mit dem ursprünglichen Alpha für ein bestimmtes Texel übereinstimmen.
BC4 _ UNORM
Die Interpolation der Einzelkomponentendaten erfolgt wie im folgenden Codebeispiel.
unsigned word red_0, red_1;
if( red_0 > red_1 )
{
// 6 interpolated color values
red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
// 4 interpolated color values
red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
red_6 = 0.0f; // bit code 110
red_7 = 1.0f; // bit code 111
}
Den Referenzfarben werden 3-Bit-Indizes (000–111, da es 8 Werte gibt) zugewiesen, die während der Komprimierung in Blöcken rot a bis rot p gespeichert werden.
BC4 _ SNORM
Das DXGI _ FORMAT _ BC4 _ SNORM ist genau identisch, mit der Ausnahme, dass die Daten im SNORM-Bereich codiert sind und 4 Farbwerte interpoliert werden. Die Interpolation der Einzelkomponentendaten erfolgt wie im folgenden Codebeispiel.
signed word red_0, red_1;
if( red_0 > red_1 )
{
// 6 interpolated color values
red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
// 4 interpolated color values
red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
red_6 = -1.0f; // bit code 110
red_7 = 1.0f; // bit code 111
}
Den Referenzfarben werden 3-Bit-Indizes (000–111, da es 8 Werte gibt) zugewiesen, die während der Komprimierung in Blöcken rot a bis rot p gespeichert werden.
BC5
Verwenden Sie das BC5-Format, um Zwei-Komponenten-Farbdaten mit 8 Bits für jede Farbe zu speichern. Aufgrund der erhöhten Genauigkeit (im Vergleich zu BC1)eignet sich BC5 ideal zum Speichern von Gleitkommadaten im Bereich von [ 0 bis 1 ] im _ DXGI FORMAT _ BC5 _ UNORM-Format und [ -1 bis +1 ] im DXGI FORMAT _ _ BC5 _ SNORM-Format. Bei einer 4×4-Textur mit dem größtmöglichen Datenformat reduziert diese Komprimierungstechnik den erforderlichen Arbeitsspeicher von 32 Byte (16 Farben × 2 Komponenten/Farbe × 1 Byte/Komponente) auf 16 Bytes.
Der Algorithmus arbeitet mit 4×4 Blöcken von Texeln. Anstatt 16 Farben für beide Komponenten zu speichern, speichert der Algorithmus zwei Referenzfarben für jede Komponente (rot _ 0, rot _ 1, grün _ 0 und grün _ 1) und 16 3-Bit-Farbindizes für jede Komponente (rot a bis rot p und grün a bis grün p), wie im folgenden Diagramm dargestellt.

Der Algorithmus verwendet die 3-Bit-Indizes, um Farben aus einer Farbtabelle nachzuschlagen, die acht Farben enthält. Die ersten beiden Farben – Rot _ 0 und Rot _ 1 (oder Grün _ 0 und Grün _ 1) – sind die minimalen und maximalen Farben. Der Algorithmus berechnet die verbleibenden Farben mithilfe der linearen Interpolation.
Der Algorithmus bestimmt die Anzahl der interpolierten Farbwerte, indem die beiden Verweiswerte untersucht werden. Wenn rot _ 0 größer als rot _ 1 ist, interpoliert BC5 sechs Farbwerte, andernfalls 4. Wenn BC5 nur vier Farbwerte interpoliert, werden die verbleibenden beiden Farbwerte auf 0,0f und 1,0f festgelegt.
BC5 _ UNORM
Die Interpolation der Einzelkomponentendaten erfolgt wie im folgenden Codebeispiel. Die Berechnungen für die grünen Komponenten sind ähnlich.
unsigned word red_0, red_1;
if( red_0 > red_1 )
{
// 6 interpolated color values
red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
// 4 interpolated color values
red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
red_6 = 0.0f; // bit code 110
red_7 = 1.0f; // bit code 111
}
Den Referenzfarben werden 3-Bit-Indizes (000–111, da es 8 Werte gibt) zugewiesen, die während der Komprimierung in Blöcken rot a bis rot p gespeichert werden.
BC5 _ SNORM
Das DXGI _ FORMAT _ BC5 _ SNORM ist genau identisch, mit der Ausnahme, dass die Daten im SNORM-Bereich codiert sind und wenn vier Datenwerte interpoliert werden, sind die beiden zusätzlichen Werte -1,0f und 1,0f. Die Interpolation der Einzelkomponentendaten erfolgt wie im folgenden Codebeispiel. Die Berechnungen für die grünen Komponenten sind ähnlich.
signed word red_0, red_1;
if( red_0 > red_1 )
{
// 6 interpolated color values
red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
// 4 interpolated color values
red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
red_6 = -1.0f; // bit code 110
red_7 = 1.0f; // bit code 111
}
Den Referenzfarben werden 3-Bit-Indizes (000–111, da es 8 Werte gibt) zugewiesen, die während der Komprimierung in Blöcken rot a bis rot p gespeichert werden.
Formatkonvertierung mit Direct3D 10.1
Direct3D 10.1 ermöglicht Kopien zwischen vorstrukturierten Texturen und blockkomprimierten Texturen der gleichen Bitbreite. Die Funktionen, die dies erreichen können, sind CopyResource und CopySubresourceRegion.
Ab Direct3D 10.1 können Sie CopyResource und CopySubresourceRegion verwenden, um zwischen einigen Formattypen zu kopieren. Dieser Kopiervorgang führt eine Formatkonvertierung durch, die Ressourcendaten als anderen Formattyp neu interpretiert. Betrachten Sie dieses Beispiel, das den Unterschied zwischen der Neuinterpretierung von Daten und dem Verhalten eines typischeren Konvertierungstyps zeigt:
FLOAT32 f = 1.0f;
UINT32 u;
Um "f" als Typ von "u" neu zu interpretieren, verwenden Sie memcpy:
memcpy( &u, &f, sizeof( f ) ); // ‘u’ becomes equal to 0x3F800000.
In der vorherigen Neuinterpretation ändert sich der zugrunde liegende Wert der Daten nicht. memcpy interpretiert float als ganze Zahl ohne Vorzeichen neu.
Verwenden Sie die Zuweisung, um den typischeren Konvertierungstyp auszuführen:
u = f; // ‘u’ becomes 1.
In der vorherigen Konvertierung ändert sich der zugrunde liegende Wert der Daten.
In der folgenden Tabelle sind die zulässigen Quell- und Zielformate aufgeführt, die Sie bei dieser Neuinterpretationsart der Formatkonvertierung verwenden können. Sie müssen die Werte ordnungsgemäß codieren, damit die Neuinterpretation wie erwartet funktioniert.
| Bitbreite | Unkomprimierte Ressource | Block-Compressed Ressource |
|---|---|---|
| 32 | DXGI _ FORMAT _ R32 _ UINT DXGI _ FORMAT _ R32 _ SINT |
DXGI _ FORMAT _ R9G9B9E5 _ SHAREDEXP |
| 64 | DXGI _ FORMAT _ R16G16B16A16 _ UINT DXGI _ FORMAT _ R16G16B16A16 _ SINT _DXGI-FORMAT _ R32G32 _ UINT DXGI _ FORMAT _ R32G32 _ SINT |
DXGI _ FORMAT _ BC1 _ UNORM [ _ SRGB] DXGI _ FORMAT _ BC4 _ UNORM DXGI _ FORMAT _ BC4 _ SNORM |
| 128 | DXGI _ FORMAT _ R32G32B32A32 _ UINT DXGI _ FORMAT _ R32G32B32A32 _ SINT |
DXGI _ FORMAT _ BC2 _ UNORM [ _ SRGB] DXGI _ FORMAT _ BC3 _ UNORM [ _ SRGB] DXGI _ FORMAT _ BC5 _ UNORM DXGI _ FORMAT _ BC5 _ SNORM |