Thread verschwunden (Reste aus "Anti-Aliasing 4xS vs 4xRG")

[zeckensack]

Keine Ahnung, wo er ist, der allseits beliebte Thread "Anti-Aliasing 4xS vs 4xRG" (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=75003). Lasst uns eine Schweigeminute einlegen :(

Hier noch die letzte Antwort für Manni, die ich zum Zeitpunkt des Desasters in der Pipeline hatte:
_______________________________________________
Original geschrieben von MadManniMan
aber so wie ich mir das vorstelle, ist das nur für die transparenten pixel und auch nur für die transparente textur notwendig.

das raycasting verhält sich meines wissens genau wie ohne alpha blending, nur wird eben beim auftreffen auf eine alphatextur nicht "HALT! hier letztes renderding, du arbeit jetzt schluß!" geschrien, sondern die relevanten werte "zwischengespeichert", der "strahl" fliegt dann weiter Nö :D

Schau dir die Blending-Funktion nochmal an (habe ich oben 'menschenlesbar' schonmal geschrieben):

Pixel #1:
Neu=(1-a1)*alt+a1*frisch1

Pixel #2:
Neu=(1-a2)*alt+a2*frisch2

Hauchen wir dem ganzen mal leben ein:

alt:= 20 (stehe im Framebuffer, bevor die beiden Pixel reingeblendet werden)

#1:
neu=(0.5)*alt+0.5*10

#2:
neu=(0.5)*alt+0.5*15


Und jetzt ausrechn0rn:
#1: neu=10+5=15
#2: neu=7.5+7.5=15

Jetzt vertauschemer die Reihenfolge:
#2: neu=10+7.5=17.5
#1: neu=8.75+5=13.75

Da ist mit 'von vorne nach hinten raycasten' nichts mehr zu machen, das muß schon in der Reihenfolge durchgerechnet werden, in der die Dreiecke in die API gestopft wurden :)


Ganz davon ab, könnte es natürlich auch sein, daß Z-Test und Z-Write aktiv sind, dann würde 'von vorne nach hinten' die erste Transparenz die zweite überdecken (deren Berechnung verhindern), umgekehrt nicht. Das ist in den meisten Fällen ein Applikationsfehler (nicht umsonst gilt 'order independant transparency' immer noch als Forschungsgebiet), aber es ist eben das vorgeschriebene Verhalten der API ;)

[Quasar]

Ist es nicht dieser (http://www.forum-3dcenter.net/vbulletin/showthread.php?s=&threadid=76309) hier?

[zeckensack]

Original geschrieben von Quasar
Ist es nicht dieser (http://www.forum-3dcenter.net/vbulletin/showthread.php?s=&threadid=76309) hier? Nein ?-)

[zeckensack]

*vorübergehend closed*

Ich habe noch die zwanzig letzten Beiträge in meinem Antwort-Fenster. Werd' ich mal hier reinschmieren ...

[zeckensack]

Demirug:

Original geschrieben von MadManniMan
hm, ist es eigentlich ohne weiteres machbar, einen solchen zaun zuerst per geometrie zu modelln, bei weiterer entfernung aber auf simplen alphatest setzt?

(ich weiß, daß das so ziemlich das unsinnigste ist, was man praktisch machen kann, da der effekt wohl scheiße aussähe. es geht hier nur um die machbarkeit)

btw: warm läßt man nicht einfach den unsäglichen alphatest weg und arbeitet mit alphablending???

Klar kann man das machen und so unsinnig ist das gar nicht mal. Man muss nur aufpassen das es keinen Popup Effekt gibt. Der Vorteil des Alphatest neben der Bandbreiteneinsparung ist das es dabei keine Probleme mit der Renderrheienfolge gibt. Beim Alphablending muss man da immer aufpassen.

[zeckensack]

aths:

Original geschrieben von Exxtreme
Wieso unkluges Design? Nur weil MSAA hier nicht wirkt? Als Gothic1 geproggt wurde, war weder SSAA oder MSAA ein Thema. Man hat einfach die Lösung genommen, die weniger Leistung frisst. Ausserdem war damals die Bandbreite noch ein Problem.

So alte Spiele sind hoffentlich schon so "schnell", dass man da mit SSAA was machen kann.

Original geschrieben von Exxtreme
Siehe rams Posting. Man könnte Kompression auch bei SSAA machen. Und Z-Compression funktioniert wohl unabhängig vom AA-Modus.
Könnte man, der Wirkungsgrad sinkt natürlich und die Logik würde aufwändiger. Das Problem der Füllraten-Anforderung ist damit aber nicht aus der Welt. Z-Compression geht auch ganz ohne AA, <Oberlehrer mit Nickelbrille> aber wie Leser des MSAA-Artikels wissen </Oberlehrer mit Nickelbrille> nützt es vor allem mit MSAA was.
Original geschrieben von Exxtreme
Genau. Man müsste jetzt alle Spiele, die jemals MSAA-inkompatible Techniken nutzten, patchen. Das ist leider nicht realisierbar. Du forderst ganz einfach, daß der Berg zum Propheten kommt. ;)
Nö, ich fordere ein Paradigmenwechsel im Spiel-Design, damit zukünftige Spiele auf zukünftiger HW sich mit den BQ-Maßnahmen wirklich aufpolieren lassen ohne dass es Nachteile gibt.
Original geschrieben von Exxtreme
Ich glaube, Leistung wird in naher Zukunft kein Problem mehr sein. Wie gesagt, die meisten Spiele liessen sich wohl doch auf jetzigen High- End-Karten mit SSAA ohne Probleme spielen. UT2003 und U2 lasse ich mal aussen vor.
Ohne Probleme? High-End-Karten haben einerseits nur die wenigsten Leute, andererseits wüsse ich gerne wo heute auch auf High-End-Karten mehr als 4xS wirklich eingesetzt wird (von einigen Ausnahmen abgesehen.)

Gestern habe ich mir eine 5900U gewünscht, um Max Payne zu spielen. (Für 1400x1050, 2xAA, 8x AF, denn ich spiele im Moment nur in 1024x768.) Mit der Highendigsten HighEnd-Karte könnte ich gerade mal ein inzwischen ziemlich altes Spiel "quasi perfekt" spielen. Dabei steht Supersampling hier gar nicht auf der Wunschliste...

[zeckensack]

Demirug:
Original geschrieben von aths
Geometrisches LOD Ab einer bestimmten Entfernung (auflösungsabhängig) wird der Zaun durch ein Objekt ersetzt mit Alpha Blending Das müsste man natürlich, damit da nichts "zuckt" beim Übergang, gut abpassen, oder sogar (sehr aufwändig) die Objekte ineinander überblenden.
Nur irgendwann gibt es da nichts mehr sinnvoll mit LOD zu entfernen. Und warum Alphablending da auch nicht der letzte schrei ist habe ich ja schon oben aufgeführt. Zudem führt bei sowas Alphablendig-AA zu Blur.

Supersampling zieht extrem an der Füllrate (und damit auch an der Bandbreite.)
Ja nur muss man das in Relation setzten. Mit einer zu feinen Geometrie die kaum noch Pixelabdeckung hat geht dir auch Füllrate ohne Ende verloren.

[zeckensack]

aths:

Original geschrieben von Demirug
Ja nur muss man das in Relation setzten. Mit einer zu feinen Geometrie die kaum noch Pixelabdeckung hat geht dir auch Füllrate ohne Ende verloren.

Deswegen schlug ich geometrisches LOD vor :) Abgesehen davon bin ich prinzipiell gegen engmaschige Maschendrahtzäune, weil sowas immer anfällig für Moirè ist. Bei Max Payne gibt es Alphablending-Maschendrahtzäune, die (zumindest in der inzwischen etwas angestaubten Grafik) ganz gut aussehen, finde ich.

[zeckensack]

MadManniMan:
Original geschrieben von Demirug
Nur irgendwann gibt es da nichts mehr sinnvoll mit LOD zu entfernen. Und warum Alphablending da auch nicht der letzte schrei ist habe ich ja schon oben aufgeführt. Zudem führt bei sowas Alphablendig-AA zu Blur.

der effekt ist trotzdem noch besser, als alpha-testing. sieh mein - viel zu dunkles - attachement

(das nicht mehr aufzutreiben ist ...)

[zeckensack]

MadManniMan:
Original geschrieben von aths
Bei Max Payne gibt es Alphablending-Maschendrahtzäune, die (zumindest in der inzwischen etwas angestaubten Grafik) ganz gut aussehen, finde ich.

rate mal, was ich grad als beipsiel zeige :)

...hier nochmal *.png in nahansicht (mehrere alphatestschichten übereinander)

(auch das ist weg ...)

[zeckensack]

Ich selbst:

Original geschrieben von Demirug
Der Vorteil des Alphatest neben der Bandbreiteneinsparung ist das es dabei keine Probleme mit der Renderrheienfolge gibt. Beim Alphablending muss man da immer aufpassen.
Das ist richtig, ist aber IMO beim reinen Einsatz für Kantenglättung viel weniger wichtig, als bei transparenten Vollflächen. Man würde sich wohl so etwas wie die Parhelia-Artefakte bei FAA einhandeln, die von der Mehrzahl der 'Betroffenen' momentan toleriert werden.

Ich hätte es halt ganz gerne, wenn ein Alphatest ala "Wegschmiß wenn 0" mit einem gefilterten Textur-Alphakanal und der passenden Blendingfunktion kombiniert würde, sodaß der Output (signaltheoretisch) zumindest stetig bleibt.

Zu den zu erwartenden Artefakten durch die 'falsche' Renderreihenfolge:
Eine nette HW-Erweiterung für diesen Spezialfall wäre ein zweistufiger Alphatest, der zB bei Alpha=0 komplett verwirft, aber schon bei Alpha < 0.5 keine Z-Werte mehr rausschreiben lässt. Könnte klappen ...

[zeckensack]

aths:
Original geschrieben von zeckensack
Eine nette HW-Erweiterung für diesen Spezialfall wäre ein zweistufiger Alphatest, der zB bei Alpha=0 komplett verwirft, aber schon bei Alpha < 0.5 keine Z-Werte mehr rausschreiben lässt. Könnte klappen ...

Mache ich mich jetzt lächerlich, oder kann man nicht ohnehin Alpha Blending und Alpha Testing (fürs Z dann) kombinieren, wie mir Xmas kürzlich kundtat, als es schon zu spät war, das für die Bäume bei meinem OpenGL-Haus umzusetzen?

[zeckensack]

Ich:

Original geschrieben von aths
Mache ich mich jetzt lächerlich, oder kann man nicht ohnehin Alpha Blending und Alpha Testing (fürs Z dann) kombinieren, wie mir Xmas kürzlich kundtat, als es schon zu spät war, das für die Bäume bei meinem OpenGL-Haus umzusetzen?

Natürlich kann man, sollte man IMO auch.

Wenn du dich mit Transparenz auf Rasterizern auseinandersetzt, weißt du aber auch daß man da 'back to front' sortieren sollte, erstens wegen der Z-Information (ein fast transparenter Pixel kann sonst das Zeichnen eines vollständig opaquen (???) Pixels verhindern), zweitens weil die Blending-Funktion sonst nicht mehr 'physikalisch korrekt' ist, oder zumindest nicht mehr kontrollierbar.

Die 'normale' Blendingfunktion ist ja mehr oder weniger
framebuffer.rgb:=incoming.alpha*incoming.rgb+(1-incoming.alpha)*framebuffer.rgb

Wenn man mehrere Schichten mit dieser Funktion überblendet, kommen abhängig von der Reihenfolge andere Ergebnisse dabei heraus - auch wenn man den Z-Buffer&Z-Test komplett abschaltet.

edit: letzteres ist IMO beim Einsatz für Kantenfilter zu vernachlässigen, ersteres führt wohl oder übel zu Artefakten, die den Sinn des ganzen (Stetigkeit des ausgegebenen Signals; Hallo, Onkel Nyquist) teilweise untergraben.

[zeckensack]

Demirug:
Original geschrieben von zeckensack
Das ist richtig, ist aber IMO beim reinen Einsatz für Kantenglättung viel weniger wichtig, als bei transparenten Vollflächen. Man würde sich wohl so etwas wie die Parhelia-Artefakte bei FAA einhandeln, die von der Mehrzahl der 'Betroffenen' momentan toleriert werden.
Ja "schlechtes" AA ist immer noch besser als gar kein AA.
Ich hätte es halt ganz gerne, wenn ein Alphatest ala "Wegschmiß wenn 0" mit einem gefilterten Textur-Alphakanal und der passenden

Blendingfunktion kombiniert würde, sodaß der Output (signaltheoretisch) zumindest stetig bleibt.

Zu den zu erwartenden Artefakten durch die 'falsche' Renderreihenfolge:
Eine nette HW-Erweiterung für diesen Spezialfall wäre ein zweistufiger Alphatest, der zB bei Alpha=0 komplett verwirft, aber schon bei Alpha < 0.5 keine Z-Werte mehr rausschreiben lässt. Könnte klappen ...

Das ist mir zu unflexibel.

Was hälst du von folgender Idee. Der Pixelshader bekommt ein zusätzliche Ausgaberegister. In diesem Register steht jeder skalar r g b a für 25% der Pixelfläche. Steht in diesem Register eine 0 wird die Ausgabe in die zugeordneten MS-Buffer unterdrückt. Ein Wert ungleich 0 läst das schreiben zu wenn nicht schon anderweitig das schreiben blockiert wurde. Bei 6xAA müssen die 4 Skalre natürlich irgendwie sinnvoll umgelegt werden.

Um das ganze jetzt noch sinnvoll in Verbindung mit einem "Alphatest" zu nutzten müsste es eine möglichkeit geben aus einer reinen Alphatexture mit einem Texturezugriff 4 Werte zu gewinnen die entsprechend in r g b a gespeichert werden. Nun könnte man mit einem Vergleich im Pixelshader aus diesen Werten das Maskenregister setzen.

Das ganze kostet dann ein zusätzliches Texturesample und einen PS-Slot.

Noch besser wäre es natürlich wenn man die vollständige Kontrolle über die AA-Sampler bekommen könnte (AA-Sample Shader) bzw im Pixelshader für einzelne Operationen festlegen könnte ob diese pro Pixel oder pro AA-Sample durchgeführt werden müssen.

[zeckensack]

Ich:

Original geschrieben von Demirug
Ja "schlechtes" AA ist immer noch besser als gar kein AA.



Das ist mir zu unflexibel.

Was hälst du von folgender Idee. Der Pixelshader bekommt ein zusätzliche Ausgaberegister. In diesem Register steht jeder skalar r g b a für 25% der Pixelfläche. Steht in diesem Register eine 0 wird die Ausgabe in die zugeordneten MS-Buffer unterdrückt. Ein Wert ungleich 0 läst das schreiben zu wenn nicht schon anderweitig das schreiben blockiert wurde. Bei 6xAA müssen die 4 Skalre natürlich irgendwie sinnvoll umgelegt werden.

Um das ganze jetzt noch sinnvoll in Verbindung mit einem "Alphatest" zu nutzten müsste es eine möglichkeit geben aus einer reinen Alphatexture mit einem Texturezugriff 4 Werte zu gewinnen die entsprechend in r g b a gespeichert werden. Nun könnte man mit einem Vergleich im Pixelshader aus diesen Werten das Maskenregister setzen.

Das ganze kostet dann ein zusätzliches Texturesample und einen PS-Slot.

Noch besser wäre es natürlich wenn man die vollständige Kontrolle über die AA-Sampler bekommen könnte (AA-Sample Shader) bzw im Pixelshader für einzelne Operationen festlegen könnte ob diese pro Pixel oder pro AA-Sample durchgeführt werden müssen.

Als erstbeste Lösung kam mir gerade in den Sinn, den Alpha-erzeugenden Teil des 'Shaders' einmal pro Subpixel laufen zu lassen.
Ist ein wenig Bruteforce, aber im Bezug auf Glättung von Alpha-gesteuerten Transparenzen gleichwertig zu SS, und billiger als volles SS.

[zeckensack]

Demirug:
Original geschrieben von zeckensack
Als erstbeste Lösung kam mir gerade in den Sinn, den Alpha-erzeugenden Teil des 'Shaders' einmal pro Subpixel laufen zu lassen.
Ist ein wenig Bruteforce, aber im Bezug auf Glättung von Alpha-gesteuerten Transparenzen gleichwertig zu SS, und billiger als volles SS.

Genau soetwas meinte ich mit:
Noch besser wäre es natürlich wenn man die vollständige Kontrolle über die AA-Sampler bekommen könnte (AA-

Sample Shader) bzw im Pixelshader für einzelne Operationen festlegen könnte ob diese pro Pixel oder pro AA-Sample durchgeführt werden müssen.

Damit könnte man dann alle denkbaren Fälle abdecken und müsste nicht wieder mit X verschiedenen Speziallösungen kommen.

[zeckensack]

Ich:

Original geschrieben von Demirug
Genau soetwas meinte ich mit:

<snip>

Damit könnte man dann alle denkbaren Fälle abdecken und müsste nicht wieder mit X verschiedenen Speziallösungen kommen.
Ich würde das lieber als transparentes Feature sehen, von dem der Programmierer nichts mitbekommt. Das Verhalten kann IMO vortrefflich deterministisch gesteuert werden, gehört also nicht in den Zuständigkeitsbereich der Applikation

(hierbei liege ich dann wohl eher auf einer Linie mit aths, unterschiedliche Probleme sollen unterschiedlich gelöst werden; für "Pixel Shader-AF" sollte man einen anderen Lösungsweg suchen, sonst kann man gleich konditionales Supersampling machen, was kein Fortschritt wäre).

[zeckensack]

Demirug:
Original geschrieben von zeckensack
Ich würde das lieber als transparentes Feature sehen, von dem der Programmierer nichts mitbekommt. Das Verhalten kann IMO vortrefflich deterministisch gesteuert werden, gehört also nicht in den Zuständigkeitsbereich der Applikation

mhm wie willst du das deterministisch feststellen. Ich habe ja in letzter Zeit viel mit Shaderbäumen gearbeitet. Ich kann dir ohne grössere Probleme für einzelne Anweisungen das Änderungsintervall feststellen aber dafür sind immer bestimmte Informationen erforderlich. So kann der übergang von Vertex in das Pixelinterval nur aufgrund von einer aus 3 Bedingungen erfolgen.

1. Zugriff auf eine Texture. Die Ausgangswerte (Texturekoordinaten)dir dafür gebraucht werden müssen auf das Pixelintervall gewandelt werden.

2. Der Übergang wird von Entwickler erzwungen (Intervall cast).

3. Die Anweisung hat mindestens eine Eingangswert der bereist auf dem Pixelintervall ist.

Die gleichen Regeln würden auch für den Übergang vom Pixel in den AA-Sampel bereich gelten. Auf die Regel 3 hat man keinen direkten Einfluss die Regel 2 erfordert das der Entwickler es manuel erzwingt. Bleibt noch die Regel 1. Hier sehe ich nur die möglichkeit das man einen Texturesampler auf die AA-Ebene zwingen kann und dadurch Regel 1 und 3 zur Anwendung kommen könnten. Aber auch hier wird vom Entwickler eine Entscheidung notwendig. Und zwar auf welcher Ebene die Alphatexture bearbeitet werden soll.

EDIT2: Das würde natürlich auch mit anderen Texturen funktionieren.

(hierbei liege ich dann wohl eher auf einer Linie mit aths, unterschiedliche Probleme sollen unterschiedlich gelöst werden; für "Pixel Shader-AF" sollte man einen anderen Lösungsweg suchen, sonst kann man gleich konditionales Supersampling machen, was kein Fortschritt wäre).
Ja da stimme ich dir zu. Aber das erfordert die Möglichkeit dynamische Schleifen in Pixelshader zu benutzen also PS 3.0 bzw 2.0+ mit den richtigen Caps.

Edit: Wird das nicht lansagm etwas OT?

[zeckensack]

MadManniMan:
Original geschrieben von zeckensack
Wenn du dich mit Transparenz auf Rasterizern auseinandersetzt, weißt du aber auch daß man da 'back to front' sortieren sollte, erstens wegen der Z-Information (ein fast transparenter Pixel kann sonst das Zeichnen eines vollständig opaquen () Pixels verhindern), zweitens weil die Blending-Funktion sonst nicht mehr 'physikalisch korrekt' ist, oder zumindest nicht mehr kontrollierbar.
IN WIE WEIT KANN MAN DIE SORTIERUNG GEZIELT STEUERNß ICH MEINE; ICH WILL JA NICHT DIE GANZE SZENE BTF RENDERN; NUR UM KORREKTES ALPHA BLENDING ZU BEKOMMEN:::

IN DIESEM SINNE WÄRE DIE WELT IN ORDNUNG; HÄTTEN ALLE NE KYRO. DIE SORTIERUNG WÄRE KAUM MEHR SO RELEVANT 8WENN ICH MICH RECHT ENTSINNE; ISTS NICHT SOOO PERFORMANCE FRESSEND BEI NEM TBDR9 UND ALPHA BLENDING WÄRE IMMER SCHÖN; AU?ERDEM WÄRE DER BANDBREITENAUFWAND NICHT MEHR SOOO SCHLIMM

NUR SON PAAR GEDANKEN:::

/edit: :lol: das kommt davon, wenn man blind schreibt, weil man "king of queens" guckt, und dann nicht mitbekommt, daß man capslock an hat :D

[zeckensack]

aths:
Original geschrieben von Demirug
Edit: Wird das nicht lansagm etwas OT?
Nö, es wird gerade richtig interessant... schreibt nur weiter .)

[zeckensack]

Demirug:
Original geschrieben von MadManniMan
IN WIE WEIT KANN MAN DIE SORTIERUNG GEZIELT STEUERNß ICH MEINE; ICH WILL JA NICHT DIE GANZE SZENE BTF RENDERN; NUR UM KORREKTES ALPHA BLENDING ZU BEKOMMEN:::

IN DIESEM SINNE WÄRE DIE WELT IN ORDNUNG; HÄTTEN ALLE NE KYRO. DIE SORTIERUNG WÄRE KAUM MEHR SO RELEVANT 8WENN ICH MICH RECHT ENTSINNE; ISTS NICHT SOOO PERFORMANCE FRESSEND BEI NEM TBDR9 UND ALPHA BLENDING WÄRE IMMER SCHÖN; AU?ERDEM WÄRE DER BANDBREITENAUFWAND NICHT MEHR SOOO SCHLIMM

NUR SON PAAR GEDANKEN:::

/edit: :lol: das kommt davon, wenn man blind schreibt, weil man "king of queens" guckt, und dann nicht mitbekommt, daß man capslock an hat :D

Ich wollte dich schon fragen warum du so schreist. :D

Wie man die Sortierung steuert? Mit der CPU natürlich man muss aber deswegen ja nicht die ganze Szene BTF rendern sondern nur die Teile mit Transparenz und diese eben als letztes.

Die Kyros emulieren aber was das Alphablending und die Transparenz angeht genau das verhalten der IMR. Und da gibt es auch ein kleines Performance Problem (ich muss da aber leider meine Klappe halten). Aber wir hatte dazu hier mal einen Thread und da kann man dann schon die richtigen Schlüsse ziehen.

[zeckensack]

Ich:
Original geschrieben von Demirug
mhm wie willst du das deterministisch feststellen. Ich habe ja in letzter Zeit viel mit Shaderbäumen gearbeitet. Ich kann dir ohne grössere Probleme für einzelne Anweisungen das Änderungsintervall feststellen aber dafür sind immer bestimmte Informationen erforderlich. So kann der übergang von Vertex in das Pixelinterval nur aufgrund von einer aus 3 Bedingungen erfolgen.

1. Zugriff auf eine Texture. Die Ausgangswerte (Texturekoordinaten)dir dafür gebraucht werden müssen auf das Pixelintervall gewandelt werden.

2. Der Übergang wird von Entwickler erzwungen (Intervall cast).

3. Die Anweisung hat mindestens eine Eingangswert der bereist auf dem Pixelintervall ist.

Die gleichen Regeln würden auch für den Übergang vom Pixel in den AA-Sampel bereich gelten. Auf die Regel 3 hat man keinen direkten Einfluss die Regel 2 erfordert das der Entwickler es manuel erzwingt. Bleibt noch die Regel 1. Hier sehe ich nur die möglichkeit das man einen Texturesampler auf die AA-Ebene zwingen kann und dadurch Regel 1 und 3 zur Anwendung kommen könnten. Aber auch hier wird vom Entwickler eine Entscheidung notwendig. Und zwar auf welcher Ebene die Alphatexture bearbeitet werden soll.

EDIT2: Das würde natürlich auch mit anderen Texturen funktionieren.
Ich bin jetzt ganz ehrlich überfragt, ich habe (fast) kein Wort verstanden :|

Ich hatte mir das so vorgestellt:

//irgendwo in den Tiefen des Treibercodes ...

RenderState::unlatch()
{
// ...
if (alpha_test&&multisample&&shader.produces_nonconstant_alpha())
/*
=> Shader in Alpha- und RGB-Teil aufsplitten, den Alpha-Teilshader pro Subpixel,
den RGB-Teil pro Pixel ausführen
*/
// ...
}

bool
FragmentShader::produces_nonconstant_alpha()const
{
if (vertex_shader.outputs_color()&&
this->references_vertex_color()) return(true);

for (int i=0;i<bound_textures;++i)
{
if (texture[ i]->has_alpha_channel()&&
texture[ i]->is_filtered()&&
this->references_texture_alpha(i)) return(true);
}
return(false);
}

//edit: UBB-Markup gefixt ( [ i] )


Das ganze beschränkt sich auf den aktivierten Alpha-Test, weil nur dann die Signaltheorie nicht mehr funktioniert. Für korrektes Verhalten ohne Alpha-Test ist nach wie vor die Applikation zuständig - OIT habe ich nicht versprochen

Ja da stimme ich dir zu. Aber das erfordert die Möglichkeit dynamische Schleifen in Pixelshader zu benutzen also PS 3.0 bzw 2.0+ mit den richtigen Caps.
Nicht zwingend. PS-AF wurde ja schon an anderer Stelle schon besprochen. Ich denke, man könnte hier mit den 'partial derivatives' die NV3x bieten bereits sehr viel anfangen.
Edit: Wird das nicht lansagm etwas OT?
Ja, gern =)

Man kann das ganze natürlich so auslegen, daß die Vorteile von SS bei Alpha-Tests zum Threadthema passen, und deswegen diskutiert gehören, ebenso wie mögliche Lösungsansätze für MS :naughty:

[zeckensack]

Ich:
Original geschrieben von MadManniMan
IN WIE WEIT KANN MAN DIE SORTIERUNG GEZIELT STEUERNß ICH MEINE; ICH WILL JA NICHT DIE GANZE SZENE BTF RENDERN; NUR UM KORREKTES ALPHA BLENDING ZU BEKOMMEN:::

IN DIESEM SINNE WÄRE DIE WELT IN ORDNUNG; HÄTTEN ALLE NE KYRO. DIE SORTIERUNG WÄRE KAUM MEHR SO RELEVANT 8WENN ICH MICH RECHT ENTSINNE; ISTS NICHT SOOO PERFORMANCE FRESSEND BEI NEM TBDR9 UND ALPHA BLENDING WÄRE IMMER SCHÖN; AU?ERDEM WÄRE DER BANDBREITENAUFWAND NICHT MEHR SOOO SCHLIMM

NUR SON PAAR GEDANKEN:::

/edit: :lol: das kommt davon, wenn man blind schreibt, weil man "king of queens" guckt, und dann nicht mitbekommt, daß man capslock an hat :D

Wie Demi schon sagte, Kyro verhält sich bei aktivem Blending (=> Transparenz) wie ein IMR, und kann seine Sortierlogik nicht ausspielen.
Die API-Specs von D3D/OpenGL fordern dieses "first in, first out"-Verhalten. Sortieren kann man nur da, wo es das Ergebnis nicht verändert, und das täte es bei aktivem Blending.

[zeckensack]

MadManniMan:
Original geschrieben von zeckensack
Wie Demi schon sagte, Kyro verhält sich bei aktivem Blending (=> Transparenz) wie ein IMR, und kann seine Sortierlogik nicht ausspielen.
Die API-Specs von D3D/OpenGL fordern dieses "first in, first out"-Verhalten. Sortieren kann man nur da, wo es das Ergebnis nicht verändert, und das täte es bei aktivem Blending.

aber so wie ich mir das vorstelle, ist das nur für die transparenten pixel und auch nur für die transparente textur notwendig.

das raycasting verhält sich meines wissens genau wie ohne alpha blending, nur wird eben beim auftreffen auf eine alphatextur nicht "HALT! hier letztes renderding, du arbeit jetzt schluß!" geschrien, sondern die relevanten werte "zwischengespeichert", der "strahl" fliegt dann weiter

[zeckensack]

So, das waren sie alle, meine direkte Antwort auf Manni ist im ersten Posting.

*wieder offen*

[Demirug]

Original geschrieben von zeckensack
Ich bin jetzt ganz ehrlich überfragt, ich habe (fast) kein Wort verstanden :|

Wir können uns gerne ausführlicher über das Thema Shadertrees und Änderungsintervalle unterhalten. Ist ein sehr interesantes Thema das ich nicht mit den paar sätzen Erschlagen konnte.

Ich hatte mir das so vorgestellt:

<snip>


Das ganze beschränkt sich auf den aktivierten Alpha-Test, weil nur dann die Signaltheorie nicht mehr funktioniert. Für korrektes Verhalten ohne Alpha-Test ist nach wie vor die Applikation zuständig - OIT habe ich nicht versprochen

mhm manchmal braucht man aber alpha berechnungen auch im Zusammenhang mit "normalen" Shaderanteil. Man könnte diese dann natürlich auch in einem anderen als dem Alphateil der Register ausführen aber dann hat man ja letzten Endes doch wieder den Entwickler verantwortlich gemacht.

Nicht zwingend. PS-AF wurde ja schon an anderer Stelle schon besprochen. Ich denke, man könnte hier mit den 'partial derivatives' die NV3x bieten bereits sehr viel anfangen.

Ja die 'partial derivatives' würde ich ja dann benutzen um die Anzahl der Schleifendurchläufe zu bestimmen. Natürlich nicht für den ganzen Shader sondern nur für die Teile wo es etwas bringt.

Ja, gern =)

Man kann das ganze natürlich so auslegen, daß die Vorteile von SS bei Alpha-Tests zum Threadthema passen, und deswegen diskutiert gehören, ebenso wie mögliche Lösungsansätze für MS :naughty:

Da ich in dem ursprünglichen Thread ja nur zum gröstenteil nur Gastleser bin überlasse ich die Entscheidung einem der Mods die hier schon länger zu werke gegangen sind.

[MadManniMan]

dank @zbag und auch an dich demi(für den rebuild)

...zum thread: hat sich da vielleicht ein mod verklickt? :ratlos:

[Exxtreme]

Original geschrieben von MadManniMan

...zum thread: hat sich da vielleicht ein mod verklickt? :ratlos:

<Bart-Simpson-Mode>
Ich war's nicht.
</Bart-Simpson-Mode>

Nee, den Thread hat wohl die Datenbank verschluckt.

[Ailuros]

Nee, den Thread hat wohl die Datenbank verschluckt.

A-HA!!! Eine Datenbank mit Personalitaet :D

Wir haben ja sowieso schon um den Kreis debattiert, viel mehr waere ja sowieso nicht mehr dabei herausgekommen.