Archiv verlassen und diese Seite im Standarddesign anzeigen : Machen Texturen in hoher Farbtiefe (24 Bit) überhaupt Sinn?
Wenn die Grafikkarte in 24 bzw. 32 Bit Farbtiefe läuft und
dank Texture Filtering sowieso zwischenwerte erzeugt werden?
Das DXT5 Format hat z.B. ohne Alpha Kanal für die jeweiligen Farbkanäle RGB nur R:5, G:6, B:5 Bit, also insgesamt 16 Bit.
Erst das R8G8B8 Format hat 24 bits pro Pixel, R:8, G:8, B:8, aber macht dieses Format für gewöhnliche Texturen (also keine Normalmaps und so Zeugs) überhaupt Sinn, wenn die Grafikkarte im 32 Bit Modus sowieso durch das Filtering Zwischenwerte erzeugt?
Der Unterschied dürfte dem Betrachter doch also kaum auffallen.
Also wenn überhaupt, dann sehe ich nur bei großen Texturauflösungen einen Sinn im R8G8B8 Format, weil bei großen Texturen die Wahrscheinlichkeit sinkt, daß der Betracher gefilterte Zwischenwerte zu Gesicht bekommt.
Sprich in Fällen wie: Die für das Polygon gerade dargestellte Pixelauflösung (oder Texel?) ist kleiner als die Auflösung der eigentlichen Textur.
Ob eine bestimmte Farbtiefe notwendig ist hängt natürlich in erster Linie vom Bildinhalt ab. In vielen Fällen ist in der Tat eine auf RGB565 reduzierte Textur kaum vom Original zu unterscheiden. Ich habe gerade ein bisschen mit Fotos experimentiert, und häufig braucht es Vergrößerung um die Unterschiede klar zu sehen. Das trifft jedoch nicht mehr zu, sobald feine Farbverläufe ins Spiel kommen. Diese erscheinen bei 16-Bit-Texturen deutlich gestuft, und Dithering wäre in Vergrößerung offensichtlich. Es ist also eher so, dass man Texturvergößerung bei 16-Bit-Texturen vermeiden sollte.
Dann nimmt man aber meist lieber gleich Texturkompression, denn damit bringt man im gleichem Speicherplatz viermal höher aufgelöste Texturen unter, was dann wiederum besser aussieht (wenn das Ausgangsmaterial diese Auflösung überhaupt hergibt).
Das DXT5 Format hat z.B. ohne Alpha Kanal für die jeweiligen Farbkanäle RGB nur R:5, G:6, B:5 Bit, also insgesamt 16 Bit.
Es werden allerdings pro 4x4-Pixelblock zwei Mischfarben mit 8 Bit pro Kanal erzeugt, so dass Farbverläufe genauer dargestellt werden können als bei RGB565.
tokugawa
2007-02-03, 19:40:19
Wenn die Grafikkarte in 24 bzw. 32 Bit Farbtiefe läuft und
dank Texture Filtering sowieso zwischenwerte erzeugt werden?
Das DXT5 Format hat z.B. ohne Alpha Kanal für die jeweiligen Farbkanäle RGB nur R:5, G:6, B:5 Bit, also insgesamt 16 Bit.
Erst das R8G8B8 Format hat 24 bits pro Pixel, R:8, G:8, B:8, aber macht dieses Format für gewöhnliche Texturen (also keine Normalmaps und so Zeugs) überhaupt Sinn, wenn die Grafikkarte im 32 Bit Modus sowieso durch das Filtering Zwischenwerte erzeugt?
Der Unterschied dürfte dem Betrachter doch also kaum auffallen.
Also wenn überhaupt, dann sehe ich nur bei großen Texturauflösungen einen Sinn im R8G8B8 Format, weil bei großen Texturen die Wahrscheinlichkeit sinkt, daß der Betracher gefilterte Zwischenwerte zu Gesicht bekommt.
Sprich in Fällen wie: Die für das Polygon gerade dargestellte Pixelauflösung (oder Texel?) ist kleiner als die Auflösung der eigentlichen Textur.
Texturen werden außerdem nicht nur als "Bild" benutzt, sondern auch als großer Datenspeicher.
Sprich, die "Pixel" einer Textur sind nicht notwendigerweise sichtbare Daten, sondern möglicherweise komplett andere (Offset-Texturen, usw. für diverse Effekte).
Das trifft jedoch nicht mehr zu, sobald feine Farbverläufe ins Spiel kommen. Diese erscheinen bei 16-Bit-Texturen deutlich gestuft, und Dithering wäre in Vergrößerung offensichtlich.
Nein, nein, du hast mich glaube ich nicht ganz verstanden.
Ich dachte da an 3d Anwendungen.
Texturen werden dort in der Regel gefiltert, sprich weichgezeichnet, so daß es keine Klötzchen wie früher mehr gibt.
Es kann also vorkommen, daß zwischen einem echten Pixel der Textur mit der Farbe dunkles Rot und einem echten Pixel der Textur mit der Farbe helles Rot noch zwischenwerte dazukommen, also ein aufhellender Übergang in das immer heller werdende Rot.
D.h. letzten endes also, daß mehr Farben dargestellt werden, als die Textur selbst zu bieten hat.
Bei einem 32 Bit Rendermodus wohlgemerkt.
Dithering gibt es da nicht.
Das ganze kann man daher auch gar nicht mit der Betrachtung der Texturen in einem Bildbearbeitungsprogramm vergleichen, weil dort werden ja keine Zwischenwerte erzeugt.
Es werden allerdings pro 4x4-Pixelblock zwei Mischfarben mit 8 Bit pro Kanal erzeugt, so dass Farbverläufe genauer dargestellt werden können als bei RGB565.
Ja,genau das meinte ich die Mischfarben kommen durch den Billinearen Filter dazu, der den Klötzcheneffekt entfernt.
Texturen werden außerdem nicht nur als "Bild" benutzt, sondern auch als großer Datenspeicher.
Sprich, die "Pixel" einer Textur sind nicht notwendigerweise sichtbare Daten, sondern möglicherweise komplett andere (Offset-Texturen, usw. für diverse Effekte).
Lies mal bitte was ich geschrieben habe:
"(also keine Normalmaps und so Zeugs)"
Das geht auch weniger brüllig.
Tigerchen
2007-02-04, 07:00:26
Nein, nein, du hast mich glaube ich nicht ganz verstanden.
Ich dachte da an 3d Anwendungen.
Texturen werden dort in der Regel gefiltert, sprich weichgezeichnet, so daß es keine Klötzchen wie früher mehr gibt.
Es kann also vorkommen, daß zwischen einem echten Pixel der Textur mit der Farbe dunkles Rot und einem echten Pixel der Textur mit der Farbe helles Rot noch zwischenwerte dazukommen, also ein aufhellender Übergang in das immer heller werdende Rot.
D.h. letzten endes also, daß mehr Farben dargestellt werden, als die Textur selbst zu bieten hat.
Bei einem 32 Bit Rendermodus wohlgemerkt.
Dithering gibt es da nicht.
Das ganze kann man daher auch gar nicht mit der Betrachtung der Texturen in einem Bildbearbeitungsprogramm vergleichen, weil dort werden ja keine Zwischenwerte erzeugt.
Ja,genau das meinte ich die Mischfarben kommen durch den Billinearen Filter dazu, der den Klötzcheneffekt entfernt.
Weiß nicht ob das passt. Aber der Himmel in Quake 2 wird in 32 Bit Farbtiefe mit weichem Farbverlauf dargestellt. Mit 16 Bit sieht man die Farbübergänge sehr deutlich.
ja, es passt, genau darum geht es ja; je nach inhalt könnten auch 16bit ausreichen, der himmel ist (nicht nur in Quake) ein beispiel fü einen fall wo es definitiv nicht reicht; ausserdem wäre der aufwand zu groß die hunderten von texturen welche ein spiel verwendet alle zu analysieren ob sie sich vielleicht auf 16bit reduzieren liessen um so vielleicht etwas speicher zu sparen.
Nein, nein, du hast mich glaube ich nicht ganz verstanden.
Ich dachte da an 3d Anwendungen.
Texturen werden dort in der Regel gefiltert, sprich weichgezeichnet, so daß es keine Klötzchen wie früher mehr gibt.
Es kann also vorkommen, daß zwischen einem echten Pixel der Textur mit der Farbe dunkles Rot und einem echten Pixel der Textur mit der Farbe helles Rot noch zwischenwerte dazukommen, also ein aufhellender Übergang in das immer heller werdende Rot.
D.h. letzten endes also, daß mehr Farben dargestellt werden, als die Textur selbst zu bieten hat.
Bei einem 32 Bit Rendermodus wohlgemerkt.
Dithering gibt es da nicht.
Das ganze kann man daher auch gar nicht mit der Betrachtung der Texturen in einem Bildbearbeitungsprogramm vergleichen, weil dort werden ja keine Zwischenwerte erzeugt.
Ich habe dich keineswegs falsch verstanden. Es gibt auch Bildbetrachter die bilinear hochskalieren, z.B. die in Windows XP integrierte Bildvorschau. Die durch den Texturfilter erzeugten Zwischenwerte sind aber nur dann ausreichend, wenn die im Bild vorkommenden Farbverläufe nicht zu flach sind. Hast du beispielsweise einen Farbverlauf mit einer Steigung von 1/255 pro Texel, dann sieht das so aus:
8 Bit pro Kanal (* 1/255): 0 1 2 3 4 5 6 7 8 ...
5 Bit pro Kanal (* 1/31): 0 0 0 0 0 1 1 1 ...
Es ergibt sich also sichtbares Banding, das ein Texturfilter nur mit viel zu großem Filterkernel "wegrechnen" könnte. Die Zwischenwerte an der Stelle zwischen 0 und 1/31 sind nicht ausreichend, um den Farbverlauf zu rekonstruieren.
Die Unterschiede zwischen Truecolor-Original und auf 16 Bit heruntergerechnetem Bild werden durch Vergrößerung auffälliger. Daran ändert auch Texturfilterung nichts. Dithering wäre bei unvergrößerten Bildern ein brauchbares Mittel, räumliche Auflösung für Farbauflösung zu opfern, bei Texturen funktioniert es jedoch schlecht. Deswegen schrieb ich auch "wäre".
Ja,genau das meinte ich die Mischfarben kommen durch den Billinearen Filter dazu, der den Klötzcheneffekt entfernt.
Nein, ich meinte die Mischfarben die durch S3TC dazukommen. Pro 4x4-Block werden 2 Farben mit 16 Bit gespeichert. Zusätlich werden aber noch zwei weitere Farben generiert, die bei 1/3 und 2/3 zwischen den explizit gespeicherten Farben liegen. Diese Farben werden aber mit 8 Bit pro Kanal erzeugt (zumindest sollten sie es), womit die effektive Farbauflösung von S3TC-Texturen über der von 16-Bit-Texturen liegt.
ja, es passt, genau darum geht es ja; je nach inhalt könnten auch 16bit ausreichen, der himmel ist (nicht nur in Quake) ein beispiel fü einen fall wo es definitiv nicht reicht; ausserdem wäre der aufwand zu groß die hunderten von texturen welche ein spiel verwendet alle zu analysieren ob sie sich vielleicht auf 16bit reduzieren liessen um so vielleicht etwas speicher zu sparen.
Der größte Teil der Bildtexturen wird sowieso S3TC-komprimiert, da stellt sich die Frage nach 16 Bit gar nicht. Besonders aufwändig wäre es allerdings nicht, jede Textur nach dem Erstellen noch auf ihre 16-Bit-Tauglichkeit zu prüfen. Das ist eine Sache von Sekunden.
Weiß nicht ob das passt. Aber der Himmel in Quake 2 wird in 32 Bit Farbtiefe mit weichem Farbverlauf dargestellt. Mit 16 Bit sieht man die Farbübergänge sehr deutlich.
Nein, es paßt nicht.
Ich rede von 16 Bit Texturen die in 32 Bit Farbtiefe gerendert werden und dort werden sie durch die Glättung verschmirt, bekommen also eine zusätzliche Farbinformation in 32 Bit. Darum geht es.
Der Gat von Post #7 bin nicht ich, ich bin der Threadstarter,
Ich habe dich keineswegs falsch verstanden. Es gibt auch Bildbetrachter die bilinear hochskalieren, z.B. die in Windows XP integrierte Bildvorschau. Die durch den Texturfilter erzeugten Zwischenwerte sind aber nur dann ausreichend, wenn die im Bild vorkommenden Farbverläufe nicht zu flach sind. Hast du beispielsweise einen Farbverlauf mit einer Steigung von 1/255 pro Texel, dann sieht das so aus:
8 Bit pro Kanal (* 1/255): 0 1 2 3 4 5 6 7 8 ...
5 Bit pro Kanal (* 1/31): 0 0 0 0 0 1 1 1 ...
Es ergibt sich also sichtbares Banding, das ein Texturfilter nur mit viel zu großem Filterkernel "wegrechnen" könnte. Die Zwischenwerte an der Stelle zwischen 0 und 1/31 sind nicht ausreichend, um den Farbverlauf zu rekonstruieren.
Die Unterschiede zwischen Truecolor-Original und auf 16 Bit heruntergerechnetem Bild werden durch Vergrößerung auffälliger. Daran ändert auch Texturfilterung nichts. Dithering wäre bei unvergrößerten Bildern ein brauchbares Mittel, räumliche Auflösung für Farbauflösung zu opfern, bei Texturen funktioniert es jedoch schlecht. Deswegen schrieb ich auch "wäre".
Nein, ich meinte die Mischfarben die durch S3TC dazukommen. Pro 4x4-Block werden 2 Farben mit 16 Bit gespeichert. Zusätlich werden aber noch zwei weitere Farben generiert, die bei 1/3 und 2/3 zwischen den explizit gespeicherten Farben liegen. Diese Farben werden aber mit 8 Bit pro Kanal erzeugt (zumindest sollten sie es), womit die effektive Farbauflösung von S3TC-Texturen über der von 16-Bit-Texturen liegt.
OK, jetzt habe ich das verstanden wie du das in deinem letzten Posting gemeint hast.
Wenn die Grafikkarte in 24 bzw. 32 Bit Farbtiefe läuft und
dank Texture Filtering sowieso zwischenwerte erzeugt werden?stell dir einfach mal den Idealfall vor, daß eine Textur genau parallel zur Zeichenebene (also senkrecht zur z-Achse) steht, und gerade so weit entfernt ist, daß jeder Texel auf einem Bildschirmpixel zu liegen kommt. Dann nämlich findet gar keine Texturfilterung statt: bilinear nicht, weil keine Texel auf mehrere Bildschirmpixel vergrößert sind, Mipmapping nicht, weil nicht mehrere Texel auf einen Bildschirmpixel kommen, anisotrop nicht, weil die Textur nicht schräg gestellt ist.
Hat die Textur nun nur 16 Bit und weist dadurch ein sichtbares Colorbanding auf, kann dieses natürlich nicht durch Filterung geglättet werden, schließlich gibt es ja keins.
Jetzt wirst du natürlich eher selten eine solche Idealsituation antreffen, du kannst dir aber überlegen, daß in Abweichungen von dieser Idealsituation, in denen dann Filterung zum Einsatz kommt, nicht urplötzlich alles Colorbanding verschwinden wird.
Oder nehmen wir ein etwas praxisnäheres Beispiel: die Textur sei vergrößert und werde daher bilinear gefiltert. Nehmen wir an, die Textur enthaltene in ihrer Originalversion zwei Blautöne (es sei z.B. eine Himmelstextur), die sich aufgrund von 16 Bit sichtbar voneinander abheben. Dann gibt es in der Textur eine Region mit dem ersten Blauton und eine mit dem anderen Blauton, und eine scharfe Grenze die zwischen beiden verläuft. Durch die bilineare Filterung (in 32 Bit) wird diese Grenze dann zwar aufgeweicht, aber nur über eine Breite von einem Texel. Nimm an, die Textur habe die Größe 128*128 Texel, auf die beiden Regionen mit den unterschiedlichen Blautönnen entfallen jeweils 128*64 Texel. Die vergrößerte Textur nehme 512*512 Bildschirmpixel ein (4*4 Texel pro Bildschirmpixel). Dann ist der Übergang zwischen den Blautönen aufgrund des bilinearen Filters zwar 4 Bildschirmpixel breit, dem stehen aber zwei monochrome Regionen mit ~256 Bildschirmpixeln Breite gegenüber.
Man sieht demnach immer noch ein deutliches Colorbanding, da die Grenze zwischen den zwei Regionen noch deutlich erkennbar ist.
Eine 32 Bit Textur dagegen einen kontinuierlichen Farbverlauf ohne Colorbanding über die gesamte Textur hinweg erlauben.
Oder nehmen wir ein etwas praxisnäheres Beispiel: die Textur sei vergrößert und werde daher bilinear gefiltert. Nehmen wir an, die Textur enthaltene in ihrer Originalversion zwei Blautöne (es sei z.B. eine Himmelstextur), die sich aufgrund von 16 Bit sichtbar voneinander abheben. Dann gibt es in der Textur eine Region mit dem ersten Blauton und eine mit dem anderen Blauton, und eine scharfe Grenze die zwischen beiden verläuft. Durch die bilineare Filterung (in 32 Bit) wird diese Grenze dann zwar aufgeweicht, aber nur über eine Breite von einem Texel. Nimm an, die Textur habe die Größe 128*128 Texel, auf die beiden Regionen mit den unterschiedlichen Blautönnen entfallen jeweils 128*64 Texel. Die vergrößerte Textur nehme 512*512 Bildschirmpixel ein (4*4 Texel pro Bildschirmpixel). Dann ist der Übergang zwischen den Blautönen aufgrund des bilinearen Filters zwar 4 Bildschirmpixel breit, dem stehen aber zwei monochrome Regionen mit ~256 Bildschirmpixeln Breite gegenüber.
Man sieht demnach immer noch ein deutliches Colorbanding, da die Grenze zwischen den zwei Regionen noch deutlich erkennbar ist.
Eine 32 Bit Textur dagegen einen kontinuierlichen Farbverlauf ohne Colorbanding über die gesamte Textur hinweg erlauben.
Also das Beispiel mit den Blauen Bildpunkten hat aber einen Denkfehler.
Da auch bei 16 Bit eine Himmelstextur mehr Abstufungen hat.
Mr. Lolman
2007-05-24, 09:29:55
Das DXT5 Format hat z.B. ohne Alpha Kanal für die jeweiligen Farbkanäle RGB nur R:5, G:6, B:5 Bit, also insgesamt 16 Bit
DXT-Formate sind komprimiert. Da bringt man in 16bit mehr Farben unter, als in einer unkomprimierten 16bit Textur (wie sie zB der Himmel in Quake2 ist) So gesehen, ist ne höhere Texturauflösung praktischer als ein unkomprimiertes 32bit Format.
Hier ein kleines Proggi was das verdeutlicht: http://www.humus.ca/index.php?page=3D&ID=68
Hier ein kleines Proggi was das verdeutlicht: http://www.humus.ca/index.php?page=3D&ID=68
hier fällt auf dass es überhaupt nur bei starker vergrößerung unterschiede gibt, ansonsten ist mit freiem auge kein unterschied zwischen den einzelnen modi zu erkennen.
Mr. Lolman
2007-05-24, 12:50:00
hier fällt auf dass es überhaupt nur bei starker vergrößerung unterschiede gibt, ansonsten ist mit freiem auge kein unterschied zwischen den einzelnen modi zu erkennen.
Naja, normales DXT erkennt man schon. Aber men merkt auch, dass es deutlich besser ist als ne unkomprimierte 16bit (RGB565) Textur - die wohl eh niemand mehr einsetzt. Und selbst zu der Zeit, wo TC noch in den Kinderschuehen steckte, wars weitaus intelligenter Texturen mit ner 8bit Palatte zu verwenden. Dadurch, dass diese sich meistens auf 256² Pixel beschränkten war die Farbtiefe der jew. 8bit Palette abslout ausreichend und quasi auch immer besser als die einer 256² RGB565 Textur.
Also das Beispiel mit den Blauen Bildpunkten hat aber einen Denkfehler.
Da auch bei 16 Bit eine Himmelstextur mehr Abstufungen hat.kommt ganz auf die Textur an, man kann eine Himmelstextur auch so designen, daß sie in 16 Bit nur zwei Blautöne enthält. Diese seien so dicht beisammen wie es in 16 Bit nur irgend geht, z.B. in RGB565 (0,0,30) und (0,0,31). Da 5 Bit für Blautöne unterhalb der Farbauflösung des Auges liegen, sieht man zwischen beiden Tönen ein Colorbanding.
Das ganze ändert sich auch nur unwesentlich, wenn man mehr als 2 Blautöne hat: entscheidend ist lediglich, daß jeweils zwei benachbarte Töne sichtbar voneinander zu unterscheiden sind und daher Colorbanding auftritt. Bei z.B. 5 Blautönen hat man dann eben 4 Bänder statt nur einem.
Avalox/Gast
2007-05-25, 20:21:44
wars weitaus intelligenter Texturen mit ner 8bit Palatte zu verwenden.
Hat dann die Grafikkarte tatsächlich mit den 262144 VGA Farben der 8Bit Palette gearbeitet, oder intern wieder auf 16Bit reduziert?
Nein, es paßt nicht.
Ich rede von 16 Bit Texturen die in 32 Bit Farbtiefe gerendert werden und dort werden sie durch die Glättung verschmirt, bekommen also eine zusätzliche Farbinformation in 32 Bit. Darum geht es.
Der Gat von Post #7 bin nicht ich, ich bin der Threadstarter,
Die zusätzlichen Farbinformationen sind aber interpoliert, entsprechen
also nur "geratenen" Zwischenwerten. Das visuell nicht immer ein Unterschied
zu einer echten hochaufgelösten Textur besteht, ist klar, und liegt u.a.
an dem Kontrast usw. der verwendeten Textur.
Liszca
2007-05-26, 02:54:30
Texturen werden außerdem nicht nur als "Bild" benutzt, sondern auch als großer Datenspeicher.
Sprich, die "Pixel" einer Textur sind nicht notwendigerweise sichtbare Daten, sondern möglicherweise komplett andere (Offset-Texturen, usw. für diverse Effekte).
du meinst doch nun sicherlich texturen mit inhalten wie einer "explosion", sowas meine ich schonmal in eine editor zu half-life gesehen zu haben.
wenn ja, wird wowas in zeiten von pixelshader & co. noch immer benötigt?
du meinst doch nun sicherlich texturen mit inhalten wie einer "explosion", sowas meine ich schonmal in eine editor zu half-life gesehen zu haben.
das weniger, das bekannteste beispiel düften wohl normalmaps sein, die statt farbinformationen informationen der oberflächennormalen beinhalten, das ganze kann dann für parallaxmapping noch mit einer highmap kombiniert werden (entweder als extra textur oder im 4. kanal der normalmap)
ansonsten werden auch noch lookup-tables für shader verwendet.
eine textur ist lediglich ein array im speicher, welches irgendwelche zahlenwerte beinhaltet, die alles mögliche repräsentieren können, diese können beispielsweise für einen farbwert stehen oder auch für alles mögliche.
Aquaschaf
2007-05-26, 15:14:44
wird wowas in zeiten von pixelshader & co. noch immer benötigt?
Mehr als je zuvor.
Hat dann die Grafikkarte tatsächlich mit den 262144 VGA Farben der 8Bit Palette gearbeitet, oder intern wieder auf 16Bit reduziert?
Die Breite der Paletteneinträge kommt auf die Hardware an. Ältere Voodoos boten RGB-Paletteneinträge mit 8 bit pro Kanal, neuere zusätzlich einen RGBA-Modus mit 6 Bit pro Kanal (der dann, abgesehen von Alpha, den VGA-Möglichkeiten entsprechen würde). Bei anderer Hardware mit echter Palettenunterstützung ist möglicherweise RGBA8888 üblich. Dann wird natürlich auch mit (mindestens) dieser Breite gefiltert, ansonsten könnte man gleich die Paletteneinträge schmaler machen.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.