(gelöst) Glare-Algorithmus

Für Fragen zu Grafik APIs wie DirectX und OpenGL sowie Shaderprogrammierung.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

(gelöst) Glare-Algorithmus

Beitrag von Krishty »

Nachtrag: Viel Gefluche über Compiler usw. Wer sich einfach nur den Glare anschauen möchte, kann das bei meinen Sternendemos tun.

Hi,

Kennt jemand einen guten Glare-Algorithmus (nicht bloß für das, was man gern als Bloom einbaut um HDR zu unterstreichen, sondern für die tatsächliche Streuung des Lichts in der Augenflüssigkeit)?

Die einzige Formel, die ich gefunden habe, hat das Quadrat des Winkels im Nenner und haut dadurch vorne und hinten nicht hin. Ich habe das Quadrat des Kosinus des Winkels probiert, und obwohl es für kleine Winkel (<20°) ganz gut aussah, fiel die Helligkeit danach sehr abrupt ab. Nun habe ich nicht mehr in der Hand als das Wissen, dass 8,7 % der empfundenen Helligkeit Streulicht sind.

Pic related; it's the Moon with shitty Gaussian blur in screen-space (a = 0.002). Da hat man auch wieder eine kleine monotone Fläche, die dann rapide abstürzt – ich brauche aber etwas, was erst schnell und dann immer langsamer nachlässt. Und um den Gauss über die ganzen 90° des Blicksfelds zu kriegen, reichen 32 Bits Präzision nicht aus (Blockbildung) -.-
GaussGlare.png
Zuletzt geändert von Krishty am 19.03.2011, 13:38, insgesamt 1-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
TGGC
Establishment
Beiträge: 569
Registriert: 15.05.2009, 18:14
Benutzertext: Ich _bin_ es.
Alter Benutzername: TGGC
Echter Name: Ich _bin_ es.
Wohnort: Mainz
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von TGGC »

Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von CodingCat »

Ist das Quadrat des Winkels denn wirklich so problematisch? Wolframalpha spuckt eine ganz nette Reihe für acos^2 aus:

Code: Alles auswählen

pi^2/4-pi x+x^2-(pi x^3)/6+x^4/3-(3 pi x^5)/40+(8 x^6)/45-(5 pi x^7)/112+(4 x^8)/35+O(x^9)
Das lässt sich eigentlich in recht wenige Instruktionen packen:

Code: Alles auswählen

float4 x = cosAngle;
x.yzw *= x.x; // x, x^2
x.zw *= x.xy; // x, x^2, x^3, x^4
float4 xx = x * x.w; // x^5, x^6, x^7, x^8

float acossq = pi*pi/4;
acossq += dot( x, float4(-pi, 1, -pi/6, 1/3.0) );
acossq += dot( xx, float4(-3*pi/40, 8/45.0, -5*pi/112.0, 4/35.0) );
// acossq ~= acos^2(cosAngle)
Ansonsten wie TGGC vorschlägt einfach eine einfachere ähnliche Kurve von Hand drüberzimmern. ;-)
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

@TGGC: Danke, der ist um Einiges Shader-freundlicher als der, den ich bisher benutzt habe.

@CodingCat: acos ist kein Problem; das Problem ist eher, dass dann eine Division durch Null auftritt und die Werte auch vorher schon irrsinnig groß werden. (Sorry, das ist ja nicht selbstverständlich – Lanczos hat auch den Winkel im Nenner und ist deshalb längst nicht unbrauchbar – war leider im OP schlecht (lies: garnicht) so ausgedrückt).

Wiedemauchsei, über sowas zu schlafen hilft: Linse und Glaskörper bestehen ja fast ausschließlich aus Wasser, also müsste ich die Streuformeln für Wasser direkt aufs Bild anwenden können. Ich werde direkt mal suchen, ob dabei bloß Rayleigh-Streuung zum Einsatz käme oder ob es sogar eigene Streumodelle gibt.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Glare-Algorithmus

Beitrag von eXile »

Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Aramis »

Natuerlich musst du bei der Simulation beachten dass der Glare beim Betrachten des Bildschirms ja nochmals leicht im Auge gestreut wird! :-)
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

@eXile: Danke! Ich wollte mich gerade nach On the cause of disability glare and its dependence on glare angle, age and ocular pigmentation richten, aber das wird ja locker in die Tasche gesteckt …

@Aramis: Ja, aber bei LDR-Ausgabe eben zum Glück nur leicht :)

Edit: Mann, Temporal Glare ist ein wirklich schwerer Brocken. Ich bezweifle mal, dass das für beliebige Lichtbilder funktioniert, ohne jeden Pixel zum Billboard zu machen? Hier mal ein Screenshot mit der trivialen CIE-Näherungsfunktion aus dem anderen Link; sieht schonmal bedeutend natürlicher aus als der Gauss (der Bildhintergrund ist eigentlich schwarz). Ist aber auch ohne Farbspiele schon nicht mehr wirklich echtzeittauglich.
TrivialGlare.png
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Glare-Algorithmus

Beitrag von eXile »

Krishty hat geschrieben:Mann, Temporal Glare ist ein wirklich schwerer Brocken. Ich bezweifle mal, dass das für beliebige Lichtbilder funktioniert, ohne jeden Pixel zum Billboard zu machen?
So, wie ich das Paper auf die Schnelle verstanden habe (sorry, kaum Zeit ;)), funktioniert deren Algorithmus ganz ohne Billboards. Die berechnen auf der GPU die FFT des Bildes und des Linsenfehlers, multiplizieren diese, und berechnen wiederum auf der GPU die IFFT. Herauskommt der im Paper gezeigte Glare-Effekt, völlig unabhängig von speziellen "Leuchtpunkten", oder was man auch sonst für Approximationen benutzt - das gesamte Sichtfeld wird für den Glare-Effekt zum Berechnen durchgenommen. Der nächste 3DMark hatte doch so etwas auch für Lens-Flare, nur leider finde ich das gerade nicht mehr … sieht aber ziemlich beeindruckend aus. Vorallem kann man die einmal berechnete FFT von der Szene für eine ganze Reihe von Effekten wiederverwenden, jedoch um die anschließenden IFFT (einzeln für jeden Effekt) kommt man leider nicht drum rum.

Natürlich ist das für eine heutige Anwendung (d.h. ungleich Demo-Anwendung, sondern eine Anwendung, die neben schöner Graphik auch noch etwas anderes zu tun hat) Overkill. Auf Seite 8 (oben) haben die irgendetwas von Vereinfachung und Billboards geschrieben, leider bin ich im Augenblick zeitlich zu sehr begrenzt, um da weiter nachzuforschen :?
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Stimmt, sie vergleichen bei der Kerze Billboards mit vollständiger Berechnung. War nur mein Verurteil, weil ich auf den Beispielen keine Flächenleuchten gesehen habe … jetzt habe ich erstmal was zu tun :P
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von Krishty »

Nach monatelanger Lethargie habe ich eben wieder 20 min in meinen Renderer investiert und eine inverse FFT hingekrickelt.
Die Präzision von 32-bit-Fließkommazahlen ist scheinbar nicht so überwältigend; ich habe hier starke Oszillationen mit ca einem Zehntausendstel der Stärke des Ursprungssignals:
inv.png
(Das ist der Mond, wie man in den Störungen sogar teilweise erkennen kann)
Da die FFT momentan aber noch mit Radix 8 und die inverse FFT mit Radix 2 arbeitet (Radix halbieren bedeutet 30 % mehr Rechenoperationen und damit auch Ungenauigkeit) und ich für den finalen Code Radix 16 anpeile, bin ich aber guter Dinge, dass die Fehler dann vernachlässigbar sind. Und falls nicht, habe ich zumindest einen coolen Star-Shader :)

Hoffentlich kriege ich über die Feiertage endlich was Neues auf die Reihe. Der Stein ist zumindest schon ins rollen gebracht.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Anti-Jammer-Thread

Beitrag von eXile »

Krishty hat geschrieben:Da die FFT momentan aber noch mit Radix 8 und die inverse FFT mit Radix 2 arbeitet (Radix halbieren bedeutet 30 % mehr Rechenoperationen und damit auch Ungenauigkeit) und ich für den finalen Code Radix 16 anpeile, bin ich aber guter Dinge, dass die Fehler dann vernachlässigbar sind. Und falls nicht, habe ich zumindest einen coolen Star-Shader :)
Relevant?. Aber wie ich immer schon sage: First make it work, then make it fast ... implementiere erst einmal deinen Teil, vielleicht ist das bereits vollkommen ausreichend ;)

Vielleicht ein Nachtrag: Mit dem Link meinte ich, dass man eventuell durch die Transformation in sehr viele MAD-Instruktionen auf der Graphikkarte gegenüber den normalerweise gebrauchten Cooley-Tukey-FFT noch etwas rausholen kann. Warum man nicht die mit weniger Instruktionen auskommende Johnson-Frigo-FFT (siehe FFTW) benutzt, erschließt sich mir nicht wirklich. Auf jeden Fall gibt es wohl zwei Standardpaper zu den Thema: 1, 2

Noch ein Nachtrag: Die CUFFT benutzt eine Variation der Johnson-Frigo-FFT (aka FFTW). Hätte mich sonst auch gewundert. ;)
hagbard
Beiträge: 66
Registriert: 05.08.2010, 23:54

Re: Anti-Jammer-Thread

Beitrag von hagbard »

Mal eine dumme Frage: Warum sollte bei einer Radix-8 FFT ein genaueres Ergebnis rauskommen als bei einer Radix-2 FFT? Das mit der Rechenzeit leuchtet mir ein auf Grund der geringeren Rekursionstiefe aber bei Fließkommazahlen hätte ich jetzt nicht solche Auswirkungen bezüglich der Genauigkeit vermutet. (eher so im bereich 10^-10)
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

eXile hat geschrieben:
Krishty hat geschrieben:Da die FFT momentan aber noch mit Radix 8 und die inverse FFT mit Radix 2 arbeitet (Radix halbieren bedeutet 30 % mehr Rechenoperationen und damit auch Ungenauigkeit) und ich für den finalen Code Radix 16 anpeile, bin ich aber guter Dinge, dass die Fehler dann vernachlässigbar sind. Und falls nicht, habe ich zumindest einen coolen Star-Shader :)
Relevant?. Aber wie ich immer schon sage: First make it work, then make it fast ... implementiere erst einmal deinen Teil, vielleicht ist das bereits vollkommen ausreichend ;)

Vielleicht ein Nachtrag: Mit dem Link meinte ich, dass man eventuell durch die Transformation in sehr viele MAD-Instruktionen auf der Graphikkarte gegenüber den normalerweise gebrauchten Cooley-Tukey-FFT noch etwas rausholen kann. Warum man nicht die mit weniger Instruktionen auskommende Johnson-Frigo-FFT (siehe FFTW) benutzt, erschließt sich mir nicht wirklich. Auf jeden Fall gibt es wohl zwei Standardpaper zu den Thema: 1, 2

Noch ein Nachtrag: Die CUFFT benutzt eine Variation der Johnson-Frigo-FFT (aka FFTW). Hätte mich sonst auch gewundert. ;)
Wo nimmst du immer die Paper her? Ich musste suchen wie ein Bekloppter, um überhaupt ansatzweise die Beschreibung eines Radix-16-Butterflys zu finden … und in dem Paper ist direkt fertiger Code …

… ja, erstmal mache ich jetzt mit der Iris und den Streufunktionen weiter. Dann wird die FFT von Grund auf neu geschrieben; mit allem, was ich bisher gelernt habe; und MAD-optimiert klingt super.

Dazu eine Frage: Ist es möglich, das Ergebnis einer reellzahligen FFT auch in reellen Zahlen zu speichern, ohne, dass der Rekonstruktionsaufwand für die inverse FFT merklich ins Gewicht fällt? VRAM-Bandbreite ist mein absoluter Bottleneck, und wenn ich durch das Meiden komplexer Zahlen den Bandbreitenbedarf fast halbieren könnte (128 MiB scattered Writes weniger pro Frame), wäre das gigantisch.
hagbard hat geschrieben:Mal eine dumme Frage: Warum sollte bei einer Radix-8 FFT ein genaueres Ergebnis rauskommen als bei einer Radix-2 FFT? Das mit der Rechenzeit leuchtet mir ein auf Grund der geringeren Rekursionstiefe aber bei Fließkommazahlen hätte ich jetzt nicht solche Auswirkungen bezüglich der Genauigkeit vermutet. (eher so im bereich 10^-10)
Ich kenne das ehrlich gesagt auch nur vom Hörensagen, erkläre es mir aber durch weniger Multiplikationen. Wäre schön, wenn das ein Experte klären könnte, bevor ich eine böse Überraschung erlebe …

… übrigens ist es, was die Präzision angeht, wirklich ein Balanceakt. Meine CPU-Referenzimplementierung litt z.B. unter Streifenbildung, wenn ich Pi im Quelltext nicht mit mehr als zwölf Nachkommastellen angegeben habe (und das, obwohl alles in Single-Precision-Arithmetik laufen sollte) …
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Glare-Algorithmus

Beitrag von eXile »

Mmmh, lol ich hab schon wieder ganz vergessen, dass wir ja reellwertige Daten haben. :P

Naja, wenn die N Inputdaten für die FFT reell sind, dann sind die 2N Outputdaten ja unter komplexer Konjugation symmetrisch. Analog macht die IFFT aus 2N komplex konjugiert symmetrischen Inputdaten wiederum N reellwertige Outputdaten. Dadurch kann man sich im Butterfly-Diagramm die Hälfte der Verzweigungen in der Berechnung sparen, da man diese Symmetrie ausnutzen kann. Man speichert dann natürlich auch nie die 2N symmetrischen Werte ab, sondern nur N Werte. Dementsprechend ändert sich auch nichts am Rekonstruktionsaufwand, wenn man von ein paar komplexen Konjugationen absieht. Da gibts auch ein entsprechendes Uralt-Paper zu ... irgendwo von der IEEE aus dem Jahre 1988 oder so. Muss das unbedingt raussuchen. Ansonsten google auch mal nach dem "Edson's Algorithm", der geht ungefähr in die Richtung -- ich mag in diesem einem Punkt aber nicht meine Hand dafür ins Feuer legen.

DIe CUFFT Library macht etwas ähnliches, dabei erhält man nämlich mit cufftExecR2C auch für N0 × N1 × ... × Nn reelle Inputdaten N0 × N1× ... × (Nn/2+1) komplexwertige Outputdaten. Dito für die inverse cufftExecC2R.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Kann mir jemand erklären, was es mit dem Fresnel-Term auf sich hat? Also so viel ist mir klar: Mit einer gewöhnlichen FFT wird aus der Pupillenfunktion nur etwas, was wie eine Fresnel-Zonenplatte aussieht. Man möchte aber gern eine Point Spread Function haben.
Ohne Fresnel
Ohne Fresnel
Darum jagt das Paper noch eine Funktion e^(i×(pi÷(lambda×d))×(x²+y²)) drüber (lambda ist die Wellenlänge des Lichts, d die Entfernung zwischen Linse und Netzhaut). Wie kommt man darauf? Tatsächlich die Wellenlänge einzusetzen führt bei mir zu haarsträubenden Ergebnissen, in aufsteigender Reihenfolge:
Faktor von 1
Faktor von 1
Lois, das ist NICHT meine Batman-PSF!
Lois, das ist NICHT meine Batman-PSF!
Realistische Werte – gibt es bei 545 nm × 2 cm schon so heftige Rundungsfehler?
Realistische Werte – gibt es bei 545 nm × 2 cm schon so heftige Rundungsfehler?
Kann mich jemand aufklären? So lange ich nicht weiß, was der Zweck ist, weiß ich auch nicht, was ich falsch mache.

P.S.: Meine FFT hat den Koordinatenursprung irgendwie nicht in der Mitte, sondern am Rand. Für die Screenshots musste ich vierteilen und vertauscht aneinanderfügen. Bisher war das kein Problem, weil die iFFT das auch wieder rückgängig macht, aber bei der Multiplikation mit dem Bild taucht die Blendenfunktion am gegenüberliegenden Bildrand wieder auf, wenn sich ein Strahler am Rand befindet. Ist das ein Zeichen, dass ich mir endlich eine vernünftige FFT bauen soll?
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Ich habe mal eine Sum of Scaled Copies improvisiert. Sieht mit einem Faktor von 1 schon richtig ansehnlich aus – insbesondere in Bewegung, wenn der Glare pulsiert und „knistert“:
ssc.png
Ich mache einfach mal so weiter und schaue, wie weit ich komme.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Schrompf »

Bau einen Bildschirmschoner draus :-) Sieht halt echt gut aus, ist aber für Außenstehende halt nur trockene Theorie. Das finde ich schade.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Da du dich dran erfreuen kannst und eine Direct3D 11-GPU hast, haue ich hier mal meine 512² Pixel füllende, hingeklatschte, langsam-wie-Scheiße-e Arbeitsversion raus. Finde den Glare einfach zu hübsch, um ihn für immer in meiner Schublade verschwinden zu lassen. (Ich hatte versucht, ein Video zu machen, aber die Qualität war nicht annähernd befriedigend …)
GlareD3D11_2.7z
(5.24 MiB) 495-mal heruntergeladen
Rand ignorieren oder Fenster entsprechend skalieren. Mausrad hoch/runter bzw. F2/F1 für heller und dunkler. Nach dem Start zehn Sekunden warten, bis die Partikel richtig in Schwung gekommen sind; dann knistert es schöner.

Ich habe noch große Probleme bei geringen Helligkeiten. Die PSF sieht dann total „geringt“ aus … gestern hatte ich hingekriegt, dass sie in die Höhe gezogen wird, wie beim echten Zusammenkneifen der Augen. Dafür war sie dann aber insgesamt unschärfer. Das Ganze hängt direkt von der Iris-Textur ab, und dort das Gamma nur geringfügig zu verändern resultiert sofort in einer ganz anderen PSF. Ich werde also nicht drum herumkommen, mir eine perfekte Iristextur zu zeichnen, bevor ich Feinabstimmung an der Streuung vornehmen kann.

Hier nochmal die PSF der zusammengekniffenen Augenlider (ohne Iris) neben die Tüte gekotzt:
eyelids pressed.png
Zuletzt geändert von Krishty am 04.01.2011, 14:06, insgesamt 1-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
joggel

Re: Glare-Algorithmus

Beitrag von joggel »

Na toll!!
Und ich kann mal wieder nur lesen wie toll das aussieht.
Sadismus :x

Notiz an mich: Es ist mal wieder an der Zeit, sich einen Schwung neue Hardware zu besorgen!
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

:) Ohne Compute Shader ist sowas sauschwer und seit ich D3D-10- und -10.1-Unterstützung über Bord geworfen habe, hat man Renderer drei Viertel weniger Quelltext. Das ist ein Angebot, das ich nicht abschlagen kann.

Aber falls es dich beruhigt: Ich arbeite absichtlich mit verhältnismäßig langsamer D3D 11-Hardware, so dass deine neue Hardware, wenn du sie denn hast, das hoffentlich problemlos stemmen können wird.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
joggel

Re: Glare-Algorithmus

Beitrag von joggel »

Ehm, ich habs mir trotzdem mal runtergeladen...
Das Entpacken hat irgendwie nicht recht geklappt!
Die Meldung:
Bild

Die Datei "core.exe" hatte nach dem Entpacken die Größe 0, andere Dateien ebenfalls!
Verwendet habe ich 7zip.
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Glare-Algorithmus

Beitrag von Chromanoid »

selbes problem...
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Oh verdammt! Ist mit 7-Zip 9.20 beta gepackt … das hat LZMA2 und Deltakompression.
Download direkt oben: http://www.7-zip.org/

Ich mache derweil ein gemeines LZMA-Paket fertig.


Edit: Ist gefixt. Quelltexturen waren mir auch noch reingerutscht … und ich hatte mich schon gewundert, wo die zusätzlichen 3 MiB herkamen … Deployment scheitert bei mir immer – wenn ich schon extra die C-Runtime beilege, passiert eben sowas.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Mal eine ganz andere Frage: Die FFT sieht das Glare-Signal als periodisch an. Das bedeutet, dass die Kränze um helle Lichtquelle, die am rechten Rand verschwindet, vorher schon am Linken wieder auftauchen. Um das zu vermeiden müsste die Blendenfunktion doppelt so groß sein wie die Szene. Das ist ein richtig böses Problem; im Paper wird darauf nicht eingegangen … muss ich nun die Blende in doppelter Bildauflösung berechnen und dann irgendeine spezielle komplexe Multiplikation mit der Szene vornehmen oder was ist da los?

Außerdem bin ich Depp bis gerade tatsächlich davon ausgegangen, die SSC im gruppenübergreifenden Speicher durchführen zu können. Das passt natürlich nicht; nun brauche ich eine weitere Textur und einen weiteren Synchronisationsschritt. Mittlerweile gerät der Ressourcenhunger ein wenig aus den Fugen – ich habe nun für eine Auflösung von n×n Pixeln 13×n×n floats zu verwalten, die mehrfach komplett gelesen und geschrieben werden … bei Full-HD wird ein Viertel des VRAMs (ca. 256 MiB) ganz allein dafür draufgehen, die Zwischenergebnisse des Glares festzuhalten.

Wird sicher noch sehr, sehr lustig zu optimieren. Immerhin ist die FFT schon relativ schnell (24 Takte für acht aus 512 Pixeln mit drei aufeinanderfolgenden Radix 8 … schon die Sum of Scaled Copies benötigt 33) – das kann aber genauso gut bedeuten, dass ich dort noch am wenigsten rausholen können werde.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Ist es nun an der Zeit, bei der iFFT von Radix 2 auf was Höheres umzusteigen?
radix2ftw.png
radix2ftw.png (3.32 KiB) 12592 mal betrachtet
Lustig, da ich ja gestern abend zwei Stunden damit verbracht habe, die Sum of Scaled Copies von 60 Takten auf 33 zu optimieren :)

Immerhin ein hübsches ALU-zu-TEX-Verhältnis – bei einer Radix-8-FFT ist es nur noch 3,5:1. Die braucht auch nur noch 17 Allzweckregister und kein einziges Scratch Register.

Da einem – je nach Thread-Auslastung – zwischen 32 und 128 Register zur Verfügung stehen, dürfte Radix 16 optimal sein.

Übrigens fängt der HLSL-Compiler ab 2000 Anweisungen an, Schleifen zu bevorzugen … und der HLSL-Compiler zeigt als Bottleneck „Exports“ an. Das spricht wohl dafür, dass AMD um jeden Preis darauf aus ist, die ALU-Leistung gegenüber dem Rest zu steigern.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

So, der Prototyp für 512×512 steht und läuft mit 21 fps. Die Rundungsfehler machen sich nicht bemerkbar, FUCK YEA! Aus irgendeinem Grund habe ich keine Farben … da habe ich wohl irgendwo eine Implicit Vector Truncation oder so; kann sich nur um Minuten handeln, bis ich das habe. Indes:
stars.png
Dort sieht man den (leider noch streifigen) Schein um den hellen Stern rechts am linken Rand wieder auftauchen. Bei der Sonne ist das tausendmal schlimmer; dort kann man vor lauter Spiegelungen garnicht mehr sehen, an welcher der vier möglichen Positionen sie sich überhaupt befindet. Ich will Ideen hören!

Update von 1967: Hier wird es noch deutlicher; ab jetzt auch in Farbe.
coloredStars.png
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Schrompf »

Sieht cool aus. Bis auf die Moiree-Muster. Aber wär ein Standard-Bloom nicht schneller? *duck&weg*
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Mal im Ernst: Ich habe 512×512-Bloom ausprobiert und sieben FPS erreicht. Das war dann mathematischer Bloom; rund, keine Muster drin. Irgendwo ab einem Radius von 128 wird die Fourier-Transformation also tatsächlich schneller … Group-Shared Memory im Compute Shader schiebt die Grenze zwar nach oben, aber das hier, das ist die Zukunft :)

Die Moirées kommen von einem falschen Gamma beim Zeichnen der Pupille. Ich werde mich noch drum kümmern, muss aber erstmal das große Ganze reibungslos zum laufen kriegen.

Ach, und auf meine Prinzipien sei geschissen. Der Effekt wird vollkommen aufdringlich und überdreht eingebaut, das habe ich eben entschieden.
fuckyeahglare.png
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Glare-Algorithmus

Beitrag von eXile »

Hast du dir deine Frage nicht schon selbst beantwortet?
Kristhy hat geschrieben:Meine FFT hat den Koordinatenursprung irgendwie nicht in der Mitte, sondern am Rand. Für die Screenshots musste ich vierteilen und vertauscht aneinanderfügen.
Wenn du das Bild einmal durch die FFT jagst, sollten die Frequenzen (0, 0) genau in der Bildmitte liegen. Wenn das Frequenzbild anders aussieht, dann ist da wohl was faul - und du musst dich nicht wundern, dass du Wraparounds kriegst, wenn du die ganze Topologie durch Auseinanderschneiden und Zusammenschnipseln änderst. ;)
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Glare-Algorithmus

Beitrag von Chromanoid »

Just for your information: :) deine Testanwendung kann bei mir nicht funktionieren, weil ich gar kein DirectX11 habe :/.

Wenn du mit dem Glare Effekt fertig bist, würde ich mich über hübsche Bokeh-Effekte mit schönen Zerstreuungskreisen freuen :).
Antworten