"Anisotropes" Pixelshading

[aths]

Beim Pixelshader besteht ja das Problem, dass pro Pixel nur eine Sample generiert wird:

http://www.aths.net/files/pixel1.png

Nun könnte man auf die Idee kommen, "trilinear" zu schaden. Weil wir keine MIP-Maps haben, generieren wir 2 Samples, die je nach Neigung des Polygons erzeugt werden (Beispiel: Flach von vorne)

http://www.aths.net/files/pixel2.png

und blenden in dieses Ergebnis langsam von dem 1-Sample-Farbwert ausgehend über. Nachteil: Man muss gleich 3 Samples berechnen. Einfacher wäre imo folgendes:

http://www.aths.net/files/pixel3.png

Die Subpixel werden von der Mitte ausgehend "aufgeteilt" und auseinander geschoben. Erreichen sie ihre neue "mittige" Position, werden sie erneut "gespalten":

http://www.aths.net/files/pixel4.png

Das wäre sozusagen "adaptives Supersampling".

[Pussycat]

Die Anzahl der Samples willst du durch die Entfernung bestimmen?

Eigentlich müsste man dafür je die Schärfe des noch nicht bekannten Ergebnisses haben. Damit könnte man ja besser entscheiden ob SSAA sinnvoll ist, also bei matschigen texturen nicht, bei Texturen mit Texel/Pixel-verhältnis > 1 sehr viel (jaja, sollte durch LOD nicht vorkommen, aber tut's doch manchmal). Dazwischen eben zwischenstufen.

Aber wieso nur für pixelshader? So wäre ein adaptives FS-SSAA möglich! Nur ist das warscheinlich nicht sehr gewollt weil es bestimmt nicht schneller als MSAA ist, wenn auch besser.

Problem wäre die Schärfebestimmung. Hast du dafür eine bessere idee als Vorgeben durch's Programm?

[aths]

Originally posted by Pussycat
Die Anzahl der Samples willst du durch die Entfernung bestimmen?Nein, eher über den Neigungswinkel.
Originally posted by Pussycat
Eigentlich müsste man dafür je die Schärfe des noch nicht bekannten Ergebnisses haben. Damit könnte man ja besser entscheiden ob SSAA sinnvoll ist, also bei matschigen texturen nicht, bei Texturen mit Texel/Pixel-verhältnis > 1 sehr viel (jaja, sollte durch LOD nicht vorkommen, aber tut's doch manchmal). Dazwischen eben zwischenstufen. Um normale Texturen gehts gar nicht.
Originally posted by Pussycat
Aber wieso nur für pixelshader? So wäre ein adaptives FS-SSAA möglich! Nur ist das warscheinlich nicht sehr gewollt weil es bestimmt nicht schneller als MSAA ist, wenn auch besser. Für normale Texturen gibts ja schon den anisotropen Filter, was im Prinzip adaptivem Supersampling entspricht.
Originally posted by Pussycat
Problem wäre die Schärfebestimmung. Hast du dafür eine bessere idee als Vorgeben durch's Programm? Soviel, wie er "braucht", bis zu einem einstellbaren Maximal-Level.

[Pussycat]

Originally posted by aths
Nein, eher über den Neigungswinkel.


Bessere idee ja. Hatte nicht ganz nachgedacht.

Originally posted by aths
Um normale Texturen gehts gar nicht.


Habe mich da vielleicht unglücklich ausgedrückt. Letzendlich sieht das, was aus dem PS rauskomt aus wie eine Textur, die auch eine gewisse Schärfe hat.

Originally posted by aths
Für normale Texturen gibts ja schon den anisotropen Filter, was im Prinzip adaptivem Supersampling entspricht.

Ja, dass stimmt. Aber ein AF der auch schärfe beachtet, wäre deutlich besser. Auch Lichtverhältnisse beachten (sehr dunkel -> weniger AF nötig) wäre IMO sehr sinvoll, wobei das leztere warscheinlich noch viel einfacher ist.

Originally posted by aths
Soviel, wie er "braucht", bis zu einem einstellbaren Maximal-Level.

Ja, da war ich auch scon drauf gekommen. Aber wie weiss man, wieviel man braucht?

[betasilie]

Originally posted by Pussycat
... Auch Lichtverhältnisse beachten (sehr dunkel -> weniger AF nötig) wäre IMO sehr sinvoll, wobei das leztere warscheinlich noch viel einfacher ist.
Das stelle ich mir aber sehr aufwendig vor, denn sowas mit Echtzeitbeleuchtung zu beachten wäre sicherlich aufwendig.

Entfernung und Neigungswinkel sind da doch sicherlich die leichter benutzbaren Werte. (?)

[Xmas]

Entfernung ist zu diesem Zweck überhaupt nicht zu gebrauchen. Ein 10m großes Objekt in 100m Entfernung sieht ohne räumliche Sicht und Fokussierung genau so aus wie ein 1m großes Objekt in 10m Entfernung.

Im Grunde müsste man eine "virtuelle Auflösung" für den Shader angeben, die angibt was die höchstmögliche "Frequenz" der resultierenden Oberflächenstruktur ist. Mit dieser virtuellen Auflösung (und dem entsprechenden Abbildungsverhältnis auf Pixel) wird wie bei Mip-Maps dann ein LOD ermittelt.

Edit: Ach ja, ich sollte wohl hinzufügen dass es rechnerisch oft gar nicht möglich ist eine solche virtuelle Auflösung zu bestimmen... aber irgendwas ist ja immer.

[Pussycat]

Mit echtzeitbeleuchtung sicher, aber wenn der Lightmap (wenn es sowas in Zukunft noch gibt) sehr dunkel ist, kann man ja davon ausgehen dass das Endergebnis nichts sehr deutlich erkennbar sein wird.

p.s: Bewegungsgeschwindigkeit fällt mir gerade noch ein. Statische Objekte kann man viel besser beobachten als dynamische.

[betasilie]

Originally posted by Pussycat
Mit echtzeitbeleuchtung sicher, aber wenn der Lightmap (wenn es sowas in Zukunft noch gibt) sehr dunkel ist, kann man ja davon ausgehen dass das Endergebnis nichts sehr deutlich erkennbar sein wird.

p.s: Bewegungsgeschwindigkeit fällt mir gerade noch ein. Statische Objekte kann man viel besser beobachten als dynamische.
Ja klar, mit Lightmaps wäre das sicher leichter machbar, aber ich hoffe es hat sich bei Spielen bald ausgelightmapped. ;)

[MeLLe]

Originally posted by Pussycat
Bewegungsgeschwindigkeit fällt mir gerade noch ein. Statische Objekte kann man viel besser beobachten als dynamische.
Die GPU weiss aber nicht, welche Objekte dynamisch, welche statisch sind. Sie rendert stur Frame für Frame und weiss weder über das letzte noch über das nächste Frame Bescheid. Damit fällt diese Idee dann als Ansatz aus ...

[aths]

Habe ich jetzt was missverstanden? Mein Vorschlag hat mit Lightmaps nichts zu tun.

[KiBa]

moin, ich hab dich noch nicht ganz verstande, was du meinst, aths...

"Beim Pixelshader besteht ja das Problem, dass pro Pixel nur eine Sample generiert wird"

warum ist das ein problem? woran erkennst du das?
das einzige, was mich beim einsatz von pixelshadern stört, ist, das es z.b. bei wasseroberflächen in der ferne zu aliasing kommt und das bild oft unruhig wirkt. das liegt aber wohl eher daran, dass ein ergebnis des pixelshaders zur weiterverarbeitung in eine textur gerendert wird. für diese textur fehlen dann allerdings die mipmaps und viele karten unterstützen die automatische generierung dieser bei dynamischen texturen nicht. in dx9 gibt es jetzt die möglichkeit, explizit mipmaps generieren zu lassen, mit IDirect3DBaseTexture9::GenerateMipSubLevels() und SetAutoGenFilterType(), was mein problem wohl beseitigen könnte. vielleicht meinst du aber was ganz anderes?

[aths]

Originally posted by KiBa
vielleicht meinst du aber was ganz anderes? MIP-Mapping würde das Aliasing auf Kosten der Schärfe eliminieren. "Anisotropes" Pixelshading würde das Wasser sowohl artefaktfrei, als auch "scharf" rendern.

[Xmas]

Originally posted by KiBa
moin, ich hab dich noch nicht ganz verstande, was du meinst, aths...

"Beim Pixelshader besteht ja das Problem, dass pro Pixel nur eine Sample generiert wird"

warum ist das ein problem? woran erkennst du das?
das einzige, was mich beim einsatz von pixelshadern stört, ist, das es z.b. bei wasseroberflächen in der ferne zu aliasing kommt und das bild oft unruhig wirkt. das liegt aber wohl eher daran, dass ein ergebnis des pixelshaders zur weiterverarbeitung in eine textur gerendert wird.
Nein, das Problem ist ein anderes. Es wird eben nicht in eine Textur gerendert die dann gefiltert angezeigt wird, sondern pro Pixel ein Wert per PS ermittelt.
Um es mal signaltheoretisch anzugehen, Die PS-Funktion kann viel höhere Frequenzen aufweisen als die Eingabefunktionen (= Texturen). Ein Shader der nur 256x256 Texturen verwendet kann trotzdem ein Ergebnis haben, dass eine Auflösung von 10000x10000 braucht, um akkurat abgebildet zu werden.

[aths]

Ja, sorum kann man es auch sagen - bisherige PixelShader verletzen gerne mal das Nyquist-Kriterium.

Was ich nun möchte ist nicht nur einfach das mit Unschärfe hinzukriegen, sondern einen möglichst "natürlichen" Anblick erzeugen. Dazu muss imo auch das Sampling anisotrop erfolgen, es reicht nicht, anisotrop gefilterte Texturen zu verwenden (sofern das überhaupt gemacht wird, imo sampeln PixelShader die Textur nur bilinear, oder irre ich hier?)

[Demirug]

Originally posted by aths
Ja, sorum kann man es auch sagen - bisherige PixelShader verletzen gerne mal das Nyquist-Kriterium.

Was ich nun möchte ist nicht nur einfach das mit Unschärfe hinzukriegen, sondern einen möglichst "natürlichen" Anblick erzeugen. Dazu muss imo auch das Sampling anisotrop erfolgen, es reicht nicht, anisotrop gefilterte Texturen zu verwenden (sofern das überhaupt gemacht wird, imo sampeln PixelShader die Textur nur bilinear, oder irre ich hier?)

Die Pixelshader sampeln so wie es für den Sampler eingestellt wurde. Das Problem ist aber wie schon richtig erkannt wurde das ein Pixelshader selbst nicht unbedingt eine lineare Funktion wiederspiegelt.

Nehmen wir jetzt mal einen NV25 als Beispiel. 2 Bi samples und 2 Shaderops pro pipe pro Takt.

Der grösste mögliche Shader darf 4 Samples und 8 Ops enthalten.

Um nun diese Samples zu erzeugen braucht man in abhängikeit der AF Stuffe unterschiedliche viele Takte.


Mode Takte max ops
1x tri 4 8
2x tri 8 16
4x tri 16 32
8x tri 32 64


Im Moment wir ja erst das Textursampeln durchgeführt und die die fertigen Samples im Pixel Shader benutzt.

die AF einheit bestimmt nach wie vor die Sample Positionen. Es wird nun aber nur noch ein bi oder tri sample für jede berechnete Position bestimmt. Diese Werte werden dem Pixelshader übergeben welcher den entsprechenden Farbwert berechnet. Dieser Vorgang wird nun für jede Sample position wiederholt. Am ende werden die Farbwerte der Pixelshader Programme nach den regeln des AF zusammengerechnet.

Das Problem dabei ist nur das alle Texturen mit der gleichen AF stuffe gefiltert werden.

Deswegen wäre es wohl besser wenn man für den Pixelshader selbst die maximale AF Stuffe vorgeben könnte. Diese müsste dann gegen die af stuffe der Texturen verechnet werden.

Also wenn man den Pixelshader nun mit 2 af benutzten will und die Textur auf 4 af steht würde man die Textur dann 2 * 2 AF filtern. bei 2 af dann natürlich 2 * 1 af.

Das Problem dabei ist nur das wir sowas niemals mehr zu sehen bekommen werden. Da die PS 3.0 es erlauben das AF selbst zu programmieren.

[zeckensack]

Originally posted by Xmas
Entfernung ist zu diesem Zweck überhaupt nicht zu gebrauchen. Ein 10m großes Objekt in 100m Entfernung sieht ohne räumliche Sicht und Fokussierung genau so aus wie ein 1m großes Objekt in 10m Entfernung.

Im Grunde müsste man eine "virtuelle Auflösung" für den Shader angeben, die angibt was die höchstmögliche "Frequenz" der resultierenden Oberflächenstruktur ist. Mit dieser virtuellen Auflösung (und dem entsprechenden Abbildungsverhältnis auf Pixel) wird wie bei Mip-Maps dann ein LOD ermittelt.Einspruch! :)

Die Information ist bereits da. Ein transformierter Vertex ist unter anderem auch eine homogene Koordinate (x,y,z,w). w gibt ganz bequem das Texel/Pixel-Verhältnis an und wird auch für 'perspektivisch korrektes Texturfiltern' (die älteren werden sich an diesen Begriff noch erinnern), aka vernünftiges Mipmapping eingesetzt. Bei projizierten Texturen kommt dann noch q, die vierte Texturkoordinate ins Spiel, das Verhältnis ergibt sich dann aus w/q.

Die 'Steilheit' von w in der x- und y-Richtung ist einer der Parameter, die der Dreiecksinterpolator erzeugt. Wenn diese beiden Parameter unterschiedlich sind, ist das Dreieck in die Bildebene geneigt und ist damit ein Kandidat für den anisotropen Filter.

=> Information ist in der Pipeline vorhanden, kann nur bisher nicht außerhalb der Textursampler genutzt werden.

[Xmas]

Originally posted by zeckensack
Einspruch! :)

Die Information ist bereits da. Ein transformierter Vertex ist unter anderem auch eine homogene Koordinate (x,y,z,w). w gibt ganz bequem das Texel/Pixel-Verhältnis an und wird auch für 'perspektivisch korrektes Texturfiltern' (die älteren werden sich an diesen Begriff noch erinnern), aka vernünftiges Mipmapping eingesetzt. Bei projizierten Texturen kommt dann noch q, die vierte Texturkoordinate ins Spiel, das Verhältnis ergibt sich dann aus w/q.

Die 'Steilheit' von w in der x- und y-Richtung ist einer der Parameter, die der Dreiecksinterpolator erzeugt. Wenn diese beiden Parameter unterschiedlich sind, ist das Dreieck in die Bildebene geneigt und ist damit ein Kandidat für den anisotropen Filter.

=> Information ist in der Pipeline vorhanden, kann nur bisher nicht außerhalb der Textursampler genutzt werden.
Ähm, ich verstehe jetzt wirklich nicht ganz was du sagen willst...

W gibt nicht das Texel/Pixel-Verhältnis an - wenn es das tun würde müsste es W pro Fläche, nicht pro Vertex geben.

Perspektivisch korrektes Texture Mapping hat nichts mit Mip-Mapping zu tun.

Und von welcher "Information" sprichst du. Die "virtuelle Auflösung" des Shader-Programms wird einzig und allein durch den Shader-Code selbst und die Auflösung der benutzten Texturen bestimmt. Das entsprechende Abbildungsverhältnis soll natürlich genau wie bei Mip-Mapping berechnet werden, als hätte man tatsächlich eine Textur in dieser "virtuellen Auflösung".

[zeckensack]

Originally posted by Xmas
Ähm, ich verstehe jetzt wirklich nicht ganz was du sagen willst...Ich wollte sagen, daß die Information über die 'Anisotropie' und die 'maximale Frequenz' tatsächlich in der Pixelpipeline vorhanden sind.

Die Texturfilter nutzen sie, es gibt einfach nur bisher keine Möglichkeit aus einem Shader darauf zuzugreifen.

Ohne Delta-X/Delta-W und Konsorten pro Pixel wären anisotrope Texturfilter garnicht implementierbar.

[zeckensack]

Originally posted by Xmas
W gibt nicht das Texel/Pixel-Verhältnis an - wenn es das tun würde müsste es W pro Fläche, nicht pro Vertex geben.W ist immerhin der Divisor der Perspektivkorrektur und wird idR pro Pixel interpoliert. Meine Formulierung war falsch, das stimmt und danke für den Hinweis :)
*schäm*
W ist nicht das Texel/Pixel-Verhältnis, dazu muß noch die Auflösung des Miplevels 0 und die Fläche eines Pixels mit einberechnet werden.
Perspektivisch korrektes Texture Mapping hat nichts mit Mip-Mapping zu tun.Doch! Perspektivisch korrekt bedeutet doch nur, daß die Berechnungen pro Pixel ausgeführt werden, und nicht pro Vertex. Dazu müssen die entsprechenden Vertexparameter über das Dreieck interpoliert und pro Pixel ein neuer hmmm ... 'Vergrößerungsfaktor' berechnet werden. Anders geht's nicht :)

ZB die Miplevel-Bestimmung für trilinearen Filter würde nichts bringen, wenn sie nur pro Vertex und nicht pro Pixel gemacht würde.

Und von welcher "Information" sprichst du. Die "virtuelle Auflösung" des Shader-Programms wird einzig und allein durch den Shader-Code selbst und die Auflösung der benutzten Texturen bestimmt. Das entsprechende Abbildungsverhältnis soll natürlich genau wie bei Mip-Mapping berechnet werden, als hätte man tatsächlich eine Textur in dieser "virtuellen Auflösung". Joa.
Was dann fehlt ist der Frequenzumfang des Shaders, den muß natürlich derjenige liefern, der den Shader entworfen hat.
Aber die restlichen Infos (Delta-X/-W in X-Richtung und Delta-Y/-W in Y-Richtung) sind in der Pipeline ... irgendwo. Nur halt nicht im Shader verfügbar.

Dort kann ich die interpolierten homogenen Raum- und Texturkoordinaten abgreifen, was man aber wissen müsste ist, wie schnell sich diese ändern (erste Ableitung, wenn man so will).

[Demirug]

zeckensack,

die Information ist ab PS 2.0+ (als option) und bei PS 3.0 (als Pflicht) verfügbar. In der DX9 Dokumenation unter dsx und dsy zu finden.

[zeckensack]

Na dann paßt ja alles. =)

[Xmas]

Originally posted by zeckensack
Doch! Perspektivisch korrekt bedeutet doch nur, daß die Berechnungen pro Pixel ausgeführt werden, und nicht pro Vertex. Dazu müssen die entsprechenden Vertexparameter über das Dreieck interpoliert und pro Pixel ein neuer hmmm ... 'Vergrößerungsfaktor' berechnet werden. Anders geht's nicht :)
Ja, du und dv müssen Pro Pixel berechnet werden (oder möglicherweise auch nur alle 4 Pixel). Aber dafür braucht es keine Mipmaps, weswegen ich den Zusammenhang zwischen "perspektivisch korrekt" und Mipmaps nicht verstand :)

Das Problem mit der "Shaderfrequenz" ist eben dass sie manchmal praktisch unbestimmbar ist, oder oft auch viel zu hoch. Wobei das ja durchaus der Realität entspricht, nur dass ein paar Besonderheiten des Auges "Texturflimmern" verhindern ;)

[aths]

*Vorsichtig meld*

"Mein" Vorschlag müsste das Pixelshader-Flimmern imo deutlich senken. Imo sollte man auch mal gucken, ob das für "normales" AF einsetzbar ist. Wenn ja, wäre "trilineares" AF imo performanter zu machen.

[tb]

Hallo!

Man könnte auch einfach Mip-Maps für den Pixel Shader verwenden, wie bei ShaderMark. Beim Test "Cubic Environment Bumped Reflections" sieht man sehr deutlich die Unterschiede zwischen mit und ohne Mip-Maps (Shift+M).

Für prozedurale Shader kannst Du ja mal hier nachschauen
http://www-viz.tamu.edu/students/gary/617presentation/

Ist zwar nicht anisotroph, dafür heute schon machbar.

Thomas