Anisotrope Filterung - Anisotropes Filtern erklärt

[Coda]

Hier wird immer wieder über's AF diskutiert und ich habe so das Gefühl das die gemeinsame technische Basis fehlt.

Deshalb versuche ich mal das ganze zu erklären. Ich weiß dass das Thema nicht einfach ist, deshalb fragt wenn irgendwas nicht klar ist.

https://i.imgur.com/mBYhlZF.png


Abgebildet ist ein Quad, also vier Pixel die zusammen in die TMU gegeben werden. Wir wollen die Textur in der Mitte des linken oberen Pixels samplen (an der Stelle des schwarzen Punktes)
Durch den Shader kennt man die Texturkoordinaten der vier Pixelmittelpunkte (abgebildet ist ab jetzt der Textur-Space). Dadurch lassen sich die sogenannten Screenspace-Derivate berechnen (die eingezeichneten blauen Linien). Ich denke man sieht leicht wie man die durch einfache Mittelwertbildung der Vektoren zwischen den Punkten berechnen kann.
Aus den Derivaten ergibt sich ein approximierter Footprint, also die Projektion des Pixels auf die Textur (blau). Ich habe den tatsächlichen Footprint auch eingezeichnet (grün). Man sieht, dass das nicht ganz übereinstimmt, aber die Approximation funktioniert gut genug.
Die Gradienten ergeben sich bei komplett winkelunabhängigem AF aus der langen und kurzen Halbachse der im Footprint liegenden Ellipse (rot). Der AF-Grad ist dann Länge langer Gradient durch Länge kurzer Gradient. In diesem Fall ist die Verzerrung ca. 2,65:1. Aus diesem Verhältnis und der Länge der Gradienten wird auch die entsprechende Mipmap ausgewählt, so dass man Nyquiest einhält.
Entlang des längeren Gradienten wird gesampled. Die TMUs können nur gerade Anzahlen filtern, deshalb sind es in diesem Fall vier Samples (nächste gerade Zahl nach 2,65).


Wirklich Performance sparen kann man im letzten Schritt indem man einfach weniger Samples nimmt als eigentlich mathematisch nötig. Gerade bei niederfrequenten Texturen ist es kaum sichtbar wenn man bei einer solchen Verzerrung von 2,65:1 beispielsweise nur zweimal sampled.

Wie man sieht ist das ganze völlig unabhängig von irgendwelchen "Winkeln", dem "Abstand" oder sonstigem. Was wirklich ausschlaggebend ist, ist die Verzerrung der Textur - mehr nicht.

[Langenscheiss]

Kannst du irgendwelche Literatur empfehlen? Danke übrigens.

[3dzocker]

was mir, als jemand der davon keine Ahnung hat, einfällt:

1. kapier ich noch

2. Warum kennt der Shader die Texturkoordinaten?
Was ist Textur-Space?
Was sind Screenspace-Derivate) (ich weiß das "derivative" Ableitung heißt - hat das was damit zu tun?)
Was berechnet man durch Mittelwertbildung der Vektoren zwischen den Punkten?

3. approximierter Footprint??? (Was ne Approximation is weiß ich)

4. Gradient, Nyquist???
Ich hatte Gradienten in Mathe 3, zusammen mit Divergenz und Rotation - ich vermute also hier wird irgendwas berechnet...?

Aber vielleicht bin ich auch nicht die Zielgruppe - wenn dem so ist: SORRY ;)

tschau

[Langenscheiss]

Also die Gradienten im Shader sagen dir immer, wie weit es bis zum nächsten Pixel im Texture-Space ist.
Wenn man nämlich Schleifen setzt, muss man die Gradienten immer vorher berechnen lassen (was nervt).
Falls diese Gradienten gemeint sind (wovon ich jetzt mal ausgehe, sonst habe ich was völlig missverstanden), so haben diese nur bedingt was mit dem Gradienten aus der Mathematik was zu tun.
Die Gradienten-Berechnung ist nicht mal sooo aufwendig, wie man meint, weil die TMUs ja eben immer Quads abarbeiten.

[Mr. Lolman]

Wie weiß ich, ab wann ich aus der nächstkleineren Mipmap sampeln kann?

[Langenscheiss]

Hab auch mal n noch n Frage:
Warum wird immer entlang der langen Halbachse gesampled und warum nicht an beiden? Und mit samples meinst du bilineare samples oder?
Texel = AF-Grad * 4 (für bilinear) * 2 (falls Mipmaps)
Erscheint mir bei max AF 16:1 nicht sinnvoll, 64 samples entlang einer Achse zu nehmen. Bitte diesbezüglich um Aufklärung.


Und auch wenn nur die Verzerrung der Textur letztendlich wichtig ist, so ist ja genau diese im Spiel meist vom Abstand bzw. wohl eher vom Blickwinkel abhängig.

[Spasstiger]

Und mit samples meinst du bilineare samples oder?
Die Samples aus Schritt 5 sind imo einfach Pointsamples, da hat noch keine Interpolation stattgefunden bzw. es spielt hier keine Rolle.

Wie weiß ich, ab wann ich aus der nächstkleineren Mipmap sampeln kann?
Müsste aus der Länge des langen Gradienten bestimmt werden können. Außerdem tastet man ja aus zwei benachbarten Mipmaps ab zwecks Interpolation (bilinear, trilinear). Sonst hat man harte Mipmap-Kanten.

[redfalcon]

Was wird denn da genau gesampled? Die TMU hat die 4 Punkte auf dem Gradienten, was macht die dann damit?

[Eggcake]

Ich hoffe ich schreibe hier nicht Müll bzw. verwirre damit nicht noch mehr, da ich ebenfalls von allem zum ersten Mal höre. Ich schreibe nicht vor jeden Satz "Ich glaube dass es XY ist", denkt es euch aber dazu :)


-----------------


2. Was ist Textur-Space?

Im Prinzip die Textur "von oben", "unverzerrt" betrachtet. Die erste Abbildung zeigt ja eine verzerrte Textur - so, wie du sie vom entsprechenden Blickwinkel&Abstand her (das soll man ja nicht verwenden) siehst.

Was sind Screenspace-Derivate
Was berechnet man durch Mittelwertbildung der Vektoren zwischen den Punkten?
Das sind die Mittellinien aus Figur 1 im Textur-Space. Ebendiese blauen Linien kannst du durch Mittelwertbildung berechnen. Die Mitten von 2 gegenüberliegenden Punkten mit der anderen Seite verbinden.

3. approximierter Footprint??? (Was ne Approximation is weiß ich)
Das ist das grüne Quadrat aus dem 1. Bild. Das heisst welcher Ausschnitt diese 4 Pixel im Textur-Space darstellen. Dieser wird durch die Screenspace-Derivate (blauen Linien zuvor) approximiert (im Prinzip kannst du die Mitte Vektoren jeweils an's Ende der anderen hängen und du hast das Polygon, um's sich bildlich vorzustellen).

4. Gradient, Nyquist???
Du willst im Prinzip die Richtung, in der die Textur im Screenspace verzogen worden ist. Diese entspricht der Richtung der langen Halbachse. Wie stark sie verzogen ist, ergibt sich aus dem Verhältnis der beiden Halbachsen
Würde man von oben draufschauen, so hätte man ja ein Quadrat, d.h. perfekter Kreis --> Verhältnis 1:1. Je schiefer man schaut, desto "langgezogener" wird diese Ellipse und desto grösser wird das Verhältnis.

Hoffe meine Erklärungen waren nicht komplett falsch - falls doch, lösche ich sie wieder. Habe versucht es möglichst einfach zu erklären, so wie ich's mit meinen bescheidenen Fähigkeiten verstanden hab'... :>
-----------------


Was genau mit Nyquist gemeint ist würde ich auch gerne noch wissen. Ich kenne es aus der Signalverarbeitung (Abtastrate > 2*fmax), sehe aber grad nicht, wie ich es auf dieses Beispiel anwenden kann.
Edit: Noch eine grundsätzliche Frage: Das bedeutet ja, je schiefer die Textur, desto mehr wird gesampled. Kann ich das nun ganz einfach so verstehen dass bei stark verzogener Textur auf "kleinem Raum" "mehr von der Textur gesehen wird" und deshalb auch mehr Samples zur Approximierung des Farbwertes herhalten müssen? So in etwa?

Würde mich übrigens auch für (Einsteigs-)Literatur interessieren. Das Thema (natürlich nicht nur AF) interessiert mich sehr, finde es aber schwer etwas darüber zu finden was meinem Niveau entspricht. Hat halt wenig mit meinem Studium zu tun, von daher lerne ich da praktisch garnix...

[Spasstiger]

Was wird denn da genau gesampled? Die TMU hat die 4 Punkte auf dem Gradienten, was macht die dann damit?
Die Samplepositionen sind Texturkoordinaten. Du willst ja wissen, welchen Farbwert ein Pixel auf dem Bildschirm an einer bestimmten Position hat. Dazu musst du wissen, welcher Farbwert sich aus der Textur bei diesem Pixel ergibt. D.h. man lädt die Farbwerte der Textur an den Samplepositionen, die zu einem Pixel (oder besser "Fragment") gehören und mischt sie zu einem Farbwert.

Was genau mit Nyquist gemeint ist würde ich auch gerne noch wissen. Ich kenne es aus der Signalverarbeitung (Abtastrate > 2*fmax), sehe aber grad nicht, wie ich es auf dieses Beispiel anwenden kann.
Es ist genau dasselbe Nyquist-Shannon-Abtasttheorem. Nur ist hier die Frequenz nicht zeitlich bezogen, sondern räumlich bzw. örtlich. Man spricht von einer Ortsauflösung und einer Ortsfrequenz. Willst du, dass deine Textur ohne Aliasing*) abgetastet wird, muss die maximale Ortsauflösung der Textur ggf. reduziert werden und zwar soweit, dass die Abtastfrequenz bzw. deine Abtast-Ortsauflösung doppelt so hoch ist wie die der Textur. Das geschieht dadurch, dass Mipmaps generiert werden, die die Textur mit reduzierter Ortsauflösung repräsentieren.

*) Aliasing bedeutet hier, dass die abgetastete Textur entlang der Abtastachse (entlang des langen Gradienten) nicht mehr aus den Abtastwerten fehlerfrei rekonstruiert werden kann. Das äußert sich als Texturflimmern.

[Gipsel]

*) Aliasing bedeutet hier, dass die abgetastete Textur entlang der Abtastachse (entlang des langen Gradienten) nicht mehr aus den Abtastwerten fehlerfrei rekonstruiert werden kann. Das äußert sich als Texturflimmern.Rekonstruiert wird da sowieso nichts, da wird stur gemittelt, so daß selbst bei Einhaltung der Nyquist-Bedingung ein gewisses Flimmern bemerkbar sein kann. Auch deswegen sollte tendenziell überfiltert werden (z.B. Aufrunden des AF-Grades auf nächste Zweierpotenz).

@Coda:
Wieviel Unterschied macht es eigentlich, wirklich die einbeschriebene Ellipse zu nehmen und nicht einfach den betragsmäßig größeren Gradienten zu benutzen? Hast Du das mal ausprobiert? Entspricht das irgendeiner Winkelabhängigkeit, die man in den letzten Jahren bei ATI oder nvida sehen konnte?

[Langenscheiss]

Kann mir bitte einmal einer erklären, warum überhaupt nur entlang der langen Halbachse gesampled wird? Die Ellipse liegt doch komplett im Bereich dessen, was der Pixel abdeckt.

[Gipsel]

Kann mir bitte einmal einer erklären, warum überhaupt nur entlang der langen Halbachse gesampled wird? Die Ellipse liegt doch komplett im Bereich dessen, was der Pixel abdeckt.
Die Breite wird schon komplett durch das Sampeln aus der richtigen MipMap abgedeckt. Man muß das also nur entlang der längeren Achse machen. Vielleicht sollte Coda oben noch die Größe der bi-/bzw. trilinearen Samples einzeichnen.

Edit:
Das sieht ungefähr so aus:
http://139.30.40.11/AF.png

Das Parallelogramm ist der (genäherte) Footprint des Pixels, die Quadrate sind praktisch die Größe der Samples aus der entsprechenden MipMap. In die Breite müßte man nur gehen, wenn man aus einer feineren MipMap sampled. Dann könnte man tatsächlich auch den Footprint besser annähern, dafür kostet das natürlich auch etwas mehr Aufwand.

[Langenscheiss]

Achso!
Liegen die Gradienten in der Ellipse, wie sie eingzeichnet sind, perspektivisch korrekt?
Ich verstehe nicht, wie die Orientierung der Gradienten genau zustande kommt. Ist diese perspektivisch oder schlicht so, als wäre die Ellipse 2-dimensional eingezeichnet. Für mich sieht das nach letzerem aus, und wenn ja, wieso?

EDIT: Deiner Skizze zu folge müsste die Ellipse also perspektivisch in dem footprint liegen. Und deine Samples sind jetzt bilineare samples?

[Eggcake]

Es ist genau dasselbe Nyquist-Shannon-Abtasttheorem. Nur ist hier die Frequenz nicht zeitlich bezogen, sondern räumlich bzw. örtlich. Man spricht von einer Ortsauflösung und einer Ortsfrequenz. Willst du, dass deine Textur ohne Aliasing*) abgetastet wird, muss die maximale Ortsauflösung der Textur ggf. reduziert werden und zwar soweit, dass die Abtastfrequenz bzw. deine Abtast-Ortsauflösung doppelt so hoch ist wie die der Textur. Das geschieht dadurch, dass Mipmaps generiert werden, die die Textur mit reduzierter Ortsauflösung repräsentieren.

*) Aliasing bedeutet hier, dass die abgetastete Textur entlang der Abtastachse (entlang des langen Gradienten) nicht mehr aus den Abtastwerten fehlerfrei rekonstruiert werden kann. Das äußert sich als Texturflimmern.

Okay, ich glaube soweit mehr oder weniger verstanden, nur verstehe ich die Abfolge nicht so ganz:
Aus diesem Verhältnis und der Länge der Gradienten wird auch die entsprechende Mipmap ausgewählt, so dass man Nyquiest einhält.
Schritt 5 ist mir wieder klar - hier spielt ja nur die Verzerrung mit rein, so wie ich das verstanden habe, aber diesen Teil verstehe ich nicht ganz.

Ich bin bei Schritt 4. Habe die Richtung und Länge des Gradienten und die Verzerrung. Und was genau ist nun meine Abtastfrequenz im oberen Beispiel?

[Langenscheiss]

Abtast-Frequenz bzw. Auflösung heißt im Grunde, wieviele Samples du auf welchem Raum bei welcher Informationsdichte benutzt. Mal anschaulich:
Nimmst du einer Strecke von 1cm 2 samples, hast du eine "Frequenz" von 2/cm! Angenommen, du hast auf diesem cm 2 verschiedene Farben, so hast du eine Signal-Frequenz von 1/cm (da das Signal eine Periode durchläuft) => Einhaltung von Nyquist. Oder nimm audio. Warum nimmt man wohl immer 44000 HZ für 22000HZ audio-files?

http://de.wikipedia.org/w/index.php?title=Datei:Nyquist_Aliasing.svg&filetimestamp=20091212221639

[Gipsel]

Achso!
Liegen die Gradienten in der Ellipse, wie sie eingzeichnet sind, perspektivisch korrekt?
Ich verstehe nicht, wie die Orientierung der Gradienten genau zustande kommt. Ist diese perspektivisch oder schlicht so, als wäre die Ellipse 2-dimensional eingezeichnet. Für mich sieht das nach letzerem aus, und wenn ja, wieso?

EDIT: Deiner Skizze zu folge müsste die Ellipse also perspektivisch in dem footprint liegen.
Da ist keine Perspektive mehr in dem Sinne dabei. Die Ellipse wird einfach so in das Parallelogramm gelegt, daß es alle Seiten berührt. Die Achsen der Ellipse zu nehmen (statt einfach die längere Seite des Parallelogramms, die ja direkt aus der Gradientenberechnung rauskommt) hat den Vorteil, daß man etwas besser die größte Streckung des Footprints erwischt (stelle dir einfach mal eine lange Raute vor), also die Achse, die sonst zuwenig gefiltert wird.

Berechnet werden die Gradienten einfach als Differenz der Pixelmittelpunkte eines Quads im Texelspace. Oder verstehe ich Deine Frage gerade nicht ganz?

[Langenscheiss]

Das mit dem Gradienten wusste ich, deswegen war ich ja verwirrt.
Danke, das klärt es für mich so ziemlich auf. Finds gut, dass hier Leute sind, die wirklich was davon verstehen. Leider gibs im Netz dazu wenig Literatur.

[Gipsel]

Okay, ich glaube soweit mehr oder weniger verstanden, nur verstehe ich die Abfolge nicht so ganz:

Schritt 5 ist mir wieder klar - hier spielt ja nur die Verzerrung mit rein, so wie ich das verstanden habe, aber diesen Teil verstehe ich nicht ganz.

Ich bin bei Schritt 4. Habe die Richtung und Länge des Gradienten und die Verzerrung. Und was genau ist nun meine Abtastfrequenz im oberen Beispiel?
Du nimmst einfach die Mipmap, so daß Du Samples mittelst, die mindestens genau Pixel(Footprint-)breite voneinander entfernt sind (also zusammen doppelt so breit wie die kleinere Achse des Footprints). Bei trilinearem Filtering werden dann noch entsprechend zwei benachbarte MipMaps gewichtet gemittelt.

[Coda]

Wieviel Unterschied macht es eigentlich, wirklich die einbeschriebene Ellipse zu nehmen und nicht einfach den betragsmäßig größeren Gradienten zu benutzen? Hast Du das mal ausprobiert? Entspricht das irgendeiner Winkelabhängigkeit, die man in den letzten Jahren bei ATI oder nvida sehen konnte?
Das verstehe ich jetzt nicht.

Was gemacht wurde ist nur die Derivate direkt und die Diagonalen des daraus entstandenen Footprints in Betracht zu ziehen. Das ergibt dann das R300/NV40-AF.

[Coda]

Achso!
Liegen die Gradienten in der Ellipse, wie sie eingzeichnet sind, perspektivisch korrekt?
Ich verstehe nicht, wie die Orientierung der Gradienten genau zustande kommt. Ist diese perspektivisch oder schlicht so, als wäre die Ellipse 2-dimensional eingezeichnet. Für mich sieht das nach letzerem aus, und wenn ja, wieso?

EDIT: Deiner Skizze zu folge müsste die Ellipse also perspektivisch in dem footprint liegen. Und deine Samples sind jetzt bilineare samples?
Es gibt keine "Perspektive" beim Filtern. Das ganze findet stur im zweidimensionalen Texturspace statt.

Das Ziel ist ja den Footprint mit möglichst wenigen "Rechtecken", also Bi/Trilinearen Samples abzudecken. Deshalb sampled man entlang des längeren Gradienten.

[Langenscheiss]

Ich weiß. Ich war nur verwirrt wegen deiner Zeichnung, denn die Halbachse war nicht parallel zur längeren Parallelogrammseite, und mir war nicht klar, wie die Orientierung der Halbachsen in deiner Zeichnung zustande kam/kommt. Gipsel hats ja aufgeklärt, warum man sowas macht.

[Gipsel]

Das ergibt dann das R300/NV40-AF.Das war meine Frage. Danke!

[Coda]

Sorry, dass ich etwas durcheinander antworte.

Kannst du irgendwelche Literatur empfehlen? Danke übrigens.
Nein. Ich habe nichts gefunden außer den OpenGL-Specs und wissenschaftliche Papers.

Wie man korrekt "winkelunabhängig" filtert musste ich selber herausfinden. Inzwischen habe ich das aber auch schonmal in einem Paper gesehen, ich weiß aber nicht mehr welches es war.

[Langenscheiss]

Wäre schön, wenn du die papers mal verlinkst. Danke schon mal, vor allem dafür, dass ich nun etwas detaillierter verstehe, wie die Graka das AF-Level bestimmt.
Ich hatte von meine Source-Shader-Erfahrungen immer so etwas diffuses Halbwissen über diesen Aspekt im Kopf.

[Coda]

Ich glaube nicht, dass ich die jetzt noch finde

Rekonstruiert wird da sowieso nichts, da wird stur gemittelt, so daß selbst bei Einhaltung der Nyquist-Bedingung ein gewisses Flimmern bemerkbar sein kann. Auch deswegen sollte tendenziell überfiltert werden (z.B. Aufrunden des AF-Grades auf nächste Zweierpotenz).
Überabtasten bringt überhaupt nichts. Selbst wenn ich alles doppelt so hoch abtaste ergibt sich keine visuelle Verbesserung.

Da muss ein anderes Problem dahinter stecken weshalb das Flimmern nie ganz verschwindet. Bisher hatte ich aber keine Zeit dem nachzugehen. Wenn du willst kannst du mal den Code haben zum rumspielen.

[Eggcake]

Abtast-Frequenz bzw. Auflösung heißt im Grunde, wieviele Samples du auf welchem Raum bei welcher Informationsdichte benutzt. Mal anschaulich:
Nimmst du einer Strecke von 1cm 2 samples, hast du eine "Frequenz" von 2/cm! Angenommen, du hast auf diesem cm 2 verschiedene Farben, so hast du eine Signal-Frequenz von 1/cm (da das Signal eine Periode durchläuft) => Einhaltung von Nyquist. Oder nimm audio. Warum nimmt man wohl immer 44000 HZ für 22000HZ audio-files?

http://de.wikipedia.org/w/index.php?title=Datei:Nyquist_Aliasing.svg&filetimestamp=20091212221639

Das war mir im Prinzip schon klar - wie gesagt, Nyquist an sich verstehe ich eigentlich schon (dachte ich), aber in diesem Beispiel nicht wirklich.

Du nimmst einfach die Mipmap, so daß Du Samples mittelst, die mindestens genau Pixel(Footprint-)breite voneinander entfernt sind (also zusammen doppelt so breit wie die kleinere Achse des Footprints). Bei trilinearem Filtering werden dann noch entsprechend zwei benachbarte MipMaps gewichtet gemittelt.

Hmmm. Ich merke, dass ich ganz nah dran bin, aber es will noch nicht ganz rüber... :> Irgendwie habe ich alles verstanden, aber hier sehe ich grad nur eine graue Wand. HD5k im 3DC-FilterTester quasi.
Schau's mir morgen sonst nochmals an, evt. macht's dann "klick".

Edit: Ach ich versuch's trotzdem nochmals:
Ich verstehe nicht, was die Samples in diesem Fall sind. Die haben wir ja eigentlich erst in Punkt 5. Oder ist was anderes gemeint?
Mir mangelts eigentlich schon am grundlegenden Basiswissen, aber wär' toll wenn ich den Teil doch noch kapiere :)

[Coda]

Nyquist bedeutet einfach dass die Frequenz der Textur auf dem Bildschirm nur halb so hoch sein darf wie die Frequenz der Samples (also ohne Supersmapling des Pixelrasters).

Ansonsten kann man das Signal nicht verlustfrei rekonstruieren, d.h. es flimmert.

[Gipsel]

Irgendwie habe ich alles verstanden, aber hier sehe ich grad nur eine graue Wand. HD5k im 3DC-FilterTester quasi.Schlechte Analogie. Das perfekte Grau in der Mitte muß so aussehen und stellt (zumindest dort) das absolut korrekte Ergebnis dar. Falls man da noch irgendwelche Moire-Muster sieht, arbeitet der Filter nicht optimal ;)

[Coda]

Schlechte Analogie. Das perfekte Grau in der Mitte muß so aussehen und stellt (zumindest dort) das absolut korrekte Ergebnis dar.
Ich bin mir da nicht so sicher. Ich würde die Textur gerne mal durch die Referenzimplementierung jagen ;)

Ich verstehe nicht, was die Samples in diesem Fall sind. Die haben wir ja eigentlich erst in Punkt 5. Oder ist was anderes gemeint?
Ein Sample ist einfach die entsprechende(n) Mipmap(s) an diesem Punkt bilinear/trilinear gefiltert.

[Eggcake]

Schlechte Analogie. Das perfekte Grau in der Mitte muß so aussehen und stellt (zumindest dort) das absolut korrekte Ergebnis dar. Falls man da noch irgendwelche Moire-Muster sieht, arbeitet der Filter nicht optimal ;)

Ich kam grad von da, deshalb:
http://www.gpu-tech.org/content.php/137-A-closer-look-at-the-anisotropic-filtering-of-the-Radeon-HD-5000-series
;)

[Gipsel]

Nyquist bedeutet einfach dass die Frequenz der Textur auf dem Bildschirm nur halb so hoch sein darf wie die Frequenz der Samples (also ohne Supersmapling des Pixelrasters).
Deswegen sampelt man aus der Mipmap, so daß die gemittelten Texel (mindestens) die doppelte Breite einnehmen, wie die kleine Achse des Footprints.
Ansonsten kann man das Signal nicht verlustfrei rekonstruieren, d.h. es flimmert.
Wie gesagt, da läuft ja kein Rekonstruktionsalgo drüber, das passiert erst in unserem Hirn. Und da kann es eben trotzdem noch zu einem Aliasing zwischen Pixel- und Texel-Raster kommen, was sich in einem (leichten) Flimmern bemerkbar macht.

Einfaches Beispiel, das auch ohne AF funktioniert:
Schachbrett, 3 Pixel weiß, 3 Pixel schwarz, mit enstprechendem Filtern bleibt 1 Pixel immer komplett weiß und 1 komplett schwarz, dazwischen gibt es irgendein Grau, je nach genauer Ausrichtung des Pixel- zum Texelraster. Verschiebt man jetzt die Raster mit konstanter Geschwindigkeit gegeneinander, ergeben sich (zeitlich) periodische Muster von verschiedenen Grautönen => Flimmern.

Diese Art des Flimmerns ist unvermeidlich. Ihr kommt man erstmal nur mit Opfern von Schärfe bei, nicht aber mit verbesserter Sampleanordnung oder Ähnlichem. Da könnte man überlegen, ob man irgendwie solche Fälle erkennen könnte, um dann die Schärfe selektiv etwas zu verringern (nur bei kritischen Verzerrungen, also nicht einfach am LOD drehen). Am einfachsten wäre wahrscheinlich eine Art stochastischer Ansatz, man wackelt einfach von Frame zu Frame ein wenig zufällig an den Samplepositionen. Dadurch ergeben sich nicht immer reproduzierbar die gleichen Muster, aus dem Flimmern wird ein leichtes Rauschen (eine Art Filmeffekt). Bei genügend hoher Framerate könnte das ganz gut funktionieren (Auge mittelt das Rauschen weg). Vom Prinzip her wäre das ähnlich dem zwischenzeitlich mal propagierten temporal Antialiasing.

[Spasstiger]

Da muss ein anderes Problem dahinter stecken weshalb das Flimmern nie ganz verschwindet. Bisher hatte ich aber keine Zeit dem nachzugehen. Wenn du willst kannst du mal den Code haben zum rumspielen.
Da gibts ja offenbar mehrere Erklärungsansätze:
- Mipmaps werden nicht nyquistkonform erzeugt (gemeinhin "böser Content" genannt ;))
- Downsampling/Resolve der Textursamples erfolgt nicht nyquistkonform (sondern z.B. mit einem einfachen Box-Filter)
- Footprint des Pixels wird nur approximiert und nicht exakt bestimmt

[Eggcake]

*KLICK!*

:D


Hab ganz vergessen, dass das Ganze ja für ein Pixel und nicht für vier gemacht wird. Irgendwie gab's da ein übles Durcheinander.
Zumindest bin ich der Erleuchtung ein Schrittchen näher gekommen, glaube ich zumindest.

[Gipsel]

Ich bin mir da nicht so sicher. Ich würde die Textur gerne mal durch die Referenzimplementierung jagen ;)Die Referenzimplementierung ist da egal. Sobald die einzelnen Schachbrettfelder deutlich kleiner als ein Pixel werden (in einer Dimension reicht), ist alles andere als Grau ein Artefakt des benutzen Filters ;)
Aber das sollte auch zu sehen sein. Im Prinzip muß er ja irgendwann aus der einer MipMap sampeln, in der nur noch graue Pixel drin sind (also 4 benachbarte Felder zu einem Texel verrechnet sind). Es sei denn natürlich, man hat in den MipMaps Aliasing drin, da die Schachbretter keine Zweierpotenz als Kantenlänge haben (dann ist nur die allerkleinste MipMap ein einziges graues Pixel).

[Langenscheiss]

Eben. Das graue ganze hinten ist völlig normal und muss so sein. Irgendwann ist man halt bei der letzten Mipstufe angekommen und die ist halt nur noch grau. Sieht man ja immer schön in den Vergleichen zwischen Mip und ohne Mip. Darüber hinaus kommt ja auch noch folgender Effekt bei diesen Schachbrettern hinzu. Denke dir mal annähernd unendlich viele Kacheln im Pixel-footprint und lasse nun AF über alle Samples mitteln. Das ganze bekommt doch schon statistischen Charackter und da ist grau, selbst ohne Verwendung von Mipmaps bei einer genügend hohen Sample-Zahl und entsprechender Gewichtung beim Mittelungsprozess geradezu Pflicht.

[Gipsel]

Darüber hinaus kommt ja auch noch folgender Effekt bei diesen Schachbrettern hinzu. Denke dir mal annähernd unendlich viele Kacheln im Pixel-footprint und lasse nun AF über alle Samples mitteln. Das ganze bekommt doch schon statistischen Charackter und da ist grau, selbst ohne Verwendung von Mipmaps bei einer genügend hohen Sample-Zahl und entsprechender Gewichtung beim Mittelungsprozess geradezu Pflicht.
Ganz genau. Ich würde das perfekte Grau in der Mitte eher als Gütezeichen des Filters sehen und eventuelle Moire-Muster dort als Artefakt. Die Übergänge dahin müssen nur ordentlich aussehen :rolleyes:

Für so einfache Texturen wie Schachbretter (Querstreifen sind noch einfacher und sollten den gleichen Effekt zeigen) kann man das im Prinzip sogar vollkommen exakt berechnen (sozusagen "infinite sample" oder "perfect sample" AF/AA, kann man bei der Gelegenheit dann gleich kombinieren). Deswegen hatte ich mich gestern Abend schon mal kurz damit beschäftigt und überlegt, ob ich das nicht mal komplett als Softwarerenderer zusammenkloppe. Aber in Anbetracht meiner knappen Zeit habe ich erst von Tunnel auf Ebene zurückgesteckt, dann von Schachbrett auf Streifen und schließlich beschlossen, daß sich das vielleicht nicht lohnt und ich lieber hier im Forum ein oder zwei Fragen loswerde. Die gingen ja zuerst in den anderen Thread, aber ist jetzt auch egal.

[Coda]

Die Referenzimplementierung ist da egal. Sobald die einzelnen Schachbrettfelder deutlich kleiner als ein Pixel werden (in einer Dimension reicht), ist alles andere als Grau ein Artefakt des benutzen Filters ;)
Offenbar ist aber der Content der Mipmaps bei jedem Miplevel gleich. Und der Filter der für die Mipmaps verwendet wurde gehört nunmal auch zum benutzen Filter.

Deshalb wundert mich das AMD-Ergebnis ja auch so. Evtl. erkennen die solchen Mist im Treiber und filtern dann die Mipmaps nochmal gescheit. Weil ansonsten kann ich mir das Ergebnis einfach nicht erklären. Die Hardware sorgt jedenfalls mit großer Wahrscheinlichkeit nicht dafür dass es so aussieht.

Eben. Das graue ganze hinten ist völlig normal und muss so sein. Irgendwann ist man halt bei der letzten Mipstufe angekommen und die ist halt nur noch grau.
Sie ist offenbar aber eben nicht nur noch grau. Sonst könnte und würde der NV-Filter auch nichts anderes anzeigen.

Aber ganz ehrlich Leute: Das hat hier nur sehr begrenzt was verloren. Meiner Einschätzung nach filtert NVIDIA bis auf die etwas ungenauere Gradienten-Rechnung perfekt ohne LOD-Bias bei HQ.

[Gipsel]

Offenbar ist aber der Content der Mipmaps bei jedem Miplevel gleich. Und der Filter der für die Mipmaps verwendet wurde gehört nunmal auch zum benutzen Filter.

Deshalb wundert mich das AMD-Ergebnis ja auch so. Evtl. erkennen die solchen Mist im Treiber und filtern dann die Mipmaps nochmal gescheit. Weil ansonsten kann ich mir das Ergebnis einfach nicht erklären. Die Hardware sorgt jedenfalls mit großer Wahrscheinlichkeit nicht dafür dass es so aussieht.

Sie ist offenbar aber eben nicht nur noch grau. Sonst könnte und würde der NV-Filter auch nichts anderes anzeigen.Heißt das jetzt, daß beim diesem Tunneltest die MipMaps von der App falsch gesetzt werden?

[Mr. Lolman]

Heißt das jetzt, daß beim diesem Tunneltest die MipMaps von der App falsch gesetzt werden?

Jo: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=8350091&postcount=193

[Gipsel]

Um den Thread mal neu zu beleben, bei B3D hat jemand ein kleines Tool gebastelt, womit sich die Sampleanzahlen des AF wohl ziemlich exakt rekonstruieren lassen. Mintmaster dort, hat (schon vor 3 Wochen) eine für mich überzeugende Deutung der Ergebnisse zumindest der nvidia-Karten gepostet (http://forum.beyond3d.com/showthread.php?p=1505477#post1505477).
Bezugnehmend auf mein früheres Posting im HD600er AF-Qualitätsthread (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8352610#post8352610), scheint nvidia die dort beschriebene Lösung #1 oder #3 zu verwenden, es findet definitv eine Verrechnung der Samples mit unterschiedlichen Gewichten statt. Weiterhin runden die nv-GPUs die Sampleanzahl nur auf das nächte Vielfache von 2 auf (weswegen ich zu Lösung #3 tendieren würde) und benutzen nicht die nächsthöhere Zweierpotenz. Letzteres ist allerdings bei AMD-GPUs zu beobachten, die also sogar im Schnitt mehr Samples als nvidia verrrechnen. Allerdings geschieht dies offenbar nicht mit angepaßten Gewichten (oder sie sind schlechter verteilt), was dann offenbar zu einer höheren Flimmerneigung führen kann. Allerdings kann man auch noch erwähnen, daß dort im Thread ein paar Hinweise zusammengetragen wurden (kann ich jetzt so nicht wirklich bewerten, aber ein paar Screenshots sehen schon so aus), daß zumindest in ein paar Spielen nv mit einem positiverem LOD arbeitet als AMD, was diese Neigung natürlich noch verstärkt.

[Ronny145]

Allerdings kann man auch noch erwähnen, daß dort im Thread ein paar Hinweise zusammengetragen wurden (kann ich jetzt so nicht wirklich bewerten, aber ein paar Screenshots sehen schon so aus), daß zumindest in ein paar Spielen nv mit einem positiverem LOD arbeitet als AMD, was diese Neigung natürlich noch verstärkt.


Das würde ich gerne sehen. Wo soll das stehen?

[Gipsel]

Das würde ich gerne sehen. Wo soll das stehen?
Na in dem verlinkten Thread bei B3D, einfach nur ein zwei Seiten vorher. Oder mal hier ein vergleichender Screenhot von TrackMania von dort:

links ATI, rechts nvidia, man achte nicht nur auf die (flimmernde) Bodentextur, sondern z.B. auf die Schrift (Trackmania) oder das zum Teil auch das Hallendach, die ist bei nvidia stärker geblurrt, da gehen (unnötig) Details verloren.

http://www.abload.de/img/_original_2yb3e.png

Edit:
Die Bilder kommen übrigens aus dem 3DC-Artikel zu dem Thema ;)

[Ronny145]

Na in dem verlinkten Thread bei B3D, einfach nur ein zwei Seiten vorher. Oder mal hier ein vergleichender Screenhot von TrackMania von dort:

links ATI, rechts nvidia, man achte nicht nur auf die (flimmernde) Bodentextur, sondern z.B. auf die Schrift (Trackmania) oder das zum Teil auch das Hallendach, die ist bei nvidia stärker geblurrt, da gehen (unnötig) Details verloren.


Das Trackmania Beispiel wurde schon widerlegt. Da ging es ums Banding und wahrscheinlich ist beim unschärferen Bild das Auto nicht komplett zum Stillstand gekommen, wodurch ein wenig Blur zu sehen ist. Schärfeunterschiede gibt es an der Stelle quasi nicht.

HD5000
http://h-5.abload.de/img/tmforever8xmsaa16xafhqxmxj.png

Nvidia
http://h-2.abload.de/img/tmforever2010-12-1018-olhd.png

[airbag]

links ATI, rechts nvidia, man achte nicht nur auf die (flimmernde) Bodentextur, sondern z.B. auf die Schrift (Trackmania) oder das zum Teil auch das Hallendach, die ist bei nvidia stärker geblurrt, da gehen (unnötig) Details verloren.

http://www.abload.de/img/_original_2yb3e.png


Trackmania ist aber bzgl. dieser Schrift auch sehr eigen.
Siehe Shots die ich vor ein paar Monaten mal gepostet habe.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=8372213&postcount=12

Mit Clamp + negatives LOD eingestellt, ist die Schrift schärfer. Der Rest bleibt im Vergleich zu LOD 0 aber gleich.

[Gipsel]

Das Trackmania Beispiel wurde schon widerlegt.Wie gesagt, ich habe mich nicht wirklich mit diesen Screenshots beschäftig. Aber gibt's eigentlich irgendeine Erklärung, daß bei Deinen verlinkten Bildern GeForce und Radeon selbst abgesehen vom AF doch deutlich unterschiedliche Bilder zu rendern scheinen (die anderen wirken "ähnlicher")?

Aber ist zumindest hier auch egal, Hauptpunkt meines Posts oben war ja die Funktionsweise des AF bei nv.

[Coda]

Worüber wird hier eigentlich noch gestritten? Ist die Wahrheit immer noch nicht durchgedrungen :tongue:

Gipsel, mein Filtertester nimmt die Samples einfach gleichverteilt über die LOA und mittelt dann ohne Gammakorrektur. Das gibt praktisch identische Resultate wie die NVIDIA-HW. Ich denke also, dass da gar nicht so viel mehr gemacht wird.

Intel beschreibt in ihren Dokumenten dass sie die "Randsamples" anders Gewichten was anscheinend das Flimmern verringert. Wenn ich nur Zeit hätte könnte ich noch einiges untersuchen in diese Richtung.

[Gipsel]

Intel beschreibt in ihren Dokumenten dass sie die "Randsamples" anders Gewichten was anscheinend das Flimmern verringert. Wenn ich nur Zeit hätte könnte ich noch einiges untersuchen in diese Richtung.Und genau das andere Gewichten der Randsamples wurde jetzt (bzw. habe ich es erst jetzt gesehen) für nvidia-GPUs durch die Tests dort nachgewiesen. Das war der Grund für mein Post ;)

Achja, und nvidia arbeitet mit 2, 4, 6, 8, 10, 12, 14 oder 16 Samples. AMD mit 2, 4, 8 oder 16, das ist also gröber abgestuft (weswegen der korrekten Verteilung/Wichtung für einen gleichmäßigeren Eindruck etwas mehr Wichtigkeit zukommen sollte), die rechnen also im Prinzip schon mit 16 (wenn sie es denn in HQ machen), wenn nvidia noch mit 10 auskommt.

[Coda]

Dann ist der effektive Gewinn davon aber sehr minimal, da ich wirklich keinen großen Unterschied erkennen kann zu meiner Implementierung.

Das ist offensichtlich nicht die Lösung für das "Restflimmern".

[Langenscheiss]

Und genau das andere Gewichten der Randsamples wurde jetzt (bzw. habe ich es erst jetzt gesehen) für nvidia-GPUs durch die Tests dort nachgewiesen. Das war der Grund für mein Post ;)

Achja, und nvidia arbeitet mit 2, 4, 6, 8, 10, 12, 14 oder 16 Samples. AMD mit 2, 4, 8 oder 16, das ist also gröber abgestuft (weswegen der korrekten Verteilung/Wichtung für einen gleichmäßigeren Eindruck etwas mehr Wichtigkeit zukommen sollte), die rechnen also im Prinzip schon mit 16 (wenn sie es denn in HQ machen), wenn nvidia noch mit 10 auskommt.
Das erklärt auch, warum AMD sowohl anfälliger für Banding als auch für Flimmern ist. Allerdings frag ich mich, wo da der Gewinn ist, wenn man grober abstuft.
Gibt es dieses Tool irgendwo bzw. auf welchen Karten hat Mintmaster den Sample-Zähler laufen lassen.

[Gipsel]

Das erklärt auch, warum AMD sowohl anfälliger für Banding als auch für Flimmern ist. Allerdings frag ich mich, wo da der Gewinn ist, wenn man grober abstuft.Ist höchstwahrscheinlich einfacher in der Umsetzung. Ich meinte damals zwar, daß durch das Loopen durch die TMUs bei AF das unterschiedliche Gewichten und auch von Zweierpotenzen unterschiedliche Samplezahlen fast umsonst gehen sollte, aber wer weiß an was ich nicht denke. Ich muß die Karten ja nicht bauen ;)
Gibt es dieses Tool irgendwo bzw. auf welchen Karten hat Mintmaster den Sample-Zähler laufen lassen.
Das Tool ist dort im Thread verlinkt (http://forum.beyond3d.com/showthread.php?p=1505365#post1505365). Die Erklärung dazu gibt es eine Seite vorher.

So weit ich das sehe, hat Mintmaster nur die Ergebnisse der GTX460 interpretiert (darauf lief das). Im Thread gibt es aber sowohl Ergebnisse für HD4k/HD5k/HD6k-Karten (die sind nicht so sehr ergiebig, außer daß man die Zweierpotenzen extrahieren kann) als auch ältere nvidia-GPUs.

[Coda]

Das erklärt auch, warum AMD sowohl anfälliger für Banding als auch für Flimmern ist. Allerdings frag ich mich, wo da der Gewinn ist, wenn man grober abstuft.
Weniger Logik. Gewinnen tut man dadurch aber im Endeffekt nichts. Mich wundert, dass sie das immer noch so machen.

[Langenscheiss]

@Gipsel
Okay danke. Hab mir mal die Funktionsweise reingezogen. Leider kann man damit nicht sehen, wie genau der footprint behandelt wird, aber als Sample-Zähler sollte es an sich funktionieren. Allerdings geht das Programm, so wie ich das sehe, von gleichen Gewichtungen aus, denn es zählt die Anzahl der verschiedenen Graustufen, die bei der Interpolation über ein statistisches schwarz-weiß Rauschen mit anisotropem point sampling nur dann der Anzahl der verwendeten AF-Samples entspricht, wenn die Gewichtung jedes Samples bei jeder Verzerrung einer Stufe gleich bleibt (sonst kämen eventuell weitere samples bei der Zählung hinzu). EDIT: Naja, mintmaster hats ja interpretiert.
Frage mich dann aber doch, warum das Ergebnis bei AMD so perfekt ist, aber andererseits der Übergang der effektiven Filterung, welche ja mit dem D3DFilterTester zu erkennen ist, trotzdem so weich ist.
Jedenfalls danke ich für die Verlinkung.

@Coda
Bin nun kein Hardware-Experte, aber wenn es für mich keinen triftigen Grund, also eventuell irgendwas in den TMUs, gäbe, der mich davon abhalten würde, in 2er Schritten abzustufen, dann würde ich das auch machen. Gut, die Referenz-Implementierung mit 2er Potenzen spart Logik, aber die Winkelinvarianz lässt doch widerum auf einen Zusatz an Logik schließen oder? Ich mein, bei den offensichtlichen Problemen mit Flimmern, banding wäre das für mich kein sinnvoller trade-off, also Logik sparen durch Abstufung in 2er Potenzen, und dafür zusätzliche Logik in die Winkelunabhängigkeit investieren, obwohl die geringe Winkelabhängigkeit der Nvidia-Karten doch nun wirklich kaum auffällt.

[Coda]

Die Logik für das Zusammenrechner ist einfacher wenn man durch Zweierpotenzen dividieren kann. Aber das sind doch alles Spekulationen. ATI wird schon seinen Grund gehabt haben das so zu machen damals.

die geringe Winkelabhängigkeit der Nvidia-Karten doch nun wirklich kaum auffällt.
Sie fällt überhaupt nicht auf. Das sieht man schlichtweg nicht.

[Gipsel]

Coda, hast Du Dir eigentlich mal den Filter des D3D10 ReferenceRasterizers angesehen? Also mir erscheint der etwas eigenartig zu arbeiten.

Vielleicht erinnerst Du Dich noch daran, daß ich vor einiger Zeit vorgeschlagen habe, das Samplemuster über einen Pixelshader sichtbar zu machen. Hatte da nie Zeit/Lust, mal auszuprobieren, ob das überhaupt klappt, aber ich habe mich gestern Abend dann mal kurz hingesetzt.

Also, was habe ich gemacht? Im Prinzip genau das, was ich damals in der PM beschrieben habe, allerdings für das Bild unten ohne LODBias (warum kommt später), dafür mit colored MipMaps. Die Anisotropie ist genau 10. Die durchgezogenen Linien kennzeichnen den Pixel-Footprint.

http://www.abload.de/img/refrast_aniso_105hpv.png

Blau ist die MipMap, die er bis zu Aniso=8 ausschließlich benutzt (bei konstanter Pixelbreite in uv-Kordinaten), das Grüne ist die nächste, höherauflösende MipMap (die bis Aniso=16 reicht, also in dem Fall die höchste).

Irgendwie fällt auf, daß die höherauflösende MipMap exakt über die Hälfte der Länge der niedriger auflösenden Map gesampelt wird, oder? Das dürfte dann auch beim RefRast zu einer leichten Flimmerneigung führen. Offensichtlich werden keine trilinearen Samples genommen und verrechnet, sondern zwei Reihen (aus den zwei beitragenen MipMaps) bilinearer Samples, die dann entsprechend dem LOD gewichtet gemittelt werden. Dabei werden die Offsets für die bilinearen Textursamples für die beiden Reihen nicht in normalisierten uv-Koordinaten ermittelt, sondern offensichtlich absolut im "MipMap-Space" (und wird die gleiche Länge in Texeln, aber unterschiedliche in uv-Koordinaten für beide MipMaps benutzt!), so daß eben für die verschiedenen MipMaps über verschiedene reale Längen gesampelt wird. Anders gesagt, es gibt offenbar eine feste Beziehung zwischen dem LOD und der Länge der LOA (gemessen wieder in Texeln in den MipMaps), die für alle MipMaps gilt (*).

Also ich würde das deutlich suboptimal nennen. Aber es spart natürlich, weil die Offsetberechnung einfacher wird und man auch an der Mittelung spart. Allerdings ist das irgendwie unschön.

(*):
Deswegen kann man beim refRast mit dem LODBias auch nicht die einzelnen Samplepositionen direkt sichtbar machen. Mit aktiviertem LODBias wird die Länge der LOA verändert, bzw. die Länge, über die gesampelt wird. Könnte bei echten GPUs aber anders sein, wenn die das anders (ordentlich) imlementiert haben (Gradienten bestimmen Länge der LOA und das LOD, aber LOD kann man eben danach noch einen Bias verpassen oder Clampen und nicht andersrum).

Edit:
Vergeßt das oben mal alles. Ich glaube, da muß ich in einer ruhigen Stunde nochmal scharf drüber nachdenken. Irgendwie habe ich aber momentan selten Lust, mich da ranzusetzen X-(

[Langenscheiss]

Für die letzliche Mittelung gibt es vom Rand des footprints also nur bilineare Daten. Könnte mMn je nach Gewichtung der äußeren Samples zu Problemen mit höher frequenten Texturen geben, aber ich schätze, dass man den möglichen Effekt theoretisch schlecht einschätzen kann, zumal, wie du ja sagst, nicht klar ist, ob GPUs auch bilineare Sample-Reihen nehmen oder direkt über die UV-Koordinaten trilinear sampeln. Insbesondere AMD scheint ja, wie im B3D-Forum erklärt wurde, mehr mit den offsets zu arbeiten (gemäß des Sample-Zählers gleiche Gewichtung bei 2^n <= 16 Samples) als mit Gewichtung und Anzahl der Samples, insofern schätze ich schon, dass wir bei GPUs ein anderes Verhalten sehen würden. Zumindest bei AMD würde ich echte trilineare Samples vermuten...??

[Nighthawk13]

Ein(das?) mathematische Grundlagenpaper: "Fundamentals of texture mapping and image warping" von Paul Heckbert(1989):
www.cs.cmu.edu/~ph/texfund/texfund.pdf
Nicht gerade ne leichte Freizeitlektüre;)

Zwei Stellen zum Reinschnuppern:
Chapter 2: linears vs. projektives Texturemapping(Bild 2.2+3)
Chapter 3.5.4: anisotrope Abtastverteilung(Bild 3.13-15)

[aths]

Die schlagen bereits "RIP-Mapping" vor, wenn auch unter anderen Namen ("4-D image pyramid".)

[mekakic]

Kann mir jemand helfen in der Beurteilung, was ein 3D Filter beim downscaling leisten kann? Hoffe das passt hier rein.

Ich sitze gerade an einem SDK und stelle mit einem OpenGL Render eine große Textur dar, die jede Menge Text und grafische Strukturen enthält (eine Landkarte). Diese Karte wird von einem Raster Objekt erzeugt, wo ich die Filterung angeben kann. Ich teste mit Bicubic oder Bilinear oder eben mit Nearest Neighbor.

Wenn ich herauszoome auf z.B. etwa 25% sehe ich heftige Unterabtast/Aliaising Artefakte in Text und Linien, so dass man nichts mehr erkennen kann. Dabei ist kein Unterschied erkennbar ob ich Bicubic oder Bilinear oder eben mit Nearest Neighbor als Filter wähle. Gefühlt geht das in die Richtung, wenn man früher bei einem Spiel Mip-Mapping deaktiviert hat (darauf hab ich hier aber AFAIK keinen Einfluß).

Wenn ich allerdings die Ausgangstextur in einem Grafikprogramm mit Bikubisch oder Bilinear auf ebenfalls 25% herunterrechne, sieht das deutlich besser aus als das was ich in meiner Szene sehe. Wieviel kann der Grafikchip beim herunterrechnen einer Textur leisten, so dass das ganze mit einem Algorithmus eines Grafikprogramm vergleichbar ist?


PS: Das Bild aus dem ersten Post ist leider nicht mehr sichtbar.

[Coda]

Der Thread passt nicht wirklich, aber um die helfen zu können fehlen leider Informationen. Was genau macht dieses "Raster Objekt"? Wo wird der Filter den du angibst genau angewendet?

Am besten sag uns einfach welches SDK es ist.

[FatBot]

Ist AF jetzt nicht mehr nötig bei 4K, wüsste nicht, das Auflösung auch AF ersetzt :conf2:
Hatte schon mal im Titan X Thread gefragt, PhuV sagte, er spiele in UHD immer ohne AA und AF und fände die Test mit 4AA/16AF sinnfrei. Da hat die Frage aber keine richtige Resonanz gefunden, ich hoffe, wegen Offtopic und nicht wegen Dämlichkeit.
Das Problem der Texturanpassung/MIP-Stufen bleibt doch auch bei hohen Auflösungen bestehen, oder habe ich das falsch verstanden und die Lösung ist dann sozusagen Übersamplen mit hohen Auflösungen?

[Coda]

4K gegenüber 1080p hat einen Effekt wie 2xAF bei gleicher Bildschirmgröße. Ich würde zumindest 4xAF dazuschalten.

[robbitop]

Zumal AF bei den meisten PC Spielen eh nicht viel kostet.

[Jupiter]

Höherwertiges AF soll jedoch mehr Frametime kosten. Da lohnt es sich nicht immer das höherwertige AF zu nehmen.

[FatBot]

4K gegenüber 1080p hat einen Effekt wie 2xAF bei gleicher Bildschirmgröße. Ich würde zumindest 4xAF dazuschalten.
um auf mindestens 8xAF als allgemein mindestens empfohlenen Wert zu kommen. Aha, besten Dank, lag ich mit meiner Einschätzung nicht gänzlich daneben.

[MrSchmelzer]

@coda:

Leider fehlt dem Eingangs-Posting dieses Threads die anfangs verlinkte
Grafik, also die Datei, die zuvor hier zu finden war:

http://axelgneiting.de/files2/afillustrated.png

Wäre es möglich, das erste Posting so zu bearbeiten, dass dieses
Bild wieder zur bereit steht?

[Coda]

Done.

[Rooter]

http://axelgneiting.de/files2/afillustrated.png

Wäre es möglich, das erste Posting so zu bearbeiten, dass dieses
Bild wieder zur bereit steht?"404 - Not Found" :(

MfG
Rooter

[Locuza]

Das war die Grafik die Coda bei imgur neu hochgeladen hat:
https://i.imgur.com/mBYhlZF.png

[Hallo]

4K gegenüber 1080p hat einen Effekt wie 2xAF bei gleicher Bildschirmgröße. Ich würde zumindest 4xAF dazuschalten.

Schliesse mich FatBot an, was hat Res. mit AF zu tun? Ausser das man bei 4k mind. auf 8AF setzten sollte wenn man was von den tollen Texturen weiter als 2 Meter was haben will.

Sind MipMap "Ebenen" mit Res. verbunden? Komisch.

Wenn ich Emus von 496x384 auf 1080p booste ändert sich nichts an MipMap.


Mist, sehe grad das ich n thread gravedigger bin, sorry...

[Raff]

Wenn eine Achse doppelt so fein abgetastet wird, verschieben sich die MIP-Maps entsprechend. Das gilt nicht nur bei nativer Auflösung, sondern Auflösung generell. Heißt: Egal, ob man Ultra HD nativ oder 2×2 SSAA auf einem Full-HD-LCD mittels Downsampling nutzt, man erhält den Effekt von 2:1 AF gegenüber Full HD ohne SSAA/AF. Packt man hier noch 16:1 AF dazu, erhält man 32:1 AF (ggü. FHD nativ).

MfG,
Raff

[Hallo]

Ah, ok. Danke für die Erläuterung.

[Geldmann3]

Im Folgenden habe ich den anisotropischen Effekt bei höheren, internen Auflösungen hier mal in GTA V visualisiert :smile:

2K AF Vergleich (1xAF - 256xAF)
https://i.ibb.co/NKgCnV4/Compare-GTAV.png (https://imgsli.com/Njg5MDM/0/8)

Wichtig ist es, das Augenmerk auf die Bodentexturen in der Ferne zu legen, ab 32x nimmt natürlich auch die Qualität der Kanten zu, da ich 32xAF via. 2xOGSSAA + 16xIngame-AF realisiert habe.
Doch ich denke, es ist deutlich zu sehen, dass die Texturen in der Full-HD-Auflösung noch bis hoch zu 256xAF profitieren.

In Full-HD verliere ich mit der RTX 3090 bis 32xAF quasi keinerlei Performance, obwohl ich es teilweise via Supersampling realisiere, komme ich nicht aus dem CPU-Limit heraus.
Ein lohnenswertes Performance-Investment.

Mit 64xAF verliere ich dagegen immerhin 3% Performance, mit 128x 32% Performance und mit 256x 54% Performance.
Aber hey, ich betreibe an dieser Stelle immerhin 16xOGSSAA zu den 16xAF, eine mindblowing Show, welche die RTX 3090 hier abliefert.
Könnte die GPU 256xAF in Hardware, würde ich davon ausgehen, dass es weniger als 15% Performance kostet.

Da gab es doch mal einen tollen Artikel vom Raff (https://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/Tests/64x-48x-und-32x-gegen-16x-AF-Zukunft-trifft-Gegenwart-813322/) dazu.

Eventuell bekommen wir dank mehr Konkurrenz im GPU-Markt in Zukunft ja mehr als 16xAF in Hardware spendiert.
Die Bilder zeigen deutlich, dass es sich lohnen könnte.

Selbst in 4k sind noch leichte Qualitätsverbesserungen bis 64x AF zu sehen.

4K AF Vergleich (1xAF - 64xAF)
https://i.ibb.co/NKgCnV4/Compare-GTAV.png (https://imgsli.com/Njg5MDI/0/6)

Auch in 4K verliert die RTX 3090 nur mickrige 3% Performance für 16xAF, 34% für 32xAF und 55% für 64xAF.
Achtung 32x sowie 64x sind via Supersampling realisiert, die GPU könnte das in Hardware wesentlich schneller.
Das ist die Dampfhammer-Methode. Auch hier würde ich auf unter 15% Performance Verlust tippen, wenn die GPU das in Hardware könnte.

Erst in 8K wirken 8xAF für mich optimal.
Streng genommen, wenn das Bild groß genug ist, profitiert man natürlich in jeder Auflösung von 256xAF, doch bei 8K wird der Gewinn aufgrund der hohen Pixeldichte über 8xAF, selbst auf einem großen TV, praktisch negiert.

Um das zu belegen, im Folgenden ein 8k Screenshot-Vergleich.
Betrachter ohne 8k-TV müssen an dieser Stelle definitiv zoomen.

8K AF Vergleich (1xAF - 16xAF)
https://i.ibb.co/NKgCnV4/Compare-GTAV.png (https://imgsli.com/Njg4ODk/0/4)

Zwischen 8xAF und 16xAF ist in 8k nicht mehr wirklich ein Benefit zu erkennen.
Messbar sind die Verbesserungen definitiv auch in 8K bis 256xAF, was man an den nicht komplettierten Linien auf den Texturen in der Ferne erkennen kann (Wenn man sehr nah ran geht), doch im Gameplay merkt man nichts davon, würde ich behaupten.

Selbst in 8K verliert die RTX 3090 lediglich 4% Performance für 16xAF.

Aufgrund der Performancemetriken bei 16xAF ist es mir schon immer ein Rätsel gewesen, wenn Konsolenspiele an dieser Stelle Performance sparen wollen.
Vor allem da 8xAF+ bei Auflösungen unter 8K auf jeden Fall für schärfere Texturen sorgt.

[Platos]

Also zwischen 128x und 256x sehe ich ehrlich gesagt nur schwer einen Unterschied bzw. muss ich die schon wirklich suchen gehen. Zwischen 64x und 128x ist es dann aber wirklich ein sehr grosser Unterschied.

Bei 4k sehe ich zwischen 32x und 64x dann aber lustigerweise wieder einen (kleineren) Unterschied (vlt. weil das FHD Bild kleiner ist). Zwischen 16x und 64x ist es aber wie Tag und Nacht. Da sieht 16x echt schlimm aus.

Und bei 8k sehe ich dann (mit meinem 4K Display) keinerlei Unterschiede zwischen 8x und 16x. Sieht tatsächlich in der weiten Ferne noch besser aus (selbst auf meinem nur 4k Display). Aber ich glaube, ich würde es in diesem Spiel mittem im Spielgeschehen trotzdem nicht lohnenswert finden.

Aber das viel wichtigere als die Optik sind hier die FPS. Unter 8K kriegst du selbst mit 16x noch 43FPS, während dem du bei 4k und 64x auch nur 43FPS hast. 8k ist natürlich dann vorzuziehen. Und selbst 32x unter 4K hat "nur" 50% mehr FPS, wie unter 8k. Bei FHD das selbe Spiel. Da setzt es einfach etwas später ein (Evtl weil CPU Limit?).

Mein Fazit wäre dann: Ja, es sieht in manchen Fällen deutlich besser aus, aber mehr wie 32x lohnt sich in 4k kein bisschen (und selbst das ist fragwürdig) und in FHD lohnt sich mehr wie 64x kein bisschen. 32x kostet unter 4k "nur" 50% mehr Leistung, da würde ich vlt. schon auf 8K mit dafür niedrigeren Details schielen. Unter FHD ist es schwierig zu beurteilen, da du dort vermutlich schon im CPU Limit steckst.

Also ich würde sagen, mehr wie 16x brauchts nicht, lieber auf 8k "hinarbeiten" ^^ Notfalls dann eben mittels DLSS. 8k DLSS mit 16x sieht bestimmt besser aus wie 4k 32x nativ und der FPS Unterschied wird dann vermutlich nicht gross sein (8kDLSS x16 vs 4k Nativ x32).

Edit: Aber interessant wäre natürlich ein Spiel das etwas neuer als 2013 ist :D