ZFX + Developia

Das Model an dem ich arbeite, ist nicht animiert... und ich fliege da dann einfach so rum. Dann schalte ich ab, dass die Flügel, Arme und Beine generiert werden und als ich mich dann umdrehe und meinen eigenen Drachen erblicke ----> :shock:
Die Knochenbindung ist komplett falsch, wenn die anderen Sachen nicht mit generiert werden, aber hab halt nicht mit so einem Anblick gerechnet... da dachte ich, ich konserviere den mal für später.
[youtube]IERpVVFI6KM[/youtube]

Nach ein bisschen Urlaub und anschließender kleiner Motivationskrise bin ich nun auch wieder dabei und habe den Drachen nun komplett per Hand UV-gemapped...
Es sind zwar noch nicht die Bereiche so optimal genutzt, aber ich wollte nun das Thema erstmal schnell halbwegs abschließen.
Die dazugehörige UV-Map

Ich überlege zur Zeit, ob ich nicht Rasenmäher usw. mit einbauen sollte :D
Rasenmäher Simulator 2017 :D
Und ein Haus, was da jemand die letzten Tage gebaut hat.
Ansonsten kann man nun Eingabetasten frei wählen, was aber nur lokal, nicht im Profil gespeichert wird.
Das Chunk generieren ist auch etwas beschleunigt, wobei ich auch überlege von 32³ auf 16³ runter zu gehen, damit es nochmal schneller ist. Die entfernten Chunks werden ja im Hintergrund aktualisiert, aber wenn man direkt vor der Nase abbaut, dann wird das direkt geupdated und erzeugt Ruckler.

Freut mich sehr, dass Du mal wieder was dran machst. Das Haus jedenfalls ist schick. Und irgendne Wachstumssimulation auf der Basis könnte durchaus Abnehmer finden. Aber nuja... Gameplay war noch nie so Deine Stärke :-)

Schrompf hat geschrieben:Das Haus jedenfalls ist schick

Ich anschließen mich tun.

Rasenmähen oder mit der der Sense zuhauen :)
Wär noch witzig wenn man sich einen Pfad durch das Gras hauen könnte und danach schneller durchlaufen kann.
Das Haus gefällt mir auch gut. Wäre noch witzig zu sehen wie eine komplette Stadt ausschauen würde.

Schrompf hat geschrieben:Gameplay war noch nie so Deine Stärke :-)

Aha, woran machst du das denn fest?

Zudomon hat geschrieben:

Schrompf hat geschrieben:Gameplay war noch nie so Deine Stärke :-)

Aha, woran machst du das denn fest?

Das war nur eine kleine scherzhafte Randbemerkung, weil Du nach all den Jahren immer noch keinen wirklichen Spielinhalt hast. Ne Farming Sim wäre z.B. eine wirklich coole Sache, vor allem als Multiplayer.

Ich weiß nicht, ob ich schon erwähnt, hatte, dass die Cluster Generierung nun wesentlich schneller ist. Das hintergrundterrain wird nun auch effektiver gerendert. Bedeutet, vorher hab ich einfach alle LOD's übereinander gemalt und dann per Clip nur den richtigen Bereich angezeigt. Jetzt wird entweder das eine oder das andere LOD gemalt... dadurch ist das Bild auch wesentlich stabiler und flipt nur dann wenn das LOD gewechselt wird.

Turbo Delphi 2006 war echt doof was das wechseln zwischen den build optionen angeht. Man muss nämlich da noch alles per Hand umstellen. Hab mir dann mal angeschaut, wo das gespeichert wird und mir dann eine 1 Click Lösung gebaut, um zwischen den Optionen zu wechseln. Damit es damals einfacher war, hab ich dann halt alles einfach in den Code gehauen, auch die Dev Sachen. Per PartitionsID und Pfad wurde dann ermittelt, ob es meine ultimative Developer Version ist, oder doch nur ein normaler Client. Theoretisch hätten also auch andere SQ updaten können... naja nicht ganz, weil die FTP Zugangsdaten hatte ich dann doch lieber ausgelagert. Jedenfalls ist das nun alles nicht mehr nötig.
1850 Kb hat die StoneQuest.exe gehabt. Hab mir gedacht, ein Icon muss ja nicht in 256² sein, 64² reicht auch. Damit schon 100 Kb gespart. Die exe ohne Debug Optionen erstellen sparrt auch nochmal 200-300 Kb. Dann konnte ich noch Funktionen raus nehmen, wie besagtes FTP, weil das auch von einer externen Anwendung gesteuert werden kann. Außerdem hat die Clipboard Unit hinten rum wieder die Forms, also die VCL mit eingebunden. Nach dem ganzen Refactoring komme ich nun auf 1003 Kb. Nun lasse ich dann noch am Ende UPX drüber laufen, was die exe Datei auf 360 Kb schrumpfen lässt. Das UPX die Virenscanner beunruhigt ist heutzutage nicht mehr so... sogar im Gegenteil. Lasse ich die exe auf VirusTotal prüfen, dann schlagen nur noch 3 von 56 Virenscanner an. Ohne UPX sind es 6.

Jedenfalls macht das so langsam den Installer überflüssig. Diesen hatte ich in erster Linie deswegen, weil dieser im Gegensatz zur StoneQuest.exe ziemlich klein war. Außerdem hat der die exe Datei versiegelt. Moment? Versiegelt? Am Ende der StoneQuest Datei wurde eine ClientID generiert und angehangen, außerdem die Versionsnummer. Mit der ClientID kann sich SQ am Server ausweisen und man braucht sich beim nächsten Start nicht wieder anmelden, weil der Server ja weiß, welcher Client sich wie eingeloggt hat. Natürlich ändert sich die ClientID, wenn man die exe kopiert. Ganz zu Anfang wollte ich damit mal einen Kopierschutz realisieren und es hätte tatsächlich geklappt, dass die exe die Ausführung verweigert, falls man diese woanders hin kopiert. Aber naja, da man eh ein Account System hat, ist das ganze recht überflüssig geworden.
Jedenfalls kam ich dann auf die Idee, die ClientID einfach zur Laufzeit zu erzeugen, dann brauch ich die auch nirgends hin speichern. Das vereinfacht die ganze Verwaltung auch und ich habe kein gefuckel mit den exe Dateien. In der ClientID werden übrigens keine persönlichen Informationen gespeichert!
Aktuell ist es so, dass ein CRC32 aus der Motherboard Seriennummer, CRC16 aus der PartitionsID und CRC16 aus dem Dateipfad gebildet wird. Also 8 Byte. Durch das Verwenden von mehreren Hashes glaube ich, Kollisionen wesentlich besser noch vermeiden zu können.
Ganz wichtig war für mich der Installer auch, weil die DirectX DLLs statisch gelinkt sind, dass diese existieren. Der Installer hat dafür gesorgt, dass diese Dateien vorhanden sind. Aber eigentlich sollte man die ja eh nicht selbst weiter geben und wenn DX installiert ist, sollten die auch da sein. Wenn ich das einfach mal vorraus setze in Zukunft, dann wird auch das überflüssig.
Das einzige, was der Installer dann noch bietet, ist der Eintrag in der Windows Firewall und das Desktop Icon. Beides nicht sooo gravierend. Desktop Icon erstellen könnte man als Menüoption in SQ mit einbauen. Wird kein Firewall Eintrag erstellt, dann fragt Windows automatisch den Benutzer.
Wichtiger wäre, in SQ einzubauen, dass dann diesen Firewall Status abgefragt wird und das ausführen verweigert wird, wenn es geblockt wird. Ich denke, als reines Multiplayer Spiel kann man vorraus setzen, dass die Anwendung nicht geblockt werden darf.
Also wird es dann erfreulicherweise darauf hinaus laufen, dass in naher Zukunft der Installer komplett verschwindet und man StoneQuest dann direkt da ausführt, wo man es haben möchte. Allerdings wäre es noch gut, dann beim start zu prüfen, ob man in dem Verzeichnis Schreibrechte hat. Sonst gibt es Probleme beim updaten und cachen.

Nachdem ich nun einiges an Management gemacht habe, hab ich heute Nacht zur Entspannung noch mal ein bisschen was fürs Auge gemacht.
Ich fand den Sternennebel irgendwie langweilig, vor allem, weil der zwischen den Sternen und Wolken irgendwie unter geht. Also hat der nochmal einen Anstrich bekommen, ist leicht geändert worden. Das der Planet doch auch davon angeleuchtet werden könnte. Also habe ich die Beleuchtung des Planeten und Ringes angepasst. Nicht perfekt, aber das Ergebnis sieht meiner Meinung nach doch besser aus als vorher. Die Wolken wurden dann auch nochmal etwas überarbeitet. Ein Zusatzparameter kann nun auch einstellen, ob die Wolken eher gleichmäßig oder Haufenweise verteilt sind. Wobei die Haufen schon sehr nach Regenwolken aussehen. Mir gefällt das jedenfalls.


Planet mit Hintergrundbeleuchtung:

Gleichverteile Wolken:

Gehäufte Wolken:

Zudomon hat geschrieben:Ganz wichtig war für mich der Installer auch, weil die DirectX DLLs statisch gelinkt sind, dass diese existieren. Der Installer hat dafür gesorgt, dass diese Dateien vorhanden sind. Aber eigentlich sollte man die ja eh nicht selbst weiter geben und wenn DX installiert ist, sollten die auch da sein. Wenn ich das einfach mal vorraus setze in Zukunft, dann wird auch das überflüssig.

Ja, aber man muss ja auch die *richtige* Version installiert haben … das kann für einige User durchaus anstrengend werden. Schicker Planet nichtsdestotrotz.

hört sich so an als ob du einiges aufgeräumt hast :)
die wolken sehen richtig geil aus.
der planet gefällt mir auch sehr gut, ist das ein modell oder vorgerendert in der skybox?

Danke!
Der Sternennebel steckt in einer Skybox... was nicht sein müsste, aber ich denke, den auch bewegen lassen ist too much.

Seit gestern habe ich gesucht, warum Avira rum zickt. Mir ist das vorher nicht aufgefallen, weil ich die EXE Datei vorher wirklich runterladen muss... einfach nur kopieren oder so, darauf schlägt Avira nicht an. Gelernt habe ich, UPX ist doch böse. Also lass ich dass dann doch. Ich zippe die Datei beim Update eh, und dann hat die auch nur 100 Kb mehr. Aber Avira springt auch an, sobald ich das Clipboard benutze.
Um genau zu sein, bei folgenden Befehlen: Nach insgesamt 80 Iterationen try&error habe ich rausgefunden, dass es, sobald ich die "imm32.dll" zusätzlich lade, für Avira doch in Ordnung ist, das zu verwenden. Die VCL bindet diese normalerweise ein. Deswegen hat Avira auch nicht angeschlagen, wenn irgendeine Unit dann hinter meinem Rücken doch die VCL eingebunden hat. Was auch etwas kurios ist, wenn ich nichts verwende sondern das Programm ausschließlich genannte Befehle benutzt, dann lässt Avira das auch durchgehen. Wahrscheinlich muss dazu noch irgendwas anderes kommen, damit es anschlägt. SQ macht ja schon so einiges, Direct3D, DirectSound, WinSock. Irgendwas wird es sein.

Vom Installer habe ich mich nun komplett losgesagt. Man braucht nun einfach nur die Zip Datei entpacken.

Ansonsten bleibt noch zu sagen, dass ich mit dem neuen Himmel wirklich glücklich bin. Vorher hatte ich das Wetter immer nur fest eingestellt. Jetzt gefällt es mir schon, die verschiedenen Phasen zu haben.

Das Beleuchtungmodell auf den Wolken ist echt geil.

Auch ich muß zwischendurch feststellen, dass die Wolken ziemlich cool aussehen.
Und der Planet gibt dem ganzen etwas Außerweltliches ... aber hat ja auch keiner gesagt, dass es die Erde ist :D

Zudomon hat geschrieben:Jedenfalls macht das so langsam den Installer überflüssig. Diesen hatte ich in erster Linie deswegen, weil dieser im Gegensatz zur StoneQuest.exe ziemlich klein war. Außerdem hat der die exe Datei versiegelt. Moment? Versiegelt? Am Ende der StoneQuest Datei wurde eine ClientID generiert und angehangen, außerdem die Versionsnummer. Mit der ClientID kann sich SQ am Server ausweisen und man braucht sich beim nächsten Start nicht wieder anmelden, weil der Server ja weiß, welcher Client sich wie eingeloggt hat. Natürlich ändert sich die ClientID, wenn man die exe kopiert. Ganz zu Anfang wollte ich damit mal einen Kopierschutz realisieren und es hätte tatsächlich geklappt, dass die exe die Ausführung verweigert, falls man diese woanders hin kopiert. Aber naja, da man eh ein Account System hat, ist das ganze recht überflüssig geworden.

Also die beste Lösung für dieses Problem habe ich mal in einem kleinen Freewarespiel gesehen (und dann gedanklich glaube ich noch ein klein wenig erweitert), leider weiß ich den Namen nicht mehr. Es ging um eine Online-Highscore und natürlich darum, dass man der einzige sein will, der sich unter seinem Namen eintragen kann. Man hat einfach seinen Namen eingetippt und das Spiel hat im Hintergrund ein zufälliges Passwort erzeugt und im Benutzerverzeichnis gespeichert. Dabei kann man natürlich diverse Dinge wie Seriennummern und Uhrzeit einfließen lassen. Mit diesem Benutzername / Passwort Paar wurde man dann auf dem Server registriert (wenn der Name noch frei war) und konnte in Zukunft immer wieder neue Punkterekorde eintragen, ohne sich über irgendwelche Accounts Gedanken machen zu müssen. Für den Fall das man umzieht, kann man einfach die Passwortdatei aus dem Benutzerverzeichnis mitkopieren. Das erfordert natürlich eine gewisse Weitsicht und auch ein wenig Erfahrung. Dafür gibt es dann aber Option zwei, bei der man zusätzlich eine EMail-Adresse angeben kann, die dann auch an den Server geschickt wird. Fortan kann man sich unter Angabe seines Benutzernamens bzw. seiner EMail-Adresse die Account-Datei jederzeit zuschicken lassen.
Das wundervolle an diesem System ist, dass es für den Benutzer optimal ist. Es kommt mit minimalen Daten aus, immerhin ist eine Highscoreliste ohne Namen ziemlich witzlos (wobei man es natürlich auch entsprechend umbauen könnte!) und hat dementsprechend auch minimalen Aufwand für den Benutzer (man muss einfach nur seinen Namen eintippen - fertig. Kein fummeliges Account anlegen, kein EMail-Adresse bestätigen). Trotzdem ist es genau so sicher (man kann halt ein gutes Passwort zufällig generieren) und skaliert perfekt: Entscheidet man sich zur Preisgabe seiner Mail-Adresse, wird es dementsprechend bequemer. Entscheidet man sich dagegen, kann man immer noch alles machen, man ist nur selber verantwortlich.

Leider habe ich ein ähnliches System nie wieder irgendwo gesehen. Man stelle sich einmal vor, man starte ein Online-Spiel und kann sofort loslegen - ganz ohne sich um Accounts Gedanken machen zu müssen. Nach einer halben Stunde merkt man, dass es Spaß macht und man entscheidet sich dazu, einen Benutzernamen zu bekommen. Nach einer Woche dann ist man sich sicher, dass man seinen Account tatsächlich langfristig behalten möchte und hinterlegt seine EMail-Adresse. Schöne heile Welt.
Aber "leider" haben Spieleentwickler natürlich kommerzielle Interessen. Sobald man den Account an einen gekauften Key binden möchte, bricht das System unweigerlich zusammen, weil man nicht mehr beliebig Accounts erstellen kann. Digitales Rechtemanagment eben. Was ich damit eigentlich nur sagen will: Jeder der nicht davon abhängig ist, durch derartige Maßnahmen seine Existenz zu sichern, sollte diese großartige Möglichkeit ergreifen, seine Spiele (in diesem Aspekt) besser (-> kundenfreundlicher) zu machen, als alles was am Markt ist.

Ich muss sagen, dass mich StoneQuest wirklich depressiv gemacht hat, wenn ich das mal ein paar Minuten ausprobiert habe. Der Trick, die letzten vier Frames zu überlagern um eine art temporales Antiaaliasing zu bekommen, war zwar nett, aber hatte ja das MotionBlur mit sich gebracht. Dass ich die letzten Bilder dann nur mit eingerechnet habe, wenn die Kamera nicht bewegt wurde, schien mir erstmal eine gute Lösung zu sein. Das Problem dabei war nur, dass es nun 3 Fälle gab, die sich mitunter fleißig abwechselten... man bewegt sich nicht und schaut sich kaum um -> schönes Antialiasing. Man dreht die Kamera nur leicht oder fängt an sich zu drehen -> MotionBlur. Man bewegt sich -> kriselliges Bild wegen der ganzen Mikrogeometrie. Dadurch wirkt das ganze ziemlich unschön.
Nun hab ich mich ein bisschen mit dem UE4 TAA beschäftigt. Statt der letzten 4 Bilder nimmt man nur das letzte und rechnet das einfach mit rein... allerdings unter Beachtung der alten Kameraprojektion. Um Ghosting zu vermeiden, werden die Farbwerte noch geclampt/geclipt. Das Ergebnis gefällt mir wesentlich besser, als das, was ich vorher drin hatte. Hab versucht das auf einem Video mal fest zu halten. Man erkennt das AA an sich kaum, wegen der schlechten Auflösung. Was man aber sieht ist, wie "unstetig" die Bewegung bei dem alten AA ist.
[youtube]zj1VpDe3bk0[/youtube]

Da ich mich nun wieder richtig gerne in StoneQuest aufhalte, bin ich auch entsprechend motiviert voran zu kommen. Ich werde mal schauen, ob das hybride Doom 4 rendering vielleicht schneller ist, als mein Deferred Ansatz. Deswegen werde ich da nochmal umbauen.
Ansonsten funktioniert nun das Sonnenflare auch für andere Items. So haben nun die Fackeln auch Flares.
Über [Shift]+[E] lässt sich nun auch bei der Rettungskapsel provisorisch Licht anschalten. Damit man auch Nachts direkt am Anfang was sehen kann. Ich werde schauen, dass ich in nächster Zeit massiv das Gameplay ausbauen werde. Ich glaube, dass neben der schlechten Performance vor allem auch die Unzugänglichkeit des Spiels das ganze unattraktiv macht.
Ansonsten habe ich den Volumennebel nochmal überarbeitet. Vorher wurde dieser in 1/2 Auflösung berechnet, jetzt nur noch in 1/4. An manchen stellen sieht man die niedrige Auflösung, aber zum Großteil fällt diese kaum auf. Das beschleunigt das Nebelrendering natürlich massiv, so dass man auf schnellen Karten die Godrays eigentlich schon nutzen kann. Habe auch noch im Nebelschatten ein bisschen Farbe mit eingebaut, damit das ganze Mystischer wirkt. Der Nebel liegt dabei auch nur in den Tälern... da ist die Sichtweite dann oft sehr beschränkt.

Zudomon hat geschrieben:Ich werde schauen, dass ich in nächster Zeit massiv das Gameplay ausbauen werde.

Super! Endlich! Die Grafik reicht doch langsam :)

Zudomon hat geschrieben:Habe auch noch im Nebelschatten ein bisschen Farbe mit eingebaut, damit das ganze Mystischer wirkt.

Sieht sehr gut aus; fiel mir schon auf der Startseite auf …

das problem mit dem anti-aliasing ist im video recht schwer zu erkennen, aber die neuste version ist doch merklich besser. schön dass du wieder freude daran hast, manchmal brauchts nur wenig um die motivation wieder zu finden.
freue mich sehr, dass du dich jetzt um gameplay kümmern willst, viel erfolg!

Ich adde doch noch ein bisschen debugging Zeugs und optimiere daraufhin ein bisschen.
Im Frame Debugger werden nun auch das zu zeichnende Objekt und dessen Informationen angezeigt. Außerdem sehe ich unten, in welchem Drawcall ich mich befinde, wobei hier bisher in grün die Dreieckszahl, in blau die Vertexshader- und in rot die PixelShaderInstruktionen jeweils relativ zueinander angezeigt wird.
Werde heute mal schauen, ob ich noch GPU-Timing dazu bekomme, damit ich auch weiß, wie lange ein Call dann auf der Grafikkarte tatsächlich braucht.



Die hohen Ausschläge bei dem VS stellen hier die Mikrogeometriesachen dar... also Grass usw.
Bei dem PS sieht man gut die niedrigen Ausschläge, da wird die Shadowmap gezeichnet. Ganz zu Beginn des Frames die Minimap... am Ende die hohen Ausschläge sind durch die Schatten/SSAO generierung, Deferred Schading usw.

Das war jetzt doch ein bisschen kniffelig, die GPU Timings zu generieren. Vorher hatte ich die Daten einfach direkt im Frame gesammelt und ausgegeben. Momentan ist es nun so gelöst, dass jeder zweite Frame ein Frame zum messen der Zeiten ist. Ich bin nun erstmal zufrieden, dass das Diagramm einigermaßen stabil ist. Die kleinen Schwankungen werden ausgeglichen, indem immer nur wenige Prozente der neuen gemessenen Zeit einfließen. Momentan ist es noch so, dass wenn das neue Ergebnis sehr von dem alten Abweicht, dass dann direkt auf den neuen Wert gesetzt wird. So gibt es aber doch noch einige extreme Ausreißer. Dabei ist auch nicht immer sicher, dass die GPU Zeiten wirklich korrekt sind.
Also muss mal schauen, dass ich das noch etwas besser hin bekomme. Aber erfreulicherweise zeigt sich mit diesem neuen Diagramm, dass zumindest bei meiner Graka ein hoher Peak beim erstellen der Lightblockingmap liegt. Wahrscheinlich hätte man das auch im PS-Instruktiondiagramm gesehen, wenn die dort verwendeten Schleifen unrollt gewesen wären.

Schick! Was sind die diagonalen Balken? Kernel-Muster bei SSAO?

Krishty hat geschrieben:Schick! Was sind die diagonalen Balken? Kernel-Muster bei SSAO?

Jo, leider nicht ganz perfekt... aber dafür kommt das SSAO mit 4 Samples aus! :D
Jetzt bin ich allerdings verunsichert. Fällt das zu sehr aus? Ist da noch eine "High Quality"-Version nötig?

… ist natürlich Jammern auf hohem Niveau, aber mir fällt es schon auf. Nicht im Gras, aber überall sonst. (Weniger als die scheiß Chromatische Aberration, aber mehr als die JPEG-Kompression, wegen der ich dich immer nerve ;) )

Sind auch deutliche Punkte auf der Fouriertransformation:
Wenn man die entfernt, wirft das Bild eindeutig weniger Schlieren:

Stimmt, wobei gerade die parallelen vertikalen Frequenzanteile bei der DCT auch nicht ganz natürlich erscheinen, hättest Du gleich mit entfernen/kompensieren können :) .

Krishty hat geschrieben:Weniger als die scheiß Chromatische Aberration

Werde ich abschaltbar machen ;)


Hab das jetzt selbst mal probiert mit einem png Ausschnitt... irgendwie echt krass...
Aber ich verstehe das nicht so ganz. Also ich mache ein paar SSAO samples. Durch das TAA überlagert sich das ganze, doch trotzdem bleibt ein Samplepattern zu sehen. Und dann transformiert man das ganze in den Spektralraum, filtert ein paar Teile weg, überführt es zurück und erhält ein makelloses Bild? Was ist das denn bitte für eine dunkle Magie, die da am Werk ist?! :o
Aber in Echtzeit lässt sich das wahrscheinlich nicht machen, vor allem wenn man auch FullHD haben möchte.

Naja, keine dunkle Magie – du kannst dir etwa vorstellen, dass das Bild in eine Reihe von Sinuskurven aller möglichen Frequenzen zerlegt wird. Die Wiederholungen bewirken dabei, dass einige Kurven (die mit der Frequenz der Wiederholung) hohe Amplitude haben. Löschst du die Amplitude, verschwinden auch die Wiederholungen.

Ist nützlich, wenn man ein Bild sieht, mit dem irgendwas nicht stimmt, aber man kann schlecht sagen, was. smurfer hat ja erwähnt, dass man damit auch deutlich die JPEG-Artefakte identifizieren kann.

Das Bild wird durchs Löschen der Frequenzen aber nicht wirklich besser, sondern enthält dann weniger Nutzinformation – es wird nur verschwommener. Das willst du eher nicht machen, obwohl’s in Echtzeit geht. (mein Glare läuft ja so, denn du kriegst Gauss-Filter beliebiger Größe in n log(n) statt n² hin … wenn du nur SSAO glätten willst, hast du auch bloß einen Kanal statt RGB, das ist dann nochmal deutlich schneller). Krassestes Beispiel: Hättest du diagonalen Text auf dem Bildschirm, wäre der dann total verwaschen.

Aber für prozeduralen Content ist es interessant. Ozeanwellen werden ja z.B. so simuliert, und du kriegst Noise differenzierter hin als mit den meisten anderen Algorithmen.

Frage am Rande: Auf der CPU ist FT - Multiplikation - IFT bekanntlich schneller als eine Faltung, insbesondere wenn man dasselbe Bild mit vielen Kerneln falten will. Wie ist es auf der GPU? EDIT: Ich meine natürlich nicht asymptotisch, das ist eh klar.

Alexander Kornrumpf hat geschrieben:Frage am Rande: Auf der CPU ist FT - Multiplikation - IFT bekanntlich schneller als eine Faltung, insbesondere wenn man dasselbe Bild mit vielen Kerneln falten will. Wie ist es auf der GPU?

Ganz spontan würde ich sagen, es hängt von der Kernelgröße der Filter und deren Anzahl ab.

Die DCT muss die gesamte Bildgröße mit einbeziehen, also vergleichbar mit der Faltung mit Kernel in Bildgröße. An der Stelle wird die Parallelisierbarkeit der GPU etwas geringere Bedeutung haben. Sprich, kleine Filter und kurze Filterketten sollten gerade auf der GPU mittels Faltung schneller zu berechnen sein. Sehr große Filterkernel (ideales Tiefpassfilter -> Faltung si-Funktion) könnten den GPU-Vorteil schwinden lassen und in Verbindung mit langen Filterketten eine Transformation lohnenswert machen.

Aber das ist lediglich meine Vermutung, getestet habe ich es nicht.