Shader und Effekte für AiRmob. Bachelorarbeit

Größe: px
Ab Seite anzeigen:

Download "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% 5 6 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 (http://www.khronos.org/) 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

(7) Normal Mapping. Vorlesung Computergraphik II S. Müller. Dank an Stefan Rilling U N I V E R S I T Ä T KOBLENZ LANDAU

(7) Normal Mapping. Vorlesung Computergraphik II S. Müller. Dank an Stefan Rilling U N I V E R S I T Ä T KOBLENZ LANDAU (7) Normal Mapping Vorlesung Computergraphik II S. Müller Dank an Stefan Rilling Einleitung Die Welt ist voller Details Viele Details treten in Form von Oberflächendetails auf S. Müller - 3 - Darstellung

Mehr

Probelektion zum Thema. Shadow Rendering. Shadow Maps Shadow Filtering

Probelektion zum Thema. Shadow Rendering. Shadow Maps Shadow Filtering Probelektion zum Thema Shadow Rendering Shadow Maps Shadow Filtering Renderman, 2006 CityEngine 2011 Viewport Real reconstruction in Windisch, 2013 Schatten bringen viel Realismus in eine Szene Schatten

Mehr

Seminar Game Development Game Computer Graphics. Einleitung

Seminar Game Development Game Computer Graphics. Einleitung Einleitung Gliederung OpenGL Realismus Material Beleuchtung Schatten Echtzeit Daten verringern Grafik Hardware Beispiel CryEngine 2 Kristian Keßler OpenGL Was ist OpenGL? Grafik API plattform- und programmiersprachenunabhängig

Mehr

"rendern" = ein abstraktes geometrisches Modell sichtbar machen

rendern = ein abstraktes geometrisches Modell sichtbar machen 3. Grundlagen des Rendering "rendern" = ein abstraktes geometrisches Modell sichtbar machen Mehrere Schritte: Sichtbarkeitsberechnung Beleuchtungsrechnung Projektion Clipping (Abschneiden am Bildrand)

Mehr

OpenGL. (Open Graphic Library)

OpenGL. (Open Graphic Library) OpenGL (Open Graphic Library) Agenda Was ist OpenGL eigentlich? Geschichte Vor- und Nachteile Arbeitsweise glscene OpenGL per Hand Debugging Trend Was ist OpenGL eigentlich? OpenGL ist eine Spezifikation

Mehr

Prozedurale Texturen >>Was nicht passt wird passend gemacht...<<

Prozedurale Texturen >>Was nicht passt wird passend gemacht...<< Prozedurale Texturen >>Was nicht passt wird passend gemacht...

Mehr

Raytracing. Schlussbericht. Jonas Lauener 1995, Áedán Christie 1997 Melvin Ott 1997, Timon Stampfli 1997

Raytracing. Schlussbericht. Jonas Lauener 1995, Áedán Christie 1997 Melvin Ott 1997, Timon Stampfli 1997 Raytracing Schlussbericht Jonas Lauener 1995, Áedán Christie 1997 Melvin Ott 1997, Timon Stampfli 1997 bei Betreuer Marco Manzi, Institut für Informatik und angewandte Mathematik Inhalt Fragestellung...

Mehr

Rendering: Lighting and Shading

Rendering: Lighting and Shading Rendering: Lighting and Shading Hauptseminar: How to make a Pixar Movie Inhalt Einführung Was ist Rendering Was ist Reflexionsmodelle Lighting Shading Globale Beleuchtungsmodelle Zusammenfassung 2/53 Inhalt

Mehr

computer graphics & visualization

computer graphics & visualization Entwicklung und Implementierung echtzeitfähiger Verfahren zur Darstellung von reflektierenden Objekten auf GPUs echtzeitfähiger Verfahren zur Darstellung von reflektierenden Objekten auf GPUs Motivation

Mehr

Photonik Technische Nutzung von Licht

Photonik Technische Nutzung von Licht Photonik Technische Nutzung von Licht Raytracing und Computergraphik Überblick Raytracing Typen von Raytracern z-buffer Raytracing Lichtstrahlen-Verfolgung (engl. ray tracing): Berechnung von Lichtstrahlen

Mehr

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr Aufgabe 8.1: Zeigerverdopplung Ermitteln Sie an folgendem Beispiel den Rang für jedes Listenelement sequentiell und mit dem in der Vorlesung vorgestellten parallelen

Mehr

Workshop: Einführung in die 3D-Computergrafik. Julia Tolksdorf Thies Pfeiffer Christian Fröhlich Nikita Mattar

Workshop: Einführung in die 3D-Computergrafik. Julia Tolksdorf Thies Pfeiffer Christian Fröhlich Nikita Mattar Workshop: Einführung in die 3D-Computergrafik Julia Tolksdorf Thies Pfeiffer Christian Fröhlich Nikita Mattar 1 Organisatorisches Tagesablauf: Vormittags: Theoretische Grundlagen Nachmittags: Bearbeitung

Mehr

Zwischenvortrag zum Entwicklungsstand der Bachelor-Arbeit. Direct 3D-Output für ein Rendering Framework

Zwischenvortrag zum Entwicklungsstand der Bachelor-Arbeit. Direct 3D-Output für ein Rendering Framework Zwischenvortrag zum Entwicklungsstand der Bachelor-Arbeit Direct 3D-Output für ein Rendering Framework von Benjamin Betting unter der Betreuung von Daniel Schiffner 1 Gliederung Kapitel I und II: Motivation,Einführung,Grundlagen

Mehr

Christina Nell. 3D-Computergrafik

Christina Nell. 3D-Computergrafik Christina Nell 3D-Computergrafik Was ist 3D-Computergrafik? 3D graphics is the art of cheating without getting caught. (unbekannte Quelle) Folie 2/52 Inhalt Beleuchtung Shading Texturierung Texturfilterung

Mehr

RTT DeltaGen Suite. Materialeinstellungen für OpenGL, RTT RealTrace & Global illumination. Copyright 2010 by Realtime Technology AG

RTT DeltaGen Suite. Materialeinstellungen für OpenGL, RTT RealTrace & Global illumination. Copyright 2010 by Realtime Technology AG RTT DeltaGen Suite Materialeinstellungen für OpenGL, RTT RealTrace & Global illumination Copyright 2010 by Realtime Technology AG Look Editor Der Look Editor zeigt die Eigenschaften des Looks des selektierten

Mehr

Rendering Grundlagen Autodesk Maya. Grundlagen. Version 1.0-2009-04-08. 2009 Ingo Clemens brave rabbit www.braverabbit.de

Rendering Grundlagen Autodesk Maya. Grundlagen. Version 1.0-2009-04-08. 2009 Ingo Clemens brave rabbit www.braverabbit.de Rendering Grundlagen Version 1.0-2009-04-08 Allgemeine Unterschiede bei Renderern Scanline Rendering Raytrace Rendering Renderlayer Einsatz von Renderlayern Overrides Material Overrides Layer Presets Batch

Mehr

Rendering: Lighting & Shading

Rendering: Lighting & Shading Hauptseminar How to make a Pixar Movie WS 2010 / 2011 Rendering: Lighting & Shading von Manuel Schmidt Gliederung: 1 Einführung 1.1 Rendering 1.2 Reflektionsmodelle 1.2.1. Diffuse Reflektion 1.2.2. Spieglende

Mehr

Softwareprojekt Spieleentwicklung

Softwareprojekt Spieleentwicklung Softwareprojekt Spieleentwicklung Prototyp I (2D) Prototyp II (3D) Softwareprojekt 12.04. 19.04. 26.04. 03.05. 31.05. Meilenstein I 28.06. Meilenstein II Prof. Holger Theisel, Tobias Günther, OvGU Magdeburg

Mehr

Non-Photorealistic Rendering

Non-Photorealistic Rendering Übersicht 1. Motivation und Anwendungen 2. Techniken - Cel Shading - Konturlinien - Hatching Einführung Traditionelle Computergraphik Ziel: Fotorealismus Einführung Motivation Bewusste Vermeidung von

Mehr

Überblick Echtzeit-Rendering. Uwe Domaratius dou@hrz.tu-chemnitz.de

Überblick Echtzeit-Rendering. Uwe Domaratius dou@hrz.tu-chemnitz.de Überblick Echtzeit-Rendering Uwe Domaratius dou@hrz.tu-chemnitz.de Gliederung 1. Einleitung 2. geometriebasierende Verbesserungen 3. Level-of-Detail 4. Culling 5. Texturen 6. bildbasiertes Rendering Was

Mehr

Darstellung komplexer 3D-Stadtmodelle im (mobilen) Webbrowser mittels bildbasiertem Rendering

Darstellung komplexer 3D-Stadtmodelle im (mobilen) Webbrowser mittels bildbasiertem Rendering Darstellung komplexer 3D-Stadtmodelle im (mobilen) Webbrowser mittels bildbasiertem Rendering Martin Christen FHNW Hochschule für Architektur, Bau und Geomatik Institut Vermessung und Geoinformation martin.christen@fhnw.ch

Mehr

Pixel oder Vektor? Die Vor- und Nachteile der verschiedenen Dateiformate. Langner Marketing Unternehmensplanung Metzgerstraße 59 72764 Reutlingen

Pixel oder Vektor? Die Vor- und Nachteile der verschiedenen Dateiformate. Langner Marketing Unternehmensplanung Metzgerstraße 59 72764 Reutlingen Die Vor- und Nachteile der verschiedenen Dateiformate Stand April 2016 Langner Marketing Unternehmensplanung Metzgerstraße 59 72764 Reutlingen T 0 71 21 / 2 03 89-0 F 0 71 21 / 2 03 89-20 www.langner-beratung.de

Mehr

Gameprogramming WS2013/14 Futurella von Pavel Belskiy und Felix Niemeyer Betreuer: Stefan Buschmann

Gameprogramming WS2013/14 Futurella von Pavel Belskiy und Felix Niemeyer Betreuer: Stefan Buschmann Gameprogramming WS2013/14 Futurella von Pavel Belskiy und Felix Niemeyer Betreuer: Stefan Buschmann Futurella Spielprinzip & Demo - Raumschiffe - Asteroiden - Zielplaneten - LAN Multiplayer Wettrennen

Mehr

:= Modellabbildung. Bildsynthese (Rendering) Bildsynthese

:= Modellabbildung. Bildsynthese (Rendering) Bildsynthese Geometrisches Modell bestehend aus Datenstrukturen zur Verknüpfung geometrischer Primitive, welche eine Gesamtszene beschreiben Bildsynthese := Modellabbildung Pixelbasiertes Modell zur Darstellung eines

Mehr

MF Breadcrumbs. Sergej Schefer & Fabian Marx

MF Breadcrumbs. Sergej Schefer & Fabian Marx MF Breadcrumbs Sergej Schefer & Fabian Marx MF Breadcrumbs! Entwurf! Algorithmen! Screenshots / Live-Demo Entwurf! 2.5D Jump n Run! Spieler kann sich durch Level bewegen und Punkte aufsammeln! Freie Levelgestaltung

Mehr

Der Einsatz von HDRIs in LightWave 7

Der Einsatz von HDRIs in LightWave 7 Seite 1 DOSCH DESIGN TUTORIAL Der Einsatz von HDRIs in LightWave 7 Eine Schritt-für-Schritt-Anleitung LightWave kann ab der Version 6.5 HDRIs (High Dynamic Range Images) als Beleuchtung und Hintergrund

Mehr

Programmierpraktikum 3D Computer Grafik

Programmierpraktikum 3D Computer Grafik Prof. Andreas Butz, Dipl.Inf. Otmar Hilliges Programmierpraktikum 3D Computer Grafik Dynamische Schattenberechnung Agenda Der Stencil-Puffer Der 1-bit Stencil-Puffer Der 8-bit Stencil-Puffer Volumetrische

Mehr

3D Programmierpraktikum: Schattenberechnung in Echtzeit

3D Programmierpraktikum: Schattenberechnung in Echtzeit 3D Programmierpraktikum: Schattenberechnung in Echtzeit Praktikum 3D Programmierung Sebastian Boring, Otmar Hilliges Donnerstag, 20. Juli 2006 LMU München Medieninformatik Boring/Hilliges 3D Programmierpraktikum

Mehr

Advanced Rendering Interior Szene

Advanced Rendering Interior Szene Advanced Rendering Interior Szene in Cinema 4D 11-11.5 Als erstes, sollten Sie ihre Szene in Cinema 4D öffnen. vergewissern sie sich, ob alle Licht quellen die evtl. mit importiert wurden, aus der Szene

Mehr

Lokale Beleuchtungsmodelle

Lokale Beleuchtungsmodelle Lokale Beleuchtungsmodelle Oliver Deussen Lokale Modelle 1 Farbschattierung der Oberflächen abhängig von: Position, Orientierung und Charakteristik der Oberfläche Lichtquelle Vorgehensweise: 1. Modell

Mehr

Wie erstellt man dynamische Elemente mit JSXGraph?

Wie erstellt man dynamische Elemente mit JSXGraph? Wie erstellt man dynamische Elemente mit JSXGraph? 1. Kurzinformation zu JSXGraph Was ist JSXGraph? Eine freie dynamische Mathematiksoftware, die vollständig in Javascript programmiert ist. Daher benötigt

Mehr

Kapitel 4: Schattenberechnung

Kapitel 4: Schattenberechnung Kapitel 4: Schattenberechnung 1 Überblick: Schattenberechnung Motivation Schattenvolumen Shadow Maps Projektive Schatten 2 Motivation Wesentlich für die Wahrnehmung einer 3D-Szene Eigentlich ein globaler

Mehr

Grundlagen der Spieleprogrammierung

Grundlagen der Spieleprogrammierung Grundlagen der Spieleprogrammierung Teil I: 3D-Graphik Kapitel 9: Engines, Cg und anderes Peter Sturm Universität Trier Outline 1. Übersicht und Motivation 2. Mathematische Grundlagen 3. Das Ideal: Photorealistisch

Mehr

8 3D-Grafik mit VPython

8 3D-Grafik mit VPython 8 3D-Grafik mit VPython In diesem Kapitel wird das Python-Erweiterungsmodul Visual-Python bzw. VPython vorgestellt. Mit VPython können interaktive und animierte 3D-Szenen erzeugt werden. Dreidimensionale

Mehr

FÜR GOOGLE ANDROID OPERATING SYSTEM. Dokumentation. Version 1.2013. 2013 NAM.IT Software-Entwicklung Alle Rechte vorbehalten.

FÜR GOOGLE ANDROID OPERATING SYSTEM. Dokumentation. Version 1.2013. 2013 NAM.IT Software-Entwicklung Alle Rechte vorbehalten. FÜR GOOGLE ANDROID OPERATING SYSTEM Dokumentation Version 1.2013 2013 NAM.IT Software-Entwicklung Alle Rechte vorbehalten. 1 Information Diese Dokumentation beschreibt die Funktionen der kostenpflichten

Mehr

Die Dreipunkt- Beleuchtung

Die Dreipunkt- Beleuchtung Die Dreipunkt- Beleuchtung Die Dreipunkt- Beleuchtung ist eine der Standard -Methoden bei der Ausleuchtung in der Materie Film und Foto und wurde auch für die Ausleuchtung im Bereich der Computer-generierten

Mehr

Linear Workflow. Linear Workflow. Version 1.0-2011-10-11

Linear Workflow. Linear Workflow. Version 1.0-2011-10-11 Version 1.0-2011-10-11 Verfahren, Bilder unter Rücksichtnahme ihres Farbprofils und der des Ausgabegeräts zu berechnen (3D), bzw. zu bearbeiten (Compositing), um eine mathematisch und physikalisch korrekte

Mehr

S/W mit PhotoLine. Inhaltsverzeichnis. PhotoLine

S/W mit PhotoLine. Inhaltsverzeichnis. PhotoLine PhotoLine S/W mit PhotoLine Erstellt mit Version 16.11 Ich liebe Schwarzweiß-Bilder und schaue mir neidisch die Meisterwerke an, die andere Fotografen zustande bringen. Schon lange versuche ich, auch so

Mehr

App-Entwicklung für Android

App-Entwicklung für Android App-Entwicklung für Android Einleitung - Systemarchitektur Hochschule Darmstadt WS15/16 1 Inhalt Historie Systemarchitektur Sandbox 2 Motivation Kontra Pro Limitierte Größe Begrenzte Ressourcen Kein Standardgerät

Mehr

Diplomarbeit. Neue Möglichkeiten durch programmierbare Shader. Unter der Leitung von: Prof. Dr.-Ing. Detlef Krömker

Diplomarbeit. Neue Möglichkeiten durch programmierbare Shader. Unter der Leitung von: Prof. Dr.-Ing. Detlef Krömker Diplomarbeit 5HDO7LPH6SHFLDO (IIHFWV Neue Möglichkeiten durch programmierbare Shader Unter der Leitung von: Prof. Dr.-Ing. Detlef Krömker Betreut von: Paul Grimm, Ralf Dörner Beginn: 01.04.02 Abgabe: 30.09.02

Mehr

Computergrafik 2010 Oliver Vornberger. Kapitel 18: Beleuchtung

Computergrafik 2010 Oliver Vornberger. Kapitel 18: Beleuchtung Computergrafik 2010 Oliver Vornberger Kapitel 18: Beleuchtung 1 Ausgangslage am Ende der Viewing Pipeline liegt vor: P A Materialeigenschaften P B P C 2 Beleuchtungmodelle lokal: Objekt, Lichtquellen,

Mehr

Dr. Holger Eichelberger

Dr. Holger Eichelberger SchülerInnen-Uni 2015 Dr. Holger Eichelberger eichelberger@sse.uni-hildesheim.de Inhalt 1. Wer ist das? 1 2. Was ist ein Smartphone? 3 3. Wie entwickelt man für Smartphones? 7 4. Wie bauen wir die App?

Mehr

3D-Engine für AiRmob. Bachelorarbeit

3D-Engine für AiRmob. Bachelorarbeit Fachbereich 4: Informatik 3D-Engine für AiRmob Bachelorarbeit zur Erlangung des Grades eines Bachelor of Science (B.Sc.) im Studiengang Computervisualistik vorgelegt von Axel Peter stoffel@uni-koblenz.de

Mehr

DYNAMISCHE SEITEN. Warum Scriptsprachen? Stand: 11.04.2005. CF Carola Fichtner Web-Consulting http://www.carola-fichtner.de

DYNAMISCHE SEITEN. Warum Scriptsprachen? Stand: 11.04.2005. CF Carola Fichtner Web-Consulting http://www.carola-fichtner.de DYNAMISCHE SEITEN Warum Scriptsprachen? Stand: 11.04.2005 CF Carola Fichtner Web-Consulting http://www.carola-fichtner.de I N H A L T 1 Warum dynamische Seiten?... 3 1.1 Einführung... 3 1.2 HTML Seiten...

Mehr

Szenengraph-Architekturen im Kontext von VR- und AR-Anwendungen

Szenengraph-Architekturen im Kontext von VR- und AR-Anwendungen Szenengraph-Architekturen - 1 Szenengraph-Architekturen im Kontext von VR- und AR-Anwendungen Hauptseminar Medieninformatik Christina Eicher 10. Mai 2004 Inhalt Szenengraph-Architekturen - 2 Teil 1: Szenengraphen

Mehr

Lineare Gleichungssysteme

Lineare Gleichungssysteme Brückenkurs Mathematik TU Dresden 2015 Lineare Gleichungssysteme Schwerpunkte: Modellbildung geometrische Interpretation Lösungsmethoden Prof. Dr. F. Schuricht TU Dresden, Fachbereich Mathematik auf der

Mehr

4.3 Beleuchtung und Schattierung

4.3 Beleuchtung und Schattierung 4.3 Beleuchtung und Schattierung Die Grundbestandteile des Renderprozesses Atmosphärische Streuung Emission Reflexion/ Transmission/ Emission Oberfläche 4-38 4.3 Beleuchtung und Schattierung Beleuchtung

Mehr

Bildbearbeitungstechniken Lehrerinformation

Bildbearbeitungstechniken Lehrerinformation Lehrerinformation 1/9 Arbeitsauftrag Ziel Zwanzig klassische Elemente der Bildbearbeitung werden vorgestellt. Die Sch arbeiten in Zweierteams und erarbeiten sich das Wissen zu je 1 2. Sie bearbeiten Bildausschnitte,

Mehr

Numerisches Programmieren

Numerisches Programmieren Technische Universität München WS /3 Institut für Informatik Prof Dr Hans-Joachim Bungartz Dipl-Inf Christoph Riesinger Dipl-Inf Dipl-Math Jürgen Bräckle Numerisches Programmieren Programmieraufgabe: Polnominterpolation,

Mehr

Embedded Computing Conference 2014 Embedded UI Qt5

Embedded Computing Conference 2014 Embedded UI Qt5 Embedded Computing Conference 2014 Embedded UI Qt5 2 Embedded User Interfaces in the Smartphone Age The Power of Qt5 and the QNX OS Qt Vorstellung 3 Qt ( cute ) Hat eine lange Geschichte (Beginn der Entwicklung:

Mehr

Staatlich geprüfte Techniker

Staatlich geprüfte Techniker Auszug aus dem Lernmaterial ortbildungslehrgang Staatlich geprüfte Techniker Auszug aus dem Lernmaterial Maschinenbautechnische Grundlagen DAA-Technikum Essen / www.daa-technikum.de, Infoline: 001 83 16

Mehr

Kontextdiagramm Erstellen von Kontextdiagrammen mit TopEase

Kontextdiagramm Erstellen von Kontextdiagrammen mit TopEase Kontextdiagramm Erstellen von Kontextdiagrammen mit TopEase Version Control: Version Status Datum / Kurzzeichen 1.0 Begründung Copyright: This document is the property of Business-DNA Solutions GmbH, Switzerland.

Mehr

Mobile Analytics mit Oracle BI - was steckt in den Apps?

Mobile Analytics mit Oracle BI - was steckt in den Apps? Mobile Analytics mit Oracle BI - was steckt in den Apps? Schlüsselworte Oracle BI, OBIEE, Mobile, Analytics Einleitung Gerd Aiglstorfer G.A. itbs GmbH Eching Oracle erweiterte im Laufe dieses Jahres das

Mehr

Anwendertreffen 20./21. Juni

Anwendertreffen 20./21. Juni Forum cadwork 3D Viewer Der cadwork 3D Viewer ist ein Programm mit dem Sie einfache Präsentationen und Bilder Ihrer Projekte erstellen können. Auch kleinere Animationen und Filme können mit ihm erstellt

Mehr

How to make a PIXAR movie

How to make a PIXAR movie How to make a PIXAR movie Non-Photorealistic Rendering Definition NPR is an area of computer graphics that focuses on enabling a wide variety of expressive styles for digital art. Alternativbezeichnungen:

Mehr

FAQs Getestete Geräte

FAQs Getestete Geräte http://bit.ly/1p5pt7a http://apple.co/1uwe9kt *Wenn Sie den App-Store auf Ihrem ipad durchsuchen, wählen Sie bitte Nur iphone in den Suchoptionen, um alle Apps zu sehen (linke obere Ecke). Android Installationsanleitungen

Mehr

Computer Graphik (CS231) - Installation der Software

Computer Graphik (CS231) - Installation der Software UNIVERSITÄT BASEL Prof. Dr. Thomas Vetter Departement Mathematik und Informatik Spiegelgasse 1 CH 4051 Basel Tobias Maier (tobias.maier@unibas.ch) Jasenko Zivanov (jasenko.zivanov@unibas.ch) Marc Schmidlin

Mehr

Wima-Praktikum 2: Bildsynthese-Phong

Wima-Praktikum 2: Bildsynthese-Phong Wima-Praktikum 2: Bildsynthese-Phong Wima-Praktikum 2: Prof. Dr. Lebiedz, M. Sc. Radic 1 Inhaltsverzeichnis 1 Einleitung 3 2 Kurze Beschreibung der Aufgabenstellung und dem Phong- Modell 3 3 Modellierung

Mehr

1.2 Einführung der Zahl Dominik Schomas Clemens Blank

1.2 Einführung der Zahl Dominik Schomas Clemens Blank 1.2 Einführung der Zahl Dominik Schomas Clemens Blank Die Zahl wird über den konstanten Quotienten eingeführt. Der Umfang sowie der Durchmesser werden von den Schülern experimentell gemessen mit und in

Mehr

Development Tools for 16/32 Bit Microcontroller

Development Tools for 16/32 Bit Microcontroller Praktika- und Diplomthemen bei Stand 01/2013 Die nachfolgend aufgeführten Themen sind Vorschläge und können in Absprache mit dem Praktikanten / Diplomanden sowie der Hochschule modifiziert werden. Die

Mehr

Java Applet Alternativen

Java Applet Alternativen White Paper Java Applet Alternativen Version 1.0, 21.01.2014 Tobias Kellner tobias.kellner@egiz.gv.at Zusammenfassung: Aufgrund diverser Meldungen über Sicherheitslücken in Java haben in letzter Zeit Browser-Hersteller

Mehr

NÜTZLICHE TIPPS FÜR OPTIMALE SCANS

NÜTZLICHE TIPPS FÜR OPTIMALE SCANS Bedingungen, um gute Scans zu erhalten Die Faktoren, von denen das Ergebnis eines Scans abhängt, sind einerseits die Umgebung sowie die Konfiguration und Kalibrierung des Scanners, aber auch das zu scannende

Mehr

kornelia rath space 277 matrikelnummer 0703756 portfolioass finale digitale darstellungsmethoden ss 2010 chair_it

kornelia rath space 277 matrikelnummer 0703756 portfolioass finale digitale darstellungsmethoden ss 2010 chair_it kornelia rath space 277 matrikelnummer 0703756 portfolioass finale digitale darstellungsmethoden ss 2010 chair_it ass c In ass c war die Aufgabe einen Stuhl zu verformen. Ich habe meinen so versucht nachzubearbeitet,

Mehr

Bin Packing oder Wie bekomme ich die Klamotten in die Kisten?

Bin Packing oder Wie bekomme ich die Klamotten in die Kisten? Bin Packing oder Wie bekomme ich die Klamotten in die Kisten? Ich habe diesen Sommer mein Abi gemacht und möchte zum Herbst mit dem Studium beginnen Informatik natürlich! Da es in meinem kleinen Ort keine

Mehr

EveryWare CloudBox User Manual

EveryWare CloudBox User Manual EveryWare CloudBox User Manual Kontakt EveryWare AG Zurlindenstrasse 52a 8003 Zürich T +41 44 466 60 00 F +41 44 466 60 10 E-Mail: info@everyware.ch Datum 25. März 2015 Version V 4.0 / rho, cdo Inhaltsverzeichnis

Mehr

Einschätzung der Diplomarbeit. Musik im Film- Auswirkungen von Filmmusik auf das Gedächtnis für Filminhalte

Einschätzung der Diplomarbeit. Musik im Film- Auswirkungen von Filmmusik auf das Gedächtnis für Filminhalte Einschätzung der Diplomarbeit Musik im Film- Auswirkungen von Filmmusik auf das Gedächtnis für Filminhalte Von: Wultsch Christina Matrikelnr.: 0411409 LV: Wissenschaftliches Arbeiten (LV-Nr.: 000.002)

Mehr

32. Algorithmus der Woche Kreise zeichnen mit Turbo Programmoptimierung: Wie kann man die Zahl der Rechenoperationen minimieren?

32. Algorithmus der Woche Kreise zeichnen mit Turbo Programmoptimierung: Wie kann man die Zahl der Rechenoperationen minimieren? 32. Algorithmus der Woche Kreise zeichnen mit Turbo Programmoptimierung: Wie kann man die Zahl der Rechenoperationen minimieren? Autor Leif Kobbelt, RWTH Aachen Dominik Sibbing, RWTH Aachen Hast Du schon

Mehr

Grumman F-14 Tomcat. ein 3D-Model erstellt in Autodesk Maya 2008

Grumman F-14 Tomcat. ein 3D-Model erstellt in Autodesk Maya 2008 Grumman F-14 Tomcat ein 3D-Model erstellt in Autodesk Maya 2008 Friedrich Maiwald s0518155 friedrich.maiwald @ fhtw-berlin.de http://www.friedrichmaiwald.de/tomcat/ Internationaler Studiengang Medieninformatik

Mehr

Texture Based Direct Volume Rendering

Texture Based Direct Volume Rendering Texture Based Direct Volume Rendering Vorlesung: "Advanced Topics in Computer Graphics" cbrak@upb.de 1 Agenda 1. Einleitung Volume Rendering 1.1. Volumendatensatz 1.2. Volumenintegral 1.3. Image order

Mehr

Bewegliche Ziele Entwicklungsumgebungen für Pocket PCs und Smartphones

Bewegliche Ziele Entwicklungsumgebungen für Pocket PCs und Smartphones Seite 1 von 5 Bewegliche Ziele Entwicklungsumgebungen für Pocket PCs und Smartphones von Robert Panther Mobile Devices auf Basis von Windows CE haben sich inzwischen fest am Markt etabliert. Nach dem Siegeszug

Mehr

Metadata Service Respository (MDS) - Sehen, lernen, verstehen!

Metadata Service Respository (MDS) - Sehen, lernen, verstehen! Metadata Service Respository (MDS) - Sehen, lernen, verstehen! Carsten Wiesbaum esentri AG Schlüsselworte Metadata Service Repository, MDS, Oracle Fusion Middleware Einleitung Früher oder später wird jeder

Mehr

T-Shirts mit Ornamenten

T-Shirts mit Ornamenten T-Shirts mit Ornamenten (Christian Liedl) Ziel ist es möglichst schicke T-Shirts durch ein eigenes Ornament zu verzieren. Dazu benötigen wir ein T-Shirt, eine T-Shirt Transferfolie zum Bedrucken und Aufbügeln,

Mehr

Installation. Arbeiten mit der MATLAB-Entwicklungsumgebung. MATLAB als Taschenrechner mit Matrix- und Vektorrechnung.

Installation. Arbeiten mit der MATLAB-Entwicklungsumgebung. MATLAB als Taschenrechner mit Matrix- und Vektorrechnung. Installation. Arbeiten mit der MATLAB-Entwicklungsumgebung. MATLAB als Taschenrechner mit Matrix- und Vektorrechnung. Die heutige Sitzung dient dem ersten Kennenlernen von MATLAB. Wir wollen MATLAB zuerst

Mehr

Technische Hintergrundinformationen

Technische Hintergrundinformationen hue, das individuell über Smartphone oder Tablet steuerbare, kabellose Beleuchtungssystem Mit hue präsentiert Philips 2012 ein neues drahtloses Beleuchtungssystem. LED- Lampen sind damit ab sofort nach

Mehr

Jörn Loviscach Hochschule Bremen

Jörn Loviscach Hochschule Bremen Programmierbare Hardware-Shader Jörn Loviscach Hochschule Bremen Überblick Vertex- und Pixel-Shader Anwendungsbeispiele fx-dateien Anwendungsbeispiele Zusammenfassung Puffer Vertex- und Pixel-Shader Hardware-Renderpipeline

Mehr

Dokumentation zum Projekt Multimediale Lehre Fluidmechanik an der Technischen Universität Graz

Dokumentation zum Projekt Multimediale Lehre Fluidmechanik an der Technischen Universität Graz Dokumentation zum Projekt Multimediale Lehre Fluidmechanik an der Technischen Universität Graz Andreas Aigner email: andreasa@sbox.tu-graz.ac.at. Januar 00 Inhaltsverzeichnis Theorie. Stromfunktion...........................

Mehr

PTV VISWALK TIPPS UND TRICKS PTV VISWALK TIPPS UND TRICKS: VERWENDUNG DICHTEBASIERTER TEILROUTEN

PTV VISWALK TIPPS UND TRICKS PTV VISWALK TIPPS UND TRICKS: VERWENDUNG DICHTEBASIERTER TEILROUTEN PTV VISWALK TIPPS UND TRICKS PTV VISWALK TIPPS UND TRICKS: VERWENDUNG DICHTEBASIERTER TEILROUTEN Karlsruhe, April 2015 Verwendung dichte-basierter Teilrouten Stellen Sie sich vor, in einem belebten Gebäude,

Mehr

MODELOPTIC Best.- Nr. MD02973

MODELOPTIC Best.- Nr. MD02973 MODELOPTIC Best.- Nr. MD02973 1. Beschreibung Bei MODELOPTIC handelt es sich um eine optische Bank mit deren Hilfe Sie die Funktionsweise der folgenden 3 Geräte demonstrieren können: Mikroskop, Fernrohr,

Mehr

Allerdings ist die Bearbeitung von Standardobjekten vorerst eingeschränkt. Wir wollen uns dies im folgenden Beispiel genauer betrachten.

Allerdings ist die Bearbeitung von Standardobjekten vorerst eingeschränkt. Wir wollen uns dies im folgenden Beispiel genauer betrachten. 7. KURVEN UND KNOTEN INFORMATION: Sämtliche Objekte bestehen in CorelDRAW aus Linien oder Kurven. So ist ein Rechteck ein Gebilde aus einem Linienzug, ein Kreis hingegen besteht aus einer Kurve. Zum Bearbeiten

Mehr

Implementation of a Framework Component for Processing Tasks within Threads on the Application Level

Implementation of a Framework Component for Processing Tasks within Threads on the Application Level Implementation of a Framework Component for Processing Tasks within Threads on the Application Level Deutsches Krebsforschungszentrum, for Processing Task within Threads on the Application Level Motivation

Mehr

Apps am Smartphone. Vortrag am Fleckenherbst Bürgertreff Neuhausen. www.buergertreff-neuhausen.de www.facebook.com/buergertreffneuhausen

Apps am Smartphone. Vortrag am Fleckenherbst Bürgertreff Neuhausen. www.buergertreff-neuhausen.de www.facebook.com/buergertreffneuhausen Apps am Smartphone Vortrag am Fleckenherbst Bürgertreff Neuhausen 1 Inhalt Was sind Apps Woher bekomme ich Apps Sind Apps kostenlos Wie sicher sind Apps Wie funktionieren Apps App-Vorstellung Die Google

Mehr

JetSym. Programmierung in Hochsprache ST nach IEC-61131-3. We automate your success.

JetSym. Programmierung in Hochsprache ST nach IEC-61131-3. We automate your success. JetSym Programmierung in Hochsprache ST nach IEC-61131-3 We automate your success. JetSym das Tool JetSym ist das zentrale Programmiertool der Jetter AG, das alle Funktionen der Automatisierungstechnik

Mehr

Kapitel 0. Einführung. 0.1 Was ist Computergrafik? 0.2 Anwendungsgebiete

Kapitel 0. Einführung. 0.1 Was ist Computergrafik? 0.2 Anwendungsgebiete Kapitel 0 Einführung 0.1 Was ist Computergrafik? Software, die einen Computer dazu bringt, eine grafische Ausgabe (oder kurz gesagt: Bilder) zu produzieren. Bilder können sein: Fotos, Schaltpläne, Veranschaulichung

Mehr

Teil 7: Beleuchtung. Einleitung. Einleitung. Beleuchtungsmodelle, Schattierungsmodelle

Teil 7: Beleuchtung. Einleitung. Einleitung. Beleuchtungsmodelle, Schattierungsmodelle Beleuchtungsmodelle, Schattierungsmodelle Einleitung Beleuchtung vs. Schattierung Beleuchtung: Modell auswerten (anschl.) global vs. lokal phsikalisch (photo-realistisch?) vs. empirisch Phong-Modell Schattierung:

Mehr

Inhalt. Seite 4... Am Anfang: Fotos, Fotos, Fotos-Referenzmaterial. Seite 4... Modellieren, texturieren und beleuchten

Inhalt. Seite 4... Am Anfang: Fotos, Fotos, Fotos-Referenzmaterial. Seite 4... Modellieren, texturieren und beleuchten Inhalt Seite 3... Die Idee Seite 4... Am Anfang: Fotos, Fotos, Fotos-Referenzmaterial Seite 4... Modellieren, texturieren und beleuchten Seite 7... Renderelemente: Wie die Bilder aufgebaut sind Seite 9...

Mehr

4 Architektur-Perspektiven (WO)

4 Architektur-Perspektiven (WO) 4 Architektur-Perspektiven (WO) Abb. 4-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WO-Dimension des architektonischen Ordnungsrahmens. Es erläutert, auf welchen

Mehr

Mobile Application Framework auf der Baustelle

Mobile Application Framework auf der Baustelle Mobile Application Framework auf der Baustelle Marcus Hammer virtual7 GmbH Karlsruhe Schlüsselworte Mobile Application Framework, REST, A-Team Mobile Persistence Accellerator Einleitung Die Firmengruppe

Mehr

GeoGebra Quickstart Eine Kurzanleitung für GeoGebra

GeoGebra Quickstart Eine Kurzanleitung für GeoGebra GeoGebra Quickstart Eine Kurzanleitung für GeoGebra Dynamische Geometrie, Algebra und Analysis ergeben GeoGebra, eine mehrfach preisgekrönte Unterrichtssoftware, die Geometrie und Algebra als gleichwertige

Mehr

2.1 CorelDRAW 8 Das Allround-Programm

2.1 CorelDRAW 8 Das Allround-Programm 2 CorelDRAW 8 Ziele dieses Kapitels: $ Sie lernen verschiedene Anwendungsgebiete von CorelDRAW 8 kennen. $ Sie verstehen den Unterschied zwischen Vektor-, Pixel- und Rendergrafiken. 2.1 CorelDRAW 8 Das

Mehr

Logo-Aufgaben mit Verbindung zur Mathematik

Logo-Aufgaben mit Verbindung zur Mathematik Logo-Aufgaben mit Verbindung zur Mathematik Student: Dozent: Prof. Juraj Hromkovic Datum: 13.06.007 Logo-Kenntnisse Für die Lösung der Aufgaben werden folge Logo-Befehle benötigt: Arithmetik: +, -, *,

Mehr

MiGo-Portal V2.21. Produkt-Sheet. Aktueller Stand: 30.11.2012 Verfasst von: Mike Goldhausen. MiGo-WebDesign Wiesenstraße 31 56459 Kölbingen

MiGo-Portal V2.21. Produkt-Sheet. Aktueller Stand: 30.11.2012 Verfasst von: Mike Goldhausen. MiGo-WebDesign Wiesenstraße 31 56459 Kölbingen MiGo-Portal V2.21 Produkt-Sheet Aktueller Stand: 30.11.2012 Verfasst von: Mike Goldhausen Unser aktuelles Portal-System für Ihre individuelle Homepage. Dieses Portal bietet die Möglichkeit verschiedene

Mehr

C# Programm: Raytracer (3D Renderer)

C# Programm: Raytracer (3D Renderer) C# Programm: Raytracer (3D Renderer) Hiermit verbrachten wir die letzte Einheit in C# des Informatikunterrichtes. Dieser Raytracer ist ein Programm, das nur mit wenigen Informationen über einen Raum, der

Mehr

Kapitel 3 Mathematik. Kapitel 3.3. Algebra Gleichungen

Kapitel 3 Mathematik. Kapitel 3.3. Algebra Gleichungen TG TECHNOLOGISCHE GRUNDLAGEN Kapitel 3 Mathematik Kapitel 3.3 Algebra Gleichungen Verfasser: Hans-Rudolf Niederberger Elektroingenieur FH/HTL Vordergut 1, 877 Nidfurn 055-654 1 87 Ausgabe: Februar 009

Mehr

Spring Dynamic Modules for OSGi Service Platforms

Spring Dynamic Modules for OSGi Service Platforms Gerd Wütherich freiberuflicher Softwarearchitekt Spring Dynamic Modules for OSGi Service Platforms Server Anwendungen mit Spring und Eclipse Equinox Agenda OSGi Technologie: OSGi Technologie im Überblick

Mehr

Elektronisches Auge wird wachsamer

Elektronisches Auge wird wachsamer Megapixelkameras erhöhen die Sicherheit Elektronisches Auge wird wachsamer Megapixel-Sensoren steigern die Lichtempfindlichkeit von Überwachungskameras deutlich. Das revolutioniert die Videoüberwachung

Mehr

Game Engine Architecture and Development. Platform Unabhängiger Code Multi Threading in Game Engines Profiling

Game Engine Architecture and Development. Platform Unabhängiger Code Multi Threading in Game Engines Profiling Game Engine Architecture and Development Platform Unabhängiger Code Multi Threading in Game Engines Profiling Folien Die Folien werden auf acagamics.de hochgeladen Das Passwort ist 60fps (ohne ) Rückblick:

Mehr

Gantt-Diagramm - Diagramm zur Projektverfolgung

Gantt-Diagramm - Diagramm zur Projektverfolgung Gantt-Diagramm - Diagramm zur Projektverfolgung 5.06.206 3:29:35 FAQ-Artikel-Ausdruck Kategorie: Windows::MS Office::Excel Bewertungen: 0 Status: öffentlich (Alle) Ergebnis: 0.00 % Sprache: de Letzte Aktualisierung:

Mehr

4 Produktspezifische Ausfallwahrscheinlichkeit und Ausbeute

4 Produktspezifische Ausfallwahrscheinlichkeit und Ausbeute 4.1 Grundlagen 4 Produktspezifische Ausfallwahrscheinlichkeit und Ausbeute 4.1 Grundlagen In den bisherigen Ausführungen wurden die Grundlagen der Ausbeuteberechnung behandelt. So wurde bereits im Abschnitt

Mehr

DRESDEN. Ermitteln von Sprunghöhen mit einem Windows Phone. ZfP-Sonderpreis der DGZfP beim Regionalwettbewerb Jugend forscht.

DRESDEN. Ermitteln von Sprunghöhen mit einem Windows Phone. ZfP-Sonderpreis der DGZfP beim Regionalwettbewerb Jugend forscht. ZfP-Sonderpreis der DGZfP beim Regionalwettbewerb Jugend forscht DRESDEN Ermitteln von Sprunghöhen mit einem Windows Phone Felix Guttbier Schule: Gymnasium Brandis Jugend forscht 2014 ERMITTELN VON SPRUNGHÖHEN

Mehr

Objektorientierte Programmierung für Anfänger am Beispiel PHP

Objektorientierte Programmierung für Anfänger am Beispiel PHP Objektorientierte Programmierung für Anfänger am Beispiel PHP Johannes Mittendorfer http://jmittendorfer.hostingsociety.com 19. August 2012 Abstract Dieses Dokument soll die Vorteile der objektorientierten

Mehr