Texturkompression: Wird heutzutage noch DXTC genutzt?

[Hübie]

Hi Leute.

In mir keimte neulich die Frage auf, ob heutzutage noch DXTC (oder überhaupt eine Texturkompressionsmethode) genutzt wird. Wenn ja:
Wie effizient arbeitet diese? Wird die zwangsläufig eingesetzt? Wie kann man diese beeinflussen? Ist das immer noch bestandteil von D3D? Welche Vor- bzw. Nachteile ergeben sich?


Ich frage aus reiner Neugier um meinen Wissensschatz zu erweitern :smile:

Danke!

LG Hübie

[xxMuahdibxx]

Seit DX 6.0 fester Bestandteil von Direct X ob nun das verfahren von S3 oder das von 3dfx ..
ATI hat auch eine entwickelt und die wurde sogar von Nvidia verwendet später

Link für die Kompression

http://www.hardware-mag.de/artikel/grafikkarten/preview_ati_radeon_x800_codename_r420/5/

3Dc lässt sich problemlos auf bestehende Applikationen anwenden und bedarf keiner großen Eingriffe. Kommende Entwicklungen, die 3Dc voll unterstützen bzw. benutzen werden, sind Half-Life 2, Serious Sam 2, Doom 3 und viele mehr

Also doch recht bekannte Titel ^^

Link für Verwendung Nvidia

http://www.hardware-mag.de/news/2005/april/3dc_texturkompression_nun_auch_fuer_nvidia_grafikkarten/

1. Effizienz erziehlt man daraus das man weniger Grafikkartenspeicher braucht für die Texturen und doch höher auflösende Texturen einsetzen kann .

2. kommt wohl dann auf die Programmierer drauf an .

3. selber beeinflussen kannst dort sehr wenig bei ATI könnte man schauen was in den ATI Tray Tools möglich ist .

4. ja

5. Vorteil bessere Texturen ... weniger Speicherlast der Graka ... somit bei gleicher Bildquali wohl schneller .

[SaschaW]

Da ich selber DDS (mit verschiedenen Kompressionsstufen, manchmal auch ohne) in meinem aktuelle Spiel verwende schreibe ich mal was aus Sicht eines Entwicklers dazu :

Wie effizient arbeitet diese?
Sehr. DDS ist das perfekte Format für 3D-Anwendungen. Nicht nur weil man verschiedene Kompressionsstufen zur Wahl hat (DXT1,DXT3,DXT5, letzteres mit interpoliertem oder explizitem Alpha, etc.), auch unkomprimierte Formate nutzen kann (ganz normales ARGB, aber auch FP-Formate), sondern v.a. weil man dort auch direkt Mipmaps ablegen kann und deren Generierung beeinflussen kann. Lädt man andere Formate die keine Mipmaps haben hat man darauf keinen Einfluss, und zur Laufzeit dauert das Laden natürlich länger da die Mipmaps dann beim Laden der Textur erstellt werden. Zudem sind die Formate (auch komprimiert) ja native Hardwareformate. Da wird nix mehr gewandelt, sondern direkt in den VRAM geschoben. Im Vergleich zu z.b. ner Textur im PNG-Format kann man mit DDS je nach Fall mehrere hundert Prozent schneller laden.


Wird die zwangsläufig eingesetzt?
Wenn die Textur komprimiert auf der Platte vorliegt, dann ja. Daran kann der Nutzer dann auch nichts ändern. Es gibt allerdings auch die Möglichkeit unkomprimiert vorliegende Texturen von der API komprimieren zu lassen (In OpenGL als internes Format GL_COMPRESSED_* angeben). Da könnte man als Entwickler rein theoretisch nen Switch/Flag einbauen um das vom User steuern lassen zu können. Aber wie gesagt legt man die Texturen meist im gewollten Format ab, denn Texturkompression ist nicht immber gewümnscht. Die ist ja fest (3:1, 5:1, etc.), und z.b. bei nem Himmel mit weichen Farbverläufen ists oft besser wenn man dann in nem unkomprimierten Format speichert. Bei der forcierten Kompression via API hat man halt keinerlei Kontrolle, im Gegensatz zur manuellen via z.b. nvdds-Plugin für Photoshop und Co.


Wie kann man diese beeinflussen?
Siehe vorherigen Punkt. Als Nutzer vermutlich garnicht wenn die Texturen vom Entwickler/Grafiker direkt im passenden Format auf der Platte abgelegt werden.


Ist das immer noch bestandteil von D3D?
Ich nutze zwar OpenGL, aber ja, die Kompressionsformate (DXT basiert ja auf S3TC) sind immer noch fester Bestandteil aktueller APIs. Und ich denke nicht dass sich daran viel ändern wird, DDS ist da extrem flexibel. Evtl. kommen noch neue Formate hinzu.


Welche Vor- bzw. Nachteile ergeben sich?
Vorteile sind wie gesagt die viel höhere Geschwindigkeit beim Laden der Texturen, und auch der geringere Speicherverbrauch. Dadurch hat man auch weniger Bandbreite die beim "Herumschieben" der Texturen von Nöten ist. Wie gesagt sind die Kompressionsverhältnisse fest, sprich z.b. 3:1 und 5:1. Dementsprechend spart man halt VRAM und Bandbreite.
Nachteile wäre dann halt die verminderte Qualität das fest komprimiert wird. Bei vielen Texturen (Mauern, Gräser, etc.) merkt man als User davon kaum was, anders siehts dann z.b. beim schon genannten weichen Verlauf einer Himmelstextur aus. Da muss man dann als Grafiker/Dev entscheiden ob man komprimiert ablegt oder unkomprimiert. Ich hab in unserem Wiki einen Artikel zu DDS geschrieben (http://wiki.delphigl.com/index.php/DDS), da ist ein Differenzvergleich zwischen einer unkomprimierten und der selben komprimierten Himmelstextur (stark multipiliziert, damit man was sieht) um mal zu sehen wie groß der Unterschied ist.

[Coda]

Seit DX 6.0 fester Bestandteil von Direct X ob nun das verfahren von S3 oder das von 3dfx ..
Nur das von S3.

Ab DirectX 11 gibt's darüberhinaus auch Blockkompression für Floating-Point-Texturen. Das wurde aber von allen gemeinsam entwickelt, bzw. von Microsoft.

ATI hat auch eine entwickelt und die wurde sogar von Nvidia verwendet später
Das war auch nur eine kleine Verallgemeinerung von S3TC a.k.a. DXT für Texturen mit zwei Farbkanälen.

[Hübie]

Hm. Wow. Nun bin ich um ein vielfaches schlauer geworden. Lese mich gerade ins DDS-Containerformat. Vielen Dank an die beteiligten, besonders dir SaschaW :smile:

Gibt es beim interpolierten Alpha-Kanal einen (sichtbaren) Nachteil ggü. des expliziten?

Ach ja: Wie werden denn eigentlich mip-maps generiert wenn diese nicht vorliegen? Gibts da n extra-Puffer? Frisst ja dann sicher einiges an Rechenzeit oder?

[SaschaW]

Gibt es beim interpolierten Alpha-Kanal einen (sichtbaren) Nachteil ggü. des expliziten?
Auch hier kommts aufs Anwendungsgebiet an. Hat man eine Textur mit weichen Übergängen im Alphakanal (also der Transparenz) dann ist interpoliert natürlich besser. Wenn man jedoch scharfe Transparenzkanten hat und diese beibehalten will dann entsprechend explizit.

Ach ja: Wie werden denn eigentlich mip-maps generiert wenn diese nicht vorliegen? Gibts da n extra-Puffer? Frisst ja dann sicher einiges an Rechenzeit oder?
Es gibt da zwei Möglichkeiten wenn man die Mipmaps nicht in der Textur vorliegen hat und diese zur Laufzeit generieren muss. Entweder via CPU (gluBuild2DMipmaps unter OpenGL) oder man lässt diese die GPU automatisch generieren, geht dann via passender Extension (GL_GENERATE_MIPMAP_SGIS) auf GPUs die dese unterstüzten. Variante 1 via CPU ist natürlich die denkbar schlechteste, da dies verglichen mit der automatischen Generierung sehr viel länger dauert und dort ein sehr simpler Filter (bilinear afaik) verwendet wird, der nicht sonderlich aussieht.

[Hübie]

Aha. Okay. Kann man anhand einer auf Platte liegenden Textur (sagen wir mal Quake4) die MipMaps herausfinden/extrahieren(?) ohne das man (das teure) Photoshop hat?

Edit: Oder noch besser: GTA4 ;D

[SaschaW]

Wenn ich nicht irre (ist lange her, konnt mich mit GIMP nie so recht anfreunden) gibts für GIMP auch ein DDS-Plugin, damit kann man sicher auch die einzelnen Mipmaps laden. Ansonsten dürte es sicher auch Freeware geben die diese extrahieren kann. Alternativ hat man sich (wenn man proggen kann) in wenigen Minuten ein Tool geschrieben dass die Mipmaps auslesen und exportieren kann.

[Hübie]

Pfff. Ich und programmieren ;D Dazu bin ich zu blöde, glaubs mir. Damals gegen Ende der 12. Klasse war bei mir der Ofen mit C++ aus. Heut kann ich dir nicht mal mehr den Unterschied einer kopf- und fußgesteuerten Schleife erklären ;D

Ich muss mich mal intensiver mit dem Thema Texturen auseinander setzen (wie und wohin werden die geladen, ausgewertet, beleuchtet, welche Stufen gibts und und und...). Muss nun aber ins Bett.

GN8

ps: Danke noch mal :)

Edit: Eine Sache noch zu Projekt W: Kannst du da einen framelimiter einbauen? Im Menü hab ich 2500fps was meine Spulen fiepen lässt. Erst per Downsampling gehts weg ;D

[Demirug]

Du musst aber davon ausgehen das bei vielen Spielen die ganzen Texturen nicht als einzelne Dateien vorliegen sondern meist in Form von mehr oder weniger speziellen Archiveformaten. Einige gehen dann auch noch so weit und benutzten für die Texturen selbst auch noch eigene Formate. DDS hat zum Beispiel den Nachteil dass es nicht sehr gut für progressives Mipmap Streaming geeignet ist.

[Dicker Igel]

Wie läuft das eigentlich mit der Mip Map Filterung vom NV DDS Plugin, wird generell das genutzt, was man angibt:

• Point: No filtering
• Box: Fastest filtering
• Mitchell: High quality filtering
• Other filters: Triangle, Quadratic, Cubic, Catrom, Gaussian, Sinc, Bessel , Hanning, Hamming, Blackman, Kaiser

oder ist die Unterstützung der verwendeten Methode auch von der Engine abhängig?
Wäre dann zudem "Mitchell" bspw. "am besten" gegen Texturflimmern in der "Ferne", oder gibt es da "empfohlene" Settings für verschiedene Objekte (statische, KI, Alphablends)?

[Coda]

Hm. Wow. Nun bin ich um ein vielfaches schlauer geworden. Lese mich gerade ins DDS-Containerformat.
Hat halt eigentlich fast nichts mit dem Thema zu tun. Man muss kein DDS verwenden. Spiele wie Rage gehen sogar so weit, das sie zur Runtime von einer globalen Kompression (JPEG ähnlich) zu DXT transkodieren beim Streaming.

oder ist die Unterstützung der verwendeten Methode auch von der Engine abhängig?
Wie soll da die Engine was nicht unterstützen können? Das sind fertige, vorberechnete Daten.

Bei den Filtern reicht es eigentlich für die meisten Leute aus den Standard eingestellt zu lassen. Hauptsache kein Box. Auf dem Papier ist sinc am besten, das neigt aber wohl zu blur.

[SaschaW]

oder ist die Unterstützung der verwendeten Methode auch von der Engine abhängig?
Wäre dann zudem "Mitchell" bspw. "am besten" gegen Texturflimmern in der "Ferne", oder gibt es da "empfohlene" Settings für verschiedene Objekte (statische, KI, Alphablends)?

Coda hat soweit alles Wichtige dazu gesagt. Die Filter gegeben ja nur an wie das Plugin die Textur/Mipmaps fürs Ablegen in der DDS-Datei filtert. Das hat also nix mit dem Renderer zu tun, der lädt die Daten ja dann nachher nur in den VRAM hoch.

Und welche Filter man verwendet muss man als Grafiker/Dev selber entscheiden. Für meine GUI-Texturen verwende ich dann entsprechend einen aufwendigen Filter (sieht dann leicht besser aus, schärfere Kanten, etc.) und lass auch die Mipmaps leicht schärfen (Sharpening-Soft). Für Texturen in einer 3D-Umgebung (Wände, Böden, etc.) sollte man dann evtl. besser auf Schärfung und co. verzichten. Aber wie gesagt hängt die Einstellungen von Filter, Schärfung, Alphamodulatione etc. halt davon ab wofür die Textur später verwendet wird.

[seaFs]

Das war auch nur eine kleine Verallgemeinerung von S3TC a.k.a. DXT für Texturen mit zwei Farbkanälen.

Ist das die von ATi vorgeschlagene Normalmapkompression?

[Dicker Igel]

@ Coda & SaschaW

Ok, danke euch - mich hatte es halt gewundert, dass "Triangle" Standard voreingestellt ist, ich hätte da eher "Point" erwartet:

http://www.abload.de/img/10khs.jpg

Kann man eigentlich mit irgendwelchen Tools herausfinden, wie DDS'en von diversen Games ursprünglich gespeichert wurden (DXT3/5, verwendete Filter)?

[SaschaW]

Nein, die Filter kann man nicht rausfinden. Die sind ja nicht Teil der Spezifikation, sondern werden vom Plugin halt vorberechnet. Und das sowas wie Triangle voreingestellt ist (man kann ja eigene Setups speichern/laden) ist schon richtig so. Pointfilter sähe nämlich ganz grässlich aus.

Und das Format liegt logischerweise im Header der DDS-Datei (zusammen mit Farbtiefe, Größe, etc.). Muss ja, damit man nach dem Laden der Datei der API das interne Texturenformat mitteilen kann.

[Coda]

Ist das die von ATi vorgeschlagene Normalmapkompression?
Ja, das heißt jetzt einfach BC5 seit DirectX 10. BC1-4 sind die alten DXT-Formate.

Ok, danke euch - mich hatte es halt gewundert, dass "Triangle" Standard voreingestellt ist, ich hätte da eher "Point" erwartet:
WTF? Wieso Point? Das ist die schlimmstmögliche Variante überhaupt.

[Dicker Igel]

Ok, also quasi: keine Filterung ist Müll weil wenig Samples, umso mehr (Box -> Gaussian, Mitchell ...) desto besser.

[SaschaW]

Welchen Filter man für welche Textur nutzt ist halt unterschiedlich. Mitchell bietet die höchste Qualität, dauert dann aber gei großen Texturen recht lange. Und die Filter unterscheiden sich ja nicht nur in der Zahl ihrer Samples, sondern auch durch die Muster die angewendet werden, weshalb je nach Grundmaterial Filter A besser sein kann als Filter B und bei nem anderen Material ists dann umgekehrt. Und Pointfilterung nutzt halt gar keine Samples, sprich es wird nichts gefiltert sondern nur die Texel vergrößert.

[Dicker Igel]

Ok, alles klar - gibt es irgendwo eine Dokumentation zu den einzelnen Filtern?

[SaschaW]

Ja, z.b hier (http://www.renderman.org/RMR/st/PRMan_Filtering/Filtering_In_PRMan.html).

Sind aber i.d.r. alles sehr theoretische Informationen, über die man sich selbst als Entwickler keine Gedanken macht. Im Plugin kann man ja direkt via Vorschau sehen wie welcher Filter wirkt.

[Coda]

Ok, also quasi: keine Filterung ist Müll weil wenig Samples, umso mehr (Box -> Gaussian, Mitchell ...) desto besser.
Nö, Point ist einfach die schlimmstmögliche Rekonstruktion des Signals. Auf die Anzahl der Samples kommt es nichtmal unbedingt an.

Mitchell bietet die höchste Qualität
Darüber lässt sich streiten. Die Textur ist eigentlich nur mit sinc/lanczos korrekt gefiltert. Mitchell liefert wohl mehr Schärfe, was aber auch automatisch zu mehr Aliasing führt.

[aths]

Darüber lässt sich streiten. Die Textur ist eigentlich nur mit sinc/lanczos korrekt gefiltert. Mitchell liefert wohl mehr Schärfe, was aber auch automatisch zu mehr Aliasing führt.Sinc funktioniert perfekt beim Audiosignal, nicht bei Bildern oder Texturen. Lanczos ist oft gut, aber nicht "richtig" im Sinne von mathematisch korrekt. Die Textur erlaubt gar keine korrekte Darstellung des eigentlichen Bildes (Ausnahme 1:1 Pixel-Texel-Mapping) da einerseits das Ausgabegerät kein kontinuierliches Signal liefert und andererseits Flächensamples genommen wurden, welche auch unter Einhaltung der Shannon-Nyquist-Grenze keine exakte Rekonstruktion erlauben.

[aths]

Ich frage aus reiner Neugier um meinen Wissensschatz zu erweitern :smile:... oder um einen Vortrag für die Schule auszuarbeiten? Hehe.


Welche Vor- bzw. Nachteile ergeben sich?Viele Bilder lassen sich relativ gut komprimieren ohne dass Verlust groß auffällt. Vorteile sind dann geringere Anforderungen an die RAM-Größe der Grafikkarte und an die Speicherbandbreite der Grafikkarte.

[Coda]

Sinc funktioniert perfekt beim Audiosignal, nicht bei Bildern oder Texturen.
Erklärung? Das Sampling-Theorem ist das selbe.

[Hübie]

Mit 30 noch in der Schule? Neeee lass´ ma gut sein ;D So langsam aber sicher übersteigt die Unterhaltung meinen Wissensschatz =)
Kenne mich mit den Texturfiltern wenig bis garnicht aus!

[aths]

Erklärung? Das Sampling-Theorem ist das selbe.Beim Audiosignal sampelst du Punkte, beim Digitalfoto den Mittelwert des Signals über eine gewisse Zeit (bzw. Fläche.) Zur Audio-Wiedergabe kannst du ein kontinuierliches Signal ausgeben, die Pixeldarstellung am Monitor ist jedoch diskret.

[Rumbah]

Unter folgendem Link bekommt man einen guten Überblick über die Vor- und Nachteile der verschiedenen Filtermethoden. Keine Variante ist perfekt und man muss je nach Bildinhalt entscheiden, was man als angenehm empfindet.

http://svn.int64.org/viewvc/int64/resamplehq/doc/kernels.html

[Man From Atlantis]

Rage uses DXTC
http://nvidia.fullviewmedia.com/gtc2010/0921-a1-2152.html

[Hübie]

Hö? Mein Abo wurde gar nicht aktualisiert?! Hab deinen Beitrag eben durch Zufall gesehen. Werd mir das mal reinpfeifen wenn ich nicht am Arschphone bin.
Klingt very interesting...

[mapel110]

Sehr interessantes Video. Aber bei all den pompösen Marketingzahlen ist letztendlich wenig dabei rumgekommen in Form von Texturqualität und Performance.

[Coda]

Wieso? Ohne DXTC wäre der Tilecache sehr viel kleiner und damit noch mehr Matsch zu sehen.

Überhaupt muss man Texturkompression ohnehin verwenden um gescheite Performance zu bekommen.

[Hübie]

Oder man hat genügend Bandbreite+VRAM. Das wird aber noch ein paar Jahre dauern, da wir ja mit Salamischeiben abgespeist werden.

[Coda]

Auch der Texture-Cache ist auf DXT ausgelegt. Es gibt auch fast keine guten Gründe DXT nicht zu verwenden, die Qualität ist oft transparent.

[SaschaW]

Ich glaub dass hier ist eher so ein Thema über das man nur wirklich diskutieren kann wenn man selbst damit entwickelt.

Ich nutze seit einiger Zeit nur noch DXT (via DDS), zumal DDS ja auch unkomprimierte Formate kann. Wenn ich also z.B. ein GUI-Element unkomprimiert haben will (z.B. weil es komprimiert nicht gut aussieht) nehm ich halt 8.8.8.8 ARGB, geht ja problemlos in DDS.

Und vor allem würden die meisten Leute garnicht erkennen ob eine Textur jetzt unkomprimiert oder als DXT3/5 vorliegt. v.a. bei hochfrequenten Texturen ist das praktisch nur mit nem Differenztool zu sehen. Da muss schon ein sehr weicher Verlauf (z.b. blauer Himmerl) her um da den Unterschied mit dem blossen Auge sehen zu können.

Und ohne DXT (oder ähnliches) wären die Ladezeiten heutzutage auch noch viel länger (sehe das an meinem aktuellen Projekt, da haben die sich mehr als halbiert). Man hat ein Format dass die GPU direkt versteht (kein Umwandeln mehr), Mimaps sind auch drin und es spart einiges an Speicherbandbreite.