Hi,
herzlichen Glückwunsch zur erfolgrechen Abgabe deiner Arbeit! Hab mir die Arbeit jetzt mal komplett durchgelesen, liest sich im Großen und Ganzen sehr gut und die Ergebnisse sehen klasse aus! Einige Fragen bzw Anmerkungen hätte ich dazu noch:
Irgendwie hab ich SVOGI im "State of the Art" Abschnitt vermisst. Gab es einen besonderen Grund warum du das nicht mit aufgenommen hast? Würde eigentlich erzänzend ganz gut dazu passen.
Fast alle Spiele nutzen heute ein hybriden Ansatz, um Reflexionen darzustellen. Meistens ist es sowas wie SSR + localized Cubemaps + global Cubemap, in der Reihenfolge als Fallbacklösung. Remember me z.B. verwendet außer (interpolierten) localized Cubemaps (parallax corrected cubemaps) ebenfalls billboard reflections. KZ: SE verwendet ein komplexes System aus localized Cubemaps, einem Screenspace Ansatz sowie analytischen Arealights und Billboard Reflections.
Bei Cubemap Reflexionen steht in der Arbeit als häufiger Nachteil, das diese manuell in der Welt verteilt werden müssen. Ich kenn diesen Hang von Programmierern, möglichst alles zu automatisieren. Meiner Erfahrung nach sehen Artisten das häufig ganz anders. Artisten mögen es häufig sämmtliche Hebel in der Hand zu haben, mit der Möglichkeit ihre künstlerischen Visionen umsetzen zu können. Ein Beispiel ist das GI System das Crytek verwendet (LPV). In einem Talk hat damals ein Lighting-Artist darüber geredet, dass das System aus einem Art-Standpunkt relativ unbrauchbar ist und indirekte Beleuchtung an allen Ecken und Enden mit manuell platzierter Lichtquellen gefaked wurd. Ähnliches hab ich auch bei meinem letzten Spiel (LotF) erlebt, da war die GI Lösung Enlighten.
Auch bzgl der Cubemaps habe ich irgendwie parallax korrigierte Cubemaps im Vergleichs-Abschnitt vermisst. Gab es da bestimmte Gründe, wieso das rausgelassen wurde?
Bzgl der SSCT Implementierung von dir. Hast du eine Lösung bzgl "reprojection artifacts" eingebaut? Du verwendest ja den letzten Frame, wie verhält sich die Implementierung bei schnellen Kamerabewegungen?
Die Performanz scheint bei höheren Auflösungen ziemlich heftig, zumindest für den realen Einsatz in Spielen. Im Allgemeinen würde man ja aber auf der halben oder viertel Auflösung arbeiten, da passen die Zahlen ja schon wieder ganz gut ins Budget. Interessant fand ich auch folgenden Satz:
"because particularly state changes to the framebuffer binding are very time consuming and it would also increase the memory footprint"
Das splitten in zwei Pässe kann durchaus ein großer Gewinn sein. Gerade auf moderner AMD Hardware (GCN) könnte das einen großen Unterschied machen hinsichtlich VGPR pressure. Wäre bestimmt mal ein interessanter Aspekt, sich das genauer anzuschauen.