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

[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]

Zitat:

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.

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]

Zitat:

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]

Zitat:

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".

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/parh...04_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/parh...16_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]

Zitat:

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, oder?

[Xmas]

Zitat:

Originally posted by Thowe
Ähh, du beziehst dich jetzt auf Morrowind, 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.