Zum 3DCenter Forum
Inhalt




Multisampling Anti-Aliasing unter der Lupe

22. Mai 2003 / von aths / Seite 6 von 8


   Alternative Multisampling-Verfahren und ihre Probleme

Matrox versuchte mit der Parhelia einen eigenen Weg zu gehen und erfand das so genannte "Fragment Anti-Aliasing". Eine "Color Compression" ist quasi schon eingebaut, gespart wird zusätzlich bei der Z-Füllrate- und Bandbreite. Das Problem der nicht geglätteten Schnittkanten wurde schon angesprochen. Auf der anderen Seite wird an Außenkanten recht gute Qualität geboten, da eine 4x4-Maske zum Einsatz kommt. Dies ist allerdings auch schon wieder mit Kanonen auf Spatzen geschossen, da man bei effizienterer Anordnung mit deutlich weniger Subpixeln eine fast genau so gute Glättung erreichen kann. Zudem ist der Speicher für Anti-Aliasing-Samples begrenzt (für durchgehendes 16x AA ist einsichtigerweise kein RAM vorhanden) was dazu führen kann, dass die restlichen Außenkanten nicht mehr geglättet werden können.

Erlauben wir uns noch einen kleinen Ausblick. Da "Framebuffer Compression" wie schon gesagt keinen Speicher, sondern nur Bandbreite spart, sind AA-Modi mit vielen Subpixeln sehr RAM-intensiv. Die Matrox-Lösung funktioniert nur bis zu einem bestimmten Anteil an AA-Samples pro Frame, danach ist Schicht.

Um das in den Griff zu bekommen, wurde ein Verfahren namens Z3-Anti-Aliasing erdacht. Dieses speichert pro Pixel die Farben von beispielsweise bis zu 3 Dreiecken, es gibt also pro Pixel 3 "Slots", die je eine Farbe speichern und ebenfalls vermerken, für wie viele Subpixel die Farbe gilt. Bei zusätzlichen Subtexeln findet "on the fly" eine Farbmischung statt. Probleme gibt es hier, wenn mehr als 3 Subtexel in ein Pixel kommen. Das heißt ja auch, dass mehr als 3 Dreiecke ihre Farbe beisteuern, was den Umgang mit den Z-Werten erschwert.

Z3-Anti-Aliasing speichert nicht pro Subpixel einen Z-Wert, sondern nur pro Dreieck, welches im Pixel liegt. Zusätzlich wird eine Maske gespeichert die angibt, welche Subpixel das Dreieck bedeckt, also für welche Subpixel die Dreiecks-Farbe denn nun gilt, und es wird eine Richtungs-Angabe für die Z-Werte gespeichert, so dass sich die Z-Werte der restlichen Subpixel die das Dreieck bedeckt, rekonstruieren lassen. Kommt ein viertes Dreieck in das Pixel, gerät das Verfahren an seine Grenze. Das Resultat sind also hier und da etwas ungenauere Farbwerte an Kanten, dafür spart man erheblich RAM. In Consumer Hardware ist dieses Verfahren bislang nicht implementiert.

Alle diese Probleme sind übrigens mit einem Schlag zu lösen, sofern Tile Based Deferred Rendering zum Einsatz kommt. Dank Multisampling spart man bekanntlich viel Texel-Füllrate. Bandbreite ist hier kein Problem, da jedes Tile nur einmal gerendert und dann komplett fertig in den Framebuffer geschrieben wird. Ein Multisampling-Anti-Aliasing-Verfahren, was einerseits trotz sehr vielen Subpixeln sehr schnell arbeiten soll, andererseits aber nur wenig RAM verbrauchen darf, ist praktisch nur auf einem Tile Based Deferred Renderer zu realisieren.

Doch genug der Theorie. Unsere bisherige Praxis-Betrachtung guckte vor allem auf die GeForce-Implementierung. Wie aber sieht es bei der Radeon aus?


   Qualität vs. Radeon: Wer glättet besser?

Ab Radeon 9500 bietet auch ATI Multisampling. Hier der Vergleich:


Links GeForce ab 4 Ti, rechts Radeon ab 9500

Wieder sind die AA-Zeilen grün, die Subpixel rot und die Texel-Positionen blau kodiert. Radeon verwendet seit dem R300-Core bei 4x Anti-Aliasing also vier temporäre Zeilen im Triangle Setup. Auch auf der X-Achse sind die Subpixel besser verteilt. Das resultiert in einer höheren effektiven Auflösung, was die Kanten angeht:


Ein intelligenteres Raster liefert bessere Kanten.

Obwohl das gewählte Beispiel nicht besonders gut ist, zeigt sich, dass die Kanten im Bild unten dank dem effizienterem Raster mehr Farbzwischenstufen bekommen.

In Dingen Multisampling Anti-Aliasing-Qualität ist der R300-Chip (ebenso sein Nachfolger R350) dem NV30 haushoch überlegen: Während NV30 im Triangle Setup das Dreieck pro finaler Bildschirm-Zeile in nur zwei Zeilen zerlegen kann, bietet R300 die Möglichkeit, es sogar in bis zu sechs Zeilen zu zerlegen. Was GeForce3, 4 und FX in Dingen Kantenglättung liefern ist, seit dem es den R300 gibt, hoffnungslos veraltet. Ab R300 gibt es zudem einen Mechanismus, der die Kantenglättungs-Qualität weiter erhöht.


   Gamma-korrektes Downfiltering: Was berechnet wird, sollte man auch sehen

Hierbei handelt es sich eigentlich um keine Multisampling-spezifische Sache, da dieses Feature aber in der Praxis nur im Zusammenhang mit Multisampling-Anti-Aliasing anzutreffen ist, wollen wir trotzdem darauf eingehen.

Gamma-Korrektur wird meistens dann eingesetzt, wenn das Bild zu dunkel erscheint. Würde man bei einem zu dunklen Bild die Helligkeit erhöhen, würde das schwarze zu grau, und die hellen Flächen liefen zu, da alles helle nur noch rein weiß wäre. Signaltechnisch sinkt die Dynamik, auf jeden Fall würde das Bild letztlich verschlechtert. Deshalb nutzt man Gamma-Korrektur. Diese hat nämlich die angenehme Eigenschaft, nicht den Kontrastumfang zu verkleinern, und stattdessen die nichtlineare Helligkeitswiedergabe üblicher Kathodenstrahl-Röhren wieder annähernd linear zu machen.

Aus historischen Gründen sind viele Grafiken darauf aber gar nicht ausgelegt, sondern für die üblichen Monitore gestaltet worden. Die Bild-Wiedergabe tatsächlich zu linearisieren resultiert dann in einem unerwartet hellem Bild, weshalb oft darauf verzichtet wird, mittels Gamma-Kurve den Monitor vollständig auszukorrigieren. Beim Anti-Aliasing allerdings findet das Downfiltering für eine lineare Kennlinie statt: Angenommen, das Verfahren berechnet bis zu drei Zwischenstufen, dann sollten alle drei Zwischenstufen auch möglichst gleichmäßig verteilt sein, was die Helligkeit angeht.

Tatsächlich aber werden mäßig dunkle Farben so dunkel dargestellt, dass sie vom schwarz praktisch nicht zu unterscheiden sind. Von den berechneten Zwischenstufen sind nicht mehr alle zu sehen, was in einer "hüggeligen" Kante resultiert. Eine vollständige Korrektur des fertiges Bildes mittels der Gamma-Funktion würde wie gesagt insgesamt zu helle Bilder liefern. So ist es sinnvoll, die Subpixel vor dem Downfiltering mit der Gamma-Korrektur zu behandeln, und das fertige Pixel wieder zurück zu korrigieren.


Wenn Innen- und Außenflächen gleich hell erscheinen, ist die Helligkeitswiedergabe genau linear.

Wie man im Bild sieht, kann die Mischfarbe von zwei Pixeln durchaus eine andere Helligkeit haben, als was die beiden Pixel "wirklich" an Helligkeit erzeugen. Gamma-korrektes Downfiltering behebt dies. Allerdings gibt es hierbei auch Grenzen.

So muss der Treiber wissen, welcher Gamma-Korrektur für das Gerät eingestellt wurde, und schätzen, welcher Wert ideal ist. Auf manchen Displays, oder wenn die Gamma-Korrektur außerhalb des Treibers vorgenommen wird, führt diese Methode zu einer Art Überkorrektur, was dann wiederum zu schlechter Sichtbarkeit von Farbzwischenstufen führt.

Wir haben nun das Thema Multisampling für sich genommen durchdiskutiert. Besondere Feinheiten werden aber erst dann sichtbar, wenn dieses Verfahren mit einem anderen verglichen wird. Das soll auf der nächsten Seite geschehen.






Kommentare, Meinungen, Kritiken können ins Forum geschrieben werden - Registrierung ist nicht notwendig Zurück / Back Weiter / Next

Shortcuts
nach oben