Mobile 3D Graphics API M3Gwerder-technologies.info/downloads/M3G-Vortrag.pdf · Andere frühe...

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


● Die Konfiguration definiert die kleinstmögliche Funktionalität einer bestimmten Geräteklasse– stellt die Virtual Machine (VM)– definiert die unterstützten Sprachmittel


● Das Profil erweitert die Konfiguration um spezielle Leistungsmerkmale bzw. Klassenbibliotheken.

● Anders als bei der Konfiguration darf das Profil optionale Teile enthalten


● 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


● Ein Beispiel für einen Szenengraphen


● 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


● Einfache Körper umschreiben komplexere ● Bounding Volumes können seinerseits unter-

geordnete Bounding Volumes umschreiben

Beispiel für eine Bounding Volume Hierarchie, Quelle: [PUL08]


● Ablauf des Retained Mode Rendering aus Sicht einer typischen M3G-Implementierung:

Grafik nach [PUL08]


● 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.


● 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


Rendern einer 3D-Szene mit M3G, Quelle: [SPE05]


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


● 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 !!!

Mobile 3D Graphics API M3Gwerder-technologies.info/downloads/M3G-Vortrag.pdf · Andere frühe...

Documents

Transcript of Mobile 3D Graphics API M3Gwerder-technologies.info/downloads/M3G-Vortrag.pdf · Andere frühe...