Die Entwicklung von Shadern und ihr moderner Einsatz in der Industrie

Transkript

1 BACHELORARBEIT Die Entwicklung von Shadern und ihr moderner Einsatz in der Industrie ausgeführt von Bernd Steinberger A-2524 Teesdorf, Kirchfeldstraße 28b Begutachter: FH-Prof. Dipl.-Ing. Alexander Nimmvervoll Teesdorf, Ausgeführt an der FH Technikum Wien Studiengang Informatik

2 Eidesstattliche Erklärung Ich erkläre hiermit an Eides Statt, dass ich die vorliegende Arbeit selbständig angefertigt habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Die Arbeit wurde bisher weder in gleicher noch in ähnlicher Form einer anderen Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht. Ort, Datum Unterschrift

3 Kurzfassung Diese Arbeit setzt sich mit dem Thema der Shader Entwicklung auseinander. Aufgrund des großen Umfangs kann hier lediglich ein Einstieg bzw. Überblick gewährt werden. Shader entwickelten sich seit dem Film Star Wars Ende der 70er Jahre. Sie ermöglichen es, Grafikkarten zu programmieren und effizient zu nutzen. Mit Hilfe von verschiedenen Werkzeugen konnten so die ersten Animationsfilme geschaffen und Computerspiele immer wieder mit detailreicheren Facetten ausgestattet werden. Sowohl HLSL als auch GLSL sind dabei wichtige Vertreter der Shader Sprachen. Um einen angemessen Praxisbezug herzustellen, werden einige ausgewählte Effekte durch die wichtigsten Entwicklungsschritte begleitet. Heutige Videospiele können auf solche Techniken mittlerweile nicht mehr verzichten, da die zur Verfügung stehenden Ressourcen sinnvoll genutzt werden müssen. Schlagwörter: Shader Entwicklung, Shader Sprache, Animationsfilm, Videospiel, Effekte

4 Abstract This paper deals with the development of Shaders. The goal is to get an overview of the topic because all details would fill hundreds of pages. The Shader languages are evolving since George Lucas had born Star Wars in the end of the seventies. They are used for programming graphic cards and for dealing with them efficiently. By the help of some tools the first animation movies were born and videogames had been growing and growing in detail over time. HLSL and GLSL are the most common languages for developing Shaders. To show how to handle them the paper walks through the development steps of some example effects. Today s videogames are dependent on these techniques because they need to take care of the available hardware resources. Keywords: Shader development, Shader language, animation movie, videogame, effects

5 Danksagung Ich danke meinem Betreuer, FH-Prof. Dip.-Ing. Nimmervoll Alexander, für seine Unterstützung, Ratschläge und aufgewendete Zeit bei dieser Arbeit.

6 Inhaltsverzeichnis 1 Problemstellung Definition Shader Grundsätzliche Begriffsklärung und Notwendigkeit Ablauf in der Hardware Shader Typen Vertex Shader Geometry Shader Pixel Shader Hull und Domain Shader Die Geschichte der Shader Programmierung Implementierung von Shadern Vorraussetzungen Beleuchtung Texturing Sprachen Gemeinsamkeiten HLSL GLSL Andere Debugging PIX NVIDIA Shader Debugger ATI PerfStudio Erzielbare Effekte Shader Grundgerüst Shading (Lighting) Classic Texture Mapping Bump Mapping (Normal Mapping) Cel Shader (Toon Shader) Shadow Mapping Einsatz in der Industrie Ausblick und Zusammenfassung...38 Literaturverzeichnis...40

7 Abbildungsverzeichnis...42 Tabellenverzeichnis...43 Abkürzungsverzeichnis...44 Anhang A: Zusätzliche Bildvergleiche...45

8 1 Problemstellung In dieser Arbeit soll ein Einblick in die Programmierung von Shadern und deren Einsatz in der Industrie gegeben werden. Dabei ist es wichtig zu klären, was ein Shader ist und für welche Teilprobleme der Computergrafik ein solcher eingesetzt wird. Welche unterschiedlichen Shader Typen gibt es? Die Antworten zu diesen Punkten sollen einen Überblick über die Funktionalitäten und Möglichkeiten von Shadern liefern. Auch der historische Laufweg soll aufgezeigt werden. Wann wurde der erste Shader programmiert und wie entwickelten sie sich in OpenGL und DirectX? Welche Sprachen stehen einem Entwickler zur Verfügung? Dabei werden die beiden wichtigsten Sprachen, HLSL und GLSL, hervorgehoben und die anderen Alternativen kurz vorgestellt. Einige der interessantesten erzielbaren Effekte mit Hilfe der Shader Programmierung sollen Teil des Ergebnisses sein. Dafür werden diese ausgewählten Exemplare durch Einsatz der HLSL Sprache implementiert und jeweils vorgestellt. Außerdem gilt es, die Möglichkeiten des Debugging zu besprechen. Welche Tools stehen den einzelnen Sprachen dabei zur Verfügung? Mit Hilfe einiger praktischer Beispiele soll so eine bessere Veranschaulichung erreicht werden. Wie sieht der technische Ablauf bei der Ausführung eines Shaders aus? Hier ist als Ergebnis eine Aufstellung der einzelnen Stufen im Prozess bzw. in der Hardware gefordert. Ein weiteres Ziel ist es, einige Einsatzgebiete von Shadern in der Industrie vorzustellen. Vor allem in den Bereichen der Computerspiele und des Animationsfilms soll ein angemessener Bezug hergestellt werden. Was wird die Zukunft bringen bzw. welche Neuerungen sind zu erwarten? Damit wird schließlich ein Ausblick auf die kommenden Entwicklungen im Bereich der Shader Programmierung gewährt. 1

9 2 Definition Shader 2.1 Grundsätzliche Begriffsklärung und Notwendigkeit Zu Beginn der Computergrafik gab es keinerlei Hilfsmittel, welche einem Entwickler auch nur ein bisschen Arbeit abnahmen. Wollte dieser eine Animation oder etwas dergleichen erstellen, musste jede Kleinigkeit manuell ausprogrammiert werden. (vgl. Bailey, Cunningham 2009, S. xxiii xxvii) Jeder Entwickler verfolgte dabei seine eigene Strategie und trotz des hohen Aufwandes entstanden nur sehr schlichte Bilder im Vergleich zu heutigen Beispielen. Daher wurde versucht, Standards zu etablieren, welche allerdings nur wenige verschiedene Funktionen implementierten. (vgl. Bailey, Cunningham 2009, S ) Um diesen Ablauf zu erleichtern, wurden etwas später Application Programming Interfaces (API) eingeführt, wodurch dem Programmierer große Teile des Arbeitsaufwandes abgenommen und die Vorgänge automatisiert werden konnten. Leider war dadurch wiederum die Freiheit des Schaffens eingeschränkt, da auf alle der API nicht bekannten Funktionen verzichtet werden musste. (vgl. Bailey, Cunningham 2009, S. xxiii xxvii) Durch die Einführung von Grafikprozessoren (engl. Graphics Processing Unit - GPU) sollte diesem Problem schließlich ebenfalls Einhalt geboten werden. (vgl. Bailey, Cunningham 2009, S. xxiii xxvii) Zunächst implementierten die Grafikkarten nur die Fixed Function Pipeline, in der es relativ wenige Freiheiten für die Programmierer gab. (vgl. Bailey, Cunningham 2009, S ) Mit Hilfe von sogenannten Shader Sprachen konnten die von den APIs nicht unterstützen Funktionen wieder eingearbeitet werden, um so den Bedürfnissen nach frei programmierbaren Grafikkarten nachzukommen. Diese Shader Programme wurden auf dem Grafikprozessor geladen und dort dann auch ausgeführt. (vgl. Bailey, Cunningham 2009, S. xxiii xxvii) 2.2 Ablauf in der Hardware Grundsätzlich wird die Rendering Pipeline in die drei Stufen Application, Geometry und Rasterizer eingeteilt. Von der GPU werden allerdings nur die letzten beiden Stufen implementiert. Diese Implementierung wird wiederum in acht Teile gegliedert, welche in Abbildung 1 unterhalb ersichtlich sind. Dabei ist zu beachten, dass die grünen Stufen voll programmierbar, die gelben nur konfigurierbar und die blauen fix verdrahtet sind. Zu Beginn waren alle diese Funktionen ein fest verdrahteter Bestandteil der Grafikkarte. Im Laufe der Zeit sind sie erst konfigurierbar und schließlich vollständig frei programmierbar geworden. Und der Trend geht in Zukunft auch weiterhin Richtung mehr Flexibilität und Dynamik für den Programmierer. (vgl. Akenine-Möller et al. 2008, S ) Abbildung 1 - Stufen der Rendering Pipeline auf der GPU (Akenine-Möller et al. 2008) 2

10 Zunächst wird ein Shader Programm kompiliert. Dies kann bereits bevor das Programm geladen wird oder auch während der Laufzeit erfolgen. Danach wird der komplette Shader nur mehr als Text dargestellt und über die Treiber auf die GPU geladen. (vgl. Akenine-Möller et al. 2008, S ) Die einzelnen programmierbaren Shader Stufen teilen sich ein einheitliches Programmiermodell, welches als Common-Shader Core bezeichnet wird und die API für die Entwicklung darstellt. Die Shader werden mit Hilfe von eigenen Sprachen wie HLSL oder GLSL geschrieben, welche Bestandteil von Kapitel 4.2 sind. Dieser Code wird dann in eine maschinenunabhängige Assembler Sprache umgewandelt, welche als Intermediate Language (IL) bekannt ist. Die Treiber sorgen dann letztendlich dafür, dass dieses Ergebnis über einen weiteren Schritt in die tatsächliche Maschinensprache übersetzt wird. Die IL dient somit als Vermittler zwischen der Shader Sprache und der Maschinensprache und kann als virtuelle Maschine angesehen werden. Durch dieses Prozedere wird eine hardwareunabhängige Programmierung ermöglicht. (vgl. Akenine-Möller et al. 2008, S ) Aus der Grafikanwendung heraus müssen Zeichenbefehle gesendet werden, um damit der API den Auftrag zu geben, Figuren zu zeichnen. Es gibt zwei unterschiedliche Werttypen, welche den Shadern als Input zur Verfügung stehen. Dies sind einerseits die variablen Werte, welche für jeden Vertex bzw. Pixel anders sein können und andererseits die einheitlichen Werte, welche während eines Zeichendurchgangs konstant bleiben und erst danach wieder einen anderen Inhalt annehmen können. Texturen werden als spezielle Form von einheitlichen Eingabewerten angesehen. (vgl. Akenine-Möller et al. 2008, S ) Alle Ein- und Ausgabewerte werden in unterschiedlichen Registern der Hardware abgelegt. Die einheitlichen Werte sind im Constant Register (oder auch Constant Buffer genannt) gespeichert und können nur gelesen werden. Für jeden Pixel bzw. Vertex werden die variablen Werte in eigenen Registern abgelegt. Schließlich gibt es noch ein temporäres Register, welches für diverse andere Zwischenspeicherungen genutzt werden kann. (vgl. Akenine-Möller et al. 2008, S ) 2.3 Shader Typen Vertex Shader Der Vertex Shader ist der erste Schritt im Verarbeitungsprozess der Rendering Pipeline. Er bekommt die Daten von der Applikation in einer für ihn zuvor angepassten, verständlichen Form geliefert. Beispielsweise werden übergebene Arrays mit Farb- und Positionsdaten in die entsprechenden Vertices des Objektes umgewandelt. Der Vertex Shader kann dann nicht mehr feststellen, welche Dreiecke aus den Vertices gebildet wurden. In dieser Stufe der Pipeline können alle mit einem Vertex verbunden Informationen, wie Positionen, Farben Normalen und / oder Texturkoordinaten, verändert werden. (vgl. Akenine-Möller et al. 2008, S ) 3

11 Das Ergebnis aus dieser Stufe ist normalerweise die Transformation vom Model Space in den homogenen Clip Space. Da es sich um die erste Stufe in der Pipeline handelt, könnte dieser Schritt theoretisch auch auf die CPU ausgelagert werden. Zu beachten dabei ist, dass in dieser Stufe kein Vertex zerstört oder erzeugt werden kann. Das Ergebnis eines durchlaufenen Vertex kann nicht für einen der folgenden verwendet werden. Der Vorteil dabei ist, dass es ohne Probleme möglich ist, mit mehreren Shader Prozessoren die eingehenden Vertices parallel zu verarbeiten. Seit dem Shader Model 4.0 ist die nächste Stufe der Geometry Shader. In den vorigen Versionen folgte nach einigen Zwischenschritten in der Rendering Pipeline immer gleich der Pixel Shader. (vgl. Akenine-Möller et al. 2008, S ) Geometry Shader Diese optionale Stufe wurde mit DirectX 10 im Jahr 2006 ausgeliefert und nach dem Vertex Shader in die Rendering Pipeline eingegliedert. Als Eingabe wird ein einzelnes Objekt mit all seinen zugehörigen Vertices erwartet. Grundsätzlich zählen Dreiecke, Linien oder Punkte als Eingabeobjekt. Zusätzlich können bei einer Linie die beiden Vertices der angrenzenden Linien und bei einem Dreieck die drei Vertices der angrenzenden Dreiecke mitgegeben werden (siehe Abbildung 2). (vgl. Akenine-Möller et al. 2008, S ) Abbildung 2 - Eingabeobjekte des Geometry Shaders (Akenine-Möller et al. 2008) Die Ausgabe erfolgt in einem Schritt und kann kein, ein oder mehr Objekte (Punkte, Liniensysteme, Dreiecke Triangle Strips) umfassen. Das bedeutet, dass nicht benötigte Objekte gelöscht und zusätzlich erforderliche Objekte erzeugt werden können. Dabei muss der Eingabetyp nicht mit dem Ausgabetyp übereinstimmen. Zum Beispiel könnte so ein Dreieck als Input geliefert und dessen Mittelpunkt als Ergebnis weitergegeben werden. Auch hier befinden sich die ausgegebenen Vertices noch im homogenen Clip Space. (vgl. Akenine- Möller et al. 2008, S ) Der Geometry Shader gibt die Objekte wieder in derselben Reihenfolge weiter, in der sie auch eingegangen sind. Dadurch kann es bei paralleler Verarbeitung zu Performanceeinbußen kommen, da auf ein anderes Ergebnis gewartet und das Eigene zwischengespeichert werden muss. (vgl. Akenine-Möller et al. 2008, S ) Pixel Shader Nach dem Vertex bzw. Geometry Shader folgen einige nicht programmierbare (oder nur konfigurierbare) Stufen in der Rendering Pipeline, zu welchen das Clipping- und die Interpolationsphase gehören. In OpenGL wird der Pixel Shader auch Fragment Shader genannt. Wie der Name schon aussagt, werden hier die einzelnen Pixel verarbeitet. (vgl. Akenine-Möller et al. 2008, S ) 4

12 Als Eingabedaten empfängt der Pixel Shader die Ergebnisse des Vertex bzw. Geometry Shaders. Die Anzahl der übergebenen Daten variiert in den einzelnen Shader Model Versionen und wird fortlaufend mehr. Als Zusatzinformation kann die sichtbare Seite des Dreiecks und die Position abgerufen werden. Der Shader kann dabei immer nur den aktuellen Pixel bearbeiten und das Ergebnis nicht direkt auf die benachbarten Pixel übertragen. Allerdings könnten zum Beispiel die Abweichungen der x und y Werte beobachtet werden, um so eine Steigung zu ermitteln. So können Informationen der benachbarten Pixel (meistens 2 x 2) erhalten und verwendet werden. (vgl. Akenine-Möller et al. 2008, S ) Der Pixel Shader ist in erster Linie dafür verantwortlich, die Farbe und den Tiefenwert für die anschließende Merging Stufe zu setzen. Es ist auch möglich, keinen Output zu erzeugen, worunter allerdings die Performance leidet. Mittlerweile stehen in den neuen Technologien sogenannte Multiple Render Targets zur Verfügung. Beispielsweise muss der Pixel Shader dabei die berechneten Farbwerte nicht in einen Speicher schreiben, sondern kann mehrere Vektoren erzeugen, welche dann in gleichgroße Speicher geschrieben werden. So kann für eine Berechnung von mehreren Bildern ein einziger Rendering Pass verwendet werden. Ohne diese Technik wäre ein Rendering Pass pro Speicher erforderlich gewesen. Außerdem können die Bildergebnisse dann wie Texturen gelesen und verwendet werden. (vgl. Akenine-Möller et al. 2008, S ) Hull und Domain Shader Die neueste Shader Model Version, 5.0, welche mit DirectX 11 ausgeliefert wurde, stellt die neue Tessellation (zu Deutsch: Mosaik) Funktion zur Verfügung. Diese wird in der Rendering Pipeline durch drei neue Stufen realisiert, zu welchen der Hull Shader, die Tessellation Stufe und der Domain Shader zählen. Sie liegen in der eben genannten Reihenfolge zwischen dem Vertex und dem Geometry Shader. (vgl. MSDN Library 2010, Tessellation Overview) Grundsätzlich wird dieses neue Feature dafür verwendet, grobe Flächen bzw. Objekte mit wenigen Dreiecken in detailreichere überzuleiten. Dadurch laufen zuvor detailarme Models über die CPU und den Speicher, welche erst auf der GPU einer Verfeinerung. Unter anderem können so auch verschiedene Levels-of-Detail (LOD) dargestellt werden. (vgl. MSDN Library 2010, Tessellation Overview) Der Hull Shader bekommt als Eingabeparameter sogenannte Control Points aus dem Vertex Shader übergeben. Diese beschreiben die detailarme Fläche, welche in Control Points eines Patches umgewandelt werden. Der Patch definiert die Struktur, welche letztendlich verfeinert werden soll. Außerdem werden parallel dazu für jeden Patch die Tessellation Faktoren und einige andere Werte für den Domain Shader berechnet. Die Tessellation Faktoren bestimmen letztendlich, wie detailliert die Fläche unterteilt werden soll. (vgl. MSDN Library 2010, Tessellation Overview) In der folgenden Tessellation Stufe wird mit Hilfe der zuvor berechneten Faktoren der Patch in die feineren Objekte unterteilt. Die Koordinaten werden dabei normalisiert. Diese Stufe ist nicht frei programmierbar und kann nur geringfügig konfiguriert werden. (vgl. MSDN Library 2010, Tessellation Overview) 5

13 Im Domain Shader werden letztendlich die Vertex Positionen der eingefügten Detailpunkte berechnet. Dieser Prozess wird für jeden ausgegebenen Punkt aus der Tessellation Stufe ausgeführt. Als Eingabeparameter können die Koordinaten aus der Tessellation Stufe und die Control Points und berechneten Werte aus dem Hull Shader herangezogen werden. (vgl. MSDN Library 2010, Tessellation Overview) Zur Veranschaulichung dienen hier vier der von Bayer und Spille vorgestellten Bilder aus dem Artikel DirectX 11 im Bildvergleich von der PC Games Homepage (siehe Abbildung 3, Abbildung 4, Abbildung 5 und Abbildung 6). Abbildung 3 Wireframe ohne Tessellation (Bayer, Spille 2009) Abbildung 4 Wireframe mit Tessellation (Bayer, Spille 2009) Abbildung 5 Haus ohne Tessellation (Bayer, Spille 2009) Abbildung 6 Haus mit Tessellation (Bayer, Spille 2009) 6

14 3 Die Geschichte der Shader Programmierung Der erstmalige Wunsch nach mehr Freiheit in der Grafikprogrammierung trat beim Film Star Wars von George Lucas aus dem Jahr 1977 auf. Wegen des geringen Budgets konnten zwar nicht sämtliche technische Möglichkeiten der damaligen Zeit genutzt werden, allerdings wurde der Film nicht zuletzt aufgrund der Spezialeffekte ein echter Verkaufsschlager. Um in zukünftigen Produktionen die Effekte noch verbessern zu können, gründete George Lucas im Jahre 1980 eine eigene Computer Abteilung in seiner Firma Lucasfilm. (vgl. Bailey, Cunningham 2009, S ) 1983 entstand dann daraus die eigenständige Firma Pixar, welche drei Jahre später von Steve Jobs übernommen wurde. Pixar wollte ein Hardware Gerät für Rendering Aufgaben erzeugen, wofür sie erstmals einen Software Prototypen entwickelten. Dieser wurde bekannt unter dem Namen REYES System und stand für Renders Everything You Ever Saw. (vgl. Bailey, Cunningham 2009, S ) Diese Software zeichnete sich aus, indem sie während des Renderns alle Objekte in extrem kleine Polygone zerlegte, welche daher Mikropolygone genannt wurden. Aus dem REYES System entstand dann letztendlich die Shader Sprache RenderMan. (vgl. Moeller 2007) Sie wurde auch viel später noch in Filmen wie Toy Story oder A Bug s Life (Das große Krabbeln) eingesetzt. (vgl. St-Laurent 2005, S. 4-5) Pixar Mitarbeiter Rob Cook setzte dann mit seiner Arbeit über Shade Trees den ersten wichtigen Meilenstein in der Geschichte der programmierbaren Shader. Ein Beispiel für so einen Baum ist in Abbildung 7 zu sehen. Damit konnten die unterschiedlichsten Effekte erzielt werden, indem einzelne Komponenten programmiert und schließlich an der passenden Stelle der Rendering Pipeline eingesetzt wurden. Diese Technik kam erstmals 1985 im Film Young Sherlock Holmes zum Einsatz. (vgl. Bailey, Cunningham 2009, S ) Abbildung 7 - Beispiel für einen Shade Tree (Akenine-Möller et al. 2008) 1985 veröffentlichte Perlin die Arbeit zu seiner entwickelten Rauschfunktion für Oberflächen. Dabei handelte es sich um eine prozedural ausprogrammierte Textur, mit der die Flächen von Objekten realistischer dargestellt werden konnten. Mit Hilfe einer mathematischen Formel wurde die Oberflächenstruktur zufällig berechnet und es musste keine Bilddatei für die Textur gesendet bzw. geladen werden. Da diese Technik sehr einfach zu adaptieren war, wurde sie sehr schnell von der Industrie aufgenommen und vielfältig eingesetzt. (vgl. Perlin 1999) 7

15 1998 wurde die PixelFlow Shading Sprache von Olano und Lastra entwickelt, welche 30 Frames pro Sekunde schaffte. Einige der darin enthaltenen Ideen beeinflussten die weitere Entwicklung der Grafikhardware. (vgl. Bailey, Cunningham 2009, S ) Da die Shader anfangs nicht direkt in der GPU verdrahtet waren, mussten sie zunächst über mehrere Rendering Passes implementiert werden. Diese Technik kam erstmals 1999 im Computerspiel Quake III: Arena zum Einsatz und war ein großer Erfolg. (vgl. Akenine- Möller et al. 2008, S ) 2000 schuf Peercy et al. die Idee, die RenderMan Shader Sprache in mehrere Schritte zu unterteilen und diese auf der Hardware nacheinander auszuführen. Die GPU war damals allerdings nicht in der Lage, die berechneten Ergebnisse als Texturkoordinaten zu verwenden und die Datentypen konnten nur mit unzureichender Genauigkeit in den Texturen und auch nur im Color Buffer dargestellt werden. Daher wurden frei programmierbare Shader von keiner Hardware unterstützt. (vgl. Akenine-Möller et al. 2008, S ) Im Jahr 2001 wurde eine höhere Sprache für Shader von Proudfoot et al. entwickelt, welche die einzelnen Operationen je nach Sinnhaftigkeit auf CPU und GPU verteilte. (vgl. Bailey, Cunningham 2009, S ) Im selben Jahr wurde die Geforce 3 von NVIDIA veröffentlicht, welche DirectX 8.0 unterstützte und OpenGL Erweiterungen beinhaltete. Auf dieser Grafikkarte standen durch das Shading Model 1.1 erstmals programmierbare Vertex Shader zur Verfügung. Auch Pixel Shader konnten realisiert werden, allerdings durften diese maximal zwölf Anweisungen umfassen. Weiters war die GPU immer noch nicht in der Lage, berechnete Texturkoordinaten oder genauere Datentypen zu verwenden, weshalb die Pixel Shader nicht sehr attraktiv wirkten. Die verwendete Sprache war ähnlich zu der Assembler Sprache und wurde von den Treibern in Mikrocode umgewandelt. (vgl. Akenine-Möller et al. 2008, S ) Im Laufe des Jahres 2001 wurden die GPUs der Grafikkarten weiterentwickelt und DirectX 8.1 erschien mit der Unterstützung von Shader Model 1.2 bis 1.4 (jede Version stand für bestimmte Hardware zur Verfügung). Durch diese Entwicklung wurde die Programmierbarkeit von Pixel Shadern um einen Schritt erweitert, wodurch mehr Anweisungen zur Verfügung standen. (vgl. Akenine-Möller et al. 2008, S ) Gleich im darauffolgenden Jahr kam bereits DirectX 9.0 mit dem neuen Shader Model 2.0 heraus und auch OpenGL wurde wiederum erweitert. Dadurch wurden auch die Pixel Shader vollständig frei programmierbar. Diese unterstützten nun 16-Bit Gleitkommawerte und ermöglichten die Berechnung der Texturkoordinaten in der Rendering Pipeline. (vgl. Akenine-Möller et al. 2008, S ) Allerdings wurden Shader bis zu diesem Zeitpunkt noch immer in einer Sprache ähnlich zu Assembler geschrieben. Dadurch stellte es einen hohen Aufwand dar, sich um sämtliche Register und Variableninitialisierungen zu kümmern. Dies wurde weiters erschwert, da je nach Hardware eine andere Anzahl an Registern und Variablen zur Verfügung stand und einige Befehle unterschiedlich interpretiert wurden. (vgl. St-Laurent 2005, S. 4-5) 8

16 Schließlich war die Hardware aber soweit entwickelt, dass es endlich möglich und auch notwendig wurde, das durch die Shade Trees von Rob Cook vorgestellte System zu verwirklichen. Daher wurden die Shader Sprachen C for Graphics (Cg) von NVIDIA und High Level Shader Language (HLSL) von Microsoft als Teil von Direct3D geboren. Danach erst folgte die vom OpenGL Architecture Review Board (ARB) entwickelte OpenGL Shader Language (GLSL) (vgl. Bailey, Cunningham 2009, S ) Alle diese Sprachen waren abgeleitet von der Programmiersprache C und der Shader Sprache RenderMan. (vgl. Akenine- Möller et al. 2008, S ) 2004 wurde Shader Model 3.0 veröffentlicht, welches einige Neuerungen und Erweiterung gegenüber der Version 2 bot (siehe Tabelle 1). Die Konsolen XBox 360 von Microsoft Ende 2005 und Playstation 3 von Sony im Jahr 2006 wurden beide mit Shader 3.0 GPUs ausgeliefert. Die Wii Konsole von Nintendo hingegen kam Ende 2006 mit einer GPU auf den Markt, welche noch über eine Fixed Function Pipeline verfügte. Auch die Mobiltelefone der damaligen Zeit wurden bereits mit programmierbaren Shadern ausgestattet. (vgl. Akenine- Möller et al. 2008, S ) Shader Model 4.0 erschien im Jahr 2007, welches in DirectX 10.0 und einer Erweiterung von OpenGL ausgeliefert wurde. Wesentliche Neuerungen waren der Geometry Shader und der Stream Output. Außerdem wurden Integer Werte eingeführt und sämtliche Beschränkungen der Instruktionen- und Registerzahl weiter hinauf gesetzt (siehe Tabelle 1). Ab dieser Version gab es keine Möglichkeit mehr benutzerdefinierten Assembler Code zu schreiben, sondern es mussten ausnahmslos High Level Shader Sprachen wie HLSL oder GLSL verwendet werden. (vgl. Akenine-Möller et al. 2008, S ) Shader Model Vergleich SM 2.0 / 2.X SM 3.0 SM 4.0 Veröffentlicht DX 9.0, 2002 DX 9.0c, 2004 DX 10, 2007 VS InstructionSlots VS Max. Steps Executed PS Instruction Slots PS Max. Steps Executed Temp. Registers VS Constant Registers x 4096 PS Constant Registers x 4096 Flow Control, Prediction Optional Ja Ja VS Textures Keine x 512 PS Textures x 512 Integer Unterstützung Nein Nein Ja VS Input Registers Interpolator Registers / 32 PS Output Registers Tabelle 1 - Shader Model Vergleich (vgl. Akenine-Möller et al. 2008, S. 38) 9

17 DirectX 11 führte schließlich das Shader Model 5.0 ein, was einige neue Möglichkeiten mit sich brachte. Ein wesentlicher Bestandteil ist der Compute Shader, welcher die parallel arbeitenden Prozessoren der Grafikkarte für allgemeine Berechnungen zur Verfügung stellt. Er ist ein eigenständiger Teil, welcher nicht in die Stufen der Rendering Pipeline integriert ist. Der zweite wichtige Punkt ist das Tessellation Feature, durch welches Objekte in verschiedenen Levels-of-Detail gerendert werden können. Außerdem ist es nun möglich, mit mehreren Threads zu arbeiten und objektorientierte Ansätze wurden in die Sprache integriert. (vgl. MSDN Library 2010, Direct3D 11 Features) 10

18 4 Implementierung von Shadern 4.1 Vorraussetzungen Eine der Hauptaufgaben von Shadern ist die Bestimmung der Farbe jedes einzelnen Vertex bzw. Pixel. Daher muss bei der Entwicklung von Shadern auf jeden Fall das Wissen über Beleuchtung und Texturing angewandt werden. Dieser Teil der Arbeit soll daher nochmals eine kurze Zusammenfassung der beiden Themen liefern Beleuchtung Für die Lichtberechnung wird in der Computergrafik die ambient-diffuse-specular (ADS) Lighting Funktion verwendet. (vgl. Bailey, Cunningham 2009, S ) Dabei setzt sich das Licht aus den drei im Namen enthaltenen Komponenten zusammen: (vgl. St-Laurent 2005, S ) Ambient Light (Ambientes Licht): Dieses Licht hat die Aufgabe für eine bestimmte Grundhelligkeit zu sorgen, wobei es sich auf jeden Farbwert eines Vertex bzw. Pixel gleichmäßig auswirkt. Diffuse Light (Diffuses Licht): Diffuses Licht wird nach dem Auftreffen in alle Richtungen gestreut. Die wiedergegebene Lichtintensität ist in diesem Fall auch unabhängig vom betrachteten Blickwinkel. Specular Light (Spekulares Licht): Diese Komponente kommt bei Oberflächen mit sogenannten Glanzpunkten zum Einsatz. In diesem Fall ist die Berechnung abhängig vom Einfallswinkel des Lichts und des betrachteten Blickwinkels. Die Summe aus all diesen Komponenten ergibt dann das tatsächliche Licht. Allerdings muss zusätzlich noch die Art des Lichts beachtet werden, wobei wiederum drei Möglichkeiten zur Auswahl stehen: (vgl. Theuerjahr 2007, S ) Directional Light: Direktionales Licht hat lediglich einen Richtungsvektor, erstreckt sich über eine unendliche Reichweite und besitzt keine genaue Positionierung im Raum, wodurch alle Lichtstrahlen als parallel angesehen werden. Eine typische Anwendung dieser Lichtart stellt die Simulation unserer Sonne dar. Point Light (Positional Light): Diese Art strahlt Licht in alle Richtungen aus, ist an einer bestimmten Stelle im Raum positioniert und hat normalerweise eine endliche Reichweite. Beispiele für solche Lichtquellen wären etwa eine Fackel oder eine Glühbirne. Spot Light: Wie auch das Positional Light ist hier eine Positionierung und eine endliche Reichweite des Lichts gegeben. Allerdings ist die Richtung auf einen definierten Strahlungswinkel begrenzt, wobei die Lichtintensität von innen nach außen abnimmt. Diese Art von Licht kann zum Beispiel für den Scheinwerfer eines Autos verwendet werden. 11

19 Das Wissen über die Lichtberechnung kann schließlich für das Shading verwendet werden, wodurch sich die Farben der einzelnen Pixel eines Objektes ergeben. An dieser Stelle sollen nochmals Gouraud Shading (Smooth Shading) und Phong Shading kurz vorgestellt werden. (vgl. Bailey, Cunningham 2009, S ) Gouraud Shading: Bei dieser Form des Shadings werden sämtliche Lichtberechnungen bereits im Vertex Shader vorgenommen und die resultierende Farbe wird dann im Pixel Shader nur mehr ausgegeben. Phong Shading: Im Unterschied zu Gouraud Shading wird hier die Lichtberechnung erst im Pixel Shader ausgeführt und das Farbergebnis dort auch ausgegeben Texturing Mit Hilfe von Texturen werden heute vielerlei Effekte erzielt und sie können als Träger unterschiedlicher Informationen dienen. Ihr hauptsächlicher Verwendungszweck ist allerdings die Zuweisung von Farben zu den einzelnen Pixel eines Objektes. (vgl. Bailey, Cunningham 2009, S ) Texturen sind im Grunde ganz gewöhnliche Bilddateien, welche ein-, zwei- oder dreidimensionale Daten enthalten. Um die einzelnen Farbpunkte des Bildes nun richtig mit dem Objekt zu verbinden, müssen diese über Texturkoordinaten zugewiesen werden. Diese Texturkoordinaten gehen von Null bis Eins, wobei sich die Punkte (0, 0) links oben und (1, 1) rechts unten im Bild befinden. (vgl. Theuerjahr 2007, S ) 4.2 Sprachen Gemeinsamkeiten Ein wesentlicher Unterschied zu normalen Programmiersprachen besteht darin, dass Shader für Grafikkarten geschrieben werden und dort auch ablaufen. Für dieses Umfeld sind andere Vorraussetzungen gegeben, als sie bei der Ausführung auf der CPU vorliegen. Die Berechnungen sind auf grafische Problemstellungen ausgelegt. Für bestimmte Aufgaben haben GPUs daher erweiterte Möglichkeiten und in anderen Bereichen sind sie wiederum eingeschränkt. Eines der Hauptmerkmale auf der Grafikkarte ist die in Stufen eingeteilte Rendering Pipeline, welche auch eingehalten werden muss. Die Aufgabe jeder Stufe ist es, die Daten einzulesen, eventuell zu verändern und schließlich wieder weiterzugeben. Auftretende Fehler innerhalb dieses Ablaufes können nicht einfach abgefangen und behandelt werden. Sollte tatsächlich eine Ausnahme auftreten, so muss der gesamte Durchgang abgebrochen und neu begonnen werden. (vgl. Bailey, Cunningham 2009, S ) Da sowohl HLSL als auch GLSL sehr ähnlich zu einer iterativen Sprache wie C sind, können viele der Sprachkonstrukte, Schlüsselwörter und Datentypen hier wiedergefunden werden. Jedoch besitzen Shader Sprachen eine erweiterte Auswahl an Operatoren und Funktionen für grafikspezifische Berechnungen, während auf andere, in diesem Kontext nicht notwendige, Befehle verzichtet wurde. Außerdem können sämtliche Funktionsparameter nicht nur konsumiert sondern auch wieder zurückgegeben werden. (vgl. Bailey, Cunningham 2009, S ) Aufgrund all dieser Gemeinsamkeiten kann ein Skript einer Sprache sehr leicht in das einer anderen umgeschrieben werden. (vgl. Bailey, Cunningham 2009, S ) 12

20 4.2.2 HLSL Die High Level Shader Language wurde von Microsoft entwickelt und ist im DirectX Software Development Kit (SDK) eingebunden. (vgl. St-Laurent 2005, S. 3-22) Die unterschiedlichen Versionen des Shader Models gaben der Hardware immer bestimmte Mindestanforderungen vor, damit diese unter der jeweiligen DirectX Version arbeiten konnte (z.b.: vorgegebene Anzahl an Registern). Da die HLSL Sprache fix mit dem DirectX SDK verknüpft ist, kann diese auch nur unter Windows Betriebssystem ausgeführt werden. (vgl. Lovesey 2005) Ein HLSL Shader wird von der Applikation zunächst an das DirectX SDK weitergeleitet, welches für die Übersetzung des Shaders in binäre Daten verantwortlich ist. Schließlich werden diese Daten an den Grafiktreiber gesendet, welcher sie letztendlich in eine für die Grafikkarte verständliche Form umwandelt. Dort wartet das Shaderprogramm dann auf seine Ausführung, was über einen Befehl in der Programmierschnittstelle geschieht. Dadurch wird der Shader in die Fixed Function Pipeline integriert und solange verwendet, bis seine Deaktivierung erfolgt. (vgl. Lovesey 2005) GLSL Die OpenGL Shader Language gehört zur OpenGL API und verfolgt in erste Linie das Ziel der Hardwareunabhängigkeit. Die Treiber der Grafikkarten sind für diese Unabhängigkeit zuständig, da sie die Shader Programme für die jeweilige Grafikkarte übersetzen. (vgl. Bailey, Cunningham 2009, S ) Daher werden den Grafikkartenherstellern lediglich die Spezifikationen der GLSL Versionen zur Verfügung gestellt, um ihnen die Verwaltung der Compiler Programme selbst überlassen zu können. Neue verfügbare Funktionalitäten müssen dann lediglich in den Compilern der Hersteller geändert werden, ohne zusätzliche Bibliotheken einbinden zu müssen. (vgl. Lovesey 2005) Wie bereits in Kapitel 3 erwähnt, wurde die GLSL Sprache erst kurze Zeit nach HLSL veröffentlicht. Auslöser für diese Verspätung war, dass die Mitglieder der ARB Gruppe über jedes einzelne Feature der Sprache abstimmte. Dieses Prozedere dauerte aufgrund zahlreicher Unstimmigkeiten länger, wodurch diese Verzögerung zustande kam. (vgl. Lovesey 2005) Im Gegensatz zu HLSL werden die Shader direkt an die OpenGL Treiber gesendet und dort kompiliert. Dabei entstehen für die unterschiedlichen Shader jeweils eigene Objekte. Diese werden anschließend zu einem GLSL Programm zusammengefügt und in der Rendering Pipeline abgearbeitet. Ein weiterer Unterschied zu HLSL ist die Verwaltung der Ein- und Ausgabeparameter der einzelnen Shader. Da GLSL eng mit der OpenGL Pipeline verknüpft ist, stehen diese in den Funktionen zur Verfügung, ohne eine eigene Struktur schreiben und diese im Funktionskopf angeben zu müssen. (vgl. Lovesey 2005) Andere Eine der bekanntesten Sprachen neben HLSL und GLSL ist Cg von NVIDIA. Sie wurde etwa zeitgleich mit den beiden Konkurrenzprodukten veröffentlicht. (vgl. Akenine-Möller et al. 2008, S ) Eine Open Source Variante stellt die Sprache Sh dar, welche auf einer C++ Bibliothek basiert. (vgl. Akenine-Möller et al. 2008, S ) 13

21 Als Hilfestellung für Personen mit nur wenig Programmierkenntnissen existieren auch noch Werkzeuge zur Erstellung von Shadern. Damit können vorgefertigte Shader Effekte abgeändert und über eine grafische Darstellung miteinander verbunden werden. Diese werden dann von der Applikation in eine gewohnte Shader Sprache wie GLSL oder HLSL umgewandelt. Ein Beispiel für so ein Werkzeug ist Mental Mill von NVIDIA. (vgl. Akenine- Möller et al. 2008, S ) 4.3 Debugging Ein wichtiger Punkt bei der Entwicklung von Software ist das Debugging. Mit Hilfe der heutigen Entwicklungsumgebungen stellt das kaum noch ein Problem dar. Zum Beispiel können mit Visual Studio sehr einfach Haltepunkte gesetzt und der aktuelle Status der Variablen ausgelesen werden. Da der Shader jedoch auf der Grafikkarte ausgeführt wird, ist das Debugging in diesem Fall etwas problematischer. (vgl. St-Laurent 2005, S ) Um Fehler im Programm auszuschließen, kann mit Hilfe des Frameworks eine Auflistung aller kompilierten Effekte und Shader erzeugt werden. Allerdings sind hierfür gute Kenntnisse der Assembler Befehle des jeweiligen Shaders ausschlaggebend, damit eventuelle Fehler aufgedeckt werden können. Eine weitere Möglichkeit ist es, immer nur einzelne Codeteile des Shaders auszuführen und so zu testen. Dabei kann es von Nutzen sein, einige Vektoren oder Objekte in einer bestimmten Farbe darzustellen, um deren Korrektheit überprüfen zu können. (vgl. St-Laurent 2005, S ) Die oben erwähnten Ansätze sind allesamt nicht automatisiert und geben keine Auskunft über die Inhalte irgendwelcher Speicher zu einem bestimmten Zeitpunkt. (vgl. St-Laurent 2005, S ) Als Hilfsmittel für solch ein Debugging werden im Folgenden nun PIX, NVIDIA Shader Debugger und ATI PerfStudio vorgestellt. Dabei soll jeweils ein kurzer Einblick in die Einsatzöglichkeiten und ein Einstieg in die Handhabung der wichtigsten Funktionalitäten gegeben werden PIX 9.27 PIX ist ein Tool für das Debugging und die Analyse jeglicher Direct3D Anwendungen. Unterstützt werden die DirectX Versionen 9.0, 10.0, 10.1 und 11.0 Es ist damit möglich, sowohl Pixel als auch Vertex Shader zu debuggen. Mit PIX kann auf verschiedene Statistiken jedes Frames und auf Aufzeichnungen zu jedem Zeichenbefehl zugegriffen werden. Weiters können von Frames erzeugte Bilder über ein Werkzeug miteinander verglichen werden. (vgl. Microsoft Corporation 2009, PIX: User s Guide) Gearbeitet wird in dieser Applikation mit Experimenten (äquivalent zu Projekten). Über das Menü File besteht die Möglichkeit ein neues Experiment anzulegen. In dem sich öffnenden Fenster muss zunächst der Pfad zur gewünschten Grafikanwendung eingegeben werden. Darunter stehen vier Optionen zur Auswahl, die bestimmen, welche Daten gesammelt werden sollen. Über den Button More Options erscheint eine erweiterte Ansicht, in welcher diese Optionen genauer spezifiziert werden können. Um nun einen Pixel oder Vertex Shader zu debuggen, reicht die Einstellung single-frame capture allerdings aus. Schließlich kann das Experiment über eine Schaltfläche rechts unten gestartet werden. 14

22 Daraufhin wird die Grafikanwendung geöffnet. Nun muss mit der Taste F12 an einer gewünschten Stelle ein Frame erfasst werden. Danach wird die Anwendung nicht mehr benötigt und kann geschlossen werden. Dadurch erscheint das Fenster Run mit vier verschiedenen Unterfenstern. Das Erste ganz oben ist eine Timeline mit der gesamten Laufzeit der Anwendung. Darunter befindet sich das Fenster Objects, welches eine Auflistung aller erzeugten Objekte beinhaltet. Und schließlich sind ganz unten die Ansichten Events und Details zu sehen. Die Abbildung 8 hilft dabei, sich zwischen den einzelnen Bereichen und Fenstern zurechtzufinden. Abbildung 8 PIX 9.27 Um nun debuggen zu können, muss aus dem Fenster Events ein Zeichenbefehl ausgewählt werden. Daraufhin kann im Bereich Details über die Registerkarte Render das Objekt des gewählten Befehls gerendert angezeigt werden. Durch einen Rechtsklick auf einen beliebigen Punkt des Objektes und anschließender Wahl von Debug this Pixel, erscheint die Registerkarte Debugger mit Details zu dem Pixel und den zugehörigen Vertices. Durch Klick auf Debug Pixel bzw. Debug Vertex erfolgt dann letztendlich der Aufruf zum Debugging. Standardmäßig wird zu Beginn des Debuggings der Programmcode in der HLSL Shader Sprache dargestellt. Über die Schaltfläche Disassembly kann aber auch auf den Assembler Code gewechselt werden. Ein gelber Pfeil im linken Seitenrand zeigt die aktuelle Zeile an. Dort können auch durch einfache Klicks beliebig Haltepunkte gesetzt werden. Diverse Schaltflächen im oberen Bereich dienen zur Navigation durch den Quellcode. Im Codefenster werden außerdem die Schlüsselwörter durch blaue und Kommentare durch grüne Farbe hervorgehoben. Die einzelnen Register und Variablen können über eine Auflistung im unteren Teil des Fensters eingesehen werden. 15

23 4.3.2 NVIDIA Shader Debugger 2.5 Der NVIDIA Shader Debugger ist kein eigenständiges Programm, sondern ist als Plugin in die NVIDIA FX Composer Applikation integriert, welche ein umfangreicheres Tool zur Entwicklung von Shadern darstellt. Wurde das Plugin für den Debugger installiert, so erscheint in der Menüleiste ein neuer Eintrag namens Debug. Es handelt sich bei der hier besprochenen Ausgabe um die Version 2.5. Unterstützt werden die Shader Sprachen HLSL und Cg, allerdings ist die Anwendung nur auf Pixel Shader ausgelegt. Zu den empfohlenen Systemvorraussetzungen zählen zwei Gigabyte Arbeitsspeicher, ein zwei Gigaherz Dual-Core Prozessor und ein eine äquivalente Grafikkarte der Geforce 6 Serie oder besser. (vgl. NVIDIA Corporation 2008, NVIDIA Shader Debugger: User s Guide) Im Folgenden soll ein Überblick der grundlegenden Handgriffe gegeben werden. Abbildung 9 ist dabei eine Hilfestellung und zeigt das gesamte Fenster der Applikation mit Beschriftung der einzelnen Komponenten. Der Debugger ist grundsätzlich in die Source View, welche den Editor verkörpert, und das Debugger Panel unterteilt. Letzteres hat wiederum viele kleine Unterfenster und ansichten, über welche beispielsweise Variablen eingesehen und Fehler beobachtet werden können. Gearbeitet wird in der Applikation mit eigenen FX Composer Projekten. Nach dem Anlegen eines neuen Projektes kann über die Toolbar oben ein Effekt hinzugefügt werden. Dabei besteht die Auswahl zwischen einem bereits vorhanden File oder einem neuen HLSL bzw. Cg Effekt. Fällt die Entscheidung auf eine Neuanlage, so kann aus einer Palette an vorgefertigten Shadern gewählt werden. Weiters stehen in der Toolbar eine Kugel, die berühmte Teekanne, ein Ring und eine ebene Fläche als Modelvorlage zur Verfügung. Über das Menü File und anschließender Wahl von Import können auch benutzerdefinierte Models in das Projekt geladen werden. Nachdem das Model geladen wurde, kann dieses rechts unten im Render Panel begutachtet werden. Im linken Bereich des Programmes besteht auch die Möglichkeit Materialien mit dazupassenden Texturen zu erzeugen, welche schließlich mit Drag & Drop auf das Objekt gelegt werden können. Schließlich wird über das Menü Debug bzw. einen Rechtsklick in den Editor und danach Start Debugging, der Debug Vorgang gestartet. Der Prozess springt dann automatisch auf die letzte Zeile des Pixel Shaders. Die gerade betrachtete Zeile wird im Editor als gelb hinterlegt dargestellt (auch in Abbildung 9 zu erkennen). Für das Navigieren durch den Programmcode stehen unter der Toolbar verschiedene Buttons zur Verfügung, mit denen beispielsweise die nächste bzw. vorherige Zeile oder die Zeile, in der sich der Cursor befindet, angesteuert werden kann. Im Debugger Panel sind unter der Registerkarte Auto die Inhalte der zurzeit vom Shader verwendeten Variablen zu sehen. Eine Auflistung sämtlicher definierter Felder ist in der Registerkarte Symbols zu finden. Je nachdem welche Variable markiert wird, legt das Render Panel auch die entsprechenden Werte auf das Objekt. Außerdem kann während des Debuggings im Render Panel die Maus über das Objekt bewegt werden, wodurch die Koordinaten und Farbwerte bei der jeweiligen Mausposition zu entnehmen sind. Mit Hilfe der dort positionierten Schaltfläche Debug a Pixel und anschließendem Klick auf einen Punkt des Objektes, wird speziell dieser ausgewählte Pixel vom Debugger übernommen. 16

24 Ein weiteres nützliches Hilfsmittel ist die Registerkarte Watch im Debugger Panel. Hier können Anweisungen aus dem Programmcode hineinkopiert werden, dessen Ergebnis daneben ausgegeben und im Render Panel auf dem Objekt angezeigt wird. Diese Befehle können dort auch direkt abgeändert werden, ohne auf den eigentlichen Quellcode zugreifen zu müssen und die neuen Ergebnisse erscheinen wieder sofort daneben auf. Abbildung 9 - NVIDIA Shader Debugger ATI PerfStudio 2.2 Das ATI PerfStudio in der Version 2.2 basiert darauf, komplette Applikationen zu debuggen, weshalb hier nicht bestimmte Shader Sprachen sondern APIs unterstützt werden. Dazu zählen die DirectX Versionen 10.0, 10.1 und 11.0 und OpenGL 3.0. Ein weiteres Feature ist, dass die zu prüfende Grafikanwendung lokal aber auch auf einem anderen Rechner liegen kann. Daher werden die Systemvorraussetzungen für den Client und den Server unterschieden. Beim Server ist eine Grafikkarte der Serie ATI Radeon HD 2000 oder besser die entscheidende Komponente. Für den Client wird das Microsoft.NET Framework 3.5 gefordert. (vgl. AMD 2009, PS2ClientHelp) Im Folgenden werden die grundlegenden Handgriffe für das Debugging einer Grafikanwendung beschrieben, wobei hier lediglich die lokale Variante und kein entfernter Server verwendet wird. Der erste Schritt nach dem Start des PerfStudio Clients ist das Verbinden zur Applikation. Dies geschieht über den Button ganz links in der Toolbar, welcher durch ein kleines Computer Icon visualisiert wird. Der erscheinende Dialog enthält standardmäßig die Einstellungen Server Host localhost und Port 80, welche keine Änderung erfordern. Im Feld Application muss der Pfad zur gewünschten Grafikanwendung gesetzt sein. Anschließend wird durch Klick auf Connect bestätigt, wodurch die erforderlichen Dienste und die Applikation gestartet werden. 17

25 Das Werkzeug für das Debugging wird als Frame Analyzer bezeichnet. Dieser unterteilt sich weiters in den Frame Debugger, den Frame Profiler und das API Trace Modul. Diese können über die Schaltflächen in der Toolbar aufgerufen werden, sobald die laufende Grafikanwendung pausiert wird. Die Aufgabe des Frame Profilers ist es, den Verbrauch der Hardware Ressourcen aufzuzeigen und hilft dabei die teuren Zeichenbefehle zu finden, um sie zu optimieren. Über das API Trace Modul werden sämtlich API Aufrufe der Grafikanwendung innerhalb eines Frames aufgelistet. (vgl. AMD 2009, PS2ClientHelp) Der Frame Debugger ist das eigentliche Tool für das Debugging und wird daher nun weiter erläutert. Aufgerufen wird er nach Pausierung der Applikation über den dritten Button von rechts in der Toolbar. Zur Hilfe sind in Abbildung 10 die einzelnen Bereiche des Frame Debuggers beschriftet. Abbildung 10 - ATI PerfStudio 2.2 Zunächst werden im Command Tree auf der linken Seite die einzelnen Stufen der Pipeline aufgelistet. Bei jeder dieser Stufen stehen unterschiedliche Listings zur Auswahl, welche über einen Klick aufgerufen werden können. Der entsprechend Inhalt wird dann rechts daneben im Content Pane dargestellt. Im Falle eines Shader Programmes wird die Syntax des Programmcodes farblich dargestellt. Unter Zuhilfenahme des Draw Call Sliders am unteren Rand des Fensters kann zwischen den einzelnen Zeichenbefehlen gewählt werden. Falls es darstellbare Inhalte gibt, scheinen diese im rechten Teil des Content Panes auf (in Abbildung 10 die beiden Dreiecke). 18

26 Wurde ein Zeichenbefehl mit Renderergebnissen ausgewählt, kann mit dem Hammersymbol oben links im Content Pane der Debug Vorgang für einen Shader gestartet und beendet werden. Allerdings sind, wie auch beim NVIDIA Shader Debugger, zurzeit nur Pixel Shader unterstützt. Weiters kann mit den Navigationsschaltflächen zu der vorherigen bzw. nächsten Zeile und zum vorherigen bzw. nächsten Haltepunkt gesprungen werden. Außerdem besteht die Möglichkeit sich zwischen der Shader Sprache und dem Assembler Code zu entscheiden. Links im grauen Bereich neben dem Programmcode können über einen Mausklick Haltepunkte gesetzt werden und ein kleines grünes Dreieck markiert die aktuelle Zeile. Um die momentanen Inhalte der Variablen einzusehen, steht eine Tabelle mit einer Auflistung aller Felder zwischen der Codeansicht und dem Draw Call Slider zur Verfügung. 19

27 5 Erzielbare Effekte Hier sollen einige der wichtigsten Shader Effekte vorgestellt werden. Dafür wurde die HLSL Sprache in Verbindung mit XNA von Microsoft und Visual Studio 2008 als Entwicklungsumgebung eingesetzt. Es wurde in den jeweiligen Beispielen darauf geachtet, immer die kleinst mögliche Shader Version zu verwenden, um eine breite Masse an Grafikkarten ansprechen zu können. Sämtliche Texturen und Models, welche in den Beispielen dieses Kapitel verwendet werden, stammen aus dem DirectX SDK. 5.1 Shader Grundgerüst Dieser Abschnitt zeigt die erforderlichen Elemente des Grundgerüstes eines Shader Programmes. In XNA können Shader mit Hilfe von Effektdateien realisiert werden. Sie tragen die Dateiendung.fx und können mit dem Befehl unterhalb eingebunden werden. Content.Load<Effect>("EffectFileName") Zu Beginn werden für die Transformation der Vertex Positionen die Variablen der World, View und Projeciton Matrix definiert. Die Werte für diese Matrizen müssen von der Applikation aus gesetzt werden. float4x4 World; float4x4 View; float4x4 Projection; Danach folgen die Strukturen für die Eingabeparameter des Vertex Shaders und für die Ausgabeparameter des Vertex Shaders bzw. Eingabeparameter des Pixel Shaders. Diese müssen zumindest die Positionswerte beinhalten. struct VertexShaderInput { float4 Position : POSITION0; }; struct VertexShaderOutput { float4 Position : POSITION0; }; Die Funktion für den Vertex Shader bekommt die VertexShaderInput Struktur als Eingabe und gibt die VertexShaderOutput Struktur zurück. Innerhalb der Funktion wird die Position mit Hilfe der drei zu Beginn definierten Matrizen auf die korrekte Position transformiert. VertexShaderOutput VertexShaderFunction(VertexShaderInput input) { VertexShaderOutput output; float4 worldposition = mul(input.position, World); float4 viewposition = mul(worldposition, View); output.position = mul(viewposition, Projection); } return output; 20

28 Der Pixel Shader erhält die VertexShaderOutput Struktur als Übergabeparameter und liefert die Farbe des Pixels zurück. Dabei wird im Beispiel unten die Farbe Rot ausgegeben. float4 PixelShaderFunction(VertexShaderOutput input) : COLOR0 { return float4(1, 0, 0, 1); } Schließlich muss noch festgelegt werden, welche Funktionen für den Vertex und Pixel Shader verwendet und in welcher Version diese kompiliert werden sollen. Dazu wird zunächst eine Technik definiert, für die ein beliebiger Name vergeben werden kann. So können innerhalb einer Effektdatei mehrere Techniken eingesetzt werden. Dann muss noch mindestens ein Pass festgelegt werden. Es besteht auch die Möglichkeit mehrere Passes innerhalb einer Technik zu definieren. Diese würden dann nach der Reihe abgearbeitet werden. Letztendlich erfolgt in dem Pass die Zuordnung der Funktionen zu den Shadern. Die Schlüsselwörter vs_1_1 und ps_1_1 geben an, dass sowohl für Vertex als auch für Pixel Shader die Version 1.1 eingesetzt werden soll. Es ist von Vorteil immer die niedrigste mögliche Version anzuwenden, um möglichst viele Grafikkarten ansprechen zu können. technique Technique1 { pass Pass1 { VertexShader = compile vs_1_1 VertexShaderFunction(); PixelShader = compile ps_1_1 PixelShaderFunction(); } } 5.2 Shading (Lighting) Die hier besprochenen Beleuchtungsberechnungen sind essentielle Effekte und werden bei allen anderen in diesem Kapitel besprochenen Techniken ebenfalls eingesetzt. Im Folgenden wird Shading unter Zuhilfenahme der berühmten Teekanne veranschaulicht. Schritt für Schritt werden dabei die einzelnen Lichtkomponenten hinzugefügt. Den Beginn macht das ambiente Licht, für welches erstmal die notwendigen Variablen definiert werden müssen. Dazu zählen die Farbe des Lichtes, dessen Leuchtkraft und die Farbe des Materials. Zur Vereinfachung wird später für alle Lichtkomponenten dieselbe Materialdefinition verwendet. float4 AmbientLightColor = float4(1, 1, 1, 1); float AmbientLightPower = 0.1; float4 MaterialColor = float4(1,1,1,1); Das ambiente Licht kann dann mit einer kurzen Anweisung im Pixel Shader berechnet und ausgegeben werden. Das Ergebnis ist in Abbildung 11 zu sehen. return AmbientLightColor * AmbientLightPower * MaterialColor; 21

29 Als nächstes folgt das diffuse Licht, für welches einige neue Variablen benötigt werden. Da wäre zunächst die transponierte Inverse der World Matrix um die Normal Vektoren transformieren zu können. Dann sind die Farbe des Lichtes und die Leuchtkraft erforderlich. Und zuletzt folgt noch eine direktionale Lichtquelle. float4x4 WorldInversedTransposed; float4 DiffuseLightColor = float4(1, 1, 1, 1); float DiffuseLightPower = 0.8; float3 DiffuseLightDirection = float3(1, 1, 1); Auch die Struktur für die Eingabeparameter des Vertex Shaders muss erweitert werden, da nun auch die Normale mitgegeben werden muss. Die Berechnung des diffusen Lichtes passiert gleich im Vertex Shader und erfolgt damit nach Gouraud Shading. Der erste Schritt ist die Transformation der Normalen und der Lichtvektor muss normalisiert werden. Mit Hilfe des Dot-Produktes errechnet sich die restliche Intensität des reflektierten Lichts. Die Ausgabestruktur wurde um das DiffuseColor Feld erweitert, da darin die berechnete diffuse Farbe gespeichert wird. float4 normal = normalize(mul(input.normal, WorldInversedTransposed)); DiffuseLightDirection = normalize(diffuselightdirection); float diffuselightattenuation = saturate(dot(normal,diffuselightdirection)); output.diffusecolor = saturate( DiffuseLightColor * DiffuseLightPower * diffuselightattenuation); Der Pixel Shader muss nur mehr das ambiente und diffuse Licht aufsummieren und mit der Materialfarbe multiplizieren, um die gewünschte Farbe zu erhalten. Abbildung 12 zeigt das Ergebnis. return saturate((ambientlightcolor * AmbientLightPower + input.diffusecolor) * MaterialColor); Nun wird noch das spekuläre Licht in die Beleuchtungsszene eingebaut. Dafür ist es notwendig, die Position der Kamera durch Angabe eines Richtungsvektors zu kennen. Wie auch bei den beiden anderen Komponenten müssen die Leuchtkraft und Farbe des Lichtes bekannt sein. Als Lichtrichtung wird die des diffusen Lichtes wiederverwendet. Und dann erfolgt noch die Definition eines Glanzwertes, welcher angibt, wie ausgeprägt der Glanzpunkt auf dem Objekt sein soll. float3 CameraViewVector = (0, 0, 1); float4 SpecularLightColor = float4(1, 1, 1, 1); float SpecularLightPower = 3; float Shininess = 150; 22

30 Für die Berechnung muss etwas mehr als bei den vorherigen Lichtarten getan werden. Zunächst muss der Reflektionsvektor der Oberfläche mit Hilfe der Normalen und des Lichtvektors ermittelt werden. Dann kann über das Dot-Produkt des Kameravektors und des soeben erhaltenen Reflektionsvektors die zurückgeworfene Lichtintensität errechnet werden. Schließlich muss die spekuläre Farbe noch ausmultipliziert werden. Dabei kommen wie gewohnt die Leuchtkraft und Lichtfarbe zum Einsatz. Um den Glanzpunkt zu berechnen, wird die zuvor berechnete Lichtintensität mit dem Glanzwert als Exponent potenziert. Und zum Schluss muss noch die Länge der diffusen Farbe miteinbezogen werden, damit nur die mit ausreichend diffusem Licht bestrahlten Flächen glänzen. float3 reflectionvector = normalize( 2 * dot(diffuselightdirection, normal) * normal - DiffuseLightDirection); float specularlightattenuation = dot(reflectionvector,normalize(cameraviewvector)); float4 specularcolor = SpecularLightPower * SpecularLightColor * max(pow(specularlightattenuation, Shininess), 0) * length(diffusecolor); Um dann noch die Gesamtfarbe zu erhalten, muss die spekuläre Farbe zu den beiden anderen berechneten Lichtfarben addiert und mit der Materialfarbe multipliziert werden. Dabei wurden wieder alle Berechnungen im Vertex Shader getätigt, was dem Gouraud Shading entspricht. In Abbildung 13 ist das zu beobachten. Werden die Berechnungen in den Pixel Shader verschoben, so erfolgt ein Beleuchtungseffekt nach Phong Shading, welcher in Abbildung 14 zu sehen ist. Bei der Implementierung ist allerdings zu beachten, dass die Normale trotzdem im Vertex Shader transformiert wird und diese danach über die Ausgabestruktur an den Pixel Shader übergeben werden muss. Außerdem sind einige Berechnungsbefehle (wie zum Beispiel max oder pow) in der Pixel Shader Version 1.1 nicht enthalten, weshalb zumindest auf 2.0 erhöht werden muss. Abbildung 11 - Ambient Light Abbildung 12 - Diffuse Light (Gouraud) Abbildung 13 Specular Light Gouraud Shading Abbildung 14 Specular Light Phong Shading 23

31 5.3 Classic Texture Mapping Bei diesem Effekt geht es darum, zweidimensionale Bilder auf dreidimensionale Objekte zu legen, um ihnen ein Aussehen zu verleihen. Das bedeutet, dass im Shader Programm Felder benötigt werden, um die Texturdaten speichern zu können. Dafür wird einerseits eine Variable vom Typ Texture benötigt und andererseits ein Sampler. Die Texturvariable muss von der Applikation aus gesetzt werden. Beispiele für Texturen können den Bildern unten entnommen werden. Abbildung 15 zeigt dabei eine einzelne Textur eines Tigers, welche schließlich auf ein entsprechendes Model gelegt werden soll. Durch die Symmetrie des Tieres kann sie für beide Seiten verwendet werden. In Abbildung 17 sind zwei Texturen für ein Propellerflugzeug zu sehen. Die Linke wickelt sich dabei um den Propeller, den Rumpf und das Ruder hinten. Die Rechte hingegen ist für die Tragflächen oben und unten zuständig. Der Sampler wird zur Konfiguration von Texturen eingesetzt. Bei seiner Definition wird festgelegt, um welche Textur es sich überhaupt handelt (Name der Texturvariablen). Dann werden Filter gesetzt, die bei einer Vergrößerung (MagFilter) bzw. Verkleinerung (MinFilter) angewandt werden sollen. Der letzte Teil legt noch den Adressierungsmodus fest, welcher aussagt, was mit Texturkoordinaten passieren soll, die nicht zwischen null und eins liegen. Durch die Einstellung Wrap wird nach eins wieder mit null begonnen. Texture ModelTexture; sampler2d modeltexturesampler = sampler_state { Texture = (ModelTexture); MagFilter = Linear; MinFilter = Linear; AddressU = Wrap; AddressV = Wrap; }; Die Ein- und Ausgabestrukturen des Vertex bzw. Pixel Shaders werden noch um die Texturkoordinaten erweitert. Im Vertex Shader werden diese lediglich weitergereicht und es finden keine weiteren Kalkulationen statt. Erst im Pixel Shader wird dann mit den Texturkoordinaten auf den zu Beginn angelegten Sampler zugegriffen, um die Farbe des aktuellen Pixels zu erhalten. Bei der abschließenden Aufsummierung der einzelnen Lichtkomponenten wird anstatt mit der definierten Materialfarbe mit der eben ausgelesenen Texturfarbe multipliziert und das resultierende Produkt als Ausgabe des Pixel Shaders zurückgeliefert. Die Ergebnisse für die beiden Beispieltexturen sind in Abbildung 16 und Abbildung 18 ersichtlich. float4 texturecolor = tex2d(modeltexturesampler, input.texturecoordinate); return saturate(ambientlightcolor * AmbientLightPower + diffusecolor + specularcolor) * texturecolor; 24

32 Abbildung 15 Textur Tiger Abbildung 16 Tigermodel mit Textur Abbildung 17 Texturen Flugzeug (links Rumpf, rechts Flügel) Abbildung 18 Flugzeugmodel mit Textur 5.4 Bump Mapping (Normal Mapping) Bump Mapping ist eine spezielle Form des Texture Mappings und bildet den Oberbegriff für eine Vielzahl von Shader Techniken, mit deren Hilfe Oberflächen eine dreidimensionale Wirkung entfalten. So sehen die resultierenden Bilder realistischer aus als mit gewöhnlichem Texture Mapping, aber nicht in dem Ausmaß wie es bei der Erzeugung zusätzlicher Geometrie der Fall wäre. Die Basisidee hinter allen Lösungsansätzen ist, nicht die Farben des Objektes zu ermitteln, sondern die Normalvektoren anzupassen. Folgende fünf wesentliche Techniken stehen für diesen Effekt zur Auswahl: (vgl. Akenine-Möller et al. 2008, S ) Methode nach Blinn: Dabei werden aus einer Textur zu jedem Punkt zwei Werte u und v gelesen, mit denen die Richtung der Normalen abgeändert wird. ormal Mapping: Hier werden in der Textur direkt die neuen Normalen hinterlegt, wodurch bei jedem Pixel Berechnungsaufwand gespart wird. Solch eine Textur wird als Normal Map bezeichnet. Parallax Mapping: Diese erweiterte Technik berücksichtigt zusätzlich den Blickwinkel des Betrachters. So können (vom Betrachter aus gesehen) näher gelegene Unebenheiten, Strukturen die weiter entfernt sind, überdecken. Relief Mapping: Beim Parallax Mapping werden die Höhenwerte zweier Pixel als ungefähr gleich angesehen. Bei diesem Ansatz hingegen wird zusätzlich versucht näherungsweise die unterschiedlichen Höhen einer Oberfläche zu ermitteln, indem von der Textur in regelmäßigen Intervallen Höhenwerte entnommen werden. 25

33 Displacement Mapping: Durch die Einführung der Vertex Texture Fetch Funktion in Shader Model 3.0, können im Vertex Shader über die Texturenwerte die einzelnen Vertex Positionen verändert werden. Im Folgenden wird die Normal Mapping Technik genauer beschrieben, da sie die Basis für das Parallax, Relief und Displacement Mapping bildet. Als Ausgangslage dient ein Effektfile, wie es im klassischen Texture Mapping oberhalb beschrieben wurde. Darin sind bereits sämtliche Variablendefinitionen und Berechnungen für eine Beleuchtung mit ambienten, diffusen und spekulären Licht und das Aufbringen der Textur auf das Model enthalten. Hinzu kommen das Texturenfeld für die Normal Map und der dazugehörige Sampler. Als dritter Filter im Sampler ist hier einer für MipMaps gesetzt, welcher benötigt wird wenn ein großes Bild in kleineren Versionen dargestellt werden soll. Texture NormalMapTexture; sampler2d normalmaptexturesampler = sampler_state { Texture = (NormalMapTexture); MagFilter = Linear; MinFilter = Linear; MipFilter = Linear; AddressU = Wrap; AddressV = Wrap; }; Um zu einer sogenannten Normal Map zu kommen, wird zunächst eine Tiefen Map benötigt, welche mit Hilfe von schwarzen und weißen Farbwerten ein Höhenrelief darstellt. Dabei wird in Weiß ein erhöhter und in Schwarz ein tiefer Bereich visualisiert (siehe Abbildung 19). Schließlich kann daraus mit diversen Tools eine Normal Map erstellt werden (z.b.: Photoshop Plugin von NVIDIA oder CrazyBump). Die darin enthaltenen Werte werden in das Intervall [-1,1] gelegt. Beispielsweise kann eine Textur mit acht Bit 2 ^ 8 = 256 Werte darstellen, wodurch null zu minuseins und 255 zu eins werden würde. Damit kann der Vektor [0.0, 1.0, 0.0] durch den Farbwert [128, 255, 128] dargestellt werden (siehe Abbildung 20). Diese Normal Map hier stammt aus dem DirectX SDK. Abbildung 19 Erdkugel Tiefen Map Abbildung 20 Erdkugel Normal Map 26

34 Im Vertex Shader gibt es im Vergleich zum klassischen Texturing nichts Neues zu tun. Deshalb wird gleich mit dem Pixel Shader fortgefahren. Der erste Schritt ist, die Normale der Normal Map zu ermitteln, was über einen gewöhnlichen Texturenzugriff geschieht. Da die Normale in einem Wertebereich von [-1,1] benötigt wird, muss sie mit zwei multipliziert und danach um eins vermindert werden. Für die Berechnung der diffusen Komponente wird zunächst die Lichtintensität mit Hilfe der Normalen der Oberfläche berechnet. Schließlich muss aber, um die richtige diffuse Farbe zu erhalten, zusätzlich die Lichtintensität mit der Normalen der Normal Map berücksichtigt werden. Beide Intensitäten werden zusammen mit der Leuchtkraft multipliziert, um die finale Farbe zu bekommen. Bei Berechnung der spekulären Komponente ist nichts Besonderes zu beachten, diese kann auch gänzlich weggelassen werden. Zum Schluss werden sämtliche Lichtkomponenten addiert und mit der Texturfarbe multipliziert, um die Gesamtfarbe des Pixels zurückgeben zu können. float3 bumpnormal = normalize( (tex2d(normalmaptexturesampler, input.texturecoordinate)) * 2-1); float diffuselightattenuation = saturate(dot(input.normal, DiffuseLightDirection)); float diffusecolor = dot(diffuselightdirection, bumpnormal) * diffuselightattenuation * DiffuseLightPower; In dem unten ersichtlichen Bilderbeispiel wurde zur Veranschaulichung der Planet Erde herangezogen. Dieser ist in Abbildung 21 zunächst nur mit der gewöhnlichen Textur zu sehen. In Abbildung 22 kam dann die zur Textur passende Normal Map (siehe Abbildung 20) zum Einsatz, um die Oberflächenstruktur zu simulieren. Bei einem Vergleich der beiden Bilder sind auf der Erdkugel mit der aufgebrachten Normal Map Erhebungen zu bemerken. Besonders ausgeprägt ist dieser Effekt im Bereich des Ural Gebirges zu beobachten. Abbildung 21 Erdkugel ohne Bump Mapping Abbildung 22 Erdkugel mit Bump Mapping 27

35 5.5 Cel Shader (Toon Shader) Der nächste Effekt behandelt das Rendern einer Szene, sodass sie wie ein Comic aussieht. Dieser ist bekannt unter dem Namen Toon Shader oder Cel Shader. Dabei geht es in erster Linie darum, die Kanten der Objekte zu finden, diese nachzuzeichnen und die Farben so abzuändern, dass sie denen der Cartoons ähneln. Dabei ist etwas mehr Aufwand erforderlich als bei den drei vorherigen Beispielen. Als Basis für den Cel Shader dient eine Beleuchtung mit diffusen und ambienten Lichtkomponenten und Texturing für die Models. Über das Feld EdgeWidth kann die Dicke der zu zeichnenden Linien festgelegt werden. Der Wert in EdgeTolerance sagt aus, welche Farbunterschiede überhaupt als Kante angesehen werden sollen. Die Höhe und Breite des Ausgabefensters (die Auflösung) wird später in der Berechnung benötigt, um benachbarte Pixel in der richtigen Relation auszulesen. Diese beiden Variablen bekommen hier Standardwerte zugewiesen, werden aber auch von der Applikation aus gesetzt. In der srgb Spezifikation (IEC ) ist der Vektor für die Leuchtdichte (= Luminanz) mit [0.2125, , ] definiert. Dieser wird für die Kantenfindung benötigt und wurde hier etwas abgeändert, um für dieses Beispiel bessere Ergebnisse zu erzielen. Schließlich erfolgt noch die Initialisierung des Quantisierungsfaktors, welcher für die Anpassung der Farben eingesetzt wird. float EdgeWidth = 1.0f; float EdgeTolerance = 0.2f; int ScreenWidth = 1024; int ScreenHeight = 768; //Default Luminance (srgb specification) float3(0.2125,0.7154,0.0721) float3 LuminanceWeight = float3(0.4, 0.4, 0.4); float QuantizeFactor = 10.0; Im Vertex Shader werden lediglich die Position und die Normale transformiert und die Texturkoordinaten weitergegeben. Auch der Pixel Shader selbst bietet wenige Neuerungen, da die meisten Berechnungen in eine eigene Funktion ausgelagert wurden. Nach der gewöhnlichen diffusen und ambienten Lichtberechnung erfolgt der Aufruf dieser Funktion, welche die entsprechende Farbe des Pixels ermitteln soll. float4 surfacecolor = GetColor(input.TextureCoordinate); Die Funktion GetColor ist somit das Herzstück dieses Shaders und wird im Folgenden detailliert erklärt. Der dazugehörige Programmcode kann weiter unten nach den Erläuterungen gefunden werden. Als Eingabeparameter erwartet die Funktion die Texturkoordinaten, welche gleich zu Beginn in eine Variable mit kürzerem Namen eingelesen werden. Darunter werden die Abstände der benachbarten Pixel in u- bzw. v-richtung berechnet. Dabei definiert sich eine Einheit über die Dicke der Kante dividiert durch die Breite bzw. Höhe des Fensters. Die Basisfarbe wird aus der Textur geholt. 28

36 Im nächsten Schritt müssen die Farbwerte der senkrecht, waagrecht und diagonal benachbarten Pixel ermittelt werden. Diese sind von links oben nach rechts unten zeilenweise durchnummeriert. In Abbildung 23 wird versucht dieses System zu veranschaulichen, wobei die Variable p11 den Wert des aktuellen Pixels enthält und daher grün markiert ist. Beispielsweise befindet sich in p20 der Pixel links unterhalb, in p12 der Pixel rechts daneben und in p00 der links oberhalb. Abbildung 23 - Pixel Nachbarn Abbildung 24 - Sobel Filter horizontal Abbildung 25 - Sobel Filter vertikal Durch den Einsatz des Sobel Filters können die benachbarten Pixel jeweils gewichtet werden. Dabei kommen jeweils ein horizontaler (siehe Abbildung 24) und ein vertikaler Filter (siehe Abbildung 25) zum Einsatz, wodurch die Spalten links und rechts daneben bzw. Zeilen darüber und darunter miteinander verglichen werden. Die Summen der gewichteten Pixel ergeben dann einen Wert für die Spalten und einen für die Zeilen. Diese können dann in einen zweidimensionalen Vektor eingesetzt werden, dessen Länge den Farbunterschied der benachbarten Pixel bekannt gibt. Ist der Wert sehr klein, so handelt es sich um einen geringen Unterschied. Handelt es sich allerdings um einen großen Wert, so sind die Farben sehr verschieden und es kann an diesem Punkt eine Kante gezeichnet werden. Beispiele für die Gewichtung der Pixel: Horizontaler Filter: p01 * -2 oder p20 * 1 oder p12 * 0 Vertikaler Filter: p01 * 0 oder p20 * -1 oder p12 * 2 Ist nun der errechnete Wert größer als der Toleranzwert in der Variable EdgeTolerance, so wird die Farbe auf schwarz gesetzt und damit ein Pixel einer Kante gezeichnet. Andernfalls muss die entsprechende Comicfarbe berechnet werden. Um diese zu erhalten, wird durch den Einsatz eines Quantisierungsverfahrens die Basisfarbe abgestuft, wodurch letztendlich weniger unterschiedliche Farbwerte in der Szene enthalten sind. Dabei werden die RGB- Werte zunächst mit dem Quantisierungsfaktor multipliziert und dann jeweils um 0,5 erhöht. Anschließend erfolgt eine Konvertierung in Integer, wodurch die Dezimalstellen wegfallen. Schließlich wird nochmals durch den Quantisierungsfaktor dividiert, was dem Endergebnis entspricht. Die errechnete Farbe bzw. das Schwarz der Kante wird zurückgegeben und im Pixel Shader mit den Lichtkomponenten multipliziert, sodass der Pixel endlich seinen Weg auf den Bildschirm findet. 29

37 float4 GetColor(float2 texturecoordinate) { float2 uv = texturecoordinate.xy; float2 ulen = float2(edgewidth/screenwidth,0.0); float2 vlen = float2(0.0,edgewidth/screenheight); float4 color = tex2d(modeltexturesampler, uv); float p00 = dot( tex2d(modeltexturesampler,uv-ulen-vlen), LuminanceWeight); float p01 = dot(tex2d(modeltexturesampler,uv-vlen), LuminanceWeight); float p02 = dot( tex2d(modeltexturesampler,uv+ulen-vlen), LuminanceWeight); float p10 = dot(tex2d(modeltexturesampler,uv-ulen), LuminanceWeight); float p11 = dot(tex2d(modeltexturesampler,uv), LuminanceWeight); float p12 = dot(tex2d(modeltexturesampler,uv+ulen), LuminanceWeight); float p20 = dot( tex2d(modeltexturesampler,uv-ulen+vlen), LuminanceWeight); float p21 = dot(tex2d(modeltexturesampler,uv+vlen), LuminanceWeight); float p22 = dot(tex2d(modeltexturesampler,uv+ulen+vlen), LuminanceWeight); float horizontalvalue = -1 * p00-2 * p01-1 * p * p * p * p22; float verticalvalue = -1 * p * p02-2 * p * p12-1 * p * p22; float edgevalue = length(float2(horizontalvalue, verticalvalue)); if (edgevalue > EdgeTolerance) color = 0; else { color.rgb *= QuantizeFactor; color.rgb += float3(0.5, 0.5, 0.5); int3 intrgb = int3(color.rgb); color.rgb = float3(intrgb) / QuantizeFactor; color = float4(color.r, color.g, color.b, 1.0); } } return color; Die Veranschaulichung dieses Effektes erfolgt an dem Beispiel eines kleinen Zimmers, welches einen Kamin einen Sessel und ein kleines Raumschiff enthält. All diese Objekte sind Models und wurden aus dem DirectX SDK entnommen. In Abbildung 26 wird der gesamte Raum mit normalem Texturing abgebildet und zum Vergleich kann in Abbildung 27 dieselbe Ansicht mit dem Toon Shader gefunden werden. Weiters wird ein detailreicheres Unterscheidungsbeispiel anhand des Kamins in Abbildung 28 und Abbildung 29 abgelichtet. Im Anhang A können außerdem noch Bildvergleiche dieses Effektes mit dem Raumschiff und dem Sessel eingesehen werden. 30

38 Abbildung 26 - Raum normales Texturing Abbildung 27 - Raum Toon Shader Abbildung 28 - Kamin normales Texturing Abbildung 29 - Kamin Toon Shader 5.6 Shadow Mapping Das Shadow Mapping dient zum Zeichnen von Schatten und stellt den aufwendigsten Effekt unter den hier besprochenen dar. Die Umsetzung erfolgt in zwei Schritten und wird in diesem Beispiel durch zwei Techniken innerhalb eines Effektfiles realisiert. Im ersten Teil müssen alle Objekte aus Sicht der Lichtquelle gerendert und dessen Tiefenwerte in einer Textur gespeichert werden. Danach wird die Szene nochmals wie gewohnt aus der Kameraperspektive gezeichnet, wobei die zuvor erzeugte Textur herangezogen wird, um die Schatten einfließen zu lassen. Um mit der ersten Shader Technik zur Erstellung der Shadow Map beginnen zu können, müssen zuvor in der Applikation einige Dinge beachtet werden. Es ist wichtig, zuerst alle Objekte mit der ersten Technik zu erstellen und danach erst mit der anderen fortzufahren. Wird die Reihenfolge für jedes Objekt extra ausgeführt, kann es zu Problemen in der Darstellung kommen. Weiters muss darauf geachtet werden, dass bei Verwendung zweier Techniken innerhalb eines Effektfiles auch wirklich immer die richtige Technik eingestellt ist. Der letzte entscheidende Punkt ist, immer zwischen den richtigen Ausgabemodi umzuschalten. In XNA kommen hierfür die RenderTarget Objekte zum Einsatz. Diese werden für die Ausgabe der Shadow Map verwendet, während für das Rendern der Szene der Bildschirm das Ziel ist. 31

39 //Aktivieren des jeweiligen Effektes part.effect.currenttechnique = part.effect.techniques["shadowmap"]; part.effect.currenttechnique = part.effect.techniques["shadowscene"]; //Anlegen eines RenderTarget für die Shadow Map private RenderTarget2D shadowmaprendertarget; //Initialisierung des RenderTarget PresentationParameters pp = GraphicsDevice.PresentationParameters; shadowmaprendertarget = new RenderTarget2D( GraphicsDevice, pp.backbufferwidth, pp.backbufferheight, 1, SurfaceFormat.Color); //Umschalten auf das RenderTarget für die Shadow Map GraphicsDevice.SetRenderTarget(0, shadowmaprendertarget); //Umschalten auf den Bildschirm als RenderTarget GraphicsDevice.SetRenderTarget(0, null); Um mehrere Techniken innerhalb eines Effektfiles anzulegen, müssen diese einfach untereinander geschrieben werden. Die Unterscheidung liegt lediglich in den Namen der Vertex bzw. Pixel Shader und im Namen der Technik selbst. Das einzig Wichtige ist, dass sie am Ende der Datei die allerletzten Einträge darstellen. Die Shader Funktionen für die Shadow Map sind mit wenigen Programmzeilen erledigt. Die Aufgabe ist es, die Szene aus der Sicht des Lichtes zu rendern und dann die Tiefenwerte der Objekte in das RenderTarget Objekt auszugeben. Der Vertex Shader muss zunächst wieder die Position transformieren, wobei die View und Projection Matrizen des Lichtes verwendet werden. Für diese werden extra Variablendefinitionen angelegt. Als nächstes muss der Tiefenwert in Form eines Grauwertes errechnet werden. Dieser ergibt sich aus der Division des z-wertes durch die w-komponente der Position (Homogenisierung) und wird über ein in der Ausgabestruktur definiertes Feld an den Pixel Shader übergeben. Desto näher ein Vertex beim Licht liegt, umso dunkler ist der Grauwert. Weiße Farbe bedeutet, dass kein Schatten an dieser Stelle geworfen wird. Im Pixel Shader muss dann nur mehr der errechnete Farbwert ausgegeben werden. Das Ergebnis ist weiter unten in Abbildung 30 zu sehen. float4x4 ViewLight; float4x4 ProjectionLight; VSShadowMapOutput VertexShaderShadowMap(VSShadowMapInput input) { VSShadowMapOutput output; float4 worldposition = mul(input.position, World); float4 viewposition = mul(worldposition, ViewLight); output.position = mul(viewposition, ProjectionLight); output.depthcolor = output.position.z/output.position.w; } return output; Jetzt kann wieder auf die Ausgabe an den Bildschirm umgeschaltet werden, um die Szene mit den Schatten aus Kameraperspektive zu rendern. Auch bei diesem Effekt dienen als Ausgangslage klassisches Texturing für die Models und diffuse und ambiente Komponenten für die Beleuchtung. Außerdem werden Variablen für die Position einer Lichtquelle und dessen Leuchtkraft definiert, deren Initialisierung von der Applikation aus erfolgt. In diesem 32

40 Beispiel wird diese Quelle durch eine Deckenlampe verkörpert, welche senkrecht nach unten strahlt und einen runden Lichtkegel wirft. Um diesen runden Lichtkegel richtig darstellen zu können, wird wiederum eine eigene Textur und ein Sampler benötigt (siehe Abbildung 31 weiter unten). Und schließlich muss auch noch die Shadow Map über eine Textur und einen Sampler eingebunden werden. Für beide Sampler kommt der Adressierungsmodus Clamp zum Einsatz. float3 SpotLightPosition = float3(0, 14, 0); float SpotLightPower = 1.0f; Texture LightTargetTexture; sampler2d lighttargetsampler = sampler_state{... AddressU = Clamp; AddressV = Clamp; }; Texture ShadowMapTexture; sampler2d shadowmapsampler = sampler_state{... AddressU = Clamp; AddressV = Clamp; }; Zu den Ein- und Ausgabeparametern des Vertex Shaders zählen die Position, die Texturkoordinaten und die Normale. Zusätzlich sind in der Ausgabestruktur noch Felder für die Position im World Space und die transformierte Position aus Sicht des Lichtes enthalten. Das Befüllen dieser Parameter stellt auch die wesentlichen Neuerungen innerhalb des Vertex Shaders dar. Die anderen Befehle transformieren die Position, verschieben die Normale und geben die Texturkoordinaten weiter, weshalb diese auch im Programmausschnitt unterhalb nicht mehr vorkommen. output.positionworld = mul(input.position, World); float4 viewpositionlight = mul(output.positionworld, ViewLight); output.originalpositionbylight = mul(viewpositionlight, ProjectionLight); Der erste Schritt des Pixel Shaders berechnet die Texturkoordinaten für den Zugriff auf die Shadow Map. Weil die Map aus Sicht des Lichts erstellt wurde, müssen auch die Positionen wieder aus dieser Blickrichtung herangezogen werden. Diese wurden allerdings bereits im Vertex Shader berechnet und stehen daher hier zur Verfügung. Da es sich bei dieser Textur um zweidimensionale Daten handelt, genügt es, auf die x- und y-koordinaten zuzugreifen. Diese werden über eine Division durch die w-komponente homogenisiert und liegen dadurch im Intervall [-1,1]. Allerdings sind für den Texturenzugriff Werte zwischen null und eins gefragt, weshalb die Koordinaten mit 0,5 multipliziert und anschließend um 0,5 erhöht werden. Schließlich ist noch eine Umwandlung des y-wertes notwendig, da im normalen Koordinatensystem die Werte der y-achse von unten nach oben und bei den Texturkoordinaten in die andere Richtung größer werden. Dies kann durch die Verminderung des y-wertes um eins gelöst werden. 33

41 Mit Hilfe der soeben ermittelten Texturkoordinaten kann der Tiefenwert aus der Shadow Map geholt werden, wobei es genügt, jeweils den Rot-Wert auszulesen. Wie auch schon im Vertex Shader der Shadow Map Technik, wird weiters der homogenisierte Tiefenwert für den Pixel aus Sicht des Lichtes berechnet (also die tatsächliche Entfernung des Lichtes zum Pixel). Ist der Wert der Shadow Map größer oder gleich der Entfernung des Pixels zum Licht, so wird der aktuelle Pixel beleuchtet und die entsprechenden diffusen Lichtberechnungen werden ausgeführt. Andernfalls ist der Pixel hinter einem Objekt und liegt in dessen Schatten, wodurch die diffuse Farbe auf Schwarz gesetzt wird. Vom Tiefenwert des Pixels aus Sicht des Lichtes wird im Programmcode unten noch ein Wert von 0,003 abgezogen. Dies geschieht, weil die gespeicherte z-komponente in der Shadow Map nur acht Bit Information enthält und daher kleine Ungenauigkeiten entstehen, welche hier wieder ausgeglichen werden. Für die diffuse Lichtberechnung wird zunächst der Vektor von der Position im World Space zur Lichtquelle hin berechnet. Mit dessen Hilfe kann dann über das Dot-Produkt wieder die Lichtintensität errechnet werden. Zusätzlich wird noch der Wert aus der Textur für den Lichtkegel durch Einsatz der Texturkoordinaten der Shadow Map ausgelesen, wobei auch hier wieder der Rot-Wert genügt. Schlussendlich errechnet sich die diffuse Farbe aus der Multiplikation der Lichtfarbe, der Leuchtkraft des Lichtes, der zurückgeworfenen Lichtintensität und dem Texturenwert des Lichtkegels. Am Ende des Pixel Shaders wird die Model Textur ausgelesen und mit dem ambienten und diffusen Licht zu einer Farbe verschmolzen. float4 PixelShaderShadowScene(VSShadowSceneOutput input) : COLOR0 { float2 ShadowMapTextureCoordinate = input.originalpositionbylight.xy/input.originalpositionbylight.w * 0.5f + float2(0.5f, 0.5f); ShadowMapTextureCoordinate.y = 1.0f - ShadowMapTextureCoordinate.y; float depthvalueshadowmap = tex2d(shadowmapsampler, ShadowMapTextureCoordinate).r; float depthvaluebylight = input.originalpositionbylight.z / input.originalpositionbylight.w; float4 diffusecolor; if(depthvalueshadowmap >= depthvaluebylight ) { float3 lightvector = normalize(spotlightposition - input.positionworld); float lightattenuation = saturate(dot(lightvector, input.normal)); float lighttargetpower = tex2d(lighttargetsampler, ShadowMapTextureCoordinate).r; diffusecolor = DiffuseLightColor * SpotLightPower * lightattenuation * lighttargetpower; } else diffusecolor = float4(0,0,0,0); float4 texturecolor = tex2d(modelsampler, input.texturecoordinate); } return (diffusecolor + AmbientLightColor * AmbientLightPower) * texturecolor; 34

42 Für diesen Effekt kommt, wie auch schon beim Toon Shader, das Zimmer mit Sessel, Raumschiff und Kamin zum Einsatz. An der Decke befindet sich eine kleine Lampe, welche die Lichtquelle darstellt und senkrecht nach unten strahlt. Die Shadow Map dafür ist in Abbildung 30 zu sehen. In diesem Fall ist das Raumschiff in der Mitte sehr nahe an der Lampe und damit gut erkennbar. Der Sessel links oben in der Textur ist hingegen sehr schwach zu sehen, da er sich weiter weg von der Lichtquelle befindet. Abbildung 31 daneben zeigt noch die Textur, welche für den Lichtkegel verwendet wird. Durch die Multiplikation mit den einzelnen Texturwerten werden die Pixel innerhalb des weißen Kreises mit diffusem Licht beleuchtet. Alle anderen Punkte liegen außerhalb des Lichtkegels und erhalten lediglich ambientes Licht. In Abbildung 32 und Abbildung 33 ist dann die fertige Szene mit den Schatten zu sehen. Im linken Bild ist dabei das Raumschiff weiter oben (näher bei der Lampe), wodurch der Schatten auf dem Boden größer ist. Rechts daneben ist es weiter unten (weiter weg von der Lampe) und der Schatten fällt daher auch kleiner aus. Im Anhang A können auch noch weitere Bilder des Shadow Mapping Effekts gefunden werden. Abbildung 30 - Shadow Map Abbildung 31 - Textur für Lichtkegel Abbildung 32 - Schattenszene Raumschiff oben Abbildung 33 - Schattenszene Raumschiff unten 35

43 6 Einsatz in der Industrie Die zwei größten Einsatzgebiete sind Videospiele und Animationsfilme, wobei die Verwendung der Shader in diesen Bereichen sehr unterschiedlich ist. Den Produktionsfirmen für Animationsfilme wie Pixar steht ein hohes Budget zur Verfügung, wodurch bei der Berechnung eines Bildes auf nicht vergleichbare Hardware zurückgegriffen werden kann. Außerdem müssen Spiele in Echtzeit gerendert werden, was bei Animationen nicht der Fall ist. Beispielsweise kamen beim Film Shrek über 3100 Prozessorkerne mit jeweils 16 Gigabyte Speicher zum Einsatz. (vgl. Akenine-Möller et al. 2008, S ) Mittlerweile sehen die erzeugten Bilder in Computerspielen und Animationsfilmen schon sehr realistisch aus. Oft kann erst durch genaues Hinsehen erkannt werden, ob es sich um ein Video der Realität oder um eine Simulation handelt. Bei einem Spiel sollten zumindest 30 Frames in der Sekunde geliefert werden, um einen flüssigen Ablauf zu gewährleisten. Der Animationsfilm Ratatouille benötigte im Durchschnitt für lediglich einen einzigen Frame 6,5 Stunden. Um also in derselben Qualität die gewünschten 30 Bilder zu erhalten, müsste darauf fast 200 Stunden gewartet werden. Einige neuartige Spiele können annähernd mit der Qualität von Toy Story mithalten. Ratatouille verwendete aber im Vergleich zu Toy Story bereits das 420-fache an Ressourcen. (vgl. Akenine-Möller et al. 2008, S ) Aber auch Organisationen anderer Branchen nutzen Shader und deren Techniken. Ein Effekt, welcher von der NASA verwendet wurde, ist die Erzeugung von dreidimensionalen Bildern durch die Verwendung von Stereo Anaglyphenbildern. Dabei kommen spezielle Brillen zum Einsatz, welche für das linke Auge einen roten Filter und für das rechte einen in Cyan eingebettet haben. Auch die gewünschte Szene muss dann einmal für das linke Auge in Rot und für das rechte in Cyan gerendert werden. Werden diese beiden Bilder dann zusammengeführt, kann mit der entsprechenden Brille der dreidimensionale Effekt beobachtet werden. Solche Aufnahmen wurden von den Robotern der NASA auf dem Mars kreiert, welche unter zu sehen sind. Für dreidimensionales Fernsehen wird eine ähnliche Technik namens Smooth Picture angewandt. Dabei wird wieder eine eigene Brillenart benötigt, welche abwechselnd links und rechts Bilder durchlässt. Der Unterschied ist, dass die beiden Bilder leicht verschoben sind und zusammengefasst etwas unscharf wirken. Dieser Effekt wurde in vielen Applikationen für Bereiche wie Architektur, Chemie oder Biologie eingesetzt. (vgl. Bailey, Cunningham 2009, S ) Im Spiel Grand Theft Auto 4 (GTA4) kam eine neu entwickelte Technik des Shadow Mappings zum Einsatz, welche von den Schaffern als Facetted Shadow Mapping bezeichnet wurde. Sie verwendete Ansätze bereits bestehender Shadow Maps wie der Warped Shadow Map oder der Split Shadow Map. Ausgelegt ist diese spezielle Kreation für globale, direktionale Lichter (wie Sonne oder Mond) bei Spielen mit umfangreichen Szenen und in einem großen Umfeld. Grund für die Neuentwicklung dieser Technologie waren einige Problemstellungen, welche damit gelöst werden sollten. So war es dann möglich, eine sich kontinuierlich zur Spielzeit bewegende Sonne zu simulieren, ohne Unmengen an Daten zu erzeugen. Für alle Objekte sollte eine einheitliche Technik verwendet werden. Weiters war es wichtig, hohe Details mit genauen Kanten und einen niedrigen Speicherverbrauch zu erzielen. Eine kleine Speichergröße war vor allem deshalb ausschlaggebend, weil Konsolensysteme oft nur limitierte Ressourcen haben und es daher möglich sein musste, die Shadow Map in kurzer 36

44 Zeit auf ein zweites Speichermedium auszulagern. Im Endeffekt verbrauchte sie 6,4 MB für eine Auflösung von 1280x1280. Für die Berechnungszeit wurden etwa zehn bis fünfzehn Prozent eines kompletten Frames benötigt. (vgl. Engel 2009, S ) Auch in der medizinischen Informatik werden Shadow Maps und andere Effekte verwendet. Im Bereich der Radiologie können beispielsweise mit Hilfe von Volumenvisualisierungen die Aufnahmen einer Computertomographie in zweidimensionale realistische Bilder umgewandelt werden. Um gute Ergebnisse zu erzielen, müssen einige Shader Techniken kombiniert und eingesetzt werden. (vgl. Bach, GPU-Based Volume Ray Casting with Advanced Illumination) Eine weitere Einsatzmöglichkeit von Shader Programmen findet sich beim Motion Capturing. Dabei werden die Bewegungen eines Menschen analysiert, auf einen Rechner übertragen und dort in visueller Form wiedergegeben. Die verschiedenen Shader Stufen haben dabei die Aufgabe, sämtliche Bewegungen der Gelenke und Muskeln in einer effizienten Art und Weise zu berechnen. Vor allem wenn dieses Verfahren in Echtzeit benötigt wird, müssen mit den Shadern die zur Verfügung stehenden Ressourcen sinnvoll eingesetzt werden. (vgl. Brüning et al., Interaktives Motion Capturing zur Echtzeitanimation virtueller Agenten) 37

45 7 Ausblick und Zusammenfassung Shader Programme sind notwendig, um die Abläufe auf der Grafikkarte zu optimieren und verschiedene Effekte darstellen zu können. Zu Beginn gab es dabei keinerlei Möglichkeiten in das Geschehen einzugreifen. Alle Schritte waren fest vorgegeben. Schließlich hat sich die Flexibilität nach und nach gesteigert, wodurch einem Entwickler schon sehr viele Freiheiten gegeben wurden. Mit OpenGL und DirectX haben sich für diesen Zweck zwei umfangreiche APIs durchgesetzt, wobei die zweite Variante nur für Windows Systeme existiert. Mit den einzelnen Shader Model Versionen sind auch immer wieder neue Stufen in den Rendering Ablauf hinzu gekommen. So gibt es jetzt neben einem Vertex und Pixel Shader einen Geometry Shader, um die Objektgeometrie zu verändern und einen Hull und Domain Shader, mit denen die Tessellation Funktion für verschiedene Levels-of-Detail realisiert wurde. Das Shader Model 5.0 führte schließlich sogar einen Compute Shader ein, wodurch die Grafikkarte auch für allgemeine Berechnungen eingesetzt werden kann. Die bekanntesten Shader Sprachen sind HLSL, GLSL und Cg, welche einem klassischen C- Programm ähneln. Der Trend geht aber auch hier mittlerweile in die Richtung der objektorientierten Programmierung. Problematisch wurde es bei diesen Sprachen immer dann, wenn diese debuggt werden mussten. Doch mittlerweile gibt es hilfreiche Werkzeuge bzw. eigenständige Applikationen, mit denen der Shader Programmcode wie der einer gewöhnliche Software Anwendung über Breakpoints durchlaufen werden kann. Auch in die Inhalte der Variablen und Register wird Einsicht gewährt. Weiters wurde dann in dieser Arbeit versucht, mit einigen ausgewählten Effekten zu veranschaulichen, wie ein Shader Programm aufgebaut ist und worauf geachtet werden muss. Darunter fanden sich grundlegende Techniken wie das Shading oder Texturing. Der Bump Mapping Effekt wird verwendet, um Oberflächen eine dreidimensionale Struktur zu verleihen, ohne dabei die Geometrie angreifen zu müssen. Mittlerweile werfen die Objekte fast aller Spiele Schatten, wofür die Shadow Mapping Technik zum Einsatz kommt. Auf diese wird in einer speziellen Form auch im Videospiel Grand Theft Auto 4 gesetzt. Neben der Videospielindustrie sind Animationsfilme das zweite große Einsatzgebiet für zahlreiche Shader Effekte. Dabei ist es allerdings nicht notwendig, alles in Echtzeit zu rendern, wodurch bessere Ergebnisse erzielt werden können. Auch die Medizin kann von zahlreichen Effekten Gebrauch machen. Das dreidimensionale Fernsehen basiert ebenfalls auf einem Shader Programm, welches auch in der NASA für Aufnahmen auf dem Mars eingesetzt wurde. Moore s Gesetz wurde von Gordon Moore im Jahre 1965 in die Welt gerufen und besagt, dass die Rechenleistung mit jedem Jahr ums doppelte ansteigt. (vgl. St.-Laurent 2005, S. 5) Selbst wenn dies eintreffen würde und die GPUs dadurch Shader schneller berechnen könnten, so würde es noch immer andere physische Limitierungen wie die der Bandbreite geben. Denn diese steigt im Vergleich pro Jahr nur um ein Viertel und bildet somit erneut einen Flaschenhals. Deshalb ist es schwer vorauszusehen, wie sich die Umsetzung der einzelnen grafischen Effekte mit steigernden Hardwareressourcen ändert. (vgl. Akenine-Möller et al. 2008, S ) 38

46 Der jetzige Stand der Dinge reicht noch lange nicht an Szenen aus der Realität heran. Die Komplexität kennt dabei keine Grenzen. So sind innerhalb eines abgeschlossen Zimmers einer Wohnung sehr viele kleine Details verstreut, welche jeweils wieder zusätzliche Rechenzeit verbrauchen würden. Wird dann noch die Umwelt in der freien Natur betrachtet, so liegen die Ziele diese Vielfältigkeit zu erreichen noch in einiger Ferne. Die Objekte werden in immer kleinere Dreiecke aufgeteilt und auch neue Berechnungsansätze für Beleuchtungsmodelle entwickeln sich. (vgl. Akenine-Möller et al. 2008, S ) Die Shader Sprachen werden inhaltlich in ihrer jetzigen Form wohl auch in Zukunft bestehen. Wie diese sich aber genau weiterentwickeln, ist schwer zu sagen. Selbst wenn eine neue Technologie plötzlich die jetzige Rendering Pipeline ersetzen würde, wäre es fraglich ob die Industrie sich so schnell daran anpassen könnte. Die Programmierschnittstellen haben sich für die derzeitige Hardware etabliert und müssten eventuell angepasst werden. Weiters wäre es erforderlich neue Werkzeuge für die Programmierer zu erstellen. Die Produktionsstätten der Filme und Spiele haben sich für diese Technologien und Sprachen entschieden und arbeiten mit ihnen. Komplexe Entwicklungen nehmen viel Zeit in Anspruch und verschlingen Millionen an Kosten. Darum ist es nicht so einfach, und vor allem nicht in absehbarer Zeit möglich, auf etwas Anderes umzustellen und auf Shader zu verzichten. Deshalb werden diese sicher auch in den nächsten Jahren noch weiter ausgebaut und mit neuen Features bestückt. (vgl. Akenine-Möller et al. 2008, S ) 39

47 Literaturverzeichnis AKENINE-MÖLLER, T., HAINES, E., HOFFMAN, N., Real Time Rendering. 3rd Edition. Wellesley: A K Peters, Ltd. AMD, PS2ClientHelp BACH, T. V. GPU-Based Volume Ray Casting with Advanced Illumination [online]. Verfügbar bei: [Zugang am ] BAILEY, M., CUNNINGHAM, S., Graphics Shaders Theory and Practice. Wellesley: A K Peters, Ltd. BAYER, T., SPILLE, C., DirectX 11 im Bildvergleich [online]. PC Games. Verfügbar bei: Stalker-CoP-Dirt-2-und-AvP-Top-Artikel-Oktober-2009/Grafikkarte/News/ [Zugang am ] BRANDAU, M., DirectX 11 for Windows Vista [online]. PC Games. Verfügbar bei: DirectX-11/News/ [Zugang am ] BRÜNING, B. A., LATOSCHIK, M. E., WACHSMUTH, I. Interaktives Motion Capturing zur Echtzeitanimation virtueller Agenten [online]. Verfügbar bei: [Zugang am ] ENGEL, W., ShaderX7 Advanced Rendering Techniques. Boston: Course Technology KREISS, T., Realitäts Check II: 3D-Spiele mit Natur und Hölle verglichen [online]. Tom s Hardware. Verfügbar bei: html [Zugang am ] LOVESEY, A., A Comparison of Real Time Graphical Shading Languages [online]. Verfügbar bei: [Zugang am ] MICROSOFT CORPORATION, PIX: User s Guide MOELLER, M., REYES, Primitives & Some Philosophy [online]. Verfügbar bei: [Zugang am ] 40

48 MSDN Library, Tessellation Overview [online]. Verfügbar bei: [Zugang am ] MSDN Library, Direct3D 11 Features [online]. Verfügbar bei: [Zugang am ] NVIDIA Corporation, NVIDIA Shader Debugger: User s Guide [online]. Verfügbar bei: e.pdf [Zugang am ] PERLIN, K., Making Noise [online]. Verfügbar bei: [Zugang am ] RÖSLER, R. Einführung in die Shader Programmierung unter OpenGL 2.0 [online] Verfügbar bei: [Zugang am ] SPOOREN, F., Test: Shader Model 3.0 vs. 2.0 [online]. Hardware-Infos. Verfügbar bei: [Zugang am ] ST-LAURENT, S., The Complete Effect and HLSL Guide. Redmond: Paradoxal Press THEUERJAHR, U., Direct3D Real Time Rendering für Computerspiele. Schönberg: ROULIO Press 41

49 Abbildungsverzeichnis Abbildung 1 - Stufen der Rendering Pipeline auf der GPU (Akenine-Möller et al. 2008)...2 Abbildung 2 - Eingabeobjekte des Geometry Shaders (Akenine-Möller et al. 2008)...4 Abbildung 3 Wireframe ohne Tessellation (Bayer, Spille 2009)...6 Abbildung 4 Wireframe mit Tessellation (Bayer, Spille 2009)...6 Abbildung 5 Haus ohne Tessellation (Bayer, Spille 2009)...6 Abbildung 6 Haus mit Tessellation (Bayer, Spille 2009)...6 Abbildung 7 - Beispiel für einen Shade Tree (Akenine-Möller et al. 2008)...7 Abbildung 8 PIX Abbildung 9 - NVIDIA Shader Debugger Abbildung 10 - ATI PerfStudio Abbildung 11 - Ambient Light...23 Abbildung 12 - Diffuse Light (Gouraud)...23 Abbildung 13 Specular Light Gouraud Shading...23 Abbildung 14 Specular Light Phong Shading...23 Abbildung 15 Textur Tiger...25 Abbildung 16 Tigermodel mit Textur...25 Abbildung 17 Texturen Flugzeug (links Rumpf, rechts Flügel)...25 Abbildung 18 Flugzeugmodel mit Textur...25 Abbildung 19 Erdkugel Tiefen Map...26 Abbildung 20 Erdkugel Normal Map...26 Abbildung 21 Erdkugel ohne Bump Mapping...27 Abbildung 22 Erdkugel mit Bump Mapping...27 Abbildung 23 - Pixel Nachbarn...29 Abbildung 24 - Sobel Filter horizontal...29 Abbildung 25 - Sobel Filter vertikal...29 Abbildung 26 - Raum normales Texturing...31 Abbildung 27 - Raum Toon Shader...31 Abbildung 28 - Kamin normales Texturing...31 Abbildung 29 - Kamin Toon Shader...31 Abbildung 30 - Shadow Map...35 Abbildung 31 - Textur für Lichtkegel...35 Abbildung 32 - Schattenszene Raumschiff oben...35 Abbildung 33 - Schattenszene Raumschiff unten

50 Tabellenverzeichnis Tabelle 1 - Shader Model Vergleich (vgl. Akenine-Möller et al. 2008, S. 38)

51 Abkürzungsverzeichnis ADS Ambient-Diffuse-Specular API ARB Cg GLSL GPU HLSL IL LOD REYES SDK Application Programming Interface (deutsch Programmierschnittstelle) OpenGL Architecture Review Board C for Graphics OpenGL Shader Language Graphics Processing Unit (deutsch Grafikprozessor) High Level Shader Language Intermediate Language Levels-of-Detail Renders Everything You Ever Saw Software Development Kit 44

52 Anhang A: Zusätzliche Bildvergleiche Hier ein weiterer Vergleich der unterschiedlichen Lichtberechnungen und der Shading Models nach Gouraud und Phong. Schädel Ambient Schädel Diffuse (Gouraud) Schädel Specular (Gouraud) Schädel Specular (Phong) 45

53 Vergleich des normalen Texturing und dem Toon Shader anhand eines Raumschiffes und einem Sessel. Raumschiff normales Texturng Raumschiff Toon Shader Sessel normales Texturing Sessel Toon Shader 46

54 Bilder des Shadow Mapping Effekts. Schattenszene mit dem Raumschiff oben Schattenszene mit dem Raumschiff unten Schatten des Sessels 47