(gelöst) Glare-Algorithmus

[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“:

Ich mache einfach mal so weiter und schaue, wie weit ich komme.

[Schrompf]

Bau einen Bildschirmschoner draus :-) Sieht halt echt gut aus, ist aber für Außenstehende halt nur trockene Theorie. Das finde ich schade.

[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) 568-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:

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

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

[joggel]

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


Die Datei "core.exe" hatte nach dem Entpacken die Größe 0, andere Dateien ebenfalls!
Verwendet habe ich 7zip.

[Chromanoid]

selbes problem...

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

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

[Krishty]

Ist es nun an der Zeit, bei der iFFT von Radix 2 auf was Höheres umzusteigen?

radix2ftw.png (3.32 KiB) 14020 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.

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

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.

[Schrompf]

Sieht cool aus. Bis auf die Moiree-Muster. Aber wär ein Standard-Bloom nicht schneller? *duck&weg*

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

[eXile]

Hast du dir deine Frage nicht schon selbst beantwortet?

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. ;)

[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 :).

[Krishty]

Momentan muss ich zum Glück nicht mehr puzzlen … aber gut, dann ist die FFT jetzt endgültig reif.

Ich werde also mit großer Sicherheit keine Wraparounds mehr haben, wenn ich den Ursprung in die Mitte kriege? Ich meine – für die FFT ist das Signal doch dann immernoch periodisch, oder?

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

Soweit kein Problem; ich muss nur das Innenauge durch eine andere Blende ersetzen. Depth of Field gibt es damit aber nicht, weil alles von außen kommende als gleich weit entfernt angesehen wird :/

[eXile]

Ich werde also mit großer Sicherheit keine Wraparounds mehr haben, wenn ich den Ursprung in die Mitte kriege? Ich meine – für die FFT ist das Signal doch dann immernoch periodisch, oder?

Mhh, mir scheint beinahe, du könntest damit recht haben. Verdammt - das wäre dann die vierfache Bildgröße, d.h. man kann das Arbeiten in Originalauflösung vergessen. Das kann doch nicht sein ... Mir aber zur Zeit vollkommen unklar, wie überhaupt jetzt deine Frequenzbilder im Augenblick aussehen! Wo sind die negativen Frequenzen hin?

[Krishty]

Noch schnell einer für Chromanoid:

(Ich hoffe, die vielen Bildchen gehen klar – nicht, dass ich hier den Traffic übertreibe)

Mir aber zur Zeit vollkommen unklar, wie überhaupt jetzt deine Frequenzbilder im Augenblick aussehen! Wo sind die negativen Frequenzen hin?

Negative was? :) Ich werde einfach mal meine komplette Pipeline in Dateien flushen und hochladen, damit du dir deine Meinung bild-en kannst …

[Jörg]

Wo die "Mitte" der FFT liegt kommt nur darauf an, ueber welchen Bereich man summiert...0..2pi oder -pi...pi. "Falsch" ist keines von beiden.

[Chromanoid]

Noch schnell einer für Chromanoid:

4chrom.png

(Ich hoffe, die vielen Bildchen gehen klar – nicht, dass ich hier den Traffic übertreibe)

♥

Ich glaube wir haben unlimited traffic... :) und für sowas sowieso :D

[eXile]

Mhhh, je mehr ich darüber nachdenke, desto weniger ergibt die Faltung (im mathematischen Sinne - d.h. eine convolution) Sinn: Welche Daten sollen denn dann gefaltet werden? D.h. an den Rändern muss man das padden/stretchen/was auch immer.

Gerade gefunden (Seiten 5 bis 7). Hört sich total logisch an. Die Größe des Paddings hängt natürlich von der Größe des verwendeten Kernels ab. (Meine Aussage aus vorherigen Posts ist somit nicht ganz korrekt - man braucht maximal die vierfache Bildgröße, nämlich genau dann, wenn der Kernel so groß ist wie das Bild selber, und das ist auch die maximale Größe des Kernels.)

[Krishty]

Erstmal gibt es jetzt eine Aufstellung der Zwischenergebnisse der Pipeline, die ich in Mühevoller Kleinarbeit zusammengepfriemelt habe …

Wir gehen von einer Szene aus, hier ein Blick auf die Sonne:

Da wird die Fourier-Transformation drübergejagt. Da das für alle drei Kanäle geschieht, habe ich die Real- und Imaginärteile einfach mal zu einem Betrag zusammengefasst:

Weiterhin haben wir die Innenansicht des Auges:

… und berechnen daraus wieder die Fourier-Transformation. Diesmal ist das nicht in RGB nötig, sondern ein Kanal reicht:

Fortsetzung folgt, da ich hier nicht genügend Dateianhänge hochladen kann.

[Krishty]

So. Die FT des Auges dient nun als Point Spread Function. Mit einer Sum of Scaled Copies drüber haben wir Glare für einen Punkt:

(Der sieht übrigens in dem Paper hübscher aus, weil ich die verdammte Fresnelfunktion nocht nicht in meinen Kopp gekriegt habe.) Davon wird wieder die FT berechnet – diesmal für alle drei Kanäle, weil der Glare ja farbig sein soll:

Das multiplizieren wir mit der Szene …

… kehren die Chose per inverser FT um und erhalten die überblendete Szene:

So. Jetzt wisst ihr, wie die Interna aussehen. Die RGB-Texturen werden intern aufgedröselt – aus der Seitenlänge n wird 2n×3n (auf der X-Achse abwechselnd Real- und Imaginärteil, auf der Y-Achse nacheinander alles R, G und B – weil Compute Shader nur das laden einer Komponente auf einmal zulassen).

Jetzt werde ich mich in das Padding einlesen. Wenn die Scheiße dabei noch mächtiger wird, besaufe ich mich heute abend und springe hinter einen Zug oder so.

[Schrompf]

Wow... einfach nur wow. Du bewegst Dich da in Bereichen, die ich noch nie angefasst habe. Wenn das die Zukunft der Grafikprogrammierung ist, wechsel ich zur Gärtnerei.

[joggel]

Wow... einfach nur wow.

Genau das Selbe dachte ich auch als ich das alles gelesen habe... dazu kam noch sowas wie dies hier:
:geek: :shock: :o ...

Ich habe zwar die Worte verstanden, aber sie haben keinen Sinn für mich ergeben ... :P

Sieht echt gut aus!!

[CodingCat]

Ach, und auf meine Prinzipien sei geschissen. Der Effekt wird vollkommen aufdringlich und überdreht eingebaut, das habe ich eben entschieden.

Na also! ;-) Ist ja eine ganz beachtliche Pipeline, wäre nun interessant, wie dieser Effekt in "normalen" Nachtszenen, z.B. mit Straßenlaternen, zur Geltung käme. Damit könnte man bestimmt sehr schön eine leicht surreale Atmosphäre erzeugen. :-)

Jetzt könntest du btw. nochmal ein schönes Bild mit fertigem Glare und farbigen Sternen posten. ;-)

[Eisflamme]

Hi,

Also ich verstehe noch nicht so ganz, was du jetzt eigentlich bastelst. Anscheinend hast Du als Ausgangsbild eine Szene, aber wie ist die dargestellt? Ich meine, bedeutet ein heller Pixel jetzt, dass von da aus Licht kommt und, indem du schaust, wie die optische Physik zwischen Auge und im Auge arbeitet, baust Du die Streuung des Lichts ein, wie sie wahrgenommen wird?

Wenn das in Echtzeit funktionieren würde, wäre das also eine realistischere Art der Belichtung in Szenen, wobei man als Ausgangsmaterial einfach nur ein paar einfache Parameter wie Position, Stärke etc. des Lichts angeben müsste?

[eXile]

Ist ja eine ganz beachtliche Pipeline, wäre nun interessant, wie dieser Effekt in "normalen" Nachtszenen, z.B. mit Straßenlaternen, zur Geltung käme.

Findest du im Paper auf Seite 9. Man mag sich vielleicht auch das Video dazu reinziehen.

Wenn das in Echtzeit funktionieren würde, wäre das also eine realistischere Art der Belichtung in Szenen, wobei man als Ausgangsmaterial einfach nur ein paar einfache Parameter wie Position, Stärke etc. des Lichts angeben müsste?

Es ist keine globale Illumination. Es werden einfach nur die optischen Relexionseigenschaften des Kamerasystems (hier: des Auges) besser erfasst (durch eine point spread function). Von der Seite der Computergraphik her finde ich dies einen bedeutenden Schritt, denn so wenn man endlich die FFT der Szene hat, kann man damit sehr viele Effekte implementieren, und zwar nur noch auf Kosten einer schnellen Multiplikation der Frequenzbilder und der anschließenden IFFT (d.h. die FFT der Szene kann man immer wieder im selben Frame recyclen). Auch ist dieses Verfahren für sehr große Filter (häufig z.B. Bloom-Filter) schneller, als eine n-fache Anwendung des Filters. Um es kurz zu sagen: Es löst Hacks wie Bloom-Filter und solche Geschichten ab, ist bei kleinen Filtern aufwändiger, aber man hat auch viel mehr Möglichkeiten ;)

Nachtrag: Grrrrr, wisst ihr, was ich im Video bei 3:40 sehe? Wrap around ...

[Krishty]

Wenn das die Zukunft der Grafikprogrammierung ist, wechsel ich zur Gärtnerei.

Keine Angst … wenn man es einmal verstanden hat und – anders als ich – die Beschränkungen im Voraus kennt, ist es relativ einfach.

Jetzt könntest du btw. nochmal ein schönes Bild mit fertigem Glare und farbigen Sternen posten. ;-)

Da kommt leider noch einiges dazwischen :/ Ein Detail, was noch fehlt, ist z.B., dass ich die Point Spread Function so modifizieren muss, dass sie für den mittleren Pixel einen gedämpften Wert zurückgibt. Der Grund dafür ist, dass ich für die FFT das Anti-Aliasing des Bildes auflösen musste und das Streubild zusätzlich noch verwaschen ist (allein, weil man in einer PSF mit gerader Seitenlänge keinen scharfen Mittelpunkt erzeugen kann, liegt ein 2×2-Blur über dem Bild). Ich muss also noch die PSF bearbeiten und mit dem geantialiasten Originalbild kombinieren … das habe ich bisher überhaupt noch nicht angepackt. (Und habe jetzt auch erstmal akutere Probleme zu lösen :/)

Also ich verstehe noch nicht so ganz, was du jetzt eigentlich bastelst. Anscheinend hast Du als Ausgangsbild eine Szene, aber wie ist die dargestellt? Ich meine, bedeutet ein heller Pixel jetzt, dass von da aus Licht kommt und, indem du schaust, wie die optische Physik zwischen Auge und im Auge arbeitet, baust Du die Streuung des Lichts ein, wie sie wahrgenommen wird?

Ich habe ein Ausgangsbild der Szene, wo für jeden Pixel seine Helligkeit in cd÷m² eingetragen ist – ein weitestgehend normaler HDR-Backbuffer.

Nun haue ich da einen Blur drüber. Normalerweise berechnet man diesen Blur anhand einer Gauss-Formel, während man die umliegenden Pixel abtastet … ich lade die Koeffizienten hingegen aus einer Textur.

In dieser Textur ist abgebildet, wie ein einziger Pixel, der durchs Auge fällt, sein Licht streut (also der Strahlenkranz eines einzelnen Pixels – siehe Bild 5, nur, dass dort der Koordinatenursprung in der Ecke statt am Rand ist). Das ist sozusagen mein Blur-Kernel, und ich habe ihn durch die Innenansicht des Auges (Bild 3) und Fresnel’sche Beugungsformeln (Bild 4) berechnet.

Ich wende also den Strahlenkranz-Blur auf jeden Pixel der Szene an … da das hier ein HDR-Bild ist und so ein Stern (wie in Wirklichkeit) tausendmal heller ist als die Umgebung drumherum, kommt sein Strahlenkranz deutlich zum Vorschein während jener der dunklen Universumspixel unbemerkt untergeht.

Die Fourier-Transformation dient dazu, diesen Effekt erheblich zu beschleunigen – ein Blur mit einem Radius von mehreren hundert Pixeln ist nämlich saulangsam. Wenn man hingegen von zwei Bildern die Fourier-Transformation berechnet (Bild 2 & 6), die beiden miteinander multipliziert (Bild 7) und dann die inverse Fourier-Transformation berechnet, ist es, als ob das komplette Bild B auf jeden Pixel des Bildes A draufprojeziert wurde.

Ich hoffe, das war einigermaßen anschaulich beschrieben.

Wenn das in Echtzeit funktionieren würde, wäre das also eine realistischere Art der Belichtung in Szenen, wobei man als Ausgangsmaterial einfach nur ein paar einfache Parameter wie Position, Stärke etc. des Lichts angeben müsste?

Erst einmal funktioniert es bereits in Echtzeit, nur habe ich (noch) keinen Prototypen mit mehr als 512×512 Pixeln Auflösung ;) Du musst für das Licht garnichts angeben. Der normale Frame, den man rendert, ist ja bereits nichts anderes als eine große Liste von Helligkeiten, die aus verschiedenen Richtungen kommen. Der Algorithmus ist immer gleich schnell (oder langsam), egal, ob da nur ein einziger beleuchteter Pixel in der Szene ist, tausend (wie bei einem Sternenhimmel) oder millionen (wenn der Spieler virtuell per Fernglas in die Sonne guckt).

[Krishty]

Nachtrag: Grrrrr, wisst ihr, was ich im Video bei 3:40 sehe? Wrap around ...

Jetzt, wo ich den Effekt kenne, sehe ich es schon bei 3:10. Der Hund hat einfach die Laternen so platziert, dass es nicht auffällt. Gut, dass ich noch nichts gegessen habe, sonst würde ich alles wieder auskotzen.

Mal eine andere Frage: Ich kann doch FFTs verschiedener Radix’ kombinieren, oder? Ich habe vor zwei Monaten die 2048er als 8-8-8-4 berechnet und die Ergebnisse waren dem Eindruck nach korrekt (ich hatte damals aber noch keine inverse FFT zur Kontrolle). Nicht, dass ich Radix-16 jetzt vergeblich einbaue …