Diskussion zum Artikel "Matrox Parhelia: Anti-Aliasing Qualitätstests"

[Leonidas]

Matrox Parhelia: Anti-Aliasing Qualitätstests
http://www.3dcenter.org/artikel/parhelia_aatest/



Update 8. Juli 2002, 12 Uhr 45: Wir haben alle bisherigen Bilder durch welche mit leicht gekippter Y-Achse ersetzt, um so die Glättung bzw. Nicht-Glättung einer Kante besser zeigen zu können.

[Quasar]

*arrrgh!!*

[Quasar]

Tja, was soll man da noch groß zu sagen: q.e.e.

Wenn eine Kante geglättet wird, dann richtig. Mich würde mal der direkte Vergleich zum SuperSceneAA der Wildcat III interessieren. Meinst du, 3dlabs könnte dir so ein Teil mal ausborgen, Leo? ;)

Ehrlich gesagt wäre für mich aber Screenshots aus Games zur Vervollständigung wünschenswert, da ich diese schließlich spiele und nicht das Reef-Demo oder Demirugs AA-Tester. ;)

Also bitte Screenies èn Masse aus vielen Games, müssen ja nicht unbedingt benchmarkfähig sein, nur screenshotfähig :D

[2B-Maverick]

Das AA der Matrox Karten erscheint zwar deutlich besser, ABER schaut euch mal die Dreiecks-Spitzen an!
z.B. pic 02 und pic08:
Dort sind bei den Matrox-Bildern die Dreiecke augenscheinlich nicht mehr gleich hoch! Bei der schlechteren Qualtität der NVidia-Karten jedoch wenigstens "korrekt" gezeichnet.

Oder habe ICH hier nen Knick in der Pupille?

CU
Markus

[Demirug]

@2B-Maverick:

Nein du hast keinen Knick in der Pupille. Das ist in beiden Fällen die Schnittline zwischen den beiden Flächen die bei Matrox fehlt. Dadurch entsteht der Eindruck das das schwarze Dreieck kleiner (höhe)ist.

[mictasm]

Und später ist dann das weisse kleiner.

Die Kantenglättung ist wirklich unglaublich gut. Dass es einen Unterschied zwischen den GF4 und der Parhelia gibt, ist klar (im Test "glättungswürdig"). Die GF bearbeitet ja das ganze Bild. Es hat aber immer den Anschein, als wenn die GF eher einen Weichzeichner einsetzt. Die P-Bilder sind sehr viel schärfer.

Das würde ich gerne in aktuellen Spielen sehen.

Hmm, bisher sind die Tests nicht so, dass ich unbedingt die Parhelia vorbestellen will. Ich warte da lieber noch ab...

MIC

[Frank]

Originally posted by Quasar
q.e.e.

???

zum Thema:
dass die senkrechte Kante nicht geglättet wird, seh ich persönlich nicht mal als Verlust. Wohl eher vorteile, das da Kontrast, wo das laufkantentypisch auch nicht stört, erhalten bleibt.

[nggalai]

Originally posted by Frank
q.e.e.

???
Quod Erat Expectandum. ;)

Zum Thema: Danke für den Artikel, Leo. Ich bin mir aber noch nicht so sicher, ob er was "gebracht" hat, i.e. ob sich daraus interessante Schlüsse ziehen lassen. Hmm. Vielleicht muss ich einfach mehr drüber nachdenken . . .

ta,
-Sascha.rb

[Exxtreme]

Originally posted by nggalai
Quod Erat Expectandum. ;)

???
Isch nix schprechen lateinisch(?).

Gruß
Alex

[nggalai]

Originally posted by Exxtreme

???
Isch nix schprechen lateinisch(?).

Gruß
Alex "was zu erwarten war" -> "wie nicht anders erwartet."

In Anlehnung an's logische/mathematische QED: quod erat demonstrandum = "was zu beweisen war."

ta,
-Sascha.rb

[Exxtreme]

Thanks. Werde ich mir merken.
;)

Gruß
Alex

[der-Leo]

das FAA der parhelia funktioniert doch ganz einfach.
es erkennt nur die aussenkanten von polygonen.
schnittlinien erkennt es nicht!
eine aussenkante ist relativ einfach zu bestimmen.
eine schnittlinie ist deutlich schwerer zu "erkennen".
deswegen werden diese von der parhelia nicht erkannt und nicht geglättet!
das ganze per treiber zu lösen ist wohl viel zu umständlich und aufwendig.
deswegen wird matrox daran wohl auf dauer auch nichts ändern (können).
dass das faa von matrox nebenbei auch probleme mit alphablending hat macht das ganze nicht besser.

ein screenshot auf einer parhelia wir NIE 100%ig geglättete kanten aufweisen können
WENN sich irgendwo polygone (sichtbar) schneiden oder wenn irgendein polygon (mit sichtbarer kante) durchscheinend ist!

d-L

[Demirug]

@der-Leo:

Das ist auch meine Vermutung seit ich die Whitepapers zu FAA gelesen habe. Allerdings ist es noch nicht zu 100% sicher das es wirklich so ist da die notwendigkeit der Glättung der Schnittkante in den Shots ja umstritten ist. Da die Schnittline aber genau in der mitte der Pixel liegt ist IMO eine Glättung notwendig da man ja jeweils einen halben schwarzen und einen halben weisen Pixel sehen würde was dann grau (wie bei der GF4) ergibt.

[aths]

Originally posted by mictasm
Die GF bearbeitet ja das ganze Bild. Es hat aber immer den Anschein, als wenn die GF eher einen Weichzeichner einsetzt. Die P-Bilder sind sehr viel schärfer.Das ist tatsächlich nur Schein. Parhelia berechnet die Kanten intern deutlich höher aufgelöst als GeForce, insofern sind die Kanten schärfer. Dass allerdings die Mittelachsenkante nicht geglättet wird, ist nicht korrekt. Die GeForce verwendet in diesem Beispiel keinerlei Weichzeichner, dieses Märchen wurde vom Matrox-Marketing in die Welt gesetzt. Die GeForce verwendet nur bei Quincunx einen Weichzeichner, außerdem behandelt eine GeForce3/4 ebenfalls nur die Kanten. (Ausnahme ist wie gesagt Quincunx, wo das gesamte Bild durch einen Unschärfefilter behandelt wird.)

[ow]

Zur Schnittkante:


Ich stimme hier mit 'der-Leo' überein. Als 'falsche' Kante wird sie nicht geglättet. Leider.

Allerdings stellt sich auch die Frage, ob in realen Szenen wirklich (viele) solcher Schnittkanten vorkommen. Das Objekte sich durchdringen ist IMO doch eher selten der Fall, oder?


@Demirug:

Welchen Z-Buffer Tiefe nutzt das Programm? AUf meiner Radeon sind Fehler zu sehen an dieser Schnittkante. Z-Fehler?

[ow]

Ach ja, um Missverständnissen vorzubeugen:
Sobald man min. 2xAA aktiviert ist die Kante glatt auf der Radeon:

[Demirug]

@ow:

Sind Z-Fehler. War zu faul die verfügbarkeit der Z-Formate zu prüfen. Wenn es unbedingt sein muss bau ichs noch ein.

[ow]

Aber wieso verschwinden die komplett bei 2x Supersampling FSAA? Leuchtet mir nicht ganz ein. Das Bild wird soch nur intern höher augelöst berechnet und dann runterskaliert. Dann müssten die Fehler doch immer noch sichtbar sein?

Oder ändert sich 'zufällig' die Z-Buffer Tiefe bei einschalten von FSAA?

[Demirug]

Originally posted by ow
Aber wieso verschwinden die komplett bei 2x Supersampling FSAA? Leuchtet mir nicht ganz ein. Das Bild wird soch nur intern höher augelöst berechnet und dann runterskaliert. Dann müssten die Fehler doch immer noch sichtbar sein?

Oder ändert sich 'zufällig' die Z-Buffer Tiefe bei einschalten von FSAA?

Die Z-Buffer Tiefe ist im Moment immer 16 Bit. Da die Fehler ja nur in der Richtung des 2*FSAA liegen und nicht so breit sind dürfte das AA ausreichen um die Löcher zu schliessen. Du könnstet höchstens prüfen ob das grau einheitlich ist.

[ow]

Originally posted by Demirug


Du könnstet höchstens prüfen ob das grau einheitlich ist.


Das ist es IMO.
Selbst bei 15-facher Vergrösserung nichts zu erkennen ausser glatter schwarzer Kante.

Aber das ist jetzt OT. Werd später meine MX und kyro mal auf das Prog loslassen.

[Pussycat]

@Demirug:

Ändere mal das Programm so, dass die Pyramide etwas schief steht. Dann ist die Kante 'glättungswürdig' und wäre deutlich ob er die Kante 'vergisst' oder sie als nicht nötig einstuft in der jetzigen Situation.

[Demirug]

@Pussycat:

Ist schon seit heute morgen gemacht. Leonidas hat es schon zum testen bekommen. Ergebnisse wird er wohl irgendwann bekannt gegeben.

Edit: Ist jetzt Online.

[Birdman]

Originally posted by ow
Allerdings stellt sich auch die Frage, ob in realen Szenen wirklich (viele) solcher Schnittkanten vorkommen. Das Objekte sich durchdringen ist IMO doch eher selten der Fall, oder?

Also ich habe selber schon einige Q3maps im radiant erstellt und diverse andere angekukkt, und solche schnittstellen kommen doch noch recht häufig vor......kann sein dass dies bei andern engines/levelbuilders anders iss, aber ganz minimieren lässt sich das wohl nicht.

[Demirug]

@Birdman:

Je mehr Zeit man sich läst um so besser bekommt man diese Überschneidungen heraus. Ganz wird man sie aber nie vermeiden können. Gerade wenn Objekte zusammen animiert sind nimmt man gerne kleine überscheidungen in Kauf um auf jeden Fall zu verhindern das es Löcher gibt. Die Überschneidungen beseitigt ja der Z-Buffer aber Löcher sieht man sofort. Und wenn ich mir die neuen Werkzeuge zum Leveldesign so anschaue gehe ich davon aus das die Überschneidungen eher zunehmen werden.

[Leonidas]

Das Pic14 ist wohl das beste zur Illustration dessen (Zoom 200%):

Die GF4Ti hat aufgrund des spitzen Winkels einige Probleme mit der Glättung der vorderen weißen Kante. Die Parhelia bekommt dies wesentlich besser hin, dafür glättet sie den Scheitelpunkt der beiden Dreiecke gar nicht.

[Quasar]

Komisch, die Baseline des weissen Dreiecks sieht für mich ziemlich gleich geglättet aus...16=4??

[mirp]

Man könnte doch einfach mal die beiden Dreiecke durch jeweils zwei simulieren, so dass die Schnittlinie auf eine reale Kante fällt.

Es wäre mal interessant zu sehen, ob die Parhelia diese Kante dann als glättungswürdig erachtet.

[Unregistered]

Schaut so aus, als ob die Parhelia die Kantenglättung nur aufgrund der Polygonkanten einschaltet, und nicht den Z-Buffer checked, um
die Kantenglättung ein, bzw. auszuschalten.
Anscheinend ist es nur eine einfache Pipeline, die nur die Informationen des Vertex-Shaders für die Kantenglättung zu rate zieht und den Z-buffer, der ja überschneidende Polygone entdecken würde, außen vor lässt.

[Demirug]

Mit einem normalen Z-Buffer hätte man gar keine Möglichkeit die Überschneidung zu entdecken. Laut dem Whitepaper von Matrox werden ja nur AA Samples für Punkte erzeugt welche geglättet werden sollen. Ob dabei pro Sample überhaupt Z-Werte erzeugt werden geht leider nicht klar aus dem Dokument hervor. Aber selbst wenn dem so wäre würde das in dieser Situation nichts nützen da ja beim Rendern des ersten Dreiecks der Chip auf keinen Fall über die Information verfügt an welchen Pixeln später das zweite Dreieck schneidet.

Die einzige möglichkeit diese Problem in den Griff zu bekommen ist zusätzlich zum normalen Z-Wert entweder zwei vektoren welche die räumliche Lage des Pixel beschreiben oder zwei zusätzliche Z Werte für 2 nicht gegenüberliegende Ecken des Pixels mitzuspeichern. Diese Information müsste dann bei der FAA Prüfung zusätzlich herangezogen werden um ein teilweises Überscheinden von altem und neuem Pixel festzustellen sowie die AA Samples des alten Punktes nachträglich zu erzeugen. Diese Technik setzt allerdings vorraus das für jedes AA Sample auch ein Z-Wert gespeichert wird.

[Xmas]

Originally posted by Quasar
Komisch, die Baseline des weissen Dreiecks sieht für mich ziemlich gleich geglättet aus...16=4??
Parhelia ist hier noch ganz leicht besser. Aber glatter als glatt geht nun mal nicht. Bei einer 45°-Kante gibt es z.B. immer nur maximal zwei verschiedene Intensitäten (festes Raster vorausgesetzt). Die Anzahl der Samples entscheidet dann nur noch darüber, ob die Kante sich in 1/2 oder 1/4 Pixel-Schritten bewegen lässt.

[Frank]

Zwischen dem weissen und schwarzen Dreieck tut meine GF3Ti teilweise auch nichts dergleichen für AA. Also die senkrechte Kante:

[aths]

Originally posted by Frank
Zwischen dem weissen und schwarzen Dreieck tut meine GF3Ti teilweise auch nichts dergleichen für AA. Also die senkrechte Kante: Liegt dann an der Subpixelanordnung. GF3 testet ja Mitte und links oben, GF4 testet "Ein bisschen links oben" und "ein bisschen rechts unten".

[Nullpointer]

Per Kanten-Antialias lassen sich nicht alle Kanten in den Griff kriegen. Ohne Anspruch auf Vollständigkeit hier ein paar Kantenursachen:

- Dreieckskanten: werden von Parhelia (meistens...) korrekt geglättet.

- Schnittkanten (wenn 2 Dreiecke einander schneiden): werden anscheinend nicht geglättet; das Feststellen von Schnittkanten in einer Szene mit 100000 Dreiecken müsste per Software erfolgen und wäre sehr aufwändig. Deshalb kann man hier getrost von einer Schwäche des Verfahrens reden.

"Nearest"-Texturfilterung / Alpha Test: Transparenzen haben eckige Kanten bei diesen Verfahren; der Baum in http://www.3dcenter.org/artikel/parhelia_firstlook/screenshot_geforce4ti_aa04_ultima9.php
ist ein Beispiel dafür (dieser Screenshot stammt wie der Name schon sagt von einer Geforce4, der Parhelia-Screenshot sieht ganz danach aus als ob die Treiberprogrammierer da ein wenig rumtricksen: http://www.3dcenter.org/artikel/parhelia_firstlook/screenshot_parhelia_aa16_ultima9.php ). Dieses Verfahren wird in vielen Spielen eingesetzt, um Texturen mit Löchern auch dann scharf aussehen zu lassen, wenn der Spieler nah dran ist; weiterer Vorteil gegenüber weichen Kanten ist, dass solche Texturen nicht vorsortiert werden müssen, da ja keine Halbtransparenzen vorkommen. Da hier massenweise und zudem noch gekrümmte Kanten vorliegen hat die Parhelia keine Chance :) also kann man auch hier ebenfalls von einer Schwäche des Verfahrens sprechen.

[ow]

Hmm... bei den gezeigten Ultima9 Screenshots macht mir die zb. den rechten Turm umlaufende Kante (knapp über Baumhöhe) mehr Sorgen.

Auch die Kante unterhalb von "4127tpf" ist nicht korrekt dargestellt.

[Xmas]

Kann es sein dass der Parhelia-Screenshot falsch beschriftet ist oder find ich da einfach nur keine Kante die überhaupt geglättet ist?
Also bei diesen beiden Screens ist die GF4 um Längen besser.

[Quasar]

Guter Punkt Xmas, aber ein paar Kanten sehen schon AA'ed aus. Besonders die Aussenumrisse der ansonsten nicht so hübschen Bäume gegen den blauen Himmel sind schön glatt, mit dem Turm im Hintergrund werden sie jedoch nicht behandelt.

[Thowe]

Originally posted by Quasar
Guter Punkt Xmas, aber ein paar Kanten sehen schon AA'ed aus. Besonders die Aussenumrisse der ansonsten nicht so hübschen Bäume gegen den blauen Himmel sind schön glatt, mit dem Turm im Hintergrund werden sie jedoch nicht behandelt.

Ähh, du beziehst dich jetzt auf Morrowind (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=318494#post318190), oder?

[Xmas]

Originally posted by Thowe
Ähh, du beziehst dich jetzt auf Morrowind (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=318494#post318190), oder?
Nein, er meint durchaus den U9-Shot, insbesondere der eine Baum/Busch rechts im Vordergrund. Interessant ist, dass tatsächlich der Rand der Blätter mit der Himmeltextur geglättet wird.

Allerdings habe ich die Befürchtung, dass es dafür keinen "Bugfix" gibt.

[Thowe]

*schäm* Hatte das Posting von Nullpointer gar nicht gesehen, naja. Aber auch bei Morrowind ist einiges auffällig.

[Demirug]

@Nullpointer:

"Schnittkanten (wenn 2 Dreiecke einander schneiden): werden anscheinend nicht geglättet; das Feststellen von Schnittkanten in einer Szene mit 100000 Dreiecken müsste per Software erfolgen und wäre sehr aufwändig. Deshalb kann man hier getrost von einer Schwäche des Verfahrens reden."

Ich kann dir da nicht ganz zustimmen. Diese Feststellung läst sich sehr wohl in der Hardware durchführen. Es würden dafür zwar ein paar transitoren mehr benötigt und auch etwas mehr Bandbreite aber machbar wäre das ganze schon und es wäre immer noch günstiger als die "normale" AA Verfahren.

[Demirug]

Mittlerweile haben wir es sogar bis zum MURC geschafft:

http://forums.matroxusers.com/showthread.php?threadid=34521

[Unregistered]

In diesem Forum lese ich eigentlich nichts und habe auch jetzt nicht die Zeit dazu. Aber die Artikel auf dieser Seite finde ich immer sehr interessant. Also nicht böse sein, falls jemand das schon geschrieben hat... ;)

Bei der Betrachtung der Bilder wird sehr schnell klar, wo der "Fehler" liegt.
Alle Kanten der Dreiecke werden geglättet, aber nur die Kanten zwischen den Eckpunkten der Dreiecke. Beim Rastern werden diese Kanten als solche erkannt, an den Fragmentbuffer geschickt und geglättet.
Die Kanten, die nicht geglättet werden, entstehen erst später. Genau dann, wenn die Pixel im Inneren eines Dreiecks durch den Z-Test fallen. Zu dem Zeitpunkt kann nicht mehr gefiltert werden, weil der Z-Buffer anders als beim Super-Sampling nur für die dargestellte Auflösung im Speicher ist. Zum Glätten müßten alle 16 Z-Werte der Sub-Pixel zum Vergleich herangezogen werden, das widerspricht dem Ansatz des FAA allerdings völlig.

Es handelt sich um ein Hardware-Problem, das nicht durch Treiber zu beheben ist.
Wenn ich falsch liege (durchaus möglich, aber die Theorie ist plausibel), dann müßte es auch ungeglättete Kanten geben, die nicht durch eine Überschneidung von Dreiecken zustandekommen. Oder es müßte geglättete Kanten geben, die erst durch die Überschneidung zustandekommen und nicht am Rande des eigentlichen Dreiecks liegen.
Solange nur wirklich saubere, solide Geometrie vorhanden ist, müßte FAA korrekte Ergebnisse liefern. Wenn es in einem Spiel allerdings Clippingfehler gibt, werden genau die Stellen Probleme machen.