Sie sind auf Seite 1von 80

Bachelorarbeit

Vergleich von Forward und Deferred Rendering

Eingereicht von:
Kamil Ren Knig
Matrikelnummer: 4565020
Studiengang: Bachelor Informatik
Goethe-Universitt Frankfurt am Main

Betreut durch:
Prof. Dr.-Ing. Detlef Krmker
Professur fr Graphische Datenverarbeitung
Goethe-Universitt Frankfurt am Main

Frankfurt am Main, den 21. Juli 2014


Eidesstattliche Erklrung

Erklrung gem Bachelor-Ordnung 2007 24 Abs.11

Hiermit besttige ich, dass ich die vorliegende Arbeit selbststndig verfasst habe und
keine anderen Quellen oder Hilfsmittel als die in dieser Arbeit angegebenen verwendet
habe.

Ort, Datum

Vorname, Nachname
Inhaltsverzeichnis

Abbildungsverzeichnis 2

1 Einleitung 3

2 Grundlagen 5
2.1 Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Framebuffer Objects . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Stencil Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3 Compute Shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Sonstiges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Datenimplementation . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Beleuchtungsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Renderingalgorithmen 10
3.1 bersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Forwad Rendering - Per-Fragment-Shading . . . . . . . . . . . . . . . . . 12
3.2.1 Grundidee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Forward Rendering - Early-Z (Per Fragment) . . . . . . . . . . . . . . . . 13
3.3.1 Grundidee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Deferred Rendering - Screen-Space Shading . . . . . . . . . . . . . . . . . 15
3.4.1 Grundidee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 Deferred Rendering - Lightvolume Based Culling . . . . . . . . . . . . . 20
3.5.1 Grundidee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6 Deferred Rendering - Lightvolume Based Culling mit Stencil-Buffer . . . 23
3.6.1 Grundidee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7 Deferred Rendering - Tile Based Culling . . . . . . . . . . . . . . . . . . . 27
3.7.1 Grundidee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.8 Forward Rendering - Tile Based Culling . . . . . . . . . . . . . . . . . . . 32
3.8.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.8.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Benchmarktest 34
4.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Testflle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 Messwerte und Auswertung der Benchmarktests 42


5.1 Testszene: Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.1 Erwartungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.2 Messergebnisse und deren Auswertung . . . . . . . . . . . . . . . 44
5.1.3 Fazit des ersten Testfalls . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2 Testszene: Groe Flche - Sicht von der Seite . . . . . . . . . . . . . . . . 49
5.2.1 Erwartungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.2 Messergebnisse und deren Auswertung . . . . . . . . . . . . . . . 50
5.2.3 Fazit des zweiten Testfalls . . . . . . . . . . . . . . . . . . . . . . . 54
5.3 Testszene: Groe Flche - Sicht von oben . . . . . . . . . . . . . . . . . . . 55
5.3.1 Erwartungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.2 Messergebnisse und deren Auswertung . . . . . . . . . . . . . . . 56
5.3.3 Fazit des dritten Testfalls . . . . . . . . . . . . . . . . . . . . . . . 58
5.4 Testszene: Crytek Sponza . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4.1 Erwartungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4.2 Messergebnisse und deren Auswertung . . . . . . . . . . . . . . . 60
5.4.3 Fazit des Average Case . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.5 Gesamtauswertung aller Messergebnisse . . . . . . . . . . . . . . . . . . 64

6 Fazit 65

Anhang A 67
Anhang B 68

Literaturverzeichnis 74

1
Abbildungsverzeichnis

3.1 Deferred-Rendering-Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Deferred Rendering mit Hardware-Anti-Aliasing . . . . . . . . . . . . . . 20
3.3 Mgliche Artefakte beim Stencil Buffer . . . . . . . . . . . . . . . . . . . . 25
3.4 Tile Based Culling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 Testszene - Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38


4.2 Testszene - Flche - Sicht von der Seite . . . . . . . . . . . . . . . . . . . . 39
4.3 Testszene - Flche - Sicht von oben . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Testszene - Sponza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1 Box: Lichttest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44


5.2 Box: Lichttest vergrert . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Box: Objekttest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 Box: Radiustest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5 Flche - Sicht von der Seite: Lichttest mit Radius 200 . . . . . . . . . . . . 50
5.6 Flche - Sicht von der Seite: Lichttest mit Radius 500 . . . . . . . . . . . . 51
5.7 Flche - Sicht von der Seite: Radiustest . . . . . . . . . . . . . . . . . . . . 52
5.8 Flche - Sicht von der Seite: Objekttest . . . . . . . . . . . . . . . . . . . . 53
5.9 Flche - Sicht von Oben: Lichttest . . . . . . . . . . . . . . . . . . . . . . . 56
5.10 Flche - Sicht von Oben: Objekttest . . . . . . . . . . . . . . . . . . . . . . 57
5.11 Flche - Sicht von Oben: Radiustest . . . . . . . . . . . . . . . . . . . . . . 58
5.12 Sponza: Einfache Algorithmen mit 100 Lichtern . . . . . . . . . . . . . . 60
5.13 Sponza: Tile-Based-Algorithmen mit 100 Lichtern . . . . . . . . . . . . . 60
5.14 Sponza: Einfache Algorithmen mit 200 Lichtern . . . . . . . . . . . . . . 61
5.15 Sponza: Tile-Based-Algorithmen mit 200 Lichtern . . . . . . . . . . . . . 62

2
1 Einleitung

Beim klassischen Forward Rendering wird die Beleuchtungsberechnung whrend der


Rasterisierung der Vertices durchgefhrt, was in Fllen mit wenigen Lichtern und
einfacher Szenenkomplexitt keine greren Probleme darstellt. Schwieriger wird je-
doch die Berechnung bei einer erhhten Anzahl von Lichtern und Objekten, wo eine
fragmentabhngige Beleuchtungsberechnung unter anderem auch Fragmente behan-
delt die von anderen Objekten verdeckt werden knnten, was zu Redundanz fhren
kann.

Um diese Problem zu lsen gibt es viele verschiedene Mglichkeiten - eine davon hat
sich vor allem in den letzten Jahren einiges an Beliebtheit gewonnen. Gemeint damit ist
das Deferred Rendering.

Unter Deferred Rendering - auch bekannt als Deferred Shading - werden im allgemei-
nem Renderingmethoden bezeichnet, bei denen bentigte Informationen fr die Be-
leuchtung und Schattierung zwischengespeichert und die Berechnungen auf einen spte-
ren Zeitpunkt in der Rendering-Pipeline verlagert werden.

Vorteilhaft zeigt sich vor allem hier, dass, da die Szenerie zuerst durch einen Geometry-
Pass alle wichtigen Informationen in bildschirmgroen Texturen speichert, somit die
versptete Beleuchtung von der Szenenkomplexitt grtenteils unabhngig gemacht
wird.

Deferred Rendering wurde des fteren in verschiedenen Varianten in der Vergangenheit


vorgestellt - unter anderem bei der SIGGRAPH 2010 von Andrew Lauritzen wie auch
bei der GDC 2011 von Johan Andersson - generelle Vergleiche zwischen Deferred und
Forward Rendering sind aber schwer aufzufinden. Aus diesem Grund befasst sich das
in dieser Arbeit vorzufindende Thema mit dem Performancevergleich beider Rendering-
methoden, wie auch der Analyse dieser. Die Frage, inwiefern das Deferred Rendering
tatschlich einen Vorteil gegenber des Forward Rendering hat, und inwieweit sogar ein
Wechsel von Forward Rendering zu Deferred Rendering sinnvoll wre, oder ob dieser
sogar unter bestimmten Bedingungen unabdinglich sein knnte, wird auch versucht in
dieser Arbeit zu beantworten.

3
1 Einleitung

Vorab sei angemerkt, dass es unzhlige Mglichkeiten gibt, beide Renderingmethoden


zu implementieren - viel zu viele um diese in nur einer Arbeit durchnehmen zu kn-
nen. Aus diesem Grund werden hier nur einige grundlegende Algorithmen betrachtet,
welche versuchen fters vorkommende Probleme der beiden Renderingverfahren in
deren simpelsten Form zu beseitigen, oder wenigstens grtenteils einzuschrnken. Zu-
stzlich dazu wird eines der moderneren Lichtabgrenzungsverfahren namens Tile Based
Culling (Kachel-basierte Abgrenzung) bearbeitet und dem Leser vorgestellt, welches
auch von den oben bereits erwhnten Lauritzen und Andersson bei deren respektiven
Prsentationen vorgestellt wurden. Dabei wird dieses Abgrenzungsverfahren nicht nur
beim Deferred, sondern auch beim Forward Rendering eingesetzt, um einen weiteren
Vergleich zwischen beiden Verfahren zu ermglichen.

Demzufolgend wird der Hauptteil dieser Arbeit in vier Abschnitte aufgeteilt: Zuerst
werden einige Grundlagen der Grafikprogrammierung errtert - insbesondere im Hin-
bezug auf die in dieser Arbeit benutzte OpenGl-API - die fr ein Verstndnis der hier
im zweiten Teil vorgestellten Algorithmen ntig sein wird.

Bei jedem Algorithmus wird als aller Erstes dessen Grundkonzept aufgegriffen, die
gewhlte Implementation in dieser Arbeit erklrt, und daraufhin die theoretische Per-
formance analysiert.

Um die Laufzeiten der verschiedenen Algorithmen aber tatschlich messen zu knnen,


wurde dazu speziell ein Benchmarkprogramm fr diese Arbeit programmiert. Deshalb
werden die wichtigsten Informationen dessen im dritten Teil zuerst zusammengefasst
dargestellt, wie auch die gewhlten Testszenen dem Leser nher gebracht und die Wahl
derer erklrt.

Danach werden dann die Messungsergebnisse aller Testflle aufgetragen und ausgewer-
tet. Aus diesen sollte sich dann ein Bild zeigen, inwiefern unsere Analysen tatschlich
der Realitt entsprechen, und somit auch geklrt werden, welcher der hier vorgestellten
Algorithmen die beste Performance abgibt.

Nach dem Hauptteil folgt zu guter Letzt ein kurzer Fazit dieser Arbeit, in welchem
unsere Ergebnisse der Fragestellung entsprechend zusammengefasst werden und - falls
mglich - diese beantwortet wird.

4
2 Grundlagen

2.1 Definitionen

Zu allererst sollte die Benutzung der einiger hier benutzter Wrter genauer definiert
werden. In dieser Arbeit wird zwischen dem Forward und Deferred Rendering in dem
Sinne unterschieden, dass beim Forward Rendering die Beleuchtungsrechnung direkt
beim Renderpass mit der Geometrien erfolgt, whrend beim Deferred Rendering diese
auf einen spteren Zeitpunkt verschoben wird.

Dies ist insofern relevant, da die Wrter bersetzt ber das Rendern selber aussagen,
ob dieses "vorwrts" oder "versptet" ausgefhrt wird. Da die Wrter aber allgemein
sehr flexibel benutzt werden - zum Beispiel wrden nach einer strikten Definition
auch Forward-Rendering-Techniken, die vor dem Wurf der Bilder auf dem Bildschirm
zuvor Post-Processing-Effekte ausfhren, dieses als "versptetes Rendern"gelten - ist
die obige Definitionsgebung in dieser Arbeit wichtig, um Verstndnisskonflikte zu
umgehen.

Des Weiteren ist hier auch die Definition von Pixeln ntig, da in dieser Arbeit die
OpenGl-API benutzt wird. Unter DirectX gelten zum Beispiel bestimmte Programme
die auf der Grafikkarte ausgefhrt werden - sogenannte Shader - als Pixel Shader[1],
whrend in OpenGl die Programme auf hnlicher Ebene als Fragment Shader bezeichnet
werden [2].

Um auch hier besseres Verstndnis der benutzten Wrter zu erlangen, sollen in dieser
Arbeit folgende Definitionen gelten:

Rasterisierte Vertices, die ber den Vertex Shader an den Fragment Shader geschickt
werden, sind als Fragmente zu bezeichnen.

Fragmente, die letztendlich auf dem Endbild vorhanden bleiben und nicht vorzeitig
verworfen oder berschrieben wurden, wie auch Informationen, die aus Texturen
herausgelesen werden, werden als Pixel bezeichnet.

5
2 Grundlagen

Der Unterschied zwischen Pixeln und Fragmenten ist also der, dass Fragmente nicht
unbedingt auf dem Endbild angezeigt werden, und somit nur als "hypothetische Pixel"
gelten, da sie jederzeit verworfen werden knnen.

Als Verstndnisbeispiel fr die Relevanz dieser Unterscheidung: Ein Algorithmus der


jeden Pixel durchgeht, bearbeitet bei einer Bildschirmgre von 800 mal 600 Pixeln
nur diese 480.000 Pixel, whrend ein Algorithmus, welcher jedes Fragment durchgeht,
eventuell sogar ein mehrfaches davon bearbeiten muss, falls Objekte existieren, die
mehrfach durch andere Objekte verdeckt wurden.

2.2 OpenGL

In dieser Arbeit wird die OpenGl-API[3] benutzt, mit welcher wir ber Schnittstellen
unsere 3D-Anwendung ausfhren lassen knnen. Aufgrund besserer Kenntnise in
der Java-Programmiersprache hat man sich hier fr einen OpenGl-Wrapper namens
LWJGL[4] entschieden, mit welchem die Benutzung der OpenGl-API auch in Java
ermglicht wird. Da LWJGL mit ab hier benutzten Version 2.9.1 offiziell OpenGL 4.4
untersttzt[5], sind uns somit alle fr unsere Arbeit bentigten Funktionalitten der
OpenGl-API vollstens ber Java-Code ergnglich, was vor allem bei spterer Benutzung
von Compute Shadern relevant wird.

In dieser Arbeit wird das Wissen ber die Standardrenderingpipeline [2] vorausge-
setzt - dazu gehren unter anderem auch ein Verstndnis ber Vertex und Fragment
Shader, sowie die Benutzung von blichen Puffern wie den Farbpuffern und Tiefen-
puffern. Weitere Konzepte die wichtig fr die Arbeit sind, werden kurz angespro-
chen.

2.2.1 Framebuffer Objects

Ab OpenGl 3.0 wurden Framebuffer Objects (FBO) offiziell eingefhrt [6], welche vom
Konzept her mit dem normalen, sogenannten Default-Framebuffer zu vergleichen sind.
Der Unterschied zwischen ihnen liegt dabei darin, dass FBOs uns vor allem eine grere
Vielfalt an Mglichkeiten geben, Render Targets zu implementieren, was beim Deferred
Rendering wichtig sein wird.

Whrend der Default-Framebuffer nur die von OpenGl bereitgestellten Puffer hat - zwei
Farbpuffer fr das Double Buffering, fr Stereoskopie zwei weitere, je nach Einstellung
auch einen Tiefen- wie Stencilpuffer - knnen wir bei FBOs mehrere Texturen als Farb-
puffer, bzw. eine Textur als Tiefenpuffer hinzufgen - genannt werden diese Texturen

6
2 Grundlagen

in diesem Fall Attachments. Somit knnen wir, wenn wir zuerst einen Renderpass mit
einem FBO anstellen, diese befllten Texturen in einem weiteren Renderpass beim
Default-Framebuffer als Input verwenden. Das Interessante dabei ist, dass wir nicht
alleine auf Farbinformationen begrenzt sind, sondern alle mglichen Zahlenkombina-
tionen in den Texturen speichern knnen - gegeben, dass die Textur bei der Erstellung
die richtigen Einstellung in der Bit-Gre und des Formats zugeteilt bekommen hat.
Genaueres, inwiefern uns das helfen mag, wird im spteren Abschnitt 3.4 Deferred
Rendering, erklrt.

2.2.2 Stencil Buffer

Ein Stencil Buffer [7] ist, wie der Tiefenpuffer auch, ein Puffer der fr jeden Pixel einen
Wert inne hlt, mit welchen dann Vergleichsoperationen durchgefhrt werden knnen
um Fragmente zu verwerfen. Der Vegleichswert, wie auch die zu setzenden Werte,
knnen dabei selbst frei bestimmt werden, solange die Zahl mit 8-Bit reprsentiert
werden kann.

Normalerweise werden die Tiefen- und Stenciltests laut OpenGl-Dokumentation erst


nach dem Fragment Shader durchgefhrt, unter bestimmten Voraussetzungen [8], die
auch hier in der Arbeit gelten, geschehen die Tests vor dem Fragment Shader, wodurch
wir diesen von zustzlichen Berechnungen befreien knnen.

In OpenGl werden Stencil Buffer durch verschiedene Einstellungsfunktionen betrie-


ben. Dabei whlt man einen selbst erdachten Vergleichswert fr den Stenciltest, und
entscheidet, was mit den Werten im Stencil Buffer passieren soll. Der Stenciltest selber
wird durch eine Einstellung definiert, die sagt, in welchen Fllen der Test erfolgreich
sein soll (" immer", "niemals", " Stencilwertvergleich mit dem Vergleichswert", etc.) Wie
der Stencil Buffer nun auf einen Stenciltest reagiert hngt zustzlich vom Tiefentest aus.
Insgesamt gibt es gibt somit drei Flle:

1. Der Stenciltest schlgt fehl.


2. Der Stenciltest ist erfolgreich, der Tiefentest schlgt fehl.
3. Der Stenciltest und der Tiefentest sind beide erfolgreich.

Jeden dieser drei Flle kann man eine Aktion zuweisen, die der Stencil Buffer danach
ausfhren muss - zum Beispiel kann ihm zugeteilt werden, dass er im ersten Fall den
derzeitigen Stencilwert beibehlt, im zweiten Fall den Wert inkrementiert und im dritten
Fall den Wert mit dem derzeitigen Vergleichswert austauscht.

Der Stencil Buffer wird in Abschnitt 3.6 Deferred Rendering - Lightvolume Based Culling
mit Stencil Buffer wichtig.

7
2 Grundlagen

2.2.3 Compute Shader

Ab OpenGl 4.3 wurden auch Compute Shader in die OpenGl-Core eingefhrt [9].
Compute Shader sind dabei Programme, die auf der Grafikkarte unabhngig von
der OpenGl-Pipeline ausgefhrt werden knnen. Sie werden vor allem in Fllen von
wiederholten Ausfhren bestimmter Berechnungen eingesetzt, die parallel durchgefhrt
werden knnen, um die bessere Performance der GPU im Vergleich zur CPU ausnutzen
zu knnen. Das Wichtigste, was bei Compute Shadern fr diese Arbeit zu verstehen
ist, ist, dass aufgrund der Mglichkeit, diesen parallel ausfhren lassen zu knnen,
einige weitere Eigenschaften bei Compute Shadern existieren die vor deren Benutzung
in Betracht gezogen werden mssen:

Einerseits kann man selber im Code bei der Ausfhrung von Compute Shadern die
Anzahl dieser selbst bestimmen - gemeint sind damit beides, die sukzessive, wie auch
die parallele Ausfhrung. Diese erfolgt im CPU-Code ber eine bergabe von drei
Zahlen, die jeweils eine Ebene der Ausfhrungen reprsentieren. Bei einer bergabe
der Zahlen {2,3,1} zum Beispiel wird der Compute-Shader zweimal in "X-Richtung",
dreimal in "Y-Richtung", und einmal in " Z-Richtung" ausgefhrt. Somit haben wir dann
insgesamt 2 3 1 = 6 Ausfhrungen, welche alle ihre eigene aus den Zahlen beste-
hende ID erhalten. Die Anzahl an parallelen Ausfhrung muss dafr im Shadercode
vor Beginn des Programms stehen - sie muss der Grafikkarte bei der Kompilierung
bekannt sein. Dort verhlt es sich hnlich mit drei Zahlen und drei Ausfhrungsebe-
nen.

Andererseits muss bei bestimmten Zugriffen auf fr alle Ausfhrungen des Compute
Shaders ffentlich zugngliche Daten wie Buffer, gemeinsame Variablen (shared va-
riables), etc. auf die Konsistenz der Daten geachtet werden, da parallele Zugriffe die
Daten unvoraussehbar verndern knnen. Aus diesem Grund werden auf der einen
Seite sogenannte Memory-Barrier benutzt - Aufrufe im Shadercode, welcher der Grafik-
karte mitteilt an dieser Stelle darauf zu warten, dass alle Ausfhrungen am gleichen
Punkt angelangt sind, bevor der Code weitergefhrt werden kann. Auf der anderen
Seite sollten fentlich zugngliche Variablen nur ber atomare Funktionen manipuliert
werden.

8
2 Grundlagen

2.3 Sonstiges

2.3.1 Datenimplementation

Die meisten bentigten Informationen werden an die Shaderprogramme ber sogenann-


te Uniforms bergeben, welche man sich als Variablen vorstellen kann, die spezifisch
vom Benutzer selber bergeben werden mssen und dabei grtenteils fr mehrere
Shaderberechnung konstant bleiben (z.B. Kameramatrizen, konstante Objektdaten wie
Lichtemittierungsfaktoren, etc.).

Da die Lichteranzahl in spteren Tests aber sogar an den vierstelligen Bereich angelangt,
und Uniforms schnell bei Arrays ihre Speichergrenzen erreichen, hat man sich in
dieser Arbeit dazu entschieden, diese in sogenannten Shader Storage Buffer Objects
(SSBO)[10] darstellen zu lassen. Wichtig ist hierbei nur, dass diese Pufferobjekte fr die
Grafikkarte relativ schnell erreichbar sind, und grtenteils fr Informationen benutzt
werden, die eine groe Anzahl an Zahlen beinhalten knnen - unter anderem die
Lichterinformationen, spter auch noch die verschiedenen Tiefenwerte und Lichter-IDs
beim Tile Based Culling.

2.3.2 Beleuchtungsmodell

Wir werden in der Arbeit eine einfache aber des fteren bliche Blinn-Phong-Beleuchtung
benutzen[11]. Im Endeffekt heit dies, das unsere Resultatsfarbe bei der Beleuchtungs-
rechnung jeweils aus einem diffusen, specular und ambienten Anteil bestehen, welche
jeweils mit den zugehrigen Farben des Objekts vermischt und aufeinander addiert
werden. Der specular Anteil bentigt dazu fr jedes Objekt einen Shininessfaktor,
whrend der diffuse Anteil ber einen Lichtemittierungsfaktor manipuliert werden
kann.

9
3 Renderingalgorithmen

Bevor wir alle in der Arbeit benutzten Renderingalgorithmen vorstellen, folgt hier
zuerst eine bersicht dieser, die jeden Algorithmus kurz zusammenfasst. Daraufhin
werden in den nchsten Abschnitten alle Algorithmen nacheinander dem Leser n-
her gebracht, wie auch deren Implementation und Vor- und Nachteile genauer er-
klrt.

3.1 bersicht

Forward Rendering - Per Fragment:

Ein ganz normaler Forward Renderer welcher die Beleuchtung ohne zustzliche Opti-
mierung berechnet. Der Per-Fragment-Algorithmus fhrt dabei die Beleuchtungsrech-
nung jeweils fr jeden Fragmenten aus, der an den Fragment Shader gesendet wird. Dies
ist die simpelste Implementation aller hier vorgestellten Algorithmen.

Forward Rendering - Early-Z(Per-Fragment):

Der Early-Z-Algorithmus basiert auf dem vorherigen Algorithmus mit dem Unterschied,
dass durch eine vorzeitigen Tiefen-Vergleich nur die Fragmente an den Fragment Shader
gesendet werden, die auch auf dem Bildschirm abgebildet werden.

Deferred Rendering - Screen-Space Shading:

Der Deferred Rendering-Algorithmus fhrt zuerst einen Geometry-Pass durch, der


alle wichtigen Informationen in bildschirmgroen Texturen abspeichert die fr die
Beleuchtungsberechnung wichtig sind. Zuletzt wird die Beleuchtung pro Pixel auf dem
Bildschirm berechnet.

10
3 Renderingalgorithmen

Deferred Rendering - Lightvolume-based Culling:

Diese Variante des Deferred Rendering versucht die Beleuchtungsberechnung zu-


stzlich zu optimieren, indem jedes Licht nur auf den Fragmenten berechnet wird,
welche von einer der Lichtquelle hnlich-groen Lichtvolumen getroffen werden.
Fr Punktlichter wren dies zum Beispiel Sphren der Gre des Wirkungsradius
eines Lichtes, fr direktionale/globale Lichter wre dies ein einfacher Fullscreen-
Quad.

Deferred Rendering - Lightvolume Based Culling mit Stencil Buffer:

Das Lightvolume Based Culling kann zustzlich mit einem Stencil Buffer erweitert
werden, um Fragmente, die sich auerhalb der Lichtervolumen befinden von den
Fragmenten abzugrenzen, die von den Lichtern tatschlich getroffen werden. Somit
kann im besten Fall die an den Fragment Shader versendete Fragmentenanzahl um
einen weiteren Anteil verkleinert werden.

Deferred Rendering - Tile Based Culling:

Die komplexeste Variante der hier vorgestellten Deferred Rendering-Algorithmen,


welcher den Bildschirm in kleinere Rechtecke (bzw. Kacheln, engl. "Tiles") aufteilt
und je nach Tile berechnet, welches der Lichter in der Umgebung diesen Tile berhrt.
Somit kann man herausfinden, welche Bildschirmpixel schlussendlich von welchen
Lichtern getroffen werden und diese abhngig von den Tiles abgrenzen (Tile Based
Culling).

Die Einteilung des Bildschirms in kleinere Tiles kann auch mehrmals hintereinander
durchgefhrt werden, jede weitere Einteilung mit kleineren Tiles, um den Algorithmus
zu optimieren. Es werden mehrere Mglichkeiten an Unterteilungen untersucht, wie
auch die Performanceauswirkungen auf zustzliche Abgrenzung der Lichter in Z-
Richtung durch Tiefenbestimmung der Tiles.

Forward Rendering - Tile Based Culling:

Die gleiche Methode kann man auch bei einem Forward Rendering-Algorithmus an-
wenden um diesen zu optimieren. Zustzlich gibt es hier auch die Mglichkeit die
Tile-Based Culling-Methode zusammen mit dem Early-Z-Algorithmus zu vebinden, um
den Forward Renderer zu verbessern. Beide Methoden, Tile Based Culling mit und ohne
Early-Z, werden im spteren Verlauf der Arbeit verglichen.

11
3 Renderingalgorithmen

3.2 Forwad Rendering - Per-Fragment-Shading

3.2.1 Grundidee

Beim Forward Rendering werden die in der 3D-Szene existieren Geometrien nacheinan-
der an die Grafikpipeline geschickt. In dieser werden zuerst die Vertices, aus welchen
die Objekte bestehen, an den Vertex-Shader gesendet, in welchem die bentigten Positi-
onsberechnung, Texturkoordinaten, sowie weitere bentigte Daten vorbereitet werden.
All diese Daten werden interpoliert - das Vertice dabei rasterisiert - an den Fragment
Shader geschickt, wo dann im Normalfall pro Fragment die Beleuchtungsrechnung
durchgefhrt wird.

Diese Herangehensweise entspricht der einfachsten Vorstellung einer normalen Grafik-


Pipeline. Alle Berechnungen werden nacheinander durchgefhrt, bevor das Endbild an
den Default-Framebuffer verschickt wird. Es werden somit keine Optimierungsmglich-
keiten in dieser Implementation in Erwgung gezogen, womit dieser Algorithmus bei
einfachen Szenerien die schnellste Art der Grafikberechnung darstellt, whrend bei kom-
plexeren Umgebungseigenschaften die Performance sehr schnell zusammenbrechen
msste.

3.2.2 Analyse

Wegen der simplen Herangehensweise ist die Laufzeit somit von der Lichteranzahl,
wie auch der versendeten Fragmentanzahl abhngig. Letztere kann unter Umstnden
die Anzahl der Pixel auf dem Bildschirm aber bersteigen, was im Vergleich zu den
anderen Algorithmen wichtig zu beachten ist.

Dabei sei zu bedenken, dass ein solcher Forward Renderer die Beleuchtungsberechnung
so am realistischsten darstellen kann, da den Lichtern keine Eingrenzungen gegeben
sein mssen. In der Realitt breiten sich Lichter nmlich bis ins Unendliche hinaus, was
bei den spteren Algorithmen nicht der Fall sein wird, da - auer beim Early-Z-Culling
und dem nicht erweiterten Deferred Rendering Algorithmus - alle weiteren Optimie-
rungsmethoden auf der Annahme basieren, dass Lichter ein bestimmtes Einflussradius
besitzen.

Ein weiterer Vorteil von Forward Renderern generell ist die relative Einfachheit der Im-
plementation von semi-/transparenten Objekten, bei denen Z-Sortierung und einfache
Blending-Methoden benutzt werden knnen. Wie man spter bei der Funktionswei-
se eines Deferred Renderers sehen wird, ist dies bei solchen eher weniger mglich.

12
3 Renderingalgorithmen

Auch sind Anti-Aliasing-Methoden besser und vor allem vielfltiger zu implementie-


ren, weil wegen der Gegebenheiten des Deferred Renderering diesem grtenteils nur
Post-Processing-Methoden zur Verfgung stehen - auf beide Nachteile des Deferred
Rendering wird spter etwas genauer eingegangen.

Nachteil bei dieser Implementation des Forward Rendering insbesondere ist jedoch die
uerst schlechte Laufzeit bei einer groen Anzahl an Fragmenten und Lichtern. Es wird
pro Fragment jedes Licht in Betracht gezogen, egal wie wenig das Licht fr einen Effekt
auf das Fragment haben wird. Zustzlich bedeutet dies, dass auch Fragmente an den
Fragment Shader zur Beleuchtungsrechnung geschickt werden die eigentlich verdeckt
sind, was zu redundanten Berechnungzyklen fhren kann.

Im Grunde genommen bedeutet dies, dass bei Szenen mit vielen - vor allem vielen
verdeckten - Fragmenten und einer hheren Anzahl an dynamischen Lichtern die
Performance sehr schnell einbrechen knnte, bei Szenen mit sehr wenigen Lichtern,
Fragmenten und berlappungen dafr aber die unteren, komplizierteren Algorithmen
gar nicht bentigt werden.

3.3 Forward Rendering - Early-Z (Per Fragment)

3.3.1 Grundidee

Die Early-Z-Variante eines jeweiligen Forward Rendering-Algorithmus verndert ge-


nerell nichts an der Beleuchtungsrechnung, versucht aber das Verdeckungsproblem
- d.h. die Anzahl an verdeckten Fragmenten und die daraus resultierende Redun-
danz in der Berechnung - zu lsen. Dazu wird die Anzahl der Fragmenten einge-
grenzt, die an den Fragment Shader gesendet werden. Dies wird durch einen Tiefenpass
durchgefhrt, der nur die Tiefeninformationen im Depth-/Z-Buffer speichert - den
Schreibvorgang der Fragmentfarben sollte man dabei aus Performancegrnden aus-
schalten.

Nach dem ersten Pass wird vor dem eigentlichen Forward Rendering der Schreibvor-
gang des Z-Buffers ausgeschaltet, wobei der Tiefentest entweder auf "gleich", oder
"kleiner gleich" eingestellt wird. Somit werden nur diejenigen Fragmente an den
Fragment Shader gesendet, die den Tiefenvergleich bestehen, was natrlich nur der
Fall ist, wenn es sich um ein Fragment handelt, welches auf dem Endbild sichtbar
ist.

Beim zweiten Pass werden daher die Modelle wie beim Per-Fragment-Algorithmus an
das Shader-Program mit allen bentigten Informationen fr die Beleuchtungsrechnung

13
3 Renderingalgorithmen

gesendet. Da man die Tiefeninformationen schon im ersten Pass gespeichert hat werden
diese nicht mitgeschrieben.

In OpenGl wrde man die Einstellungen in dieser Reihenfolge ndern lassen:

1 // Schalte Schreiben zum Tiefenpuffer an


2 glDepthMask ( true ) ;
3 // Schalte Schreiben der Farbinformationen aus
4 glColorMask ( false , false , false , false ) ;
5 // Normales Tiefentesten - Kleinere Tiefe besteht den Test
6 glDepthFunc ( GL_LESS ) ;
7 // Rendere alle opaquen Objekte
8 RenderOpaqueModels () ;
9 // Schalte Schreiben zum Tiefenpuffer aus
10 glDepthMask ( false ) ;
11 // Schalte Schreiben der Farbinformationen ein
12 glColorMask ( true , true , true , true ) ;
13 // Nur Fragmente mit der gleiche Tiefe bestehen den Test
14 glDepthFunc ( GL_EQUAL ) ;
15 // Rendere alle opaquen Objekte noch einmal , wobei jetzt der
16 // Shader mit der Beleuchtungsrechnung benutzt werden sollte
17 RenderOpaqueModelsWithShading () ;

Von der Implementation her muss nur darauf geachtet werden, dass beim Early-Z
semi-/transparente Objekte nicht im Tiefenpass vorkommen, da bei solchen Objekten
die dahinter liegenden Fragmente, die beim Early-Z verworfen werden, von groer
Relevanz fr die Farbenberechnung sind.

3.3.2 Analyse

Die Laufzeit der zustzlichen Early-Z-Methode ist zwar auch von der Anzahl der
Fragmente abhngig, der Gewinn in Performance jedoch zeigt sich bei den durch den
Tiefentests abgeschnittenen Fragmente, die nicht mehr Teil der Beleuchtungsrechnung
sind.

Die Laufzeit der Beleuchtungsrechnung ist also weniger abhngig von der Gesamtan-
zahl an Fragmenten als bisher, da nur die Fragmente betrachtet werden, die tatschlich
auf den Bildschirm landen. Der Worst-Case msste aber dennoch dem oberen Per-
Fragment-Algorithmus entsprechen, da im schlimmsten Fall alle in der Szene vorhan-
denen Objekte sichtbar sein knnten. In solchen Szenerien knnte dies den doppelten
Renderpass berflssig gelten lassen, wodurch der Overhead die generelle Laufzeit des
gesamten Rendervorgangs erhhen kann.

14
3 Renderingalgorithmen

Grundstzlich jedoch werden aber im Normalfall meistens Fragmente existieren die


verdeckt werden, weswegen der Overhead im Vergleich zum Performancegewinn nicht
zu schlimm ausfallen sollte.

Dies bedeutet also, dass die Early-Z-Methode vor allem bei Szenen mit viel verdeckten
Fragmenten schneller verlaufen sollte, als die normale Forward Rendering Methode
- bei Szenen mit kaum Verdeckung und vielen Fragmenten knnte aber der doppelte
Pass unntige Performanceverluste erbringen.

Inwiefern und bei welchen Szenen die Early-Z-Methode aber tatschlich einen Vorteil
bringen mag, wird spter in den Benchmarktests berprft.

3.4 Deferred Rendering - Screen-Space Shading

3.4.1 Grundidee

Die Grundidee der Deferred Rendering-Methoden besteht darin, die Beleuchtungsrech-


nung von der Anzahl der zu bearbeitenden Fragmente unabhngig zu machen, um
die Laufzeit somit zu verbessern. Angenommen wird dabei, dass nur jedes Fragment
welches auch tatschlich den Bildschirm trifft, Auswirkungen auf das Gesamtbild haben
wird.

Damit stellt sich aber auch die Frage, wie man effizient alle bentigten Informationen
einfach abspeichern und wieder laden kann, wobei die Implementation nicht zu schwer
ausfallen sollte. Seit der Mglichkeit, Multiple Render Targets (MRT) benutzen zu kn-
nen, hat sich die Umsetzung von Deferred Renderern deutlich vereinfacht. MRT wurden
in OpenGL 2.0 und DirectX 9 eingefhrt [12], und obwohl es nicht unmglich ist, einen
Deferred Renderer mit nur einem Render Target zu implementieren, ist es natrlich viel
performanzlastiger und umstndlicher dies so handzuhaben, da mehrfache Psse ntig
wren, schon um alleine die Informationen zu erhalten, die mit MRT in einem einzigen
Renderpass abgespeichert werden knnen.

Die Implementierung basiert auf einer Aufteilung der gebrauchten Informationen, die
ntig sind fr die jeweilige Beleuchtungsrechnung. Generell werden bei der Beleuch-
tung die Positionen im World-Space, die Normalen, die Albedo-Informationen (diffuse
Farbwerte, Texturfarben), je nach Beleuchtungsmodell Specular- und weitere lichtma-
nipulierende Faktoren und sonstige mgliche Daten wie Material- oder Objekt-IDs
bentigt. All diese Werte sollte man so effizient wie mglich in Texturen speichern, da
mit erhhter Pixelanzahl und grerem Informationsgehalt der bentigte Render-to-
Texture Speicherplatz steigt.

15
3 Renderingalgorithmen

Abbildung 3.1: Deferred-Rendering-Beispiel


Von Links nach Rechts die Reihen durch:
Normalentextur, Diffuse Farbtextur, Tiefentextur, das resultierende Endbild

Nachdem dieser sogenannte Geometry Buffer (G-Buffer) nach einem ersten Renderpass
vervollstndigt wird, kann in einem zweiten Pass die Beleuchtungsrechnung aktiviert
werden. Am simpelsten wird dies durch das Rendern eines Fullscreen-Quads bewltigt,
welcher jeden Pixel auf dem Bildschirm trifft. Jedes Fragment, das in diesem zweiten
Pass an den Fragment Shader gesendet wird, berechnet nun fr sich die Endfarbe aus
den bergebenen Texturen des G-Buffers. Das Ausleseverfahren ist einfach umzusetzen,
indem die Fragmentkoordinate als Texturkoordinate in jeder Textur benutzt wird. So
kann man sich die gebrauchten Informationen fr das jeweilige Fragment in den Shader
laden und die Beleuchtungsrechnung durchfhren.

Zur Namensgebung: Eigentlich trgt das simple Deferred Rendering keinen Eigen-
namen, genauso wie rein technisch gesehen alle Deferred-Rendering-Methoden das
Shading im Screen-Space ausfhren. Da wir hier aber zwischen den verschiedenen
Deferred-Rendering-Varianten unterscheiden wollen, wird im Folgenden mit Screen-
Space Shading die hier vorgestellte Variante gemeint sein.

16
3 Renderingalgorithmen

3.4.2 Implementation

Die Implementation der Texturinformationen wurde in dieser Arbeit aufgrund der


einfachen Phong-Beleuchtung simpel gehalten. Es werden insgesamt vier Texturen
gebraucht - drei der vier Texturen liegen dabei im RGBA16F-Format: eine von die-
sen speichert die diffusen Farben der Weltobjekte, die zweite speichert die jeweiligen
Normalen, die dritte speichert Werte wie Shininess- und Lichtemittierungsfaktoren/Spe-
cular Skalar. Fr den Tiefenpuffer wird die vierte Textur gebraucht, welche hier noch als
einfache 24-bit Tiefentextur in OpenGl erstellt werden kann - dies ist nicht unbedingt
immer der Fall. Spter wird bei einer der folgenden Algorithmen ein Stencilbuffer be-
nutzt, bei welchem eine kombinierte 24-bit/8-bit Tiefen-/Stenciltextur benutzt werden
muss.

Die Worldview-Position der Fragmente htte man auch in einer weiteren Textur spei-
chern knnen, ntig ist dies aber nicht, da man genauso einfach die Position aus den
Z-Werten im Z-Buffer auslesen kann und sich somit Speicherplatz sparen kann. Aus
dem Z-Wert lassen sich nmlich, gegeben der Bildschirmkoordinaten, eine eindeuti-
ge Position im Worldview-Raum berechnen. Dazu muss im Shader die Umrechnung
der Worldview-Koordinaten zu Screen-Space in umgekehrter Reihenfolge durchge-
fhrt werden, d.h. die Screen-Space-Koordinaten werden zuerst in Normalized Device
Coordinates (NDC) umgerechnet, woraufhin der Koordinatenvektor im NDC mit der
invertierten Projektionsmatrix multipliziert wird um die Worldview-Koordinaten zu
erhalten.

Das Rendern wird in zwei Pssen erledigt. Der erste Geometry-Pass rendert zuerst
alle Weltobjekte und speichert die oben erwhnten Informationen in den Texturen,
die einem selbst erstellten Framebufferobject (FBO) als jeweilige Depth- und Color-
Attachments zugeteilt wurden. Nach dem ersten Pass wird der derzeitig gewhlte
Framebuffer zurck auf den von OpenGl bereitgestellten Default-Framebuffer gesetzt,
damit der zweite Pass, welcher den Fullscreen-Quad aufzeichnet, die Fragmente auf
den Bildschirm wirft.

3.4.3 Analyse

Die Laufzeit der Beleuchtungsberechnung ist nun nicht mehr von der Fragmentenanzahl
abhngig, sondern alleine von der Anzahl an Lichtern und der Anzahl der Pixel. Zu be-
merken ist hierbei die Tatsache, dass, da die Bildschirmauflsung wie auch die Lichteran-
zahl (wobei dies abhngig von der gewhlten Szeneriebedingungen ist, je nachdem ob
Lichter verschwinden knnen oder nicht) jeweils eine Konstante sind, die Laufzeit, wie
auch die Performance generell gleichmig bleiben sollte.

17
3 Renderingalgorithmen

Als Overhead kommt hier zustzlich zu der ber alle Lichter laufende For-Schleife im
Shader auch allgemein die gesamte Vorbereitung und Benutzung des G-Buffers hinzu,
welcher aus dem bentigten Speicher, der Geschwindigkeit und der Bandbreite der
Texturhantierung (Speichern und Laden von MRT, sowie der Texturenzugriff/Texture-
Lookup) besteht. Dies ist natrlich noch performancelastiger und relevanter bei Sys-
temen, die nicht gengend Speicher auf der Grafikkarte brig haben - unter ande-
rem ltere PC-Systeme und Konsolen die auch schon so unter Speicherplatzmangel
leiden. Als Beispiel sei die Xbox 360 erwhnt, wessen EDRAM nur 10 MB an Spei-
cherplatz hat [13], in welcher alle Render Targets passen mssen, was bei mehreren
16/32-Bit Zahlen auf mehreren Texturen in Bildschirmgre kaum ausreichen kann,
wenn das gewhlte Beleuchtungsmodell viele Informationen zur Berechnung ben-
tigt.

Mit neueren Technologien wird dieser Defizit von Deferred Rendering aber immer
weniger an Relevanz besitzen. Whrend viele mobile Gerte heutzutage immer noch
nicht gengend groe Bandbreiten fr die Untersttzung einer gnzlichen Deferred-
Rendering-Pipeline besitzen, ist dies nur eine Frage der Zeit, bis es soweit kommt -
OpenGL ES zum Beispiel brachte den Support fr MRTs schon im Jahre 2012 mit der
Version 3.0 [14], whrend die Unity3D-Engine, die wie OpenGl ES unter anderem bei
mobilen Gerten benutzt wird, eine abgenderte Version des Deferred Renderings
implementiert hat namens Deferred Lighting [15].

Bei diesem wird nur eine Textur mit Normalen und Specularinformationen neben dem
Tiefenpuffer mitgespeichert, im Gegenzug fr die Kosten eines zustzlichen Render-
passes. Sie ist vor allem im Konsolenbereich wegen geringen Speicherplatzes oder
Bandbreite beliebt, aus Grnden der schon so enormen Gre der Arbeit wurde aber
auf einen zustzlichen Vergleich zwischen der hier vorgestellten Algorithmen und dem
Deferred Lighting verzichtet - der Vollstndigkeit halber sollte dies hier aber dennoch
erwhnt werden.

Vorteilhaft beim Deferred Rendering ist grundstzlich die weniger GPU-lastige Beleuch-
tungsberechnung, die auch bei schwcheren Grafikkarten Szenerien mit einer Vielzahl
an Lichtern ermglichen, ohne die Performance zu sehr runterzudrcken. Auch ist
die Implementation von Deferred Rendering generell simpel gestaltet, vorausgesetzt die
Grafikkarte untersttzt die Mindestvoraussetzungen fr MRT.

Zu bedenken ist aber auf der anderen Seite, dass Grafikkarten normalerweise die Anzahl
an Texturen, die bei einem Pass bergeben werden knnen, eingrenzen. Hier muss man
sich dann, abhngig von der Komplexitt des Beleuchtungsmodells welches die Gre
der bentigten Informationsmenge definiert, berlegen, wie man entweder die Daten

18
3 Renderingalgorithmen

in so wenige Texturen einfgt wie nur mglich, oder man in der Implementation die Be-
rechnung der Beleuchtung in mehrere Shadingpsse aufteilt.

Auch zu den Nachteilen gehren aber vor allem die Tatsache, dass die vorherig an-
gesprochene Annahme nicht in jedem Fall der Realitt entspricht. Vor allem bei semi-
/transparenten Objekten sind auch die Informationen von verdeckten Objekten fr die
schlussendliche Pixelfarbe wichtig, beim Deferred Rendering werden diese Informatio-
nen aber nicht mitgespeichert.

Es wurden zwar mehrere Mglichkeiten, transparente Objekte dennoch zu implemen-


tieren, in der Vergangenheit benutzt - das Online-Spiel Tabula Rasa des im Jahre 2009
geschlossenem Entwicklerstudios Destination Games zum Beispiel benutzte zwei ver-
schiedene Rendering-Pipelines gleichzeitig um transparente Objekte aus dem Forward
Renderer im Endbild mit dem Ergebnis des Deferred Renderers in Verbindung zu
bringen[16], whrend Emil Perssons Implementation eines Deferred Renderers unter
anderem einen erweiterten G-Buffer benutzt, welcher mehrere Schichten an Texturen
speichert, um die Informationen hinterer Pixel speichern zu knnen [17]- generell sind
aber all diese Methoden komplexer und zeitaufwendiger als einfache Forward Renderer
dies ermglichen knnen.

Auch gestaltet es sich als schwierig, mehrere und/oder komplexere Beleuchtungsmo-


delle zu implementieren, da verschiedene Modelle verschiedene Daten gebrauchen,
was nun wiederum eine Vielzahl an Texturen und Speicher-/Ladeimplementationen
dieser voraussetzt.

Des Weiteren ist die fehlende Mglichkeit von hardwarebasierenden Anti-Aliasing (AA)
ein weiterer Nachteil, da, auch wenn AA beim ersten Geometry-Pass mglich ist, dieses
erst wegen bei den durch die Beleuchtungsrechnung vernderten Endfarben zur vollen
Geltung kommen kann, welche beim Deferred Rendering erst nach dem AA berechnet
wird. Somit bleiben einem nur Post-Processing-AA als Alternativen brig, auch wenn
in letzter Zeit Fortschritt in dieser Richtung gemacht wurde(unter anderem mit SRAA
[18] und FXAA [19]).

Im Endeffekt kann man vor allem bei Szenen mit einer hohen Anzahl an Fragmenten
und dynamischen Lichtern von der Deferred Rendering Methode theoretisch viel ge-
winnen, auch wenn insbesondere bei dieser Implementation eines Deferred Renderers
Szenen mit wenig berlappenden Lichtern(falls Lichter mit Wirkungsradius implemen-
tiert wurden) zu viele zustzliche Berechnungszyklen bei der Beleuchtungsrechnung
verbrauchen, da vor allem bei jedem Pixel jedes Licht mitberechnet wird, auch wenn
dies nicht unbedingt ntig wre.

19
3 Renderingalgorithmen

Abbildung 3.2: Deferred Rendering mit Hardware-Anti-Aliasing


Links zu sehen das Bild mit Forward Rendering, rechts mit Deferred Rendering, beides
bei Grafikkarten blichen 8xMSAA

3.5 Deferred Rendering - Lightvolume Based Culling

3.5.1 Grundidee

Auch wenn man schon im vorherigen Algorithmus die Beleuchtungsrechnung von der
Fragmentanzahl der Szenenerie abgetrennt hat, kann man diesen dennoch weiterhin ver-
bessern. Wie bereits erwhnt wurde, werden im bis jetzt vorhandenem Algorithmus alle
Pixel durchgegangen, wobei bei jedem Pixel alle Lichter betrachtet werden. Was ist aber
mit Pixeln, die soweit von einer Lichtquelle entfernt liegen, dass diese kaum einen Effekt
auf diesen Pixel hat? Um somit den vorherigen in dieser Hinsicht zu verbessern, wird
Deferred Rendering des fteren mit Lightvolumes, d.h. Lichtervolumen implementiert
[20]. Mithilfe von geometrischen Primitiven lassen sich nmlich dem Wirkungsradius
hnlich groe Objekte an den Shader schicken, mit dem Unterschied, dass anstelle von
dem Zeichnen dieser Primitive nur die Beleuchtungsrechnung innerhalb der getroffenen
Fragmente aktiviert wird. Fr jedes Licht wird ein solches Primitv and den Shader ge-
schickt und das Resultat der Berechung wird beim Fragment additiv geblendet, sodass
fr jedes Licht auch nur die Fragmente berechnet werden, die dieses Licht auch trifft.
Wichtig dabei zu beachten ist, dass, damit auch jeder von einem Licht getroffene Pixel
an den Shader geschickt wird, der Tiefenvergleich ausgeschaltet wird, da die derzeitig
gespeicherte Tiefe innerhalb des Z-Buffers irrelevant ist - Lichter knnen sich nicht
gegenseitig verdecken, wenn dann nur berlappen.

20
3 Renderingalgorithmen

3.5.2 Implementation

Implementiert wird dies hnlich der oberen Deferred Rendering-Methode. Die Vorbe-
reitung bleibt gleich, der Unterschied liegt beim finalen Zeichnen. Anstelle von einem
Fullscreen-Quad der jeden Pixel an den Shader sendet - wo dann jedes Licht pro Pi-
xel berechnet wird - wird fr jedes Punktlicht eine dem Wirkungsradius gleich groe
Sphre an den Shader geschickt. Fr direktionale und globale Lichter werden dennoch
Fullscreen-Quads gebraucht.

An den Shader werden neben des Primitivs auch die jeweilige Lichter-ID geschickt,
sodass auch nur dieses eine Licht aus dem Light-Buffer fr dieses eine Primitv berechnet
wird.

Benutzt wurden folgende (Blendungs-)Einstellungen in dieser Reihenfolge:

1 glDisable ( GL_BLEND ) ; // Beim ersten Pass wird nicht geblendet


2 glCullFace ( GL_BACK ) ; // Es werden die Rueckseiten abgeschnitten
3 FirstGeometryPass () ; // Geometry - Pass
4 glEnable ( GL_BLEND ) ; // Blenden wird eingeschaltet
5 glDisable ( GL_DEPTH_TEST ) ; // Tiefentest wird ausgeschaltet
6 glBlendEquation ( GL_FUNC_ADD ) ; // additives Blenden
7 glBlendFunc ( GL_ONE , GL_ONE ) ; // Die Farbe des Fragments , wie
8 // die Farbe des derzeitigen Lichts sind gleichwertig
9 glCullFace ( GL_FRONT ) ; // Es wird die Vorderseite abgeschnitten
10 // da man innerhalb einer Lichtsphaere trotzdem den Effekt eines
11 // Lichtes erkennen sollte
12 for ( int LightID = 0; LightID < Max_Light_Count ; LightID ++)
13 {
14 SecondPrimitivPerLightPass ( LightID , Primitiv [ LightID ]) ;
15 } // zweiter Pass , welcher fuer
16 // jedes Licht dessen Primitive " zeichnet " und im Shader nur
17 // fuer jeweils dieses Licht die Beleuchtung berechnet

3.5.3 Analyse

Da nur die Pixel gezeichnet werden, die jedes Licht trifft, sollte die Laufzeit im Allge-
meinen besser sein als die des Screen-Space Shadings.

Der Overhead beim Lightvolume-based Culling kommt aber dabei in drei Formen:

Als erstes Problem zeigen sich Fragmente der Lichtervolumen die auf dem Bildschirm
landen und die Beleuchtungsrechnung bei Pixeln in den Texturen im G-Buffer starten,
die nicht einmal im Volumen vorkommen. Dies kann daher kommen, dass, falls ein

21
3 Renderingalgorithmen

Licht von einem Objekt verdeckt wird, oder das Licht selber dieses berdeckt obwohl
das Objekt auerhalb des Lichtradius liegt, so wird dort die Berechnung umsonst
erledigt.

Ein weiterer Overhead ist die Anzahl an Draw-Calls, da diese einmal pro Primitve, das
heit einmal pro Licht, benutzt werden. OpenGl arbeitet effizienter mit einer mglichst
geringeren Anzahl an Draw-Calls, was aber hier schwer zu umgehen ist, wenn es wich-
tig ist, das pro gezeichnete Primitive nur ein Licht berechnet werden soll. Dazu kommt
auch noch die Tatsache,dass bei diesem Algorithmus bei jedem Draw-Call additiv
geblendet wird, was zustzlich an Performance kostet.

Auch zu bedenken ist aber die dritte Art vom Overhead: das Auslesen der Texturin-
formationen. Im vorherigen Algorithmus wird jeder Bildschirmpixel einmal durch-
gegangen, wodurch bei jeder Textur der jeweilige Pixel nur einmal ausgelesen wird.
In diesem Fall werden diese Informationen aber pro Licht pro Pixel einmal ausgele-
sen

whrend beim vorherigen Algorithmus dies nur von der Bildschirmgre und Texturen-
anzahl alleine abhngig war. Denn auch wenn heutige Grafikkarten den Texture-Lookup
von Informationen im Shader weitestgehend optimieren knnen, dies vor allem aber
nur dann der Fall ist, wenn die zu durchsuchenden Koordinaten auf der Textur auch im
Programm als Konstanten vorkommen, nicht, wie in diesem Fall, als nicht vorausseh-
bare Variablen, welche bei jedem Draw-Call eine andere Position auf dem Bildschirm
ansprechen.

Im Endeffekt bedeutet dies, dass, theoretisch, die Lightvolum-Based-Culling-Methode


effizienter ist als der Algorithmus ohne diese, falls die Lichter die vorhanden sind
kaum den ganzen Bildschirm einnehmen. Je mehr Pixel von mehreren Lichtern getrof-
fen werden, desto geringer fllt der Performancegewinn aus. Sobald der Bildschirm
grtenteils von gengend vielen Lichtern getroffen wird, kann es sogar sein, dass
die Methode ohne Culling wegen dem hier vorhandenem Overhead effizienter sein
knnte. Anders gesagt, whrend die normale Deferred Rendering-Methode grtenteils
eine konstante Laufzeit behlt, msste die Lightvolume-based Culling-Methode je nach
Szenerie besser oder schlechter laufen.

Vor allem Szenen mit wenig berlappenden Lichtern mssten also einen Performance-
gewinn erbingen, whrend Szenen mit vielen berlappenden Lichtern und Objekten die
diese verdecken groe Performanceeinbuen machen sollten, einerseits wegen der red-
undanten Berechnungen bei verdeckten Lichtervolumen, andererseits wegen der bereits
erwhnten erhhten Anzahl an Textur-Zugriffen die zusammen mit der Lichteranzahl
skaliert. Inwiefern dies jetzt Auswirkungen auf die Laufzeit des Algorithmus tatschlich
haben mag wird spter bei den Benchmarktests berprft.

22
3 Renderingalgorithmen

3.6 Deferred Rendering - Lightvolume Based Culling mit


Stencil-Buffer

3.6.1 Grundidee

Einen der bereits erwhnten Nachteile knnen wir hier aber mit etwas Geschick verbes-
sern. Wie bereits erwhnt werden alle Pixel die von den Lichtervolumen im Screen-Space
getroffen werden an den Fragment Shader gesendet um dort die Beleuchtungsrechnung
durchzufhren, obwohl diese nicht berall notwendig ist. Bis jetzt werden nmlich
Objekte die vor, hinter oder in einem Lichtervolumen stehen alle gleichwertig behandelt.
Um dies zu ndern und einige Berechnungszyklen sparen zu knnen, kann ein Stencil
Buffer benutzt werden.

Der hier benutzte Algorithmus orientiert sich dabei grtenteils an der von DICE
Rendering Engineer Yuriy ODonnel [21] Konzeption, wobei bei den benutzten Ver-
gleichswerten diese fr eine bessere Performance modifiziert wurden. Eine genauere
Erklrung dieser Entscheidung wird beim genauen Durchgang des Algorithmus erlu-
tert, welcher zusammengefasst wie folgt aussieht:

1. Zuerst werden im Tiefenpuffer alle Tiefenwerte der Szene durch den G-Buffer-Pass
gespeichert.

2. Pro Licht wird:

2.1. Je nach Licht-ID der Stencil Buffer geleert

2.2. Eine Maske ber die im Bild auftretende Flche des Lichtervolumen erzeugt

2.3. Die Beleuchtungsrechnung nur dort aktiviert, wo die obere Maske passiert wird
und gleichzeitig ein Objekt innerhalb des Lichts existiert

Die Stencilmaske wird ber einen ersteren Stencil Pass erstellt, in welchem nichts auer
der Position der Vertices des Lichtervolumens an die Shader geschickt werden und der
Stenciltest immer erfolgreich ist. Bei einem auf "grer/gleich" eingestellten Tiefentest
und gecullten Rckseiten der Dreiecke werden nur die Fragmente des Lichtervolumens
den Tiefentest bestehen, die fr die Kamera nicht sichtbar sind. Genau in diesem Fall
setzen wir die Werte auf einen Vergleichswert, der an die Lichter-ID gekoppelt ist.
Da wir nur 8-Bit fr den jeweiligen Stencilwert zu Verfgung haben, lautet dieser
Vergleichswert (Lichter-ID modulo 255)+1. Die Addition kommt daher, dass die erste
Lichter-ID den Wert Null betrgt, womit bei einem Vegleich ohne Addition am Anfang,
wo der Stencil Buffer wegen dem Clear voller Nullen gefllt ist, der Algorithmus nichts
verbessern wrde.

23
3 Renderingalgorithmen

Nach dem Stencil Pass senden wir die Lichtervolumen wieder an den Shader. Gecullt
werden jetzt die Vorderseiten der Dreiecke, der Stenciltest ist dabei auf " ungleich
Vergleichswert" eingestellt, der Tiefentest bleibt gleich. Bestehen werden den Tiefen-
und Stenciltest in dem Fall nur die Fragmente der Lichtervolumen, die einerseits an der
Maske durchgelassen werden, und gleichzeitig hinter einem Objekt liegen. Dies ist nur
dann der Fall, wenn das Lichtervolumen fr die Kamera sichtbar ist, und ein Objekt im
Lichtervolumen existiert.

Zur Wahl des von ODonnels Algorithmus verschiedenen Vergleichswerts gibt es dabei
folgenden Grund:

Wenn wir versuchen wollen, Artefakte aufgrund von stets vorhandener Werte im Stencil
Buffer zu vermeiden, mssen wir ihn eigentlich nach jedem Fllen dessen leeren, falls
die geschriebenen Werte fr alle Lichter allgemein gelten. ODonnels Algorithmus
zum Beispiel wrde hier den jeweiligen Stencilwert nur erhhen, und diesen mit einer
Konstante - in seinem Fall der Null - vergleichen. Da dieser Vergleichsfall aber fr alle
Lichter gilt, muss nach jedem Licht der Wert im Stencil Buffer berschrieben oder geleert
werden. Bei wenigen Lichtern ist dies kein Problem, wenn aber bei 1024 Lichtern 1024
mal der Stencil Buffer zustzlich geleert werden muss, kann dass zustzliche Laufzeit
kosten (kurze Messungen ergaben in extremen Fllen einen zustzlich lngere Laufzeit
von ca. 5 Millisekunden).

Durch Verbinden des Vergleichswerts mit der Lichter-ID behebt sich aber das Problem:
Bei jedem Licht wird nur nach den Werten gesucht, die zur jeweiligen Licht-ID kor-
respondieren, womit nur bei einem berlauf der Modulofunktion ein zustzlicher
Clear ntig ist - anstelle von 1024 Stencil Buffer Clears brauchen wir somit nur bei 1024
Lichtern nur vier Clears.

3.6.2 Implementation

Implementiert werden Stencil Buffer in OpenGl normalerweise automatisch durch das


Einschalten des Stencil-Testens, solange zu Anfangs ein Display-Modus ausgewhlt
wurde, welcher einen Stencil Buffer ermglicht. Normalerweise erfolgt dies durch
Einfgens des Stencil-Bits namens GLUT_ STENCIL bei der glutInitDisplayMode()-
Funktion - bei OpenGl-Wrappern ist dabei die korrespondierende Funktion zu su-
chen.

Da wir hier allerdings nicht den Default-Framebuffer, sondern wegen des Deferred
Rendering ein eigenes Framebufferobjekt benutzen, muss man selber diesem einen
kombinierten Tiefen-Stencil Buffer bereitstellen, welcher (je nach bentigter Genauig-
keit) 24 oder 32 Bit fr den Tiefenwert und 8 Bit fr den Stencil-Wert als Format betrgt.

24
3 Renderingalgorithmen

Einzustellen ist dies bei der Erstellung des FBO, wobei hier zu beachten ist, dass, im
Gegensatz zu normalen Tiefen- und Stencil-Attachments, man fr eine kombinierte
Textur den fr solche zustndigen Attachment-Punkt angibt, nmlich GL_ DEPTH_
STENCIL_ ATTACHMENT.

Auch zu beachten ist hierbei die Tatsache, dass wir in diesem Algorithmus gleich-
zeitig aus dem Tiefenpuffer lesen und testen wollen. In solchen Fllen knnen, auf-
grund der Funktionsweise der OpenGl-Pipeline, Artefakte beim Lesen der Z-Werte
im Tiefenpuffer entstehen, wenn gleichzeitig Werte aus dem Tiefenpuffer gelesen, wie
auch der Tiefentest durchgefhrt wird. Aus diesem Grund muss alleine bei diesem
Algorithmus eine zustzliche Tiefentextur erstellt werden, die im G-Buffer gefllt
wird.

Abbildung 3.3: Mgliche Artefakte beim Stencil Buffer


Hier sieht man zweimal denselben Algorithmus, einmal mit zwei Tiefentexuren links,
einmal mit nur einer Tiefentextur rechts

Somit knnen wir den Tiefenpuffer fr die bentigten Tiefentests von der fr die Posi-
tionsberechnung der Fragmente bentigten Z-Werte abtrennen. Dies erhht zwar die
bentigte Bandbreite, diese jedoch nur minimal, da nur ein einziger zustzlicher Wert ge-
schrieben werden muss. Eine Color-Attachment-Textur die nur aus GL_ RED Werten be-
steht (d.h. nur eine Zahl) sollte somit ausreichend dafr sein.

Der erste Geometry-Pass beginnt wie der vorherige Deferred Rendering-Algorithmus,


der zweite Pass hingegen muss die einzelnen Einstellungen pro Lichtervolumen-Rendering
verndern, wobei hier selber die Vertices zweimal an zwei verschiedene Shader versen-
det werden - der Erste Shader dient zur Erstellung der Stencil-Maske, der zweite dient
der Beleuchtungsrechnung. Dem oberen Algorithmus folgernd verluft der zweite Pass
wie folgt:

25
3 Renderingalgorithmen

1 glDepthMask ( false ) ; // Tiefe - Werte werden nicht geschrieben


2 glEnable ( GL_STENCIL_TEST ) ; // Stencil - Test wird angeschaltet
3 glDepthFunc ( GL_GEQUAL ) ; // Tiefentest " groesser / gleich "
4 for ( int i = 0; i < Max_Light_Count ; i ++)
5 {
6 if ( i %255 == 0) glClear ( STENCIL_BUFFER_BIT ) ;
7 // Falls die Vergleichswerte einen Umlauf haben , Stencil clearen
8 glColorMask ( false , false , false , false ) ;
9 // Farbwerte werden nicht geschrieben
10 glCullFace ( GL_BACK ) ; // Rueckseiten werden abgeschnitten
11 glStencilOp ( GL_KEEP , GL_KEEP , GL_REPLACE ) ;
12 // Der Wert wird auf ( ID mod 255) +1 gesetzt , falls der Tiefentest
13 // erfolgreich ist
14 glStencilFunc ( GL_ALWAYS ,( i %255) +1 ,0 xFF ) ;
15 // Stencil - Test ist immer erfolgreich , da hier erst die
16 // Stencil - Maske erstellt wird
17 drawStencilPass () ; // " Zeichne " die Lichtsphaere , damit Werte im '
Stencil Buffer gefuellt werden
18 glCullFace ( GL_FRONT ) ; // Vorderseiten werden abgeschnitten
19 glStencilOp ( GL_KEEP , GL_KEEP , GL_KEEP ) ;
20 // Wir wollen nichts schreiben , um Performance zu verbessern
21 glStencilFunc ( GL_NOTEQUAL ,( ID mod 255) +1 ,0 xFF ) ;
22 // Stencil - Test ist nur erfolgreich , falls der Wert ungleich der '
Licht - ID ist
23 glColorMask ( true , true , true , true ) ; // Farbwerte werden geschrieben
24 drawLightvolume () ; // Zeichne das Lichtvolumen mit dem Shader
25 // der die Beleuchtungsrechnung durchfuehrt
26 }

3.6.3 Analyse

Die Laufzeit der Beleuchtungsrechnung sollte sich insofern verbessern, dass nur noch
die Fragmente an den Fragment Shader gesendet werden, auf welche das betrachtende
Licht tatschlich eine Wirkung hat. " In der Luft" hngende Fragmente werde somit
nicht beachtet, da sie den zweiten Tiefentest nicht bestehen. Der Algorithmus sollte
somit in Szenen besser verlaufen, in welchen viele Lichter kaum welche Objekte tref-
fen. Inwiefern aber der Stencilpass an Laufzeit verbraucht im Vergleich zum Gewinn
der verworfenen Fragmente lsst sich aber erst wirklich bei den Benchmarktests her-
ausfinden. Vor allem bei Szenen, wo die Objekte in den meisten Pixel von fast allen
Lichtern getroffen werden, knnte der doppelte Pass der Lichtervolumen aber unntig
sein.

Auch gilt hier, wie bereits zuvor, der zustzliche Overhead zu bedenken: Zwar wrden

26
3 Renderingalgorithmen

weniger Fragmente im Endeffekt zur Beleuchtungsrechnung geschickt werden, die


mehrfach bentigten Zugriffe auf Textur-Informationen bleiben aber vorhanden, da
ein Bildschirmpixel mehrmals von mehreren Lichtern getroffen werden mag, wodurch
auch hier die Textur-Informationen einmal pro Licht ausgelesen werden mssen. Dieses
Problem wurde also mit dem Stencilbuffer nicht behoben.

3.7 Deferred Rendering - Tile Based Culling

3.7.1 Grundidee

Wo wir bislang von Seiten der Lichter an die Optimisierungsmethodiken angegangen


sind, indem wir geschaut haben, welche Pixel im Screen-Space ein Licht trifft um nur
bei diesen die Beleuchtungsrechnung zu aktivieren, kann man die Sache natrlich auch
andersherum angehen. Die Frage ist also, wie schauen wir mglichst effizient nach,
welche Lichter ein Pixel im Screen-Space trifft? Die Idee dazu wurde unter anderem
bei der SIGGRAPH 2010 von Andrew Lauritzen[22] und bei der GDC 2011 als Teil der
hauseigenen Frostbyte-Engine von DICE Rendering Architect Johan Andersson[23]
vorgestellt:

Wenn man annimmt, dass mehrere benachbarte Pixel im Durchschnitt Objekte darstel-
len, die auch in der 3D-Szene nah beieinander liegen, kann man davon asugehen, dass
benachbarte Pixel auch des fteren sich die gleichen Lichter teilen. Diese Annahme
vereinfacht unsere bentigte Berechnung der Zuteilung von Lichtern auf Pixeln auf eine
Zuteilung von Lichtern auf Pixelgruppen, welche wir uns der Einfachheitshalber als
Rechtecke auf dem Bildschirm vorstellen. Der Algorithmus teilt den Bildschirm somit in
eine maximale Anzahl an vorher entschiedene Rechtecke ein, deren Gre fr die best-
mgliche Performance empirisch bestimmt werden muss.

Wenn man nun bestimmen kann, welche Lichter in einem Tile sich befinden, mssen in
der Beleuchtungsrechnung nur noch bestimmte Lichter bei bestimmten Pixelmengen
beachtet werden mssen.

Zustzlich dazu kann man Lichter auch in Z-Richtung abgrenzen, was wir in dieser
Arbeit als Z-Culling bezeichnen werden. Dazu mssen die jeweiligen minimalen und
maximalen Z-Werte eines Tiles durch Vergleiche aller im Z-Buffer liegenden Werte aller
im jeweiligen Tile liegenden Pixel bestimmen. Liegt der Wirkungsradius eines Lichts
nun nicht zwischen dem minimalen Z-Wert und dem maximalen Z-Wert, so liegt auch
dieses Licht auerhalb des Tiles.

27
3 Renderingalgorithmen

Abbildung 3.4: Tile Based Culling


Links das Bild, in der Mitte die Tiles, rechts mit Z-Culling. Helligkeit der Tiles ist
proportional zu Menge der Lichter pro Tile.

Um die im Vergleich zu CPUs hhere Geschwindigkeit von GPUs bei der oberen Be-
rechnung benutzen zu knnen, wird der Algorithmus mit Compute Shadern umgesetzt,
wobei wegen der voneinander unabhngigen Tileberechnung diese parallel ausgefhrt
werden knnen.

Bei dieser Methode ist auch zu bemerken, dass diese mit jeweils abfallender Tilegre
mehrmals hintereinander benutzt werden kann. So kann man kleine Tiles wegen der
greren Abgrenzungen benutzen, ohne dass fr jeden Tile jedes Licht durchgegangen
werden muss, da die vorherigen Unterteilungen die zu betrachtenden Lichter schon
reduziert haben.

3.7.2 Implementation

Benutzt wurden hier in der Arbeit Compute-Shader mit der GLSL-Version 430. Systeme
die dies nicht untersttzen, knnen den Algorithmus also nicht ausfhren.

Je nach Einstellung wird der Compute Shader, der zustndig fr die Einteilung der Lich-
ter ist, nach dem G-Pass ein- oder mehrmals ausgefhrt. Beim mehrmaligen Aufteilen
ist dabei der Vorteil der, dass die kleineren Tiles nur die Lichter betrachten mssen, die
der grere Tile, welcher den kleiner umgibt, beinhaltet.

Deswegen muss darauf geachtet werden, dass die greren Tile-Unterteilungen in Hhe
und/oder Breite ein Vielfaches der kleineren Tiles darstellen sollten, da sonst bei der
Berechnung zu viele Umstnde beachtet werden mssten. Unter Umstnden wrde
ansonsten einer der kleineren Tiles zwei grere Tiles berhren, wodurch dieser die

28
3 Renderingalgorithmen

Lichter-IDs beider greren Tiles berprfen msste, was eventuell zu zustzlichen,


redundanten berprfungen fhren wrde.

Falls das Z-Culling eingeschaltet wird, sollte dies mindestens vor dem letztmaligen
Ausfhren des Einteilungs-Shaders ausgefhrt werden, damit dieser die jeweiligen
Informationen bekommen kann.

Die Daten werden dabei, wie die Lichterinformationen, in einem Shader Storage Buffer
Object (SSBO) gespeichert, welcher jedem Shader zugnglich ist. Um den Zugriff auf
die Lichter-IDs zu optimieren wurde die Datenstruktur an die von Ola Olsson und Ulf
Assarsson vorgeschlagenen angelehnt[24]:

Benutzt werden insgesamt mindestens 3 SSBOs, bei mehreren Unterteilungen des Bild-
schirms knnen der Einfachheit halber weitere benutzt werden. Ein SSBO ist der schon
vorhin erwhnte Lichter-SSBO mit den Lichterinformationen, das zweite beinhaltet
die Lichter-Indizes pro Tile, und das dritte speichert Offset und Anzahl der Lichter
pro Tile, die fr das Auslesen des zweiten SSBO wichtig sind. ber diese Anordnung
mssen dann die SSBO auch gar nicht geleert werden - bei jedem Durchgang des Al-
gorithmus wird automatisch gespeichert, welche IDs aus dem zweiten SSBO gelesen
werden mssen.

Falls Z-Culling benutzt werden mchte, wird ein weiteres SSBO gebraucht, welches
jeweils zwei Floats pro Tile speichert, einmal den minimalen und einmal den maximalen
Z-Wert.

Die Shader werden dabei beide parallelisiert ausgefhrt, der Einteilungs-Shader teilt die
durchgegangen Lichter in mehrere Threads auf (z.b. bei 1024 Lichtern jeweils 4 Lichter
pro Thread bei 256 parallelen Threads bearbeiten), whrend der min/max-Z-Shader die
Tiefenwerte der Pixel pro Tile parallelisiert bearbeitet.

Das eigentliche Berechnen wird wie folgt durchgefhrt:

Einteilung des Bildschirms:

Ob ein Licht innerhalb eines Tiles liegt oder nicht, kann man durch Ebenengleichun-
gen berechnen. Dazu gibt es viele verschiedene Mglichkeiten dies umzusetzen; hier hat
man sich einfach an Jason Stewarts Tiled Lighting 11 Demo von AMD orientiert[25].

Bei jedem Tile sind dessen jeweiligen Eckpunkte immer bekannt. Berechnet man diese
in World-View-Koordinaten um, knnen mit der Hesseschen Normalform vier ver-
schiedene Ebenengleichungen bestimmt werden, ber welche man jeweils den Abstand
zwischen Ebene und Lichtposition berechnen kann. Ist der Abstand kleiner als der
Radius, trifft das Licht den Tile.

29
3 Renderingalgorithmen

Bestimmung der minimalen und maximalen Z-Werte:

Der Compute-Shader wird in diesem Fall einmal pro Tile ausgefhrt, wobei jeder Pixel
der Tiefentextur parallel bearbeitet wird. Die Anzahl an parallelen Threads ist dabei
von der GPU eingeschrnkt, wodurch grere Tiles die Paralellisierbarkeit meistens
nicht beansprechen knnen.

Im Shaderprogramm werden dabei zwei Variablen fr die maximalen und minimalen


Z-Werte fr alle Asufhrungen ffentlich gemacht, sodass alle auf diesen Zugriff haben
und diese manipulieren knnen. In jedem Thread wird dabei der gelesene Z-Wert des
Pixels unter GLSL ber atomicMin() und atomicMax() mit den verteilten Variablen ver-
glichen und je nachdem, ob der neue Wert kleiner oder grer ist, gesetzt. Zu beachten
ist, dass ein barrier() nach Benutzen der atomaren Funktionen gesetzt werden sollte,
um keine asynchronen Ergebnisse am Ende zu erhalten.

Nachdem beide Berechnungen durchgefhrt, wie auch die SSBOs mit den bentigten
Daten vollgeschrieben wurden, kann die Beleuchtungsrechnung wie beim Deferred
Rendering Algorithmus ohne Culling ber einen Bildschirm-Quad erfolgen. Jeder Bild-
schirmpixel wird also einmal durchgegangen, die jeweiligen Daten aus dem G-Buffer
rausgelesen und die Lichter-IDs bei der Beleuchtung durchgegangen. Den jeweiligen
Tile und die damit verbundenen Informationen in den SSBOs lassen sich dabei einfach
aus der Fragment-Koordinate im Fragment Shader berechnen, da die Tile- und Bild-
schirmgre bekannt ist.

Betreffend der Unterteilungseinstellungen, die bei den spteren Benchmarktest benutzt


wurden, hat man sich dafr entschieden, eine zweifache Unterteilung des Bildschirms
durchzufhren. Da es eine unendlich groe Anzahl an Mglichkeiten gibt, den Bild-
schirm in Rechtecke zu unterteilen - vor allem wenn man dies mehrmals machen mchte
- wurde aus diesem Grund ein kurzer Testlauf gestartet, um empirisch zu bestimmen,
welche Anzahl an Unterteilungen in welcher Gre der Tiles bei der in dieser Arbeit
benutzten Bildschirmgre - nmlich 1600 Pixel breit, 900 Pixel hoch - von den be-
trachteten Unterteilungsfolgen die beste Performance erbrachte. Die dazu gehrigen
kurzen Testlufe knnen im Anhang A nachgeschaut werden; hier sei einfach dazu
erwhnt, dass der Bildschirm zuerst in 320 x 150, danach in 20 x 25 groe Tiles einge-
teilt wurde. Falls ein Z-Culling stattfand, wurde es bei der letzten Unterteilungsgre
durchgefhrt.

30
3 Renderingalgorithmen

3.7.3 Analyse

Die Performance hierbei sollte im Vergleich zu allen anderen Algorithmen von der
eigentlichen Beleuchtungsrechnung ausgehend am optimalsten erfolgen, da hier jeder
Pixel nur geringfgig zustzliche Lichter durchgeht als ntig sein sollte. Das grere Pro-
blem bei dieser Methode ist aber eigentlich das Einteilen des Bildschirms, wie auch die
Berechnung der minimalen/maximalen Z-Werte pro Tile.

Diese sollten im besten Fall sehr viele Lichter abgrenzen lassen, im Falle von Lichtern,
die aber alle den gesamten Bildschirm verdecken, werden unzhlige Berechnungszyklen
fr den gesamten Algorithmus verbraucht, der im Endeffekt kaum an der Beleuchtungs-
rechnung spart.

Auch ist aber die Performance vor allem von der Tilegre abhngig. Bei zu groen
Tiles werden kaum Lichter abgegrenzt und zu viele Z-Werte fr das dadurch viel lang-
samere Z-Culling betrachtet, um ein gutes Abgrenzungsergebnis zu prsentieren. Sind
die Tiles zu klein, funktioniert zwar das Z-Culling sehr schnell, die Einteilung und
Bearbeitung der Tiles kann aber dafr eventuell lnger dauern als die Beleuchtungsrech-
nung selber, vor allem weil auch die Einteilung zustzlich mit der Anzahl der Lichter
skaliert.

Somit empfiehlt es sich bei der Benutzung kleiner Tiles den Bildschirm zuerst mit einer
etwas greren Tilegre Aufzuteilen, bevor die kleineren Tiles berechnet werden,
wobei auch hier darauf geachtet werden sollte, dass diese aufeinanderfolgende Untertei-
lung des Bildschirms nicht zu oft passiert, sodass wieder mehr Zeit bei der Unterteilung
als bei der Beleuchtungsrechnung verbraucht wird.

Aus den vorherigen Gedankengngen sollte sich also das Bild eines Algorithmus ge-
zeichnet haben, welcher noch hardwareabhngiger ist als das Deferred Rendering. Die
Parallelisierungsmglichkeiten, und vor allem die Benutzung von Compute-Shadern
selber setzen gengend moderne Grafikkartenleistung voraus, welche aber, falls vorhan-
den, das Lichterproblem sehr effizient und elegant lsen sollte.

31
3 Renderingalgorithmen

3.8 Forward Rendering - Tile Based Culling

Bei der vorhin vorgestellten Implementation des Deferred Tile Based Culling ist das
Vorteilhafte an dieser, dass der obere Algorithmus das Deferred Rendering selber
gar nicht voraussetzt, weswegen wir das Tile Based Culling auch in eine Forward-
Rendering-Pipeline benutzen knnen. In hnlicher Form hatte dies auch AMD 2012
beim Release derer AMD Radeon HD 7900 GPU mit der Grafikdemo namens Leo
vorgestellt, wessen Algorithmus auch auf einem Forward Renderer mit Tile Based
Culling basierte[26].

Anstelle des Bildschirm-Quads, welcher bei jedem Pixel die berechneten Lichter-IDs
aus den SSBOs rausliest, kann man auch die Fragment-Koordinaten der an die Gra-
fikpipeline versendeten Objekte benutzen. Somit beachtet jedes versendete Fragment
nur die jeweiligen Lichter, die im vorherigen Algorithmus in dessen Bildschirm-Tile
bestimmt wurden.

3.8.1 Implementation

Die Implementation ist daher nicht viel verschieden vom vorherigen Abschnitt. Die
Einteilung des Bildschirms in Tiles erfolgt genauso wie vorhin, einziger Unterschied
ist dabei das Culling in Z-Richtung, da dieses beim Forward Rendering nicht ohne
weiteres mglich ist. Da wir keine Tiefentextur im Normalfall haben, kann das Z-Culling
natrlich ohne einen vorherigen Tiefenpass nicht erfolgen.

Auf der anderen Seite ist sich deswegen die berlegung wert, einen Tiefenpass dennoch
ausfhren zu lassen, wenn man bedenkt, dass man das Tile Based Culling somit vor al-
lem in Verbindung mit dem Early-Z-Algorithmus benutzen kann.

Aus diesem Grund sollte die Grafikpipeline wie folgt aussehen:

Zuerst sollte, falls Z-Culling benutzt werden mchte, der Tiefenpass erfolgen. Nach dem
Tiefenpass lsst man beide Compute-Shader nacheinander ablaufen - den ersten, wel-
cher die minimalen/maximalen Z-Werte berechnet falls Z-Culling aktiviert wurde, so-
wie den zweiten, welcher den Bildschirm (eventuell mehrmals) aufteilt.

Erst nach dieser gesamten Vorbereitung sollte das eigentliche Versenden der Vertices an
das Shader-Programm erfolgen, welches die Beleuchtungsrechnung inne trgt.

32
3 Renderingalgorithmen

3.8.2 Analyse

Die somit vereinfachte Beleuchtungsrechnung sollte vor allem in Vergleich mit dem
normalen Forward Rendering bei einer greren Anzahl von Lichtern die Performance
um einen groen Teil verbessern. Der Vergleich zum Deferred Renderer sollte aber
immer noch anstehen, da auch hier der Forward Renderer pro verschicktes Fragment die
Beleuchtung berechnet, weswegen die Anzahl an Berechnungen, welche beim Deferred
Renderer durch die Bildschirmgre eingeschrnkt wird, immer noch die Performance
abhngig von der Szenen- und Objektkomplexitt macht.

Diese Implementation des Tiled Based Culling Algorithmus ist vor allem deshalb rele-
vant, weil insbesondere bei dessen Vergleich mit der Deferred Rendering-Variante einzig
und allein die Renderingmethode variiert, weswegen es einfacher sein sollte zu erken-
nen, inwiefern ein Wechsel zu Deferred Rendering nun tatschlich gewinnbringend sein
mag. Sonst gelten hier aber die gleichen Nachteile wie bei der Deferred-Variante des Tile
Based Culling, vor allem die verbrauchte Zeit fr das zuerst zu berechnende Tile-Gitter
knnte bei geringer Anzahl an Lichtern ein zu groes Overhead erbringen. Auch nicht
zu vergessen seien die bei wenigen Lichtern unntigen Hardwarevoraussetzungen
einer gengend modernen Grafikkarte, wenn in solchen Fllen kaum ein Unterschied
zu den anderen Algorithmen gemacht werden sollte.

33
4 Benchmarktest

4.1 Implementation

Das Programm zur Ausfhrung der Benchmarktests wurde eigenstndig fr die Arbeit
konzipiert. Benutzt wird, da mit LWJGL und Java gearbeitet wird, die Java-Swing-
Umgebung fr die GUI-Programmierung. Die Grafikpipeline wird parallel zur Gui in
einem eigenen Thread ausgefhrt, whrend die Messwerte der Millisekunden pro Fra-
me direkt von OpenGl ber interne Funktionen, sogenannter Queries abgefragt werden.
Wichtig hierbei ist, dass, aufgrund der mglichen Wartezeiten bei der Abfrage der Gra-
fikkarte nach vergangener Zeit, diese in einem Doppel-Buffer-Verfahren durchgefhrt
wird, dessen Implementation von Lighthouse3D empfohlen wird [27]:

Es werden zwei Buffer fr die Abfrage der vergangenen Zeit benutzt, bei welchen diese
immer abwechselnd geschaltet und bearbeitet werden. Am Ende jedes Frames wird
eine Abfrage nach der Zeit gestartet, wobei diese Abfrage noch nicht ausgelesen wird.
Falls man dies nmlich tut, wrde in einigen Fllen die Grafikkarte erst darauf warten,
die gesuchten Werte zurckzugeben, bevor diese weiter arbeiten wrde, was somit die
gemessene Zeit pro Frame manipulieren knnte. Wenn man aber das Auslesen dieser
Werte erst im nchsten Frame durchfhrt, gibt es eine sehr hohe Wahrscheinlichkeit,
dass die Werte bereits im Buffer stehen. Somit wird die Grafikkarte beim Bearbeiten der
Grafik-Pipeline nur minimal gestrt, weswegen die ermessenen Werten nher an der
Realitt sind.

Betreffend der Testfahrten, werden die gemessenen Werte dieser pro Frame in einer Liste
hinzugefgt, ber welcher dann der Mittelwert berechnet wird, der fr die Vergleiche
benutzt wird.

Folgendes Testsystem wurde dabei bei der gesamten Arbeit benutzt:

CPU i5-3750k @ 3.4 GHz


GPU Nvidia Geforce GTX 660 Ti @ 967 MHz, 4GB RAM
Arbeitsspeicher 8 GB RAM
Betriebssystem Windows 7 64-Bit

34
4 Benchmarktest

Die fr die Benchmarktests benutzten Kamerafahrten folgen verschiedenen, vorab


gesetzten Positionen in den 3D-Szenen, dessen genauer Verlauf vor dem Start ber
Bzierkurven-Bildung berechnet wurden. Jeglicher Input ber Mausbewegung oder
Tastatursteurung wird dabei whrend der Fahrt vollstens ignoriert, um die gleichen
Gegebenheiten bei jeder Testfahrt beizubehalten.

Blickrichtung der Kamera wird dabei vor der Testfahrt ausgewhlt - mgliche Alternati-
ven sind Blickrichtung in Fahrtrichtung, auf eine ausgewhlte Position in der 3D-Szene,
oder statisch in eine von Anfang an bestimmte Richtung.

Als Szenenobjekte werden in den ersten drei Testfllen Sphren benutzt - Anzahl der
Vertices liegt bei 642, Gre dieser liegt bei einem Radius von 20 Einheiten - da die
Erstellung solcher Primitiven einfach ist, whrend gleichzeitig die Oberflcheneigen-
schaften der einzelnen Vertices gengend voneinander variieren. Damit ist eine einfache
berprfung der korrekten Lichtberechnung auch per Auge alleine schnell durchzu-
fhren. Dies ist insofern relevant, da eventuell Artefakte aufgrund von zu geringer
Bit-Gre der gewhlten Texturen beim Deferred-Rendering auftreten knnen - somit
kann man dieses Problem einfach berprfen.

Des Weiteren kann so aber auch deutlich gezeigt werden, dass bei den gespeicherten
Informationen - zum Beispiel die unterschiedlich liegenden Normalen bei der Sphre -
beim Endergebnis des Bildes generell keine Unterschiede zwischen Forward und Defer-
red Rendering vorliegen, falls die Bit-Gre der benutzten Texturen gengend gro ist.
Auch werden aus diesem Grund Normalmaps implementiert, nur um darzustellen, dass
solche Techniken bei beiden Rendering-Methoden gleichwertig und genauso benutzbar
sind.

Der G-Buffer beim Deferred Renderer besteht, wie oben bereits erwhnt, normalerweise
aus vier Texturen:

einer Diffuse Farb-Textur

einer Normalen-Textur

einer kombinierte Tiefen-/Stenciltextur

einer Materialinformationen-Textur mit Shininess-, Lichtemittierungs- und Specular-


Faktor

Beim Stencil Buffer-Algorithmus kommt noch eine weitere Tiefentextur dazu, die nur
eine Zahl pro Pixel speichert.

35
4 Benchmarktest

Die Normalmap-Berechnung wird dabei vor dem G-Bufferpass erledigt. Dies ist nicht
unbedingt ntig, beim kurzen Testen hat sich aber gezeigt, dass die Performance des
verspteten Berechnens aufgrund der bentigten zustzlichen Informationen in der
Laufzeit geringfgig langsamer wahr. Dies ist daran zu erklren, dass diese Informatio-
nen - gemeint sind damit Texturkoordinaten und Tangenten der Fragmente - zustzliche
Texturen im G-Buffer bentigen, wobei vor allem die Texturkoordinaten eine erhhte
Genauigkeit und somit greren Speicherplatz gebrauchen. Da die Laufzeit wiederum
von der Bandbreite der Grafikkarte abhngig ist, und diese von den zustzlich zu be-
arbeitenden Texturen weiterhin belastet wird, wurde auf diese Implementationsweise
verzichtet.

Bei komplizierteren Pipelines, welche weitere Berechnungen auf diesen Informationen


aufbauen knnten, wre die versptete Berechnung sogar sinnvoll, da diese genau
wie die Beleuchtungsrechnung dadurch vereinfacht werden knnten. Weil wir aber
die Performance der beiden Rendering-Techniken im Allgemeinen vergleichen wollen,
und wir somit keine weiteren Effekte einbauen, wird diese versptete Berechnung der
Normalmaps hier nicht in der Arbeit umgesetzt. So werden die Normalmaps aber auch
beim Performance-Vergleich keinen Unterschied zwischen beiden Rendertechniken
erzeugen, da die Berechnung bei allen Algorithmen genau gleich erfolgt.

Zu den Algorithmen selber sei noch zu bemerken, dass bei den Tile-Based-Algorithmen
diese jeweils einmal ohne Z-Culling und einmal mit ausgefhrt werden, wobei bei der
Forward-Variante dazu auch noch das Early-Z-Verfahren mit de-/aktiviert wird. An-
sonsten werden alle Algorithmen den jeweiligen Testfall durchlaufen, dessen Ergebnis
dann hier aufgetragen wird.

4.2 Testflle

Bevor wir zu den eigentlichen Tests kommen, sollten vor allem die Benutzung der in
Krze dargestellten Szenentestflle begrndet und mit den Vor- und Nachteilen der
Algorithmen in Verbindung gebracht werden. Dazu werden genau diese zuerst noch
einmal verkrzt nacheinander aufgezhlt:

Forward Rendering:

Generelle Nachteile bei allen Forward Rendering-Algorithmen sind vor allem die
von der Szenenkomplexitt abhngige Beleuchtungsrechnung, welche mit der An-
zahl an verschickten Fragmenten stark skaliert. Aus diesem Grund werden einige

36
4 Benchmarktest

der Testflle mehrmals ber eine verschiedene Anzahl an Szenenobjekten verlau-


fen.

Zustzlich zum oberen Problem kommt beim Per-Fragment Shader vor allem die Tatsa-
che der Beleuchtungsrechnung bei verdeckten Fragmenten hinzu, welches der Early-Z-
Algorithmus zu lsen versucht. Daher brauchen wir Testflle, die jeweils die Anzahl an
verdeckten Objekten variiert.

Vor allem aber brauchen wir den Vergleich zwischen Forward und Deferred Rendering
in Abhngigkeit mit der Lichteranzahl. Deswegen werden bei den meisten Testfllen
diese ber mehrere Versuche verndert.

Deferred Rendering:

Bei den Deferred Rendering-Algorithmen ist die Bildschirmgre und die Position wie
auch der Radius der Lichter fr die Performance wichtig - vor allem das Tile Based
Culling welches bei beiden Renderingalgorithmen benutzt wird ist stark vom Radius
der Lichter abhngig. Auch ist die Anzahl an verdeckten Lichtern durch Objekte wie
auch Lichter die kaum Objekte treffen interressant fr den Auswirkungen des Stencil
Buffers auf den Lightvolume-based Culling Algorithmus. Zu guter Letzt mag vor allem
der Vergleich bei vielen Objekten generell zum Forward Rendering ntzlich sein, da das
Deferred Rendering vor allem die Szenenkomplexitt fr die Beleuchtungsrechnung
irrelevant macht.

Es werden daher mehrere Szenen fr die Tests benutzt, bei welchen:

Die Anzahl der Lichter, die den gesamten Bildschirm einnehmen, variiert werden
(Vergleich zwischen aller Deferred Algorithmen mit den Forward Algorithmen)

Die Anzahl der Objekte, und somit auch verdeckte Objekte und Lichter, variiert
wird (Vergleich zwischen Early-Z Algorithmen und Deferred Rendering, Vergleich
zwischen Lighvolume Based mit und ohne Stencil Buffer)

Die Radien der Lichter verndert werden (Vergleich der Effizienz der Lichtabgren-
zungsalgorithmen)

Auf den Eigenschaften der Algorithmen aufbauend wurden daher folgende Testszenen
und -flle ausgewhlt:

37
4 Benchmarktest

Kleiner Raum mit Objekten und Lichtern nah beieinander:

Abbildung 4.1: Testszene - Box

In der relativ kleinen Box sind die Lichter alle nah beisammen und sollten somit des
fteren einen groen Teil des Bildschirmes verdecken. Die Kamerafahrt erfolgt um die
Box herum, welche gleichzeitig die Szenenobjekte inne hlt. Der Aufbau der Positionen
der Sphren, sowie der Lichter, ist kubisch. Die Abstnde sind dabei nicht alle uniform -
in vertikaler Richtung sind die Abstnde geringer als in horizontaler Richtung damit
mehr Objekte gleichzeitig auf den Bildschirm passen.

Die Blickrichtung der Kamera bleibt dabei andauernd auf den Mittelpunkt der Box
zentriert, sodass alle Sphren und Lichter grtenteils immer auf dem Bildschirm zu
sehen sind.

Getestet werden hier die Effizienz der Lichtabgrenzungsmethoden bei grter An-
sammlung an Lichtern auf dem Bildschirm (in diesem Fall dessen Worst-Case), wie
auch die Performanz von der Verdeckungsproblem lsenden Eigenschaften aller De-
ferred Rendering Methoden im Vergleich zu den benutzten Early-Z-Verfahren bei den
Forward Rendering-Varianten. Da die meisten Objekte gleichzeitig zu sehen sind, wer-
den diese auch nicht von der Grafikkarte selber automatisch abegrenzt, weswegen
die Objektanzahl vor allem beim Forward Rendering einen Nachteil bringen mss-
ten.

38
4 Benchmarktest

Groer Raum mit Objekten und Lichtern gleichmig verteilt -


Sicht von der Seite:

Abbildung 4.2: Testszene - Flche - Sicht von der Seite

Auf der groen Flche innerhalb der zweiten Testszene werden alle Sphren in gewissen
Abstnden aneinandergereiht. Wichtige Eigenschaften dieser Testszene zeigen sich in
der erhhten Anzahl an verdeckten Fragmente aus der Sicht der Kamerafahrt, die
lngs an den Sphrenreihen vorbeifhrt - die Blickrichtung bleibt dabei konstant in eine
Richtung gesetzt, sodass die grte Anzahl an mglichen Sphren sich verdecken. Die
Lichter sind dabei genauso wie die Sphren ber die Flche verteilt, weswegen hier die
Lichtabgrenzungsalgorithmen stark vorteilhaft gegenber den Algorithmen sein sollten,
die die Positionen und Radien der Lichter nicht beachten.

Nicht zu vergessen ist auerdem die Tatsache, dass, whrend beim Box-Test alle Objekte
und Lichter gleichzeitig im Bild vorhanden sind(wenn auch teilweise verdeckt), wir
in dieser Testszene grtenteils nur immer einen Teilausschnitt der gesamten Szene
sehen. Dies ist vor allem bei den Forward Rendering Techniken relevant, da Objekte,
die auerhalb der Kameraansicht liegen, grtenteils optimiert von der Grafikkarte
eigentstndig abgegrenzt werden.

Somit werden hier die Verdeckungsproblem lsenden Verfahren in Verbindung mit


den Lichtabgrenzungsmethoden verglichen, wobei Letzteres im Vergleich zum ersten
Testfall viel effektiver funktionieren mssten.

39
4 Benchmarktest

Groer Raum mit Objekten und Lichtern gleichmig verteilt -


Sicht von oben:

Abbildung 4.3: Testszene - Flche - Sicht von oben

Beim dritten Testfall bleiben die Positionen der Lichter und Objekte dieselben wie
beim zweiten, es wird lediglich die Kamerafahrt wie auch dessen Blickwinkel gen-
dert. Dies ist insofern relevant, da bei der neuen Betrachtungsweise der Szene vor
allem kaum Objekte verdeckt werden, was die Verdeckungsproblem lsenden Algo-
rithmen unntig machen sollte, weswegen somit deren Overhead gemessen werden
kann. Damit sollte klar werden, inwiefern diese Algorithmen dennoch nutzbar sein kn-
nen, auch wenn sie kaum einen Unterschied in der Anzahl an verworfener Fragmente
machen.

Der dritte Testfall sollte somit zusammen mit dem zweiten Testfall in Verbindung
gebracht werden, weil bei einem Vergleich zwischen beiden Renderingverfahren ab-
gewogen werden muss, ob das Lsen des Verdeckungsproblem ber das Deferred
Rendering nicht auch ber ein einfaches Early-Z Verfahren letztendlich ersetzt werden
kann.

Bei all diesen drei Testfllen werden die Anzahl an Lichtern, deren Radius, wie auch die
Anzahl der Objekte verndert, um die jeweiligen Auswirkungen dieser Einstellungen
vergleichen zu knnen.

40
4 Benchmarktest

Crytek Sponza - Average Case:

Abbildung 4.4: Testszene - Sponza

Der letzte Testfall soll den sogenannten Average Case bilden. Wir werden also bei
einer bei 3D-Benchmarks des fteren benutzten Testszene - in diesem Fall die Crytek
Sponza[28] - die Performance aller Algorithmen vergleichen. Die Position und Lichtra-
diengre werden zufllig innerhalb der Sponza gewhlt - bei den Lichtern wird fr
jedes Licht ein zufllige Radius zwischen 100 und 800 Einheiten gewhlt. Es werden
dazu einmal genau 100, ein weiteres mal genau 200 Lichter benutzt, wobei bis auf die
Sponza selber keine weiteren Objekte vorhanden sein werden. Die Kamerafahrt selber
wird durch die gesamte Sponza hindurchgehen.

Die Wahl der 3D-Szene und Einstellungen der Lichtparameter sollte dabei den hypo-
thetischen Average Case in 3D-Anwendungen approximativ entsprechen, bei denen
ein Deferred Rendering in Erwgung gezogen werden knnte. Es existieren viele Ver-
deckungen aufgrund der Wnde, Gardinen und Sulen, whrend die Lichteranzahl
gengend hoch fr die Relevanz von Deferred Rendering Methoden gesetzt wurde,
ohne wiederum zu viele Lichter auszuwhlen, da bei allgemeinen 3D-Anwendungen
in den meisten Fllen Lichter im hheren drei- bis vierstelligen Bereich kaum auftre-
ten. Whrend die ersten drei Testflle also die Performanz der verschiedenen Problem
lsenden Algorithmen in besonders extremen Fllen vergleichen, ist der letzte Test-
fall hauptschlich fr unsere Hauptthese, inwiefern ein Umstieg auf das Deferred
Rendering Sinn macht, fr den allgemeinen Fall wichtig.

41
5 Messwerte und Auswertung der
Benchmarktests

Die gemessenen Durchschnittswerte wurden alle jeweils im Datenanalyseprogramm


Origin der Version 9.1 von OriginLab eingetragen und als Graphen exportiert. Die
genauen Daten werden zustzlich zu den Graphen im Flietext hinten im Anhang B
vorzufinden sein.

Insgesamt werden zuerst jeweils alle Messungen, die resultierenden Graphen, sowie de-
ren objektive Betrachtung mit einer kurzen Analyse aufgefhrt - deren Gesamtinterpre-
tation erfolgt dabei je nach allen Messungen eines Testfalls.

Es erfolgen dabei bei den ersten drei Testszenen jeweils drei Messungen, die allesamt
die Zeit pro Frame in Abhngigkeit von:

der Anzahl der Lichter bei konstant gehaltener Anzahl an Objekten und Gre
des Lichtradius

der Anzahl der Objekte bei konstant gehaltener Anzahl an Lichter und Gre des
Lichtradius

der Gre des Lichtradius bei konstant gehaltener Anzahl an Lichtern und Objek-
ten

messen.

Zu bemerken sei hier auerdem, dass die Einheit der Radien relativ zur gesamten Welt
sind. Zum Vergleich: alle Sphren haben einen Radius von 20 Einheiten. Ein Lichtervolu-
men mit dem Radius 200 ist also in der Lnge 10 Sphren lang.

42
5 Messwerte und Auswertung der Benchmarktests

5.1 Testszene: Box

5.1.1 Erwartungen

Da in diesem kleinem Raum alle Lichter und Objekte gleichzeitig auf dem Bildschirm
sichtbar sind, sollten beim Messen der Laufzeiten in Abhngigkeit von der Anzahl der
Lichter und Objekte die Deferred Rendering Algorithmen alle eine bessere, eventuell
sogar eine konstantere Performance abliefern als die Forward Rendering-Gegenstcke
zu ihnen. Aufgrund der groen Anzahl an verdeckten Fragmenten mssten somit auch
nicht nur diese, sondern auch im direkten Vergleich das Early-Z-Verfahren einiges an
verbesserten Laufzeiten bei den Forward Rendering Methoden zeigen.

Das Stencil Buffer Verfahren hingegen msste im Gegensatz zum Lightvolume Based
Culling ohne dessen Hilfe kaum einen Unterschied bringen, da die groe Anzahl der
Objekte die sehr viele der Lichter berhren kaum Platz fr zustzlich verworfene
Fragmente lassen - das Stencil Buffer Verfahren hilft nmlich vor allem bei Lichtern, die,
relativ zu ihrer Gre, kaum Objekte treffen.

Wegen der hier sehr oft an vielen Stellen berlappenden Lichtern im Screen-Space
wird auch angenommen, dass vor allem alle Lichtabgrenzungsmethoden Probleme
aufweisen werden, weswegen der Fall hier als Worst-Case fr diese gelten sollte - vor
allem in Abhngigkeit mit der Messung fr Radiengren.

Fraglich ist auch, ab welcher Lichteranzahl die komplexeren Varianten es wert sind
ausgefhrt zu werden, weswegen auch darauf in den Messungen kurz eingegangen
wird.

43
5 Messwerte und Auswertung der Benchmarktests

5.1.2 Messergebnisse und deren Auswertung

Abbildung 5.1: Box: Lichttest

Wie man sehen kann, haben alle Deferred-Rendering-Techniken vor allem bei der
greren Anzahl an Lichtern einen erheblich bessere Performance. Wie erwartet brachte
die Stencil Buffer Methode zu anfangs kaum einen Unterschied zu der Laufzeit der
Lightvolume-Based Deferred-Rendering-Methoden. Bei greren Zahlen erhhte sich
dessen Effizienz, mehr als eine Verbesserung von maximal 5 Millisekunden fand aber
nicht statt.

Whrend vor allem bei den Forward-Rendering-Methoden der frhzeitige Tiefenpass


des Early-Z-Algorithmus bei beiden Implementationen - mit und ohne Tiled Based
Culling - einen erheblichen Gewinn erbrachten, haben die Z-Culling Methoden nur
einen vergleichbar geringen Unterschied bei der Deferred-Variante des Tiled Based
Cullings gebracht. Bei der Forward-Variante hingegen gab es im hheren Zahlenbereich
Verbesserungen durch Benutzung dieser Methodik im Bereich von 5-7 Millisekun-
den.

Auch zu Erkennen ist die in den vorherigen Abschnitten erwhnte konstante Skalierung
der Laufzeit in Abhngigkeit von der Lichteranzahl bei den simpleren Forward und
Deferred Rendering-Algorithmen. berraschenderweise sind, trotz eines vorhandenen
Worst-Cases, alle Lichtabgrenzungsalgorithmen hchst effizient - auch bei sehr vielen

44
5 Messwerte und Auswertung der Benchmarktests

Lichtern. Wohlmglich wird sich dies aber spter bei den Messungen mit den greren
Radien ndern.

Um herauszufinden, ab wann der Umstieg von Forward auf Deferred in diesem Testfall
zu bevorzugen ist, dient dazu das folgende Bild, welches eine Vergrerung des ersten
Graphen darstellen soll.

Abbildung 5.2: Box: Lichttest vergrert

Zu beachten ist hier, dass bei so vielen an einem Platz versammelten Objekten erst
ab ungefhr 35 Lichtern die simpleren Deferred-Varianten - vor allem im Vergleich
zu den genauso einfach gestrickten Forward-Methoden - zu empfehlen sind. Gene-
rell sind vor allem im [0,30]-Intervall die Benutzung der komplexeren Algorithmen
unntig, danach aber dominiert vor allem die Deferred-Variante des Tile Based Cul-
ling, mit und ohne Z-Culling. Die Differenz in der Laufzeit bei der maximalen Anzahl
an Lichtern zwischen des performantesten Deferred Rendering(Tiled Based Culling
mit Z-Culling) und Forward Rendering Algorithmus(Tiled Based Culling mit Early-
Z und Z-Culling) betrgt um die 31 Millisekunden - ein sehr gravierender Unter-
schied.

45
5 Messwerte und Auswertung der Benchmarktests

Abbildung 5.3: Box: Objekttest

Verglichen mit unseren Messungen der Abhngigkeit von der Objektanzahl treffen
unsere Erwartungen grtenteils zu. Alle Deferred Rendering Algorithmen behalten
ein konstante Laufzeit, da sie unabhngig von der Anzahl der hier vorzufindenden
Objekte sind. Wie zuvor verhalfen die Early-Z-Verfahren hier zu verbesserten Laufzeiten,
whrend im Gegensatz dazu die Z-Culling-Verfahren bei den Tiled Based Culling
Methoden nur bei wenigen Objekten ihre hchste Effektivitt vorfanden. Dies ist vor
allem durch das Vorkommen hnlicher Tiefenwerte im Tiefenpuffer erklrbar, die bei
wenigen Objekten auftaucht: Falls bis auf die Wnde keine Objekte existieren, haben die
meisten benachbarten Pixel die Tiefenwerte der Wnde, womit die zu vergleichenden
Ebenen bei der Lichtabgrenzung dicht beieinander liegen - dies fhrt zu einer hheren
Anzahl an abgegrenzten Lichtern.

Gleiches gilt auch beim Stencil Buffer Verfahren. Wie erwartet, hatten bei die Lichter
weniger Objekten im Raum weniger Fragmente, die sie getroffen haben, womit das
normale Lightvolume Based Culling zustzliche Berechnungszyklen verbraucht, welche
das Stencil Buffer Verfahren einspart.

Bei der radienabhngigen Messungsreihe finden sich vor allem bei kleineren Radien
unseren Erwartungen entsprechend die meisten Lichtabgrenzungsmethoden im unte-
ren Bereich der Laufzeiten. berraschenderweise ist die Skalierung bei der Forward-
Variante des Tile Based Culling so stark, dass die Laufzeiten bei hheren Radien sogar
mehr als das 4-fache des Screen-Space Shading betrgt.

46
5 Messwerte und Auswertung der Benchmarktests

Abbildung 5.4: Box: Radiustest

Generell zeigen sich aber wie bei einem Worst-Case erwartet sehr groe Steigungen
bei allen Lichtabgrenzungsverfahren, whrend die simpleren Verfahren alle weniger
abhngig von der Radiengre waren - vor allem bei der fast dauerhaft konstanten
Performance des Screen-Space Shading.

Letztendlich sollte noch der Einfluss des Stencil Buffers berprft werden. Anschei-
nend waren die getroffenen Vermutungen richtig - die vielen Objekte die mehrfach
von verschiedenen Lichtervolumen getroffen werden ergaben somit keine gengend
hohe Anzahl an verworfenen Fragmente bei der Beleuchtungsrechnung um den Un-
terschied in der Performanz relativ gro aussehen zu lassen, auch wenn die Stencil
Buffer Methode dennoch sich ab ca 130 Radieneinheiten positiv auswirkt - eine Ver-
besserung von bis zu ca. 3- 5 Millisekunden ist vor allem bei greren Radien ersicht-
lich.

47
5 Messwerte und Auswertung der Benchmarktests

5.1.3 Fazit des ersten Testfalls

Betreffend des angeblichen Worst-Cases hat sich gezeigt, dass fast alle Lichtabgren-
zungsmethoden nur Laufzeitverbesserungen erbrachten. Alleine bei greren Radien
sollte abhngig von der Gre und Anzahl der Lichter entschieden werden, ob diese
nun benutzt werden sollten oder nicht.

Abgesehen davon, waren in fast allen Fllen die Deferred Rendering Methoden den For-
ward Rendering Methoden um einiges berlegen. Auch wenn bei wenigen Lichtern die
einfache Implementation der Per-Fragment Berechnung oder dessen Early-Z-Variante
schneller als alle Alternativen sind, sind schon ab ca. 30 Lichtern die Deferred Rendering
Methoden in Fllen mit viel auf den Bildschirm auftretenden Objekten und Lichtern zu
empfehlen.

Dies gilt umso mehr bei dynamischen Lichtern mit greren Radien, wobei in die-
sem Fall abzuwgen ist, ob die bereitgestellte Hardware fr die Implementation der
Rendering-Techniken den Systemvoraussetzungen fr Compute Shader erfllen. Falls
nicht, sollte in Abhngigkeit des Lichtradius sich entweder bei sehr greren Radi-
en fr das einfache Screen-Space Shading, bei kleineren fr das Lightvolume Based
Culling entschieden werden. Ob Stencil Buffer mit benutzt werden sollten oder nicht
hngt von der Szenerie ab, grundstzlich aber sollten sich vor allem bei dem Testfall
hnliche Szenen meistens positive Auswirkungen bei dessen Benutzung vorzufinden
sein.

Zusammenfassend sollte also bei Projekten mit vielen Szenen, welche besonders vie-
le Objekten und Lichter gleichzeitig auf dem Bildschirm auftauchen lassen, in Er-
wgung gezogen werden, sich fr das Deferred Rendering gnzlich zu entscheiden.
Die Forward-Variante des Tiled Based Cullings mag zwar die Performance im Ver-
gleich zu den anderen Forward-Rendering-Algorithmen in den Messungen bei klei-
nen bis mittleren Radien erheblich verbessert haben, bei allen Messungen waren
aber die besten Deffered-Rendering-Methoden im klaren Vorteil bezglich der Lauf-
zeit.

48
5 Messwerte und Auswertung der Benchmarktests

5.2 Testszene: Groe Flche - Sicht von der Seite

5.2.1 Erwartungen

Da in dieser Testszene die meisten im Bild vorkommenden Sphren verdeckt werden,


mssten die Early-Z-Methoden, wie auch das Deferred Rendering im Allgemeinen
positiv auftreten. Die Lichter in der Szene sind ber ein ganzes Feld verteilt, genauso
wie die Objekte selber, womit wir in der Kamera immer nur einen gewissen Ausschnitt
der gesamten Szene, und somit nur einen Teil der Objekte und Lichter gleichzeitig
auf dem Bildschirm sehen. Aus diesem Grund knnten das Forward Rendering in
einigen Stellen dennoch eine gewisse gute Performanz haben - einzuschtzen ist dies
aus Sicht der Anzahl an Objekten schwer, eben wegen der bereits erwhnten Mg-
lichkeit der Grafikkarte, nicht in der Kamera vorkommende Objekte abgrenzen zu
lassen.

Die Lichteranzahl sollte aber weitestgehend bei allen Lichtabgrenzungsverfahren op-


timiert bearbeitet werden. Weil immer nur ein Teil der Lichter zu sehen ist, mssten
die meisten Lichter abgegrenzt werden. Weitere Eigenschaften der Szene wie die
grtenteils hnlichen Bilder der Kamerafahrt entlang sollten auch bei den zustzlich
eingestellten Hilfsverfahren eine gewisse Auswirkung hinterlassen: Vor allem das Z-
Culling bei den Tiled Based Methoden msste einen nicht zu unterschtzenden Vorteil
erbringen, wenn man bedenkt, dass meistens ein groer Teil des Bildes entweder nur
den leeren Hintergrund darstellt, oder das vorderste Objekt - damit hat man in gewissen
Bildschirmbereichen grtenteils hnliche Z-Werte, womit das Z-Culling zustzlich
aushelfen kann. Des Weiteren dazu kommt auch die Effektivitt der Stencil Buffer Algo-
rithmus in Frage. Auf der Flche mssten die Lichter fr sich gesehen jeweils wenige
Objekte aus Sicht der Kamera treffen, womit zum Beispiel die Stencil Buffer Methode
hilfreich sein knnte.

49
5 Messwerte und Auswertung der Benchmarktests

5.2.2 Messergebnisse und deren Auswertung

Abbildung 5.5: Flche - Sicht von der Seite: Lichttest mit Radius 200

Als erstes wurde die Abhngikeit von der Lichteranzahl bei einem Radius von 200 Ein-
heiten gemessen. Bis ungefhr 100 Lichtern bleiben die Forward Rendering Methoden
auch hier effektiv, ab dieser Grenzschwelle jedoch knnen sind weder bei den simpleren,
noch bei den Tiled Based Methoden die Forward-Varianten im Vorteil. Die groe Anzahl
an verdeckten Fragmenten im Bild ist somit wohl gro genug, bei hheren Lichtern die
Deferred-Methoden zu bevorzugen.

Vegleicht man die Algorithmen ohne Compute Shader alleine, zeigt sich berraschen-
derweise bei der Stencil Buffer Methode ein gewisser Defizit von 1 bis zu maximal 5
Millisekunden. Wenn man sich die zweite hier durchgefhrte Messung anschaut, bei
welcher die Radien auf 500 Eiheiten erhht wurden, kann man erkennen, dass dies vor
allem von der Radiengre abhngt.

Im zweiten Graphen ist in diesem Punkt daher fast eine konstante maximale Verbesse-
rung der Performance zu sehen. Im hheren Bereich der Lichteranzahl liegt die sogar
bei ungefhr 12 Millisekunden - ca. 30% weniger im Vergleich zur Variante ohne Stencil
Buffer, die als schlechteste Laufzeit ca. 30 Millisekunden aufzeichnet, im Gegensatz zu
den 18 Millisekunden des Algorithmus mit Stencil Buffer.

50
5 Messwerte und Auswertung der Benchmarktests

Abbildung 5.6: Flche - Sicht von der Seite: Lichttest mit Radius 500

Eine weitere interessante Beobachtung sind die Laufzeiten aller Lichtabgrenzungsver-


fahren in den beiden Messungen, dessen Laufzeiten ab einer gewissen Lichteranzahl
konstant bleibt.

Dies ist wohlmglich durch die konstante Anzahl an Lichtern auf dem Bildschirm zu
erklren. Je nach Radius breitet sich der Effekt eines Lichtes aus. Bei kleineren Radien
ist die Anzahl an bildschirmeffektierenden Lichtern kleiner als bei greren Radien,
wenn man von einer uniformen Verteilung der Lichter in der 3D-Szene ausgeht. Daher
werden bei kleinen Radien die maximale Anzahl an solchen Lichtern pro Bildschirm-
schnappschuss schon bei wenigen Lichtern in der Szene erreicht, whrend bei greren
Radien dies erst bei einer gren Lichteranzahl passiert.

Zu unserer Vermutung wegen der Abhilfe der Laufzeit durch das Z-Culling hat sich
diese teilweise erfllt. Whrend beim kleineren Radius kaum an Performance gewonnen
wurde - beim Deferred Tiled Based Culling liegt die gewonnene Laufzeit bei maximal
einer Millisekunde, bei der Forward-Variante dessen wurde sogar an einigen Stellen
langsamere Performance aufgezeichnet - hat man vor allem bei den greren Radien des-
sen positiven Einfluss auf die Laufzeit entdecken knnen:

Bei der Forward-Variante erkennt man maximale Verbesserungen im 3 Millisekunden-


bereich, bei der Deferred-Variante sogar ganze 8 Millisekunden. Da die verglichenen
Laufzeiten beider Varianten um den 20-25 Millisekundenbereich liegen (24.31 beim Tiled
Based Forwad Rendering mit Early-Z ohne Z-Culling, 21.4 beim Tiled Based Deferred

51
5 Messwerte und Auswertung der Benchmarktests

Rendering ohne Z-Culling) sind diese Performanceboosts vergleichbar erheblich - fast


12% , bzw. 37%.

Zu verstehen ist dieser Unterschied der Laufzeiten in der Anzahl der durch das Z-
Culling abgegrenzten Lichtern durch die kleinere Anzahl an auftauchenden Lichtern
bei kleineren Radien. Da schon von vornerein weniger Lichter auf dem Bildschirm auf-
tauchen, ist die zustzliche Behandlung der Z-Werte grtenteils nicht die Mhe wert,
bei greren Radien hingegen steigt die maximale Anzahl an Lichtern im Bild, wodurch
mehr Lichter in Z-Richtung abgegrenzt werden knnen.

Abbildung 5.7: Flche - Sicht von der Seite: Radiustest

Betrachtet man die Messungswerte der Algorithmen in Abhngigkeit vom Lichtra-


dius, wurden auch hier unsere Erwartungen erfllt. Die Lichtabgrenzungsverfahren
verschlechtern sich mit greren Lichtradius, wobei vor allem die unterschiedliche Ska-
lierbarkeit zu beachten ist: Ab ca. 350 Lichtern ist das Tile Based Culling Verfahren des
Forward Rendering ohne zustzliche Abgrenzungen sogar schlechter als die simplere
Early-Z Methode, und auch die sonstigen Varianten des Tiled Based Cullings beginnen
bei einem Radius von 500 nah an die Laufzeit des Early-Z zu gelangen. Bei greren
Radien kann man also annehmen, dass die Abgrenzungsverfahren in diesen Fllen dann
nur eine Verschlimmerung der Laufzeit darstellen. Dies kommt teilweise berraschend,
da der Testfall eigentlich speziell dazu ausgelegt ist, die Abgrenzungsverfahren hier
optimiert laufen zu lassen. Dennoch ist dieses Problem viel weniger relevant bei der
Benutzung des Z-Cullings - damit werden auch bei greren Radien die Lichter stark
abgegrenzt.

52
5 Messwerte und Auswertung der Benchmarktests

Des Weiteren zeigt sich auch die bereits erwartete Effizienz des Stencil Buffer Algorith-
mus wieder: Auch wenn bei kleineren Radien dieser schon um nicht zu ignorierende 5
Millisekunden lnger braucht als die Alternative ohne Stencil Buffer, kann man deutlich
erkennen, dass mit greren Lichtradius, beginnend ab ungefhr 220 Einheiten, der Sten-
cil Buffer an grerer Relevanz gewinnt. Vor allem gegen Ende hin sind die Unterschiede
erheblich - die Laufzeit beim Lightvolume Based Culling ohne Stencil Buffer betrgt bei
einem Radius von 500 Einheiten im Durchschnitt 29.05 Millisekunden, bei der Benut-
zung des Stencil Buffers hingegen nur 17.1 Millisekunden.

Kommen wir somit zu der letzten Messung des zweiten Testfalls.

Abbildung 5.8: Flche - Sicht von der Seite: Objekttest

Da bei diesem Test wie bereits erwhnt vor allem die groe Anzahl an Verdeckungen
in der Szenerie exisieren, wird auch hier dieses nur wieder verdeutlicht. Alle Deferred
Rendering Methoden verlaufen fast gnzlich unabhngig von der Anzahl der Objekte.
Bei den Forward Rendering-Varianten ist dies weniger der Fall, vor allem aber zeigen
sich die Strken des frhzeitigen Tiefenpass beim Early-Z. Wie bei der normalen Early-Z
Methode, so auch bei der Kombination dieser mit dem Tiled Based Culling zeigt die
zustzliche Benutzung dessen erhebliche Gewinne.

Zuletzt sei noch gegen Ende eher konstant existierende Laufzeit erwhnt. Da in der
vorherigen Testszene alle Objekte gleichzeitig im Bild waren, hat sich auch die Laufzeit
somit mit jedem weiteren Objekt um ein vielfaches verschlechtert - auch wenn die

53
5 Messwerte und Auswertung der Benchmarktests

Steigung in hheren Bereich langsam begann abzufallen. Da hier aber meistens ein
groer Teil aller Objekte nicht im Bild vorkommen, kommt das effektive Culling der
Grafikkarte hier ins Spiel, weswegen die Laufzeit auch bei Hinzufgen weiterer Objekte
mit dem ersten Testfall verglichen eher konstant bleibt.

5.2.3 Fazit des zweiten Testfalls

Der Fokus dieses Testfalls lag bei der erhhten Anzahl an Verdeckungen: Insofern
konnten bei kleineren Radien beide Rendering-Alternativen gute Ergebnisse erbringen,
dies aber nur in Betracht der Benutzung der komplexeren Tiled Based Culling Verfahren.
Stellt man grere Radien ein, oder werden nur alleine die einfacheren Algorithmen
in einen Vergleich gesetzt, die keine Compute Shader voraussetzen, so sind bei einer
greren Anzahl an Lichtern die Lightvolume Based Culling Methoden(bei greren
Radien mit, bei kleineren ohne Stencil Buffer) im Vorteil.

Nichtsdestotrotz hat sich in diesem Szenario am deutlichsten gezeigt, dass die Benut-
zung eines zustzlichen Tiefenpasses beim Forward Rendering uerst hilfreich sein
kann. Dieser Testfall alleine erklrt aber nicht, inwiefern das Early-Z Verfahren im Nor-
malfall aushilft. Um somit abwgen zu knnen, ob die dadurch erhhte Performance
im hiesigen Best-Case nicht im Worst-Case gnzlich auseinander genommen wird, soll
der nchste Testfall ein Licht darauf werfen.

Generell haben sich im allgemeinen Vergleich zwischen beiden Render-Techniken ge-


zeigt, dass das Early-Z alleine nicht den groen Vorteil des Deferred Rendering ersetzen
kann. Nur bei sehr wenigen Lichtern konnten offensichtlich bessere Laufzeiten bei der
Forward Rendering Methode ersichtlich werden.

Zum Abschluss wurde hier nebenbei ein besseres Verstndnis der Einsatzgebiete beider
Lightvolume Based Verfahren erlangt. Vor allem bei kleineren Lichtradien kann auf das
Stencil-Buffer-Verfahren wegen zu groem Overhead verzichtet werden, whrend bei
greren Lichtradien der Stencil Buffer umso relevanter ausfllt.

54
5 Messwerte und Auswertung der Benchmarktests

5.3 Testszene: Groe Flche - Sicht von oben

5.3.1 Erwartungen

Wegen der Kameraperspektive, aus welcher man sehr viele Objekte und Lichter gleich-
zeitig erkennen kann, ohne dass es viele berlappungen gibt, sollte hiermit dieser
Testfall als Worst-Case Szenario fr alle Verdeckungsproblem lsenden Methoden gel-
ten. Grundstzlich gibt es hier eine einzige Art der Verdeckung, nmlich die Flche,
die von allen ber ihr liegenden Sphren verdeckt wird. Demzufolge sollten vor al-
len die Early-Z-Methoden kaum positive Auswirkungen haben, eventuell sogar die
Performance verschlechtern.

Weil auerdem alle Lichter, die nah an den Sphren und dem Boden liegen, diese gr-
tenteils auch berhren (bzw. im Lichtervolumen inne haben), kann des Weiteren davon
ausgegangen werden, dass das Z-Culling wie auch der Stencil Buffer Algorithmus im
Vergleich zur normalen Lightvolume Based Culling Methode nur negative Auswir-
kungen haben wird. Von der Kamera aus gesehen mssten alle der Lichtervolumen
existierenden Fragmente zur Beleuchtungsrechnung geschickt werden, da, falls mal
nicht die Sphre im Licht liegen wrde, die darunter liegende Flche in jedem Fall das
ganze Lichtervolumen berdeckt.

Interessant ist hier vor allem die berlegung, inwiefern das Deferred Rendering hilfreich
sein mag, wenn es kaum verdeckte Fragmente gibt. Normalerweise sollte die mehrfache
Berechnung der Fragmente von hinter anderen Objekten liegenden Vertices eines der
Grnde sein, wieso zum Deferred Rendering gewechselt wird, da dies vor allem bei
einer groen Anzahl an Lichtern und Objekten die Performance verschlechtert. Aus die-
sem Grund wird vor allem darauf geachtet, inwiefern neben dem Verdeckungsproblem
sich die generelle Laufzeit verbessert oder verschlechtert.

55
5 Messwerte und Auswertung der Benchmarktests

5.3.2 Messergebnisse und deren Auswertung

Abbildung 5.9: Flche - Sicht von Oben: Lichttest

Was als erstes beim ersten Graphen dieser Messung auffllt, ist, dass das grtenteils
nicht existente Verdeckungsproblem in der Testszene tatschlich die Early-Z Methoden
bei der simplen, wie auch bei den komplexeren Forward-Rendering-Methoden in der
Zahl der verworfenen Fragmente stark gedmpft wurde, weswegen berall der zustz-
liche Tiefenpass eine schlechtere Laufzeit erzeugt. Die Unterschiede zwischen dem An-
und Ausschalten dessen sind im Vergleich jedoch sehr gering:

Im schlimmsten Fall brachte das Early-Z einen Overhead von 3-4 Millisekunden, vergli-
chen mit der Per-Fragment-Methode. Eventuell zeigen sich grere Unterschiede beim
nchsten Graphen mit der variablen Objektanzahl - in Abhngigkeit von den Lichtern
verschlechtert sich dessen Laufzeit jedoch nicht zu stark im Vergleich zu den Methoden
ohne Tiefenpass.

Das Z-Culling hat den Erwartungen entsprechend nur fr die Laufzeit zustzliche ver-
geudete Berechnungen hinzugefgt. Bei beiden Rendering-Varianten des Tiled Based
Culling braucht die Benutzung des Z-Culling zustzlich um die 2 bis 3 Millisekun-
den.

56
5 Messwerte und Auswertung der Benchmarktests

Auch kann bei der ersten Messreihe beim Stencil Buffer erwhnt werden, dass die
erwartete Verschwendung des benutzten Algorithmus hier 1-3 Millisekunden zustzlich
an Laufzeit kostet. Die Relevanz der Kosten des Z-Cullings, wie auch des Stencil Buffers
werden gleich im Fazit dieses Testfalls genauer erklrt.

Abbildung 5.10: Flche - Sicht von Oben: Objekttest

In Abhngigkeit von der auftauchenden Anzahl an Objekten verschlechtert sich der


zustzliche Overhead des Early-Z weiterhin, jedoch bleiben die Diskrepanzen im ak-
zeptablen Bereich. Auch hier bleibt die maximale Verschlimmerung der Laufzeit durch
Benutzung dieser Methode bei 1-2 Millisekunden bei den einfachen Algorithmen, wie
auch beim komplexeren Tiled Based Culling.

57
5 Messwerte und Auswertung der Benchmarktests

Abbildung 5.11: Flche - Sicht von Oben: Radiustest

Bei dieser letzten Messung zeigen sich die gleichen Probleme wie bisher. Vor allem
der Stencil Buffer Algorithmus bleibt bei den zustzlich bentigten Kosten von ca. 3-4
Millisekunden. Auch das Z-Culling braucht dieselben oben benannten Kosten, wobei
Letzteres nicht berraschend sein sollte: Bei den Gegebenheiten dieser Szene sollte es
nur bei sehr kleinen Radien eine verndernde Auswirkung auf das Z-Culling geben, im
Falle, dass die Lichter ber der Flche schweben und zu klein sind, diese gnzlich mit
ihrem Volumen zu treffen. Ab einer bestimmten Radiengre jedoch treffen die Lichter
die Flche vollkommen, womit kaum Mglichkeiten zur Abgrenzung in Z-Richtung
existieren.

5.3.3 Fazit des dritten Testfalls

Was hat der dritte Testfall also gezeigt? Einerseits sind die verschiedenen Overheads
des Stencil Buffers wie der Early-Z-Variante generell vergleichbar gering gehalten.
Erinnert man sich an die mglichen Performanceverbesserungen durch die Benut-
zung dieser Methoden aus dem zweiten Testfall, wo in einigen Fllen bis zu 30%
schnellere Laufzeiten erreicht wurden, wird klar, dass zur Benutzung der Early-Z-
Methode in fast jedem Fall geraten werdem kann. Da in normalen Fllen diese Al-
gorithmen grtenteils nicht die Worst-Case-Flle konstant durchlaufen, wird das
Risiko, eben bei solchen kurz auftauchenden Worst-Cases ein paar Millisekunden an
Laufzeit zu verlieren, grtenteils durch die im Durchschnitt verbesserte Performance
mitigiert.

58
5 Messwerte und Auswertung der Benchmarktests

Des Weiteren hat sich aber gleichzeitg auch wiederum gezeigt, dass die Deferred-
Rendering-Pipeline so effektiv verdeckte Fragmente abtrennt, wie auch generell die
Beleuchtungsrechnung von der Laufzeit her stark vereinfacht, dass selbst im Worst-Case
diese bei grerer Anzahl an Objekten und Lichtern im Vergleich zum Early-Z bessere
Laufzeiten sichtbar sind.

Betrachtet man die hier gezeigten Messreihen auch aus der Sicht von Hardware ohne
Compute-Shader-Untersttzung, wird auch im Worst-Case des Verdeckungsproblems
- vor allem bei vielen Objekten und Lichtern - zum Deferred Rendering mit Light-
volume Based Culling, eventuell mit Stencil Buffer, geraten. Nur bei sehr wenigen
Lichtern und Objekten sind auch hier die einfachen Per-Fragment/Early-Z Algorithmen
akzeptabel.

5.4 Testszene: Crytek Sponza

5.4.1 Erwartungen

Generell sollten aber die Lichtabgrenzungsmethoden und Verdeckungsproblem l-


sende Algorithmen in beiden Messreihen eine bessere Laufzeit aufstellen als die Al-
gorithmen ohne deren Hilfe. Dies sollte sich deutlicher bei 200 Lichtern als bei 100
Lichtern zeigen, grundstzlich ist aber das Abschtzen aufgrund der randomisierten
Positionen und Radien schwer, selbst mit Zugriff auf die vorherigen Messergebnisse,
weswegen hier nur explizit nur eine mgliche Beantwortung unserer Fragestellung
erwartet.

Aus diesem Grund wird hier stark auf die Performancedifferenzen zwischen aller
Algorithmen geachtet, genauso wie deren maximalen und minimalen Ausschlge
in der Laufzeit, um deren Konsistenzen bei Kamerafahrten mit stark unterschiedli-
chen Bildern zu untersuchen. Somit sollte sich zeigen, ob bei einfacheren bis mitt-
leren 3D-Szenen die Implementation komplexerer Algorithmen ntig sind, und ob
die Wahl zwischen beiden Renderingmglichkeiten hier uns einfach fallen wird oder
nicht.

59
5 Messwerte und Auswertung der Benchmarktests

5.4.2 Messergebnisse und deren Auswertung

Abbildung 5.12: Sponza: Einfache Algorithmen mit 100 Lichtern

Abbildung 5.13: Sponza: Tile-Based-Algorithmen mit 100 Lichtern

Betrachtet man zuerst die einfachen Algorithmen alleine, sieht man bei 100 Lichtern nur
geringe Unterschiede in deren Laufzeiten. Der Early-Z und das Screen-Space Shading
haben hier zwar um eine Millisekunde eine bessere Laufzeit, zwischen den beiden ist
aber die Deferred-Variante viel konsistenter. Das Early-Z mag zwar ein besseres Mini-
mum erziehlt haben, mchte man aber flssige Framerates behalten, wre die letztere
aber eher zu empfehlen. Die drei anderen Algorithmen zogen im Average Case mit 100

60
5 Messwerte und Auswertung der Benchmarktests

Lichtern aber dafr den Krzeren - der Stencil Buffer ist hier sogar geringfgig inkon-
sistenter als die Lightvolume Based Methode ohne diesen.

Wrde man also nur von dieser Messreihe ausgehen, knnte man zum Schluss kommen,
dass im Average Case ein Umsprung zur Deferred-Variante nicht unbedingt ntig ist:
Die Gewinne sind hier nur sehr geringfgig.

Die komplexeren Tiled Based Algorithmen zeigen hingegen, wie das Z-Culling in Avera-
ge Cases vor allem bei der Konsistenz verhilft. Zwar sind die Varianten ohne Z-Culling
1-2 Millisekunden schneller, dafr aber sind die Ausschlge in beider Richtungen viel
kleiner.

Im allgemeinem Vergleich sieht man einen Unterschied von ca. 2-3 Millisekunden
zwischen den komplexeren und einfacheren Algorithmen, wobei die Tendenzen bei
Letzteren fr die Deferred-Varianten sprechen, whrend bei den Tiled Based Algorith-
men die Forward Version mit dem Early-Z nur eine minimal schnellere Laufzeit bietet.

Abbildung 5.14: Sponza: Einfache Algorithmen mit 200 Lichtern

Erhht man die Anzahl der Lichter auf das doppelte, was in Vergleich zu vorherigen
Testreihen verglichen immer noch wenig ist, kann man Verbesserung in der Konsis-
tenz des Stencil Buffer Algorithmus erkennen. Unterschiede in der durchschnittlichen
Laufzeit sind kaum erkennbar - einzig und allein die einfache Per-Fragment-Variante
eines Forward Renderers zeigt seine groen Nachteile. Die maximalen Ausschlgen
reichen bis ins fast doppelte der durchschnittlichen Zeit, whrend selbst diese bei ca
21 Millisekunden bleibt. Viel besser ist dabei das um ca. 5 Millisekunden schnellere
Early-Z, welches stark mit der Deferred-Variante konkurriert, wenn es um die Laufzeit
generell geht. Zum Vergleich: 21 Millisekunden sind ungefhr 47 Bilder die Sekunde,

61
5 Messwerte und Auswertung der Benchmarktests

whrend 16 Millisekunden ca. 62 Bilder die Sekunde bedeuten - ein mit dem Auge sehr
erkennbarer Unterschied.

Abbildung 5.15: Sponza: Tile-Based-Algorithmen mit 200 Lichtern

Bei 200 Lichtern zeigen aber hier die Tile-Based-Algorithmen, inwiefern sie im Nor-
malfall doch zu gebrauchen sind. Bei wenigen Lichtern mit durchschnittlich mittle-
ren Radien hatten diese nur geringe Performanceverbesserungen hergehalten, hier
kann man aber sofort erkennen, dass alle Varianten ca. 5 Millisekunden bessere Lauf-
zeiten bieten - vor allem in diesem Laufzeitenbereich sind das enorme Unterschie-
de.

5.4.3 Fazit des Average Case

In beiden Fllen, bei 100 Lichtern und 200 Lichtern, hatten die Tile-Based-Methoden
ihre Vorteile. Diese waren zwar bei weniger Lichtern geringer, brachten aber dennoch
eine bessere Laufzeit. Betrachtet man aber die Konsistenzen dieser, war diese bei den
Forward-Varianten bei niedriger, wie auch hherer Lichteranzahl besser als bei den
simpleren Forward-Alternativen.

Die Deferred-Varianten hingegen hatten grundstzlich bei wenigen wie bei vielen
Lichtern hnliche groe Ausschlge beibehalten, was aufgrund der etwas schlechtereren
Performance der einfacheren Deferred-Varianten bei hheren Lichtern die Tile-Based-
Methoden umso nutzbarer macht. Allgemein war aber bei allen Tile-Based-Algorithmen
die um einiges bessere Performance zu erkennen, was uns somit zur eigentlichen
Erkenntnis dieser Testszene bringt:

62
5 Messwerte und Auswertung der Benchmarktests

Die Deferred-Varianten waren bei 100 Lichtern im Durchschnitt hnlich performant wie
ihre Forward-Pendants: Weder die besten einfachen, noch die besten komplexen Metho-
den beider Renderingtechniken hatten einen gengend groen Abstand zur Alternative
erbracht. Von der flssigen Bildrate her waren aber bei den Algorithmen ohne Compute
Shader das Screen-Space Shading, bei denen mit das Forward Tiled Based Culling mit
Early-Z zu empfehlen. Abhngig von der benutzten Hardware also knnte man sich
hier fr die jeweilige Renderingtechnik entscheiden.

Bei 200 Lichtern hingegen zeigten bei beiden Algorithmengruppen die Deferred-Varianten
die besten Ergebnisse: Wie bei der Laufzeit, so auch bei der Konsistenz dieser sind das
Screen-Space Shading und das Tiled Based- mit Z-Culling beide zu empfehlen, wo-
bei die Differenz zur jeweils besten Forward Rendering Alternative uerst gering
war. Der Early-Z-Algorithmus mit und ohne Tile Based Culling und Z-Culling war im
Durchschnitt knapp eine Millisekunde langsamer als die Alternative - zu gering um
eine definitive Antwort im Sinne der Laufzeit geben zu knnen, welche der beiden
Renderingtechniken nun Vorne liegt - auch wenn die maximalen Ausschlge um 4
Millisekunden grer waren. Dies sollte also bedeuten, dass je nach Kameralage bei den
Forward-Varianten ab und zu grere Ruckler zu sehen sind, als einen entscheidenden
Vorteil bei der Bestimmung der besseren Renderingtechnik kann man dies aber nicht
klassifizieren.

Zusammenfassend haben sich grundstzlich bessere Laufzeiten beim Deferred Rende-


ring gezeigt, diese sind aber im Durchschnitt beim Average Case zur jeweiligen optimals-
ten Forward Rendering Alternative minimal gehalten. Aus diesem Grund kann hier, un-
abhngig von der Hardware, keines der beiden Renderingtechniken eine besondere Zu-
gunst erteilt werden - einzig bei fehlender Compute-Shader-Untersttzung wre das De-
ferred Rendering der Laufzeit betreffend eine bessere Wahl.

63
5 Messwerte und Auswertung der Benchmarktests

5.5 Gesamtauswertung aller Messergebnisse

Aus den erbrachten Ergebnissen haben sich verschiedene Sinnschlsse ergeben: Das
Verdeckungsproblem ist generell beim Forward Rendering einfach durch einen vor-
zeitigen Tiefenpass zu lsen, wenn auch nicht damit die grtmgliche Effizienz er-
bracht wird. Der zweite Testfall hatte vor allem gezeigt, dass die Benutzung eines
Early-Z-Algorithmus im schlimmsten Fall in bestimmten Szenen die Laufzeit nur sehr
wenige Millisekunden kosten kann, womit dieses Verfahren grundstzlich zu emp-
fehlen ist. Ersetzen kann sie aber die beim Verdeckungsproblem optimale Strategie
des Deferred Rendering nicht in jedem Fall. Genauer genommen ist das Early-Z in
dieser Hinsicht nur bei entweder sehr wenigen Objekten und/oder wenigen Lichtern
und somit Berechnungen im Fragment Shader ein Ersatz fr die alternative Rendering-
Variante.

Die einfacheren Lichtabgrenzungsmethoden, die keine Compute Shader gebrauchen,


hatten in den meisten Fllen eine sehr verbesserte Performanz erbracht, wobei diese wie-
derum stark vom Radius der gegebenen Lichter abhing - bei kleineren Radien kann auf
den Stencil Buffer beim Lightvolume Based Culling verzichtet werden, sonst wird des-
sen Benutzung empfohlen. Im Vergleich zu den hier vorgestellten einfacheren Forward-
Rendering-Methoden jedoch gab es bei objekt- und lichterbefllten Szenen aber kaum
Momente in welchen Letztere zu empfehlen wren.

Das Tiled Based Culling wiederum, welches hier in dieser Arbeit in zweifacher Aus-
fhrung vorkam, war besonders effektiv. In beiden Rendering-Techniken war diese in
den meisten Fllen die effizienteste Lsung des Lichterproblems. Ob das Abgrenzen
der Lichter in Z-Richtung jedoch zu gebrauchen ist, hatte grtenteils mit der Szenerie
zu tun: In Fllen mit vielen, hnlichen Tiefenwert, die Objekte mit wenig Lichtbefall
reprsentieren, als auch Szenerien mit vielen " in der Luft hngenden " Lichtern, die
zwar existieren, aber kaum Objekte treffen, hat sich die zustzliche Berechnung der
minimalen und maximalen Z-Werte ausgezahlt.

Zu den beiden Rendering-Techniken allgemein konnte in den Messungen eine Ten-


denz in Richtung des Deferred Renderings gefunden werden. Dieses war nmlich
konsistent in fast allen Messungen am performantesten - vor allem wenn man nur die
simplen Algorithmen alleine vergleicht, waren in den Fllen mit sehr vielen Lich-
tern die Unterschiede so gro, dass hierbei nur zum Deferred Rendering geraten
werden kann. Bei einem Hardwareunabhngigen Vergleich waren aber die Forward-
Varianten des Tile Based Culling konkurrenzfhig zur Deferred-Rendering-Version
dieser, auch wenn dessen Grenzen viel schneller erreicht wurden, als bei der Deferred-
Variante.

64
6 Fazit

Ziel dieser Arbeit war es zu klren, in welcher Hinsicht das Deferred Rendering, im
Vergleich zum Forward Rendering, positive Aspekte innehlt, und ob ein grundstzli-
cher Wechsel zu diesem Sinn machen wrde oder nicht. Die Beantwortung des ersten
Teils der Fragestellung lies sich anhand der durchgefhrten Benchmarktests relativ
ersichtlich gestalten: Vor allem bei einer greren Anzahl an verdeckten Objekten in
einer Szenenumgebung, wie auch bei einer stark erhhten Anzahl an existierenden
dynamischen Lichtern, waren die Laufzeiten des Deferred Rendering fast unschlagbar -
selbst die Forward-Variante des Tiled Based Cullings musste sich bei vielen Lichtern
mit greren Radien geschlagen geben.

Aus diesem Grund ist das Deferred Rendering generell bei komplexen Szenerien mit
hoher Anzahl an Lichtern zu empfehlen: Das Forward Rendering kann nur ber Com-
pute Shader vor allem in hheren Bereichen der Lichteranzahl mit dieser ansatzweise
konkurrieren, bessere Laufzeiten als bei der Alternative werden meistens aber nicht
erzielt.

Die zweite Frage ist eher schwieriger mit den hier vorgestellten Methoden zu beant-
worten, da sich bei der Recherche und Durchfhrung der Arbeit ein sehr breites Bild
des Deferred Rendering gezeichnet hat. Die Wahl, sich fr diese Rendering-Variante zu
entscheiden, kann aufgrund derer Eigenschaften im Endeffekt nicht einfach gemacht
werden. Die Benutzung des Deferred Rendering zieht Nachteile mit sich, die wegen
der Gre des gesamten Themas nicht in dieser Arbeit bearbeitet werden konnten, hier
aber dennoch noch einmal erwhnt werden sollten:

Ein fehlendes Hardware-Anti-Aliasing, wie auch die Komplexitt der korrekten Imple-
mentation von transparenten Objekten, knnen bei einem Projekt ausschlaggebend sein
bei der Wahl zwischen Forward und Deferred Rendering, womit die Frage in diesem Sin-
ne von den subjektiven voraussetzungen des Projekts abhngen.

Weitere Probleme knnten das Fehlen von gengend guter Multiple-Render-Target-


Untersttzung sein, was in lteren Grafikkarten und mobilen Gerten, wie vor allem
bei Konsolen der Fall ist. Um einige Vorteile des Deferred Rendering trotz dieses
Mangels auch im Konsolenbereich benutzen zu knnen, haben sich weitere Subarten

65
6 Fazit

des Deferred Rendering wie das sogenannte Deferred Lighting etabliert - fr einen
zustzlichen Vergleich dazu wurde aber aufgrund der schon so vorhanden Gre dieser
Arbeit dagegen entschieden.

Lsst man diese Mngel aber mal auen vor und betrachtet somit die Laufzeiten allei-
ne, sind vor allem die extremen Szenengegebenheiten relevant bei der Entscheidung,
wie auch die Mglichkeit, Compute Shader benutzen zu knnen, da bei dem Fehlen
Letzterer eine effektive Forward-Rendering-Implementation bei sehr vielen Lichtern
schwer fallen wird. In solchen Fllen kann auf das Deferred Rendering dann gar nicht
verzichtet werden, da die Laufzeitdifferenzen verglichen mit den simpleren Forward-
Rendering-Methoden viel zu gro sind.

Wie aber im Average Case gezeigt wurde, sind die Unterschiede in normal vorkom-
menden Szenen zwischen beiden Tile Based Varianten selbst bei 200 Lichtern relativ
gering, weswegen fr jedes Projekt eigenstndig abgewogen werden muss, ob die vor-
kommenden Eigenschaften ein Deferred-Rendering-System bevorzugen knnten oder
nicht. Dies kann unter anderem von der Grenordnung der Anzahl vorkommender
Objekte und Lichter, wie auch von der Anzahl an komplexer Algorithmen, die durch
ein solches System vereinfacht werden knnen, abhngen.

In dieser Arbeit wurde Letzteres dabei in Form der Normalmap-Berechnung kurz


angesprochen. Generell knnten neben der Beleuchtungsrechnung theoretisch weitere
Per-Fragment-Algorithmen versptet durchgefhrt werden um bessere Laufzeiten zu
erhalten. Inwieweit dies nun aber ausgenutzt werden kann, msste in einer weiteren
Arbeit untersucht werden.

Insgesamt hat sich in dieser Arbeit somit ergeben, dass die Erwgung, sich fr eine
Deferred-Rendering-Pipeline zu entscheiden, durchaus in vielen Fllen seine Vorteile
haben kann, bei modernerer Hardware aber der Performance-Unterschied im Normal-
fall nicht gro genug ist, um den mit sich gezogenen Ballast vollstndig ignorieren
zu knnen, weswegen die Entscheidung von den gesetzten Prioritten des jeweiligen
Projekts abhngt.

66
Anhang A

Die Unterteilungsstufen mssen von der kleinsten Gre aus betrachtet in der Hhe
und Breite ganze Vielfache dieser sein. Da wir bei wegen einer optimalen Lichtabgren-
zung gengend kleine Tiles als letztere Unterteilungsstufe haben wollen, entschied man
sich aufgrund der unzhligen Mglichkeiten bei einer in dieser Arbeit benutzten Bild-
schirmgre von 1600 x 900 auf Tiles der Gre 20 x 25. Davon ausgegangen konnten
nur ganze Vielfachen dieser, wie auch ganze Teiler der Bildschirmgre fr weitere
Unterteilungen zwischen diesen beiden Gren noch in Frage kommen. Insgesamt
wurden die fnf folgenden Unterteilungsfolgen betrachtet:

20 x 25

320 x 150 20 x 25

80 x 50 20 x 25

320 x 150 80 x 50 20 x 25

320 x 300 160 x 150 80 x 50 20 x 25

Der Reihe nach durchnummeriert wie sie hier stehen ergaben Messungen bei der
ersten Testszene mit 500 Lichtern und keinen Objekten, auer den Wnden, folgende
Messwerte (gemessen in Millisekunden pro Frame):

Unterteilungen Min. Mil.Sek. Durchschnitt. Mil.Sek. Max. Mil.Sek.


1. Unterteilungsfolge 30.56 37.79 44.11
2. Unterteilungsfolge 28.89 36.24 42.9
3. Unterteilungsfolge 29 36.42 42.96
4. Unterteilungsfolge 28.86 36.3 43.03
5. Unterteilungsfolge 29.25 36.7 43.06

Auch mehrere Testlufe ergaben hnliche knappe Ergebnisse, weswegen die zweite
Unterteilungsfolge gewhlt wurde.

67
Anhang B

Alle Angaben bezeichnen die durchschnittliche bentigte Zeit pro Frame in Millisekun-
den.

Zu den Abkrzungen :

EAZ := Early-Z

DR := Deferred Rendering

FR := Forward Rendering

ZC := Z-Culling

Testszene Box:

Lichttest:
Lichter 0 10 20 50 100 200 500 750 1024
Per-Fragment 2.36 3.11 4.11 9.2 17.8 35.44 86.71 128.48 171.85
Early-Z 3.36 3.93 4.1 7.1 13.15 25.82 62.46 91.93 124.23
Screen-Space 5.77 5.83 5.83 5.83 8.26 14.08 31.49 45.48 60.95
Lightvolume 5.12 5.2 5.24 5.64 6.57 10.56 21.69 28.82 34.82
Lightvolume Stencil 5.13 5.26 5.39 6.05 6.86 10.31 19.73 25.03 29.49
DR Tile 5.16 5.13 5.13 5.15 5.29 7.04 13.52 18.05 21.8
DR Tile ZC 5.32 5.28 5.3 5.62 6.14 8.01 13.42 16.84 19.52
FR Tile 3.22 3.99 4.57 7.12 11.15 23.52 59.34 77.54 85.59
FR Tile EAZ 3.74 4.37 4.77 6.26 8.5 16.01 39.02 51.82 58.51
FR Tile EAZ ZC 6.26 6.27 6.48 7.55 9.55 15.98 35.94 46.15 50.59

68
6 Fazit

Objekttest:

Objekte 0 50 100 200 500 750 1000


Per-Fragment 40.45 44.34 49.09 58.94 85.94 101.12 108.99
Early-Z 34.53 39.4 44.3 49.42 61.93 72.65 81.27
Screen-Space 28.82 29.08 29.28 29.82 31.38 32.38 33.2
Lightvolume 17.26 17.59 17.91 18.8 21.23 22.69 23.87
Lightvolume Stencil 12.19 12.7 13.15 14.7 19.08 21.59 23.02
DR Tile 10.85 11.07 11.3 11.89 13.39 14.45 15.4
DR Tile ZC 8.99 9.34 9.65 10.63 13.24 14.81 15.77
FR Tile 17.86 21.95 25.98 34.82 58.75 67.79 68.92
FR Tile EAZ 16.07 20.11 24.06 28.97 38.69 45.02 46.69
FR Tile EAZ ZC 11.26 14.36 17.32 23.06 35.45 41.67 43.68

Radiustest:
Radius 50 100 200 350 500
Per-Fragment 77.92 79.45 86.21 107.34 136.29
Early-Z 56.52 57.66 62.02 76.4 96.61
Screen-Space 28.75 29.14 31.28 37.65 47.09
Lightvolume 6.34 7.85 21.16 54.55 94.66
Lightvolume Stencil 10.57 10.75 19.23 50.67 93.07
DR Tile 5.23 5.87 13.42 32.9 56.81
DR Tile ZC 5.44 6.83 13.27 30.49 53.46
FR Tile 6.95 18.6 58.96 133.49 208.43
FR Tile EAZ 6.09 12.73 38.74 91.38 146.72
FR Tile EAZ ZC 7.14 12.66 35.65 84.19 139.01

69
6 Fazit

Testszene Flche - Sicht von der Seite:

Lichttest - Radius 200:


Lichter 0 10 20 50 100 200 500 750 1024
Per-Fragment 1.8 2.08 2.25 3.29 5.43 10.96 31.8 47.56 63.99
Early-Z 2.07 2.38 2.53 3.58 5.47 9.32 20.64 30.14 41.03
Screen-Space 5.63 5.84 5.8 5.7 7.44 12.77 28.71 41.88 56.41
Lightvolume 5.14 5.19 5.14 5.21 5.35 6.38 8.67 9.71 10.12
Lightvolume Stencil 5.18 5.23 5.39 5.67 6.43 7.54 10.64 13.03 15.99
DR Tile 5.04 5.12 5.24 5.07 5.16 5.1 6.74 7.42 7.84
DR Tile ZC 5.18 5.38 5.36 5.37 5.28 5.43 6.16 6.48 6.66
FR Tile 3.48 3.66 3.71 4.14 5.31 7.47 12.28 13.1 13.49
FR Tile EAZ 4.02 4.54 4.14 4.46 5.58 6.68 8.6 9.52 9.96
FR Tile EAZ ZC 6.13 6.13 6.2 6.1 6.71 7.72 8.99 9.47 9.76

Lichttest - Radius 500:


Lichter 0 10 20 50 100 200 500 750 1024
Per-Fragment 2.1 2.41 2.51 4.04 6.74 13.78 36.54 52.17 68.81
Early-Z 3.29 3.63 4.01 4.57 6.58 11.36 23.64 33.16 43.99
Screen-Space 5.57 5.81 5.85 5.81 8.31 14.24 30.62 43.77 58.24
Lightvolume 5.25 5.23 5.32 6.58 10.44 17.38 28.71 29.84 30.41
Lightvolume Stencil 5.23 5.35 5.53 5.93 7.67 11.8 17.22 17.87 18.44
DR Tile 5.23 5.11 5.22 5.24 7.5 12.21 20.3 21.1 21.4
DR Tile ZC 5.34 5.37 4.26 5.35 6.89 9.41 13.04 13.41 13.53
FR Tile 3.53 3.96 5.31 5.73 9.04 17.42 35.73 36.57 36.88
FR Tile EAZ 4.03 4.35 4.26 5.84 8.64 14.02 22.9 23.91 24.31
FR Tile EAZ ZC 6.42 6.49 5.17 7.05 9.48 13.88 20.22 20.78 21.01

70
6 Fazit

Objekttest:

Objekte 0 50 100 200 500 750 1000


Per-Fragment 13.82 16.89 18.05 22.64 31.64 33.17 34.21
Early-Z 13.83 15.62 16.2 17.91 20.68 22.44 23.6
Screen-Space 27.21 27.4 27.51 27.83 28.72 29.47 30.1
Lightvolume 6.48 6.73 6.83 7.66 8.7 9.43 10.1
Lightvolume Stencil 8.86 9.03 9.16 9.58 10.62 11.36 12.01
DR Tile 4.77 4.94 5.03 5.72 6.69 7.49 8.16
DR Tile ZC 4.24 4.48 4.66 5.2 6.16 6.91 7.65
FR Tile 3.74 4.44 5.07 7.27 12.27 13.63 14.86
FR Tile EAZ 3.75 4.29 4.71 6.22 8.61 10.19 11.6
FR Tile EAZ ZC 4.19 4.72 5.34 6.67 8.93 10.49 11.95

Radiustest:
Radius 50 100 200 350 500
Per-Fragment 30.86 30.91 31.79 33.81 36.66
Early-Z 20.03 20.14 20.64 21.88 23.76
Screen-Space 28.55 28.33 28.73 29.63 31.03
Lightvolume 6.42 6.2 8.69 18.2 29.05
Lightvolume Stencil 10.76 10.35 10.63 11.23 17.1
DR Tile 5.25 5.14 6.72 12.87 20.29
DR Tile ZC 5.32 5.29 6.15 9.22 13.02
FR Tile 4.52 6.46 12.26 23.21 35.61
FR Tile EAZ 4.69 5.68 8.6 15.16 22.88
FR Tile EAZ ZC 6.22 6.58 8.91 13.96 20.12

71
6 Fazit

Testszene Flche - Sicht von Oben:

Lichttest:
Lichter 0 10 20 50 100 200 500 750 1024
Per-Fragment 2.06 2.53 3.28 6.06 11.32 22.22 53.59 81.93 110.23
Early-Z 3.2 2.77 3.59 6.46 11.69 22.75 54.53 84.23 114.36
Screen-Space 5.78 5.77 5.78 5.71 7.61 13.21 30 43.59 59
Lightvolume 5.11 5.15 5.11 5.14 5.24 5.93 10.09 10.32 10.56
Lightvolume Stencil 5.08 5.23 5.31 5.69 6.19 7.39 11.57 13.46 16.19
DR Tile 5.08 5.04 5.07 5.06 5.07 5.04 5.04 5.82 5.93
DR Tile ZC 5.16 5.16 5.17 5.18 5.24 5.61 7.62 7.53 7.57
FR Tile 3.42 3.34 3.3 3.61 3.96 5.44 8.36 8.38 8.43
FR Tile EAZ 3.85 4.89 4.18 4.03 4.67 5.97 8.85 8.83 8.9
FR Tile EAZ ZC 6.17 6.18 6.09 6.13 6.21 7.69 10.75 10.79 10.86

Objekttest:

Objekte 0 50 100 200 500 750 1000


Per-Fragment 27.36 28.51 31.61 38.1 53.54 54.25 55.01
Early-Z 27.58 28.84 32.1 38.6 54.7 55.55 56.35
Screen-Space 28.5 28.57 28.8 29.11 30.12 30.72 31.31
Lightvolume 8.07 8.16 8.36 8.79 9.98 10.69 11.4
Lightvolume Stencil 9.71 9.76 9.95 10.21 11.45 12.15 12.87
DR Tile 4.42 4.49 4.64 4.92 5.82 6.56 7.25
DR Tile ZC 5.97 6.11 6.26 6.56 7.45 8.18 8.92
FR Tile 4.11 4.37 4.85 5.8 8.3 9.39 10.59
FR Tile EAZ 4.13 4.42 4.92 5.98 8.76 10.01 11.27
FR Tile EAZ ZC 5.95 6.29 6.79 7.87 10.66 11.92 13.18

72
6 Fazit

Radiustest:
Radius 50 100 200 350 500
Per-Fragment 51.52 52.17 53.78 58.2 64.8
Early-Z 52.45 53.14 54.67 59.11 65.87
Screen-Space 28.81 28.8 29.91 32.88 37.17
Lightvolume 6.28 6.07 10.06 22.28 38.46
Lightvolume Stencil 10.67 10.29 11.53 24.63 41.9
DR Tile 5.2 5.08 5.83 12.46 22.45
DR Tile ZC 5.31 5.24 7.49 14.2 24.35
FR Tile 3.98 4.48 8.29 21.31 41.1
FR Tile EAZ 4.69 5.22 8.75 21.82 41.69
FR Tile EAZ ZC 6.13 6.56 10.63 23.86 43.83

Testszene Sponza:

Test mit 100 Lichtern:


Algorithmen Minimum Durchschnitt Maximum
Per-Fragment 6.23 10.52 18.88
Early-Z 6.16 8.57 17.11
Screen-Space 6.16 8.57 17.11
Lightvolume 6.76 8.66 11.37
Lightvolume Stencil 6.48 9.47 17.65
DR Tile 5.86 7.51 24.79
DR Tile ZC 6.13 7.93 17.37
FR Tile 2.66 8.2 17.89
FR Tile EAZ 2.85 6.79 13.01
FR Tile EAZ ZC 5.42 8.22 10.95

Test mit 200 Lichtern:


Algorithmen Minimum Durchschnitt Maximum
Per-Fragment 11.87 20.64 36.7
Early-Z 11.9 16.11 27.12
Screen-Space 12.48 15.15 18.76
Lightvolume 6.97 14.4 28.77
Lightvolume Stencil 7.78 14.03 24.72
DR Tile 6.24 10.55 26.73
DR Tile ZC 6.2 10.56 17.1
FR Tile 4.67 14.11 37.92
FR Tile EAZ 4.75 11.8 25.37
FR Tile EAZ ZC 6.11 11.73 20.29

73
Literaturverzeichnis

[1] Microsoft Corporation. Pipeline Stages(Direct3D 10). http://msdn.microsoft.


com/en-us/library/windows/desktop/bb205123(v=vs.85).aspx, 2014. Zuletzt
besucht am: 17.07.2014.

[2] Gemeinschaft der OpenGL-Wiki-Autoren, siehe Versionsgeschichte. Rende-


ring Pipeline Overview. http://www.opengl.org/wiki_132/index.php?title=
Rendering_Pipeline_Overview&oldid=8134, 2013. Zuletzt besucht am: 17.07.2014.

[3] The Khronos Group. OpenGL Overviewl. http://www.opengl.org/about/, 2014.


Zuletzt besucht am: 17.07.2014.

[4] Caspian Rychlik-Prince. About LWJGL. http://lwjgl.org/wiki/index.php?


title=About_LWJGL, 2012. Zuletzt besucht am: 17.07.2014.

[5] Brian Matzon, kappaOne, momokan und Ioannis Tsakpinis. Version selection.
http://lwjgl.org/changelog.php, 2013. Zuletzt besucht am: 17.07.2014.

[6] Gemeinschaft der OpenGL-Wiki-Autoren, siehe Versionsgeschichte. Framebuf-


fer Objects. http://www.opengl.org/wiki_132/index.php?title=Framebuffer_
Object&oldid=11438, 2013. Zuletzt besucht am: 17.07.2014.

[7] Gemeinschaft der Wikibooks-Autoren, siehe Versionsgeschichte. Opengl program-


ming/stencil buffer wikibooks, the free textbook project. http://en.wikibooks.
org/w/index.php?title=OpenGL_Programming/Stencil_buffer&oldid=2506514,
2013. Zuletzt besucht am: 18.07.2014.

[8] Gemeinschaft der OpenGL-Wiki-Autoren, siehe Versionsgeschichte. Per-Sample


Processing. http://www.opengl.org/wiki_132/index.php?title=Per-Sample_
Processing&oldid=11177, 2013. Zuletzt besucht am: 17.07.2014.

[9] Gemeinschaft der OpenGL-Wiki-Autoren, siehe Versionsgeschichte. Com-


pute Shader. http://www.opengl.org/wiki_132/index.php?title=Compute_
Shader&direction=next&oldid=11280, 2013. Zuletzt besucht am: 17.07.2014.

[10] Gemeinschaft der OpenGL-Wiki-Autoren, siehe Versionsgeschichte. Shader Stora-


ge Buffer Object. http://www.opengl.org/wiki_132/index.php?title=Shader_
Storage_Buffer_Object&oldid=10740, 2013. Zuletzt besucht am: 17.07.2014.

74
Literaturverzeichnis

[11] Gemeinschaft der Wikipedia-Autoren, siehe Versionsgeschichte. Blinnphong


shading model wikipedia, the free encyclopedia. http://en.wikipedia.org/
w/index.php?title=Blinn%E2%80%93Phong_shading_model&oldid=610314649,
2014. Zuletzt besucht am: 18.07.2014.

[12] Gemeinschaft der Wikipedia-Autoren, siehe Versionsgeschichte. Multiple render


targets wikipedia, the free encyclopedia. http://en.wikipedia.org/w/index.
php?title=Multiple_Render_Targets&oldid=574813172, 2013. Zuletzt besucht
am: 18.07.2014.

[13] Microsoft Corporation. Xbox 360 Technical Specifications. http:


//web.archive.org/web/20080822024003/http://www.xbox.com/en-AU/
support/xbox360/manuals/xbox360specs.htm, 2008. Zuletzt besucht am:
17.07.2014.

[14] The Khronos Group Inc. OpenGl ES Version 3.0. http://www.khronos.


org/registry/gles/specs/3.0/es_spec_3.0.0.pdf, 2012. Zuletzt besucht am:
17.07.2014.

[15] Unity Technologies. Unity Documentation. http://docs.unity3d.com/Manual/


RenderTech-DeferredLighting.html. Zuletzt besucht am: 17.07.2014.

[16] NC Software Rusty Koonce. CPU Gems 3. http://http.developer.nvidia.com/


GPUGems3/gpugems3_ch19.html. Zuletzt besucht am: 17.07.2014.

[17] Emil Persson. Deep deferred shading. http://www.humus.name/index.php?page=


3D&ID=75. Zuletzt besucht am: 17.07.2014.

[18] NVIDIA Matthus G. Chajdas, Morgan McGuire und David Luebke. Subpixel Re-
construction Antialiasing for Deferred Shading. https://research.nvidia.com/
publication/subpixel-reconstruction-antialiasing, 2011. Zuletzt besucht
am: 17.07.2014.

[19] NVIDIA Timothy Lottes. FXAA. http://www.ngohq.com/images/articles/fxaa/


FXAA_WhitePaper.pdf, 2009. Zuletzt besucht am: 17.07.2014.

[20] Shawn Hargreaves. Deferred Shading. http://www.shawnhargreaves.com/


DeferredShading.pdf, 2004. Zuletzt besucht am: 17.07.2014.

[21] DICE Yuriy ODonnel. Rendering deferred lights using Stencil culling algo-
rithm. http://kayru.org/articles/deferred-stencil/, 2009. Zuletzt besucht
am: 17.07.2014.

[22] Intel Andrew Lauritzen. Deferred Rendering for Current and Future Rende-
ring Pipelines. https://prd1idz.cps.intel.com/sites/default/files/m/d/4/

75
Literaturverzeichnis

1/d/8/lauritzen_deferred_shading_siggraph_2010.pdf. Zuletzt besucht am:


17.07.2014.

[23] DICE Johan Andersson. DirectX 11 Rendering in Battlefield 3. http://


dice.se/wp-content/uploads/GDC11_DX11inBF3_Public.pdf. Zuletzt besucht
am: 17.07.2014.

[24] Ola Olsson und Ulf Assarsson. Tiled Shading - Preprint. http://www.
cse.chalmers.se/~uffe/tiled_shading_preprint.pdf. Zuletzt besucht am:
17.07.2014.

[25] AMD Jason Stewarts. TiledLighting11 v1.1. http://developer.amd.


com/tools-and-sdks/graphics-development/graphics-development-sdks/
amd-radeon-sdk/. Zuletzt besucht am: 17.07.2014.

[26] AMD. Radeon HD 7900 Series Graphics Real-Time Demos. http:


//developer.amd.com/resources/documentation-articles/gpu-demos/
amd-radeon-hd-7900-series-graphics-real-time-demos/. Zuletzt besucht am:
17.07.2014.

[27] Lighthouse3D. OpenGL Timer Query. http://www.lighthouse3d.com/


tutorials/opengl-short-tutorials/opengl-timer-query/. Zuletzt besucht am:
17.07.2014.

[28] Crytek Frank Meinl. Crytek Sponza. http://graphics.cs.williams.edu/data/


meshes.xml, 2010. Zuletzt besucht am: 17.07.2014.

76

Das könnte Ihnen auch gefallen