Weitere S3TC-Ergebnisse.

[zeckensack]

Wollte nicht weiter ow's Thread mit dem Kram zumüllen. Wer wissen will, wie alles angefangen hat, der lese bitte hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=14919&pagenumber=6).

Hier hab ich jetzt noch ein Bildchen von einer Geforce2MX, Treiber-Version 28.32.

Der Treiber hat im Grunde genau das gemacht, was er auch sollte, nämlich meine Applikation nicht mit irgendwelchen Tricks verarscht.

Insgesamt muß ich aber der Radeon (siehe anderer Thread) dann doch die höhere S3TC-Qualität unterstellen. Besonders auffällig finde ich den wesentlich unregelmäßigeren Verlauf in der zweiten Reihe, sowohl bei DXT3 als auch - weniger auffällig - DXT5.

Tests mit aktiviertem Texturfilter hab ich mir geschenkt, schließlich kommt's ja auch da auf das Rohmaterial an.

[zeckensack]

Noch mal zur Veranschaulichung, hier ein Differenzbild MX gegen Radeon. Ich hab's mit +3.0 Gamma aufgepumpt, dadurch ist der Effekt natürlich stark übertrieben. Das hab ich gemacht damit man besser sieht, wo die Unterschiede sind. Außerdem hätte sonst die JPEG-Kompression die kleineren Unterschiede einfach wegkomprimiert.

[zeckensack]

Hallo, Bild?

http://www.forum-3dcenter.org/vbulletin/attachment.php?s=&postid=187940

[zeckensack]

Na!

Klappt in diesem Thread irgendwie nicht, das Differenzbild gibt's hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=187940#post187940) zu sehen.

[ow]

Hmm, was sieht man denn jetzt da auf dem Differenzbild?

Lässt sich das irgendwie deuten?

[zeckensack]

Originally posted by ow
Hmm, was sieht man denn jetzt da auf dem Differenzbild?

Lässt sich das irgendwie deuten?
Schwer. Man kann auf jeden Fall darauf sehen, daß sich Geforce2 und Radeon nicht ganz einig sind, wie man Texturen zu addressieren hat und/oder welcher Bildpunkt zu bemalen ist. Zu sehen an den hellen senkrechten und waagrechten Linien. Wer da jetzt richtig arbeitet und wer falsch, da hab ich vorerst keine Ahnung, möglicherweise hängt das auch mit unterschiedlicher Subpixel-Präzision zusammen, dann hätten technisch gesehen beide Fraktionen recht.

Die verschiedenfarbigen Kleckse im dritten und im sechsten Streifen deuten darauf hin, daß einer der beiden Kontrahenten Alpha und Farbe bei DXT5 - nach der Dekompression wohlgemerkt - unterschiedlich auflöst. Auch hier wieder keine Ahnung wer das ist.

Was man aber am Vergleich des jeweils fünften Streifens sehen kann ist, daß die Radeon offensichtlich intern mit höherer Farbauflösung arbeitet als die Gf2, und daß dieser Effekt in bestimmten Situationen sogar schon bei einer einzigen Textur und ohne Multipass - allerdings mit blending - sichtbar ist.

/edit
Noch ein Zusatz: die Geforce2 schneidet IMO hier schlechter ab, allerdings halte ich das nicht wirklich für tragisch. Dieser Test ist glaube ich eine Extremsituation, der halt die volle Präzision erfordert. Im echten Leben wird das wesentlich weniger bis garnicht auffallen. Den verramschten Himmel in Q3 erklärt das auch nicht, die Schuld dafür liegt nach wie vor bei id.

[KiBa]

Warum liegt die Schuld bei id?
Die haben DXT1 verwendet, was nunmal fehlerhaft auf den meisten NVidia-Karten implementiert ist. Der Himmel verwendet doch gar keine Alpha-Texturwerte, da wird einfach mit nem festen Wert geblendet, oder irre ich mich da? Wenn das so ist, müssten DXT1 (original Q3) und DXT3 (Q3-fix) exakt gleich aussehen, was bei NVidia nun mal nicht der Fall ist...
Ich habe auch mal ein wenig in Direct3D programmiert und hatte dieselben Probleme. Sobald DXT1-Texturen ins Spiel kamen, wurde es häßlich bei Transparenz-Effekten...

[zeckensack]

Originally posted by KiBa
Warum liegt die Schuld bei id?
Die haben DXT1 verwendet, was nunmal fehlerhaft auf den meisten NVidia-Karten implementiert ist. Der Himmel verwendet doch gar keine Alpha-Texturwerte, da wird einfach mit nem festen Wert geblendet, oder irre ich mich da? Wenn das so ist, müssten DXT1 (original Q3) und DXT3 (Q3-fix) exakt gleich aussehen, was bei NVidia nun mal nicht der Fall ist...


Ei so ist das also, die Himmelstexturen haben gar keinen Alphakanal ???
Hättest du mir auch ruhig ein paar Tage früher erzählen können ;)

So, wie soll ich denn das nun wieder testen ... ???
Im Moment ist die Gelegenheit günstig, hab jetzt 'ne MX im Hause (steckt grad im Zweitrechner und bleibt wahrscheinlich auch drin).

[ow]

@Kiba

Hast du schon mal den Q3 Himmel auf einer Radeon1 bewundert?

Wenn das die korrekte Umsetzung sein soll, dann ist NVs fehlerhafte aber wesentlich besser gelungen.

[KiBa]

@ow
wenn ich deinen letzten thread beim überfliegen richtig interpretiert habe, warst du mit der q3-himmel qualität und den lightmaps bei eingeschalteter texturkompression nicht einverstanden.
zu deinen geposteten screenshots kann ich nur sagen, dass es auf nvidia-karten mit dxt1-bug imo noch schlimmer aussieht. die lightmap-probleme hatten die meisten ja nicht, da würde ich den fehler mal bei deinem system suchen...

[KiBa]

@zeckensack
wenn du mal zeit und lust hast, render mehrere polygone übereinander mit einem festen alpha-wert (z.b. alphawerte von der vertex-farbe). die texturen dürfen keinen alpha-kanal besitzen.
ich wäre mal gespannt auf die unterschiede zwischen dxt1 und dxt3, obwohl keiner exestieren sollte...

[ow]

Originally posted by KiBa
@ow
wenn ich deinen letzten thread beim überfliegen richtig interpretiert habe, warst du mit der q3-himmel qualität und den lightmaps bei eingeschalteter texturkompression nicht einverstanden.
zu deinen geposteten screenshots kann ich nur sagen, dass es auf nvidia-karten mit dxt1-bug imo noch schlimmer aussieht. die lightmap-probleme hatten die meisten ja nicht, da würde ich den fehler mal bei deinem system suchen...


Die lightmap Probleme haben die nicht, deren Treiber bescheissen, indem die Lightmaps nicht komprimiert werden.

Sowohl auf GF2MX, Radeon1, Kyro1 taucht das Problem auf, wenn die lightmaps komprimiert werden.

Der Q3 Himmel auf der Radeon ist mit Abstand das grässlichste was ich je gesehen hab, hat mich richtig schockiert. Auf der Kyro sieht der Himmel gut aus.

[HOT]

Hast du wohl nen verdammt miesen Treiber erwischt... bei mir sieht der Himmel komprimiert recht gut aus. Die Radeon7500 besteht aus Radeon1 Technik.

[Birdman]

nee nee, ich kann das mit dem hässlichen Himmel auch nachvollziehen...von mir sind ja auch die Shots. (Ati8500 treiber waren 6043)

btw. vielleicht sollte diejenigen die hier behaupten dass bei ihnen der Himmel mit der Ati gut ausieht, zuerst mal die texturkompression aktivieren.
ab ver. 1.17 hat id das ding ja standardmässig deaktiviert....

[zeckensack]

Originally posted by KiBa
@zeckensack
wenn du mal zeit und lust hast, render mehrere polygone übereinander mit einem festen alpha-wert (z.b. alphawerte von der vertex-farbe). die texturen dürfen keinen alpha-kanal besitzen.
ich wäre mal gespannt auf die unterschiede zwischen dxt1 und dxt3, obwohl keiner exestieren sollte...

Hab ich jetzt gemacht, mit einer rein weißen, einer rein grauen und einer rein grünen Textur, nix Alphakanal, Alpha nur durch interpolierte Vertex-Farben. Fazit bisher: die Auflösung des Alphakanals ändert sich nicht abhängig vom Texturformat (bisher nur Radeon, Gf2MX mach ich irgendwann später). Kann mir mal jemand 'nen Tip geben, wie ich das offensichtliche Defizit im Q3-Himmel reproduzieren kann? Multitexturing oder was? Ich bin hier ein wenig ratlos, wie ich ein funktiontionierendes Testszenario aufbauen muß ???

[Xmas]

Originally posted by zeckensack
Hab ich jetzt gemacht, mit einer rein weißen, einer rein grauen und einer rein grünen Textur, nix Alphakanal, Alpha nur durch interpolierte Vertex-Farben. Fazit bisher: die Auflösung des Alphakanals ändert sich nicht abhängig vom Texturformat
Klar, die Berechnung erfolgt immer mit 9 Bit pro Kanal (GeForce). Wenn die Eingangswerte aber nur 4 Bit sind, ist das Resultat natürlich nicht ganz optimal...

[ow]

Originally posted by zeckensack


Kann mir mal jemand 'nen Tip geben, wie ich das offensichtliche Defizit im Q3-Himmel reproduzieren kann? Multitexturing oder was? Ich bin hier ein wenig ratlos, wie ich ein funktiontionierendes Testszenario aufbauen muß ???

Multitexturing scheidet aus, der Q3 Himmel funzt auch bei "Vertex lighting", welches single pass laeuft und nur eine Texturlage benutzt.

Mehr weiss ich dazu nicht.

Ausser dass alle Q3 Texturen original in unkomprimiertem 32Bit Format vorliegen AFAIK.

*nachdenk*

wenn ich mich nicht irre, dann wird der Q3 Himmel sogar vom ollen Permedia2 korrekt dargestellt.
Es kann sich also nur um einfaches additives Alpha-Blending handeln (viel anderes kann der Perm.2 nicht).

Oder genauer: der Perm.2 kann AFAIK
ONE - ONE,
ONE - ONE_MINUS_SRC_ALPHA
SRC_ALPHA - ONE_MINUS_SRC_ALPHA

Mehr Blending is mit dem P2 nicht.
Vielleicht hilft dir das ja weiter.

[Liszca]

Originally posted by ow
@Kiba

Hast du schon mal den Q3 Himmel auf einer Radeon1 bewundert?

Wenn das die korrekte Umsetzung sein soll, dann ist NVs fehlerhafte aber wesentlich besser gelungen.

am schönsten habe ich den himmer bei den Voodoo karten und kyro karten gesehen!

[Liszca]

wiso interressiert euch das so ???

[Haarmann]

Naja ich denke eher, dass es am GF S3TC liegt, der den Himmel auf 4/4/4/4 entpackt...

[Liszca]

Originally posted by Haarmann
Naja ich denke eher, dass es am GF S3TC liegt, der den Himmel auf 4/4/4/4 entpackt...

4 bit rot, 4 bit grün, 4 bit blau, 4 bit alpha werte ??? stimmt das so ???

[Gerhard]

Huch, was man hier alles liest. Für den Quake3 Himmel ist DXT1 vollkommen ausreichend, da hier der Alpha Wert der Texturen garnicht genutzt wird, es wird vielmehr ein konstanter Alphawert über die gesamte Textur benutzt.
Wäre es anders, würde DXT1 garnicht funktionieren, da hier nur ein Bit für Alpha zur Verfügung steht, also durchsichtig oder undurchsichtig. DXT3 bringt bei korrekter dekomprimierung für den Himmel keinerlei Vorteile gegenüber DXT1, braucht nur mehr Speicher (nachzuvollziehen bei GF4TI oder ATI Radeon).
Das bei der Geforce1/2/3 so ein starker Unterschied zwischen DXT1 und DXT3 zu bemerken ist, liegt einfach daran, das bei diesen Karten aus Performancgrüuden intern (pro Microblock) von DXT1 auf 16Bit Texturen (5/5/5/1), bei DXT3 dagegen auf 32Bit (8/8/8/8) dekomprimiert wird (16Bit 4/4/4/4 sähe absolut furchbar aus, ausserdem wäre dan DXT3 schlechter als DXT1). Die anderen Karten arbeiten dagegen immer mit 32Bit. Dies fällt besonderst bei Quake3 auf, da hier zum einen mehrere Layers, zum anderen noch overbrightness über die Gammakorrektur der Grafikkarte verwendet wird, und somit in der Regel nichteinmal die 16Bit voll genutzt werden.

Also kein Fehler von den Quake3 Entwicklern (er währe sonst sicherlich auch schon längst beseitigt worden), sondern eine Performanceoptimierung bei den Geforce1/2/3 Karten. Manche Leute denken einfach nicht das geringste über die eigentlichen Ursachen nach :(

[Mephisto]

Originally posted by Gerhard
Manche Leute denken einfach nicht das geringste über die eigentlichen Ursachen nach.
Die Frage ist, ob man einfach durch Nachdenken darauf kommen kann, wie hard- oder softwareseitig bestimmte Features implementiert sind. Manchmal ist man auf Spekulieren angewiesen.
Mich würde auch interessieren, wo solch detaillierte Informationen zu finden sind.
Könntest Du bitte, falls vorhanden, entsprechende Links posten?
Besten Dank! :)

[ow]

Originally posted by Gerhard
Huch, was man hier alles liest. Für den Quake3 Himmel ist DXT1 vollkommen ausreichend, da hier der Alpha Wert der Texturen garnicht genutzt wird, es wird vielmehr ein konstanter Alphawert über die gesamte Textur benutzt.
Wäre es anders, würde DXT1 garnicht funktionieren, da hier nur ein Bit für Alpha zur Verfügung steht, also durchsichtig oder undurchsichtig. DXT3 bringt bei korrekter dekomprimierung für den Himmel keinerlei Vorteile gegenüber DXT1, braucht nur mehr Speicher (nachzuvollziehen bei GF4TI oder ATI Radeon).
Das bei der Geforce1/2/3 so ein starker Unterschied zwischen DXT1 und DXT3 zu bemerken ist, liegt einfach daran, das bei diesen Karten aus Performancgrüuden intern (pro Microblock) von DXT1 auf 16Bit Texturen (5/5/5/1), bei DXT3 dagegen auf 32Bit (8/8/8/8) dekomprimiert wird (16Bit 4/4/4/4 sähe absolut furchbar aus, ausserdem wäre dan DXT3 schlechter als DXT1). Die anderen Karten arbeiten dagegen immer mit 32Bit. Dies fällt besonderst bei Quake3 auf, da hier zum einen mehrere Layers, zum anderen noch overbrightness über die Gammakorrektur der Grafikkarte verwendet wird, und somit in der Regel nichteinmal die 16Bit voll genutzt werden.

Also kein Fehler von den Quake3 Entwicklern (er währe sonst sicherlich auch schon längst beseitigt worden), sondern eine Performanceoptimierung bei den Geforce1/2/3 Karten. Manche Leute denken einfach nicht das geringste über die eigentlichen Ursachen nach :(




Dann erklaere jetzt mal, warum S3TC unter Q3 auf meiner Radeon in 32Bit noch schlechter ausssieht als auf meiner GF2MX.

Und was ist mit den Verfaerbungen der Lightmaps, s. Shot?

Und von Performanceoptimierung kann wohl keine Rede sein, wenn DXT3 gerade mal 1-3% langsamer als DXT1 ist auf NV Karten.

[zeckensack]

Hosting ist schon was feines:
Und jetzt sollte es auch klappen ;)
Neue Bildchen (http://home.t-online.de/~zsack/s3tc_noalpha.zip).
Zur Erklärung:
Zwei Screenies, einmal Radeon, einmal Geforce2MX. Texturfilter deaktiviert.
1-3: Textur ohne Blending auf den Monitor geklebt, zuerst unkomprimiert, dann DXT1, dann DXT3. Alphakanal für DXT3 ist auf volle Pulle, der Helligkeitsverlauf ergibt sich also nur durch die RGB-Komponenten.
4-6: Dito, nur daß diesmal die gleiche Textur 16fach mit aktivem Blending übereinandergemalt wurde. Alpha dafür kommt aus Vertex-Farben.

Die Geforce2MX erzeugt ziemlich schrottiges in Banding in DXT1, abzählen ergibt 32 Treppchen und Grünfehler, verhält sich also wie eine RGB565-Textur. DXT3 sieht auch nicht wirklich gut aus.
Radeon ist oben besser, allerdings geht der Blending-Test doch arg in die Hose.

[Gerhard]

@ow
Das ist einfach, dies ist die Lightmapkomprimierung, diese sieht sowohl bei der Geforce2 als auch bei der Radeon bescheiden aus, hier sieht man allerdings nicht die Bit-Ungenauigkeit, sondern die Artefakte die durch die Komprimierung entstehen, diese sind bei allen Karten gleichermassen vorhanden. Neuere Quake3 Versionen komprimieren aus diesem Grund übrigens Lightmaps überhaupt nicht mehr, sondern nur mehr noramle Texturen. Du hast hier also offensichtlich unterschiedliche Einstellungen verwendet.

Diese Optimierung ist Hardwaremässig vorhanden, es geht hier vor allem um die besser Ausnutzung des Texture-Cache. Wiestark der Vorteil ist hängt vor allem davon ab, was die Bremse ist, bei Quake3 ist es meistens aber nicht der Texture-Cache (da dieser hier schon sehr gut optimiert ist), sondern eher die Speicherbandbreite, deswegen ist hier der Vorteil nicht besonderst gross.

Das was ich geschrieben habe ist keine Vermutung, sondern eine Tatsache, dies sich mit einem X-Beliebigen Programm nachweisen lässt, das eine DXT1 und DXT3 Textur dekomprimiert. Brauchst es hier wirklich nicht anzuzweifeln, aber wenn du willst kann ich dir heute Abend einige Bilder liefern. (und eventuell das Testprogramm, sofern ich es noch finde). DXT1 ist wirklich nur ein Bit Alpha (brauchst nur in den Spezifikationen nachsehen) und 1 Bit ist nur ein/aus. Der Himmel wäre also durchsichtig oder undirchsichtig. Es gibt auch ein DXT1 ohne Alpha-Bit, dieses wird dann auf 5/6/5 dekomprimiert (siehe Foto Zeckensack, PS: Danke)

Geforce und Radeon Vergleichsfotos kann ich hier auch leicht machen, aufpassen das der DXT3 Fix (=S3Quality Fix) nicht aktiv ist, dann lässt sich dies leicht zeigen. Bei Quake3 ist dies noch kein Problem, da hier die Texturen beim Levelladen komprimiert werden, und somit die Methode änderbar ist (und auch der Kompressor auf die Qualität einwirkt, welche übrigens bei allen Karten ausser der S3 Savage4 Softwaremässig arbeitet), anderst sieht es dagegen bei Spielen aus die vorkomprimierte Texturen verwenden (Beispiel UT, Unreal 9), dort hat man die Möglichkeiten nicht.

@Zeckensack
(Download des ZIP Files) OK, nun gehts doch, war wohl zu voreilig, sorry

[zeckensack]

T-Offline braucht immer ein paar Minuten, außerdem hab' ich vorsichtshalber noch den Dateinamen komplett auf Kleinbuchstaben umgestellt. Mittlerweile kann ich es von hier aus korrekt runterladen.

[ow]

Originally posted by Gerhard
@ow
Das ist einfach, dies ist die Lightmapkomprimierung, diese sieht sowohl bei der Geforce2 als auch bei der Radeon bescheiden aus, hier sieht man allerdings nicht die Bit-Ungenauigkeit, sondern die Artefakte die durch die Komprimierung entstehen, diese sind bei allen Karten gleichermassen vorhanden. Neuere Quake3 Versionen komprimieren aus diesem Grund übrigens Lightmaps überhaupt nicht mehr, sondern nur mehr noramle Texturen. Du hast hier also offensichtlich unterschiedliche Einstellungen verwendet.



Nein, ich weiss dass es alle meine S3TC faehigen Karten (Radeon1, Kyro1, GF2MX) diese Verfaerbung zeigen.
Allerdings wundert mich, dass man seinerzeit (Q3) nix daruebergelesen hat. Ich hab das naemlich lange Zeit fuer den beruechtiugten S3TC-'Bug' be NV gehalten. Ist aber dann ja doch eine Limitierung von S3TC selbst (man sollte es wohl besser nicht fuer kleine Texturen einsetzen).



Das was ich geschrieben habe ist keine Vermutung, sondern eine Tatsache, dies sich mit einem X-Beliebigen Programm nachweisen lässt, das eine DXT1 und DXT3 Textur dekomprimiert. Brauchst es hier wirklich nicht anzuzweifeln, aber wenn du willst kann ich dir heute Abend einige Bilder liefern. (und eventuell das Testprogramm, sofern ich es noch finde). DXT1 ist wirklich nur ein Bit Alpha (brauchst nur in den Spezifikationen nachsehen) und 1 Bit ist nur ein/aus. Der Himmel wäre also durchsichtig oder undirchsichtig. Es gibt auch ein DXT1 ohne Alpha-Bit, dieses wird dann auf 5/6/5 dekomprimiert (siehe Foto Zeckensack, PS: Danke)



Wo hab ich was angezweifelt??? Ich habe dich nur um eine Erklaerung gebeten.
Und warum der Q3-Himmel auf meiner Radeon1 in 32Bit so haesslich ist, hat mir bis jetzt noch niemand gesagt. Ist das auch eine Limitierung durch S3TC, denn ich sehe da richtig haessliche quadratische (&fast einfarbige) Bloecke? Sieht wie ungefiltert aus (nearest point sampling). Also wie bei den Lightmaps zu geringe Texturaufloesung um mit S3TC ein anstaendiges Ergebnis zu erreichen??

[Gerhard]

@ow, sorry wollte dir nichts unterstellen. Ich habe zumindest mit der Radeon8500 eine deutliche Verbesserung festgestellt (liegt nun zumindest auf dem Niveau der Geforce2 mit S3Quality Trick, eher noch besser. Kann natürlich sein das die 1er Radeon hier schlechter abschneidet. Leichte Kästchenstruckturen sieht man leider immer, liegt in der Natur der S3TC Komprimierung begründet (besonderst an Blockübergängen). Kannst du vielleicht mal ein Foto vom Himmel posten, dann kann man ja vergleichen.

Was auch sein kann, im Control Panel unbedingt diese "Convert 32 Textures to 16Bit" oder so ähnlich abstellen, imho sollte so eine Option mit einer Warnung versehen werden, oder zumindest nicht per default aktiviert werden :(

[ow]

Die 32 nach 16Bit Konvertierung ist abgeschaltet.

Screenshot gibt's schon irgendwo hier im Forum, ich such ihn mal und haeng ihn hier rein.

[ow]

Hier der Screenshot (ich hoffe man kann was erkennen, mein Rechner hier (Arbeitsplatz) hat nur 2MB ATi onboard = nur 16Bit Farbtiefe in 1024 Aufloesung):


/edit: der Shot ist aus diesem Thread: http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=14919

[Gerhard]

So, hier sind meine 2 Vergleichsbilder, habe sie gerade mit den gleichen Quake3 Einstellungen gemacht. (je ~ 100kByte)

NVidia (mit Geforce2Go, Detonator 27.10) S3TCQuality (DXT3) deaktiviert:
http://www.edu.uni-klu.ac.at/~gpfeiffe/gf2go.jpg

und Radeon 8500, Plutonium XP71 Treiber. Beide unter WindowsXP
http://www.edu.uni-klu.ac.at/~gpfeiffe/r8500.jpg

Der Unterschied ist eigentlich mehr als deutlich. Für Quake-Spiele bietet NVIDIA ja die Möglichkeit DXT3 zu verwenden (S3TCQuality auf 1, die Qualität entspricht dann ungefähr der Radon8500, vielleicht minimal schlechter, deckt sich auch mit den Ergebnissen des Testprogramms von Zeckensack ), nur bei vorkomprimierten Texturen hilft auch dies nicht.

[zeckensack]

Hmmm. Sieht irgendwie alles ziemlich ranzig aus. Auf meiner Radeon 1 ist's auch nicht besser. Dabei sind die Texturen eigentlich sehr gut für DXT1 geeignet. (pak0.pk3 mit Winzip öffnen und in textures/skies die jpgs abgreifen)

Vielleicht ist das einfach nur eine dumme Treiber-'Optimierung', der Treiber übernimmt in diesem Fall ja die Wandlung ins komprimierte Format. DXT1-Kompression ist ein ziemlich schwieriges Optimierungsproblem (im mathematischen Sinne) und dauert je nach Qualität relativ lang. Hier zu schlampen kann zB die Ladezeiten in Q3 drastisch verkürzen.
Werd' mal versuchen, die Texturen mit externen Tools zu komprimieren, hab da irgendwo noch die Referenzteile von S3 rumfliegen ... Jäger und Sammler halt, hoffentlich hab ich das Zeug noch nicht weggeworfen ???

[Gerhard]

Ja, die Qualität leidet wirklich merkbar, sinnvoll wäre es meines erachtens nur, solche transparenten Texturen (gerade bei Quake ist es eh nur die Himmelstextur die wirklich stört (Danke aths ;) ) gar nicht zu komprimieren. Das Problem am Himmel ist, das die Texture riesig aufgeblasen wird, dadurch fallen alle Artefakte so stark auf, zum anderen wird bei Quake3 die Helligkeit so hochgedreht.

Aber gerade auf dem Notebook (nur 16MByte Videospeicher) ist die Texturekomprimierung unverzichtbar.

[Unregistered]

Originally posted by zeckensack
Hmmm. Sieht irgendwie alles ziemlich ranzig aus. Auf meiner Radeon 1 ist's auch nicht besser. Dabei sind die Texturen eigentlich sehr gut für DXT1 geeignet. (pak0.pk3 mit Winzip öffnen und in textures/skies die jpgs abgreifen)


Wie? Versteh ich das richtig? Quake nimmt JPG Dateien (die blockkomprimiert sind) und packt sie aus und schiebt sie in den nächsten Blockkomprimierer (DXTx)? Eine Grundregel lautet: never use jpeg for texture maps. Und die Gründe sind eigentlich logisch. Ich hoffe bloß, da liegt ein Versehen vor...
Btw, heutzutage werden die Texture von vornherein in DXTx auf CD gebrannt, weil man dann mit viel Zeit komprimieren kann. Die Kompression aus dem DXSDK ist nicht die beste....

Pitchfork

[zeckensack]

Originally posted by Unregistered
Wie? Versteh ich das richtig? Quake nimmt JPG Dateien (die blockkomprimiert sind) und packt sie aus und schiebt sie in den nächsten Blockkomprimierer (DXTx)?Kannst es dir ja selbst anschauen. Die pk3s, in denen die Daten für Quake3 daherkommen, sind nichts anderes als mundäne zip-Dateien, mit jeder halbwegs aktuellen Winzip-Version oä zu öffnen.