Mobile 3D-Spieleprogrammierung mit der Mobile 3D Graphics API (M3G) am Beispiel des Handyspieles "MobileBlocks"

Transkript

1 Mobile 3D-Spieleprogrammierung mit der Mobile 3D Graphics API (M3G) am Beispiel des Handyspieles "MobileBlocks" Mobile 3D Gameprogramming with the Mobile 3D Graphics API (M3G) using the Example of the Mobile Game "MobileBlocks" Ulrich Voigt Diplomarbeit Betreuer: Prof. Dr. F. N. Rudolph Berlin,

2 II Danksagungen Ganz besonderer Dank gilt meiner Frau Dioné und meinen Kindern Minas und Lasse, die in den letzten Jahren aufgrund meines Studiums oft ohne mich auskommen mussten und mir verständnissvoll die Zeit gaben, die ich dafür brauchte. Ebenso bedanke ich mich bei meinen Eltern für die großzügige Unterstützung und die Ausdauer die sie dabei aufbringen.

3 III Kurzfassung Diese Diplomarbeit demonstriert am Beispiel des Spieles MobileBlocks, welche Möglichkeiten die Mobile 3D Graphics API zur Entwicklung von 3D Handyspielen bietet. Seitdem zu Beginn dieses Jahrhunderts Java fähige Mobiltelefone auf den Markt kamen, werden auch Spiele für sie entwickelt und erfreuen sich wachsender Beliebtheit. Inzwischen sind die Prozessoren und Speicher vieler Mobiltelefone leistungsstark genug, um auch die performanceintensiveren 3D Spiele auf Handys darstellen zu können. Die Mobile 3D Graphics API bietet mit ihren Funktionen und ihrer inzwischen weiten Verbreitung eine geeignete Plattform, dreidimensionale Inhalte für Mobiltelefone bereit zu stellen. Diese Arbeit beschreibt, wie M3G arbeitet und liefert mit dem selbst erstellten Spiel MobileBlocks ein Beispiel für die praktische Umsetzung ihrer Funktionen.

4 IV Inhaltsverzeichnis 1 Einleitung Problemstellung Aufgabenstellung und Zielsetzung Anwendungsentwicklung für Mobiltelefone Kategorien von Mobiltelefonen Mobile Anwendungsentwicklung Plattformabhängige Entwicklung Plattformunabhängige Entwicklung Entwicklung mobiler 3D Anwendungen OpenGL ES Mobile 3D Graphics API MascotCapsule API OpenGL ES for Java (JSR 239) Mathematische Grundlagen und Konzepte der 3D Programmierung Mathematische Grundlagen der 3D Programmierung Koordinatensysteme Vektoren und Punkte Homogene Koordinaten Matrizen Affine Transformationen Transformationen um einen Pivot Konzepte der 3D Computergraphik Geometrische Primitiven D Modelle Licht und Beleuchtung Texturen Kamera und Projektion Die Transformationspipeline Mobile 3D Graphics API M3G und OpenGL ES M3G - Features und Struktur M3G Konzepte Graphics3D Szenengraphen... 3

5 V Transformationen Animationen Animierte Mesh Objekte Laden externer Dateien und das M3G Dateiformat Geometrie- und Fragmentpipeline Das Handyspiel MobileBlocks Vorstellung des Spieles Spielsteuerung Aufbau und Klassenstruktur des Handyspieles MobileBlocks Rahmenklassen Spielinterne Klassenstruktur Zusammenfassung der 3D Elemente von MobileBlocks Literatur... 7 Index Glossar... 73

6 VI Abbildungsverzeichnis Abbildung 5-1: Drei Finger-Regel [PUL8.]... 1 Abbildung 5-2: Skalarprodukt zweier Vekoren [PUL8.] Abbildung 5-3: Kreuzprodukt zweier Vektoren [PUL8.] Abbildung 5-4: affine Transformationen [PUL8.] Abbildung 5-5: Geometrische Primitiven von OpenGL ES [PUL8.] Abbildung 5-6: Mesh aus verbundenen Dreiecken [PUL8.]... 2 Abbildung 5-7: Lichtreflexion auf Vertexbasis und auf Dreiecksbasis [SCH3.] Abbildung 5-8: Lichtquellen: Punktlicht, Richtungslicht und Spotlicht [PUL8.] Abbildung 5-9: Texturwrapping. Mitte clamp-to-edge, rechts repeat Wrapping [PUL8.] 23 Abbildung 5-1: Perspektivprojektion [HOE7.] Abbildung 5-11: Parallelprojektion [HOE7.] Abbildung 5-12: Transformationspipeline [MAL6.] Abbildung 6-1: M3G Klassenhierarchie [PUL8.] Abbildung 6-2: M3G Klassenhierarchie [PUL8.] Abbildung 6-3: Aufbau eines Mesh Objektes in M3G [PUL8.] Abbildung 6-4: Appearance Komponenten [PUL8.] Abbildung 6-5: Sprite3D, Appearance und Image2D [MOR7.] Abbildung 6-6: field of view, near plane und far plane eines Camera Objektes [MOR7.] Abbildung 6-7: Benutzung eines zusätzlichen Group Knotens zur Implementierung einer Rotation um einen Pivot und achsen-orientierter Skalierung [PUL8.] Abbildung 6-8: Zusammenhang der Klassen KeyframeSequence, AnimationTrack und AnimationController [MOR7.] Abbildung 6-9: Interpolationsmethoden [HOE7.] Abbildung 6-1: Eine Transformation des Bones bewirkt eine Skinverformung [HOE7.] 48 Abbildung 6-11: M3G Dateiformat [HOE7.]... 5 Abbildung 6-12: Referenz der Geometrie- und Fragmentpipeline von M3G (aus: M3G Javadoc) Abbildung 7-1: Icons zur Kamerasteuerung. Links: Translation, Mitte: Rotation, Rechts: Figurensteuerung... 56

7 VII Tabellenverzeichnis Tabelle 1: KeyframeSequence Interpolationsmethoden Tabelle 2: animierbare Eigenschaften in M3G ( animation targets )... 44

8 Einleitung 1 1 Einleitung Schon im Jahr 23 wurden mit der Entwicklung von OpenGL ES und der Mobile 3D Graphics API die Grundlagen geschaffen, auch 3D Anwendungen für Mobiltelefone zu erstellen und damit der Grundstein für die Entwicklung von 3D Handyspielen gelegt. Da die Mobiltelefone jedoch zu dieser Zeit noch wenig Rechenleistung und Speicher zur Verfügung stellten, war die Produktion von 3D Spielen höchstens für einzelne Handymodelle, in einem sehr eingeschränkten Umfang möglich. Dies hat sich mit der Entwicklung von Mobiletelefonen zu Smart Phones, also kleinen Taschencomputern, geändert. Inzwischen gibt es über 2 unterschiedliche Handys, welche die Mobile 3D Graphics API unterstützen 1 und auch das Angebot an 3D Spielen wird immer größer. Auch wenn heute 3D Handyspiele vielleicht noch eine Randerscheinung sein mögen, so zeigt doch die Entwicklung der Computer- und Konsolenspiele, dass erweiterte Fähigkeiten der jeweiligen Plattform gerade in Spielen genutzt werden und die Tendenz meistens hin zu einer realistischeren Darstellung der Spielwelten mittels 3D geht. Schon in wenigen Jahren wird die Masse der Mobiltelefone die gleichen Möglichkeiten bieten, die heute lediglich die neueren Smart Phones zur Verfügung stellen und spätestens dann werden die meisten Handyspiele, wie heute schon im Bereich der Computer- und Konsolenspiele, 3D Spiele sein. 1

9 Problemstellung 2 2 Problemstellung Will man ein 3D Handyspiel entwickeln, stellt sich zunächst die Frage, welche Möglichkeiten zur Verfügung stehen, um dies zu verwirklichen. Es ist notwendig, zu wissen, welche Technologien es dafür bereits gibt und welche Unterstützungen sie leisten, dem Ziel eines lauffähigen 3D Spieles näher zu kommen. Da Handyspiele zu einem, im Vergleich zu Computerund Konsolenspielen, niedrigen Preis angeboten werden, darf der Aufwand, der zur Erstellung eines solchen Spieles notwendig ist, einerseits nicht zu groß sein und andererseits sollte es eine größere Zahl von Mobiltelefonen geben, welche die zu Grunde liegende Technologie auch unterstützen. Schnell wird man bei der Suche nach 3D Technologien für Handys auf OpenGL ES und die Mobile 3D Graphics API stoßen. Doch was ist der Unterschied und welche der beiden Möglichkeiten ist diejenige, die das Potenzial hat, mit möglichst geringem Aufwand, möglichst viele Nutzer zu erreichen?

10 Aufgabenstellung und Zielsetzung 3 3 Aufgabenstellung und Zielsetzung Nahezu jedes auf dem Markt angebotene Handy unterstützt heutzutage die mobile Java Version Java ME und auf den meisten ist zusätzlich auch die Mobile 3D Graphics API installiert. Zwar unterstützen viele Geräte auch OpenGL ES, eine kleinere, für eingebettete Systeme optimierte Version des bekannten 3D Standards OpenGL, aber um diese Schnittstelle ansprechen zu können, muss die Anwendung meist auf Basis der jeweils zugrunde liegenden Plattform programmiert werden. Dies wiederspricht dem Anspruch einer möglichst großen Portabilität des Spieles. OpenGL ES ist eine Schnittstelle auf niedrigem, hardwarenahem Niveau, die, um sie als Basis für Anwendungen und Spiele effektiv einzusetzen, zunächst einmal in eine abstraktere und allgemeinere Engine gekapselt werden muss. Genau das macht die Mobile 3D Graphics API, so dass mit ihr bereits eine fertige und anwendbare 3D Engine vorliegt, die außerdem weit verbreitet ist. Jede 3D Engine bietet auf ihre eigene Art Unterstützung für die zu lösenden Probleme einer dreidimeanionalen Anwendung. Die Mobile 3D Graphics API verfolgt dabei ihre eigenen, eher objektorientierten Ansätze, die für viele 3D Programmierer aus dem Computer- oder Konsolenspielebereich eher ungewohnt sein werden. Diejenigen Programmierer, die zwar Java ME kennen, jedoch noch keine Erfahrung mit der Entwicklung von 3D Spielen haben, erhalten dank der Mobile 3D Graphics API einen relativ einfachen und vertrauten Einstieg in die Welt der 3D Programmierung. Trotzdem ist es notwendig zunächst einmal die Terminologie und die mathematischen Grundlagen einer graphischen 3D Anwendung zu verstehen. Daher werde ich, nach einem allgemeinem Überblick über die Möglichkeiten der Anwendungsentwicklung und speziell der 3D Entwicklung auf Mobiltelefonen, eine kurze Einführung in die Mathematik und Terminologie von graphischen 3D Anwendungen geben. Meine Arbeit erklärt danach die Funktionsweise von M3G, um im letzten Teil mit der Beschreibung des Handyspieles MobileBlocks ein Anwendungsbeispiel zu geben.

11 Anwendungsentwicklung für Mobiltelefone 4 4 Anwendungsentwicklung für Mobiltelefone In diesem Kapitel möchte ich eine kurze Einführung in die Möglichkeiten der Anwendungsentwicklung für Mobiltelefone geben. Zunächst werde ich die heute verfügbaren Handys grob kategorisieren, um danach unterschiedliche Betriebssysteme und Plattformen zu beschreiben. Am Ende dieses Kapitels gebe ich einen kurzen Abriss über die Möglichkeiten der 3D Anwendungsentwicklung für Mobiltelefone. 4.1 Kategorien von Mobiltelefonen Heutige Mobiltelefone lassen sich laut Pulli et. Al. grob in drei Kategorien einordnen: Basic Phones, Feature Phones und Smart Phones [PUL8.]. Obwohl es innerhalb der drei Kategorien große Variationsbreiten gibt, hilft die Einteilung dabei zu beurteilen, welche Möglichkeiten ein Handy für die Ausführung graphischer Anwendungen und insbesondere Spiele bietet. Die Entwicklung schreitet jedoch so schnell voran, dass heutige Smart Phones die Feature Phones von morgen sind und Anwendungen, die heute nur auf High End Smart Phones möglich sind, schon bald massentauglich werden (ebd.). Die Kategorie der Basic Phones ist für graphische Anwendungen nicht weiter interessant, da sie meist eine geschlossene Umgebung mit proprietären Betriebssystemen haben, deren Anwendungen lediglich von den Entwicklern der Handys selbst erstellt werden können. Außerdem ist diese Kategorie von Mobiltelefonen mit sehr geringen Prozessorkapazitäten und kleinen Displays mit geringer Auflösung ausgestattet. Die zweite Katgorie der Feature Phones dagegen bildet die Masse der Mobiltelefone in den Industrieländern, und die meisten von ihnen unterstützen mobile Java Anwendungen. Dies ermöglicht eine relativ einheitliche graphische Anwendungs- und Spieleentwicklung und bietet genügend Programmierschnittstellen für die meisten Multimediabedürfnisse, inklusive 3D Graphiken. Die Java Handys umspannen jedoch eine so große Bandbreite bezüglich Performance und zur Verfügung stehender Features, dass viel Zeit investiert wird, Anwendungen an die unterschiedlichen Gegebenheiten der einzelnen Geräte anzupassen (ebd.). Die dritte Kategorie der Smart Phones entwickelt sich schon jetzt zu vollwertigen, tragbaren Computern. Ihre Schlüsselfeatures sind große, scharfe und helle Farbdisplays, schnelle Prozessoren, viel Speicher und üppige Multimedia Ausstattungen. Einige der neueren Geräte beinhalten auch ausgewiesene 3D Hardwareunterstützung. Die Betriebssysteme lassen die Installation von Fremdanwendungen ebenso zu wie Java Anwendungen, und sowohl die Mobile 3D Graphics API, als auch OpenGL ES stehen meist für 3D Inhalte zur Verfügung (ebd.).

12 Anwendungsentwicklung für Mobiltelefone Mobile Anwendungsentwicklung Während in der Welt der Desktopcomputer lediglich drei Hauptfamilien von Betriebssystemen existieren, gibt es dutzende Betriebssysteme für Mobiltelefone. Traditionell waren alle Handy Betriebssysteme geschlossene Systeme, was bedeutet, dass lediglich die Hersteller Anwendungen für sie entwickeln und installieren konnten. Sie dienten ja auch hauptsächlich dem Zweck des Telephonierens. Dies hat sich mit der Entwicklung von Mobiltelefonen zu kleinen Taschencomputern geändert. Alle Anwendungen selbst zur Verfügung zu stellen bedeutet eine große und teure Entwicklungsaufgabe für einen einzelnen Hersteller, so dass erst durch das Öffnen der Handyplattformen die Bandbreite der verfügbaren Anwendungen deutlich wachsen konnte. Heute haben fast alle vertriebenen Mobiltelefone eine offene Entwicklungsumgebung, auch wenn für einige erst Zertifikate vom Hersteller benötigt werden, damit Anwendungen für sie erstellt werden dürfen. Beispiele für offene Plattformen sind Java, BREW/WIPI, Linux, Palm OS, Symbian OS und Windows Mobile (ebd.). In neuester Zeit sind noch das Apple iphone und Google s Android hinzugekommen Plattformabhängige Entwicklung Native Anwendungen, also Anwendungen, die direkt im Maschinen Code des Zielprozessors kompiliert wurden, haben den Vorteil, dass sie ihren Code direkt auf der Hardware des Zielgerätes ausführen können. Dadurch haben sie einerseits die Möglichkeit, auf alle geräteinternen Features zuzugreifen und können andererseits die maximale Performance erzielen. Der große Nachteil dieser Anwendungen ist die fehlende Portabilität auf andere Plattformen und die Gefahr, dass fehlerhafte Ausführungen der Programme das ganze System zum Absturz bringen können. Ich möchte hier nur ganz kurz die wichtigsten nativen Plattformen erwähnen Symbian OS Das zurzeit marktführende Betriebssystem für Smart Phones ist Symbian OS, der Firma Symbian, die jedoch zu Nokia gehört. Auf Basis von Symbian OS arbeiten die Benutzeroberflächen S6, S8, S9 und UIQ. Symbian OS wird aber nicht nur von Nokia verwand, sondern unter anderem auch von Sony Ericsson, Motorola und Siemens. Symbian OS unterstützt, ähnlich wie Desktop Betriebssysteme, Multithreading, präemptives Multitasking und Speicherschutz. Aufgrund der weiten Verbreitung von Symbian OS ist dieses Bertiebssystem auch in den Fokus von Virenprogrammierern gerückt. Durch Einführung eines Zertifikatsystems ist jedoch das Ausführen von unerwünschtem Code stark eingeschränkt worden. 2 Die native Programmiersprache von Symbian OS ist das Symbian C++. Besonderheiten des Symbian C++ sind ein strenges Exception Handling und Speichermanagement. Es bietet durch seine Klassenbibliotheken Zugriff auf unterschiedliche Features der Mobilfunkgeräte. 3 Aufgrund der weiten Verbreitung von Symbian OS und der Plattformen S6 und UIQ, welches die Touchscreen Variante von S6 darstellt, wird der Nachteil der geringen Portabilität der nativen Anwendungen bis zu einem gewissen Grad aufgefangen. Aus diesem Grund ist das Angebot von Symbian Anwendungen inclusive Spielen relativ groß. Insbesondere die von

13 Anwendungsentwicklung für Mobiltelefone 6 Nokia wiedererweckte Spieleplattform N-Gage baut auf Symbian OS auf und bietet hochwertige Handyspiele, zum Teil auch in 3D auf Basis von OpenGL ES, an Windows Mobile Microsofts Windows Mobile ist ein mobiles Betriebssystem, welches auf der Microsoft Win32 API basiert. Es wird vor allem auf PDAs aber auch für Smart Phones benutzt und ähnelt in seiner Oberfläche den Desktop Varianten von Windows. 5 Auch Windows Mobile ist weit verbreitet, wobei seine Anwendungsausrichtung jedoch deutlich stärker in Richtung Office Anwendungen tendiert. Eine eigene Spielplattform, wie N- Gage für Symbian Geräte gibt es hier daher nicht. Windows Mobile unterstützt auf vielen Geräten zur 3D Programmierung Direct3D 6, aber auch OpenGL ES Apple iphone Das iphone von Apple nutzt als Betriebssystem ein angepasstes Mac OS X für Flashspeicher. 8 Zur Entwicklung von iphone und ipod Touch Software ist man gezwungen, einen Macintosh Computer zu benutzen, wobei als Programmierspache Objective-C zum Einsatz kommt. Ein kostenloses SDK stellt Apple nebst der IDE Xcode nach einer Registrierung zur Verfügung. Auf das Mobiltelefon selbst darf jedoch nur signierte Software, so dass zur Entwicklung nur der Emulator zur Verfügung steht. Die Zahl der für das iphone zur Verfügung stehenden Anwendungen wächst sehr schnell, da das Interesse der Entwickler am Geschäft des iphones teilzuhaben scheinbar sehr groß ist. 9 Das iphone unterstützt OpenGL ES zur Entwicklung von 3D Software Android Das von der Open Handset Alliance entwickelte mobile Betriebssystem Android basiert auf dem Linux-Betriebssystem und nutzt als Programmiersprache Java. Die Laufzeitumgebung von Android basiert auf der Dalvik Virtual Machine, die ähnlich wie die Java VM funktioniert, jedoch eine Registermaschine darstellt. Anwendungen für Android werden in Java geschrieben und können mit dem Android SDK entwickelt werden. 11 Auch die Android Plattform unterstützt zur mobilen 3D Entwicklung OpenGL ES. 12 Momentan kann man in Deutschland noch kein Android Handy erwerben, in den USA ist jedoch inzwischen mit dem T-Mobile G1 das erste Mobiltelefon auf Basis der Android Plattform auf dem Markt Siehe: c t Magazin für Computertechnik Ausgabe 18/28 S.18ff

14 Anwendungsentwicklung für Mobiltelefone Plattformunabhängige Entwicklung Java Micro Edition Da heutzutage fast alle Mobiltelefone mit J2ME Unterstützung ausgeliefert werden, ist die Java Micro Edition inzwischen die am weitesten verbreitete Anwendungsplattform überhaupt [PUL8.]. Die Plattformunabhängigkeit von Java ME erlaubt es den Entwicklern Anwendungen zu erstellen, die auf den unterschiedlichsten Mobiltelefonen verwendbar sind. Zur Entwicklung von 3D Anwendungen stellt Java ME auf vielen Handys die M3G API zur Verfügung. Es gibt jedoch auch noch andere Klassenbibliotheken, die mit J2ME zusammen verwendbar sind und eine Schnittstelle zur 3D Programmierung bieten (siehe unten). Die Java Plattform stellt eine hervorragende Ergänzung für ein ansonsten geschlossenes System dar. Sie gewährleistet Sicherheit, Stabilität und Portabilität dank des Designs ihrer Virtual Machine, während die Kosten für Dokumentation und Support auf alle Firmen verteilt wird, die an der Java Standardisierung teilhaben (ebd.). Die sichere und robuste Architektur der Java Virtual Machine hat jedoch ihren Preis: Das Abschirmen der Anwendungen von der darunterliegenden Software und Hardware macht Low- Level Optimierungen unmöglich und bietet der Anwendung nur eingeschränkten Zugang zu den Features eines Mobiltelefons. Die Performance der Anwendungen kommt meist nicht an die einer nativen Anwendung heran. Es ist laut Pulli et. Al. ganz besonders auf mobilen Geräten kein Mythos, dass in Java programmierter Code langsamer ist als C und C++ (ebd.) Flash Lite Neben J2ME hat sich seit einiger Zeit auf vielen Mobiltelefonen die Unterstützung von Flash Lite etabliert. Flash Lite ist eine für mobile Geräte optimierte Version des Flash Players der Firma Adobe. Mit Hilfe der Programmiersprache Action Script lassen sich so auch interaktive Anwendungen wie Benutzeroberflächen, aber auch Spiele erstellen. Flash und auch Flash Lite benutzen dafür Vektorgrafiken, was eine Skalierung ohne Qualitätsverlust ermöglicht und eine Portierung auf unterschiedliche Geräte mit verschiedenen Displaygrößen vereinfacht. Neben der noch nicht so großen Verbreitung und geringer Soundunterstützung ist die schlechtere Performance aufgrund des größeren Rechenaufwands für Vektorgraphiken, ein Nachteil, den Flash Lite gegenüber Java ME bietet

15 Anwendungsentwicklung für Mobiltelefone Entwicklung mobiler 3D Anwendungen Die weltweit ersten Mobiltelefone mit einer eingebetteten 3D Engine wurden in Japan im Jahr 21 von der Firma J-Phone vertrieben [PUL8.]. Die Grafik Engine war eine frühe Version der Mascot Capsule Engine der Firma HI Coorporation. Der Hauptzweck dieser frühen Anwendungen war es, einfache 3D Objekte zu animieren (ebd.). Außerhalb Japans war das erste Mobiltelefon, welches 3D Grafiken unterstützte, das Nokia 341, welches im Jahr 22 in Europa vertrieben wurde. Es hatte noch einen monochromen Bildschirm mit einer Auflösung von lediglich 96x65 Pixeln, unterstützte aber schon alle essentiellen 3D Render Features und ähnelte der OpenGL ES Version 1. (ebd.). Andere frühe 3D Grafik Engines waren Swerve von Superscape, ExEn (Execution Engine) von InFusio, X-Forge von Fathammer und Mophun von Synegetics (ebd.). Es waren alles Middleware- und Spielengine Lösungen, die High-Level Features wie Animation, binäre Dateiformate und oftmals auch Eingabeverarbeitung und Sound unterstützten. Das Fehlen einer einheitlichen Plattform machte es jedoch schwer, genügend Marktsegmente zu besetzen, um gewinnbringend Anwendungen zu erstellen (ebd.). Im Jahr 22 gründete die Khronos Group, ein Standardisierungskonsortium zur Spezifizierung und Förderung mobiler Multimedia APIs, ein Komitee, um eine abgespeckte OpenGL Version für mobile Geräte zu entwickeln. In Konkurenz dazu bildete sich unter der Führung von Nokia eine Initiative, um eine High-Level 3D API für Java ME zu standardisieren. Beide Standards wurden Seite an Seite entwickelt und beeinflußten einander, da teilweise die gleichen Leute an beiden Projekten mitwirkten. Im Herbst 23 wurden sowohl OpenGL ES 1., als auch M3G 1. im Abstand von nur wenigen Monaten veröffentlicht. Ein Jahr später konnten dann die ersten Implementierungen auf Mobiltelefonen vertrieben werden (ebd.) OpenGL ES OpenGL ES ist eine kompakte Version des bekannten Grafikstandards OpenGL. Es handelt sich um eine Low-Level Rendering API, die auf die Bedürfnisse von eingebetteten Systemen angepasst ist. Die erste Vesion, OpenGL ES 1., hatte zum Ziel, eine extrem kompakte API zur Verfügung zu stellen, ohne dabei auf wichtige Features zu verzichten. Sie musste als volle Softwareimplementierung mit weniger als 5KB Code auskommen, jedoch gleichzeitig eine Hardwarebeschleunigung ermöglichen. Die grafischen Effekte, die von den Desktop Versionen bekannt waren, sollten dennoch zur Verfügung stehen (ebd.). Die spätere Version OpenGL ES 1.1 beinhaltete mehr Features zur Unterstützung von Hardwarebeschleunigung, die zusammen mit den ersten 3D Graphikchips verfügbar wurde. Die letzte Version, OpenGL ES 2., stellt eine völlig überarbeitete API zur Verfügung und ist nicht rückwärtskompatibel zu den 1.x Versionen. Die 1.x und 2.x Versionen koexistieren jedoch insofern, als dass alle OpenGL 2.x Geräte auch mit Version 1.1 Treibern ausgestattet werden (ebd.). Eine OpenGL ES unterstützende API ist EGL. Sie kümmert sich um die Integration von O- pengl ES in das zugrundeliegende System und managt Render Targets und Kontexte (ebd.).

16 Anwendungsentwicklung für Mobiltelefone Mobile 3D Graphics API Als die ersten Java fähigen Mobiltelefone im Jahr 2 auf den Markt kamen, wurde ersichtlich, dass die Performance und der Speicheroverhead von Java für Echtzeit 3D Anwendungen ungeeignet waren. Daraus ergab sich die Notwendigkeit, eine neue Standard API zu entwickeln, die so viele Berechnungen wie möglich in nativen Code auslagern konnte. M3G war eine völlig neue High-Level API, die Ideen aus früheren APIs wie Java 3D und OpenInventor entlehnte. Sie besteht aus einer Baumstruktur mit Knoten, welche die 3D Elemente kapseln. Die Knoten können so zu einem Szenengraphen verbunden werden, dass er die grafischen Objekte und ihre Beziehung zueinander repräsentiert. M3G ist so entworfen, dass es effizient auf Basis des OpenGL ES Renderers implementiert werden kann (ebd.). Da M3G das Hauptthema dieser Arbeit darstellt, werde ich mich weiter unten tiefgehend mit dieser Schnittstelle befassen MascotCapsule API MascotCapsule ist eine 3D Rendering Engine für mobile Geräte, die von der japanischen Firma HI Corporation entwickelt und 21 das erste Mal kommerziell genutzt wurde [HOE7.]. Die Version V4 bietet Unterstützung für M3G und ist rückwartskompatibel zu Version V3. Im Vergleich zu M3G bietet MascotCapsule weniger Features, ist aber gerade durch seine Einfachheit performanter. Version V3 überbrückt die Unterschiede zwischen älteren Geräten und solchen mit erweiterten Fähigkeiten (ebd.). Ähnlich wie M3G bietet MascotCapsule auch Unterstützung zum Laden von Binärdateien. Die 3D Daten werden hier in Modell Dateien mit der Endung.bac und Animationsdateien mit der Endung.tra aufgeteilt. Texturdaten werden als.bmp Dateien gespeichert und geladen (ebd.) OpenGL ES for Java (JSR 239) JSR 239, auch als JOGL (Java Bindings for OpenGL ES) bezeichnet, ist eine Java Spezifikation, deren Ziel es ist, OpenGL ES und EGL mobilem Java so direkt wie möglich zur Verfügung zu stellen. Es verspricht volle OpenGL ES Funktionalität für eine maximale Performance und Flexibilität. Die unterschiedlichen Versionen von OpenGL ES werden hier als eine Hierarchie von Java Schnittstellen präsentiert [PUL8.]. Als Java API erweitert JSR 239 die Fehlerbehandlungen von OpenGL ES mit zusätzlichen Exceptions, um potentielle Risiken für die Systemstabilität und -sicherheit auszuschalten. Bis jetzt ist die Anzahl der Handys, die JSR 239 unterstützen jedoch noch recht klein (z.b. Sony Ericsson Z75).

17 Mathematische Grundlagen und Konzepte der 3D Programmierung 1 5 Mathematische Grundlagen und Konzepte der 3D Programmierung Bevor ich die Funktionen der Mobile 3D Graphics API beschreibe, möchte ich einen kurzen Überblick auf die mathematischen Grundlagen der 3D Programmierung geben und anschließend einige grundlegende Konzepte der 3D Computergraphik vorstellen. 5.1 Mathematische Grundlagen der 3D Programmierung Koordinatensysteme Um Formen und Positionen zu definieren benötigt es eine Referenz. Diese stellt das Koordinatensystem zur Verfügung und definiert einen Raum. Den Ursprung eines Koordinatensystems bildet ein Punkt, während seine Achsen Richtungen darstellen. Dreidimensionale Koordinatensysteme haben drei Achsen, die normalerweise mit den Buchstaben x, y und z bezeichnet werden. Jede Achse hat eine Längeneinheit und ist senkrecht zu den anderen Achsen positioniert. Werden zunächst die x- und die y-achse senkrecht zueinander positioniert, dann gibt es zwei Möglichkeiten die z-achse anzulegen. Die Wahl der Positionierung der z- Achse entscheidet daher darüber, ob ein Koordinatensystem rechtshändig oder linkshändig orientiert ist. Die Rechtshändigkeit eines Koordinatensystems läßt sich mit der 3 Finger Regel überprüfen (siehe Abb. 5-1). Abbildung 5-1: Drei Finger-Regel [PUL8.] Mit Ausnahme des globalen Weltkoordinatensystems, wird ein Koordinatensystem immer in Bezug zu einem anderen Koordinatensystem gesetzt. So hat jedes 3D Objekt sein eigenes lokales Koordinatensystem, welches in Beziehung zu dem System des Raumes steht, der das Objekt umgibt [PUL8.].

18 Mathematische Grundlagen und Konzepte der 3D Programmierung Vektoren und Punkte Innerhalb eines 3D Koordinatensystems ist jede Position im Raum ein Punkt, der durch seine Koordinaten beschrieben werden kann. Ein Vektor dagegen ist eine Verschiebung, eine Differenz zwischen zwei Punkten. Ein Vektor hat keine Position, jedoch eine Richtung und eine Länge. Ähnlich wie Punkte können Vektoren durch Koordinaten beschrieben werden. Der Vektor v ab, der die Verschiebung von Punkt a nach Punkt b darstellt, hat die Koordinaten: v ab = [b x - a, b x y - a y, b z - a z ] Formel 1: Vektor v ab zwischen den Punkten a und b Ein Punkt lässt sich auch durch einen Vektor vom Ursprung zu dem Punkt selbst darstellen (ebd.). Die Summe zweier Vektoren bildet einen neuen Vektor. Vektoren können auch mit skalaren Werten multipliziert werden, wodurch sich die Länge des Vektors ändert: a v = [av, av, av ] x y z Formel 2: Multiplikation des Vektors v mit dem Skalar a Es gibt zwei Arten, Vektoren miteinander zu multiplizieren: Das Skalarprodukt und das Kreuzprodukt. Das Ergebnis des Skalarproduktes ist ein Skalar. Es lässt sich auf zwei verschiedene Arten darstellen: a b = a x b x + a y b y + a z b z a b = cos(θ ) a b Formel 3: zwei Darstellungen des Skalarproduktes Die erste Darstellung ist algebraisch und benutzt die Vektorkoordinaten. Die zweite ist geometrisch und basiert auf den Längen der Vektoren und dem kleinsten Winkel zwischen ihnen. Eine der wichtigsten Eigenschaften, die mit dem Winkel einhergehen, ist die, dass bei senkrecht zueinander stehenden Vektoren das Skalarprodukt ergibt (siehe Abb. 5-2).

19 Mathematische Grundlagen und Konzepte der 3D Programmierung 12 Abbildung 5-2: Skalarprodukt zweier Vekoren [PUL8.] Das Kreuzprodukt zwischen zwei Vektoren existiert nur im dreidimensionalen Koordinatensystem. Aus ihm entsteht ein neuer Vektor. a b = [ aybz azby, azbx axbz, axby a ybx ] Formel 4: Kreuzprodukt zweier Vektoren a und b Der durch das Kreuzprodukt der Vektoren entstandene Vektor ist senkrecht zu den Vektoren a und b (siehe Abb. 5-3). Die Länge des neuen Vektoren entspricht sin(θ ) a b. Sind a und b parallel, dann ist seine Länge. Wird die Multiplikation umgekehrt, dann ändert sich das Vorzeichen des Ergebnisses (ebd). Abbildung 5-3: Kreuzprodukt zweier Vektoren [PUL8.] Homogene Koordinaten Es kann sehr verwirrend sein, Punkte und Richtungen durch Vektoren mit drei Koordinaten zu repräsentieren. Homogene Koordinaten können diesen Unterschied besser darstellen: Es wird einfach eine vierte Koordinate (w) hinzugefügt. Ist w =, dann handelt es sich um eine Richtung, ansonsten um einen Punkt (ebd.). Um einen Punkt mit den homogenen Koordinaten [h x, h y, h z, h w ] in einen 3D Punkt umzurechenen, dividiert man die Komponenten durch den Wert von h w. Ist h w =, dann erhält man einen Punkt, der eine unendliche Entfernung besitzt. Dies wird als die Richtung zum Punkt [h x, h y, h z ] interpretiert. Umgekehrt kann man den Punkt [hx, hy, hz] durch hinzufügen der

20 Mathematische Grundlagen und Konzepte der 3D Programmierung 13 vierten Komponente homogenisieren: [p x, p y, p z, 1]. Tatsächlich kann man jeden Wert der ungleich Null ist für w benutzen, um den gleichen Punkt zu erhalten: [wp x, wp y, wp z, w] (ebd.). Es läßt sich auch erkennen, dass für normalisierte homogene Koordinaten (w ist entweder oder 1) aus der Differenz zweier Punkte ein Richtungsvektor entsteht (w wird zu 1-1=). Aus der Addition eines Richtungsvektors zu einem Punkt entsteht dagegen wieder ein Punkt, der entgegen dem alten um die Werte des Vektors verschoben wurde (w wird zu 1+=1). Es gibt noch einen weiteren, wichtigeren Grund, für die Benutztung homogener Koordinaten: Sie erlauben es, alle linearen 3D Transformationen mit einer 4x4 Matrix, die auf 4x1 homogenen Vektoren basiert, auszudrücken. Diese Darstellung ist so mächtig, dass sich mit ihr Verschiebungen, Rotationen, Skalierungen, Scherungen und sogar Perspektiv- und Parallelprojektionen ausdrücken lassen (ebd.) Matrizen Eine 4x4 Matrix M besteht aus den Komponenten m ij, wobei i die Reihe bezeichnet und j die Spalte: M m m = m m m m m m m m m m m m m m Formel 5: 4x4 Matrix Ein Spaltenvektor v besitzt die Komponenten v i : v v = v v3 [ v v v v ] T 1 v = Formel 6: Spaltenvektor und transponierte Form Die Transponierung wandelt einen Spaltenvektor in einen Reihenvektor um, und umgekehrt. Bei einer Matrix M=[m ij ] bewirkt eine Transponierung eine Spiegelung an der Diagonalen, das heißt, die Spalten werden zu den Reihen: M T =[m ji ] (ebd.) Matrix Produkte Das Produkt einer Matrix mit einem Vektor erzeugt einen neuen Vektor. Sowohl Richtungen als auch Positionen werden durch die Multiplikation des entsprechenden homogenen Vektors v mit einer Transformationsmatrix M transformiert: v =Mv. Jede Komponente des Spaltenvektors v ergibt sich durch ein Skalarprodukt einer Reihe von M mit v, wobei M genauso viele Spalten haben muss, wie v Reihen: