Shader und Effekte für AiRmob. Bachelorarbeit

Transkript

1 Fachbereich 4: Informatik Shader und Effekte für AiRmob Bachelorarbeit zur Erlangung des Grades eines Bachelor of Science (B.Sc.) im Studiengang Computervisualistik vorgelegt von Philipp Brandt Erstgutachter: Zweitgutachter: Prof. Dr.-Ing. Stefan Müller (Institut für Computervisualistik, AG Computergraphik) Dipl.-Inform. Diana Röttger (Institut für Computervisualistik, AG Computergraphik) Koblenz, im April 2012

2 Erklärung Ich versichere, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Ja Nein Mit der Einstellung der Arbeit in die Bibliothek bin ich einverstanden. Der Veröffentlichung dieser Arbeit im Internet stimme ich zu (Ort, Datum) (Unterschrift) 1

3 Inhaltsverzeichnis 1 Einleitung Motivation Hintergründe des Projekts Zielsetzung AiRmob Ziele dieser Arbeit Zum Thema Android OpenGL ES OpenGL ES Shading Language Shader-Theorie Geschichtliche Hintergründe Stand der Technik Beleuchtung Cel-Shading Schatten Mapping Image Post-Processing AiRmob Shader Shaderkonzept Implemetierte Shader Erweiterbarkeit Framework Airmob Architektur Schnittstellen zwischen Renderer und Shadern Techdemo 44 6 Schluss Auswertung Ausblick

4 1 Einleitung 1.1 Motivation Im Laufe eines Studiums der Computervisualistik lernt man viele Facetten dieses Studiengangs kennen. Ein wichtiger Baustein ist dabei die Computergrafik. Durch sie lernt man, eine entworfene Szene besonders interessant oder optisch ansprechend in Erscheinung treten zu lassen. Da dieser Schritt in der Regel mit Hilfe von Shadern passiert, habe ich diese als Thema meiner Arbeit gewählt. Der spezielle Reiz dieser Arbeit liegt allerdings darin, das Gelernte auf eine neue Ebene zu bringen. Durch den Umstand, dass das Projekt AiRmob im Zuge mehrerer Bachelorarbeiten ins Leben gerufen wurde, eröffnet sich für mich die Möglichkeit, Shader auf dem vergleichsweise noch neuen Gebiet der mobilen Endgeräte zu realisieren. Aufgabe dieser Arbeit ist es, herauszufinden, welche Shadertechniken auf verschiedenen mobilen Endgeräten möglichst echtzeitfähig realisierbar sind. Eine große Hürde ist dabei die Tatsache, dass bei AiRmob während dem Rendern auch gleichzeitig Tracking und Koordination stattfindet, was ebenfalls einen nicht unerheblichen Teil der sowieso schon geringen Leistung von Smartphones in Anspruch nimmt. Zudem ist bei mobilen Geräten darauf zu achten, nicht nur leistungseffizient, sondern auch möglichst stromsparend zu programmieren, da man die begrenzte Akkuleistung nicht unnötig strapazieren möchte. Diese Umstände, sowie das Zusammenarbeiten in einem Team aus vier Personen, machen für mich die Besonderheit dieser Arbeit aus und ich hoffe meinen Teil zu einem erfolgreichen Augmented Reality Framework für Android Geräte beizutragen. 1.2 Hintergründe des Projekts Autoren: Philipp Brandt, Florian Kathe, Nils Lichtenberg und Axel Peter Diese Arbeit ist ein Teil des AiRmob-Frameworks. Dieses Framework wurde im Zuge von insgesamt vier Bachelorarbeiten parallel entwickelt. Es soll das Entwickeln für Augmented Reality Applikationen für Android ermöglichen. Das Projekt entstand aus folgenden Arbeiten: Anwendungs- und Interaktionskomponente für AiRmob - von Nils Lichtenberg Bei dieser Arbeit handelt es sich um das Grundgerüst, welches auf einfache Art und Weise mit einem Tracking- und Renderingsystem erweitert und vervollständigt werden kann. Das Verknüpfen des Frameworks mit der Standard-Android-API soll dem Benutzer möglichst einfach gemacht werden. 3

5 Trackingkomponente für AiRmob - von Florian Kathe Grundlage dieser Arbeit soll ein Tracker sein, der auf Basis von Markern oder Features ein Objekt in einem Bild tracken kann und dessen Pose berechnet. Diese soll dann wiederum an den Renderer weitergegeben werden. Es sollen dabei zwei Tracker entwickelt werden, die als Standard- Tracker verwendet werden können und als Beispiel dienen, wie man Tracker für dieses Framework entwickelt. 3D-Engine für AiRmob - von Axel Peter In dieser Arbeit wird eine 3D-Engine entwickelt, welche dem Benutzer ermöglichen soll, schnell und einfach 3D-Inhalte zu produzieren. Hierzu soll der Anwender nur über grundlegende Kenntnisse von OpenGL verfügen müssen. Die anfänglichen Schwierigkeiten eines Einstiegs in OpenGL ES 2.0 sollen ihm genommen werden. Fortgeschrittene Techniken für eine möglichst hohe Effizienz und Qualität der Darstellung sollen verwendet werden. Shader und Effekte für AiRmob - von Philipp Brandt Bestandteil dieser Arbeit ist die Entwicklung verschiedener Shader, die im Renderer des Frameworks integriert und aufgerufen werden. Es wird der aktuelle Stand der Technik ermittelt und im Verlauf der Arbeit versucht, möglichst aktuelle und anspruchsvolle Shader auf den gegebenen mobilen Endgeräten echtzeitfähig zu implementieren. Texte die gemeinsam verfasst wurden, werden wie dieser entsprechend kenntlich gemacht. Auf die Zielsetzungen der einzelnen Arbeiten wird im nächsten Abschnitt noch genauer eingegangen. Architektur, Schnittstellen und Austauschbarkeit der Komponenten wird in Abschnitt 4 erläutert. 1.3 Zielsetzung AiRmob Autoren: Philipp Brandt, Florian Kathe, Nils Lichtenberg und Axel Peter Das Hauptziel der Arbeiten ist die Entwicklung des AiRmob-Frameworks. Dieses soll eine einsteigerfreundliche Entwicklungsumgebung für Augmented Reality (AR) Anwendungen auf Android-Geräten bieten. Hierzu sollen die Schritte, die zum Erstellen einer lauffähigen Applikation nötig sind, reduziert werden. Der Benutzer, im Falle dieses Frameworks ein Entwickler von Applikationen, soll in der Lage sein, mit minimalen Vorkenntnissen von Android, OpenGL und Trackingsystemen seine Ideen schnell umzuset- 4

6 zen. Gleichzeitig soll es für fortgeschrittene Benutzer möglich sein, eigene Trackingsysteme und Renderer in das Framework einzubinden. Das Android-SDK soll als Basis für dieses Framework dienen. Hierdurch wird es für die Benutzer möglich sein, ihr Applikationen für alle mit Android kompatiblen Geräte zu entwickeln. Das Framework wird auf der SDK-Version 2.3 (Gingerbread) entwickelt und ist somit für diese und alle späteren lauffähig. Zusätzlich sollen mit Hilfe des Frameworks in gemeinsamer Arbeit zwei Applikationen entstehen. Die erste Applikation ist eine Techdemo. Mit ihr soll es möglich sein, diverse Einstellungen für die verschiedenen Komponenten auf Effizienz und Stabilität testen zu können. Diese Applikation entsteht parallel zur Entwicklung des eigentlichen Frameworks und wird nach und nach um neue Funktionalitäten erweitert. Die zweite Anwendung ist eine Beispielapplikation. Diese soll mit dem Framework selbst entwickelt worden sein und dadurch aufzeigen, in welcher Weise die Komponenten des Frameworks für eine Gesamtapplikation benutzt werden. Während die Techdemo in Abschnitt 5 beschrieben wird, ist die Beispielapplikation Teil der Arbeit von Nils Lichtenberg. Auf die genauen Ziele dieser Arbeit wird im nächsten Abschnitt eingegangen Ziele dieser Arbeit Ziel dieser Arbeit ist es zu evaluieren, welche Shadermethoden aktuell dem Stand der Technik entsprechen und ob es möglich und sinnvoll sein wird, diese auf mobilen Endgeräten mit OpenGL ES 2.0 zu implementieren. Dabei wird zuerst in einem theoretischen Teil der Arbeit auf die einzelnen Techniken eingegangen. Am Anfang wird in einem kurzen Abschnitt Android vorgestellt und auf die Besonderheiten von OpenGL ES 2.0 und dessen Unterschiede zum regulären OpenGL eingegangen. Im darauf folgenden Abschnitt werden Formeln und Algorithmen erläutert, die den wichtigsten Methoden zur Beleuchtung, Schattierung und anderen Grafikeffekten zu Grunde liegen. Im zweiten Teil der Arbeit wird auf die praktischen Implementationen der Effekte, sowie das Konzept der Einbindung in die Engine eingegangen. Ziel ist es, eine möglichst große Zahl der zeitgemäßen Effekte als Shader zu realisieren und in einem System zu vereinen. Außerdem soll es einem Benutzer ermöglicht werden, diese Effekte zu steuern, ohne im Code editieren zu müssen. Ein weiterer Teil der Arbeit befasst sich mit der Gesamtarchitektur des AiRmob Frameworks, sowie den Schnittstellen der Shader zur Engine. Der letzte Teil der Arbeit wird diese kritisch bewerten und hinterfragen, ob das angestrebte Konzept sinnvoll ist. Außerdem wird ein Ausblick gegeben, inwieweit das Erweitern dieses Systems in Zukunft möglich sein wird. 5

7 2 Zum Thema 2.1 Android Android ist die Bezeichnung für ein Betriebssystem und eine Software- Plattform für mobile Endgeräte. In beiden Fällen handelt es sich um eine freie und quelloffene Software, die auf Apache 2.0 lizenziert ist (siehe: [anda]). Für die Entwicklung der Android Software ist die Open Handset Alliance verantwortlich. Hauptteilhaber und Gründer dieses Entwickler- Konsortiums, bestehend aus aktuell 1 ca. 80 Mitgliedern, ist die Aktiengesellschaft Google Inc. (siehe [24a]). Auf dem Bereich der Smartphones hat sich der Marktanteil von Android- Geräten im letzten Quartal mit einem Sprung von 25,3% auf 52,5% mehr als verdoppelt. Damit übernimmt Android die Spitze des Marktes mit mehr als 35 Prozentpunkten Vorsprung auf die beiden Hauptverfolger Symbion und Apples ios (siehe: [hei]). Die derzeit aktuellste Version von Android trägt den Namen Ice Cream Sandwich und hat die laufende Versionsnummer 4.0 (siehe: [andb]). Androids Entwicklerteam ermittelt im zweiwöchigen Takt, welche Versionen zum entsprechenden Zeitpunkt am verbreitetsten sind. Hierzu werden die Zugriffe auf den Android Market 2 gezählt und ausgewertet. Aus der Erhebung vom 3. November 2011 ging hervor, dass die Masse der Nutzer 2.3 Gingerbread 3 oder 2.2 Froyo 4 nutzen (siehe: [andc]). Diese Werte begünstigen die Entscheidung auf dem Froyo- SDK zu entwickeln. Allerdings unterstützt diese Version für das Programmieren relevante Methoden nicht, was dazu führte, dass im Laufe der Arbeit auf Gingerbread umgestiegen werden musste. SDK steht für Software Development Kit, welches den Programmierern externer Apps zur Verfügung gestellt wird. Es beinhaltet unter anderem einen AVD-Manager, einen entsprechenden Emulator und einen Debugger (siehe: [andd]). Die Programmiersprache des SDK ist Java und die Entwicklung findet in einer dafür vorgesehen Umgebung wie Eclipse 5 statt. Die Ausgabe des Tools wird entweder an ein angeschlossenes Android-Gerät mit passender Plattformversion oder an den Emulator übermittelt (siehe: [ande]). Dieser ist ein seiner aktuellen Ausgabe 6 nicht mit OpenGL ES 2.0 kompatibel. 1 Stand: November seit : Google Play Store 3 44,4% 4 40,7% Stand: November

8 2.2 OpenGL ES 2.0 OpenGL ES ist ein application programming interface, welches 3D- Applikationen auf mobile Geräte, eingebettete Systeme und Konsolen bringt. Mit der Version 2.0 ermöglicht Khronos 7 den Entwicklern die programmierbare Shaderpipeline (siehe dazu auch Kapitel 2.2.1) auf diesen Systemen. Allerdings stehen nur Vertex- und Fragmentshader zur Verfügung. Der Geometryshader, der in OpenGL 3.2 eingeführt wurde, wird in OpenGL ES 2.0 noch nicht bereitgestellt. Mobile Geräte haben im Vergleich zu Desktop-PCs einige Einschränkungen: weniger Speicher, weniger Rechenleistung, niedrigere Übertragungsgeschwindigkeiten und eine signifikante Abhängigkeit vom Stromverbrauch. Bedingt durch diese Einschränkungen, wurden bei der Adaption der OpenGL API einige Kriterien festgelegt, denen das neue OpenGL ES folgen musste. So wurden alle Redundanzen entfernt, die verschiedene Programmierstile ermöglichten. In den meisten Fällen wurde auf die effektivste Methode reduziert. Beispielsweise lässt sich Geometrie nur noch über vertex arrays spezifizieren. Immediate mode und display list wurden entfernt. Es wurden aber auch neue Features implementiert, wie zum Beispiel ein precision qualifier für Shader, durch den der Entwickler den Energieverbrauch und die Performance seiner Shader regulieren kann (siehe: [MGS09]) OpenGL ES Shading Language Wie schon im voranstehenden Kapitel erwähnt, liefert OpenGL ES mit der Version 2.0 eine programmierbare Shaderpipeline. Diese soll hier im Detail vorgestellt werden, da sie mit dem Programmieren von Shadern einhergeht. Die vollständige Pipeline ist in Abbildung 1 zu sehen. Die grau hinterlegten Kästen weisen diese Elemente als programmierbar aus. Im Einzelnen handelt es sich um die bereits angesprochenen Vertex- und Fragmentshader. 7 Entwickler von OpenGL ES und anderen APIs ( 7

9 Abbildung 1: OpenGL ES 2.0 Shaderpipeline aus [MGS09] [S.4] Der Vertexshader enthält programmierbare Methoden, die auf die Vertizes einer Szene angewandt werden. Als Input werden dem Vertexshader von der API Attributes, Uniforms und Sampler übergeben. Attributes sind Werte, welche die Eigenschaften einzelner Vertizes beschreiben. Beispielweise ihre Position oder Normale. In den Uniforms werden Konstanten geliefert, welche der kompletten Szene oder einem vordefinierten Objekt unterliegen. Darunter fallen unter anderem Lichtwerte oder Materialeigenschaften. Sampler sind spezielle Uniformtypen, die eine Textur enthalten. Als Output benutzt der Vertexshader Varying Variablen, die bei der Übergabe an den Fragmentshader für jedes Fragment interpoliert werden. Außerdem werden vordefinierte gl-werte ausgegeben. Eine Übersicht der In- und Outputs lässt sich Abbildung 2 entnehmen Abbildung 2: Schema: Vertexshader aus [MGS09] [S.5] Beim Primitive Assembly werden die Vertizes, die den Shadingprozess 8

10 durchlaufen haben, zu geometrischen Primitiven zusammengesetzt. Primitive sind beispielsweise Dreiecke oder Linien. Alle Primitive werden auf ihre Position im View-Frustum geprüft und falls notwendig geclippt oder verworfen. Danach werden die Vertizes in Bildschirmkoordinaten transferiert. Der letzte Schritt ist ein back-face-culling, bevor der nächste Schritt folgt: die Rasterisierung, bei der die Primitive in Fragmente aufgeteilt werden, wobei jedes Fragment mit seiner Bildschirmkoordinate genau einem Pixel entspricht. Der Fragmentshader ist der zweite programmierbare Teil der Pipeline. Er enthält entsprechende Methoden, die auf den, durch die Rasterisierung entstandenen, Pixeln ausgeführt werden. Der Shader bekommt als Input ebenfalls Uniforms und Sampler. Allerdings kann man ihm keine Attribute übergeben, da die zugehörigen Vertizes nicht mehr existieren, weil sie zu Fragmenten interpoliert wurden. Stattdessen bedient sich der Fragmentshader an den interpolierten Varying Variablen, die vom Vertexshader als Output übergeben wurden. Ein Schema der Ein- und Ausgaben ist in Abbildung 3 verdeutlicht. Abbildung 3: Schema: Fragmentshader aus [MGS09] [S.8] Nachdem die Fragmente den zweiten Shader durchlaufen haben, stehen ihnen noch verschiedene Per-Fragment Operationen bevor, bei denen entschieden wird, ob das Pixel gezeichnet werden muss oder nicht, da es zum Beispiel von einer anderen Anwendung überdeckt sein kann. Anstatt zu zeichnen wird der Wert entweder verworfen oder Farb-, Tiefen- oder Stencilinformationen in eine entsprechende Position im Framebuffer geschrieben (siehe: [MGS09]). 9

11 2.3 Shader-Theorie Shader: A custom shading and lighting procedure that allows the motivated artist or programmer to specify the rendering of a vertex or pixel. -RON FOSNER Geschichtliche Hintergründe Der Begriff des Shaders fiel zum ersten Mal im Jahr 1989 in Zusammenhang mit Pixars Rendersoftware RenderMan. Dieses Programm ermöglichte erstmals das Programmieren eines Teils der Renderpipeline. Die mit Hilfe dieser Software entstandene Arbeit bekam die Öffentlichkeit aber erst im Jahr 1995 in Form des Films Toy Story zu sehen. Mit wachsender Popularität der CGI- (computer-generated imagery) Filme und steigender Grafikkartenleistungen fand diese Technik Anklang in der Videospielindustrie. Softwareentwickler erkannten schnell das Potential und stellten immer höhere Anforderungen an die Hardware. Man wollte in Echtzeit das schaffen, was Pixars RenderMan-Shader in mehreren Monaten Renderzeit auf 117 SPARCStations 8 mit Toy Story geschafft hatte (siehe: [Fos03]). Sowohl OpenGL als auch das unmittelbare Konkurenzprodukt Direct3D förderten das Entwickeln von Shadern. Zu Beginn war nur das Programmieren von Pixelshadern möglich, doch programmierbare Vertexshadern folgten kurz danach. Die letzte Neuerung wurde in Form des Geometry Shaders von OpenGL 3.2 und Direct3D 10 eingeführt. Diese findet man nur auf modernen GPUs (siehe: [ogl]) Stand der Technik unter Betrachtung von: In diesem Abschnitt soll anhand drei moderner Beispielengines aufgezeigt werden, welche Shadereffekte und -möglichkeiten solche Systeme heutzutage bieten. Die Systeme sind alle für nicht-kommerzielle Anwendungen kostenlos und veröffentlichen ihre aktuellsten Featurelisten selbst. Irrlicht und Ogre (Object-Oriented Graphics Rendering Engine) sind plattformunabhängige, Echtzeit-3D Engines, die sowohl OpenGL als auch Direct3D unterstützen. Beide sind allerdings nicht für embedded oder mobile Systeme geeignet (siehe: [ogra] und [irra]). Die dritte Engine, die für mobile Geräte konzipiert ist, heißt SIO2 und ist eine Gaming-Engine für Android eingeführte Rechnerserie von Sun Microsystems 10

12 und ios. Die damit entwickelten Spiele können nach Angaben der Entwickler in Apples Mac Store und nach Windows portiert werden. Die Engine basiert auf der bereits in 2.2 vorgestellten OpenGL Adaption OpenGL ES (siehe: [sioa]). Irrlicht bietet in der programmierbaren Pipeline neben Vertex- und Fragmentshader auch Geometryshader an, welche in OpenGL ES noch nicht verfügbar sind. Zudem bietet es ein Partikelsystem an, mit dem Entwickler unter anderem Schnee, Rauch oder Feuer realisieren können. Die Engine ermöglicht die Darstellung transparenter Objekte mit Hilfe vier verschiedener Methoden. Zu den bereits implementierten Effekten zählen Bumpund Parallax Mapping, sowie Light-Maps. Außerdem können dynamische Schatten, sowie dynamische Lichter erzeugt werden, die eine per-pixel Beleuchtung vornehmen (siehe:[irrb]). Ogre stellt noch keine Geometryshader zur Verfügung, bietet aber auch eine programmierbare Pipeline mit Vertex- und Fragmentshader. Es verfügt ebenfalls über ein Partikelsystem und eine automatische Behandlung transparenter Objekte. Mit Ogre ist es zudem möglich, fullscreen Post-Processing Effekte zu realisieren. Bereits implementiert ist Bump- und Cube Mapping. Ogre ermöglicht dem Benutzer Materialwerte außerhalb des Codes zu definieren und zu übergeben (siehe: [ogrb] und [ogrc]). SIO2 bietet ebenfalls keine Geometryshader, da es für mobile Systeme ausgelegt ist. Es basiert allerdings auf OpenGL ES 2.0, welches mit dieser Version die Grafikpipeline für programmierbare (Vertex- und Fragment-) Shader eingeführt hat. SIO2 hat ein integriertes Partikelsystem und ermöglicht das Rendern in Textur, was beispielsweise für Mapping und Post- Processing vonnöten ist. Die Engine bietet eine Emulation des Stencil Buffers, welcher standardmäßig nicht in OpenGL ES verfügbar ist. Somit ist es unter Anderem möglich, shadow volumes und Reflektion zu realisieren. An Beleuchtungseffekten bietet SIO2 sowohl Per-Vertex als auch Per-Pixel Beleuchtung. Ebenfalls wird multi texturing für lightmaps unterstützt (siehe: [siob]). Unter Betrachtung dieser Featurelisten werden im Folgenden die Funktionalitäten verschiedener Effekte erläutert, die bei der Entwicklung eines modernen Enginesystems Berücksichtigung finden könnten. Im folgenden Kapitel 3 wird vorgestellt, welche Shader und Effekte AiRmob enthalten soll und wie diese realisiert wurden Beleuchtung Beleuchtung spielt in der Computergrafik eine zentrale Rolle. Da die Simulation oder das abstrakte Annähern an einen realitätsähnlichen Zustand einer beleuchteten Szene stets Bestandteil der Forschung war, gibt es auch viele Ansätze, an dieses Problem mit Shadern heranzugehen. Üblicherweise unterscheidet man zwischen vier verschiedenen Arten von 11

13 Licht, die ein Objekt beeinflussen (siehe: [Fos03] [S.34ff]): ambient lighting : Globales Licht, welches von keiner konkreten Lichtquelle ausgeht und alle Objekte einer Szene betrifft. Ambientes Licht ist ein Zusatzfaktor, der eine beleuchtete Szene realistischer Wirken lässt. Durch ihren Einfluss kann man beispielsweise kühle oder warme Grundeindrücke schaffen, die selbst bei natürlichem, weißem Licht eine entsprechende Wirkung haben. diffuse lighting : Gerichtetes Licht, dass von einer definierten Lichtquelle ausgeht. Diffuses Licht ignoriert generell die Oberflächeneigenschaften der angestrahlten Objekte, sowie die Blickrichtung des Betrachters. Ausschließlich diffus beleuchtete Objekte haben somit stets eine matte Oberfläche. Die Intensität des Lichtes ist ausschließlich abhängig vom Einfallswinkel des Lichtes. Im Falle einer statischen Szene verändert sich die Beleuchtung nicht, wenn der Betrachter sich darin bewegt. specular lighting : Konzentriertes Licht, welches Highlights auf den angestrahlten Objekten erzeugt. Das Licht wird ein einem Kegel von der Oberfläche reflektiert. Die Größe dieses Kegels ist abhängig von der Beschaffenheit der Oberfläche, der sogenannten shininess des Objektes. Die Position des Betrachters spielt bei diesem Licht ebenfalls eine entscheidende Rolle. Je nach Betrachtungswinkel kann man das spekulare Licht entweder gar nicht, nur teilweise, oder in seiner vollen Intensität sehen. emissive lighting : Zusätzlich erzeugtes Licht, welches bei einem selbst lumineszierenden Objekt auftritt. Die Farbinformation wird zusätzlich auf das auftreffende Licht addiert. Es handelt sich in erster Linie nicht um eine weitere Lichtquelle der Szene. Lumineszierende Objekte, die emissives Licht ausstrahlen, beleuchten damit keine anderen Objekte. Lokales Beleuchtungsmodell Beim lokalen Beleuchtungsmodel handelt es sich um eine simple, aber robuste Beleuchtungstechnik, die weder andere angeleuchtete Objekte, noch besondere Oberflächengegebenheiten berücksichtigt. Für eine Anwendung auf mobilen Geräten, die mit geringem Aufwand und ohne Raytracing ein passables Ergebnis liefern soll, ist diese Beleuchtung ideal. Das Modell arbeitet mit ungerichteten Lichtquellen, die eine unendliche Entfernung haben, vergleichbar mit der Sonne. Sie werden bestimmt durch den Lichtvektor, der die Richtung der parallel ausgesandten Strahlen angibt, sowie ambienter, diffuser und spekularer Farbwerte, die in der Regel einfarbig 12

14 gehalten werden und sich maximal in ihrer Intensität unterscheiden. Der Farbwert des Vertex oder Pixels (je nach Shading) berechnet sich durch folgende, vereinfacht dargestellte Formel (siehe: [Fos03]), die im Einzelnen noch erläutert wird: i total = k a i a + (k d i d + k s i s ) Der globale, ambiente Beleuchtungskoeffizient i a wird addiert mit der Summe der diffusen und spekularen Koeffizienten i d und i s über alle Lichtquellen. Multipliziert werden diese jeweils mit einem entsprechenden Reflexionskoeffizienten k zwischen 0 und 1. In der Praxis wird dieser Term durch die Intensität der einzelnen Farbwerte ausgedrückt, sodass kein zusätzlicher Wert benötigt wird. Diese Werte sind materialabhängig. Im Folgenden wird erläutert, welche Berechnungsmöglichkeit es für die jeweiligen Beleuchtungskoeffizienten gibt. Ambienter Beleuchtungskoeffizient i a = m a s a Der ambiente Term ist, wie oben beschrieben, unabhängig von jeglichen Lichtquellen. Daher nehmen diese auch keinen Einfluss auf die Berechnung des Wertes. Es werden lediglich die ambienten Material- m a und (Umgebungs-)Lichtwerte s a komponentenweise multipliziert, wobei s a global definiert ist. Diffuser Beleuchtungskoeffizient nach Lambert i d = ( n l )(m d s d ) Nach Lamberts Gesetz nimmt die sichtbar beleuchtete Fläche mit dem Cosinus ( cos ) des Einfallswinkels ab. Der cos dieses Winkels entspricht dem Skalarprodukt der (normierten) Vertexnormalen n mit dem (normierten) Richtungsvektor des Lichtes l. Abbildung 4 verdeutlicht dieses Prinzip. Um das gewünscht Ergebnis zu erreichen, wird dieser cos-wert mit dem Beleuchtungskoeffizienten multipliziert, welcher äquivalent zum ambienten berechnet wird, jedoch mit dem Unterschied, dass der diffuse Lichtwert s d abhängig von der Lichtquelle ist. Abbildung 4: Grafische Verdeutlichung von Lamberts Gesetz aus [DF07] 13

15 Um zu vermeiden, dass Seiten, die der Lichtquelle abgewandt sind, nicht beleuchtet werden, sollte an der Formel eine minimale Modifikation vorgenommen werden: i d = MAX(0, ( n l ))(m d s d ) Sie bewirkt, dass Winkel mit einem negativen Cosinus als 0 in die Berechnung eingehen und somit alle vom Licht abgewandten Seiten schwarz werden. Spekularer Beleuchtungskoeffizient nach Phong [BT75] i s = ( r v ) m (m s s s ) Wobei r der Reflexionsvektor ist, mit der Annahme, dass die Oberfläche glatt ist. v ist der Blickvektor vom Vektor zum Viewpoint. Die Idee dahinter besteht darin, dass das spekulare Licht immer intensiver wird, je kleiner der Winkel zwischen Betrachter und der Reflexion ist. Um zu ermöglichen, dass die Reflexion in einem Kegel zu sehen ist und nicht nur in einem Punkt, hat Phong die Glanzzahl ( shininess value ) m eingeführt. Diese liegt im Bereich zwischen 1 und 128. Je höher der Wert ist, desto kleiner wird der Kegel (siehe hierzu Abbildung 5). Abbildung 5: Phong Beleuchtung in 3ds Max mit verschiedenen Glanzwerten. Abbildung im Original von [dma] Der Reflexionsvektor berechnet sich wie folgt: r = 2(n l)n l n 2. Da von normierten Vektoren ausgegangen werden kann, kann man den Term wie folgt vereinfachen und erhält den normierten Reflexionsvektor: r = 2( n l ) n l. Nach Berücksichtigung der negativen Werte (äquivalent zum Diffusen Beleuchtungskoeffizienten) erhält man folgenden Term für die Berechnung des ambienten Beleuchtungskoeffizienten: i s = MAX(0, ( r v ) m )(m s s s ). 14

16 Verbesserung des Phong-Terms durch Blinn [Bli77] Um den hohen Rechenaufwand, der für die Ermittlung des Reflexionsvektors nötig ist, einzudämmen, hat Blinn folgende Modifikation an Phongs Formel angeführt: i s = ( n h ) 4m )(m s s s ). Neu daran ist der sogenannte Halbvektor h. Er wird berechnet mit: h = l+v l+v. l und v sind Ressourcen, auf die leicht zugegriffen werden kann. Außerdem sind die notwendigen Berechnungen vergleichsweise günstig. Die Idee von Blinn ist, einen Vektor einzuführen, der sich zur Normalen verhält, wie der Reflexionsvektor zum Blickvektor. Zwar unterscheidet sich die Variante im Ergebnis etwas von der ursprünglichen von Phong, aber durch eine Multiplikation der Glanzzahl mit 4 erhält man ähnliche Ergebnisse. Zudem kommt die Blinn-Formel etwas näher an die Realität heran. Diffuse Reflexion auf nicht-glatten Oberflächen Ansatz von Oren und Nayar. [ON92] Um eine diffuse Lichtreflexion auf verschiedenen Oberflächen zu simulieren, haben Oren und Nayar die Formel zur Berechnung des diffusen Beleuchtungskoeffizienten i d wie folgt modifiziert: i d = (m d s d )( n l )(A + B MAX[0, cos(φ r φ i )]sin(α)tan(β)) wobei gilt: A = 1 0, 5 σ 2 σ 2 +0,33 und B = 0, 45 σ 2 σ 2 +0,09. σ beschreibt die Unebenheit der Oberfläche. Je höher die Gradzahl, desto unebener ist die Oberfläche. Dieser Wert ist eine Materialeigenschaft. φ r φ i ist der Winkel zwischen Blickvektor und Lichtvektor auf dem Scheitelkreis um die Normale. Er lässt sich wie folgt ausdrücken: cos(φ r φ i ) = (v (n (v n))) (l (n (l n))) (siehe hierzu auch: [DV04]) Die beiden Winkel α und β werden beide bestimmt durch die Winkel θ v und θ l, welche den Winkel zwischen Normale und Blickvektor, sowie Normale und Lichtvektor beschreiben. α entspricht dem Größeren dieser beiden Winkel und β dem Kleineren. Mathematisch ausgedrückt bedeutet das: 15

17 θ v = acos(v n) und θ l = acos(l n) sowie: α = MAX(θ v, θ l ) und β = MIN(θ v, θ l ). Erweiterung des Models durch Spotlights Abbildung 6: Darstellung eines Spotlight. Aus [FK03] Eine Erweiterung dieser Beleuchtungsmodelle beinhaltet die Verwendung von Spotlights, welche sich grundsätzlich in zwei Eigenschaften von den bisherigen Lichtquellen unterscheiden. Zum einen haben sie neben der Richtung noch eine Position, von der der Lichtkegel ausgeht und zum anderen einen Winkel θ cut off, der angibt, wie groß der Bereich ist, der vom Spotlight abgedeckt wird. Alles außerhalb dieses Bereiches bleibt mit Ausnahme der ambienten Komponente unbeleuchtet (siehe Abbildung 6). Um herauszufinden, ob ein Punkt P im Lichtkegel des Spots liegt, benötigt man zwei Vektoren D und V. Beschreibt S die Position des Spotlight und V den Vektor von S zu P, dann berechnet sich V durch V = S + P. S und P sind die Vektoren vom Ursprung zu den entsprechenden Punkten. D ist der Richtungsvektor des Lichtes und als Konstante gegeben. Durch bilden des Skalarproduktes zwischen D und V erhält man den Cosinus des Winkel α. cos(α) = D V 16

18 Abbildung 7: Von einem Spotlight beleuchteter Punkt. Originalgrafik aus [FK03] Da θ cut off kleiner als 180 ist, kann man den cosinus mit dem von α vergleichen, um herauszufinden ob P im Bereich des Spotlight liegt. Dies ist der Fall, wenn cos(α) cos(θ cut off ) Ist α größer als 180, liegt P hinter dem Licht und muss unbeleuchtet bleiben (siehe: [FK03]). Abbildung 7 stellt dies dar. Mit dem Wissen, welcher Punkt innerhalb des Lichtkegels liegt, kann man diese beleuchten. Es ist allerdings möglich, dem Kegel etwas mehr Natürlichkeit zu verleihen, indem man den Rand nicht vollständig beleuchtet. Dies kann mit einem Exponenten e erreicht werden, den jede Lichtquelle als weitere Eigenschaft erhält. Die Intensität des Lichtes I wird mit folgender Rechnung ermittelt: I = cos(α) e Sie liegt im Bereich [0,1] und nimmt zur Mitte des Kegels hin zu. Je höher e gewählt wird, desto verschwommener wird der Kegelrand, bis die Leuchtkraft des Spotlights irgendwann gegen 0 strebt Cel-Shading Unter Cel-Shading oder Toon-Shading versteht man eine non-photorealistische Rendermethode, die oftmals in Comics oder comichaften Realisierungen verwendet wird. Ziel des Cel-Shadings ist es, eine Szene aussehen zu lassen, als sei sie per Hand gezeichnet, in Anlehnung an alte Animationsmethoden, die mit celluloid arbeiteten. Daher auch der Name Cel- Shading. Das gewünschte Ergebnis des Effekts besteht aus einem Zusammenwirken mehrerer Komponenten. Einen guten Toon-Effekt zu erzielen, ist in erster Hand Aufgabe des Modellierers, denn nicht jede beliebige Textur kann einfach mit einem Cel-Shading Effekt belegt werden (siehe: [cela]). 17

19 Abbildung 8: Abgestufte Beleuchtung am Teapot. Grafik von [celb] Dennoch gibt es Möglichkeiten diesen Effekt (bei angemessener Texturierung) zu begünstigen. Eine Methode ist das Abstufen der Beleuchtung und das Hinzufügen einer schwarzen Outline. Der Beleuchtungseffekt wird erreicht, indem eine per-pixel Beleuchtung durchgeführt und im Nachhinein anhand der Intensität der Beleuchtung des Pixels, gemessen am Winkel zwischen Oberflächennormale und Lichtvektor, eine Abstufung in drei bis vier Kategorien durchgeführt wird. Jede Kategorie bekommt eine festgelegte Intensität zugeordnet. So entsteht auf dem ganzen Objekt eine Helligkeitsaufteilung in lediglich drei bis vier Werte, was für klare Kanten sorgt und den gewünschten Cel-Shading Effekt bewirkt (siehe: Abbildung 8). Der nächste Schritt ist das Erstellen der Outlines, die den Toon-Effekt komplettieren (siehe: Abbildung 9). 18

20 Abbildung 9: Fertiges Cel-Shading am Teapot. Grafik von [celb] Die einfachste Methode dies zu erreichen, ist, die Rückseiten der Objekte in dicken, schwarzen Linien zu rendern (siehe: Abbildung 10) und das normale Renderbild darüber zu legen. Eine etwas kompliziertere Methode arbeitet auf dem Bild der fertigen Szene. Zudem werden die Tiefentextur und eine Normal-Map der Szene benötigt. Auf diese beiden Texturen wird ein Sobel-Filter angewandt, der die Kanten detektiert. Diese Kantenbilder werden in einem finalen Schritt mit dem Bild der Szene verrechnet (siehe: [celb]). Abbildung 10: Raster der back-face des Teapots. Grafik von [celb] 19

21 2.3.5 Schatten Um Schatten einer Szene darzustellen gibt es zwei populäre Methoden. Eine davon ist die des Shadow Mapping, welche für das Programmieren auf mobilen Geräten am besten geeignet ist. Das Verfahren besteht aus zwei Schritten, welche im Folgenden erläutert werden. Depth-Map erstellen Im ersten Schritt wird die Szene aus der Sicht der Lichtquelle gerendert und die Tiefenwerte z A ermittelt, welche den Abstand zur Lichtquelle beschreiben. Hierzu benötigt man die Objektkoordinaten aus der Lichtperspektive. Der Tiefenwert des Fragments errechnet sich durch z A = r/q. s t r q Diese Tiefenwerte werden in einer Textur gespeichert, der Depth-Map. Szene verschatten Mit Hilfe der Depth-Map kann nun im zweiten Schritt ermittelt werden, ob ein Fragment der Szene im Schatten liegt oder nicht. Hierzu wird die Szene aus der Sicht des Betrachters gerendert. Beim Ermitteln der Fragmentfarbe wird nun in der Depth-Map nachgeschaut, ob die Tiefe des aktuellen Fragments größer ist als die der Depth-Map an dieser Position. Um das zu ermitteln, müssen die Koordinaten wieder aus Sicht des Lichtes berechnet werden. Mit ihnen kann nun die tatsächliche Tiefe des aktuellen Fragments z B äquivalent zu z A bestimmt werden. z B = r/q Die Koordinaten (x, y) für den entsprechenden Texturzugriff auf der Depth- Map werden wie folgt berechnet: x = s/q y = t/q. Ist nun z B größer als z A, so liegt das Fragment im Schatten (siehe Abbildung 11) und wird dunkler oder schwarz gezeichnet (siehe [Mül11] und [LP09]). 20

22 Abbildung 11: Detektion von Schatten mittels einer Depth-Map. Grafik aus [Mül11] Mapping Mappingverfahren tragen dazu bei, Objekte plastischer erscheinen zu lassen. Mit Hilfe von Mapping ist es möglich, Objekte mit vergleichsweise wenigen Polygonen sehr hochauflösend aussehen zu lassen. Dies führt zu einem großen Performancegewinn bei nahezu gleichem visuellen Ergebnis. Im Folgenden wird das grundlegende Verfahren des Bump Mapping vorgestellt, sowie die erweiterte Variante Parallax Mapping. Beide Verfahren benötigen eine Normal-Map Textur, die auf verschiedene Arten erstellt und genutzt werden kann. Normal-Map Um Mappingverfahren zu realisieren, benötigt man immer eine Normal- Map. Dies ist eine Textur, in der die Normalenkoordinaten eines Objekts als RGB-Farbwerte gespeichert werden. Es ist üblich den Alpha-Kanal der Textur zu nutzen, um die Height-Map (Eine Textur mit den Höhenangaben der Vertizes) darin zu speichern (siehe [Ril09]). Es gibt verschiedene Möglichkeiten, eine Normal-Map Textur zu erstellen. Es gibt Plugins für Graphiksoftware wie Adobe Photoshop 9, mit deren Hilfe aus einer Modelltextur eine Normal-Map erzeugt werden kann (siehe [nvi]). Eine andere Möglichkeit ist das Verwenden des kostenlosen Programms Melody von Nvidia (siehe [mel]). Dieses Programm erstellt mit

23 tels zwei verschiedener Versionen eines Modells eine Normal-Map für dieses. Das erste Modell hat in der Regel eine vergleichsweise geringe Anzahl an Polygonen und wird vom Entwickler zum finalen Rendering verwendet. Das zweite sollte mit wesentlich mehr Polygonen modelliert sein, aber das gleiche Objekt repräsentieren. Es ist das Referenzmodell. Mit Hilfe der von Melody erstellten Normal-Map sieht das Arbeitsmodell durch Mapping nahezu so aus, als wäre es das teure Referenzmodell. Abbildung 12: Nvidia Melody mit Referenz- und Arbeitsmodell (siehe: [mel]) Ist bereits eine Height-Map des Modells vorhanden, kann aus dieser ebenfalls eine Normal-Map errechnet werden (siehe [Ril09]). Eine Normal-Map kann auf zwei verschiedene Arten erstellt werden: Object-Space und Tangent-Space. Die dritte Möglichkeit World-Space soll nur am Rande erwähnt werden, da sie nur für statische Objekte relevant ist. Die Wahl des Normal-Map Space wird durch die Verarbeitung in der Engine entschieden. Object-Space ist die günstigere Variante, jedoch funktioniert sie nur bei Objekten, die sich nicht verformen. Sich bewegende Objekte sind allerdings möglich. Object-Space Normal-Maps haben farblichen immer ein Regenbogenspektrum (siehe Abbildung 13). 22

24 Abbildung 13: Object-Space Normal-Map [sur] Abbildung 14: Tangent-Space Normal-Map [sur] Benutzt man Tangent-Space, wird der Aufwand des Mapping etwas größer, die gemappten Objekte können allerdings verformt werden. Die Normal- Map hat in diesem Fall einen intensiven Blaustich (siehe Abbildung 14). Bump Mapping Bump Mapping beschreibt das grundlegende Verfahren, eine Normal-Map auf ein Objekt anzuwenden. Je nachdem, welchen Normal-Map Space man in seiner Engine verwenden möchte, ist eine größere oder kleinere Zahl an Berechnungen nötig. Verarbeitet man Normal-Maps in Object-Space, so muss man lediglich die x-, y- und z-werte der Textur an der aktuellen Position auslesen und diesen Vektor anstelle der Oberflächennormalen für die Lichtberechnung einsetzen. Liegt die Normal-Map in Tangent-Space vor, ist es notwendig die Blickrichtung und den Lichtvektor mit Hilfe einer Matrix ebenfalls in Tangent-Space umzurechnen. Diese Matrix besteht aus Tangente, Binormale und Normale der Texturebene und kann mit Hilfe von drei Punkten in Weltkoordinaten, sowie deren Texturkoordinaten errechnet werden (siehe [jer]). 23

25 Parallax Mapping Parallax Mapping ist eine Erweiterung, die bei bewegten Objekten den räumlichen Eindruck weiter verstärkt. Für dieses Verfahren wird neben der Normal-Map auch eine Height-Map benötigt. Im Gegensatz zu normalem Bump Mapping wird jedem Fragment nicht mehr die Texturkoordinate an der eigenen Position zugewiesen, sondern es findet eine Verschiebung statt, die abhängig vom Blickwinkel des Betrachters ist. Dadurch entsteht eine kontinuierliche Änderung der Beleuchtung bei sich bewegenden Objekten. θ beschreibt den Winkel zwischen der Blickrichtung entlang der x-achse und der Normalen N. h gibt die Höhe an der aktuellen Texturposition an. Durch die Verschiebung der Texturkoordinate um u auf der x-achse erhält man den Wert der Normal-Map an einer Stelle, die wesentlich näher am eigentlichen Betrachtungspunkt liegt (siehe Abbildung 15). Abbildung 15: Annäherung des Blickpunktes auf die Textur mittels Parallax Mapping [Ril09] Analog zu u wird v, die Texturverschiebung auf der y-achse bestimmt. Dieses Verfahren liefert ebenfalls keine exakten, aber gut angenäherte Resultate der korrekten Lichtreflexion. Eine Verbesserung ist nur mittels Ray- Tracing und sogenanntem Relief Mapping möglich Image Post-Processing Unter Image Post-Processing (IPP) versteht man die Technik, eine fertig gerenderte und beleuchtete Szene als bildschirmfüllende Textur zu erzeugen und auf dieser weitere Effekte zu realisieren. Diese Effekte dienen oftmals dem Zweck, die Szene cinematisch oder auf andere Weise künstlerisch wirken zu lassen. Durch die Tatsache, dass die Szene als Textur vorliegt, ist es vergleichsweise einfach, in ein bereits funktionsfähiges System neue IPP- Effekte zu implementieren. Der folgende Abschnitt befasst sich mit zwei solcher Effekte, Blur und Bloom. Weitere Effekte sind beispielsweise 24

26 Depth of Field, Volumetric Light Scattering und Screen Space Ambient Occlusion (siehe: [lea]). Blur Blurring ist ein Effekt, der bewirkt, dass die Szene weichgezeichnet wird. In der Bildverarbeitung wird dieser Effekt meistens genutzt, um Unschärfe zu erzeugen oder Rauschen zu entfernen (siehe Abbildung 16). Abbildung 16: Entferntes Rauschen auf einem Bild mittels Gaussian Blur. Grafik von [wik] Es gibt verschiedene Ansätze von Blurring-Methoden. Die wohl populärste ist Gaussian Blur, welche auf der Gauß-Funktion beruht (siehe [del]). Im Folgenden wird erst einmal auf das Grundprinzip des Blurring anhand eines einfachen Algorithmus eingegangen, bevor das Gauß-Verfahren näher erläutert wird. Die Farbe des Pixels wird beim Blurring durch die Werte der Nachbarpixel errechnet. Eine offset - Variable bestimmt dabei, wie weit entfernt die Pixel sind, die für die Berechnung relevant sein sollen. Im einfachsten Fall werden die Werte der vier diagonalen Nachbarn aufaddiert und die Summe durch vier geteilt. Dieser Wert ist der neue Farbwert des Mittelpunktes. Blurring entsteht, nachdem jeder Pixel diesem Verfahren unterzogen wurde. Gaussian Blur Bei dieser fortgeschrittenen Version des Blurring werden nicht nur vier Nachbarpixel betrachtet, sondern jeder Nachbar bis zu dem festgelegten offset Radius. Mit Hilfe der Gauß-Funktion wird die Intensität dieser 25

27 Pixel gewertet. Es wird neben dem offset eine weitere Konstante σ benötigt, welche den Gauß Graphen beeinflusst. Die Gauß-Funktion lässt sich in zwei Parameter unterteilen (siehe [Ngu07]). Durch diese Unterteilung lässt sich der Algorithmus optimal steuern. Die erste Komponente x wird auf alle relevanten Pixel als Wertigkeit aufmultipliziert. Die zweite Komponente y x = 1 σ 2π y = e offset2 2σ 2 modifiziert die x-komponente schrittweise. Jedes Mal, wenn ein Pixel weiter Richtung Radius gerückt wird, wird x erneut mit y multipliziert. y wird ebenfalls schrittweise modifiziert, indem es mit seinem eigenen Quadrat multipliziert wird. Dadurch entsteht die für die Funktion typische Gauß Glocke (siehe Abbildung 17). Die aufaddierten, gewerteten Farbwerte werden am Ende durch die Summe der x-komponenten der Gauß-Funktion geteilt, um den finalen Farbwert des Mittelpunktes zu erhalten (siehe: [cal]). Abbildung 17: Gauß Glocke mit sigma = Grafik von [del] Bloom Der zweite Effekt, Bloom oder auch Light Bloom, bewirkt, dass stark beleuchtete Objekte in einer dunkleren Umgebung einen zusätzlichen Glüheffekt erhalten. Das simuliert das Verhalten von sehr hellen Objekten, in die das Auge oder eine Fotolinse hineinschaut (siehe [gim]). Abbildung 18 zeigt diesen Effekt an einem mit GIMP 10 aufgearbeiteten Foto. Um diesen Effekt zu erreichen, bedient man sich eines Tricks, der Blurring nutzt. Ein Objekt, welches einen Leuchteffekt erhalten soll, wird einfarbig 10 Kostenloses Bildbearbeitungsprogramm: 26

28 Abbildung 18: Bloom Effekt auf einer Fotografie. Grafik von [gim] gezeichnet und mehrfach einem Blurring unterzogen (mindestens zweimal mit verschiedenen Radien). Im dritten Schritt wird das Objekt nochmals normal gezeichnet und über das verschwommene Objekte gelegt. Am Rand entsteht dadurch ein Leuchteffekt in der vorher festgelegten Farbe (siehe: [MGS09]). Neben dieser Methode gibt es weitere Ansätze, die beispielsweise nur die hellsten Stellen oder Lichthighlights einer Szene verwischen und somit, durch Kombination mit der ursprünglichen Szene, heller leuchten lassen. 27

29 3 AiRmob Shader 3.1 Shaderkonzept Basierend auf den Recherchen zum Stand der Technik aktueller Engines wurde für AiRmob ebenfalls eine Liste von Effekten erstellt, die mittels Shader implementiert und dem Entwickler zur Verfügung gestellt werden sollen. Nachdem die Effekte im letzten Kapitel bereits in ihrer Funktionsweise vorgestellt wurden, soll jetzt das Konzept aufgezeigt werden, welches alle Effekte auf einer Engine vereint. Abbildung 19 zeigt dieses Konzept. Abbildung 19: Airmob Shaderkonzept 28

30 Die Idee hinter diesem Konzept ist es, möglichst alle Berechnungen in einem Hauptshader unterzubringen, um so mögliche Kombinationen realisieren zu können. Diese Kombinationen werden vom Entwickler (bzw. Benutzer) durch die Uniformvariablen lightingmode, shadowtoggle und mappingmode gesteuert. Diese Variablen können entweder direkt in den Settings im Code oder im User Interface zur Laufzeit geändert werden. Im Hauptshader befinden sich die Berechnungen für folgende Effekte: Beleuchtung Per-Vertex Per-Fragment Cel-Shading Shadow Mapping Mapping Bump Parallax Die Beleuchtung wird über die bereits angesprochene Variable lightingmode eingestellt. Diese steuert im Shader den entsprechenden Algorithmus an, welcher den daraus resultierenden Farbwert an die Ausgabe des Shaders übergibt. Mit der Variable use_spotlights legt der Entwickler fest, ob seine Lichter Spotlights oder ungerichtete Punktlichtquellen sind. Bei aktiviertem Shadow Mapping wird in einem zusätzlichen Shader eine Tiefentextur der Szene berechnet und als Depth-Map an den Hauptshader übergeben. In diesem findet die Schattenkalkulation statt. Der daraus resultierende Schattenfaktor kann auf jedes Ergebnis der gewünschten Beleuchtung multipliziert werden. Mittels mappingmode kann eines der beiden Mapping-Verfahren ausgewählt werden. Die Variable lässt den Nutzer zwischen Bump- und Parallax Mapping wählen. In beiden Varianten wird die Uniformvariable normalmap zur Berechnung herangezogen. Allerdings sollte für Parallax Mapping eine Height-Map im Alpha-Kanal vorliegen. Für IPP-Effekte wie Blur und Bloom werden zusätzliche Shader benötigt. Alle Algorithmen, die Blurring erzeugen, sind im entsprechenden Blurshader untergebracht. Die Auswahl des Verfahrens bestimmt der Benutzer mittels blurringmode. Alle nötigen Variablen werden als Uniform übergeben und können bei Bedarf verwendet werden. Im Gegensatz zu simplem Blurring verwendet der Gauß-Algorithmus zusätzlich eine sigma- Variable. Die Variable gaussdirection kann nicht vom Benutzer verändert werden und verändert lediglich die Richtung des Blurring. Durch den 29

31 Renderer wird der Shader je einmal mit horizontaler und vertikaler Richtung aufgerufen. Aktiviertes oder deaktiviertes Bloom steuert die Eingabetextur, auf welcher Blurring stattfindet. Ist Bloom deaktiviert, wird die gerenderte Szene aus dem Hauptshader übergeben und das Resultat des Blurring als Ausgabe auf dem Display dargestellt. Ist Bloom aktiviert worden, wird neben dem Hauptshader ein weiterer Bloomshader aufgerufen, der den Teil der Szene rendert, der den Bloomeffekt verursachen soll. Die gerenderte BloomTexture wird als Input an den Blurshader übergeben. Das Resultat wird mit dem des Hauptshaders addiert und ans Display übergeben. 3.2 Implemetierte Shader In diesem Abschnitt wird gezeigt, wie die in Kapitel 2.3 beschriebenen Effekte in den AiRmob Shadern implementiert wurden. Dazu werden diverse Variablen erläutert, die bestimmte Effekte steuern, sowie einzelne Techniken, die es möglich gemacht haben, mehrere Algorithmen zu kombinieren. Wie bereits in Kapitel 3.1 besprochen, findet der größte Teil der Berechnungen im Hauptshader statt. Die Uniformvariablen, die durch die Eingaben des Benutzers gesteuert werden, wurden ebenfalls in diesem Kapitel beschrieben. Alle weiteren Information über die Objekte, die Lichtquellen und die Welt, die für die Berechnungen benötigt werden, werden wie in Abbildung 19 gezeigt, übergeben. Beleuchtung Bereits im Vertexshader wird die Variable lightingmode genutzt um festzustellen, welches Beleuchtungsmodel angewandt wird, denn im Falle von Gouraud-Lighting findet die Berechnung schon auf der Vertexebene statt. Es wird für jede Lichtquelle die Funktion aufgerufen, welche die per-vertex Beleuchtung durchführt. Als Übergabe werden alle Parameter angegeben, welche die Lichtquelle definieren, sowie Normale und Position. vec4 temp_normal = u_inv_modelview_matrix vec4 ( a_normal, 0. 0 ) ; i f ( u_lightingmode == 1. 0 ) { vec4 temp_color = l i g h t C a l c ( [... ] ) ; i f ( u_light_num >= 1 ) { temp_color += l i g h t C a l c ( [... ] ) ; / / [... ] } } Die Verschachtelung geht bis zur achten Lichtquelle. Die Variable light_num gibt an, wie viele Lichtquellen aktiviert sind und wird von der 30

32 Engine übergeben. Wie bei allen Uniformvariablen, welche an einen Vertexshader übergeben werden, hat sie das Prefix u_. Die aufsummierten Lichtwerte werden final einmal mit dem globalen, ambienten Licht verrechnet und mit einer Varyingvariable an den Fragmentshader übergeben: temp_color += ( u_global_ambient_color u_material. ambient_color ) ; v_color = temp_color ; Die Varyingvariable ist durch den Prefix v_ ausgezeichnet. Uniformvariablen, die direkt an den Fragmentshader übergeben werden, tragen ebenfalls diesen Prefix, damit es nicht zu Komplikationen mit gleichnamigen Vertex-Uniformvariablen kommt. Für Phong-Lighting und Cel-Shading wird lediglich die transformierte Normale an den Fragmentshader übergeben: e lse i f ( u_lightingmode == 2. 0 u_lightingmode == 3. 0 ) { v_normal = temp_normal. xyz ; } Die Normale ist temporär als Vektor mit vier Werten gespeichert, um die Berechnung im Gouraud-Lighting zu vereinfachen. Im Fragmentshader findet wieder eine Abfrage statt, die ermittelt, welches Beleuchtungsmodell aktiv ist. Im Falle von Gouraud wird die übergebene und interpolierte Farbe nur noch mit der Textur des Objektes verrechnet und mittels der Übergangsvariablen computed_color an die Ausgabe des Shaders übergeben: i f ( v_lightingmode == 1. 0 ) { computed_color = v_color texture2d ( stexture, v_tc ) ; } Ist Phong-Lighting aktiviert, wird nun im Fragmentshader die eigentliche Beleuchtung durchgeführt. Äquivalent zur Gouraud Beleuchtung im Vertexshader wird die Beleuchtungsfunktion für jede Lichtquelle aufgerufen, der ambiente Beleuchtungsterm addiert und die Farbe mit der der Textur multipliziert, bevor der endgültige Wert mittels computed_color übergeben wird. Bei aktiviertem Cel-Shading wird der Winkel zwischen Normale und Lichtvektor berechnet und im Anschluss abgestuft. Diese Abstufungen sind in der Variablen intensity gespeichert und für den Benutzer leicht anzupassen. Für die Übergabe wird der Intensitätswert mit der diffusen Lichtund Materialfarbe, sowie der Texturfarbe verrechnet. Folgendes Codebei- 31

33 spiel zeigt die Berechnung anhand einer Lichtquelle: e lse i f ( v_lightingmode == 3. 0 ) { vec4 i n t e n s i t y ; vec3 norm_normal = normalize ( v_normal ) ; vec3 norm_lightvector = normalize ( v _ l i g h t. p o s i t i o n ) ; f l o a t LdotN = dot ( norm_ lightvector, norm_normal ) ; vec4 t e x _ c o l o r = texture2d ( stexture, v_tc ) ; i f ( LdotN > ) i n t e n s i t y = vec4 ( , , , 1. 0 ) ; e lse i f ( LdotN > 0. 5 ) i n t e n s i t y = vec4 ( 0. 5, 0. 5, 0. 5, 1. 0 ) ; e lse i f ( LdotN > ) i n t e n s i t y = vec4 ( , , , 1. 0 ) ; e lse i n t e n s i t y = vec4 ( , , , 1. 0 ) ; computed_color = i n t e n s i t y v_material. d i f f u s e _ c o l o r v _ l i g h t. d i f f u s e _ c o l o r t e x _ c o l o r ; } Ist eine Lichtquelle als Spotlight definiert, kann man den Kegel des Spots anzeigen lassen, indem die Variable usespotlights in den Einstellungen auf true gesetzt wird. Die Berechnung des Spots ist Teil der Phong- Beleuchtung. Der Effekt ist nur in dieser Kombination zu sehen, da bei anderen Modellen keine sinnvollen Resultate erzielt werden. f l o a t DdotV = dot ( norm_lightdirection, norm_lightvector ) ; i f ( DdotV >= cos ( radians ( lightangle ) ) ) s p o t _ f a c t o r = pow( DdotV, lightexp ) ; e lse s p o t _ f a c t o r = 0. 2 ; Liegt ein Fragment nicht im Spot, so wird sein Farbwert mit 0,2 multipliziert, um nicht die ganze Szene zu schwärzen. Damit der Rand des Kegels dennoch realistisch wirkt, wird auf alle inneren Farbwerte auch jeweils 0,2 addiert. Werte, die größer als 1 sind, werden von OpenGL automatisch auf 1 gesetzt. Schatten Um Schatten zu erzeugen wird neben dem Hauptshader noch ein weiterer Shader benötigt, der die Tiefentextur erstellt. In diesem wird die Szene aus 32

34 Sicht der Lichtquelle gerendert und die Tiefe als Farbe gesetzt. Die Position wird im Vertexshader mit der Modelviewprojection Matrix des Lichtes multipliziert. Zur Berechnung der Tiefeninformation wird diese Position zusätzlich mittels Varyingvariable an den Fragmentshader übergeben. void main ( ) { v_position = light_mvp_matrix a _ p o s i t i o n ; g l _ P o s i t i o n = light_mvp_matrix a _ p o s i t i o n ; } Im Fragmentshader wird die Tiefeninformation errechnet, auf das Intervall [0,1] skaliert und in einer Funktion für eine RGBA-Textur gepackt. void main ( ) { f l o a t d i s t a n c e = v_position. z / v_position.w; d i s t a n c e = ( d i s t a n c e ) / 2. 0 ; d i s t a n c e += ; gl_fragcolor = pack ( d i s t a n c e ) ; } Der Packalgorithmus ist Teil der dengine und wurde von Fabien Sanglard entwickelt (siehe [san]). vec4 pack ( f l o a t depth ) { const vec4 bitsh = vec4 ( , , , 1. 0 ) ; const vec4 bitmsk = vec4 ( 0, 1. 0 / , 1. 0 / , 1. 0 / ) ; vec4 comp = f r a c t ( depth bitsh ) ; comp = comp. xxyz bitmsk ; return comp ; } Im nächsten Schritt wird diese Textur an den Hauptshader übergeben, wo der Tiefenwert mit einer inversen Funktion im Fragmentshader wieder entpackt wird. 33

35 f l o a t getshadowfactor ( vec4 l i g h t Z ) { vec4 packedzvalue = texture2d ( shadowtexture, l i g h t Z. s t ) ; const vec4 b i t S h i f t s = vec4 ( 1. 0 / ( ), 1. 0 / ( ), 1. 0 / , 1. 0 ) ; f l o a t d i s t a n c e = dot ( packedzvalue, b i t S h i f t s ) ; return f l o a t ( d i s t a n c e >= l i g h t Z. r ) ; } Als Texturkoordianten werden die st-werte der Position des Fragments aus Sicht der Lichtquelle genutzt. Um diese zu ermitteln, muss zuerst im Vertexshader eine Transformation mit der Lichtmatrix vorgenommen und im Anschluss der Vektor im Fragmentshader durch den q-wert geteilt werden. Vertexshader i f ( u_shadowtoggle == 1 ) { v_shadow_coord = l_mvp_matrix a _ p o s i t i o n ; } Fragmentshader i f ( v_shadow_coord. q > 0. 0 ) { / / shadow c o o r d i n a t e s f o r t e x t u r e l o o k up vec4 l i g h t Z = v_shadow_coord / v_shadow_coord. q ; l i g h t Z = ( l i g h t Z ) / 2. 0 ; l i g h t Z += ; svalue = getshadowfactor ( l i g h t Z ) ; } Der Positionsvektor wird, wie im vorherigen Shader auch, auf das Intervall [0,1] skaliert und zur Artefaktvermeidung mit einem Bias versehen. Die Funktion getshadowfactor vergleicht den Tiefenwert der Textur mit dem realen Tiefenwert des aktuellen Fragments und gibt 0 als Wert zurück, falls das Fragment eine höhere Distanz hat und somit im Schatten liegt. Andernfalls ist der Wert 1. Dieser Wert in svalue wird nach dem vollständigen Rendern der Szene mit der finalen Farbe multipliziert. Somit wird die Farbe schwarz, falls das Fragment im Schatten liegt und behält seine Farbe, falls dies nicht der Fall ist. Der Alphawert bleibt von dieser Berechnung ausgeschlossen, damit verschattete Regionen nicht durchsichtig werden. vec3 computed_shadow_color = computed_color. rgb svalue ; gl_ FragColor = vec4 ( computed_shadow_color, computed_color. a ) ; 34

36 Mapping Jede Form des Mappings beeinflusst die Normalen. So liegt es nahe, durch die Wahl des Mappings zu entscheiden, wie die Normale gesetzt wird, welche im nachfolgenden Schritt an die Beleuchtung übergeben wird. In AiRmob sind Bump-, sowie Parallax Mapping möglich. Außerdem wird der Fall berücksichtigt, dass Mapping deaktiviert ist und die Vertexnormalen per Attribute übergeben werden. Letzteres wird für Gouraud-Lighting vorausgesetzt, da Texturnormalen nur per Fragment ausgelesen werden. Mapping ist also nur möglich, wenn Phong Beleuchtung aktiviert ist. Dem Beleuchtungsterm wird immer eine Normale übergeben, welche in der Variablen normal gespeichert wird. Bei deaktiviertem Mapping ist dies die vom Vertexshader übergebene und interpolierte Vertexnormale, welche bereits mit der transponierten Inversen der Modelview-Matrix verrechnet wurde. i f ( v_mappingmode == 0. 0 ) { normal = v_normal ; } Im Falle von Bump Mapping wird anstelle der Vertexnormalen die Normale genommen, welche in der Normal-Map Textur an der Stelle des Fragments gespeichert ist. Die Textur muss in Object-Space erstellt sein. e lse i f ( v_mappingmode == 1. 0 ) { normal = texture2d ( normalmap, v_tc ). rgb ; } Beim Parallax Mapping muss die Texturkoordinate angepasst werden. Um die Verschiebung approximieren zu können, wird die interpolierte Vertexnormale genutzt und der Winkel zwischen ihr und dem Vektor zwischen der Kamera im Ursprung und der Fragmentposition entlang der x- und y-achsen errechnet. e lse i f ( v_mappingmode == 2. 0 ) { f l o a t h = texture2d ( normalmap, v_tc. s t ). a ; vec3 xpos = vec3( v_position. x, 0. 0, v_position. z ) ; vec3 ypos = vec3 ( 0. 0, v_position. y, v_position. z ) ; f l o a t deltau = tan ( acos ( dot ( xpos, v_normal ) ) ) h ; f l o a t deltav = tan ( acos ( dot ( ypos, v_normal ) ) ) h ; vec2 d e l t a = vec2 ( 0. 0, 0. 0 ) ; d e l t a. s = v_tc. s + deltau ; d e l t a. t = v_tc. t + deltav ; normal = texture2d ( normalmap, d e l t a ). rgb ; } 35

37 Die Höhe wird aus der Height-Map entnommen, welche im Alpha-Kanal der Normal-Map gespeichert sein muss. Die resultierende Verschiebung wird in deltau und deltav zwischengespeichert und auf die aktuelle Texturkoordinate addiert. Blur Wie dem Konzept zu entnehmen ist, findet Blurring in einem eigenen IPP- Shader statt, welcher die fertig gerenderte Szene als Textur erhält. Dies ist notwendig, da auf Informationen der jeweiligen Nachbarpixel zugegriffen werden muss, was in den von OpenGL ES verfügbaren Vertex- und Fragmentshadern nicht möglich ist. Da auf der Textur, welche in der Auflösung des Displays vorliegt, gearbeitet wird, finden alle Berechnungen im Fragmentshader statt. Im Vertexshader wird nur die Position transformiert und die Texturkoordinaten interpoliert an den Fragmentshader übergeben. In diesem wird durch die dafür zuständige Uniformvariable blurringmode bestimmt, welcher Algorithmus angestoßen wird. Beim simplen Blurring wird die vom Benutzer festgelegte offset-variable abhängig von der Auflösung umgerechnet... f l o a t x _ o f f S e t = u _ o f f S e t / f l o a t ( width ) ; f l o a t y _ o f f S e t = u _ o f f S e t / f l o a t ( height ) ;... und mit dieser die Daten der Nachbarn aus der Textur gelesen. Als Nachbarn gelten die vier Pixel, die im entsprechenden Abstand auf der Diagonalen durch den aktuellen Pixel liegen. Hier am Beispiel des oberen, linken Nachbarn: vec4 upperleftsample = texture2d ( rendertexture, vec2 ( v_tc. x x_offset, v_tc. y + y _ o f f S e t ) ) ; Die Farbwerte der vier Nachbarn werden im letzten Schritt gemittelt und an computed_color übergeben. Diese Variable enthält stets das Ergebnis der Kalkulation der Blurring-Algorithmen und wird am Ende des Shaders an die Farbausgabe übergeben. computed_color = ( lowerleftsample + upperleftsample + upperrightsample + lowerrightsample ) / 4. 0 ; Im Fall von Gaussian Blur wird der Shader zweimal aufgerufen. Im ersten Durchlauf horizontal und im zweiten vertikal. Dies wird mit der Uniformvariablen gaussdirection gesteuert, welche im Renderer vor der zweiten Übergabe und dem zweiten Aufruf des Shaders geändert wird. 36

38 Renderer.java i f ( s e t t i n g s. blurringmode == 1) { GLES20. glclear ( GLES20. GL_DEPTH_BUFFER_BIT GLES20. GL_COLOR_BUFFER_BIT ) ; gaussdirection = 1 ; GLES20. gluniform1f ( gdirloc0, gaussdirection ) ; drawfullscreenquad ( postprocessingtexture, mblurprogram ) ; } Abhängig von dieser Richtung wird im Shader der Richtungsvektor und die Pixelgröße berechnet, welche von der Höhe oder Breite der Auflösung abhängt. i f ( u_gaussdirection == 0. 0 ) { p i x e l S i z e = 1. 0 / f l o a t ( width ) ; d i r e c t i o n _ v e c = vec2 ( 0. 0, 1. 0 ) ; } e lse i f ( u_gaussdirection == 1. 0 ) { p i x e l S i z e = 1. 0 / f l o a t ( height ) ; d i r e c t i o n _ v e c = vec2 ( 1. 0, 0. 0 ) ; } Im ersten Schritt der Berechnung wird die Farbe des aktuellen Pixels aus der Textur der Szene gelesen, gewichtet, der Divisor erhöht und die Gaußglocke für die nächsten Werte erzeugt: colorsum += texture2d ( rendertexture, v_ t c ) incrementalgaussian. x ; d i v i s o r += incrementalgaussian. x ; incrementalgaussian. xy = incrementalgaussian. yz ; Im Anschluss werden die Werte der Nachbarelemente ermittelt und gewichtet. Dazu wird mittels einer Schleife über alle Werte sowohl positiv als auch negativ gegangen und mit jedem Schritt gewichtet, der Divisor erhöht und die Gaußglocke erweitert. for ( f l o a t i = 1. 0 ; i <= u _ o f f S e t ; i ++){ colorsum += texture2d ( rendertexture, ( v_tc ( i p i x e l S i z e d i r e c t i o n _ v e c ) ) ) incrementalgaussian. x ; colorsum += texture2d ( rendertexture, ( v_tc + ( i p i x e l S i z e d i r e c t i o n _ v e c ) ) ) incrementalgaussian. x ; d i v i s o r += ( 2. 0 incrementalgaussian. x ) ; incrementalgaussian. xy = incrementalgaussian. yz ; } 37

39 Danach wird der aufsummierte Farbwert durch den Divisor geteilt und für die Ausgabe bereitgestellt. computed_color = colorsum / d i v i s o r ; Bloom Für Bloom können verschiedene Shader genutzt werden, die die Szene oder einen Teil der Szene rendern. Das Vorgehen wird im Folgenden am Beispiel eines simplen Shaders beschrieben, welcher die komplette Szene einfarbig und ohne zusätzliche Effekte rendert. Ist Bloom aktiviert, wird im Renderer eine Funktion aufgerufen, welche die Szene mittels des ausgewählten Bloomshaders rendert. Für dieses Beispiel erhält der Shader standardmäßig Farbe und Position der Vertizes, die Modelviewprojection Matrix, sowie eine mögliche Textur und deren Texturkoordinaten. Möchte man einen anderen Shader für das Prerendering nutzen, so muss man die benötigten Variablen in der Methode drawmodelforbloom() übergeben. Für spekulares Bloom sind die Übergaben schon vorhanden. Das Ergebnis dieses Prerendering-Durchlaufs wird immer in einer Fullscreen- Textur gespeichert, da es im nächsten Schritt geblurrt wird. Das setzt voraus, dass für einen erfolgreichen Bloomingeffekt auch immer Blur aktiviert sein muss. Die Wahl der Blurmethode, sowie der nötigen Parameter, liegt weiterhin beim Benutzer. Die Wahl hängt von der vorliegenden Szene sowie den gewünschten Ergebnissen ab. Im letzten Schritt wird die Szene wie gehabt mit dem Hauptshader gerendert, als Textur in postprocessingtexture gespeichert und das Ergebnis mit der vorbereiteten und geblurrten Szene kombiniert. Renderer.java GLES20. glenable ( GLES20.GL_BLEND ) ; GLES20. gldepthmask ( f a l s e ) ; GLES20. gldisable ( GLES20. GL_CULL_FACE ) ; GLES20. glblendfunc ( GLES20. GL_ONE, GLES20. GL_ONE_MINUS_SRC_ALPHA ) ; i f ( s e t t i n g s. bloom ) { drawfullscreenquad ( bloomresulttexture, mfullscreenprogram ) ; GLES20. glclear ( GLES20. GL_DEPTH_BUFFER_BIT ) ; } drawfullscreenquad ( postprocessingtexture, mfullscreenprogram ) ; GLES20. gldisable ( GLES20.GL_BLEND ) ; GLES20. gldepthmask ( true ) ; GLES20. glenable ( GLES20. GL_CULL_FACE ) ; 38

40 3.3 Erweiterbarkeit Diese Arbeit und das ganze Projekt AiRmob legt den Grundstein für ein Augmented Reality Framework auf mobilen Androidgeräten. Durch die Austauschbarkeit in jeder Hinsicht des Systems ist es sehr flexibel und erweiterbar. Auch im Bereich der Shader können vergleichsweise sehr einfach bereits geschriebene Shader, die einen schon vorhandenen Effekt erzeugen, integriert werden. Dazu muss lediglich der Pfad zum Shader in die vorgesehene Variable eingetragen und die Namen der Übergaben angepasst werden. Neu benötigte Variablen müssen in die Übergabemethoden im Renderer integriert werden. Wie welcher Shader zugeordnet werden muss, wird in Abschnitt 4.2 beschrieben. Eine weitere einfache Möglichkeit einen Effekt durch einen eigenen Algorithmus zu erzeugen ist, ihn in den entsprechenden Shader zu implementieren und durch eine neue Settingvariable zugänglich zu machen. So belegt beispielsweise Bump Mapping die 1.0 und Parallax Mapping die 2.0 für mappingmode. Integriert man ein eigenes Mappingverfahren, so kann man den entsprechenden Aufruf im Shader mit mappingmode = 3.0 belegen. 39

41 4 Framework Airmob 4.1 Architektur Autoren: Philipp Brandt, Florian Kathe, Nils Lichtenberg und Axel Peter Framework Renderergebnis Empfängt Kamerabilder und verknüpft diese mit Engine und Tracker. Kamerabild Engine Verarbeitet Szene und Einstellungen zu gerendertem Bild View- und Projectionmatrix Tracker Berechnet die 3D- Pose eines angegebenen Objekts im Kamerabild Shader Rendert verschiedene unter Berücksichtigung übermittelter Werte Abbildung 20: Systemarchitektur von AiRmob In Abbildung 20 wird die Systemarchitektur des Frameworks grob in die einzelnen Teilarbeiten aufgeteilt, dargestellt. Im Grunde ergibt sich hier eine Verarbeitungsschleife, die parallel zur eigentlichen Anwendungslogik einer App auf Basis des Frameworks abläuft. Der Einstieg in die Schleife geschieht an der Komponente Framework. Hier wird nach einigen Initialisierungsschritten das Kamerabild empfangen und kontinuierlich an den Tracker weitergegeben. Der Tracker sucht in jedem Kamerabild, was er bekommt, nach einem vorher angegebenem Marker oder Textur. Wird eine Übereinstimmung gefunden, ist der nächste Schritt, die Lage des Objektes im Kamerabild zu bestimmen. Aus dieser Lage kann dann eine 3D Pose (Viewmatrix) bestimmt werden, die im Framework dann weitergegeben wird. Zusätzlich wird bei der Initalisierung des Trackers noch eine Projectionmatrix berechnet, die dann auch in jedem Schleifendurchlauf an die Engine weitergegeben wird. Die Engine zeichnet die vom Programmierer angelegte Szene. Dazu wird die vom Tracker angereichte View- und Projectionmatrix genutzt, um die 3D-Objekte korrekt zur realen Welt zu platzieren. Mit diesen und aus der Szene ermittelt die Engine sämtliche zu zeichnenden Werte und übergibt sie an die Shader, um sie zu zeichnen. 40

42 Die Shader nehmen je nach ihrer Aufgabe alle benötigten Werte entgegen und berechnen die gewünschten Effekte. Bei mehreren Auswahlmöglichkeiten zu einem bestimmten Effekt (bspw. Beleuchtung), werden vom Benutzer festgelegte Entscheidungen mittels Variablen übermittelt. Die durch die ausgewählten Effekte berechneten Farb- oder Tiefenwerte werden wieder an den Renderer zurückgegeben. Die Ergebnisse der verschiedenen Shader werden verknüpft und das finale Renderergebnis an das Framework übermittelt. Das Renderergebnis wird anschließend in der Frameworkkomponente mit dem Livekamerabild überlagert, wodurch sich das fertige Ergebnis eines Verarbeitungsdurchgangs ergibt. 4.2 Schnittstellen zwischen Renderer und Shadern Autoren: Philipp Brandt und Axel Peter Zum Zeichnen der Szene müssen den verschiedenen Shadern von der Engine sämtliche dafür benötigten Werte und Texturen übermittelt werden. In der AiRmob-Engine gibt es einen festen Ablauf bestehend aus austauschbaren Shadern. Dabei benötigen die Shader teilweise die Ergebnisse anderer Shader. Die Funktionsweisen und die Theorie hinter den einzelnen Shadern wurde in dieser Arbeit näher erläutert, während der Renderablauf und die Engine in der Arbeit von Axel Peter beschrieben werden. Es werden jeweils ein Vertex- und Fragmentshader für jede Aufgabe verwendet. Diese Aufgaben sind in der AiRmob-Engine zum einen das eigentliche Zeichnen in den Hauptshadern, das Zeichnen von Texten in den Textshadern, das Zeichnen einer Pickingtextur in den Pickingshadern, das Zeichnen der Modelle als Outlines in den Outlineshadern sowie das Erstellen der Tiefentexturen in den DepthShadern. Außerdem werden noch zusätzliche Shader für das Post-Processing verwendet. Im Folgenden sollen diese Shader kurz mit ihrem benötigten Input und individuellen Output vorgestellt werden. Hauptshader Im Hauptshader werden alle Berechnungen auf Vertex- und Pixelebene ausgeführt, die nicht dem Post-Processing entsprechen. Hierzu zählen Beleuchtung, Schatten und Mapping. Die Pfade der Hauptshader sind in den Variablen mainvertexshader und mainfragmentshader gespeichert. Die Funktionalität dieses Shaders ist durch den Benutzer steuerbar. Er hat die Auswahl zwischen drei verschiedenen Beleuchtungsmodellen (mit oder ohne Spotlighteinschränkung), aktiviertem oder nicht-aktiviertem Schatten, sowie Bump-, Parallax- oder keinem Mapping. Diese Effekte sind - bis auf wenige Ausnahmen - frei kombinierbar. Die Elemente sind bei Bedarf frei erweiterbar, indem den Übergabeparametern ungenutzte Werte mit- 41

43 gegeben werden, die man im Hauptshader mit eigenen implementierten Algorithmen abfängt. Neben den Shadern main.vert und main.frag wird ein weiteres Shaderpaar onelight_main.vert und onelight_main.frag zur Verfügung gestellt, welches alle Berechnungen für genau eine Lichtquelle durchführt. Diese Shader sind speziell für schwächere Hardware oder Szenen, die nur eine Lichtquelle verwenden, konzipiert. Wie teuer die Berechnung mehrerer Lichtquellen ist, wird in Kapitel 6.1 gezeigt. Die Implementation zielt darauf ab, verschiedene Modelle leicht kombinierbar zu gestalten und trotzdem Erweiterbarkeit möglich zu machen. Depthshader Der Depthshader arbeitet dem Hauptshader zu und ist deshalb von diesem abgekapselt. Er erstellt eine Textur der Tiefenwerte der Szene aus Sicht der Lichtquellen. Diese wird benötigt um Schatten zu realisieren. Da zuerst eine vollständige Textur der Szene vorliegen muss, bevor einzelne Objekte final gerendert werden können, ist es nicht möglich, diese Berechnung mit dem Hauptshader zu vereinen. Der Shader wird, falls für eine Berechnung notwendig, automatisch aktiviert und bedarf keiner weiteren Einstellung durch den Benutzer. Deaktiviert dieser in den Settings alle Modi, die die Tiefentextur nicht benötigen, so wird der Shader nicht aufgerufen, um unnötige Performanceeinbußungen zu vermeiden. Die Pfade zu diesem Shader werden in den Variablen depthvertexshader und depthfragmentshader abgelegt. Blur- und Bloomshader Beim Blurshader handelt es sich um einen IPP Shader, der die Textur der fertigen Szene benötigt, um darauf arbeiten zu können. Wie bei allen IPP Shadern ist es somit nicht möglich, ihn in den Hauptshader zu integrieren. Der Benutzer steuert über Eingaben den Blurring Effekt. Er hat die Auswahl zwischen einem einfachen Blurmodell und dem Modell nach Gauß. Beide Algorithmen benötigen die Eingabe eines Radius. Bei letzterem wird zusätzlich ein sigma-wert übergeben. Die Pfade für diesen Shader befinden sich in blurvertexshader und blurfragmentshader. Bei deaktiviertem Blurring wird dieser Shader ebenfalls, zur Schonung der Performance, nicht aufgerufen. Die Implementation von Bloom sieht vor, dass eine Textur erstellt wird, welche durch Blurring modifiziert und mit der regulären Fullscreen-Textur vereint wird. Durch aktiviertes Blooming wird der Blurshader automatisch zur Verfügung gestellt. Die Auswahl der Bloom-Textur kann durch unterschiedliche Algorithmen variieren. Das Erzeugen dieser Textur wird durch einen eigenen Shader gesteuert, der bei aktivem Bloom aufgerufen wird. Er ist, wie alle Shader, austauschbar und seine Pfade in den Variablen bloom- VertexShader und bloomfragmentshader gespeichert. 42

44 Text-, Picking- und Outlineshader Die Shader, die zum Zeichnen von Texten, der Pickingtextur und von Outlines verwendet werden, sind alle sehr simpel und berechnen einfach die Position der Vertizes. Für die Farbe setzten sie konstant einen mitgegebenen Farbwert. Die AiRmob-Engine verwendet unterschiedliche Shader für diese Aufgaben, um ein Erweitern dieser zu erleichtern. Falls beispielsweise texturierter Text gewünscht ist, müssten dazu lediglich die Textshader ausgetauscht und die Textur zusammen mit den Texturkoordinaten im Renderer übergeben werden. Sie können in den Einstellungen über in den Strings pickingvertexshader, textvertexshader, outlinevertex- Shader (für die Fragmentshader entsprechend) verändert werden. Fullscreenshader Der Fullscreenshader wird zum Zeichnen von bildschirmfüllenden Rechtecken benutzt, also beispielsweise nach Post-Processing-Effekten. Die in den Variablen fullscreenvertexshader und fullscreenfragmentshader angegebenen Pfade werden für diese Shader genutzt. Die Standardimplementierung setzt einfach den Wert der Textur als Farbe. Alle Shader können in den Einstellungen unter den jeweils genannten Variablen ausgetauscht werden. Neue Implementationen müssen dann die gleichen Bezeichnungen für Uniforms und Attributes verwenden. 43

45 5 Techdemo Autoren: Philipp Brandt, Florian Kathe, Nils Lichtenberg und Axel Peter Die Techdemo dient dazu, die Fähigkeiten des Frameworks auf der technischen Ebene zu präsentieren. Hierzu gehören Funktionalitäten, die die AiRmobActivity direkt anbietet, verschiedene Shader, Leistungen der Engine und Trackingverfahren. Renderer und Tracker werden im Hauptmenü festgelegt und anschließend geladen. Je nach Renderer sind verschiedene Voreinstellungen der Shader möglich, zur Laufzeit können diese aber stets geändert werden. Es sind dabei verschiedene Renderer verfügbar, die jeweils vom AiRmob-Renderer abgeleitet sind und die Funktion putscene zum Anlegen der Szene überschreiben. Die Szenen und Einstellungen dieser Renderer sollen verschiedene Effekte und Vorgehensweisen der AiRmob-Engine demonstrieren. Im Folgenden sollen die verschiedenen auswählbaren Renderer und das was sie jeweils demonstrieren sollen kurz erläutert werden. Screenshots der Ergebnisse werden in Abschnitt 6.1 dieser Arbeit dargelegt. Free Choice Nach der Auswahl dieses Renderers erscheint ein weiteres Menü. In diesem kann eines der externen Modelle gewählt werden, die sich im Ordner models befinden. Dieses wird mit den Standardeinstellungen der AiRmob-Engine sowie einer Standardlichtquelle gezeichnet. Insbesondere können hier natürlich auch die OBJ-Dateien eigener Modelle schnell und unkompliziert getestet werden. Tres Amigos Die Szene dieses Renderers besteht aus drei der vorgegebenen Modelle der AiRmob-Engine sowie einer Lichtquelle. Bei den Modellen handelt es sich um den Blender-Affenkopf Suzanne, den Utah-Teapot sowie einem einfachen Würfel, also Instanzen der Klassen modelsuzanne, modelteapot und modelcube. Diese werden in rot, grün und blau nebeneinander angezeigt. Die Lichtquelle bewegt sich um den Mittelpunkt und in den Einstellungen sind Spotlights aktiviert. Hier soll der Umgang mit den vorgegebenen Modellen sowie die Lichteffekte präsentiert werden. Transparent Businesses Die Modelle des vorherigen Renderers werden in diesem leicht versetzt hintereinander und transparent gezeichnet. Dabei würden sie von vorne nach hinten gezeichnet werden, falls die Sortierung nach Distanzen deaktiviert ist. Dies würde zu Fehlern führen, die verdeckten Modelle wären nicht sichtbar. Bei aktivierter Sortierung nach Distanzen ist die Ansicht korrekt. Die Sortierung kann im Menü de-/aktiviert werden. Dementspre- 44

46 chend soll in diesem Renderer die Sortierung transparenter Objekte nach Distanzen demonstriert werden. 100 Monkeys Dieser Renderer zeichnet 100 Instanzen der Klasse modelsuzanne, also des Blender-Affenkopfes, in einem Raster verteilt um den Marker. Hier können die verschiedenen Picking-Einstellungen verändert und getestet werden. Trackingtest Es wird ein einfaches Rechteck in Markergröße gezeichnet. Auf dieses wird eine Textur gelegt, die einen rötlichen Rahmen passend auf den Marker legt, sowie ein Kreuz in dessen Mitte. Animation In diesem Renderer wird eine Animation importiert und angezeigt. Diese zeigt einen Würfel, der sich Frame für Frame zu einer Kugel verändert. Durch Tippen auf den Bildschirm lässt sich die Animation pausieren. Sie befindet sich in einer Endlosschleife. Tres Amigos with multiple lights Hier wird die Szene des Renderers Tres Amigos um mehrere Lichtquellen ergänzt. Dazu wird die maximale Anzahl der Lichtquellen erhöht und der Szene neue hinzugefügt. Bumpmapping In diesem Renderer wird das Bumpmapping gezeigt. Es kann über die normalen Einstellungsmöglichkeiten zu Paralaxmapping umgestellt werden. Texts In diesem Renderer werden die beiden Textarten präsentiert. Zum einen ist ein weißer Text, der statisch zur Kamera gerichtet ist, zu sehen. Zum anderen sind ein blauer und ein grüner Text im 3D-Raum sichtbar. Diese drei Texte können über das Menü zur Laufzeit durch Eingabe eines neuen Textes verändert werden. Neben den verschiedenen Renderern können wie bereits erwähnt auch verschiedene Tracker gewählt werden. Der markerbasierte Tracker von AndAR ist als Defaultwert festgelegt. Wählt man den AiRmob-Tracker, welcher auf Featuredetection basiert, muss diesem noch ein Imagetarget zugewiesen werden. Das kann entweder aus der Anwendung heraus und von der SD- Karte des Geräts geladen oder mit der Kamera selbst aufgenommen werden. Schießt man ein neues Foto, kann dieses entweder komplett als Imagetarget verwendet oder per Hand zugeschnitten werden. Dazu werden im Originalbild vier Punkte definiert, die die Eckpunkte des Ergebnisbildes 45

47 angeben. Abbildung 21 zeigt ein Beispiel. Das aufgenommene Bild wird zunächst auf Displaymaße gestreckt. Die Eckpunkte werden dann gegen den Uhrzeigersinn, beginnend in der oberen linken Ecke, festgelegt. Zur Weiterverarbeitung werden die Punkte zuletzt von Display- auf Bildmaße umgerechnet. Abbildung 21: Zuschneiden eines Imagetargets Bevor eine Szene endgültig geladen wird, muss der Benutzer noch die Kameraauflösung einstellen. Dazu kann er entweder drei vom Framework vorgeschlagene Werte benutzen oder manuell einen Eintrag aus den von der Kamera unterstützten Einstellungen festlegen. In Abbildung 22 ist eine Beispielszene der Techdemo zusammen mit dem Optionsmenü zu sehen. Am oberen Bildschirmrand werden die Auflösung der Kamera und die in der Szene vorhandene Anzahl an Dreiecken, Vertices und Indices angezeigt. Am unteren Rand werden die aktuelle Tracking- und Framerate, die maximal mögliche Framerate ohne Synchronisierung sowie deren Durchschnittswerte angezeigt. Die Durchschnittswerte können vom Benutzer zu jeder Zeit zurückgesetzt werden, z. B. um passende Werte zu einer neuen Shadereinstellung zu erlangen. Diese Einstellungen sind ebenfalls im Optionsmenü zu erreichen. Durch Auswahl von ToggleFreeze wird das Kamerabild entweder angehalten oder wieder fortgeführt. Unter Pipeline können die vom Framework angebotenen Pipelinevarianten ausgewählt werden. Zuletzt ist unter Description eine Beschreibung der aktuellen Szene zu finden. 46

48 Abbildung 22: Optionen und Ansicht der Techdemo Um die Eingabeoperationen des AiRmob-Frameworks zu testen, kann ein 3D-Objekt angewählt und dann rotiert oder verschoben werden. Abbildung 23 zeigt das Auswahlmenü. Im Hintergrund ist zu sehen, wie die Markierung bereits vom Marker wegbewegt und rotiert wurde. Abbildung 23: Objektinteraktion Die Techdemo dient aufgrund ihrer Eigenschaften als Testmittel um die Performance der Shader zu evaluieren. 47

49 6 Schluss 6.1 Auswertung In diesem Abschnitt werden die erzielten Effekte anhand von Screenshots präsentiert. Weiterhin wird reflektiert, welche Methoden gute Ergebnisse erzielt haben und in welchen Bereichen Verbesserungen nötig oder möglich sind. Außerdem wird aufgezeigt wie sich die Effekte auf die Leistung der Hardware ausüben. Hierzu wurde für jeden Test die Framerate der Engine unter den gleichen Bedingungen notiert und ausgewertet. Erzielte Effekte Die erzielten Beleuchtungseffekte entsprechen alle den gestellten Erwartungen. Die folgenden Screenshots stellen alle eine Beleuchtungsmethode mit einer Lichtquelle dar. In Abbildung 24 sieht man die per-vertex Beleuchtung nach Gouraud. Abbildung 24: Gouraud Beleuchtung Die Abbildungen 25 bis 27 zeigen die per-fragment Beleuchtungen mittels Phong-, sowie Cel-Shading mit und ohne Outlines. 48

50 Abbildung 25: Phong Beleuchtung Abbildung 26: Cel-Shading ohne Outlines 49

51 Abbildung 27: Cel-Shading mit schwarzen Outlines (Stärke: 0.05) Die Outlines des Cel-Shaders werden mittels back-face Überlagerung erzeugt. Eine mögliche Verbesserung wäre die in Kapitel beschriebene Technik mit Hilfe des Sobel-Filters. Abbildung 28 zeigt ein eingeschaltetes Spotlight. Für die Darstellung wurde Phong-Shading benutzt und mit einer Lichtquelle gearbeitet. Der Spot hat einen Radius von 2 x 30 und einen Exponenten von 11, um den Rand weicher wirken zu lassen. Abbildung 28: Phong-Shading mit eingeschaltetem Spotlight In Abbildung 29 ist eine, von mehreren Lichtquellen beleuchtete Szene zu sehen. Für die Aufnahme wurde Phong-Shading verwendet und zwei 50

52 Lichtquellen mit weißem und rotem Licht an verschiedenen Punkten platziert. Abbildung 29: Phong-Shading mit zwei Lichtquellen Abbildung 30 zeigt einen Würfel, der mit einer Normal-Map Textur versehen ist (Textur aus [vwc08]). Der Würfel selbst hat eine flache Oberfläche und besteht aus acht Vertizes. Die Szene ist mittels Phong-Shading beleuchtet. Abbildung 30: Bumpmapping auf einem Würfel Die Entscheidung, die Shader auf Object-Space auszulegen, um die Performance zu erhöhen, hat sich nicht ausgezahlt, da sich das Erstellen einer 51

53 Normal-Map als weitaus schwieriger herausgestellt hat. Normal-Maps, die in Tangent-Space erstellt werden, sind für den Benutzer wesentlich einfacher zu handhaben und lassen sich mit den ich genannten Tools weitaus besser erstellen.. Außerdem stellte sich heraus, dass die Anpassung der Texturkoordinate durch Parallaxmapping in Object-Space keine zufriedenstellenden Ergebnisse liefert. Anstelle der Texturnormalen, die durch die Tangent-Space Berechnung ermittelt wird, muss zur Bestimmung des Winkels, die Vertexnormale genutzt werden, was in den meisten Fällen nicht bloß zu ungenauen sondern zu falschen Resultaten führt. Im Zuge der Weiterentwicklung von AiRmob ist es zu empfehlen, die Mappingverfahren auf den Tangent-Space umzustellen. Die Abbildungen 31 bis 33 zeigen die IPP-Effekte Blur und Bloom. Für das simple Blurring wurde ein Radius von 2 eingestellt. Der Radius für das Gauß-Verfahren beträgt 4 und für sigma wurde der Wert 2 eingestellt. Um den Bloom Effekt gut erkennen zu können, wurde der Hintergrund geschwärzt. Abbildung 31: simples Blurring Anmerkung: Auf Grund der Tatsache, dass das Testgerät "Galaxy S-II"von Samsung das Kamerabild bei Screenshots nicht aufnimmt, musste dieses mit der Szene erneut gerendert werden. Dadurch wurde der Blur-Effekt ebenfalls auf den Hintergrund angewandt. Bei regulärem Nutzen der App ist dies nicht der Fall. 52

54 Abbildung 32: Gauß-Blurring Abbildung 33: Bloom Effekt Framerate-Tests Ein Ziel der Arbeit war es unter anderem, zu ermitteln in wie weit es möglich, ist die Effekte auf mobilen Geräten mit eingeschränkter Hardware lauffähig zu machen. Die folgenden Test zeigen, welche Frameraten die Effekte auf dem Galaxy S-II erreicht haben. Die Frameraten können je nach Position, Szene und anderen aktiven Prozessen stark schwanken. Daher wurde für jeden Test eine Referenz ermittelt, die immer eine Phong-Beleuchtung mit einer Lichtquelle als Grundlage hat. Der erste Test ermittelt die Leistung in Bezug auf die Anzahl der Lichtquel- 53

55 len. Als Grundlage des Test dient der Renderer Tres Amigos, der mittels Phong- und Gouraud-Shading beleuchtet wird. Für jeden Durchlauf wurde eine Lichtquelle mehr aktiviert, bis zu einem Maximum von acht. Es wurde jeweils die durchschnittliche Framerate über einen Zeitraum von 30 Sekunden gemessen und notiert. Abbildung 34 zeigt die Ergebnisse. Abbildung 34: Testergebnisse zur Evaluierung der Leistung mit multiplen Lichtquellen Der Test zeigt, dass die Leistung mit jeder zugeschalteten Lichtquelle massiv abnimmt. Bei einer Auflösung von 640 x 480 Pixel und einer Szene mit Vertizes erweist sie die per-fragment Beleuchtung als effizienter. Um die Beleuchtung für hardwareschwache Geräte möglich zu machen, wurde ein modifizierter Shader geschrieben, der lediglich eine Lichtquelle behandelt. Um zusätzlich Performance zu gewinnen, wird dieser Shader automatisch genutzt, sollte nur eine Lichtquelle definiert sein. Dieser neue Shader onelight_main ist weiterhin kompatibel mit allen Effekten. Er implementiert die Berechnung der Beleuchtung inplace. Dadurch wird der Aufruf der Funktion gespart, was zu einem Performancegewinn von weiteren fps führt. Der nächste Test ermittelt den benötigten Leistungsaufwand der beiden Mappingverfahren. Hierzu wurde der Beispielrenderer Bumpmapping verwendet, der einen einfachen Würfel zeichnet und diesen mit einer Lichtquelle mittels Phong beleuchtet. Für den Referenzwert wurden dem Würfel 54

56 seine Vertexnormalen übergeben. Danach wurde jeweils Bump- und Parallaxmapping aktiviert. Abbildung 35: Testergebnisse zur Evaluierung der Leistung bei unterschiedlichen Mappingverfahren Die Ergebnisse zeigen, dass die unterschiedlichen Berechnungen der Texturkoordinate keinen Einfluss auf die Leistung der App haben. Lediglich die Verwendung einer Normal-Map Textur führt zu einem Leistungsabfall von ca. 9%. Die verwendete Textur hat eine Auflösung von 256 x 256 Pixel. Der dritte Test befasst sich mit Image Post-Processing und insbesondere den Blurring-Algorithmen. Als Grundlage wird wieder der Tres Amigos Renderer verwendet, der durch eine Lichtquelle mittels Phong beleuchtet wird. Der Referenzwert A beschreibt die Leistung der App ohne aktiviertes IPP und somit auch ohne Blurring. Für Referenzwert B wurde die IPP-Textur bereits aktiviert, aber noch kein Blurring darauf angewandt. Es wurde sowohl simples als auch Gauß-Blurring getestet. Für beide Methoden wurden die gleichen Radien benutzt. Der Sigma Wert für den Gauß- Algorithmus wurde für die entsprechenden Radien sinnvoll angepasst. Er ist ebenfalls der Tabelle zu entnehmen. 55

57 Abbildung 36: Testergebnisse zur Evaluierung der Leistung bei aktiviertem Blur Der Test zeigt, dass das Erzeugen und Verwenden einer IPP-Textur bereits 33% Leistungseinbuße mit sich bringt. Bei dem Testgerät entspricht das einem Abfall von 170 fps. Das Arbeiten auf dieser Textur bewirkt weitere starke Performanceverluste. Der simple Blur-Effekt bewegt sich unabhängig vom Radius stets um ca. 100 fps. Das bedeutet ein Verlust von weiteren 251 fps oder 81% zum Referenzwert A. Die Konstanz dieses Verfahrens ist leicht zu erklären. Unabhängig vom Radius werden stets vier Texturzugriffe durchgeführt. Die Koordinaten der Zugriffe errechnen sich immer über die gleiche Formel und variieren nur in einem Wert: dem Radius. Auffällig ist, dass der Gauß-Algorithmus, dem weitaus komplexere Berechnungen zugrunde liegen, bei einem Radius von 1 schneller ist als simples Blurring. Die einzig mögliche Erklärung lässt sich in der Tatsache suchen, dass für den Gauß-Algorithmus zwei Shaderaufrufe durchgeführt werden und so zweimal zwei anstelle von vier Zugriffen auf die Textur stattfinden. Der offensichtliche Nachteil dieses Algorithmus eröffnet sich aber sehr schnell, wenn der Radius größer als 3 gewählt wird. Es ist eine hyperbolische Kurve zu erkennen, die sich an 0 annähert. Unter Betrachtung dieser Ergebnisse und der erhaltenen Resultate beider Algorithmen, lässt sich schlussfolgern, dass der Gauß-Algorithmus in den meisten Fällen das favorisierte Verfahren sein sollte. Spätestens bei einem Radius von 5 oder größer liefert das simple Blurring Resultate, die keine Illusion von einem Weichzeichner mehr erzeugen. Es ist lediglich die Szene viermal versetzt übereinander zu 56