BC-, ASTC- und ETC2-Texturen auf realen Zielplattformen budgetieren

Die hochgeladene Repräsentation budgetieren

Eine kleine Quell-Bilddatei bedeutet nicht, dass auch die GPU-Allokation klein ist. GPU-Blockkompression ermöglicht begrenzten wahlfreien Zugriff auf Texelgruppen; Distributionskompression und Containergrösse beantworten andere Fragen. [2][3] Nach dem Import oder Transcoding das tatsächlich hochgeladene Format festhalten und anschliessend dessen residente Allokation auf dem Zielgerät prüfen.

Speicherkapazität, Übertragungsgrösse, Encoder-Zeit und Sampling-Kosten im Budget getrennt führen. Ein einzelner Kompressionsprozentsatz kann nicht alle vier beschreiben.

Formate den unterstützten Kanälen zuordnen

BC1 speichert einen 4 × 4-Block in 8 Bytes; BC5 und BC7 benötigen für dieselbe Fläche 16 Bytes. Ihre Kanalfähigkeiten unterscheiden sich, und die Direct3D-Unterstützung hängt vom Format und vom Feature Level ab. [1]

ASTC behält einen 128-Bit-Block bei und variiert die Texelfläche (Footprint), wodurch sich unterschiedliche Bitraten ergeben. [2] Die ETC2/EAC-Unterstützung ist Teil von OpenGL ES 3.0; andere APIs verwenden eigene Mechanismen zur Abfrage von Fähigkeiten. Der Khronos-Leitfaden nennt konkrete Format- und Feature-Prüfungen, darunter Vulkan-Kompressionsfeatures. [3] Unterstützung nicht allein aus der Bezeichnung «Desktop» oder «Mobile» ableiten.

Blockweise gerundeten Speicher berechnen

Als Beispiel dient eine Basistextur von 2048 × 2048. BC7 benötigt 512 × 512 Blöcke zu 16 Bytes, also genau 4 MiB. ASTC mit 6 × 6 Footprint erfordert das Aufrunden jeder Dimension auf 342 Blöcke: 342 × 342 × 16 = 1'871'424 Bytes, rund 1,78 MiB.

Dies sind Nutzdatengrössen der Basisstufe, weder vollständige Allokationen noch eine Aussage über gleichwertige Qualität. Hinzu kommen alle Mip-Stufen mit jeweils eigener Blockrundung sowie Array-Layer, Cube-Faces und plattformspezifisches Alignment. Ein Fallback, der auf unkomprimierte Pixel expandiert, verändert das Budget erneut. Diese Rechnung neben dem im Build beobachteten Texturbericht festhalten.

Fehler dort vergleichen, wo sie zählen

Ein kleines Testset mit weichen Verläufen, scharfen Alphakanten, verrauschten Farben und Normalendaten anlegen. Jedes anwendbare Format mit gewählten Einstellungen kodieren und das importierte Ergebnis im tatsächlichen Shader prüfen. Normalen anhand bewegter Glanzlichter, Masken anhand ihrer Verwendung mit Schwellenwert kontrollieren; eine gefällige RGB-Vorschau kann funktionale Fehler verbergen.

Den Encoder-Aufwand getrennt vom Block-Footprint variieren. Build-Zeit festhalten und prüfen, ob eine bessere Kodierung das störende Artefakt beseitigt, bevor für eine ganze Asset-Kategorie mehr Speicher eingeplant wird.

Ausnahmen bewusst definieren

Kein verlustbehaftetes Format ist für jedes Signal ideal. Feiner Text, binäre Masken und ungewöhnlich empfindliche Materialkanäle können ein anderes Format oder eine andere Auflösung rechtfertigen. Eine klare Ausnahmeregel festhalten und prüfen, dass die Plattform-Fallbacks sie umsetzen.

Die kleinste getestete Repräsentation ausliefern, die auf den unterstützten Zielplattformen die visuelle Anforderung erfüllt. Das hochgeladene Format erneut prüfen, sobald sich Importer, Transcoder oder Deployment-Plattform ändern.

Quellen

• [1] Texture Block Compression in Direct3D 11 — Microsoft.
• [2] ASTC Format Overview — Arm.
• [3] KTX Developer Guide — Khronos Group.