Vergleich von Forward und Deferred Rendering Kamil René König Bachelorarbeit Bachelor Informatik 12.08.2014 Betreuer: Prof. Dr. Detlef Krömker, Dr. Daniel Schiffner
Übersicht Motivation Definitionen Forward und Deferred Allgemein Betrachtete Algorithmen Benchmarktest Implementation Testfälle Ergebnisse Fazit 2 von 28
Motivation In den letzten Jahren gewann Deferred Rendering mehr an Beliebtheit Direkte Vergleiche zwischen Forward und Deferred Rendering immer noch nicht gänzlich vorhanden Performanceunterschied groß genug um von FR zu DR zu wechseln? 3 von 28
Definitionen Definitionsunterschied: Pixelshader in DirectX heißen Fragmentshader in OpenGl Hier benutzte Definition: Fragment: Ein rasterisiertes Vertex mit Tiefen- und/oder Farbinformation Pixel: Ein auf den Bildschirm geworfenes Fragment Ein ausgewählter Punkt auf einer Textur 4 von 28
Forward Rendering Forward und Deferred Allgemein Einfach zu implementieren und systemunabhängig Vor allem bei vielen dynamischen Lichtern schlechte Performanz Lichter) Laufzeit: O(Objekte 5 von 28
Deferred Rendering Forward und Deferred Allgemein Erst mit Multiple Rendertargets und Render-to-Texture Speicher effizient Hardware-Antialiasing und Transparenz nicht trivial Dafür aber: Szenenkomplexität irrelevant bei verspäteten Algorithmen Laufzeit: O(Objekte + Lichter) 6 von 28
Deferred Rendering Forward und Deferred Allgemein 7 von 28
Betrachtete Algorithmen Forward Rendering: Per-Fragment-Shading Early-Z Tile-based Culling Deferred Rendering: Screenspace-Shading Lightvolume-based Culling Lightvolume-based Culling mit Stencilbuffer Tile-based Culling 8 von 28
Tile-based Culling Unter anderem vorgestellt von Andrew Lauritzen [1]: Einteilung des Bildschirms in Tiles Bestimmung der im Tile auftretenden Lichter Nach Aufteilung der Lichter auf Tiles: Jeder Pixel durchläuft nur die Lichter in seinem Tile Zusätzlich möglich: Culling in Z-Richtung Benötigt minimale/maximale Z-Werte pro Tile Beim Forward Rendering vorheriger Tiefenpass nötig 9 von 28
Tile-based Culling Laufzeit von Größe/Anzahl der Tiles und Lichter abhängig Algorithmus lässt sich parallelisieren Mehrmalige Unterteilungen möglich Benötigt Compute Shader min. OpenGl 4.0, DirectX 11, OpenCl, etc. Worst-Case-Fall: Alle Lichter treffen alle Tiles 10 von 28
Tile-based Culling Ohne Z-Culling Mit Z-Culling 11 von 28
Deferred Rendering Lightvolume-based Culling Falls realistische Beleuchtung nicht nötig ist können Lightvolumes zur Abgrenzung benutzt werden. 12 von 28
Deferred Rendering Lightvolume-based Culling Anzahl der Fragmente pro Licht eingegrenzt Overhead: Rendern der Lightvolumes Blendungsoperation Texturzugriffe Verbesserungsbedarf: Fragmente können vor/hinter den Volumen liegen 13 von 28
Deferred Rendering Lightvolume-based Culling 14 von 28
Deferred Rendering Lightvolume-based Culling 15 von 28
Deferred Rendering Lightvolume-based Culling mit Stencilbuffer Rot Verdeckte Vorderseite Blau Sichtbare Vorderseite Grün Sichtbare Vorder- und verdeckte Rückseite 16 von 28
Deferred Rendering Lightvolume-based Culling mit Stencilbuffer Algorithmus von DICE Engineer Yuriy O'Donell [2]: Tiefentest: größer/gleich Pro Licht: Erstelle Maske von gesehener Vorderseite der Lichtfläche: Tiefentest erfolgreich: Wert im Stencilbuffer +1 Berechne Licht nur wo Rückseite von Objekten verdeckt wird: Stenciltest: Werte gleich 0 Falls beide Tests erfolgreich: Beleuchtungsrechnung gefolgt von Clear des Stencilbuffers Verbesserungsmöglichkeit: Stencilwert an LichtID ankoppeln: Wert = (LichtID mod 255) +1 17 von 28
Benchmarktest Implementation Geprüft werden Worst-/Best-Case aller Algorithmen Kamerafahrten erfolgen über Bézierkurven und vordefinierte Positionen Millisekunden-Angaben über OpenGl-interne Abfragen Testsystem: CPU: Intel Core i5-3750k @ 3.4 GHz GPU: Nvidia GeForce GTX 660 TI, 4GB Ram Arbeitsspeicher: 8 GB Ram System: Windows 7 64-Bit 18 von 28
Benchmarktest Implementation Benutzt wird ein einfaches PhongBeleuchtungsmodell Benötigte Informationen: Position im Worldviewspace Normalen Diffuse Farben Shininess-Wert Lichtemittierungsfaktor Lichterinformationen 19 von 28
Testfälle [3] 20 von 28
Ergebnisse: Forward Rendering Laufzeitvermutung: Abhängigkeit von Objekt- und Lichteranzahl O(Objekte Lichter) Early-Z: Best-Case: Mittelwert: -19.5% Median: -20.5% Worst-Case: Mittelwert: +1.5% Median: +1.7% 21 von 28
Ergebnisse: Deferred Rendering Laufzeitvermutung: Allgemeine Objektanzahl weniger relevant als bei FR Fast konstante Performance beim Objekttest O(Objekte + Lichter) Lightvolume-based Culling: Worst-Case: Bei großen Radien langsamer als SS Stencil: Nutzbarkeit von minimal getroffener Lichtfläche abhängig 22 von 28
Forward: Ergebnisse: Tiled-based Culling Deferred: 23 von 28
Ergebnisse: Tile-based Culling Z-Culling: Effizienz stark von der Verteilung der Tiles-Tiefenwerte wie auch Lichteffektivität abhängig Forward: Deferred: 24 von 28
Ergebnisse: Forward und Deferred Rendering im Vergleich Einfache Algorithmen: Tile-based Algorithmen: 25 von 28
Fazit Deferred Rendering bei sehr vielen Objekten und dynamischen Lichtern fast immer im Vorteil Durchschnittliche Szenengegebenheiten bringen jedoch keine großen Unterschiede hervor Letztendlich abhängig vom Projekt und der Zielplattform 26 von 28
Aussichten und mögliche Untersuchungen Mit neuerer Technologie werden Nachteile des Deferred Rendering ausgebessert: Bessere Anti-Aliasing-Methoden Größere Bandbreiten und Render-to-TextureSpeicherplatz Untersuchungen: Performanz von weiteren Algorithmen unter Deferred Rendering Alternative Methode zu beiden Rendering-Verfahren: Deferred Lighting 27 von 28
Quellen [1] Andrew Lauritzen, SIGGRAPH 2010, Deferred Rendering for Current and Future Rendering Pipelines https://software.intel.com/sites/default/files/m/d/4/1/d/8/lauritzen_defe rred_shading_siggraph_2010.pdf [2]Yuriy O'Donnel, Rendering deffered lights using Stencil culling algorithm, http://kayru.org/articles/deferred-stencil/ [3]Frank Meinl, Crytek Sponza, http://graphics.cs.williams.edu/data/meshes.xml