Transparenz und Alpha Channel

[GloomY]

Ich hab' mir mal ein paar Gedanken gemacht, was dieses Thema angeht. Und zwar bin ich da auf 2 Sachen gestoßen:

Zum einen betrifft das den neuen Framebuffer-Modus des Parhelia (RGBA 10-10-10-2). Man hat nun zwar 10 Bit pro Farbe, aber nur noch 2 für den Alpha Kanal. Das heisst man kann nur noch 2 hoch 2 = 4 Transparenzeinstellungen wählen (im Gegensatz zu 256 bei RGBA 8-8-8-8).
Damit sind die Möglichkeiten bei Transparenz beim Parhelia auf
i) komplett undurchsichtig
ii) 25% durchsichtig
iii) 50% durchsichtig und
iv) 75% durchsichtig

beschränkt (100% durchsichtig ergibt ja keinen Sinn, dann kann man den Farbwert ja grad' verwerfen).

Die erhöhte Farbgenauigkeit bei den RGB-Kanälen ist ja eine gute Sache, aber wenn ich mich an den Artikel von 3dconcept.ch (http://www.3dconcept.ch/cgi-bin/showarchiv.cgi?show=1861) erinnere, wie viel produktiver Overdraw (=Transparenzeffekte) in den heutigen Spielen vorkommen, dann stellt sich für mich folgende Frage:

Wirkt sich die Limitierung von 256 Transparenzstufen auf mickrige 4 insgesamt nicht als Qualitätsverlust aus (man denke an sehr viel mehr transparente Dreiecke übereinander)? ???

Denn der Gewinn, den man durch die Erweiterung der RGB-Kanäle von 8 auf 10 Bit erreicht hat, kommt ja nur bei großer Anzahl an Blending-Operationen überhaupt zu stande, bei denen dann (mit großer Wahrscheinlichkeit) wieder transparete Dreiecke dabei sind, die die Genauigkeit und damit die Qualität wieder reduzieren...


Nun meine zweite Frage:
Durch die obige Überlegung kam ich dazu, mir den grundsätzlichen Sinn des Alpha-Kanals im Framebuffer klar zu machen.
Dieser wird benötigt, um die (Licht-)Durchlässigkeit eines Pixels zu beschreiben.
Eigentlich wäre es ja einfacher, sofort den Farbwert des Pixels mit dem dahinterliegenden zu blenden und diesen dann in den Framebuffer zu schreiben. Dann könnte man sich den Alpha-Kanal sparen.
Aber die beiden Pixel gehören nunmal zu unterschiedlichen Dreiecken. Somit ist der Farbwert des dahinter liegenden Pixels eventuell noch gar nicht berechnet. Deshalb braucht man eben den Alpha Kanal, um später (wenn der dahinterliegende Farbwert vorhanden ist) diese Blend-Operation ausführen zu können.

Jetzt meine Überlegung: Wie sieht es bei einem TBR mit HSR aus, der sowieso nur das in den Framebuffer schreibt, was letztendlich sichtbar ist?
Ein Alpha-Kanal ergibt nach meinen Überlegungen überhaupt gar keinen Sinn, denn an den Farbwerten wird ja nichts mehr verändert und der RAMDAc braucht ja sowieso nur die RGB-Werte für den Monitor.

Imho könnte man da doch den Alpha-Kanal komplett einsparen und somit
i) den Platzbedarf des Framebuffer um 25% reduzieren und
ii) die Speicherbandbreite zum Framebuffer schreiben ebenfalls um genau diese Wert reduzieren (was ja viel wichtiger ist).

Ich hoffe, ich habe nirgendwo einen Denkfehler drin, wenn ja, dann bitte ich um Korrektur...

[Demirug]

Zu deiner ersten Frage:

Die Reduzierung des Alphakanals im Framebuffer ist in der Regel kein Problem da beim Alphablending normalerweise der Kanal der Textur benutzt wird. Dieser ist weiterhin 8 bit gross.

Frage 2:

Es gibt zwei Gründe warum das direkte Blenden meistens nicht machbar ist.

- Die zur verfügung stehenden Texturen reichen einfach nicht.
- Wenn man das Object welches später z.B. durch ein Fenster betrachtet wird rendert weis man im Regelfall nicht welche Teile (wenn überhaupt) des Objects durch das Fenster zu sehen sind. Das ganze zu bestimmen wäre vom Aufwand her mit raytracing zu vergleichen. Und wenn ich die Power zur verfügung hätte würde ich gleich raytracen und nicht mehr rendern.

Was das TBR angeht so werden auch dort beide pixel (der untere und der Blendpixel) berechnet. Das ganze läuft fast genauso ab wie beim IMR mit dem unterschied das eben nicht im Framebuffer zwichengespeichert wird.

Was deine Speicherbandbreite angeht hast du im Prinzip recht. Es gibt dabei nur folgendes zu bedenken. Der Alphakanal des Framebuffers wird manchmal als zusätzlicher Stencilbuffer missbraucht. 24 bzw 30 bit Werte liegen für einen schnellen Zugriff eher ungünstig im Speicher.

[GloomY]

Originally posted by Demirug
Die Reduzierung des Alphakanals im Framebuffer ist in der Regel kein Problem da beim Alphablending normalerweise der Kanal der Textur benutzt wird. Dieser ist weiterhin 8 bit gross.Wie sieht das bei mehreren verwendeten Texturen aus?
Könnte man dann nicht ganz auf den Alpha-Kanal im Framebuffer verzichten und immer auf den der Texturen zurückgreifen?
Originally posted by Demirug
Was das TBR angeht so werden auch dort beide pixel (der untere und der Blendpixel) berechnet. Das ganze läuft fast genauso ab wie beim IMR mit dem unterschied das eben nicht im Framebuffer zwichengespeichert wird.Das war mir klar. ;)
Originally posted by Demirug
Was deine Speicherbandbreite angeht hast du im Prinzip recht. Es gibt dabei nur folgendes zu bedenken. Der Alphakanal des Framebuffers wird manchmal als zusätzlicher Stencilbuffer missbraucht.Reicht der normale Stencil-Buffer denn nicht aus? 8 Bit, d.h. 256 verschiedene Zustände könnnen pro Pixel gespeichert werden. Wenn das für die paar Effekte nicht ausreicht... ???
Originally posted by Demirug
24 bzw 30 bit Werte liegen für einen schnellen Zugriff eher ungünstig im Speicher.Das stimmt natürlich...

[Demirug]

Originally posted by GloomY
Wie sieht das bei mehreren verwendeten Texturen aus?
Könnte man dann nicht ganz auf den Alpha-Kanal im Framebuffer verzichten und immer auf den der Texturen zurückgreifen?


Im Prinzip schon nur was macht man dann mit den überflüssigen bits?


Reicht der normale Stencil-Buffer denn nicht aus? 8 Bit, d.h. 256 verschiedene Zustände könnnen pro Pixel gespeichert werden. Wenn das für die paar Effekte nicht ausreicht... ???

Stencil buffers werden normalerweise Bitsweise benutz. Also 8 Effekte. Das mit den Alphawerten als Stencilersatz stamt noch aus der Zeit als es keine Hardware Stencils gab. Und ein paar Engines können das anscheined immer noch.

[zeckensack]

Der Alphakanal im Framebuffer kommt (wenn man ihn nicht für anderes 'mißbraucht') nur für 'Destination Alpha' zum Einsatz. Damit kann man ein paar Spezialeffekte machen, es wird aber AFAIK von keiner aktuellen Engine überhaupt genutzt.(Demirug und vogel: bitte motzen, wenn's falsch ist ;) )

Die wichtigen Alphawerte sind die, die aus den Texturkanälen oder Combinern kommen, diese werden aber idR nach dem Blending verworfen, sodaß es nicht tragisch ist, wenn der Alphakanal im Framebuffer eng ist ...
... aaaber im Grunde ist es ein Rückschritt, bzw nichts, was man nicht auch früher schon hätte machen können.
Ich kenne nur die OpenGL-Perspektive, könnte mir aber vorstellen, daß DX hier ähnlich funktioniert:
Eine Applikation/ein Spiel gibt beim Öffnen des Fensterchens an, ob sie einen Alpha-Kanal im Framebuffer haben will.
Fall 1)Wenn sie ihn nicht braucht, dann kann der Treiber von mir aus gerne dafür die Farbauflösung erhöhen. Das hätte man wirklich schon früher einführen können.
Fall 2)Wird er aber doch angefordert, so ist davon auszugehen, daß er auch genutzt wird (für was auch immer ...). 2 bit sind dann völlig inakzeptabel. Dann sollte er IMHO schon die gleiche Auflösung wie die Farbkanäle haben.

Ich halte also nicht viel von dieser Lösung. Entweder 10-10-10-0, oder 8-8-8-8, das wären die Optionen, die der Treiber bieten sollte. Besser wäre natürlich, gleich auf 16 bit pro Komponente zu gehen, oder von mir aus 'halbwegs' alignment-freundliche Formate wie 12-12-12-12 oder 16-16-16-0 (beide 48bit) anzubieten. Für beides sollte der Parhelia doch wohl ausreichend Bandbreite haben.

Die jetztige Lösung halte ich für sinnloses Säbelrasseln, zumal wir uns garnicht mal sicher sein können, ob er nicht schon längst von anderen Chips genutzt wird.

Schließlich war Matrox bisher die einzige Chipschmiede, die überhaupt echtes 24-bit-Rendering angeboten hat, alle anderen haben seit Jahr und Tag Truecolor-Formate direkt auf 32 bit 'aufgeblasen', zwecks besserem Alignment.

[Demirug]

Originally posted by zeckensack
(Demirug und vogel: bitte motzen, wenn's falsch ist ;) )


Also von meiner seite aus past das.

Ich kenne nur die OpenGL-Perspektive, könnte mir aber vorstellen, daß DX hier ähnlich funktioniert:
Eine Applikation/ein Spiel gibt beim Öffnen des Fensterchens an, ob sie einen Alpha-Kanal im Framebuffer haben will.
Fall 1)Wenn sie ihn nicht braucht, dann kann der Treiber von mir aus gerne dafür die Farbauflösung erhöhen. Das hätte man wirklich schon früher einführen können.
Fall 2)Wird er aber doch angefordert, so ist davon auszugehen, daß er auch genutzt wird (für was auch immer ...). 2 bit sind dann völlig inakzeptabel. Dann sollte er IMHO schon die gleiche Auflösung wie die Farbkanäle haben.


Ist ähnlich. Man enumiert die verfügbaren Modis durch und nimmt den der am besten past.

Ich halte also nicht viel von dieser Lösung. Entweder 10-10-10-0, oder 8-8-8-8, das wären die Optionen, die der Treiber bieten sollte. Besser wäre natürlich, gleich auf 16 bit pro Komponente zu gehen, oder von mir aus 'halbwegs' alignment-freundliche Formate wie 12-12-12-12 oder 16-16-16-0 (beide 48bit) anzubieten. Für beides sollte der Parhelia doch wohl ausreichend Bandbreite haben.

Die jetztige Lösung halte ich für sinnloses Säbelrasseln, zumal wir uns garnicht mal sicher sein können, ob er nicht schon längst von anderen Chips genutzt wird.

Schließlich war Matrox bisher die einzige Chipschmiede, die überhaupt echtes 24-bit-Rendering angeboten hat, alle anderen haben seit Jahr und Tag Truecolor-Formate direkt auf 32 bit 'aufgeblasen', zwecks besserem Alignment.

Ist schon was dran. aber 48 bit vertragen sich leider auch nicht so gut mit den derzeitigen Memoryinterfaces.

[zeckensack]

Originally posted by Demirug
Ist schon was dran. aber 48 bit vertragen sich leider auch nicht so gut mit den derzeitigen Memoryinterfaces. Solange die Speicherinterfaces mit 16-bit-Modi halbwegs zurechtkommen, sollten 48bit auch noch irgendwie gehen ;)

[aths]

zeckensack,

wieso 10-10-10-0 und nicht lieber 10-12-10-0? (Bringt beides natürich nur was, wenn intern überhaupt mit so vielen Stellen gerechnet wird. Afaik hapert es hier schon, zumindest bei GeForce-Karten.)

[zeckensack]

Originally posted by aths
zeckensack,

wieso 10-10-10-0 und nicht lieber 10-12-10-0? (Bringt beides natürich nur was, wenn intern überhaupt mit so vielen Stellen gerechnet wird. Afaik hapert es hier schon, zumindest bei GeForce-Karten.) Erstmal vorweg, natürlich muß der Chip mindestens die Genauigkeit der externen 'Ablage' unterstützen.

10-12-10 klingt irgendwie logisch, 11-12-9 entspräche sogar noch besser der menschlichen Wahrnehmung.
Leider hat die ungleiche Auflösung der Farbkanäle gerade da, wo hohe Farbauflösung Sinn macht (exzessives Alphablending mit vielen Passes) ihre Nachteile.

Ich kann hier nur meine Erfahrungen wiedergeben, zB sieht ein einfacher Graukeil (RGB888-Rohmaterial) mit RGB565 scheußlich aus, mit RGB555 deutlich besser. Zwar ist in letzterem Fall (wie zu erwarten) das Banding stärker, jedoch ist das Verfälschen der Farben durch unterschiedliche Kanalauflösung eben noch schlimmer.

Ich bau' dir mal ein Screenie, Moment bitte ...

[zeckensack]

So, mal wieder vier Farbreihen

Das hier ist eine Software-Lösung, quasi eine 256x16-Textur als Graukeil. Das Original hat selbstredend die vollen 256 Helligkeitsabstufungen, ist hier aber nicht dargestellt.

Alle Regeln der Kunst wurden berücksichtigt, korrekte Farbraumexpansion durch Replikation von MSBs usw, so wie es echte Grafikchips auch machen. Btw hatte ich einen ähnlichen Effekt auch schon mit HW-beschleunigtem OpenGL beobachtet.

Von oben nach unten:
1)Graukeil auf RGB555 runtergerechnet
2)Blending. Der Graukeil 'von links nach rechts' wurde mit dem Graukeil 'von rechts nach links' mulitpliziert und (vor dem zurückrechnen nach RGB555) mit Faktor vier skaliert, um den vollen Helligkeitsbereich nutzen zu können
3)Wie 1, nur diesmal mit RGB565
4)Wie 2, nur wieder mit RGB565

PS: Das hier ist 'beinahe' Lossless JPEG, weniger als 1 (von 100) kann ich in Paint Shop nicht als Kompressionsfaktor einstellen ;)

PPS: bitte auch gezoomt betrachten, IMO echt scheußlich ;)

[Xmas]

4) hat nen Grünstich, aber 3) find ich besser als 1)

[GloomY]

Dem stimme ich zu, wenn man (3) nicht vergrößert. Dann sieht man den Grünstich nämlich auch deutlich.

edit: Wie groß ist denn der Unterschied von ungünstigem und optimalem Aligment der Daten im Speicher?

[zeckensack]

Originally posted by Xmas
4) hat nen Grünstich, aber 3) find ich besser als 1) Genau!
#3 ist ganz ordentlich, erst durch Blending wird's schlimm. Die Nummer 4 ist jetzt quasi 'zwei Passes', je mehr ich mache, desto übler wird die Farbverfälschung durch unterschiedliche Kanalauflösung. Und diese Blending-Monstrositäten sind doch der Grund, warum man überhaupt höhere Framebuffer-Farbtiefen braucht.

[ow]

Ich vermute, das dies auch fuer die starke Gruenverfaerbung der RL Trails in Q3 verantwortlich ist, die praktisch alle Karten unter 16Bit dort zeigen.

Am schlimmsten ist der Intel i740. Der Rauch ist dort am Ende des mehrfach Blendings komplett gruen.

Aber auch TNT und Benshee zeigen recht starke Gruenverfaerbung.
Nur mein Permedia2 nicht, weil der nur 5551 rendert (15Bit Farbe).

[harrypitt]

Der Alphakanal im Framebuffer kommt (wenn man ihn nicht für anderes 'mißbraucht') nur für 'Destination Alpha' zum Einsatz. Damit kann man ein paar Spezialeffekte machen, es wird aber AFAIK von keiner aktuellen Engine überhaupt genutzt.

Drei Jahre später stellt sich mir die Frage, ob eine aktuelle Engine den Alphakanal des Framebuffers verwendet. Interessant wäre diese Frage vor allem im Zusammenhang mit HDR - Rendering. Wenn der Alphakanal noch immer nicht verwendet wird warum wird er dann noch mit abgespeichert?

Ein Floatingpoint Framebuffer ohne Alpha (16-16-16 / R-G-B) verbraucht "nur" um die Hälfte mehr Speicherplatz als ein normaler 8-8-8-8 (R-G-B-A) Framebuffer. Sollte das Memoryinterface ineffizient mit 48 bit pro Pixel arbeiten, könnte man auch folgendes machen: Ein Floatingpoint Framebuffer der so ausschaut: 21-21-21-1 / R-G-B-Rest. Das würde zwar nichts am Speicherverbrauch ändern, aber die Farbkanäle sind viel besser aufgelöst bzw. haben mehr Dynamikumfang.

Für den wahrscheinlichen Fall, dass ich hier nur technologischen Blödsinn schreibe: Tut mir leid, bin kein Experte, aber interessieren tut mich das ganze trotzdem...

[Coda]

Also von meiner seite aus past das.Hast du nicht mal gemeint, dass Splinter Cell Destination Alpha verwendet?

Außerdem:
The 10 bit color framebuffer is nice, but Doom needs more than 2 bits of destination alpha when a card only has four texture units, so we can't use it.

[Xmas]

Letzteres bezog sich dann ja nur auf Parhelia.

[Coda]

Ja, aber wenn man Multipass machen muss (egal aus welchem Grund) ist Destination Alpha sicher nicht unnütz.

[harrypitt]

Ja, aber wenn man Multipass machen muss (egal aus welchem Grund) ist Destination Alpha sicher nicht unnütz.

Das heißt also, Destination Alpha im Framebuffer ist vor allem für Multipass Rendering da?
Ist Multipass bei SM3 Grafikchips überhaupt noch notwendig?

Meines Wissens kann jede SM2 Grafikkarte Doom3 in Singlepass rendern, eventuell kann das ATI R2x0 auch (8 Texturen pro Pass).

[Coda]

Ja auch mit SM3 kann das passieren wenn Register, Interpolatoren, etc. ausgehen.

[Demirug]

Hast du nicht mal gemeint, dass Splinter Cell Destination Alpha verwendet?

Im SM1.1 Pfad auf jeden Fall. Aber hast du mal auf das Datum von meiem Post geschaut?

[aths]

Das heißt also, Destination Alpha im Framebuffer ist vor allem für Multipass Rendering da?
Ist Multipass bei SM3 Grafikchips überhaupt noch notwendig?

Meines Wissens kann jede SM2 Grafikkarte Doom3 in Singlepass rendern, eventuell kann das ATI R2x0 auch (8 Texturen pro Pass).R200 kann 6 unterschiedliche Texturen pro Pass nutzen, aber jede Textur bis zu 2x sampeln. Mit SM2.0 kann man 16 unterschiedliche Texturen pro Pass nutzen, und insgesamt 32x Texturen sampeln.


Drei Jahre später stellt sich mir die Frage, ob eine aktuelle Engine den Alphakanal des Framebuffers verwendet. Interessant wäre diese Frage vor allem im Zusammenhang mit HDR - Rendering. Wenn der Alphakanal noch immer nicht verwendet wird warum wird er dann noch mit abgespeichert?

Ein Floatingpoint Framebuffer ohne Alpha (16-16-16 / R-G-B) verbraucht "nur" um die Hälfte mehr Speicherplatz als ein normaler 8-8-8-8 (R-G-B-A) Framebuffer. Sollte das Memoryinterface ineffizient mit 48 bit pro Pixel arbeiten, könnte man auch folgendes machen: Ein Floatingpoint Framebuffer der so ausschaut: 21-21-21-1 / R-G-B-Rest. Das würde zwar nichts am Speicherverbrauch ändern, aber die Farbkanäle sind viel besser aufgelöst bzw. haben mehr Dynamikumfang.Man bräuchte mehr Logikgatter für FP21-Alphatests. FP16 ist als Format auf absehbare Zeit "gut genug", weshalb man sich breitere Formate derzeit noch klemmt. Wenn FP16 bei einer größeren Anzahl an denkbaren Applikationen nicht mehr reicht, ist es wenig wahrscheinlich, dass FP20 oder FP21 wieder auf Jahre genügend Luft nach oben böte, dann würde man wohl gleich FP32 nutzen.

Was ATI bietet, nämlich RGB 10-10-10-2, seit R520 auch mit Multisampling, das hätte allerdings viel früher kommen können. Für HDR-Rendering reichts nicht, auch nicht für MDR-Rendering – aber man könnte Quake3 oder Max Payne mit deutlich reduziertem Colorbanding spielen.

[harrypitt]

R200 kann 6 unterschiedliche Texturen pro Pass nutzen, aber jede Textur bis zu 2x sampeln. Mit SM2.0 kann man 16 unterschiedliche Texturen pro Pass nutzen, und insgesamt 32x Texturen sampeln.


Ja du hast recht, R2x0 kann 6 Texturen pro Pass nutzen... Hab mich um eine Zeile geirrt, sorry:
http://www.3dcenter.org/artikel/2002/01-04_b.php

Danke für die Info über die (zukünftigen) FP-Formate.

[StefanV]

Was ATI bietet, nämlich RGB 10-10-10-2,
Öhm, aths, das kam viel früher, sprich Parhelia, obs meine WIldkatze kann, keine Ahnung, auf der Packung wird aber mit 10bit RAMDACs geworben :|