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

Re: Glare-Algorithmus

Beitrag von 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?
Chromanoid hat geschrieben: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 :/
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: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?
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Noch schnell einer für Chromanoid:
4chrom.png
(Ich hoffe, die vielen Bildchen gehen klar – nicht, dass ich hier den Traffic übertreibe)
eXile hat geschrieben: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 …
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Jörg
Establishment
Beiträge: 296
Registriert: 03.12.2005, 13:06
Wohnort: Trondheim
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von 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.
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 »

Krishty hat geschrieben: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
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Glare-Algorithmus

Beitrag von 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.)
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von 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:
_01 scene.png
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:
_02 scene DFT.png
Weiterhin haben wir die Innenansicht des Auges:
_3 aperture.png
… und berechnen daraus wieder die Fourier-Transformation. Diesmal ist das nicht in RGB nötig, sondern ein Kanal reicht:
_4 aperture DFT.png
Fortsetzung folgt, da ich hier nicht genügend Dateianhänge hochladen kann.
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. 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:
_5 PSF.png
(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:
_6 PSF DFT.png
Das multiplizieren wir mit der Szene …
_7 scene manipulated DFT.png
… kehren die Chose per inverser FT um und erhalten die überblendete Szene:
_8 result.png
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.
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 »

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.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
joggel

Re: Glare-Algorithmus

Beitrag von joggel »

Schrompf hat geschrieben: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 ... :cry:

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

Sieht echt gut aus!!
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von CodingCat »

Krishty hat geschrieben: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. ;-)
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: Glare-Algorithmus

Beitrag von 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?
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Glare-Algorithmus

Beitrag von eXile »

CodingCat hat geschrieben: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.
Eisflamme hat geschrieben: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 ...
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Schrompf hat geschrieben: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.
CodingCat hat geschrieben: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 :/)
Eisflamme hat geschrieben: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.
Eisflamme hat geschrieben: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).
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 »

eXile hat geschrieben: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 …
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 »

Ich hab jetzt überhaupt erst verstanden, was zum Teufel die da gemacht haben:
\($$\begin{align}f_2 &= (f_1 \otimes \mathrm{PSF}_\text{aperture}) \otimes \mathrm{PSF}_\text{eye} \\
&= f_1 \otimes (\mathrm{PSF}_\text{aperture} \otimes \mathrm{PSF}_\text{eye}) \\
&= f_1 \otimes \big((...\!) \ F(\mathrm{PSF}_\text{eye} \cdot E(...\!))\big) \\
&= F^{-1}\big(F(f_1) \cdot F\big((...\!) \ F(\mathrm{PSF}_\text{eye} \cdot E(...\!))\big)\big) \end{align}$$\)
Die Formel zeigt übrigens die komplette Pipeline. Dieser Post wird in den nächsten Stunden noch aktualisiert, ich muss erst einmal feiern, dass ich das rausbekommen habe.
Zuletzt geändert von eXile am 20.04.2012, 04:19, insgesamt 2-mal geändert.
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 unterbreche deine Edits ja nur ungern, aber ich wollte mal eben die ganze Welt wissen lassen, dass die Sum of Scaled Copies alles ruiniert. 32 Kopien übereinander blenden braucht – im Compute-Shader, wohlgemerkt – genau so viel Zeit wie die 20 FFTs und iFFTs, die ich über Szene und Linse jage! Das ist echt der Punkt, wo ich den Glauben verliere.

Zumal der GPU Shader Analyzer ausspuckt, die SSC würde 40 Takte brauchen und die FFT 2000. Aber das Ding ist sowieso total scheiße, weil z.B. ein manueller int-to-float-Cast an einer Stelle, wo der Compiler auch automatisch castet, ausreicht, um die Statistiken mit N/A zu füllen.

Mal ein wenig was zur Performance: Ich kann für die Werte keine Richtigkeit garantieren; ich glaube sogar, dass die Messungenauigkeit zu hoch ist, um überhaupt irgendwas herausdeuten zu können. Das liegt daran, dass ich keine Methode gesehen habe, CS-Performance zuverlässig zu messen. Ich habe einfach Schritt für Schritt ausgeklammert und die FPS gemessen.
  • Erster Schritt, vier FFTs (Linse horizontal, Szene R/G/B horizontal): 1,1 ms (911 fps)
  • Zweiter Schritt, vier FFTs (Linse vertikal, Szene R/G/B vertikal): 2,19 ms (460 fps)
  • Dritter Schritt, PSF (Sum of Scaled Copies): Abgeschaltet, bis der Performance-Einbruch geklärt ist
  • Vierter Schritt, sechs FFTs (PSF horizontal und vertikal, Multiplikation mit Szene): 9,86 ms (100 fps)
  • Fünfter Schritt, sechs iFFTs (Szene R/G/B je horizontal und vertikal): 7,14 ms (140 fps)
Insgesamt also 20,28 ms oder 49 fps. Wäre noch anzumerken, dass die 512er-Version nur ein Viertel des verfügbaren Gruppenspeichers nutzt, die iFFTs im suboptimalen Radix-2 sind und dass die ALU-Last noch sinken wird, wenn ich die FFTs von Radix-8 auf Radix-16 umgestellt habe. Aber ALU-Last ist eh meine geringste Sorge. Was die Geschwindigkeit der ersten beiden Schritte angeht: es ist gut möglich, dass der Treiber die Arbeit schlicht und einfach verworfen hat, als er sah, dass das Ergebnis nicht weiterverwendet wird. Mit Sonne, Mond, Sternen und Tonemapping läuft meine Testanwendung momentan bei 40 fps.

Und hier habe ich eine PSF, mit der man den Fehlerwert der FFT einschätzen kann:
error.png
Der helle Strahler in der Mitte ist die Sonne mit ca. einer Milliarde cd÷m², der Sternenhimmel liegt bei 0,001 bis 1 cd÷m2. Der relative Fehler ist also (zum Glück) relativ gering geblieben.
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 »

Nachdem Cat so lieb nach Screenshots gefragt hat habe ich mir gedacht, „Was soll’s“ (ohne Satzzeichen, weil Instant Messaging meine Betonung so hat verkommen lassen, dass ich auch in Gedanken schon Alt+S drücke statt zu interpunktieren … oder mein Leben meine Sprache so geprägt hat, dass ich auch meine Sätze schon ins Leere laufen lasse … obwohl dann eher eine Ellipse kommen müsste. Nein; ich denke, meine Gedanken sind zusammenhanglos wie eine Aufzählung – ja, das wird es sein) und direkt ein Video gemacht (H.264):

[Die Dateierweiterung mkv wurde deaktiviert und kann nicht länger angezeigt werden.]

  • Um der Prestige Willen ist der helle Stern am Anfang starr fixiert bis er schwach genug ist, beim Schwenk keinen merklichen Wrap-Around hervorzurufen – könnte man glatt für Lense Flare halten
  • Am Ende schalte ich den Glare mal kurz ab, damit die Sterne wieder nur ein paar ausdruckslose Pixel sind und man mal sieht, was für ein gutes Gefühl für Überhelligkeit Glare vermittelt
  • Die Ringing-Artefakte kriege ich nicht weg so lange ich nicht die Fresnel-Funktion kapiere
  • Die Sternhelligkeiten sind, wie ich feststellen musste, von vorn bis hinten verkackt. In dem Video nicht, da habe ich mir eine schöne Ecke rausgesucht. Aber ich habe z.B. einen fetten gelben Stern, der so hell scheint wie der komplette Mond … da gibt es also noch viel zu tun
Fun fact: Ich hatte die letzten Tage versehentlich doppelte Auflösung allokiert. Den Fehler habe ich nun behoben, aber weil ich irgendwo irgendwas anderes kaputt gemacht habe, ist es nur noch halb so schnell wie vorher (also vier Mal langsamer als man es vermuten würde). Oder das ist weil der Rechner langsam schlapp macht, denn der ist schon vier Tage am arbeiten und ich habe keine Möglichkeit, ihn herunterzufahren. Genau wie mein Kopf. Boah, kurz vor Sonnenaufgang bin ich noch tausendmal verballerter als sonst.
Zuletzt geändert von Krishty am 07.01.2011, 15:58, insgesamt 2-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von CodingCat »

Wow, wunderhübsch - da macht selbst ein ganz normaler Sternenhimmel was her. :D
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 »

Soo, die 1024×1024-Version läuft vorerst (nun auch mit Tonemapping). Performance ist unterirdisch – gestern 4 fps; mittlerweile habe ich sie verdoppelt indem ich mehrere Schübe mit einfachen Shadern rechne statt weniger mit Komplexeren. Offenbar gilt für Compute Shader die Regel: Nur von einer Stelle lesen und das Ergebnis möglichst an dieselbe Stelle zurückschreiben – selbst, wenn der Gesamtrechenaufwand dadurch steigt …
1024.png
Ich muss unbedingt die Ringe glattkriegen; verdammter Fresnel. Wer genau hinschaut sieht außerdem, dass die PSF 2×2 Pixel groß ist und der Blur deshalb einen halben Pixel gegenüber den Sternen verschoben ist. Way to go … und ich muss selbstverständlich gucken, was ich an der Performance drehen kann (Zeit für Benchmarks), damit 2048² nicht auf immer Illusion bleibt.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
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 »

Sieht klasse aus.Ich faende es toll, die Technik auch mal auf was anderes als Sterne angewandt zu sehen - schlussendlich ist es ja ein general-purpose Glare-Modell, nicht wahr? :-)
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Glare-Algorithmus

Beitrag von Alexander Kornrumpf »

Nur von einer Stelle lesen und das Ergebnis möglichst an dieselbe Stelle zurückschreiben
Wie doof ist dass denn? Da lobe ich mir ja dass die coalescing rules es für CUDA transparent machen wann lesen und schreiben schnell sind und wann nicht.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Aramis hat geschrieben:Ich faende es toll, die Technik auch mal auf was anderes als Sterne angewandt zu sehen - schlussendlich ist es ja ein general-purpose Glare-Modell, nicht wahr? :-)
Ich auch, aber beim derzeitigen Tempo müssen wir da noch bis 2016 warten.
Alexander Kornrumpf hat geschrieben:
Nur von einer Stelle lesen und das Ergebnis möglichst an dieselbe Stelle zurückschreiben
Wie doof ist dass denn? Da lobe ich mir ja dass die coalescing rules es für CUDA transparent machen wann lesen und schreiben schnell sind und wann nicht.
So wie ich das sehe, gelten die Coalescing Rules für Nvidia-Hardware, nicht speziell für CUDA. Per Compute Shader kann ich die Lese- und Schreibzugriffe genau so gruppieren und der Treiber wird ähnlichen Text erzeugen wie unter CUDA … und unter AMD-Karten mit anderer Speicheranbindung funktioniert dann beides gleich schlecht. Im übrigen bedeutet es ja dasselbe – dass man eine kontinuierliche Speicherregion bearbeiten und dabei jeder Thread „seinen“ Offset lesen soll – und ist ganz einfach ein Resultat der Evolution aus Pixel-Shadern.

Achja – falls ihr gerade aus dem Fenster blicken und den Mond sehen könnt, könnt ihr gut sehen, wie weit ich noch von einem akzeptablen Ergebnis weg bin: Der Glare ist zu stark, seitlich gestreckt (weil ich fälschlicherweise annehme dass man bei solchen Helligkeiten schon die Augen zusammenkneift) und die Sternhelligkeit ist ein paar Dekaden zu hoch. Aber immerhin ist die Leistung eben nochmal von acht auf zehn Hertz verbessert worden.
rl.png
Zuletzt geändert von Krishty am 09.01.2011, 19:17, insgesamt 1-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
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 »

Und hast du mal geschaut ob du das Glare auf einem verkleinerten bild berechnen kannst um es dann auf das original bild vergößert drüber zu legen?
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Ja, das werde ich sogar müssen – 1024² ist ja noch nicht einmal in annähernd echtzeitfähigen Gefilden für einen Postprocessing-Effekt und Full-HD fordert 2048². Allerdings muss ich den Glare dazu erstmal fokussiert kriegen – wenn nämlich schon in Originalauflösung alle Pixel zu 2×2 streuen, wird das in halber Auflösung richtig schlampig.

Edit: Besser?
rl2.png
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Glare-Algorithmus

Beitrag von Alexander Kornrumpf »

So wie ich das sehe, gelten die Coalescing Rules für Nvidia-Hardware, nicht speziell für CUDA.
Das eigentlich Entscheidene ist ja das Pattern das sich daraus entwickelt hat, das man wo möglich einmal coalsced in den lokalen (schnellen) Speicher liest, dort alle Berechnungen vornimmt und dann wieder coalesced in den globalen Speicher zurück schreibt. Ich weiß ja nicht inwiefern du diese Kontrolle auch im Shader hast, aber es klang deiner Beschreibung nach eher wie kompilieren und hoffen.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Krishty »

Ja doch, die habe ich – globalen, lokalen und gruppenübergreifenden Speicher kann man mit erträglichem Aufwand verwalten. Ich war nur halt baff, weil diese Coalescing Rules schon seit der GeForce 8800 gelten und sich scheinbar kein bisschen verändert haben, obwohl immer von verbesserter Scattering Performance gesprochen wird. Seine Daten aus vier Texturen zusammenlesen ist einfach (noch) nicht.
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 ein kleiner Statusbericht:
  • Die 1024²er-Version läuft bei 12 fps (auf einer Radeon HD 5770). Es werden 15 sein, wenn (oder falls) ich endlich den inversen Radix-8-Butterfly zusammengekriegt habe, mit dem ich mich seit Wochen quäle. Wie schnell die 512er-Version läuft, kann ich erst sagen, wenn ich sie auf den selben technischen Stand gebracht habe (habe nun eine Woche nicht mehr mit ihr gearbeitet) – ich gehe von über 30 fps aus.
  • Ich habe die meisten generellen Optimierungen abgeschlossen – ich werde morgen noch etwas testen, was den VRAM-Bedarf um ein Siebtel senkt; werde es aber nicht übernehmen, falls es sich negativ auf die Geschwindigkeit auswirkt. Radix-16 könnte vielleicht nochmal 20 bis 30 % rausholen, aber Sprünge um Vielfache dürften unmöglich sein. (Randbemerkung: Radix wirkt sich tatsächlich noch so stark aus, weil nicht nur die Gesamtzahl der Rechenoperationen ein wenig sinkt, sondern, weil es der GPU bei doppeltem Radix auch nur noch halb so schwer fällt, die Speicherverzögerungen zu verstecken – und die sind das Hauptproblem.) Alles, was darüber hinaus noch bleibt, sind maschinenspezifische Optimierungen (Anordnung der Lese- und Schreiboperationen, Anordnung der Zwischenergebnisse entsprechend der Speicherbänke usw; also alles, was ab der nächsten GPU vergebene Liebesmüh’ sein wird).
  • Ich habe ein wenig an der Iristextur gefeilt und nun endlich „stacheligen“ Glare. Das ist eine echte Qual, weil sich tatsächlich jeder Iris-Pixel stark auf die Form des Glares auswirkt. Hier könnte ich wahrscheinlich ganze Wochen verplempern. Screenshots unten.
  • Ich werde zwei Optionen anbieten: Einmal, vorberechnetes Glare-Muster statt dynamischem zu benutzen (dürfte die Performance verdoppeln, oszilliert und knistert aber nicht mehr so schön) und, den Glare in halber Auflösung zu berechnen (dürfte die einzige Möglichkeit sein, das innerhalb der nächsten Jahre echtzeitfähig zu halten – dafür muss ich aber erstmal die PSF scharf kriegen).
  • Je nachdem, wie sehr ich meinen Welthass unter Kontrolle habe, baue ich nächste Woche u.U. eine 2048²-Version – just for fun.
shinynew2.png
shinynew.png
Nachtrag: Die 512²er-Version läuft bei 49 fps, also ziemlich genau vier Mal so schnell wie die 1024²er-Version – mit an Sicherheit grenzender Wahrscheinlichkeit wird also eine 2048²er-Version bei 3 fps arbeiten; vielleicht 4 falls man optimiert, dass von nicht genutzten Bildbereichen auch keine FFT berechnet werden muss (was bei 1920×1080 immerhin fast die Hälfte wäre).
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von CodingCat »

Unglaublich, mit den Stacheln sieht das jetzt absolut fantastisch aus. Und das bei 49 FPS, da kann man ja echt was mit anfangen... Nur schade, dass ich keine DX11-Karte haben. :-(
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: Glare-Algorithmus

Beitrag von Zudomon »

Also ich finde, der Glare ist absolut falsch! So bricht sich das Licht in meinem Auge nicht...
Aber was erwartest du denn auch? Du modellst ein Standardauge und gehst dann davon aus, es würde keinem auffallen, wenn du anderen das Scattering eines fremden Auges unterjuwelst! ;)

btw. sieht echt schon verdammt real aus!
Antworten