Echtes Kantenantialiasing

[ethrandil]

Hallo,
gibt es keine Programme, die den Anteil einer Kante an einem Bildrechteck ausrechnen, und entsprechend verrechnen?
Wenn man von 16fachem antialiasing hört könnte das doch irgendwann sogar schneller sein.

Das funktioniert natürlich nicht für texturen, aber die Kanten müssten dann doch 'echt' geglättet sein, nicht?

- Eth

[Adam D.]

Kantenantialiasing :hammer:

[1283912]

nennt sich multisampling

[Kant]

Hallo,
gibt es keine Programme, die den Anteil einer Kante an einem Bildrechteck ausrechnen, und entsprechend verrechnen?
Wenn man von 16fachem antialiasing hört könnte das doch irgendwann sogar schneller sein.

Das funktioniert natürlich nicht für texturen, aber die Kanten müssten dann doch 'echt' geglättet sein, nicht?

- Eth

Prinzipiell könnte man die Bedeckung mathematisch ermitteln, aber wie will man es verrechnen. Man muss ja für jeden der Subpixel nicht nur testen, ob er im Polygon liegt, sondern auch ob er überhaupt sichtbar ist (Z-Test). Und irgendwo muss man die Farbe/Z-Wert der Subpixel ja auch zwischenspeichern, bis er letzlich zum finalen Pixel verrechnet wird.
Da mann also ohnehin alle Subpixel durchgehen muss, hätte man keinen Vorteil daraus das man vorher schon weiss, das 30% des Pixel vom Polygon bedeckt werden.

Edit: Stell dir vor, es werden auf einen Pixel drei Polygone gerendert. Das erst ist rot, hat 30% Bedeckung, das 2. grün mit 45% Bedeckung, und das letzte blau, mit 70% Deckung. Es ist nicht möglich nur mit diesen Informationen die finale Farbe zu bestimmen. Vielleicht verdeckt das Blau das rot vollkommen, oder auch umgekehrt.

[ethrandil]

hmmm...

z-test bliebe.

erster Durchgang: Testen welcher pixel von xyz ganz bedeckt ist / welcher zu Teilen, von Polygonen x,y,z. (Dabei wird es ein 'Hintergrund'polygon geben, dass von mehreren anderen überdeckt wird.) (mit z-test)

Jetzt müsste man noch die teilweise überdeckten berechnen und man hätte ein mathematisch korrektes antialiasing. Nicht?

Es kann natürlich sein, dass man keine 'mathematische Korrektheit' braucht, aber es geht ums Prinzip ;)

- Eth

[Coda]

Das würde mit einfarbigen Polygonen wohl funktionieren.

...

Aber heutzutage sind die üblicherweiße nicht einfarbig ;D

[aths]

hmmm...

z-test bliebe.

erster Durchgang: Testen welcher pixel von xyz ganz bedeckt ist / welcher zu Teilen, von Polygonen x,y,z. (Dabei wird es ein 'Hintergrund'polygon geben, dass von mehreren anderen überdeckt wird.) (mit z-test)

Jetzt müsste man noch die teilweise überdeckten berechnen und man hätte ein mathematisch korrektes antialiasing. Nicht?Der Framebuffer muss immer eine endliche Größe haben. Damit kann man nicht beliebig genau speichern. Feinste Polygonanteile müssten irgendwann unter den Tisch fallen.

Multisampling nähert die Berechnung der echten Überdeckung an, in dem mehrere, möglichst günstig verteilte Stichproben genommen werden. 16x MSAA stellt die heutige Technik vor große Bandbreiten-Probleme (ein sinnvoll konstruierter TBDR hingegen könnte das mit links erledigen.)

Ich halte 8x MSAA bei "guter" Subpixel-Verteilung für einen recht guten Kompromiss: Sehr hohe Kantenqualität bei einem noch beherrschbaren Bandbreitenproblem.

Wenn ich das richtig verstanden habe, bietet ein TBDR nicht nur Vorteile, z. B. weil das Pixelshader-Programm häufiger gewechselt werden muss, gleiches gilt für die Texturen. Den daraus resultierenden Leertakten steht allerdings an anderer Stelle eine deutlich höhere Effizienz gegenüber, gerade bei hohen Multisampling-Stufen.

[Trap]

Bei endlicher Anzahl von Polygonen und endlicher Genauigkeit der Polygonkoordinaten ist auch das mathematisch exakte Ergebnis mit perfektem Antialiasing in endlich Datenmenge repräsentierbar.
Die Framebuffergröße ist aber nicht nur endlich sondern hat auch eine feste Größe, erst dadurch muss man Informationen verwerfen.

Zusammen mit Texturen sind mathematisch korrekte Verfahren nicht einfach. Ich wüsste nicht auf Anhieb wie man das machen kann. Mit Shadern wird es nahezu unmöglich. Daher muss man Oversampling-Verfahren benutzen.

[ethrandil]

Hm, ja da habt ihr natürlich recht.
Pixelbasierte Texturen und Shader wollen so garnicht zu mathematisch korrektem Antialiasing passen.

Trotzdem würde ich so ein "perfektes Antialiasing" gerne mal sehn - in stark vergrößert und im Vergleich zu einem "fake".

Gibt es da ein Tool oder Bilder? Ich hab mich selber schon theoretisch daran versucht, aber das war mir dann zu viel Schnittpunktberechnung...

- Eth

[aths]

Gibt es da ein Tool oder Bilder? Ich hab mich selber schon theoretisch daran versucht, aber das war mir dann zu viel Schnittpunktberechnung...Ein Tool kannste doch recht einfach proggen: Einfach mit 64x64 Supersampling. Kommt der echten Berechnung recht nahe. Zumal der endgültige Farbwert eh auf 8 Bit pro RGB-Komponente gerundet wird. Das Downsampling solltest du dann noch gammakorrekt gestalten, und du siehst dann halt die (praktisch) bestmöglichen Kanten für die gegebene Auflösung.

[Matti@work]

Hm, ja da habt ihr natürlich recht.
Trotzdem würde ich so ein "perfektes Antialiasing" gerne mal sehn - in stark vergrößert und im Vergleich zu einem "fake".

Gibt es da ein Tool oder Bilder? Ich hab mich selber schon theoretisch daran versucht, aber das war mir dann zu viel Schnittpunktberechnung...

- Eth
wenn du noch ne V3/4/5 hast, könntest du in eigenen OpenGL-Programmen korrektes Edge-AA nutzen ... mit glEnable(GL_POLYGON_SMOOTH) glaube ich. Außerdem muß man es noch im Treiber aktivieren. Wenn du noch ne Voodoo, aber keine Lust zum Programmieren hast, könnte ich dir auch ne Demo schicken.

Alle aktuellen Gamer-Karten ignorieren aber GL_POLYGON_SMOOTH. Ob die Quadros es noch können, weiß ich nicht.

[f!3rce]

ich hab ein programm geschrieben mit echtem antialiasing es ist übertriebn einfach den anteil auszurechnen und ist in echtzeit locker möglich auch bei über 1000000 kantenpixel, mein algorythmus hat keine fehler(außer das beim füllen meine polygons manche antialiasten kanten "überschrieben" werden und so nur die normale aliaste kante zu sehen ist, aber das kann man noch beheben) und ist im vergleich zu ohne antialiasing nur 10% bis 18% langsamer eben weil die berchnung aus zwei wirklich einfachen subtraktionen und dem anschließendem errechnen des farbwertes durch das arithmetische mittel der hintergrundsfarbe und der farbe die darauf gezeichnet werden soll besteht. genauer will ichs nicht beschreiebn weil mein AA vielleicht ne menge wert ist so wie ich das hier überall sehe... (email: Basicfreak1@aol.com)

[aths]

ich hab ein programm geschrieben mit echtem antialiasing es ist übertriebn einfach den anteil auszurechnen und ist in echtzeit locker möglich auch bei über 1000000 kantenpixel, mein algorythmus hat keine fehler(außer das beim füllen meine polygons manche antialiasten kanten "überschrieben" werden und so nur die normale aliaste kante zu sehen ist, aber das kann man noch beheben) und ist im vergleich zu ohne antialiasing nur 10% bis 18% langsamer eben weil die berchnung aus zwei wirklich einfachen subtraktionen und dem anschließendem errechnen des farbwertes durch das arithmetische mittel der hintergrundsfarbe und der farbe die darauf gezeichnet werden soll besteht. genauer will ichs nicht beschreiebn weil mein AA vielleicht ne menge wert ist so wie ich das hier überall sehe... (email: Basicfreak1@aol.com)Dann beheb das doch mal und sorge auch noch dafür, dass man die Polygone nicht von hinten nach vorne rendern muss, sondern die korrekte antialiaste Kante auch bei zufälliger Polygonsortierung zustande kommt.

[f!3rce]

hi

ich hab das n bisschen dumm erklärt meine polygone sind immer zufällig sortiert. das problem ensteht nicht zwischen 2 verschiedenen polygonen sondern intern beim zeichnen eines polygons, worauf ist egal. zuerst werden die kanten berechnet und dann wird das polygon gefüllt und dabei übermalt die füllung manche schon gezeichnete kanten !

[f!3rce]

kann ich eigentlich bilder hier reinstellen?? dann könnte ich das mal zeigen (ist aber sozusagen erst nur ne beta) vom prinzip ist es enfach auch texturen zu für die polygone zu benutzen

[aths]

Zuerst die Kanten berechnet – zeichnest du die als Linien? Wie auch immer, ich sehe Probleme beim Übermalen mehrerer Polygonkanten, die sich schneiden.

Bilder kleiner Größen kann man ins Forum stellen.

[f!3rce]

jein ich zeichne sozusagen zuerst die linien von einem punkt zum anderen des polygons und während dessen wird für die punkte der alphawert berechnet und dann wird farbe in einem Puffer gespeichert, wenn jetzt auf dem selben punkt noch eine kante gezeichnet wird, wird die gespeicherte farbe als hintergrunds farbe gewählt und probleme gibts nirgens, der ganze algorithmus ist sehr dynamisch und variabel anwendbar. alles perfekt geglättet ohne stufen außer durch die begrenzung der farbtiefe

[aths]

jein ich zeichne sozusagen zuerst die linien von einem punkt zum anderen des polygons und während dessen wird für die punkte der alphawert berechnet und dann wird farbe in einem Puffer gespeichert, wenn jetzt auf dem selben punkt noch eine kante gezeichnet wird, wird die gespeicherte farbe als hintergrunds farbe gewählt und probleme gibts nirgens, der ganze algorithmus ist sehr dynamisch und variabel anwendbar. alles perfekt geglättet ohne stufen außer durch die begrenzung der farbtiefeWenn du Alphablending nimmst, musst du doch von hinten nach vorne rendern. Ansonsten scheint durch Kanten weiter vorne der Hintergrund nicht durch.

[f!3rce]

das würde bei einer 3d anwendung der z buffer übernehmen oder nicht?

[f!3rce]

außerdem könnte ich dasauch von vorne nach hinten rendern, denn dann würde mein programm die neue farbe als hintergrund farbe nehmen

was davor kommt würde meinen code verraten:

alpha2 = 1-alpha1
farbe= (alpha1*neueFarbe)+(alpha2*altefarbe)

[f!3rce]

das ist auch zugleich das aufwendigste an meiner berechnung ich finds irgendwie komisch ich suche schon vergeblich im internet irgendwie scheint keiner auf diese billige berechnung gekommen zu sein.

[ethrandil]

Hmm, diese Rechnung ist ja nicht so schwer. problematischer wurds bei mir bei der Berechnung dieser Alpha-Werte, also des Überdeckungsgrads des Pixels.

- Eth

[aths]

außerdem könnte ich dasauch von vorne nach hinten rendern, denn dann würde mein programm die neue farbe als hintergrund farbe nehmen

was davor kommt würde meinen code verraten:

alpha2 = 1-alpha1
farbe= (alpha1*neueFarbe)+(alpha2*altefarbe)Du kannst zwar speichern, wie viel vom Pixel überdeckt ist, aber nicht, wo. Angenommen, zwei Kanten tragen bislang zu einer Pixelfarbe zu jeweils 50% bei. Wenn eine neue (also eine dritte) Kante das Pixel teilweise bedeckt, weißt du nicht, ob damit eine der vorherigen Kanten vollständig rausmaskiert wird, oder beide alten Kanten zum Teil überdeckt werden. Du weißt nur, wie die neue Kante verläuft, aber nicht, wo die alten Kanten im Pixel zur Mischfarbe beitragen.

[f!3rce]

tja da liegt halt mein geheimnis mal gucken gleich sollt ich bilder reinstellen können

[f!3rce]

ich kann keine bilder reinstellen oder ich weiß nicht wie es geht

[f!3rce]

verdammt aber warn versuch wert, vielleicht könnt ihr das ja ohne diese [img] befehle in´eine jpg datei packen und angucken

[ethrandil]

er hat mir ein Bild geschickt:

- Eth

[aths]

tja da liegt halt mein geheimnis mal gucken gleich sollt ich bilder reinstellen könnenDein Geheimnis in Ehren – sofern es ein IMR ist, also nur die Daten des aktuellen Dreiecks vorhanden sind und du in einen Framebuffer renderst, sehe ich prinzipielle Probleme.

Edge-Aliasing via geglätteten Linien ist soweit ich weiß ein alter Hut und hat sich wegen bestimmten Einschränkungen nicht durchgesetzt.

Um Bilder anzuzeigen solltest du sie hochladen. Scroll man etwas nach unten, wenn du im Bildschirm "Auf Thema antworten" bist.

[aths]

er hat mir ein Bild geschickt:

- EthDa glättet meine 6600 GT aber besser ... die übersieht keine Kanten.

[Coda]

das würde bei einer 3d anwendung der z buffer übernehmen oder nicht?Nein. Der verhindert nur dass Polygone die eigentlich weiter hinten sind nicht gezeichnet werden.
Perfektes Back to Front Ordering ist viel zu teuer, Edge-AA ist ja nix neues.

[dirk.loesche]

Da glättet meine 6600 GT aber besser ... die übersieht keine Kanten.
Aber wenn das mal 100% funktioniert ist es bestimmt mal interessant anzuschauen.

Mal sehen ob er den Quellcode unter einer Open Source Lizenz freigibt. Dann könnten wir alle mal schauen und mitverbessern helfen. ;D

[f!3rce1]

so ich hab das ganze jetzt mal eben umgeschrieben sodass ich jetzt texturen benutzen kann, wenn ethrandil so nett ist und das bild reinstellt könnt ihr das ganze mal mit "texturen" sehen aus einfachheits gründen habe ich das nur mit zwei wallpapers von windows gemacht, und zum besseren erkennen die linien die von der füllung überschrieben werden mit rot übermalt ;)

[Neomi]

Deine Hoffnungen, etwas neues entdeckt zu haben, sind unbegründet. Die Idee hatten schon viele, nahezu jeder hat das nach weiteren Überlegungen wieder verworfen.

Beispielrechnungen...

Ein weißes Dreieck bedeckt 50% eines Pixels, ein anderes weißes Dreieck belegt ebenfalls 50% dieses Pixels. Schwarzer Hintergrund -> 50% Weiß -> 75% Weiß. Etwas anderes wirst du mit einem IMR nicht berechnen können, da du ohne konkrete Subpixel nicht wissen kannst, welcher Teil bereits bedeckt ist.

Liegt das zweite Dreieck vor oder hinter dem ersten (zumindest, was diesen Pixel angeht), sollte es aber weiterhin bei 50% bleiben, nicht bei 75%. Liegt das zweite Dreieck neben dem ersten, da beide zur gleichen Oberfläche eines Körpers gehören (kommt sehr häufig vor), bedecken sie zusammen 100% des Pixels. 75% sind falsch und sorgen für sichtbare Linien in einer geschlossenen Geometrie.

Berechne einfach mal eine geschlossene Geometrie oder auch nur ein paar zusammenhängende Dreiecke. Du wirst sofort sehen, daß arithmetisches Antialiasing hier nichts taugt. Einzig und alleine für additives Blending kann man das nutzen.

[f!3rce1]

hm ich probiers mal aus aber ich glaub, dass bei mir automatisch aus 2 pixeln mit jeweils 50 % bedeckung 100% wird... und wenn nicht dann kann man das doch ganz einfach überprüfen genug leistung ist bei meiner methode übrig...

[f!3rce1]

ich meinte 2 kanten nicht pixel sorry

[aths]

Aber wenn das mal 100% funktioniert ist es bestimmt mal interessant anzuschauen.Wenn das so einfach wäre, würde das längst genutzt.

[ScottManDeath]

Naja, das was z.B. in Grafikkarten implementiertist sogenanntes Postfilter-Antialiasing. Man sampelt an einigen diskreten Stellen und verrechnet diese miteinander.

Es gibt auch noch das Prefilter Antialiasing. Dabei sieht man jeden Pixel als Rechteck mit gewissser Fläche an und berechnet analytisch wieviel % der Rechteckfläche von z.B. einem Dreieck besetzt sind. Danach färbt man entsprechend dem Anteil den Pixel ein. Allerdings erfordert IMHO dieses Verfahren dass man Back To Front rendert.

Da ich grade Netzprobleme habe kann ich keine Links dazu liefern :(

[aths]

Naja, das was z.B. in Grafikkarten implementiertist sogenanntes Postfilter-Antialiasing. Man sampelt an einigen diskreten Stellen und verrechnet diese miteinander.

Es gibt auch noch das Prefilter Antialiasing. Dabei sieht man jeden Pixel als Rechteck mit gewissser Fläche an und berechnet analytisch wieviel % der Rechteckfläche von z.B. einem Dreieck besetzt sind. Danach färbt man entsprechend dem Anteil den Pixel ein. Allerdings erfordert IMHO dieses Verfahren dass man Back To Front rendert.Und man hat weiterhin das beschriebene Problem: Kommt im Pixel eine neue Teilfläche hinzu, weiß man nicht, welche alten Teilflächen damit vielleicht völlig überdeckt werden.

[ethrandil]

Hi, ich war leider ein bisschen langsam,, hier das Bild mit Texturen.

Leider musste ich den Bildausschnitt verkleinern, damit die Datei nicht zu groß wird.

- Eth

[aths]

Hi, ich war leider ein bisschen langsam,, hier das Bild mit Texturen.

Leider musste ich den Bildausschnitt verkleinern, damit die Datei nicht zu groß wird.

- EthWas soll man da jetzt tolles drauf sehen?

[f!3rce1]

glatte kanten

[f!3rce1]

so ich habe vorhin versucht die kanten in beliebiger konstillationzueinder zu einander zu schieben und ich sehe darauf keine fehler ,alles ist glatt und sieht natürlich aus und selbst wenn es so wäre mit dem fehler würde ich das lieber haben als das völlig falsche und langsame AA von ATi oder Geforce. außerdem kann man dem fehler so begegnen, dass die kanten immer 1/2 pixel überstehen so würden zwei sich begegnende polygone keine linie dazwischen haben. noch mal zur wiederholung bei mir passiert es nicht wenn ihr den beweis auch haben wollt dann gebt mir eure emails und ich maile das bild( ich will ethrandil nicht belästigen) oder guckt mal mit paint genauer auf meine bilder(und sucht diese vermeintlichen fehler)!

warum glaubt mir den keiner, dass da alles ok ist?? :(

[Coda]

Ich wüsste nicht wo das AA von derzeitigen Karten "falsch" ist. Ab 4xSGMSAA ist die Kante glatt genug.
Vor allem braucht das fast keine Rechenzeit und dank Kompression ist auch die Bandbreite nicht so wild.

Wenn du auch nur halbwegs glaubhaft erscheinen willst, dann nerv hier nicht mit skalierten (!) Bildern wo man AA sehen soll.

hier kannst du alles hochladen: http://imageshack.us/

Und bitte wenn es geht ein Bild mit vielen nicht back-to-front sortierten Polygonen die sich auch überlappen und natürlich PNG.

[f!3rce1]

außerdem ging es bei diesem thema um echtes antialiasing und wie man vielleicht sieht geht das grafisch nicht besser als es auf den bildern zusehen ist. meine abstufungen sind so genau wie ein single daten typ gleitkommastellen hat, wenn das nicht reicht kann ich ja noch auf einen double umstellen!! ich frag mit sowieso warum dieses AA system nicht genutzt wird selbst wenn dieses andere Edge AA diesen fehler hat. außerdem würde ich mich dafür interessieren was ihr denkt wie mein code ist (natürlich nur der wichtige teil mit der berechnung der alphawerte)

[f!3rce1]

Ich wüsste nicht wo das AA von derzeitigen Karten "falsch" ist. Ab 4xSGMSAA ist die Kante glatt genug.
Vor allem braucht das fast keine Rechenzeit und dank Kompression ist auch die Bandbreite nicht so wild.

Wenn du auch nur halbwegs glaubhaft erscheinen willst, dann nerv hier nicht mit skalierten (!) Bildern wo man AA sehen soll.

hier kannst du alles hochladen: http://imageshack.us/

Und bitte wenn es geht ein Bild mit vielen nicht back-to-front sortierten Polygonen die sich auch überlappen und natürlich PNG.

die überlappen sich nur weil ich die koordinaten der pixel des polygons für die farbentnahme aus dem bild genommen habe (lässt sich auch noch ändern)

[Coda]

außerdem ging es bei diesem thema um echtes antialiasing und wie man vielleicht sieht geht das grafisch nicht besser als es auf den bildern zusehen ist.Ich sehe keinen Unterschied zwischen ATi's 6xSGMSAA und "echtem" AA. Beides glatt genug für's Auge und mehr braucht's nicht.

außerdem würde ich mich dafür interessieren was ihr denkt wie mein code ist (natürlich nur der wichtige teil mit der berechnung der alphawerte)Ich behaupte einfach mal dass dein System a) nicht funktioniert oder b) falsch rechnet.

Und ohne weitere Bilder werde ich meine Meinung dazu auch nicht ändern.

[f!3rce1]

mach doch mal n screenshot und guck dir da kanten mit einer schräge von ca 50 oder 60 grad an (von unten nach oben wobei beta rechts ist...) die sollten falsch sein, ist bei meiner geforce jedenfalls so

[Coda]

Wenn du keine GeForce 6 hast, dann ist es auch noch OGMSAA. Das ist deutlich schlechter.

[f!3rce1]

http://img167.exs.cx/img167/501/aa3ae.th.png (http://img167.exs.cx/my.php?loc=img167&image=aa3ae.png)

hier

[f!3rce1]

das zieht auf ner grafikkarte berechnet warscheinlich garnix weil ich nur 2 sachen subtrahieren muss und dann alphablending berechnen muss für die paar kanten pixel

[f!3rce1]

gibt es jetzt wieder was zu meckern?

[Neomi]

Das "andere" Edge-AA ist nicht fehlerhaft, sondern durch die prinzipiellen Nachteile der arithmetischen Bedeckungsberechnung nur sehr eingeschränkt nutzbar. Das, was du da beschreibst, kann rein logisch und mathematisch gesehen nicht funktionieren, solange in einen Buffer mit diskreten Pixeln gerendert wird.

Entweder hast du die relevanten Dinge noch gar nicht getestet, oder du willst es einfach nicht sehen. Nimm es nicht persönlich, aber ich denke, der "Erfinderstolz" trübt deinen Blick.

Zeichne einfach einen weißen Quad (zwei coplanare Dreiecke mit einer gemeinsamen Kante, keine Lücke, keine Überlappung) auf schwarzem Hintergrund, die gemeinsame Kante bitte diagonal. Abhängig davon, wie die Kante durch die Pixel verläuft, werden die dunkleren zwischen 75% Grau und 89,0625% Grau schattiert sein, aber nicht mit 100% Weiß.

Das sieht dann in etwa so aus:

http://img218.exs.cx/img218/2307/quad5vq.gif

[f!3rce1]

http://img61.exs.cx/img61/103/aa8ac.th.png (http://img61.exs.cx/my.php?loc=img61&image=aa8ac.png)

[f!3rce1]

ok ich glaub ich brauch noch mehr beweis bilder einen kleinen mom bitte

[f!3rce1]

wie krieg ich das den hier hin sodass die bilder nicht skaliert sind?? scheint der automatisch zumachen

[f!3rce1]

ok ist ja klar mit dergrauen linie, aber das ist doch kein problem, wenn man einfach die zu zeichnende kante orthogonal zur kante um einen pixel in die entgegen gesetzte richtung zum 3 punkt verschiebt.

oder die alphawerte nach einander in einen buffer speichert und im nachhinein den richtigen Pixel ausgibt.

oder solche kanten einfach weg lässt das kann man ja auch überprüfen

also hätte das doch trotzdem seinen zweck; so viel leistung bei dem algorythmus würde ich nicht einfach wegschmeißen

[f!3rce1]

hab nochmal ne frage:

weiß einer wie der algorithmus von "normalen" edge AA ist vielleicht ist meiner ja in der hinsicht was neues

[f!3rce1]

ach übrigens fällt mir gerade ein habe ich doch sozusagen "indirekte" single genaue subpixelinformationen ich glaub daran sollt ich nochmal arbeiten!!

[Neomi]

ok ist ja klar mit dergrauen linie, aber das ist doch kein problem, wenn man einfach die zu zeichnende kante orthogonal zur kante um einen pixel in die entgegen gesetzte richtung zum 3 punkt verschiebt.

Das ist keine Option. Ein Renderer soll die Geometrie so exakt wie möglich darstellen, sie aber keinesfalls verändern. Das führt nur zu weiteren Problemen.

oder die alphawerte nach einander in einen buffer speichert und im nachhinein den richtigen Pixel ausgibt.

Ein Buffer für die Alphawerte? Du sprichst hier von Subpixeln. ;)

oder solche kanten einfach weg lässt das kann man ja auch überprüfen

Und wie willst du das überprüfen? Wenn du das erste Dreieck renderst, weißt du vom zweiten noch nichts. Wenn du das zweite renderst, weißt du vom ersten nichts mehr.

also hätte das doch trotzdem seinen zweck; so viel leistung bei dem algorythmus würde ich nicht einfach wegschmeißen

Microsoft hat es weggeworfen. In DirectX 8.1 war Edge-AA noch enthalten, in 9.0 nicht mehr. Eigentlich schade, da es für Spezialfälle wie z.B. adaptives Blending nutzbar ist. Aber eben auch nur da.

[f!3rce1]

sorry aber ich hab nochmal ne frage:

wenn man jetzt weiß welcher teil vom Pixel bedeckt ist wie muss man jetzt weiterrechnen damit man zum finalen pixel kommt (ich hab die information wieviel von welcher seite bedeckt ist (z.b. 10% von oben oder 30% von links)

[Neomi]

hab nochmal ne frage:

weiß einer wie der algorithmus von "normalen" edge AA ist vielleicht ist meiner ja in der hinsicht was neues

Das "normale" Edge-AA berechnet die exakte Bedeckung eines Pixels, heraus kommt ein Wert zwischen 0 und 1. Damit wird der Alphawert des Pixels multipliziert, deshalb funktioniert das auch nur bei eingeschaltetem Alphablending. Für additives Blending setzt du also D3DRS_ALPHABLENDENABLE auf TRUE, D3DRS_SRCBLEND auf D3DBLEND_SRCALPHA und D3DRS_DESTBLEND auf D3DBLEND_ONE.

Dein Algorithmus ist nicht neu. Er ist vielleicht sogar fehlerfrei. Bloß die Technik ist nicht für den Praxiseinsatz geeignet.

[f!3rce1]

sagen wir das mal so:

ich hab sozusagen die bedeckung als alphawert genommen aber wie du das meinst wäre die linie zwischen zwei dreiecken noch fehlerhafter... entweder hast du dich da falsch augedrückt oder du hast nur spekuliert...

[Neomi]

sorry aber ich hab nochmal ne frage:

wenn man jetzt weiß welcher teil vom Pixel bedeckt ist wie muss man jetzt weiterrechnen damit man zum finalen pixel kommt (ich hab die information wieviel von welcher seite bedeckt ist (z.b. 10% von oben oder 30% von links)

Die Informationen, welcher Teil bedeckt ist, hat du nicht. Es gibt nicht einfach nur vier Seiten. Du müßtest also für jeden Pixel ein Rechteck bilden, die Dreiecke darauf zuschneiden, all diese Dreiecksfragmente in einer Liste zunehmender Größe verwalten, alle Fragmente abhängig von ihrer Tiefe relativ zueinander schneiden, daß keine Überlappung mehr existiert und erst dann alle Teile zusammenrechnen. Und das gilt auch nur für den Fall, daß keins der Dreiecke transparent ist. Das wirst du nicht in vertretbarer Performance umsetzen können.

[f!3rce1]

tja dann sehen wir uns wohl bald mit meinem mit perfekter performance umgesetzten fehlerfreien algorithmus wieder, vielleicht morgen ich weiß sehr genau dass ich das mache

[Neomi]

sagen wir das mal so:

ich hab sozusagen die bedeckung als alphawert genommen aber wie du das meinst wäre die linie zwischen zwei dreiecken noch fehlerhafter... entweder hast du dich da falsch augedrückt oder du hast nur spekuliert...

Nö, nicht falsch ausgedrückt, nur eben die Eigentransparenz des Dreiecks nicht unterschlagen. Bei undurchsichtigen Dreiecken beträgt der Alphawert quasi 1, was in einem neuen Alphawert resultiert, der exakt der Bedeckung entspricht. Bei einem Dreieck, das mit 50% Transparenz gerendert werden will, muß eben dieser Wert noch damit multipliziert werden.

Gerade die transparenten Dreiecke sind es auch, die deinen Ansatz mit der Kantenverschiebung (neben weiteren Problemen) ausschließen. Ein weißes Quad mit 50% Transparenz auf schwarzem Hintergrund muß 50% grau ergeben, die zusätzliche Überlappung der Kante mittendrin würde dieses 50% Grau nochmal auf 75% Grau hochprügeln.

[Neomi]

tja dann sehen wir uns wohl bald mit meinem mit perfekter performance umgesetzten fehlerfreien algorithmus wieder, vielleicht morgen ich weiß sehr genau dass ich das mache

Deinen Ehrgeiz in allen Ehren, aber das wird nicht klappen. Ich will dir das ja nicht vermiesen. Du wirst aber enttäuscht sein. Wenn immer wieder Praxisfälle kommen, mit denen es nicht funktioniert.

[Matti@work]

Man könnte Edge-AA machen, das auch unsortierte Polygone fast immer korrekt darstellt, wenn man 2 Z-Buffer, 2 Color-Buffer und 1 Alpha-Buffer verwendet. Jedoch gibt es auch hier 2 Probleme:

1. es ist bei heutigen Grafikkarten nur in Software möglich (bzw über ziemlich aufwändige Shader)

2. Z-Pass-First-Rendering ist nicht möglich, was aber in zukünftigen Shader-lastigen Game-Engines immer mehr genutzt werden wird

Außerdem braucht man über Edge-AA heutzutage gar nicht mehr diskutieren, weil alle Oberklasse-Grakas auch hohe AA-Modes schnell genug darstellen können ... wäre etwa so, als wenn wir schon Fusions-Kraftwerke hätten und über Energie-sparen reden würden ;)

[Xmas]

hm ich probiers mal aus aber ich glaub, dass bei mir automatisch aus 2 pixeln mit jeweils 50 % bedeckung 100% wird... und wenn nicht dann kann man das doch ganz einfach überprüfen genug leistung ist bei meiner methode übrig...
Wenn man das "ganz einfach" überprüfen kann, dann beschreibe doch mal wie. Und wie definierst du "genug Leistung"?
Wie renderst du deine Bilder eigentlich? Berechnest du erst was in Software vor und renderst dann in Hardware, ist das Softwarerendering oder läuft das vollständig in Hardware?

so ich habe vorhin versucht die kanten in beliebiger konstillationzueinder zu einander zu schieben und ich sehe darauf keine fehler ,alles ist glatt und sieht natürlich aus und selbst wenn es so wäre mit dem fehler würde ich das lieber haben als das völlig falsche und langsame AA von ATi oder Geforce.
MSAA ist innerhalb der gegebenen Auflösung korrekt und eigentlich gar nicht langsam. Ich glaube nicht, dass "dein" Algorithmus schneller ist.

außerdem kann man dem fehler so begegnen, dass die kanten immer 1/2 pixel überstehen so würden zwei sich begegnende polygone keine linie dazwischen haben.
Damit hast du wieder ein paar neue Probleme. Du kannst nicht einen Bildfehler einfach gegen einen anderen austauschen. Zumal man die Objekte dann nicht mehr in Triangle Strips, sondern in Triangle Lists rendern müsste, da die Dreiecke ja keine Eckpunkte mehr teilen. Das drückt die Vertex-Performance.


warum glaubt mir den keiner, dass da alles ok ist?? :(
Weil da nicht alles ok ist. Weil es schon viele Leute vor dir versucht haben und herausgefunden haben, dass Edge-AA durch Alpha-Blending mit dem Bedeckungswert einfach nicht fehlerfrei und gleichzeitig performant zu realisieren ist.

http://img167.exs.cx/img167/501/aa3ae.th.png (http://img167.exs.cx/my.php?loc=img167&image=aa3ae.png)

hier
Na da sind doch schon mal Fehler. Beispielsweise dass die Eckpixel abstehen und nicht geglättet sind. Oder dass unten rechts drei Kanten nicht geglättet sind. Kannst du mal die Texturkoordinaten frei wählen, und nicht Screen-aligned?

das zieht auf ner grafikkarte berechnet warscheinlich garnix weil ich nur 2 sachen subtrahieren muss und dann alphablending berechnen muss für die paar kanten pixel
Alpha-Blending ist aber ganz und gar nicht umsonst.


sagen wir das mal so:

ich hab sozusagen die bedeckung als alphawert genommen aber wie du das meinst wäre die linie zwischen zwei dreiecken noch fehlerhafter... entweder hast du dich da falsch augedrückt oder du hast nur spekuliert...
Die Bedeckung als Alpha-Wert zu nehmen (dann mit dem Pixel-Alpha-Wert multiplizieren) und mit dem Hintergrund linear zu interpolieren ist überhaupt nicht neu. Voodoo Graphics tat das schon in Hardware. Dass es sich nicht durchgesetzt hat, sollte dir doch zu denken geben.

[f!3rce1]

bei durchsichtigkeit von 50% würde die kante mit nur 50% auf dem pixel nur noch 25% sein, und 25% der einen + 25% der anderen hälfte des pixel wären korrekterweise wieder 50% ! genau wie das bei den sub pixel wäre! du scheins komisch gedacht zu haben.

ich habe bei mir rausgefunden das ich sozudagen 4 sub pixel habe, und die so eingeteilt sind:

[img=http://img188.exs.cx/img188/719/aaf0ee.png] (http://www.imageshack.us)

ich kann damit überprüfen ob eine kante die andere um wieviele einheiten überlegt. und somit wäre dann das perfekte antialiasing geboren.

ich versteh eure skepsis ja, aber dann lasst mich euch doch wenigsten davon überzeugen, dass ich einen neuen ansatz habe der eine ganz einfache rechnung darstellt, die will euch aber nicht verraten wäre ja auch ein bisschen dumm. außerdem habt ihr mir indirekt viele gute tips gegeben. ;)

ich wäre euch nochmal dankbar wenn einer mir zeigen kann wie das "andere" Edge-AA funktioniert.

[f!3rce1]

das ganze wird nur sofware gerendert(vb6 gemessen hab ich nur den bereich wo die polygone in ein 2 dimensionales(x,y) array gespeichert werden mit ihren farben(d.h. weil da normalerweise noch ne menge dazukommt bis das bild auf dem monitor erscheint ist der gemessene wert sogar noch langsamer als der bis zum völlig gerenderten bild!!!!) und glaub mir für die überdeckung muss ich einen wert (der ist automatisch drin wenn die kanten entlang gehe)von einem anderen abziehen und schon ist da die überdeckung sogar von welcher richtung. und warum da fehler auftreten hab ich schon mal früher erwähnt.

ihr müsst echt denken, dass ich einen iq von 5 hab oder?

[f!3rce1]

man man... das was meinen algorithmus "neu" macht, hab doch noch gar nicht erwähnt würde ich auch nicht tun, falls das was wert ist

das neue ist meine rechnung die nur aus ner billigen subtraktion besteht die wohl alle übersehen haben (die ist auch n bissl ungewöhnlich)

[f!3rce1]

außerdem nochmal zum alpha blending:

das "normale"AA mit subpixeln muss doch trotzdem alphablending benutzen??

[f!3rce1]

http://img173.exs.cx/img173/6817/aaf6pf.png (http://www.imageshack.us)

[Xmas]

bei durchsichtigkeit von 50% würde die kante mit nur 50% auf dem pixel nur noch 25% sein, und 25% der einen + 25% der anderen hälfte des pixel wären korrekterweise wieder 50% ! genau wie das bei den sub pixel wäre! du scheins komisch gedacht zu haben.
Ich weiß nicht auf was sich das jetzt genau bezieht, aber du machst doch lineare Interpolation, kein additives Blending.

Angenommen, der Hintergrund sei Schwarz und du hast zwei weiße, halbtransparente Polygone die sich den Pixel mittig teilen.
Beim Rendern des ersten Polygons ergibt sich eine Bedeckung von 50% und eine Transparenz von 50%, also Alpha = 50% * 50% = 25%. Lineare Interpolation zwischen Schwarz und Weiß ergibt also 25% Grau. So weit so gut, aber beim nächsten Polygon ist der Alpha-Wert derselbe, nur die Hintergrundfarbe nicht.
Du interpolierst mit 25% Grau und Weiß, und kommst dabei auf 43,75% Grau. Korrekt wäre aber 50%.



ich kann damit überprüfen ob eine kante die andere um wieviele einheiten überlegt. und somit wäre dann das perfekte antialiasing geboren.
Dazu musst du aber erst mal die Daten beider Kanten vorliegen haben. Und wie willst du mit vier Subpixeln die Überdeckung exakt feststellen.

ich versteh eure skepsis ja, aber dann lasst mich euch doch wenigsten davon überzeugen, dass ich einen neuen ansatz habe der eine ganz einfache rechnung darstellt, die will euch aber nicht verraten wäre ja auch ein bisschen dumm. außerdem habt ihr mir indirekt viele gute tips gegeben. ;)
Nun, wenn du uns überzeugen willst, aber nichts verraten willst, dann musst du eben Beispiele verschiedener realistischer Spielszenarien präsentieren, die mit deinem Algorithmus fehlerfrei gerendert wurden, und das ohne Sortieren.

ich wäre euch nochmal dankbar wenn einer mir zeigen kann wie das "andere" Edge-AA funktioniert.
- Pixelbedeckung ermitteln
- Pixelbedeckung mit dem Alpha-Wert des Pixels multiplizieren
- Alpha-Blending mit linearer Interpolation: (Alpha * Src + (1-Alpha) * Dest)

Dabei ist es relativ egal, wie man genau die Pixelbedeckung ermittelt, sofern dazu nur die aktuelle Kante betrachtet wird. In der Regel nimmt man den Abstand des betrachteten Pixels von der idealen Kante. Du kannst ja mal nach Wu-Antialiasing googlen.

[Xmas]

außerdem nochmal zum alpha blending:

das "normale"AA mit subpixeln muss doch trotzdem alphablending benutzen??
Aber nur bei transparenten Objekten. Bei Edge-AA muss zum Rendern aller Kanten Alpha-Blending aktiv sein.

[Xmas]

und glaub mir für die überdeckung muss ich einen wert (der ist automatisch drin wenn die kanten entlang gehe)von einem anderen abziehen und schon ist da die überdeckung sogar von welcher richtung. und warum da fehler auftreten hab ich schon mal früher erwähnt.
Das hört sich für mich eben genau wie Wu-Antialiasing an. Linien Rendern á la Bresenham, aber anstatt anhand des Error Terms einen von zwei möglichen Pixeln zu wählen, nimmst du ihn um die anteilige Bedeckung beider Pixel zu errechnen.

Wenn man das ganze für Polygone statt für Linien macht, kann man vorher auch die Seite der Kante ermitteln, die im Polygon innen liegt, und braucht nur für die äußeren Pixel die anteilige Bedeckung zu ermitteln.


Es ist ja schön dass du weißt warum da Fehler auftreten, aber das reicht nicht. Du musst auch wissen wie du sie ohne Nebenwirkungen beseitigst.

[f!3rce112h]

ich hab mich jetzt nich hauptsächlich um die beseitigung dieser fehler gekümmert und wollte eigentlich nur das antialiasing zeigen also habe ich mich nicht ums zeichnen des inhalts eines polygons gekümmert, wenn du wissen willst warum diese fehler auftreten erkläre ich es dir:

bei meinem "algorithmus" gehe die linie von einem punkt zum anderen des polygons dabei wird die aktuelle x position gespeichert in einen array z.b. so h1(y) = X ; y ist die aktuelle höhe, das mache ich bei jeder kante so ,
dann wenn alles AA berechnet ist, nehme ich diese werte und gehe von oben nach das ganze Polygon durch und überprüfe ob h1(y) < h2(y) wenn ja, dann
kommt:
//for x = h1(y) to h2(y)
//Pixel(x,y) = Farbevonpolygon
//next

wenn //h2(y)<h1(y)
dann

//for x = h2(y) to h1(y)
//Pixel(x,y) = Farbevonpolygon
//next

so jetzt kommt es an manchen stellen vor, dass h2(y) (oder h1(y)) genau die position ist wo die antiliaste kante ist, also wird sie überschrieben; verstehst du??

so: zu dem Prozentproblem:

ich hatte mir überlegt, dass z.b. 50% bedeckung der einen seite vom pixel und 50% alpha(des polygons) der einen seite zu 50% alpha des halben pixels wird (heißt 25% alpha im ganzen pixel), wenn jetzt die andere seite auch 50% alpha kriegt bleibt im gesamten Pixel 50% erhalten, so meinte ich das
(jetzt mal ein bisschen primitiv erklärt)
hoffe, das dass mit dem alphablending problem jetzt geklärt ist...

[Xmas]

bei meinem "algorithmus" gehe die linie von einem punkt zum anderen des polygons dabei wird die aktuelle x position gespeichert in einen array z.b. so h1(y) = X ; y ist die aktuelle höhe, das mache ich bei jeder kante so ,
dann wenn alles AA berechnet ist, nehme ich diese werte und gehe von oben nach das ganze Polygon durch und überprüfe ob h1(y) < h2(y) wenn ja, dann
kommt:
//for x = h1(y) to h2(y)
//Pixel(x,y) = Farbevonpolygon
//next

wenn //h2(y)<h1(y)
dann

//for x = h2(y) to h1(y)
//Pixel(x,y) = Farbevonpolygon
//next

Ja, das ist ein üblicher Scanline-Fill-Algorithmus. Könnte man noch ein bisschen optimieren (die Entscheidung, welche Kante rechts und welche links liegt, muss z.B. nur einmal, nicht pro Zeile getroffen werden), aber das ist ja erst mal nicht so wichtig.

so jetzt kommt es an manchen stellen vor, dass h2(y) (oder h1(y)) genau die position ist wo die antiliaste kante ist, also wird sie überschrieben; verstehst du??
Du malst ja zuerst die Kanten als geglättete Linien, korrekt? Dann müsstest du in diesem Schritt doch feststellen können, wo das Polygoninnerere aufhört und die Kantenpixel anfangen.

so: zu dem Prozentproblem:

ich hatte mir überlegt, dass z.b. 50% bedeckung der einen seite vom pixel und 50% alpha(des polygons) der einen seite zu 50% alpha des halben pixels wird (heißt 25% alpha im ganzen pixel), wenn jetzt die andere seite auch 50% alpha kriegt bleibt im gesamten Pixel 50% erhalten, so meinte ich das
(jetzt mal ein bisschen primitiv erklärt)
hoffe, das dass mit dem alphablending problem jetzt geklärt ist...
Das Verständnisproblem ist vielleicht geklärt, das technische Problem aber nicht. Nachdem das erste Polygon einmal gerendert ist, weißt du nicht mehr wo genau es lag. Somit kannst du eben auch nicht mehr feststellen ob sich die Polygone den Pixel brüderlich teilen oder ob sie sich vollständig überdecken.

[Neomi]

Na wenn du es nicht glauben willst, dann versuche es ruhig, dadurch kannst du eigentlich nur dazulernen.

Ein paar Tips für automatisiertes Überprüfen des Ergebnisses:
1. Berechne Dreiecke von konstanter Farbe und einen konstanten Hintergrund, damit eliminierst du Einflüsse durch von der Auflösung abhängigen Texturfilterung.
2. Berechne ein Bild ein zweites mal ein einer höheren Auflösung (z.B. 16x so hoch) und rechne es per Boxfilter runter. Vergleiche dann per Differenz die beiden Bilder, die nun die gleiche Auflösung haben. Ein perfektes Antialiasing würde für eine Differenz von 0 sorgen, wenn du dich an 1. hälst.

Diese Überprüfung muß jedem Bild (sofern 1. gilt) standhalten, nicht nur wenigen ausgesuchten.

[MadManniMan]

Uiuiui...

...an sich ist die ganze Sache vorangig interessant, nebenbei auch noch unterhaltsam.
Aber fierce, ich BITTE dich, bemüh dich BITTE um Interpunktion - deine dahingerafften Worthaufen sind kaum als Sätze zu erkennen ;(

[f!3rce1]

ich habe festgestellt´, dass mein algorithmus sozusagen dieser besenham algorithmus ist. Also das mit den nachkommastellen:

(ystep = (y1 - y2)/(x1 - x2))
for x = x1 to x2
dy = dy + ystep
alpha = dy - int(dy)
farbe(x,dy) = (alpha*neuefarbe) + ((1-alpha)*altefarbe)
next
(da ist natürlich noch mehr, z.b. die entscheidung ob ystep > 1 um dann nicht in x richtung zu gehen, sondern y richtung)

aber dadurch, dass die nachkommastelle sozusagen die information ist, wie weit die linie und von welcher richtung in den pixel reinreicht, kann man doch den fehler mit den kanten, die in einem Pixel liegen beheben.

wie wird denn das bei dem herkömmlichen antaliasing verhindert? das hab ich noch nicht so ganz verstanden, dann könnte ich meinen vielleichtnoch verbessern.

außerdem kann das mit dem alphablending problem alleine doch nicht diesen tollen algorithmus aus dem rennen schmeißen oder?

[Neomi]

aber dadurch, dass die nachkommastelle sozusagen die information ist, wie weit die linie und von welcher richtung in den pixel reinreicht, kann man doch den fehler mit den kanten, die in einem Pixel liegen beheben.

Welchen Fehler meinst du jetzt genau?

wie wird denn das bei dem herkömmlichen antaliasing verhindert? das hab ich noch nicht so ganz verstanden, dann könnte ich meinen vielleichtnoch verbessern.

Bei FSAA werden die Nachteile von arithmetischem Antialiasing dadurch umgangen, daß kein arithmetisches Antialiasing benutzt wird. Dafür gibt es dann ja die Subpixel. Die haben dann zwar den "Nachteil" einzelner Abstufungen, innerhalb dieser Grenze ist das dafür aber korrekt.

Beim Kantenantialiasing werden die Fehler nicht umgangen, sondern in Kauf genommen, deshalb ist das auch nur begrenzt nutzbar. Bei der Darstellung von Drahtgittermodellen z.B. spielt das keine Rolle.

außerdem kann das mit dem alphablending problem alleine doch nicht diesen tollen algorithmus aus dem rennen schmeißen oder?

Oh doch, zumindest in deinem Anwendungsgebiet. Der Bresenham-Algorithmus wurde auch nicht für Antialiasing gemacht, sondern zum Zeichnen von simplen Linien mit hoher Geschwindigkeit. Dafür behält er weiterhin seine Gültigkeit.

[Xmas]

ich habe festgestellt´, dass mein algorithmus sozusagen dieser besenham algorithmus ist. Also das mit den nachkommastellen:

(ystep = (y1 - y2)/(x1 - x2))
for x = x1 to x2
dy = dy + ystep
alpha = dy - int(dy)
farbe(x,dy) = (alpha*neuefarbe) + ((1-alpha)*altefarbe)
next
(da ist natürlich noch mehr, z.b. die entscheidung ob ystep > 1 um dann nicht in x richtung zu gehen, sondern y richtung)
Das ist eine Variante des Wu-Algorithmus. Bresenham wäre ja ungeglättete Linien.

aber dadurch, dass die nachkommastelle sozusagen die information ist, wie weit die linie und von welcher richtung in den pixel reinreicht, kann man doch den fehler mit den kanten, die in einem Pixel liegen beheben.
Sofern du die Informationen der zuvor gerenderten Kante parat hast. Deren Deckungsinformationen brauchst du ja auch. Nur, wo und wie willst du diese ablegen?

wie wird denn das bei dem herkömmlichen antaliasing verhindert? das hab ich noch nicht so ganz verstanden, dann könnte ich meinen vielleichtnoch verbessern.
Bei Supersampling oder Multisampling werden Farbe und Z-Wert pro Subpixel gespeichert. Damit kann man auch pro Subpixel testen, ob die neue Kante die bereits gerenderte Geometrie überdeckt.

außerdem kann das mit dem alphablending problem alleine doch nicht diesen tollen algorithmus aus dem rennen schmeißen oder?
Doch. Das Problem ist, dass man mit Alpha-Blending Back-to-Front rendern muss. Damit kann man sich zwar den Z-Buffer sparen, aber muss jeden einzelnen Pixel rendern, selbst wenn er im finalen Bild von anderen Polygonen verdeckt wird. Die vielen schönen Z-Cull-Optimierungen funktionieren dann nicht mehr, und das kostet massiv Leistung. Und Depth Sorting ist auch nicht gerade schnell, ebenso Alpha-Blending.

[f!3rce1]

ich glaube, dass ihr meine idee noch nicht so ganz verstanden habt.
ich will mich ja vom alpha blending lösen.
vielleicht so:

ich brauche einen neuen dynamischen buffer in dem ich für jeden pixel die information, wie weit und von welcher seite die kante in den pixel reinreicht und natürlich die farbe, speichere. und dass ich dann im nachhinein, wenn alles berechnet ist, entscheide, ob zwei kanten übereinander liegen, wieviel dann von einer kante "überguckt" oder ob sich kanten den pixel "brüderlich" teilen. dann wenn alles entschieden ist, wird der pixel, so genau wie dieses verfahren ist, gezeichnet. im spiel sollten dann fehler nicht zu erkennen sein.

ich würde bei solch "perfekt" geglätteten kanten auch das bisschen leistungsverlust eingehen, falls da überhaupt so viel leistung verloren geht.

außerdem könnte man das ganze noch so verbessern das es noch einen zweiten puffer gibt in dem gespeichert wird, ob sich in dem pixel überhaupt zwei kanten treffen und dann werden diese pixel bei der ganaueren berechnung ausgelassen.

oder so:

ich lege vier sub pixel an. in jedem wird dann nicht nur die farbe gespeichert sondern auch der wert wie viel die kante im pixel "steckt". dann werden pro polygon die werte neu aufeinander gerechnen bis dann am ende die farbe des subpixels feststeht und mit den anderen sub pixeln verechnet wird.

ich werde mich mal ransetzen und das ganze neu programmieren mit beiden versionen und wenn ichs geschaft habe kann ich euch das ergebnis präsentieren. aber momentan ist mein anderer pc an dem ich das mache "hin", deshalb kann das noch n bissl dauern

[f!3rce1]

Sofern du die Informationen der zuvor gerenderten Kante parat hast. Deren Deckungsinformationen brauchst du ja auch. Nur, wo und wie willst du diese ablegen?


die deckungsinformation ist ja diese:

da die beiden blauen dreiecke gleich groß sind würden sie, wenn man das überstehende dreieck auf das "unterstehende" dreieck legt ein rechteck ergeben.
da die "höhe" bekannt ist, als die nachkommastelle (siehe anderer bericht) und die breite des pixel 1 ist, ist die bedeckte fläche der kante(grün) genau die höhe (rot) 1xhöhe=fläche -> höhe=fläche (fläche = gelb),
damit habe ich alle informationen zumberechnen des antialiasing:

http://img56.exs.cx/img56/6342/pixel2jz.png (http://www.imageshack.us)

[f!3rce1]

nanu?

sind jetzt alle eingefroren? ich dachte ihr wollt mich noch n bissl verbessern?

[ethrandil]

Nagut, ein Hinweis:
Das funktioniert nur solange die Kante durch den Pixel komplett durchläuft. Wie hier ja schon festgestellt wurde, funktioniert das nicht wenn die Spitze des Dreiecks in dem Pixel liegt.
Ebenso funktioniert das nicht, wenn zwei Kanten eines Polygons durch den Pixel verlaufen.

Und so ganz Mathematisch korrekt ists damit leider auch nicht, das ist aber ja schon klar, oder?

- Eth

[Neomi]

sind jetzt alle eingefroren? ich dachte ihr wollt mich noch n bissl verbessern?

Na denn, nächste Runde, diesmal mit Beispielbildern. Jedes Quadrat entspricht einem stark vergrößerten Pixel und dessen Inhalt vor der Verrechnung zum entgültigen Pixel.

http://img96.exs.cx/img96/8485/aaa2bm.jpg

Bild 1:

- ein grünes Dreieck, 50%, rechte Seite
- ein rotes Dreieck, 50%, linke Seite

Nach deinen Vorstellungen zur Speicherung der Informationen über die Lage der Dreiecke würde das wohl hinhauen, auch wenn diese Vergleiche schon zu viel Rechenzeit verschlingen.

Bild 2:

- ein grünes Dreieck, 50%, rechte Seite
- ein rotes Dreieck, 50%, linke Seite

Nanu, irgendwas ist anders. Obwohl die Informationen, die du dir dazu merken willst (wieviel von welcher Kante aus) identisch sind. Wie willst du das lösen?

Bild 3:

Das rote Dreieck kommt von links und von oben rein, bedeckt aber die linke obere Ecke nicht. Das grüne Dreieck ist nichts besonderes, das blaue aber. Nein, eigentlich ist es nichts besonderes, bloß für dein Programm. Welcher Kante des Pixels willst du es zuordnen? Oben, unten oder gar rechts?

Bild 4:

Das Mesh eines Objektes, entweder hoch aufgelöst oder aus großer Entfernung betrachtet. Jedenfalls werden die Dreiecke so klein, daß viele von ihnen in einem einzigen Pixel Platz finden. Und ein Dreieck kann wirklich eine beliebige Position innerhalb eines Pixels einnehmen. Ein normaler Immediate Mode Renderer würde bei 4x FSAA einfach flott drüberpflügen, drei der vier Subpixel umfärben und weiterarbeiten. Wie lautet dein Ansatz dazu?

Bild 5:

Nochmal deutlich kleinere Dreiecke. Die herkömmliche Weise mit den Subpixeln würde wohl für ein undeutliches Flackern des Pixels schon ab der 1. oder 2. Nachkommastelle reichen. Aber nicht so das arithmetische Antialiasing, denn das ist ja sowas von exakt ist das aber auch.

Antialiasing per Subpixel ist innerhalb seiner Abstufungen exakt. Das liegt daran, daß zu jedem Subpixel die vollständigen Informationen vorliegen, vor dem Downsampling könnte man sich also theoretisch noch den Inhalt der Subpixel einzeln betrachten. Zumindest die GPU kann das, muß sie zur Verrechnung ja auch.
Für ein arithmetisches Antialiasing heißt das, sofern es denn wirklich arithmetisch sein will, daß man den Inhalt eines "Pixels" vor dem Verrechnen in beliebiger Skalierung betrachten kann. Auch in Postergröße, auch mit dem Beispiel in Bild 5, und es muß weiterhin exakt sein. Wenn es nicht so exakt ist (und der "ungenaue" Single als Begründung langt nicht, dann nimmt man eben Double), dann ist es kein arithmetisches Antialiasing. Dann kommt man nämlich mit endlich vielen Subpixeln besser und schneller zum Ziel, und wenn es 256 oder 1024 sind. Und selbst wenn es 65536 sind, hat dies immer noch den Vorteil, daß der Speicherbedarf des nötigen Puffers nicht während des Renderns steigen kann. Die dynamischen Listen jedes einzelnen Pixels, die du beim arithmetischen Antialiasing verwalten müßtest (was dann auch noch in einem Deferred Renderer resultieren würde), tun dies nämlich.

Jetzt überzeugt? Oder nehmen auch die Jungs bei Pixar nur 64 stochastisch verteilte SubPixel zum Rendern ihrer Filme, da keiner von ihnen so schlau war wie du? ;)

[Coda]

Ein normaler Immediate Mode Renderer würde bei 4x FSAA einfach flott drüberpflügen, drei der vier Subpixel umfärben und weiterarbeiten.Das Zusammenrechnen geschieht erst beim Scanout (nVidia) oder beim Pageflip (ATi)

[Neomi]

Das Zusammenrechnen geschieht erst beim Scanout (nVidia) oder beim Pageflip (ATi)

Na sicher doch, geht ja auch nicht früher. Habe ich etwa was anderes behauptet?

Edit: ah, das "weiterarbeiten" stört dich. Natürlich meine ich nicht die Weiterverarbeitung des Pixels, sondern die Bearbeitung der nächsten Pixel (bzw. des nächsten Pixelquads).

[Coda]

Ne mich stört das "drei der vier subpixel umfärben".
Alle 4 Subpixel werden gleich behandelt und in verschiedene Buffer geschrieben.

[f!3rce1]

ich würd halt viele fallunterscheidungen machen

außerdem bei zwei kanten vom selben polyon in einem pixel würde mein programm nichts falsch machen denn es überprüft ja welche flächen übereinander liegen es macht halt folgendes:

erste kante:

-bemerkung, dass die kante von rechts 50% in den pixel reicht
-speicherung

zweite kante

-bemerkung, dass die kante von rechts 60% in den pixel reicht
-speicherung

nachüberprüfung:

- rechte kante vom polygon 0.6 im pixel linke 0.5 heißt 0.1fläche im ganzen pixel (siehe erklärung mit fläche der kante im pixel letztes posting von mir)

das gleiche gilt für die ecke in einem pixel und einem ganzen polygon im pixel:

das programm schneidet die kante ja nicht einfach ab, sondern behandelt sie auch im letzten punkt des polygons noch als kante: da kommt dann auch wieder die richtige fläche raus wenn man will sogar noch mit der position(hier zwei bildchen zur besseren erklärung):

in der berechnung ist die gesuchte fläche nichts anderes, als die fläche die sich zwischen den beiden türkisen linien befindet(dunkel blau gestreift) und damit die gesuchte dreiecksfläche. das geht aus meiner flächen erklärung hervor und kann man auch nachrechnen:
http://img68.exs.cx/img68/3323/pixel21ds.png (http://www.imageshack.us)
http://img68.exs.cx/img68/6262/pixel39iu.png (http://www.imageshack.us)

beim nächsten mal solltet ihr euch etwas mehr gedanken über das problem mahen (ist nicht bös gemeint) :)

[Neomi]

Letztendlich ändert das an dem Ergebnis aber nichts. Ob der Rasterizer den einen Subpixel gar nicht erst berechnet (ich weiß, er berechnet ihn), das Ergebnis verwirft oder ins Nirvana schreibt, ist von außen betrachtet recht egal. Der Subpixel behält seinen alten Wert, die anderen drei bekommen einen neuen zugewiesen.

Was hat die Gleichbehandlung der Subpixel eigentlich mit dem späteren Zusammenrechnen zu tun?

[Coda]

Redest du grad von einem Fall wo ein Polygon nur 3 Subpixel überdeckt? Dann reden wir sowieso aneinander vorbei.

[f!3rce1]

ich hoffe das ganze nimmt bald ein ende, entweder damit , dass ich gewonnen habe und ein chickes AA habe oder ihr einen einwand habt den ich nicht lösen kann. na dann ...

[f!3rce1]

Letztendlich ändert das an dem Ergebnis aber nichts. Ob der Rasterizer den einen Subpixel gar nicht erst berechnet (ich weiß, er berechnet ihn), das Ergebnis verwirft oder ins Nirvana schreibt, ist von außen betrachtet recht egal. Der Subpixel behält seinen alten Wert, die anderen drei bekommen einen neuen zugewiesen.

Was hat die Gleichbehandlung der Subpixel eigentlich mit dem späteren Zusammenrechnen zu tun?

ich versteh nicht genau was du damit meinst. (eigentlich habe ich davon nichts verstanden)

[Neomi]

beim nächsten mal solltet ihr euch etwas mehr gedanken über das problem mahen (ist nicht bös gemeint) :)

Ah ja. Dann erklär doch mal, wie du alleine schonmal das Problem in meinem Bild 2 angehen würdest. Du kannst die Informationen nicht im Vorfeld reduzieren, wenn du exakt arbeiten willst.

[f!3rce1]

meinst du in deinem bild 2 das problem, dass sich die ecke des polygons in einem pixel befindet oder wie?

[Neomi]

ich hoffe das ganze nimmt bald ein ende, entweder damit , dass ich gewonnen habe und ein chickes AA habe oder ihr einen einwand habt den ich nicht lösen kann. na dann ...

Die Einwände, die du nicht lösen kannst, sind massig im Thread verteilt. Jetzt mußt du nur noch erkennen, daß du sie nicht lösen kannst. ;)

@Coda:
Scheint so. Zumindest sehe ich gerade nichts, wo wir uns widersprechen.

[f!3rce1]

dann zähl mal n paar auf meiner meinung nach bleibt da nicht viel übrig oder ich hab mich nicht gut ausgdrückt

[Neomi]

meinst du in deinem bild 2 das problem, dass sich die ecke des polygons in einem pixel befindet oder wie?

Nein, das mit der Ecke ist Bild 3. Obwohl... beim Zählen beginne ich eigentlich immer bei 0...

Zuerst wird das grüne Dreieck gezeichnet, eine Kante verläuft vollständig durch den Pixel und es werden 50% von rechts aus überdeckt. Dann wird das rote Dreieck drübergezeichnet, es belegt 50% von links aus. Das sind die Informationen, die du speichern willst, sie sind identisch mit denen aus Bild 1. Und doch ist das Ergebnis unterschiedlich. Es reicht nicht aus, einfach nur zu wissen, wie weit und von welcher Seite etwas in einen Pixel ragt.

[Neomi]

dann zähl mal n paar auf meiner meinung nach bleibt da nicht viel übrig oder ich hab mich nicht gut ausgdrückt

Och bitte. Wenn ich jetzt all diese Dinge nochmal aufzähle, wirst du nochmal behaupten, daß es doch geht.

Vielleicht wäre es besser, wenn du dein Glück versuchst. Und jedesmal, wenn du glaubst, daß es funktioniert, werden wir dir mit konkreten Testfällen das Gegenteil beweisen. Allerdings brauchst du dazu die Testfunktion, die ein Bild anhand einer höher aufgelöst berechneten und dann heruntergerechneten Version verifiziert. Dazu noch ein simples Format, in dem einfache Szenen erstellt, geladen und getestet werden können.

[f!3rce1]

ok wir machen das so: ich schreib das programm sodass man beliebig viele dreiecke mit beliebigen positionen angeben kann und ihr sagt was nich geht und dann verbesser ich weiter. zudem werde ich den code preisgeben ok?

[f!3rce1]

Nein, das mit der Ecke ist Bild 3. Obwohl... beim Zählen beginne ich eigentlich immer bei 0...

Zuerst wird das grüne Dreieck gezeichnet, eine Kante verläuft vollständig durch den Pixel und es werden 50% von rechts aus überdeckt. Dann wird das rote Dreieck drübergezeichnet, es belegt 50% von links aus. Das sind die Informationen, die du speichern willst, sie sind identisch mit denen aus Bild 1. Und doch ist das Ergebnis unterschiedlich. Es reicht nicht aus, einfach nur zu wissen, wie weit und von welcher Seite etwas in einen Pixel ragt.
ich weiß echt nicht was du genau meinst wenn die informtaionen identisch sind ist das bild auch immergleich mehr informationen zum exakten zeichnen der kante im pixel, als "ystep", farbe und von welcher seite brauch ich nicht

[Coda]

Was machst du denn bitte mit einem Polygon das genau einen Pixel groß ist und eine Textur hat? Du müsstest dann ja die Textur aufsummieren für perfektes AA, wie soll das gehen?

[aths]

Was machst du denn bitte mit einem Polygon das genau einen Pixel groß ist und eine Textur hat? Du müsstest dann ja die Textur aufsummieren für perfektes AA, wie soll das gehen?Das ist Sache des Texturfilters. Aufsummiert wird beim MIP-Mapping. Hier gehts ja um Kantenantialiasing.

[Xmas]

ich glaube, dass ihr meine idee noch nicht so ganz verstanden habt.
ich will mich ja vom alpha blending lösen.
Jetzt mal halblang. Nur weil du plötzlich auf den Dreh kommst, dich vom Alpha-Blending lösen zu wollen heißt nicht dass wir deine Idee nicht verstanden hätten.


ich brauche einen neuen dynamischen buffer in dem ich für jeden pixel die information, wie weit und von welcher seite die kante in den pixel reinreicht und natürlich die farbe, speichere. und dass ich dann im nachhinein, wenn alles berechnet ist, entscheide, ob zwei kanten übereinander liegen, wieviel dann von einer kante "überguckt" oder ob sich kanten den pixel "brüderlich" teilen. dann wenn alles entschieden ist, wird der pixel, so genau wie dieses verfahren ist, gezeichnet. im spiel sollten dann fehler nicht zu erkennen sein.
Dann mach dir bitte einmal Gedanken über den exakten Aufbau jenes dynamischen Buffers, also wieviel Bit auf welche Information genau entfallen und wie du Platz für mehrere Einträge pro Pixel schaffst. Danach überlegst du dir präzise den Algorithmus, der dir aus diesen Informationen die finale Farbe eines Pixels errechnet.

Wenn du das getan hast, überlegst du dir, wie du folgende Dinge berücksichtigst:
- Alpha-Blending (mit wechselnder Blend-Operation)
- Z-Test (mit welchselndem Vergleichsoperator)
- Stencil-Op und Stencil-Test (wiederum mit wechselnden Einstellungen)
- sich schneidende Polygone
- mehr Polygone, als dein Buffer Platz bietet


ich würde bei solch "perfekt" geglätteten kanten auch das bisschen leistungsverlust eingehen, falls da überhaupt so viel leistung verloren geht.
Das würde kaum einer anders sehen. Nur glaube ich, dass du die Konsequenzen diverser Eingriffe in die Grafikpipeline massiv unterschätzt.


oder so:

ich lege vier sub pixel an. in jedem wird dann nicht nur die farbe gespeichert sondern auch der wert wie viel die kante im pixel "steckt". dann werden pro polygon die werte neu aufeinander gerechnen bis dann am ende die farbe des subpixels feststeht und mit den anderen sub pixeln verechnet wird.
Ich würde dich bitten, Methoden und Algorithmen präziser zu beschreiben. Ich kann mit der obigen Beschreibung nichts anfangen, nicht weil ich die Worte nicht verstehen würde sondern weil das mehrdeutig ist und Informationen fehlen.

[aths]

dann zähl mal n paar auf meiner meinung nach bleibt da nicht viel übrig oder ich hab mich nicht gut ausgdrücktDu speicherst bei der Bedeckungsinformation bereits gerenderter Dreiecke nicht (zumindest nicht exakt) die Position.

[f!3rce1]

mein AA sollte nicht für irgend welche komplexe 3d kreieranwedungen sein sondern für spiele und da würde es nicht auffallen, dass ein pixel in dem sich mehrere polygone aufhalten eine falsche farbe hat und das interessiert einen zocker auch kaum. im gesamtbild ist nur noch auffällig, dass keine Stufen mehr zu sehen sind.

die einzigen fehler die das AA noch hätte wären der wo mehr als 2 polygone in einem pixel sind und selbst dann fällt das in einem spiel nicht auf weil das ganze zumindest noch "halb" richtig berechnet wird.
also, dass der pixel nicht rot ist, obwohl er blau sein sollte.

[Coda]

Das ist Sache des Texturfilters. Aufsummiert wird beim MIP-Mapping. Hier gehts ja um Kantenantialiasing.Und wenn kein Mipmapping aktiv ist? "Perfektes" AA würde das nämlich unnötig machen. Und genau das ist ja sein Anspruch...

[f!3rce1]

ich glaub ich hab das ganze in eines falsches thema geschrieben. ich habe eigentlich nicht vor perfektes AA zu machen, sondern ein AA was in !Spielen! die Kanten vollkommen eliminiert. das würde nämlich bei meinem algorithmus passieren. die Fälle die ihr beschrieben habt (NICHT ALLE) sind extremfälle die für ein spiel völlig unrelevant sind. es ist doch schwachsinnig zu erwarten, dass das AA für so einen fall, in dem 20 polygone in einem pixel sind, noch eine richtige berechnung zu erwarten. das supersampling würde das genausowenig genau machen können, mit nur einer handvoll subpixeln.

[f!3rce1]

... und die fälle die für spiele relevant sind habe ich, wie schon etwas früher erklärt, schon gemeistert.

[aths]

Und wenn kein Mipmapping aktiv ist? "Perfektes" AA würde das nämlich unnötig machen. Und genau das ist ja sein Anspruch...Texturfilter und Kanten-Antialiasing möchte ich getrennt wissen. Warum sollte kein MIP-Mapping aktiviert sein? Zur Not kann man MIP-Mapping via Treiber erzwingen (wenn der Treiber das vorsieht.)

Das Topic hier ist "Echtes Kantenantialiasing", da ist es imo eine Spitzfindigkeit, nach Belangen des Texturfilters zu fragen.

[aths]

ich glaub ich hab das ganze in eines falsches thema geschrieben. ich habe eigentlich nicht vor perfektes AA zu machen, sondern ein AA was in !Spielen! die Kanten vollkommen eliminiert. das würde nämlich bei meinem algorithmus passieren. die Fälle die ihr beschrieben habt (NICHT ALLE) sind extremfälle die für ein spiel völlig unrelevant sind.Irrelevant sind die Dinge nicht, dazu gleich mehr ...

es ist doch schwachsinnig zu erwarten, dass das AA für so einen fall, in dem 20 polygone in einem pixel sind, noch eine richtige berechnung zu erwarten. das supersampling würde das genausowenig genau machen können, mit nur einer handvoll subpixeln.Da hast du Recht. "Echtes" Kantenantialiasing müsste das aber bringen.

... und die fälle die für spiele relevant sind habe ich, wie schon etwas früher erklärt, schon gemeistert.Dein Verfahren, was von der Idee so neu nicht ist, liefert in bestimmten Umständen glatte Kanten.

Doch du übersiehst die Problemfälle. Die sind nicht nur darin zu suchen, dass sich in einem Pixel 20 Dreiecke befinden könnten, denn das ist in der Tat ein äußerst unwahrscheinliches Szenario. Bei deiner Methode verlierst du jedoch einen Teil der Bedeckungsinformation. Multisampling hingegen speichert – im Rahmen seine Subpixelauflösung – die Bedeckungsinformation.

Hier noch mal die Kriterien, die dein Verfahren erfüllen müsste, um Chancen zu haben je angewendet zu werden:

- Kantenglättung ohne Artefakte unabhängig von der Render-Reihenfolge der Polygone.

- Funktionieren auch beim Einsatz von Alphablending.

- Realisierbar mit vergleichsweise geringem Hardware-Aufwand.

[Xmas]

... und die fälle die für spiele relevant sind habe ich, wie schon etwas früher erklärt, schon gemeistert.
Mit welchem Algorithmus jetzt? Der mit dem Alpha-Blending oder der mit dem "dynamischen Buffer" oder anderes?
Der mit dem Alpha-Blending ist weder neu noch in Spielen wirklich brauchbar. Warum, habe ich vorher schon einmal geschrieben.
Einen anderen Algorithmus müsstest du erst mal etwas genauer beschreiben, damit man sagen kann ob er was taugt.

[Neomi]

... und die fälle die für spiele relevant sind habe ich, wie schon etwas früher erklärt, schon gemeistert.

Die Probleme, die mit Extremfällen so schön gezeigt werden können, treten ständig auf, für Spiele relevant sind sie alle. Ja, du hast schon mehrfach erklärt, daß du diese Probleme gemeistert hättest. Nein, du hast sie nichtmal ansatzweise gemeistert. Und daß du Fehler bei der Berechnung in Kauf nehmen willst, paßt auch absolut nicht zum Anspruch eines "perfekten" Antialiasing.

[DocEW]

Kannst du nicht mal so einen richtig großen (>=1024x768) Screenshot posten? Auf diesen mini-Teilen sieht man irgendwie nicht so viel...

[f!3rce1]

sry, dass ich lang nicht on war

so ich nochmal alles durch überlegt und bin zum schluß gekommen, dass das mit dem dynamischen puffer zwar sehr gut funktioniert aber der rechenaufwand zu groß ist, da der Arbeits speicher immer neu eingeteilt werden muss (bei jedem Pixel!!).

ich hab was viel besseres:

man sollte alles nicht mit subpixeln machen, sondern mit Sublinien die dynamisch in flächen eingeteilt werden!!

da gibt es keine probleme mit speicher, alphablending, mehreren polygonen im pixel oder z werten!!

und das funktionniert wunderbar mit dem edges-Antialiasing

ich taufe dieses AA auf Subline-Edge-Antialiasing
(falls es die idee nicht schon gibt...)

ich hab es schon fast fertig, das problem ist nur, dass man ziemlich den kopf braucht um das im code umzusetzen wegen position sortierungen und der dynamik die erhalten bleiben soll.

der Vorteil ist, dass man in Richtung der Scanlines höchst genaue berechnungen hat und selbst entgegen den scanlines kaum sichtbare abstufungen hat. es werden zu genauen berechnungen nicht mehr als 3 lines benötigt.

ein Nachteil könnte sein, dass man nicht unendlich viele Kantenabschnitte innerhalb einer Line speichern kann. diese zahl muss man festlegen. ich denke, dass 4 Abstufungen in Spielen ausreichen. d.h. 4 Polygonkanten pro Sublinie. (denn wenn ein Teil durch ein Polygon völlig verdeckt wird kann man seinen abschnitt wieder freigeben!)

ich hab noch eine frage: wie groß sollte ein Puffer höchstens sein und viel wird bei SSAA benötigt? sind 25mb zuviel?

wenn einer das Prinzip nicht verstanden hat kann er ruhig nachfragen ich versuchs dann mit bildchen.

[Gast]

Kannst du nicht mal so einen richtig großen (>=1024x768) Screenshot posten? Auf diesen mini-Teilen sieht man irgendwie nicht so viel...


tja weil die pixel nicht mehr so auffallen... ;)

[f!3rce1]

ein Nachteil könnte sein, dass man nicht unendlich viele Kantenabschnitte innerhalb einer Line speichern kann. diese zahl muss man festlegen. ich denke, dass 4 Abstufungen in Spielen ausreichen. d.h. 4 Polygonkanten pro Sublinie. (denn wenn ein Teil durch ein Polygon völlig verdeckt wird kann man seinen abschnitt wieder freigeben!)


ich denke das Problem mit dem speicher kann man noch so beheben, dass die sublines nicht für jeden Pixel existieren sondern nur entlang der polygon kanten (also ein kleinerer nebenpuffer der dann den pixel zugeordnet wird, dann könnte man sogar noch mehr abschnitte einteilen).(es werden nämlich nur ca 10% der eigentlichen sublines benötigt, nicht wie beim SSAA)

[Xmas]

sry, dass ich lang nicht on war

so ich nochmal alles durch überlegt und bin zum schluß gekommen, dass das mit dem dynamischen puffer zwar sehr gut funktioniert aber der rechenaufwand zu groß ist, da der Arbeits speicher immer neu eingeteilt werden muss (bei jedem Pixel!!).
Wenn der Rechenaufwand zu groß ist, wie kann es dann "gut funktionieren"?

ich hab noch eine frage: wie groß sollte ein Puffer höchstens sein und viel wird bei SSAA benötigt? sind 25mb zuviel?
Das hängt von der Auflösung ab. Grob gesagt, 32 Byte pro Pixel für Farbe und Z-Wert sind noch akzeptabel.

wenn einer das Prinzip nicht verstanden hat kann er ruhig nachfragen ich versuchs dann mit bildchen.
Ich bitte darum, aber bitte weniger schwammig als "Sublinien die dynamisch in flächen eingeteilt werden".

[f!3rce1]

also...

bei der berechnung der kanten hat man nach besenham die information wieviel die kante im pixel "steckt".
diese information mache ich mir zunutze indem ich ein pixel in mehrere "unterlinien" einteile. die können dann eine einstellbare menge an positionen aufnehmen, also die position der kante.
undfähr so ist die der puffer dann eingeteilt:

(vb6):

private type typsubline
. pos(3) as byte
. rgb(4) long
. z(4) long oder single? (ich weiß nicht wie z ausehen muss)
. alpha(4) long
end type
private type typpixel
. subline(2) as typsubline
end type
dim pixel(800, 600) as typpixel

also: der pos array speichert die einzelnen positionen der kante , dadurch entsehen sozusagen flächen(wenn man eine pos hat ist links dieser pos eine fläche und rechts eine fläche (deshalb 3 pos variablen und 4 von den anderen variablen))

http://img218.echo.cx/img218/7886/pos1lh.png (http://www.imageshack.us)

jetzt muss beim rendern nur noch in z reihen folge sortiert werden und dann kann alles aufeinander in die sublines gespeichert werden wie der rest ist wie bei den subpixeln außer, dass am ende die farbe des pixel anders errechnet werden muss also ungefähr so:

farbe = (1/anzahlsubline)*fläche*farbe

ich hoffe, dass ich das gut genug erklärt hab. das ganze ist auch schwierig zu erklären.

[f!3rce1]

hallo ? habt ihr jetzt keine lust mehr oder wie? -.-

[Coda]

Nein, aber falls sich deine Methode nicht im Ansatz geändert hat wird sie nie funktioneren, bzw nur Nachteile mit sich bringen gegenüber Multisampling :rolleyes:

[f!3rce1]

wie kommts du darauf ??

[Xmas]

private type typsubline
. pos(3) as byte
. rgb(4) long
. z(4) long oder single? (ich weiß nicht wie z ausehen muss)
. alpha(4) long
end type
private type typpixel
. subline(2) as typsubline
end type
dim pixel(800, 600) as typpixel

also: der pos array speichert die einzelnen positionen der kante , dadurch entsehen sozusagen flächen(wenn man eine pos hat ist links dieser pos eine fläche und rechts eine fläche (deshalb 3 pos variablen und 4 von den anderen variablen))
Alpha ist Teil der Pixelfarbe, also RGBA. Z sind mindestens 24 bit, dann brauchst du noch 8 bit Stencil.
Allerdings:
Position ist ein Kantenattribut (Anfang und Ende sind aber immer bei 0 bzw. 1, deswegen kann man die weglassen)
RGBA und Stencil sind Flächenattribute
Z ist ein Kantenattribut

Wenn du das berücksichtigst, hast du aber schon 38 Byte pro Sublinie. Nimmst du deren 3 (wieso hast du oben 2, aber im Bild 3?), bist du schon bei 114 Byte pro Pixel.
Das ist mehr als bei 14x Multi- bzw. Supersampling. Da musst du dir schon eine effektive Speichermethode einfallen lassen...

Offensichtlich bietest du ja Platz für 3 Kanten in einem Pixel. Was passiert, wenn es mehr werden? Wie wird eine Polygonecke interpretiert? Was ist, wenn die Kante von Rechts nach Links läuft? Von Unten nach einer Seite?

Ich wiederhole mich ungern, aber:
Dann mach dir bitte einmal Gedanken über den exakten Aufbau jenes dynamischen Buffers, also wieviel Bit auf welche Information genau entfallen und wie du Platz für mehrere Einträge pro Pixel schaffst. Danach überlegst du dir präzise den Algorithmus, der dir aus diesen Informationen die finale Farbe eines Pixels errechnet.

Wenn du das getan hast, überlegst du dir, wie du folgende Dinge berücksichtigst:
- Alpha-Blending (mit wechselnder Blend-Operation)
- Z-Test (mit welchselndem Vergleichsoperator)
- Stencil-Op und Stencil-Test (wiederum mit wechselnden Einstellungen)
- sich schneidende Polygone
- mehr Polygone, als dein Buffer Platz bietet
Wenn du das getan hast, dann hast du vielleicht einen robusten Algorithmus entworfen.

jetzt muss beim rendern nur noch in z reihen folge sortiert werden
Das wäre schon absolutes K.O.-Kriterium. Aber wieso sollte man sortiert rendern?

[Neomi]

wie kommts du darauf ??

Es ist schon längst kein arithmetisches Antialiasing mehr, die von dir angestrebte Genauigkeit existiert also nichtmal mehr in deinem Plan. Dadurch, daß du weiterhin nur reduzierte Daten speicherst und diese interpretieren mußt, wirst du Fehler haben, die bei einer exakten Auswertung diskreter Punkte nicht auftreten können. Immerhin können viele verschiedene Situationen zu einer identischen reduzierten Speicherung führen.

Mit drei Linien, die sich in vier Abschnitte unterteilen lassen, bist du in jeder Hinsicht herkömmlichen 16x FSAA unterlegen. Du erreichst nicht annähernd die Geschwindigkeit und nicht ganz die Genauigkeit, stattdessen hast du je nach Szene noch ein paar kleine Grafikfehler drin.

[f!3rce1]

das kann ich mir nicht vorstellen denn adadurch dass die abschnitte je nach position der kante eingeteilt werden is die genauigkeit um einiges höher als es bei ss überhaupt sein kann