Upload
lethien
View
224
Download
0
Embed Size (px)
Citation preview
JSR – 184
Mobile 3D Graphics APIMobile 3D Graphics API
M3GM3GVortrag an der Hochschule Fulda
November 2010, Dipl.-Inf (FH) Jeronimo Werder
Einleitung
● Bisher 3D-Grafik hauptsächlich in PCs● Jetzt in vielen anderen Systemen, wie
– Set-Top-Boxes (z.B. DVD-Player/-Rekorder, Spielekonsolen u. ä.)
– Navigationsgeräte, Boardcomputer im Auto– mobile Spielekonsolen– PDAs, PocketPCs– Mobiltelefone
Klassifikation der Mobiltelefone
● Mobiltelefone lassen sich in drei Gruppen einteilen:– Basicphones geschlossene Plattform
nur der Hersteller kann Anwendungen schreiben und auf dem Gerät installieren
– Featurephones offene PlattformMöglichkeit eigene Anwendungen zu programmieren und zu installieren, Zertifizierung durch Anwender oder Hersteller wird benötigt
– Smartphones offene native PlattformMöglichkeit native binäre Anwendungen zu installieren
Einschränkungen von Mobiltelfonen
● Mobiltelefone werden mit Strom von Akkus versorgt
● Moore´sches Gesetz bei der Prozessorleistung(40-60% mehr Schaltkreise/Jahr)
● Das Gesetz gilt nicht für die Akkutechnologie(max. 10% mehr Energiekapazität/Jahr)
● Gene´sches Gesetz hilft der Entwicklung(Energiebedarf und Hitzeentwicklung halbiert sich alle 16 Monate)
Erste 3D-Grafiken auf Mobiltelefonen
● Erste Mobiltelefone mit 3D-Grafik 2001 in Japan (mit einer frühen Version der Mascot Capsule Engine von HI-Corporation)
● Erstes auf dem europäischen Markt: Im Jahr 2002 das Nokia 3410 aber noch mit monochromen Display
● Andere frühe Grafik-Engines waren in Game-Engines wie Swerve, Mascot Capsule oder X-Forge usw.
● Sie alle basieren auf Softwarerendering
Viele 3D-Grafik-APIs
● Viele 3D-Grafik-APIs für mobile Endgeräte– Manche basieren auf OpenGL:
● PocketGL, TinyGL, miniGL, Klimt– Direct 3D Mobile basiert auf DirectX 8.0– Unzählige Game-Engines
● Im 2D-Bereich haben sich ebenfalls viele APIs entwickelt– z.B.: SVG Tiny, SVG Basic, OpenVG JSR-226 und
der Nachfolger JSR 287
Grafikstandards
● Problem: – Viele Lösungen für dasselbe Problem– Fehlende Portabilität für Drittanbieter– Verlangsamung der Entwicklung auf dem
Softwaremarkt● Lösung Grafikstandards:
– Bessere Dokumentation– größere Wiederverwertbarkeit von Quellcode– bessere Portabilität
Grafikstandards
● Im Jahr 2002 spezifiziert die Khronos-Gruppe OpenGL|ES
● Gleichzeitig wurde vom JCP die Mobile 3D Graphics API (M3G) unter der Nummer JSR 184 spezifiziert.
● Beide APIs wurden parallel zueinander entwickelt und beeinflussten sich gegenseitig
Anforderungen mobile Grafik-APIs
● Niedrige Komplexität● Ein hoher Abstraktionsgrad● Kleine Programme● Hardwarefreundlichkeit● Produktivität● Orthogonales Feature Set● Erweiterbarkeit● Minimale Fragmentierung
OpenGL|ES vs. M3G
● OpenGL|ES– ist eine Teilmenge von OpenGL– ist eine reine „Low-Level“-API, die eine Schnittstelle
zu Hardwarefunktionalität darstellt● Mobile 3D Graphics API
– ist eine komplett neu entwickelte „High-Level“-API, basiert nicht auf Java 3D
– bietet Funktionalitäten wie Szene-Graphen, eigenes Dateiformat und Animation
OpenGL|ES vs. M3G
● OpenGL|ES– wird direkt für das jeweilige Betriebssystem
kompiliert– ist für C/C++ implementiert
● Mobile 3D Graphics API– baut konzeptionell auf OpenGL|ES auf– ist eine Java-API => Virtual Machine interpretiert
den Bytecode
Anforderungen an M3G
● Muss High-Level-Rendering (Retained Mode) unterstützen
● Muss direkten Zugriff auf den Frame-Buffer (Immediate Mode) unterstützen
● Darf keine optionalen Teile enthalten● Muss Importer für Schlüsseldatentypen (z.B.
Meshes, Texturen, komplette Szenegrahen zur Verfügung stellen
● Implementierbar auf Basis von OpenGL|ES
Anforderungen an M3G
● Muss den nativen Float-Datentypen von Java unterstützen
● Muss auch ohne Hardware für Fließkomma-berechnungen effizient implementierbar sein
● Muss in unter 150KB implementierbar sein● Muss so strukturiert sein, dass Garbage
Collection minimiert wird● Muss vollständig kompatibel mit anderen Java
APIs sein (insbesondere mit MIDP)
Abgerenzung von anderen Java-APIs
● Java Bindings for OpenGL|ES (JSR 239)● Mobile Media API (MMAPI, JSR 135)● Scalable 2D Vector Graphics API for J2ME
(JSR 226 und 2.0-Version JSR 287)● kein Zusammenhang mit Java3D ● aktuelle Version von M3G ist 1.1, die Version
2.0 wird zur Zeit entwickelt (JSR 297)
J2ME – Die Grundlage von M3G
● Seit 1999 gibt es die Java 2 Plattform in drei Editionen:– Java 2 Enterprise Edition (J2EE) für serverseitige
Lösungen– Java 2 Standard Edition (J2SE) für Desktop-
Applikationen– Java 2 Micro Edition (J2ME) für kleine ressourcen-
beschränkte Geräte
Die drei Java Editionen
● J2ME hat im Gegensatz zu J2EE nur eine sehr kleine Schnittmenge mit J2SE
Quelle: [WER08]
Konfigurationen, Profile und optionale Pakete
● Die J2ME ist in verschiedene Schichten aufgeteilt:– Konfiguration– Profil– optionale Pakete
Konfigurationen, Profile und optionale Pakete
● Die Konfiguration definiert die kleinstmögliche Funktionalität einer bestimmten Geräteklasse– stellt die Virtual Machine (VM)– definiert die unterstützten Sprachmittel
Konfigurationen, Profile und optionale Pakete
● Das Profil erweitert die Konfiguration um spezielle Leistungsmerkmale bzw. Klassenbibliotheken.
● Anders als bei der Konfiguration darf das Profil optionale Teile enthalten
Konfigurationen, Profile und optionale Pakete
● Die optionalen Pakete sind Klassenbibliotheken, die Funktionalität anbieten, die über Profile hinausreichen.
● Werden von einer JCP-Expertengruppe in einem Java Specification Request (JSR) definiert.
in Anlehnung an: [SCH04]
M3G im Java Software-Stack
● Die Position von M3G innerhalb des Java Software-Stacks
Quelle: [PUL08]
MIDlets
● Die Java-Applikationen für das MIDP werden MIDlets genannt
● Ein oder mehrere MIDlets werden wiederum zu einer MIDlet-Suite zusammengefasst, die die kleinste installierbare Einheit bildet
● Die Funktionalität zum Installieren und Ausführen eines MIDlets muss vom Gerät selbst zur Verfügung gestellt werden
MIDlets
Architektur eines typischen M3G-Gerätes, Quelle: [HÖF07]
MIDlets
● Diese Funktionalität zum Ausführen und der Installation u.s.w. wird unter dem Begriff Application Management Software (AMS) zusammengefasst
● Eine MIDlet-Suite wird mit ihren Klassen und Ressourcen in einem JAR-Archiv verpackt
● Im JAR-Archiv ist auch eine Manifest-Datei, die Metainformationen über das MIDlet enthält
MIDlets
● MIDlets müssen den Anforderungen von Mobiltelefonen, wie geteilte Ressourcen und eingehende Anrufe, gerecht werden
● Daher haben MIDlets keine main()-Methode● MIDlets werden von Ereignissen gesteuert● Daher werden statt der main()-Methode ein
Satz von Event Handler implementiert
MIDlets
● Ein MIDlet kann sich in einem der drei Zustände befinden
● Der Übergang zwischen den Zuständen wird durch die AMS über die drei Eventhandler gesteuert
Lebenszyklus eines MIDlets, Quelle: [PUL08]
MIDlets
● Die Event Handler finden sich in der Klasse MIDlet des MIDP
● Daher muss ein MIDlet auf jeden Fall die Klasse MIDlet erweitern und die Methoden startApp(), pauseApp() und destroyApp() implementieren
MIDlets
Erweiterung der Klasse MIDlet, Quelle: [SPE05]
M3G noch näher betrachtet
● Nachdem das Grundgerüst für ein MIDlet geschaffen wurde, kann nun näher auf M3G eingegangen werden
● Der Benutzer hat nun die Möglichkeit, sowohl auf einer High-Level-Ebene als auch auf der Low-Level-Ebene zu programmieren
● Es können auch High-Level-Eigenschaften zusammen mit Low-Level-Eigenschaften gemischt werden
Immediate Mode vs. Retained ModeLow Level vs. High Level
● Dem entsprechend unterstützt M3G zwei Modi:– Immediate Mode – Retained Mode
● Immediate = direkt, sofort, ...kann auch als „Low-Level Mode“ angesehen werden
● Retained = zurückbehalten, einbehalten, ...kann auch als „High-Level Mode“ angesehen werden.
Immediate Mode Rendering
● OpenGL war ursprünglich eine reine Immediate Mode API
● Erstes Retained Mode Konzept waren die Display Listen
Retained Mode Rendering
● Frühe Szenengraphen wie Performer von SGI wurden entwickelt um die Performanzprobleme vom Immediate Mode zu lösen
● Vorteil des Immediate Modes ist die volle Kontrolle über die Render-Engine
● M3G dagegen wurde von Grund auf als ein Retained Mode System entwickelt
● Herzstück des Retained Modes ist der Szenengraph
Retained Mode Rendering
● Ein Beispiel für einen Szenengraphen
Retained Mode Rendering
● Hauptzweck des Szenengraphen in M3G:– Visibility Culling
● zu weit entfernte Objekte, verdeckte Objekte werden vom Rendering ausgeschlossen
– hierarchische Transformationen● Beispiel Sonnensystem (siehe vorherige Folie)
– View Frustum Culling● Bounding Volume Hierarchie bestimmt durch einfache
umschreibende Körper, ob ein Objekt sich im Sichtfeld befindet
Retained Mode Rendering
● Einfache Körper umschreiben komplexere ● Bounding Volumes können seinerseits unter-
geordnete Bounding Volumes umschreiben
Beispiel für eine Bounding Volume Hierarchie, Quelle: [PUL08]
Retained Mode Rendering
● Ablauf des Retained Mode Rendering aus Sicht einer typischen M3G-Implementierung:
Grafik nach [PUL08]
Retained Mode Rendering
● Aus Sicht des Softwareentwicklers bzw. des Anwenders:
– Retained Mode Rendering = Rendern des gesamten Szenen Graphen
– Immediate Mode Rendering = Rendern einer Geometrie, eines Knoten oder Teils des Szenengraphen
Der Szenengraph in M3G
Quelle: [SPE05]
Die Klassen von M3G
Die Klassenstruktur des Pakets javax.microedition.m3g, Quelle: [PUL08]
Die Klassen von M3G ● Die gestrichelte Linie umkreist die Klassen,
welche die Low-Level Eigenschaften von M3G abbilden (Wrapper-Klassen von OpenGL ES).
● M3G stellt als geometrische Primitive nur noch den Triangle Strip zur Verfügung.
Links werden zum Ver-gleich die geometrischen Primitive von OpenGL ES gezeigt
Quelle: [PUL08]
Die Klassen von M3G
● Fast alle Eigenschaften von OpenGL ES 1.0 werden durch M3G zur Verfügung gestellt
● Die Szenengraphknoten sind alle von der Klasse Node abgeleitet
● Ein Körper wird durch die Klasse Mesh repräsentiert
● Zusätzlich gibt es noch deformierbare Varianten von Mesh: SkinnedMesh und MorphingMesh
Die Klassen von M3G
● M3G ermöglicht die Keyframe-Animation● Die Klasse KeyFrameSequence speichert die
Keyframes● Die Klasse AnimationController legt die
Geschwindigkeit der Animation fest● AnimationTrack verbindet schließlich die
Keyframesequenz, die Animationskontrolle und das Zielobjekt
Die Klassen von M3G
● Eine sehr wichtige High-Level-Eigenschaft bietet die Klasse Loader
● In der M3G-Spezifikation wird ein eigenes Binärformat definiert, das alle Eigenschaften der API abbildet
● Durch das Binärformat wird eine Trennung von gestalterischen Inhalten und der programmierbaren Anwendungslogik wesentlich erleichtert
Die Klassen von M3G
● Mit der Klasse Loader lassen sich also ganze Szenen und Szenengraphen aus M3G-Dateien importieren
● Darüber hinaus lassen sich auch individuelle Bilder aus PNG und JPEG-Dateien laden
● Loader kann nicht instantiiert werden und bietet nur zwei statische Methoden:Object3D[] load(String name)Object3D[] load(byte[] data, int offset)
Die Klassen von M3G
● Die Klasse RayIntersection speichert eine Referenz auf ein sich überkreuzendes Mesh oder Sprite3D.
● Dazu wird vom Anwender mit der Methode pick() ein Strahl in die Szene geschickt und die Methode füllt dann das RayIntersection-Objekt mit einer Referenz auf das Objekt, dass sich mit dem Strahl schneidet.
Das Rendering-Konzept von M3G
● M3G stellt nur den 3D-Grafikkontext zur Verfügung.
● M3G selbst stellt keine 2D-Oberfläche für die Anzeige auf dem Display zur Verfügung.
● Diese Aufgabe übernehmen andere APIs wie beispielsweise das MIDP.
● Es muss also eine 2D-Oberfläche als Render-Ziel (Rendering Target) zur Verfügung gestellt werden.
Das Rendering-Konzept von M3G
● Vier Schritte, um eine 3D-Szene mit M3G zu rendern:1) Eine Instanz von Graphics3D holen
2) Ein Rendering Target an den Grafikkontext (die Instanz von Graphics3D) binden
3) Die 3D-Szene auf dem Rendering Target zeichnen
4) Das Rendering Target wieder freigeben
Das Rendering-Konzept von M3G
Rendern einer 3D-Szene mit M3G, Quelle: [SPE05]
Das Rendering-Konzept von M3G
void bindTarget(java.lang.Object target, boolean dephtBuffer, int hints)
– Mit target wird das Renderziel übergeben– Mit depthBuffer kann der Tiefnpuffer ein- oder
ausgeschaltet werden– Mit dem dritten Argument hints können noch
weitere Hinweise übergeben werden
Das Rendering-Konzept von M3G
● Retained Mode Rendering:void render(World world)
● Immediate Mode Renderingvoid render(Node node, Transform transform)
void render(VertexBuffer vertices, IndexBuffer triangles, Appearance appearance, Transform transform)
M3G 2.0
● Wird in JSR 297 definiert● Immer noch nicht endgültig verabschiedet● Einige Schlüsselneuerungen sind:
– Höhere Render-Qualität– Reduzierter Speicherbedarf– Schnelleres Rendering– Reduzierte Zergliederung der API– Vereinfachte Handhabung und größere Flexibilität
M3G 2.0
● Ist eine voll kompatible Erweiterung von M3G 1.1
● wird in einen allgemein gültigen „Core“-Block und einen optionalen „Advanced“- Block unterteilt
M3G 2.0 Advanced
M3G 2.0 Core
M3G1.1Feature Set
Was ist neu im Core-Block?
● Collision Detection => world.collide(...) dient dazu Kollisionen zu ermitteln
● Optimierte Animation und Deformation● Neue grafische Primitive
– Point Sprites– Triangle Lists– Lines
● Automatisches Level of Detail (LOD)
Was ist neu im Core-Block?
● „Depth Sorting“ bei transparenten Objekten● Dynamische (Video) Texturen● Einige optionale Features sind nun Standard
– Mipmapping– Perspective Correction– Multitexturing (mind. 2)– Texturformate bis 1024 x 1024
Was ist neu im Advanced-Block?
● Programmierbare Shader● Stencil Buffering● Cube mapping● Advanced blending
● Bei Verwendung des Advanced Block sollte folgendes Attribut in die JAD-Datei eingetragen werden: M3G-Version: 2.0-Advanced
Quellen & Literatur
● [PUL08] : Kari Pulli, Tomi Aarnio, Ville Miettinen, Kimmo Roimela, Jani Vaarala, Mobile 3D Graphics, 2008, Morgan Kaufmann
● [HÖF07] : Claus Höfele , Mobile 3D Graphics, Learning 3D Graphics with the Java Micro Edition, 2007, Thomson Course Technology PTR
Quellen und Literatur
● [SCH04] : Klaus-Dieter Schmatz, Java 2 Micro Edition, 2004, dpunkt.verlag GmbH
● [SPE05] : JSR-184 Expert Group, Java Community Process (JCP), Mobile 3D Graphics API - Technical Specification, http://www.jcp.org/en/jsr/detail?id=184
● [WER08]: Jeronimo Werder,Realisierung von 3D Grafiken für mobile Endgeräte unter Betrachtung geeigneter Grafikbibliotheken und Fenstersystemen
Fragen & Anregungen
??
Zum Schluss noch...
Vielen Dank für IhreVielen Dank für IhreAufmerksamkeit !!!Aufmerksamkeit !!!