Archiv verlassen und diese Seite im Standarddesign anzeigen : Texturkompression – wird die überhaupt sinnvoll eingesetzt?
Wie viele Spiele nutzen Texturkompression? Wie exzessiv wird die genutzt? Und warum kann man bei so gut wie keinem Titel bzw. keiner Engine Einfluss darauf nehmen? Mir fällt jetzt spontan nur id Software ein, die seit jeher per Konsole alles anbieten – sehr löblich.
Die Frage wirft sich mir wegen der dauernden Diskussionen um VRAM-Mengen auf Grafikkarten auf. Schon in der Vergangenheit fragte ich mich, warum "die" Grafik denn bitte so viel Speicher frisst.
Hat da jemand genaue Infos?
Was mir gerade noch einfiel: Warum bietet kein Treiber forcierbare Kompression an? Der WickedGL konnte Voodoo-Grafikkarten damit in völlig neue Fps-Sphären hieven, ohne dass man an der Optik viel bemerkte. Regelbare Kompressionsgrade wären optimal. Das Argument, dass diverse Texturen von den Entwicklern nicht zum Komprimieren vorgesehen wurden, lasse ich nicht gelten. Das mag ich dann selbst entscheiden. ;)
MfG,
Raff
Demirug
2006-07-05, 20:27:49
Wahrscheinlich dürfte jedes Spiel komprimierte Texturen nutzen. Ich habe für den Tweaker mal ein Plugin geschrieben das sowas protokoliert.
so gut wie jedes spiel verwendet normalerweise komprimierte texturen.
es gibt nur manche "idiotische" spiele wie z.b von id-software die in der höchsten detailstufe nichts machen als die texturkompression auszuschalten.
im normalfall sind aber zumindest diffuse-maps komprimiert, lediglich normalmaps werden oft unkomprimiert verwendet.
ein erzwingen der texturkompression ist zumindest bei nvidia in openGL möglich.
Mike1
2006-07-05, 20:34:57
was wird da eigentlich gemacht, und kostet das nicht viel leistung?
StefanV
2006-07-05, 20:35:50
1. die Texturen werden komprimiert (fast lossless), so a la JPG.
2. nein, komprimierte Texturen bringen Leistung (oder aber größere/bessere Texturen bei gleicher).
Mike1[/POST]']was wird da eigentlich gemacht
http://en.wikipedia.org/wiki/S3_Texture_Compression
Mike1[/POST]']und kostet das nicht viel leistung?
Im Gegenteil.
Raff[/POST]']Wie viele Spiele nutzen Texturkompression? Wie exzessiv wird die genutzt? Und warum kann man bei so gut wie keinem Titel bzw. keiner Engine Einfluss darauf nehmen? Mir fällt jetzt spontan nur id Software ein, die seit jeher per Konsole alles anbieten – sehr löblich.
Die Frage wirft sich mir wegen der dauernden Diskussionen um VRAM-Mengen auf Grafikkarten auf. Schon in der Vergangenheit fragte ich mich, warum "die" Grafik denn bitte so viel Speicher frisst.
Hat da jemand genaue Infos?
Was mir gerade noch einfiel: Warum bietet kein Treiber forcierbare Kompression an? Der WickedGL konnte Voodoo-Grafikkarten damit in völlig neue Fps-Sphären hieven, ohne dass man an der Optik viel bemerkte. Regelbare Kompressionsgrade wären optimal. Das Argument, dass diverse Texturen von den Entwicklern nicht zum Komprimieren vorgesehen wurden, lasse ich nicht gelten. Das mag ich dann selbst entscheiden. ;)
MfG,
Raff
Wie stellst du dir das genau vor? Zur Laufzeit (im Level), oder waehrend des Loadings eines Levels? Das erste sollte doch die CPU noch weiter belasten und CPU-limitierte Spiele noch verlangsamen?
Monger
2006-07-05, 20:53:58
Mike1[/POST]']was wird da eigentlich gemacht, und kostet das nicht viel leistung?
Der JPG Vergleich ist wohl ganz geschickt: Die Texturen liegen bereits komprimiert auf Festplatte vor. Da diese wesentlich kleiner sind als die unkomprimierten Originale, lassen sie sich wesentlich bequemer über die AGP / PCIe Schnittstelle schieben, und auch wesentlich bequemer im VRAM einlagern.
Das Problem ist nur, dass sie an irgendeiner Stelle entpackt werden müssen, und das muss die Grafikkarte natürlich in Echtzeit können.
Wer heute keine unkomprimierten Texturen mehr verwendet, reisst vermutlich die Performance kräftig in den Keller.
Deshalb bin ich mal gespannt, wann es ein hardwareunterstütztes Kompressionsformat für Normal Maps geben wird. Ich vermute, wenn sich das erstmal eingebürgert hat, wird man Normal Maps auch in anständiger Auflösung verwenden können, ohne gleich Grafikkartenspeicher und Bandbreite zuzuballern.
IVN[/POST]']Wie stellst du dir das genau vor? Zur Laufzeit (im Level), oder waehrend des Loadings eines Levels? Das erste sollte doch die CPU noch weiter belasten und CPU-limitierte Spiele noch verlangsamen?
Beim WickedGL wurde vor dem Spielstart eine Datei angelegt, die die Infos auf der Platte speicherte. Ok, bei neuen Spielen kann das dann wohl schnell die Platte zuknallen und dürfte etwas dauern. Aber dann hat man schnellere Spiele. Es gibt aber sicher einen "on-the-fly"-Kompromiss, der besser ist als garkeine/billige Kompression.
MfG,
Raff
Raff[/POST]']1. Beim WickedGL wurde vor dem Spielstart eine Datei angelegt, die die Infos auf der Platte speicherte. Ok, bei neuen Spielen kann das dann wohl schnell die Platte zuknallen und dürfte etwas dauern. Aber dann hat man schnellere Spiele. 2. Es gibt aber sicher einen "on-the-fly"-Kompromiss, der besser ist als garkeine/billige Kompression.
MfG,
Raff
1. Das hoert sich interessant an.
2. Klar, besonders bei GPU-limitierten Spielen.
Raff[/POST]']Wie viele Spiele nutzen Texturkompression? Wie exzessiv wird die genutzt? Und warum kann man bei so gut wie keinem Titel bzw. keiner Engine Einfluss darauf nehmen? Mir fällt jetzt spontan nur id Software ein, die seit jeher per Konsole alles anbieten – sehr löblich.
Praktisch jedes Spiel nutzt Texturkomprimierung, ausgenommen werden allerdings meist Normal Maps und irgendwelche Lookup Tables. Um Normal Maps brauchbar zu komprimieren muss man in der Regel die Shader ändern, deswegen lässt sich das auch schlecht erzwingen.
Dass man darauf kaum Einfluss nehmen kann liegt daran dass die Spiele meist nur noch mit den komprimierten Texturen ausgeliefert werden, schließlich belegen die Originaltexturen nur unnötig (sehr viel) Speicherplatz wenn sie nicht verwendet werden.
Ultra Quality ist lediglich ein kleines Extra, ein kleines Bisschen mehr Qualität für jene Systeme die erst in Zukunft Standard sein werden.
Die Frage wirft sich mir wegen der dauernden Diskussionen um VRAM-Mengen auf Grafikkarten auf. Schon in der Vergangenheit fragte ich mich, warum "die" Grafik denn bitte so viel Speicher frisst.
Man hat heute in der Regel größere Welten als früher, mehr Texturlagen, und das mehr an Texturen wird auch dafür eingesetzt um Wiederholungen deutlich zu reduzieren. Dies und die weitere Erhöhung der Texturauflösung fällt nicht mehr so stark auf wie die Entwicklungsschritte früher, kostet aber deutlich mehr Speicher.
Was mir gerade noch einfiel: Warum bietet kein Treiber forcierbare Kompression an? Der WickedGL konnte Voodoo-Grafikkarten damit in völlig neue Fps-Sphären hieven, ohne dass man an der Optik viel bemerkte. Regelbare Kompressionsgrade wären optimal. Das Argument, dass diverse Texturen von den Entwicklern nicht zum Komprimieren vorgesehen wurden, lasse ich nicht gelten. Das mag ich dann selbst entscheiden. ;)
Damals war S3TC aber noch keine 5 Jahre Standard. Heute würdest du an den fps nicht mehr viel bemerken.
Mike1
2006-07-05, 23:40:00
ja aber wenn ich ein .rar archiv entpacke hat meine meine CPU ordentlich zu hackeln, warum nicht auch so bei komprimierten texturen?
StefanV
2006-07-05, 23:40:55
Mike1[/POST]']ja aber wenn ich ein .rar archiv entpacke hat meine meine CPU ordentlich zu hackeln, warum nicht auch so bei komprimierten texturen?
Weil man dafür Hardware verwendet und dafür spezielle Einheiten genutzt hat.
BlackBirdSR
2006-07-05, 23:55:49
Mike1[/POST]']ja aber wenn ich ein .rar archiv entpacke hat meine meine CPU ordentlich zu hackeln, warum nicht auch so bei komprimierten texturen?
30+GB/s Speicherbandbreite, noch höhere Werte innerhalb des Chips und Texturen statt generischem Code. Das geht dann schon sehr schnell.
Wenn du ein rar-archiv entpackst hast du vielleicht 2GB/s Bandbreite, musst die Daten von der Festplatte lesen und gleichzeitig schreiben. Das ist nicht wirklich vergleichbar.
Neomi
2006-07-06, 00:19:47
BlackBirdSR[/POST]']30+GB/s Speicherbandbreite, noch höhere Werte innerhalb des Chips und Texturen statt generischem Code. Das geht dann schon sehr schnell.
Wenn du ein rar-archiv entpackst hast du vielleicht 2GB/s Bandbreite, musst die Daten von der Festplatte lesen und gleichzeitig schreiben. Das ist nicht wirklich vergleichbar.
Der Vergleich ist ja schön und gut, aber RAR ist trotzdem nicht vergleichbar mit Texturkompression. Die Daten, die du genannt hast, spielen keine Rolle, weil der Unterschied an ganz anderer Stelle sitzt.
Ein RAR-Archiv ist eigentlich ein gepackter Stream von Daten. Um auf ein Byte zuzugreifen, muß man alles davor entpacken. RAR ist darauf ausgelegt, verlustfrei (sonst wäre es nicht für Daten geeignet) so stark zu komprimieren, wie es nur irgendwie geht.
DXT1 bis DXT5 sind blockbasierte (4x4 Texel) verlustbehaftete Kompressionsverfahren. Sie sind darauf ausgelegt, bei nicht allzu starkem Verlust die Größe einzudampfen, um bei gleichbleibender Speicherbandbreite mehr Texel übertragen zu können (daher der Geschwindigkeitsvorteil bei Kompression) und nebenbei Speicher zu sparen. Es werden pro Block zwei Referenzfarben mit je 16 Bit abgelegt, dazu werden zwei weitere Farben per Interpolation (sollte dann mit höherer Präzision erfolgen) generiert (DXT1 kennt noch einen Spezialfall für Transparenz). Dann gibt es 16 Indizes à 2 Bit, mit denen in diesem Array indiziert wird. Für die Transparenz (DXT2 bis DXT5) gibt es einen weiteren Block, der ähnlich aufgebaut ist. Ein 4x4-Block kann ohne weitere Daten von anderen Blöcken entpackt werden. Jeder Block hat die gleiche Größe und läßt sich deshalb genauso einfach in der Textur lokalisieren wie ein Texel in einer ungepackten Textur. GPUs haben dafür natürlich spezielle Hardware, aber komprimierte Texturen lassen sich auch auf ganz normalen CPUs mit sehr hoher Geschwindigkeit entpacken.
RAR und DXTC fallen zwar beide in den Bereich Kompression, arbeiten aber völlig verschieden und sind nicht wirklich vergleichbar. RAR hat mehr Gemeinsamkeiten mit HTML als mit DXTC.
Mit Bandbreite hat das nichts zu tun. Das wird einfach on-the-fly entpackt wenn Daten vom L2- in den L1-Texturecache geladen werden (auf nVIDIA-GPUs zumindest).
RAR ist auch um Größenordnungen komplexer als S3TC und zudem verlustfrei.
zeckensack
2006-07-06, 00:40:30
Monger[/POST]']Das Problem ist nur, dass sie an irgendeiner Stelle entpackt werden müssen, und das muss die Grafikkarte natürlich in Echtzeit können.Das ist kein Problem, denn das können alle heute noch relevanten Grafikchips.
Wer heute keine unkomprimierten Texturen mehr verwendet, reisst vermutlich die Performance kräftig in den Keller.Vertipper? :|
Das Gegenteil ist der Fall. Komprimierte Texturen sparen Platz und Bandbreite, können "for free" entpackt werden, und mehr davon passt in den Texturcache.
Deshalb bin ich mal gespannt, wann es ein hardwareunterstütztes Kompressionsformat für Normal Maps geben wird.Gibt's schon eine ganze Weile.
http://www.ati.com/developer/samples/dx9/3dcnormalcompression.html
LordDeath
2006-07-06, 01:01:08
hat sich seit ut2k4 die texturauflösung in spielen tendenziell erhöht oder ist eher die anzahl der einzelnen texturvarianten gestiegen?
+1024er texturen werden doch heute noch nur für sachen wie die skybox gebraucht.
StefanV
2006-07-06, 01:07:05
Ja, die Texturauflösung steigt stetig, zumindest ist das der Eindruck, den man von aktuellen Spielen bekommen kann...
Auch steigt der (Video) Speicherverbrauch stetig an (wird echt Zeit für 64bit, näheres SIGNATUR; NICHT HIER!), unter anderem weil man die ganzen Details irgendwo unterbringen muss...
Der Speicherplatz steigt ja auch nicht alleine durch die Basistexturen, sondern insbesondere steigt er in letzter Zeit sehr zügig, durch die ganzen anderen Maps, die noch so zu moderner Grafik gehören, wie z.B. Normalmaps, Vertexmaps, etc.
Mike1[/POST]']was wird da eigentlich gemacht, und kostet das nicht viel leistung?Die Komprimierung kostet viel CPU-Leistung, deshalb werden Texturen bereits komprimiert beigelegt.
Mike1[/POST]']ja aber wenn ich ein .rar archiv entpacke hat meine meine CPU ordentlich zu hackeln, warum nicht auch so bei komprimierten texturen?Wenn du die mittels CPU entpacken wolltest, hätte die CPU auch viel zu tun. Die GPU hat dedizierte Schaltkreise dafür. Außerdem ist RAR eine Entropie-Optimierung, während DXT1 (vereinfacht gesagt) nur die räumliche Farbauflösung, und in der Helligkeit den Rauschabstand verkleinert (aber nur so weit, dass es abgesehen von Texturvergrößerungen nicht auffällt.) Zum Entpacken reichen ein paar MULs und LERPs. Um RAR zu entpacken muss man hingegen Tabellen aufbauen (da es sich wohl um ein wörterbuchbasiertes, entropieoptimiertes Verfahren handelt.)
Coda[/POST]']Mit Bandbreite hat das nichts zu tun. Das wird einfach on-the-fly entpackt wenn Daten vom L2- in den L1-Texturecache geladen werden (auf nVIDIA-GPUs zumindest).Ist bei ATI nicht anders. Was Nvidia L1-Cache nennt sind imo nur Latches.
Monger
2006-07-06, 10:11:41
zeckensack[/POST]']Das ist kein Problem, denn das können alle heute noch relevanten Grafikchips.
Logisch. Ich sag ja nur: das muss in Hardware passieren, nicht in Software. Sonst bringt's nix. Das war vor 5 Jahren noch gar nicht so selbstverständlich...
Vertipper? :|
Das Gegenteil ist der Fall. Komprimierte Texturen sparen Platz und Bandbreite, können "for free" entpackt werden, und mehr davon passt in den Texturcache.
Ich hab es nicht so sehr mit den doppelten Verneinungen nicht! :D
Ich meinte es selbstverständlich andersrum: Kompression spart Bandbreite.
Gibt's schon eine ganze Weile.
http://www.ati.com/developer/samples/dx9/3dcnormalcompression.html
Ja, aber verwendet es irgendjemand? Von nVidia hab ich in der Hinsicht bis jetzt nix gehört, und solange sich die beiden nicht einig sind (oder von MS einig gemacht werden), wird sich wohl auch kein neues Kompressionsformat flächendeckend durchsetzen.
Monger[/POST]']Logisch. Ich sag ja nur: das muss in Hardware passieren, nicht in Software. Sonst bringt's nix. Das war vor 5 Jahren noch gar nicht so selbstverständlich...Schon vor 5 Jahren konnte jeder relevante Chip DXT1.
Monger[/POST]']Ja, aber verwendet es irgendjemand? Von nVidia hab ich in der Hinsicht bis jetzt nix gehört, und solange sich die beiden nicht einig sind (oder von MS einig gemacht werden), wird sich wohl auch kein neues Kompressionsformat flächendeckend durchsetzen.Die Z-Rekonstruktion muss man im Shader immer machen, wenn man Normalmaps in nur 2 Kanälen speichert. Zweikanal-Speicherung ist auch mit jeder NV-Hardware möglich.
Monger[/POST]']
Ja, aber verwendet es irgendjemand? Von nVidia hab ich in der Hinsicht bis jetzt nix gehört, und solange sich die beiden nicht einig sind (oder von MS einig gemacht werden), wird sich wohl auch kein neues Kompressionsformat flächendeckend durchsetzen.
zumindest das 3Dc-texturformat wird auch von nvidia unterstützt. allerdings denke ich dass dort intern nur 2 "herkömliche" 8bit-kanäle gespeichert werden und keine echte kompression/dekompression erfolgt.
die 3. normale muss bei 3Dc sowieso immer im shader rekonstruiert werden, weshalb man es auch nicht "einfach so" in eine engine integrieren kann, man muss jeden shader der die normalmaps verwendet entsprechend anpassen.
aths[/POST]']Die Komprimierung kostet viel CPU-Leistung, deshalb werden Texturen bereits komprimiert beigelegt.
Eigentlich nicht sonderlich. Doom macht das auch on-the-fly beim laden.
Es kostet genug, so das man es nicht zur Laufzeit benutzen kann. D3 hat kein Texture-Kracher-Reputation, und laedt auch nicht besonders kurz. Demnach muss der Verbrauch der CPU-Leistung immens sein.
IVN[/POST]']Es kostet genug, so das man es nicht zur Laufzeit benutzen kann. D3 hat kein Texture-Kracher-Reputation, und laedt auch nicht besonders kurz. Demnach muss der Verbrauch der CPU-Leistung immens sein.
doom3 hat sogar sehr viele texturen, was die datenmengen angeht. dass man anstatt auf hohe texturauflösungen auf texturenvielfalt gesetzt hat ist eine andere sache. und mit ordentlich arbeitsspeicher läd doom3 auch nicht so wahnsinnig lang, da gibt es viel schlimmeres.
HajottV
2006-07-07, 14:58:17
Raff[/POST]']Warum bietet kein Treiber forcierbare Kompression an? Der WickedGL konnte Voodoo-Grafikkarten damit in völlig neue Fps-Sphären hieven, ohne dass man an der Optik viel bemerkte. Regelbare Kompressionsgrade wären optimal. Das Argument, dass diverse Texturen von den Entwicklern nicht zum Komprimieren vorgesehen wurden, lasse ich nicht gelten. Das mag ich dann selbst entscheiden. ;)
Weil das bei manchen Texturen grauenhaft aussieht. Dein Posting hatte mich dazu gebracht, mal selber damit zu experimientieren... hab wohl direkt ein pathologisches Beispiel erwischt (caust00.tga aus dem DXSDK). Die Textur sieht mit Kompression zum Kotzen aus. :eek:
Hab dann mal ein paar andere Texturen ausprobiert, und dort mußte man den Unterschied schon mit der Lupe suchen.
Viel an Regelbarkeit kann man wohl da nicht machen. Man könnte maximal pro Textur angeben, ob es DXT1... DXT5 sein soll. Aber mach das mal für jede Textur in einem Spiel - da hast Du was zu tun.
Gruß
Jörg
HajottV[/POST]']Weil das bei manchen Texturen grauenhaft aussieht. Dein Posting hatte mich dazu gebracht, mal selber damit zu experimientieren... hab wohl direkt ein pathologisches Beispiel erwischt (caust00.tga aus dem DXSDK). Die Textur sieht mit Kompression zum Kotzen aus. :eek:
das hängt auch sehr stark vom eingesetzten algorithmus ab, siehe hier: http://www.3dcenter.org/artikel/3dc/index5.php
HajottV[/POST]']Weil das bei manchen Texturen grauenhaft aussieht. Dein Posting hatte mich dazu gebracht, mal selber damit zu experimientieren... hab wohl direkt ein pathologisches Beispiel erwischt (caust00.tga aus dem DXSDK). Die Textur sieht mit Kompression zum Kotzen aus. :eek:
Hab dann mal ein paar andere Texturen ausprobiert, und dort mußte man den Unterschied schon mit der Lupe suchen.
Viel an Regelbarkeit kann man wohl da nicht machen. Man könnte maximal pro Textur angeben, ob es DXT1... DXT5 sein soll. Aber mach das mal für jede Textur in einem Spiel - da hast Du was zu tun.
Gruß
JörgDXT3 und DXT5 bieten abgestufte Transparenz, aber ansonsten die genau gleiche Farbkomprimierung wie DXT1.
DXT3 benützt explizites Alpha, da is nix abgestuft.
Coda[/POST]']DXT3 benützt explizites Alpha, da is nix abgestuft.Doch, in 16 Stufen.
Coda[/POST]']Eigentlich nicht sonderlich. Doom macht das auch on-the-fly beim laden.Eine einzelne 512-er Textur zu komprimieren dauert schon mal einige Sekunden, jedenfalls mit den entsprechenden Tools von ATI und NV. Doom3 müsste dann eine laufzeitoptimierte Methode nutzen – was (leicht) zulasten der Qualität gegen dürfte.
Gast[/POST]']doom3 hat sogar sehr viele texturen, was die datenmengen angeht. dass man anstatt auf hohe texturauflösungen auf texturenvielfalt gesetzt hat ist eine andere sache. und mit ordentlich arbeitsspeicher läd doom3 auch nicht so wahnsinnig lang, da gibt es viel schlimmeres.
so was denn. far cry, eine zumutung. gibt auch viel besseres, zb. splinter cell 3 oder pop.
Also meine Radeon 9700Pro komprimiert die Texturen von Half-Life (1) und den ganzen dazugehörigen Mods unter OpenGL obwohl die Texturen unkomprimiert auf der Festplatte liegen.
Zu der Zeit hätte ich auch gerne gewusst wie man das abschaltet, weil die Texturen eh nicht so toll waren und mit Kompression sahen die noch deutlich schlechter aus. Man konnte deutlich die Blockbildung erkennen.
R300[/POST]']Also meine Radeon 9700Pro komprimiert die Texturen von Half-Life (1) und den ganzen dazugehörigen Mods unter OpenGL obwohl die Texturen unkomprimiert auf der Festplatte liegen.
Zu der Zeit hätte ich auch gerne gewusst wie man das abschaltet, weil die Texturen eh nicht so toll waren und mit Kompression sahen die noch deutlich schlechter aus. Man konnte deutlich die Blockbildung erkennen.Das ist hoffentlich nur der Fall, wenn die Basemap vergrößert dargestellt wird. Der Hintergedanke von Texturkomprimierung ist, dass man für den gleichen Speicherplatz ja mehr Details speichern kann, um somit gar nicht erst Diffusemaps vergrößern zu müssen. Sieht man die Blockbildung auch bei 1:1-Darstellung oder Texturverkleinerung, taugt der Komprimierungsalgorithmus nichts.
Naja bei 1:1 Darstellung oder kleiner hat man das kaum bis garnicht gesehen, nur wenn man sehr genau hingesehen hat, aber bei Half-Life 1 waren die Texturen ja so klein, dass sie in der näheren Umgebung alle ziemlich vergrößert und unscharf waren und somit konnte man die Komprimierung ziemlich gut erkennen.
aths[/POST]']Doch, in 16 Stufen.
Nö DXT3 benützt explizites Alpha pro 4x4 Block. Was du meinst ist DXT5.
R300[/POST]']Naja bei 1:1 Darstellung oder kleiner hat man das kaum bis garnicht gesehen, nur wenn man sehr genau hingesehen hat, aber bei Half-Life 1 waren die Texturen ja so klein, dass sie in der näheren Umgebung alle ziemlich vergrößert und unscharf waren und somit konnte man die Komprimierung ziemlich gut erkennen.
Ich kann dir garantieren dass eine R300 garantiert nicht von alleine Texturen komprimiert. Was du da evtl. siehst sind Artefakte des bilinearen Filters, weil ATi da nicht volle Präzision fährt.
Wie man das ausschält? nVIDIA oder ATi ab R5xx.
Neomi
2006-07-09, 16:33:55
Coda[/POST]']Nö DXT3 benützt explizites Alpha pro 4x4 Block. Was du meinst ist DXT5.
Explizites Alpha zwar, aber trotzdem in 16 Stufen. Genau so wie unkomprimiertes A8 mit 256 Stufen daherkommt. Ihr habt einfach nur aneinander vorbeigeredet.
Coda[/POST]']Nö DXT3 benützt explizites Alpha pro 4x4 Block. Was du meinst ist DXT5.DXT3. DTX3 hat 16 4-Bit-Werte für Alpha, die in linearen Stufen 0% bis 100% abdecken. Ich schrieb "DXT3 und DXT5 bieten abgestufte Transparenz".
Jaja schon gut, siehe Neomi.
Hab den Thread gefunden den ich damals gestartet hatte.
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=89759&highlight=Kompression
das Beispiel auf den Bildern ist natürlich zu extrem. So läuft man ja nicht im Spiel rum, aber man sieht das auch auf Kisten usw. wenn man etwas weiter weg ist.
Das unkomprimierte Bild habe ich glaub ich im D3D Mode gemacht. Für D3D konnte man die DXT Kompression im Treiber abschalten.
Noch ein Zotat aus dem Thread:
pervert[/POST]']
Tatsache ist, dass man die Kompression auch in Q3-Engine-Games NICHT abgeschaltet bekommt, auch wenn man sie per console deaktiviert. Die ATI-Treiber komprimieren hier immer noch ein wenig an den Texturen herum, allerdings nicht im gleichen Umfang, als wenn man in der console die Kompression aktiviert.
Man kann aber nicht nur "ein wenig" rumkomprimieren. Entweder ganz DXT oder gar nicht.
Aber seltsam ist die Sache schon - ist ja anscheinend doch nicht die Filtergenauigkeit.
Coda[/POST]']Man kann aber nicht nur "ein wenig" rumkomprimieren. Entweder ganz DXT oder gar nicht.
Aber seltsam ist die Sache schon - ist ja anscheinend doch nicht die Filtergenauigkeit.Das würde mich auch seeehr wundern. Bilineare Filterung nutzt 6 "Nachkomma-Bitstellen", die trilineare Interpolation immerhin noch 5.
Auf den ersten Blick ein Unterschied wie zwischen 16- und 32-Bit-Texturen. Auf den zweiten Blick könnte es auch DXT sein – anhand dieses einen Screenshots schlecht zu beurteilen.
Wenn ich mich recht erinnere waren beide entweder 16 oder 32 bit, weil ich am Anfang mit 16bit gespielt habe und dann dauerhaft mit 32bit. (-32bpp in der console)
Aber die Texturen liegen eh in 8bit vor...
kann man nur die normalen texturen mit non-3dc-karten komprimieren, also alles andere bm, pm, specmaps usw. nicht? denn mit ner 32mb karte kam man früher gut aus, jetzt gar nicht mehr
Jules
2006-07-13, 14:40:31
mal eine frage, hat hier irendwer schon mal die ALPHA zu D3 angespielt???
Silpion
2006-07-13, 23:33:15
Da ich gerade einen Vortrag über Volume Rendering vorbereite, interessiert mich folgendes:
Funktioniert Texturkompression auch schon mit 3D-Texturen? Dort könnte man eine Speichersparende Methode wirklich gut gebrauchen.
ScottManDeath
2006-07-14, 11:23:10
Unter OpenGL gibts die NVIDIA NV_texture_compression_vtc extension die entsprechende interne Formate zur Verfügung stellt.
Silpion
2006-07-15, 10:45:11
Exzellent, danke.
Gibt es eine ähnliche Erweiterung auch für ATI? Ich habe zwar eine Nvidia-Karte, aber es wäre praktisch, wenn es auf Karten von beiden Herstellern läuft.
ScottManDeath
2006-07-15, 11:20:35
Nicht dass ich wüsste. Könnte aber unter DX9 sein.
ARB_texture_compression unterstützt auch 3D-Texturen, wenn es die Karte kann - würd ich einer proprietären Extension sowieso vorziehen.
Jules
2006-07-15, 23:11:49
normal maps werden auch komprimiert???
Kann man machen, ist allerdings nicht so schön wenn man die Kanäle normal sortiert lässt (x=R, y=G, z=B) - deshalb tauscht man da normal irgendwas und ändert die Shader entsprechend.
Und dann gibts natürlich noch ATis 3Dc das eine spezielle Abwandlung von DXT dafür ist - braucht aber auch Unterstützung im Shader.
Gast[/POST]']so was denn. far cry, eine zumutung. gibt auch viel besseres, zb. splinter cell 3 oder pop.
z.b das genannte farcry, oder auch halflife2, wobei letzteres bereits vorkomprimierte texturen nutzt.
*Spaten schwingt*
Was ich erst vor paar Tagen bemerkte: Der Kyro-Treiber bietet vorbildlicherweise forcierbare DXT-Kompression an. Welche genau das ist steht da zwar nicht, aber sie ist da und funktioniert. Eine Sauerei, dass das nicht Mode gemacht hat. Immer die "Außenseiter" bieten nette Sachen, aber die "Großen" pfeifen drauf (siehe S3 mit RGSSAA, auch wenn das eine Notlösung darstellt) ... :(
MfG,
Raff
Was ich erst vor paar Tagen bemerkte: Der Kyro-Treiber bietet vorbildlicherweise forcierbare DXT-Kompression an. Welche genau das ist steht da zwar nicht, aber sie ist da und funktioniert. Eine Sauerei, dass das nicht Mode gemacht hat. Immer die "Außenseiter" bieten nette Sachen, aber die "Großen" pfeifen drauf (siehe S3 mit RGSSAA, auch wenn das eine Notlösung darstellt) ... :(
sogar der integrierte grafikchip in meinem notebook, ein intel extreme-irgendwas, bietet forcierte texturkompression an, sogar wahlweise S3TC oder FXT1.
leider aber nur unter OGL, und der OGL-treiber ist so scheiße dass ein großteil der anwendungen nicht mal startet ;)
Ich poste das jetzt mal hierrein:
Weiß jemand, wie man bei Thief3 die Texturkompression abschalten kann?
Die sieht nämlich hier echt übel aus, vor allem da auch die Normalmaps komprimiert werden.
Danke!
Was ich erst vor paar Tagen bemerkte: Der Kyro-Treiber bietet vorbildlicherweise forcierbare DXT-Kompression an. Welche genau das ist steht da zwar nicht, aber sie ist da und funktioniert.
DXT1, denn Kyro kann die anderen Modi nicht. Der Nachteil bei solchen erzwungenen Einstellungen ist dass dann möglicherweise manche Benutzer Bildfehler erleben und sie nicht mit der erzwungenen Kompression in Verbindung bringen, und dann gibts wieder Geschrei...
sogar der integrierte grafikchip in meinem notebook, ein intel extreme-irgendwas, bietet forcierte texturkompression an, sogar wahlweise S3TC oder FXT1.
FXT1? Das wäre ja ein echtes Novum!
Ich weiß nicht ob Thief 3 auch unkomprimierte Texturen beiliegen, aber da wurde in der Tat einiges vermurkst (wie auch bei Deus Ex 2). Möglicherweise helfen John Ps Texturen schon mal weiter (auch wenn die bei weitem nicht alle gut sind): http://www.john-p.com/textures/Thief-DS/index.shtml
Ja die Intel-Hardware kann angeblich noch viel obskurere Dinge wie bikubische Texturfilter...
FXT1? Das wäre ja ein echtes Novum!
laut CP ja.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.