Vortrag - Materialien zum M3G-Vortrag an der Hochschule Fulda

JSR – 184
Mobile 3D Graphics API
M3G
Vortrag 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
Featurephones
offene Plattform
Smartphones
offene native Plattform
nur der Hersteller kann Anwendungen schreiben und auf
dem Gerät installieren
–
Möglichkeit eigene Anwendungen zu programmieren und zu
installieren, Zertifizierung durch Anwender oder Hersteller
wird benötigt
–
Mö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 GameEngines wie Swerve, Mascot Capsule oder XForge 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ßkommaberechnungen 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 DesktopApplikationen
–
Java 2 Micro Edition (J2ME) für kleine ressourcenbeschränkte Geräte
Die drei Java Editionen
Quelle: [WER08]
●
J2ME hat im Gegensatz zu J2EE nur eine sehr
kleine Schnittmenge mit J2SE
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
in Anlehnung an: [SCH04]
●
●
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.
M3G im Java Software-Stack
Quelle: [PUL08]
●
Die Position von M3G innerhalb des Java
Software-Stacks
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
●
●
Lebenszyklus eines MIDlets, Quelle: [PUL08]
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
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 Mode
Low 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
●
–
hierarchische Transformationen
●
–
zu weit entfernte Objekte, verdeckte Objekte werden vom
Rendering ausgeschlossen
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
Beispiel für eine Bounding Volume Hierarchie,
●
●
Quelle: [PUL08]
Einfache Körper umschreiben komplexere
Bounding Volumes können seinerseits untergeordnete Bounding Volumes umschreiben
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 Vergleich 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 RenderZiel (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 Rendering
void 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.1
Feature 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 Ihre
Aufmerksamkeit !!!