3D Application for Mobile Phones

VYSOKÉ U

Č

ENÍ TECHNICKÉ V BRN

Ě

FAKULTA INFORMA

Č

NÍCH TECHNOLOGIÍ

ÚSTAV PO

Č

ÍTA

Č

OVÉ GRAFIKY A MULTIMÉDIÍ

FACULTY OF INFORMATION TECHNOLOGY

DEPARTMENT OF COMPUTER GRAPHICS AND MULTIMEDIA

3D APLIKACE PRO MOBILNÍ TELEFONY

BAKALÁ

Ř

SKÁ PRÁCE

BACHELOR‘S THESIS

AUTOR PRÁCE

MAREK VYORAL

AUTHOR

VYSOKÉ U

Č

ENÍ TECHNICKÉ V BRN

Ě

FAKULTA INFORMA

Č

NÍCH TECHNOLOGIÍ

ÚSTAV PO

Č

ÍTA

Č

OVÉ GRAFIKY A MULTIMÉDIÍ

FACULTY OF INFORMATION TECHNOLOGY

DEPARTMENT OF COMPUTER GRAPHICS ANF MULTIMEDIA

3D APLIKACE PRO MOBILNÍ TELEFONY

3D APPLICATION FOR MOBILE PHONES

BAKALÁ

Ř

SKÁ PRÁCE

BACHELOR‘S THESIS

AUTOR PRÁCE

MAREK VYORAL

AUTHOR

VEDOUCÍ PRÁCE

Ing. ALEŠ LÁNÍK

SUPERVISOR

Abstrakt

Tato práce se zabývá 3D grafickými rozhraními M3G a MascotCapsule navrženými pro platformu J2ME (Java 2 Micro Edition). Nejprve poskytuje základní informace o samotné platformě _{a poté}

o obou rozhraních. Dále tato rozhraní porovnává z pohledu implementace, následuje porovnání jejich výkonnosti na základě _{testování na reálných mobilních za}ř_{ízeních. Práce pak dále popisuje}

implementací demonstrač_{ní aplikace, která využívá rozhraní M3G.}

Abstract

This thesis considers with 3D graphics interfaces M3G and MascotCapsule, both designed for platform J2ME (Java 2 Micro Edition). First of all it provides basic information about platform and then about both interfaces. Afterwards, interfaces are compared from implementation point of view. It is followed by comparision of performance based on testing on real mobile devices. Then this thesis describes implementation of demonstration application, which uses M3G interface.

Klí

č

ová slova

J2ME, mobilní aplikace, mobilní telefon, M3G, Mobile 3D Graphics API, JSR 184, MascotCapsule

Keywords

J2ME, mobile application, mobile phone, M3G, Mobile 3D Graphics API , JSR 184, MascotCapsule

3D aplikace pro mobilní telefony

Prohlášení

Prohlašuji, že jsem tuto bakalář_{skou práci vypracoval samostatn}ě _{pod vedením Ing. Aleše Láníka.}

Uvedl jsem všechny literární prameny a publikace, ze kterých jsem č_erpal.

……… Marek Vyoral 18.5.2009

Pod

ě

kování

Tímto bych chtě_{l pod}ě_{kovat vedoucímu mé bakalá}ř_{ské práce Ing. Aleši Láníkovi za spolupráci, cenné}

rady a užiteč_{né návrhy.}

© Marek Vyoral, 2009

Tato práce vznikla jako školní dílo na Vysokém uč_{ení technickém v Brn}ě_{, Fakult}ě _informač_ních

technologií. Práce je chráně_{na autorským zákonem a její užití bez ud}ě_{lení oprávn}ě_{ní autorem je}

Obsah

Obsah ... 1

1 Úvod ... 2

2 J2ME ... 3

2.1 Programovací jazyk Java ... 3

2.2 Java platformy ... 3

2.3 Java 2 Micro Edition ... 3

2.4 Java Specification Request ... 4

3 M3G API (JSR 184) ... 6

3.1 Vytvář_{ení model}ů _{... 6}

3.2 Tř_{ídy balí}č_{ku javax.microedition.m3g ... 6}

4 MascotCapsule ... 8

4.1 Vytvář_{ení model}ů _{... 8}

4.2 Tř_{ídy balí}č_{ku com.mascotcapsule.micro3d.v3 ... 8}

5 Srovnání obou API ... 9

5.1 Nač_{ítání model}ů _{do aplikace ... 9}

5.2 Objekty ve scéně _{a manipulace s nimi ... 10}

5.3 Textury ... 11

5.4 Graf scény ... 11

5.5 Osvě_{tlení scény ... 12}

5.6 Vzhled objektů _{... 13}

5.7 Vykreslení scény (rendering) ... 14

6 Srovnávací aplikace ... 15

6.1 Popis jednotlivých testů _{... 15}

6.2 Výsledky ... 18

6.3 Zhodnocení výsledků _{... 21}

7 Demonstrač_{ní aplikace ... 22}

7.1 Návrh a volba rozhraní ... 22

7.2 Implementace ... 22

7.3 Návrhy na další vylepšení aplikace ... 28

8 Závě_{r ... 29}

Literatura ... 30

1

Úvod

Není tomu tak dávno, kdy mobilní telefony sloužily výhradně _{k uskute}čň_{ování telefonních hovor}ů_.

Vzhledem k vysoké poř_{izovací cen}ě _{a menší dostupnosti byla tato za}ř_{ízení používána p}ř_{edevším jako}

nástroj ke zrychlení a zefektivně_{ní komunikace v pracovním prost}ř_{edí. P}ř_{ibývání další funkcionality}

bylo tomuto podř_{ízeno, takže vývoj se zabýval p}ř_{edevším technologiemi využitelnými pro pracovní}

nasazení. Př_{íkladem mohou být textové zprávy, datové p}ř_{enosy nebo p}ř_{ístup k e-mailu.}

Postupem č_{asu se ovšem mobilní telefony stávaly levn}ě_{jšími a tím pádem dostupn}ě_jšími

pro širší vrstvy populace. Zde už se situace výrazně _mě_{ní. Mobilní telefon už není jen nástrojem}

pro práci, ale stává se i jakousi hrač_{kou, poskytující svému uživateli zábavu, kdykoliv pot}ř_ebuje

ukrátit nudnou chvilku. Výrobci mobilních telefonů _{si toto uv}ě_{domili a postupn}ě _zač_{ali p}ř_idávat

i funkce urč_{ené výhradn}ě _{pro zábavu.}

Nejtypič_tě_{jším p}ř_{íkladem jsou mobilní hry. Ty se za}č_{aly postupn}ě _{objevovat už na modelech,}

které mě_{ly pouze jednoduchý} č_{ernobílý displej a z dnešního pohledu velmi slabý výpo}č_{etní výkon.}

Takovéto hry byly samozř_ejmě _{velmi jednoduché a po grafické stránce velmi omezené, ovšem od té}

doby si mobilní telefon bez her už jen málokdo dokáže př_{edstavit. První hry byly také pevn}ě

implementovány v zař_{ízení a nebylo možné jakkoliv instalovat a p}ř_{idávat hry nové. Pr}ů_kopníkem

v této oblasti byla společ_{nost Nokia, která jako první p}ř_{išla s možností p}ř_{idávání her do svých model}ů

telefonů_.

Absolutní revolucí v oblasti mobilních her a aplikací bylo vyvinutí platformy J2ME a zavedení její podpory na mobilních telefonech. To umožnilo do telefonů _{nejen p}ř_{idávat nové aplikace a hry, ale}

také je jednoduše a efektivně _{vyvíjet, což zvládne prakticky každý programátor, který je schopen}

programovat v jazyce Java.

Postupem č_{asu se mobilní telefony stále zdokonalovaly, rostl jejich výpo}č_{etní výkon, velikost}

pamě_{tí a zlepšovaly se další hardwarové parametry. Vývojem prošly také displeje,} č_{ernobílé s malým}

rozlišením byly postupně _{nahrazovány barevnými s} č_{ím dál tím v}ě_{tším rozlišením a barevnou}

hloubkou. Tento fakt se samozř_ejmě _{odrazil také v oblasti mobilních her. Podobn}ě _{jak tomu bylo}

u osobních poč_ítačů_{, postupn}ě _{rostla jejich složitost, velikost a p}ř_{edevším úrove}ň _grafického

zpracování. Není tedy př_{ekvapivé, že evoluce mobilních her velmi podobn}ě _{kopírovala vývoj her}

poč_ítač_{ových. Ze za}č_{átku to byly p}ř_{edevším graficky a výpo}č_etně _nenároč_{né logické hry.}

Se zdokonalováním mobilního hardwaru př_{icházely stále propracovan}ě_{jší typy her, ovšem po}ř_{ád byly}

omezeny dvourozmě_{rnou grafikou. A tak bylo pouze otázkou} č_{asu, kdy se na mobilních telefonech}

objeví první 3D hry.

A právě _{touto oblasti, 3D grafikou na mobilních za}ř_{ízeních, se budu v této bakalá}ř_{ské práci}

zabývat. Konkrétně _dvě_{ma 3D rozhraními, která byla vyvinuta pro J2ME za ú}č_{elem jednoduššího}

programování vykreslování tř_írozmě_{rné grafiky v reálném} č_{ase. Tím prvním je Mobile 3D Graphics} API for J2ME a tím druhým MascotCapsule. Nejprve tato práce podává základní informace

o samotné platformě _{J2ME a o obou rozhraních. Dále pak rozhraní srovnává z pohledu programování}

a př_{ístupu k n}ě_{kterým oblastem. Následuje srovnání z pohledu výkonnosti založené na praktickém}

testování na rů_{zných mobilních za}ř_{ízeních. Nakonec tato práce popisuje demonstra}č_{ní aplikaci, která}

2

J2ME

Kapitola poskytuje základní informace týkající se Java 2 Micro Edition (dále J2ME) [1] a zasazuje následně _{probíraná témata do širšího kontextu.}

2.1

Programovací jazyk Java

Programovací jazyk Java [2] vyvinula společ_{nost Sun Microsystems. Byl p}ř_{edstaven 23. kv}ě_{tna roku}

1995 a brzy se zař_{adil mezi nejpoužívan}ě_{jší programovací jazyky na sv}ě_tě_{. Jeho syntaxe vychází}

z programovacího jazyka C++ a odstraň_{uje n}ě_{které problémové konstrukce. Jedná se o jazyk}

objektově _{orientovaný, tedy krom}ě _ně_{kolika primitivních datových typ}ů _{jsou všechny ostatní prvky}

objekty.

Na rozdíl od staticky kompilovaného C++ je Java jazykem interpretovaným. To s sebou př_ináší

jednu z nejvě_{tších výhod jazyka Java, a tou je snadná p}ř_{enositelnost program}ů _{na r}ů_{zná za}ř_ízení

a architektury. Nutnou podmínkou je ovšem existence interpretu (tzv. JVM – Java Virtual Machine) na daném zař_{ízení. Java ovšem není} č_istě _{interpretovaným jazykem, zdrojový kód musí být nejd}ř_íve

zkompilován do mezikódu, tzv. bytecode. Tento kód je poté možné distribuovat a pomocí interpretu JVM spouště_{t na konkrétních za}ř_{ízeních. Skute}č_{nost, že se jedná o jazyk interpretovaný s sebou}

př_{ináší také jisté nevýhody. Jednou z nich m}ů_{že být nap}ř_{íklad nižší rychlost a delší doba nutná}

ke spuště_{ní aplikace. Je zde ale snaha tyto problémy eliminovat zavád}ě_{ním technologií jako nap}ř_íklad just-in-time kompilace (ně_které č_{ásti kódu jsou p}ř_{ekládány p}ř_{ímo do nativního strojového kódu).}

Další možná nevýhoda interpretovaného jazyka se projeví v podobě _{velké pam}ěť_{ové náro}č_nosti

u malých aplikaci. Ty totiž potř_{ebují mít v pam}ě_{ti na}č_{teno také celé b}ě_{hové prost}ř_edí.

2.2

Java platformy

Pro vývoj a bě_{h program}ů _{v jazyce Java vznikly} č_tyř_{i základní platformy [3]:}

• JavaCard – použití na jednoduchých zař_{ízeních jako platební a} č_{ipové karty nebo SIM karty}

mobilních operátorů_{. Jedná se o nejjednodušší edici poskytující p}ř_{edevším funkcionalitu}

danou cílovým zaměř_{ením, jako šifrování a zabezpe}č_ení.

• Java ME – Micro Edition – použití na mobilních zař_{ízeních jako PDA a mobilní telefony. Je}

známa také pod zkratkou J2ME a právě _{jí se zabývá tato bakalá}ř_{ská práce.}

• Java SE – Standard Edition – urč_{ena pro standardní stolní po}č_ítač_e.

• Java EE – Enterprise Edition – aplikace pro rozsáhlé informač_{ní a distribuované systémy.}

Aplikace napsané v jazyce Java jsou př_{enositelné v rámci stejné platformy. P}ř_{enositelnost mezi}

rů_{znými platformami je už ovšem komplikovaná, protože cílová platforma nemusí poskytovat}

všechnu potř_{ebnou funkcionalitu.}

2.3

Java 2 Micro Edition

Verze J2ME [4] je jakousi odlehč_{enou a modifikovanou edicí odvozenou od Java Standard Edition}

a upravenou pro potř_{eby mobilních za}ř_{ízení. Mezi jednotlivými za}ř_{ízeními jsou však zna}č_{né rozdíly,}

proto vznikly ještě _{tzv. konfigurace. Ty specifikují minimální požadavky na za}ř_{ízení, jako typ}

Existují dvě _{základní konfigurace [1] [5]:}

Connected Limited Device Configuration (CLDC) – Typickým zástupcem této kategorie jsou mobilní telefony a rů_{zné organizéry. Tato konfigurace stanovuje jako minimální}

hardwarové požadavky 160 kB (pro CLDC 1.1 192 kB) stálé pamě_{ti a 32 kB volné pam}ě_ti

typu RAM pro bě_{h virtuálního stroje JVM. Konfigurace CLDC podporuje podmnožinu}

modifikovaných funkcí z ně_{kterých knihoven Java Standard Edition, konkrétn}ě _java.lang, java.io a java.util. Př_{ináší také zcela novou knihovnu pro vstup a výstup uzp}ů_sobenou

mobilním zař_{ízením javax.microedition.io.}

Connected Device Configuration (CDC) – Tato konfigurace odpovídá zař_{ízením, která jsou}

ně_{kde mezi jednoduchými za}ř_{ízeními typu CLDC a stolními po}č_ítač_{i. Typickými zástupci}

jsou chytré telefony, výkonně_{jší PDA a r}ů_{zné kapesní po}č_ítač_{e. Hardwarovými požadavky}

jsou 32 bitový procesor, 2 MB pamě_{ti RAM a 2,5 MB stálé pam}ě_{ti. Tato konfigurace se již}

na rozdíl od CLDC více př_{ibližuje Java Standard Edition.}

Každá z konfigurací je dále doplně_{na tzv. profilem. Ten p}ř_{ináší další t}ř_{ídy a funkce, které odpovídají}

specifickému použití a potř_{ebám daných za}ř_{ízení. Pro ob}ě _{konfigurace existuje n}ě_{kolik profil}ů_.

Z pohledu této bakalář_{ské práce je d}ů_{ležitý Mobile Information Device profil (MIDP) [6]. Práv}ě _ten

rozšiř_{uje konfiguraci CLDC a je ur}č_{en primárn}ě _{pro mobilní telefony. K hardwarovým požadavk}ů_m

na zař_{ízení p}ř_{idává displej o velikosti minimáln}ě _{96 krát 54 pixel}ů _{a možnost ovládat za}ř_ízení

klávesami, př_ípadně _{pomocí dotykové obrazovky. MIDP 1.0 dopl}ň_{uje konfiguraci CLDC o tyto}

knihovny:

• javax.microedition.io – vstup/výstupní funkce upravené pro potř_{eby mobilních telefon}ů • javax.microedition.lcdiu – funkce pro práci s uživatelským rozhraním

• javax.microedition.rms – poskytuje perzistentní úložiště _dat

• javax.microedition.midlet – základní tř_{ídy pro b}ě_{h mobilních aplikací}

Č_{asem vznikla na nových výkonn}ě_{jších modelech mobilních telefon}ů _potř_{eba práce}

např_{. s multimédii, proto verze profilu MIDP 2.0 p}ř_{ináší navíc další knihovny:} • javax.microedition.media – obsahuje tř_{ídy pro práci s multimédii}

• javax.microedition.lcdui.game – knihovna pro jednoduché vytvář_{ení 2D her} • javax.microedition.pki – poskytuje zabezpeč_{ené p}ř_ipojení

2.4

Java Specification Request

Jak jednotlivé konfigurace, tak profily vznikly na základě _{procesu Java Community Process (JCP)}

[5]. Na tomto procesu se podílejí odborníci ze společ_{ností, které p}ů_{sobí v oblasti po}č_ítačů_{, elektroniky}

a softwaru. Cílem je dojít ke společ_{né dohod}ě _{a návrhu tak, aby vznikaly specifikace, podle kterých}

budou výrobci navrhovat své produkty. Právě _{díky tomu je zajišt}ě_{na podpora J2ME na široké škále}

zař_{ízení od r}ů_{zných výrobc}ů_.

Dů_{ležitým prvkem procesu vývoje je tzv. Java Specification Request (JSR) [7], který popisuje}

jakési zadání, co je potř_{eba vyvinout a ud}ě_{lat. Na základ}ě _{požadavku JSR je sestavena skupina}

specifikace mohou navrhovat svá zař_{ízení. Takovýchto JSR jsou pro celou platformu Java stovky,}

pro edici J2ME desítky.

Nové požadavky na specifikace se objevují neustále, proto jsou jednotlivá JSR v rů_zných

stádiích vývoje, od zadání, př_{es rozpracované, až po finální kompletn}ě _{hotové verze. Každý}

požadavek Java Specification Request je označ_en č_íslem.

A právě _{jedním z t}ě_{chto požadavk}ů _{je také JSR 184 s názvem Mobile 3D Graphics API for}

J2ME (dále M3G) [8]. Tato specifikace vznikla na základě _potř_{eby rozhraní pro práci s 3D grafikou}

na mobilních zař_{ízeních. Nicmén}ě _{nezávisle na Java Community Process vzniklo samostatn}ě _také

konkurenč_{ní rozhraní se stejným zam}ěř_{ením nazvané MascotCapsule [9], podporované p}ř_edevším

společ_{ností Sony Ericsson.}

2.4.1

P

ř

ehled vybraných JSR

Následující př_{ehled zmi}ň_{uje n}ě_{která JSR [7], která se týkají aplikací na mobilních telefonech. Jsou}

zde uvedena př_{edevším ta, jenž zasahují do oblasti grafiky a mobilních her.}

JSR 30 - Connected Limited Device Configuration

Specifikace CLDC konfigurace, pod kterou spadají mobilní telefony.

JSR 37 - Mobile Information Device Profile

Specifikace MIDP profilu, který rozšiř_{uje práv}ě _{CLDC konfiguraci.}

JSR 118 - Mobile Information Device Profile 2.0

Druhá upravená verze specifikace profilu MIDP.

JSR 135 - Mobile Media API

Rozhraní pro práci s multimédii, videem a audiem na mobilních zař_ízeních.

JSR 139 - Connected Limited Device Configuration 1.1 Nově_{jší verze konfigurace CLDC.}

JSR 178 - Mobile Game API

Rozhraní pro snadně_{jší a rychlejší vývoj her.}

JSR 184 - Mobile 3D Graphics API

Rozhraní pro vykreslování 3D grafiky v reálném č_ase.

JSR 226 - Scalable 2D Vector Graphics API

Specifikace API pro práci a vykreslování 2D vektorové grafiky a podporu grafického formátu W3C Scalable Vector Graphics (SVG).

JSR 271 - Mobile Information Device Profile 3

Nejnově_{jší verze profilu MIDP p}ř_{inášející novou funkcionalitu.}

JSR 297 - Mobile 3D Graphics API 2.0

3

M3G API (JSR 184)

Specifikace Mobile 3D Graphics API [8] byla vyvinuta na základě _{žádosti JSR 184 (Java}

Specification Request) jako souč_{ást Java Cummunity Process. Toto rozhraní je ur}č_{eno p}ř_edevším

pro zař_{ízení konfigurace CLDC s profily MIDP 1.0 nebo MIDP 2.0, což jsou typicky za}ř_ízení

s nízkým výpoč_{etním výkonem, malou velikostí pam}ě_{ti a bez hardwarové podpory vykreslovaní 3D}

grafiky. Nicméně _{specifikace nebrání implementaci tohoto rozhraní i na složit}ě_{jších za}ř_ízeních

konfigurace CDC nebo jakékoliv jiné Java platformě_.

Vývojem se zabývala skupina odborníků_{, tzv. Mobile 3D Graphics API Expert Group, složená}

ze zástupců _{mnoha firem p}ů_{sobících v oblasti mobilních za}ř_{ízení a vestav}ě_{ných systém}ů

(např_{. Nokia, Sony Ericsson, Siemens, Motorola, Sun Microsystems, Intel, Texas Instruments).}

Zapojení takto širokého spektra výrobců _př_{ineslo rozší}ř_{ení tohoto rozhraní prakticky na v}ě_tšinu

mobilních telefonů _{s podporou J2ME na sou}č_{asném trhu.}

3.1

Vytvá

ř

ení model

ů

Kromě _vytvář_{ení model}ů _př_{ímo pomocí p}ř_íkazů _{programovacího jazyka, což m}ů_{že být velmi složité,}

nepř_{ehledné a} č_asově _nároč_ně_{, umož}ň_{uje M3G API použít jednodušší postup. Modely lze vytvo}ř_it

pomocí externích 3D editorů_{, exportovat je do souboru formátu .m3g a poté na}č_{íst v mobilní aplikaci}

pomocí tř_{ídy Loader. Toto p}ř_{ináší p}ř_{edevším zrychlení a zjednodušení vývoje. Nicmén}ě _možnost

vytvář_{et modely pomocí programového kódu z}ů_{stává zachována, nebo}ť _{v n}ě_{kterých aplikacích m}ů_že

být nezbytná.

Plug-in moduly umožň_{ující export model}ů _{do .m3g soubor}ů _{existují pro všechny b}ě_žně

rozšíř_{ené 3D editory (nap}ř_{. 3ds Max, Blender, Maya, Cinema 4D). Náležitosti formátu, datové typy}

a struktura souboru jsou dů_kladně _{popsány ve specifikaci API.}

3.2

T

ř

ídy balí

č

ku javax.microedition.m3g

M3G API je obsaženo v balíč_{ku javax.microedition.m3g [8]. V této podkapitole je uveden seznam}

všech tř_{íd, které tento balí}č_{ek obsahuje. U každé t}ř_{ídy je pak uveden stru}č_{ný popis. Jde pouze}

o př_{ehled základních údaj}ů_{, detaily n}ě_{kterých vybraných t}ř_{íd jsou pak rozebírány v dalších}

kapitolách.

AnimationController uchovává informace o rychlosti a pozici animač_{ní sekvence.}

AnimationTrack spojuje KeyframeSequence a AnimationController a umožň_{uje tak animaci.}

Appearance seskupuje objekty tř_{íd, které ur}č_{ují vzhled modelu a další vlastnosti ovliv}ň_{ující jeho}

vykreslení, např_{íklad Material a Texture2D.}

Background odpovídá pozadí scény. Umožň_{uje nastavit barvu nebo obrázek pozadí záb}ě_ru.

Camera reprezentuje bod, ze kterého je scéna pozorována. Umožň_{uje nastavit jak paralelní, tak}

perspektivní projekci.

CompositingMode je komponentou tř_{ídy Appearance zapouzd}ř_{ující vlastnosti týkající}

se vykreslování pixelů_.

Fog je taktéž komponentou tř_{ídy Appearance, definuje osv}ě_{tlení v závislosti na vzdálenosti objektu.}

v aplikaci probíhá pomocí metody render právě _{této t}ř_ídy.

Group je uzlem v grafu scény, umožň_{uje seskupovat více objekt}ů _{do skupiny.}

Image2D uchovává dvourozmě_{rný obrázek, který m}ů_{že být použit jako textura, pozadí scény nebo}

sprite.

IndexBuffer je komponenta tř_{ídy Mesh definující submesh.}

KeyframeSequence reprezentuje posloupnost klíč_{ových snímk}ů _animace.

Light je zdrojem svě_{tla ve scén}ě_{. Lze mu nastavit vlastnosti jako barva, intenzita nebo typ osv}ě_tlení.

Loader poskytuje metody k importu a deserializaci modelů _{a grafu scény z externích .m3g soubor}ů_.

Také poskytuje metodu pro nač_{tení textury ze souboru .png.}

Material je jedna z komponent tř_{ídy Appearance definující vzhled objektu.}

Mesh reprezentuje 3D objekt ve scéně _{jako povrch složený z polygon}ů _{a p}ř_iř_{azuje mu vzhled typu}

Appearance.

MorphingMesh se liší od bě_{žného t}ě_{lesa Mesh tím, že m}ů_{že obsahovat více objekt}ů _{VertexBuffer.}

Každý z nich mů_{že mít dále zadánu svou váhu. Výsledný tvar t}ě_{lesa je poté dán kombinací}

všech VertexBufferů _{podle jejich váhy.}

Node je abstraktní tř_{ída, která reprezentuje uzel v grafu scény. Z této t}ř_{ídy d}ě_{dí t}ř_ídy

Camera, Mesh, Sprite3D, Light a Group. Díky tomu mohou být uzly v grafu scény.

Od tř_{ídy Object3D je odvozeno tém}ěř _{všechno, co se ve 3D scén}ě _{vyskytuje. Výjimkou jsou pouze}

tř_{ídy Loader, Transform, RayIntersection a Graphics3D.}

PolygonMode je komponentou tř_{ídy Appearance, uchovává informace týkající se vykreslování}

polygonů _{(viz. kapitola 5.6 Vzhled objekt}ů_).

RayIntersection je tř_{ída, kterou využívá API výhradn}ě _př_{i vykreslování pro uložení pr}ů_seč_íků_.

SkinnedMesh je vhodnou tř_{ídou pro objekty animované pomocí kostry (skeletally animated).}

Sprite3D odpovídá dvourozmě_{rnému obrázku, který má t}ř_írozmě_{rnou pozici ve scén}ě_.

Texture2D je jednou z komponent Appearance, uchovává texturu typu Image2D a další informace specifikující umístě_{ní textury na povrch t}ě_{lesa, sou}ř_{adnice a typ filtrování.}

Transform odpovídá transformač_{ní matici. Má rozm}ě_{ry 4} ř_{ádky a 4 sloupce} č_{ísel typu float.}

Poskytuje metody pro rotace, inverzi, násobení matic a podobně_.

Transformable je nadř_{azenou t}ř_{ídou pro objekty typu Node a Texture2D. Poskytuje metody}

pro transformaci 3D objektů _{a textur, jako nap}ř_{íklad rotace, posunutí nebo zm}ě_{nu m}ěř_ítka

VertexArray je pole urč_{ené pro uchování sou}ř_{adnic vrchol}ů_{, jejich barev a normál.}

VertexBuffer je složen z ně_{kolika VertexArray. Reprezentuje vrcholy, které dohromady tvo}ř_{í povrch}

3D objektu.

4

MascotCapsule

Toto rozhraní, podobně _{jako M3G bylo vyvinuto jako knihovna pro vykreslování 3D grafiky}

v reálném č_{ase pro vestav}ě_{ná za}ř_{ízení, mobilní telefony a PDA podporující J2ME. Vývojem tohoto}

API se zabývá japonská firma HI Corporation. MascotCapsule vyžaduje jako minimální prostř_edí

pro korektní bě_{h za}ř_{ízení s procesorem srovnatelným s ARM9 100Mhz, zabírá 100 kB pam}ě_ti

a vyžaduje alespoň _{800 kB volného místa na hald}ě _[9].

Rozhraní prochází postupným vývojem, proto je potř_{eba uvést, že tato bakalá}ř_{ská práce}

pojednává o tř_{etí verzi, tj. MascotCpasule V3. V sou}č_{asné dob}ě _{již existuje verze V4, která p}ř_ináší

novou funkcionalitu a plně _{odpovídá specifikaci M3G 1.1. Z tohoto d}ů_{vodu zde již zásadní odlišnosti}

MascotCapsule oproti M3G prakticky zanikají. V souč_{asné dob}ě _{je stále ale ješt}ě _{používána p}ř_evážně

verze 3, proto se tedy tato práce zabývá MascotCapsule V3.

4.1

Vytvá

ř

ení model

ů

Modely pro MascotCapsule lze stejně _{jako v MG3 API vytvá}ř_{et jak v kódu, tak pomocí b}ě_žných

komerč_ních č_{i voln}ě _šiř_{itelných 3D editor}ů_{. Podporovány jsou nap}ř_{íklad nástroje 3ds Max,}

LightWave3D, Maya, Softimage 3D a Blender.

Po vytvoř_{ení modelu následuje export do soubor}ů _{formátu .bac a .tra [10]. Prvn}ě _zmíně_ný

soubor obsahuje samotný model, druhý soubor obsahuje animač_{ní data. Tyto soubory je následn}ě

potř_{eba zkonvertovat do formátu .mbac, respektive .mtra. K tomu slouží nástroj M3DConverter, který}

je k dispozici zdarma na stránkách společ_{nosti HI Corporation.}

Dalšími užiteč_{nými nástroji, které jsou voln}ě _{k dispozici, jsou jednoduchý editor .bac/.tra}

souborů _{PAC a prohlíže}č _{.mbac/.mtra soubor}ů _{PVMicro. Ten je možné použít pro prvotní náhled, jak}

př_ibližně _{bude výsledný model vypadat na mobilním za}ř_{ízení. Stejn}ě _{jako v M3G API je pak modely}

uložené ve vyexportovaných souborech možné nač_{íst do aplikace.}

4.2

T

ř

ídy balí

č

ku com.mascotcapsule.micro3d.v3

od M3G je MacotCapsule na poč_{et t}ř_{íd zna}č_ně _{chudší, je jich pouze p}ř_ibližně _tř_etina.

ActionTable uchovává data o pohybu objektů _{a umož}ň_{uje tak jejich animaci.}

AffineTrans je transformač_{ní matice o rozm}ě_{ru 3} ř_{ádky a 4 sloupce. Slouží k manipulaci s objektem,}

např_{íklad k rotaci.}

Effect3D obsahuje informace pro vykreslení objektu, typ stínování, osvětlení, průhlednost atd.

Figure reprezentuje 3D objekt ve scéně _{a umož}ň_{uje na}č_{íst model z externího souboru.}

FigureLayout obsahuje další data nutná pro vykreslení objektu, př_{edevším pozici, orientaci}

a velikost.

Graphics3D je stě_{žejní t}ř_{ídou celého API, zajiš}ť_{uje totiž vykreslování a poskytuje k tomu pot}ř_ebné

metody.

Light reprezentuje osvě_{tlení scény a uchovává nastavení jeho parametr}ů_.

Texture uchovává texturu a umožň_{uje její na}č_{tení z externího souboru.}

Util3D poskytuje matematické operace odmocnina, sinus a cosinus.

5

Srovnání obou API

Tato kapitola srovnává obě _{rozhraní z implementa}č_{ního pohledu. Zabývá se n}ě_{kolika oblastmi,}

ve kterých se obě _{API od sebe zna}č_ně _{liší. Tato kapitola} č_{erpá ze zdroj}ů _{[8], [9], [10] a [11].}

5.1

Na

č

ítání model

ů

do aplikace

Jak bylo v př_{edchozích kapitolách uvedeno, modely lze vytvá}ř_{et v r}ů_{zných 3D editorech a poté je}

exportovat do souborů _{odpovídajících formát}ů_{. Nyní se podíváme, jakým zp}ů_{sobem lze s modely}

v tě_{chto souborech uložených, pracovat p}ř_{ímo v aplikaci.}

K nač_{tení modelu do aplikace v M3G API slouží speciální t}ř_{ída Loader. Ta umí deserializovat}

data z .m3g souboru a nalézt v nich instance tř_{íd odvozených od Object3D, tj. World, Group, Camera,}

Light a dále také Material, Appearance a Texture2D. Z této tř_{ídy nelze vytvá}ř_{et instance a obsahuje}

pouze dvě _{statické metody load (rozlišeny pomocí parametr}ů_{). Ty vrací pole nalezených objekt}ů

typu Object3D. Toto pole však neobsahuje všechny objekty grafu scény, obsahuje pouze objekty (uzly), na které není reference ze žádných jiných uzlů_{. Tyto vrcholové uzly lze dále prohledávat}

metodou load pro nalezení dalších objektů_{, a takto rekurzivn}ě _pokrač_{ovat. P}ř_{íklad na}č_{tení scény:}

World world = null;

Object3D[] buffer = Loader.load("/myScene.m3g"); for(int i = 0; i < buffer.length; i++) {

if(buffer[i] instanceof World) { world = (World)buffer[i];

break; }

}

Statická metoda load tř_{ídy Loader vrátí do pole} buffer nalezené instance typu Object3D, které nalezne v souboru myScene.m3g. Následuje cyklus, který toto pole prohledá a získá referenci na objekt typu World. Ten je koř_{enem grafu scény, který obsahuje všechny modely a objekty. Díky}

tomu mů_{žeme získat reference na další objekty ve scén}ě_.

Př_{i exportu scény do .m3g souboru je pot}ř_{eba nastavit jednu kameru jako aktivní. Tu lze pak}

získat jednoduše pomocí metody tř_{ídy World getActiveCamera(). P}ř_{i exportu do souboru je také}

vygenerován HTML dokument, který obsahuje tabulku všech objektů _{scény a jejich identifikátor}

(celé č_{íslo). Reference na jednotlivé objekty scény lze získat práv}ě _{pomocí t}ě_{chto jejich ID. T}ř_ída

World obsahuje metodu find(int ID), která toto provede, nicméně _{je t}ř_{eba ješt}ě _{provést p}ř_{etypování na}

odpovídající typ. V př_ípadě _{3D objektu je to tedy p}ř_{etypování na typ Mesh apod.}

MascotCapsule používá zcela odlišný př_{ístup k na}č_{ítání model}ů _{do aplikace. P}ř_{edchozí zp}ů_{sob není}

možný už jen kvů_{li absenci implementace grafu scény v tomto API. Jak již zde bylo zmín}ě_{no d}ř_íve,

MascotCapsule chápe jeden vyexportovaný soubor .mbac jako jeden 3D model objektu, ne jako celou scénu, jak tomu je u M3G.

Objekt je zde reprezentován tř_{ídou Figure. K na}č_{tení modelu ze souboru slouží konstruktor,}

který jako parametr př_ijímá ř_etě_{zec s cestou k danému souboru s modelem:} Figure box = new Figure("/box.mbac");

Soubor .mbac obsahuje pouze objekt samotný, nikoliv navíc kamery, svě_{tla, textury}

a materiály, jak tomu mů_{že být v M3G. Tyto objekty je t}ř_{eba deklarovat, nastavit a umístit do celé}

scény dodateč_ně _{v kódu.}

5.2

Objekty ve scén

ě

a manipulace s nimi

Každý objekt v tř_írozmě_{rné scén}ě _{je reprezentován instancí odpovídající t}ř_{ídy. V M3G se jedná}

o tř_{ídu Mesh. Nejd}ů_ležitě_{jším prvkem této t}ř_{ídy je VertexBuffer, který obsahuje sou}ř_{adnice všech}

vrcholů _tě_{lesa a normály. Dále pak tato t}ř_{ída obsahuje pole IndexBuffer, ve kterém je možné pomocí}

indexování vrcholů _{definovat submesh. Další d}ů_{ležitou sou}č_{ástí t}ř_{ídy Mesh je pole objekt}ů _typu

Appearance, které definují vzhled celého objektu, př_ípadně _{každého submesh.}

S objekty ve scéně _je č_{asto pot}ř_{eba manipulovat, rotovat jimi a m}ě_{nit jejich velikost. To je}

umožně_{no díky tomu, že t}ř_{ída Mesh d}ě_{dí ze t}ř_{ídy Transformable. A práv}ě _{ona poskytuje metody pro}

výše zmíně_{né manipulace. Tyto metody jsou pak volány p}ř_{ímo nad konkrétní instancí t}ř_{ídy Mesh.}

Metoda setTranslation(float x, float y, float z) umístí objekt př_esně _{na zadané sou}ř_adnice

ve scéně_{. Metoda translate(float x, float y, float z) p}ř_ič_{te zadané hodnoty k aktuální pozici objektu,}

tj. jedná se o posunutí objektu.

Podobně _{je tomu i u rotací. Existuje zde metoda na nastavení orientace objektu} setOrientation(float angle, float x, float y, float z). Prvním parametrem je úhel natoč_{ení udaný}

ve stupních po smě_{ru hodinových ru}č_ič_{ek, další t}ř_{i parametry udávají osu rotace. K rotaci o ur}č_itý

poč_{et stup}ňů _{podle zadané osy slouží metody preRotate(float angle, float x, float y, float z)}

a postRotate(float angle, float x, float y, float z), které se liší pouze poř_{adím násobení transforma}č_ních

matic.

Poslední dů_{ležitou manipulací s objektem je zm}ě_{na jeho velikosti. Jako u p}ř_{edchozích operací,}

i zde je k dispozici metoda, která př_{ímo nastaví velikost objektu setScale(float x, float y, float z).}

Samozř_ejmě _{nechybí ani metoda pro zm}ě_{nu velikosti scale(float x, float y, float z), která aktuální}

velikost vynásobí zadanými hodnotami.

Další možností manipulace je př_{ímá úprava transforma}č_{ní matice. Ta je prvkem v již zmín}ě_né

nadř_{azené t}ř_ídě _{Transformable jako objekt t}ř_{ídy Transformation. Jedná se o transforma}č_{ní matici} č_ísel

typu float o rozmě_{ru 4 krát 4. T}ř_{ída Transformation poskytuje metody jako inverze, rotace a násobení}

jinou maticí.

V MascotCapsule je 3D objekt ve scéně _{reprezentován t}ř_{ídou Figure. Ta obsahuje taktéž prvky jako}

souř_{adnice vrchol}ů _{a normály, navíc na rozdíl od M3G t}ř_{ídy jí lze p}ř_{ímo nastavit texturu (p}ř_ípadně

více textur) typu Texture.

Zásadní rozdíl ovšem nastává v př_{ístupu k manipulacím s objekty. V MascotCapsule nelze}

jednoduše volat nad objektem tř_{ídy Figure metody zajiš}ť_{ující manipulaci, jak tomu je v M3G. Zde je}

situace zcela odlišná. Informace o objektu jako pozice, rotace, měř_{ítko a další data nutná}

pro vykreslení jsou uloženy ve tř_ídě _{FigureLayout. K propojení konkrétního 3D objektu ve scén}ě

s konkrétní instancí FigureLayout dojde až př_{i volání vykreslovací metody. T}ř_{ída FigureLayout již ale}

poskytuje metody pro nastavení umístě_{ní a m}ěř_ítka.

Ovšem neimplementuje př_{ímo metody pro rotace s objektem. Obsahuje ale transforma}č_ní

matici typu AffineTrans (př_ípadně _{pole takovýchto matic), která již poskytuje spoustu metod}

Porovnáme-li př_{ístupy obou API, vidíme, že M3G p}ř_{ináší navíc jakési zjednodušení v podob}ě

metod, které lze volat př_{ímo nad konkrétními objekty a které vykonají požadovanou transformaci.}

5.3

Textury

Další oblastí, ve které se obě _{API zna}č_ně _{liší, je práce s texturami.}

V M3G není maximální velikost textury nijak omezena, pouze množstvím volné pamě_{ti, která}

je k dispozici. Nicméně _{zde jisté omezení existuje, rozm}ě_{ry textury musí být mocninami} č_{ísla 2.}

Textury mohou být uloženy př_{ímo v souboru .m3g spole}č_ně _{s modely, nebo pomocí metody statické}

tř_{ídy Loader na}č_{teny z externího souboru (ve formátu.png). Barvy jsou uloženy ve formátu RGB,}

př_ípadně _{RGBA, jeden byte pro každou složku.}

Samotný obrázek textury je reprezentována objektem tř_{ídy Image2D. Tento objekt m}ů_{že mít}

nastavenu vlastnost muttable, tzn. mů_{že být m}ě_ně_{n kdykoliv za b}ě_{hu aplikace a zm}ě_{na se projeví}

okamžitě _{ve scén}ě_{. Image2D m}ů_{že být ale taky nastaven jako immutable, tzn. po vytvo}ř_{ení se již}

mě_{nit nebude. Tato informace umož}ň_{uje API provést optimalizaci, kompresi, p}ř_ípadně _redukci

barevné hloubky za úč_{elem zvýšení rychlosti vykreslování a úspory pam}ě_ti.

Objekt tř_{ídy Image2D m}ů_{že být použit také jako sprite nebo obrázek na pozadí scény. V tomto}

př_ípadě _{ovšem mohou být rozm}ě_{ry libovolné, omezení na mocniny} č_{ísla 2 zde neplatí.}

Texturu jako takovou reprezentuje tř_{ída Texture2D, ovšem samotná bitmapa, jak již bylo}

zmíně_{no, je uložena v objektu typu Image2D. T}ř_{ída Texture2D uchovává navíc také další vlastnosti}

textury, jako např_{íklad typ filtrování, nastavení barvy nebo blending. Na rozdíl od MascotCapsule,}

texturu nelze konkrétnímu 3D objektu (Mesh) př_iř_{adit p}ř_{ímo. Je zde ješt}ě _{jeden mezi}č_{lánek, a tím je}

tř_{ída Appearance. Ta krom}ě _{jiného m}ů_{že obsahovat objekt typu Texture2D. Objekt typu Appearance}

lze pak již př_{ímo p}ř_iř_{adit danému objektu Mesh, p}ř_ípadně _{více objekt}ů_m.

MascotCapsule umožň_{uje použít textury o maximálním rozm}ě_{ru 256 krát 256 pixel}ů _{s 8 bitovou}

barevnou hloubkou, tj. 256 barev. V porovnání s M3G toto omezení barevné hloubky př_{ináší výrazné}

snížení vizuální kvality vykreslovaných modelů_{. Textury nejsou uloženy v souborech .mbac spolu}

s modely, ale nač_{ítány z bitmapových soubor}ů _.bmp.

Texturu reprezentuje tř_{ída Texture. Na rozdíl od M3G API je zde situace zna}č_ně _{jednodušší.}

Existuje zde př_{ímo konstruktor, který dokáže na}č_{íst texturu z externího bitmapového souboru. Je zde}

také implementován druhý konstruktor, který nač_{te texturu z bajtového pole a metoda dispose(), která}

texturu zruší. To je ovšem vše, žádné další vlastnosti ani nastavení, jako tomu je v MG3, tato tř_ída

neposkytuje. Výhodou je, že texturu lze již př_{ímo p}ř_iř_{adit konkrétnímu modelu nebo model}ů_m.

Výhodou MascotCapsule v práci s texturami je tedy př_{edevším jednoduchost, nicmén}ě _{to s sebou}

př_{ináší zna}č_{ná omezení. Naopak lehce složit}ě_{jší p}ř_{ístup k texturám na stran}ě _{M3G je vyvážen}

podporou dalších nastavení (blending, filtering, wrapping) a toto API poskytuje subjektivně

kvalitně_{jší texturování model}ů_.

5.4

Graf scény

Jedním z velkých rozdílů _{mezi ob}ě_{ma rozhraními je podpora grafu scény. Ten je implementován}

pouze v M3G API, v MascotCapsule V3 zcela chybí.

Celá scéna je tedy reprezentována stromem jednotlivých uzlů_{. Uzly v grafu scény mohou být}

reprezentuje bod, ze kterého je celá scéna pozorována. Tř_{ída Group je neuspo}ř_{ádanou skupinou}

ně_{kolika jiných uzl}ů _{grafu. Speciální podt}ř_{ídou t}ř_{ídy Group je t}ř_{ída World, což je ko}ř_{enový uzel}

celého grafu. Tř_{ída Light reprezentuje sv}ě_{tlo, t}ř_{ída Mesh 3D objekt scény a t}ř_{ída Sprite3D}

dvourozmě_{rný obrázek umíst}ě_{ný v prostoru.}

Př_{i vytvá}ř_{ení scén v externích 3D editorech a jejich exportu do soubor}ů _{formátu .m3g}

se struktura grafu scény vytvoř_{í automaticky, nap}ř_{. v 3ds Max jsou všechny jednotlivé 3D objekty}

potomky vrcholového uzlu World. Nicméně _př_{i exportu je možné si tento strom upravit dle vlastních}

potř_{eb. Samoz}ř_{ejmostí je možnost manipulace a vytvá}ř_{ení grafu scény p}ř_{ímo v programu. K tomu}

slouží př_{edevším metody t}ř_{ídy Group, jako addChild() a removeChild().}

5.5

Osv

ě

tlení scény

Velmi dů_{ležitým prvkem ve scén}ě _{je osv}ě_{tlení, bez n}ě_{j by nebylo ve scén}ě _vidě_{t naprosto žádné}

objekty.

V M3G je svě_{telný zdroj reprezentován t}ř_{ídou Light. Ta d}ě_{dí ze t}ř_{ídy Node, sv}ě_{tlo m}ů_{že být}

tudíž také souč_{ástí grafu scény. T}ř_{ída Node zase d}ě_{dí ze t}ř_{ídy Transformable, proto m}ů_{že být}

se svě_{tlem manipulováno jako s kterýmkoliv jiným 3D objektem, tzn. m}ě_{nit jeho pozici ve scén}ě

a orientaci.

Svě_{telný zdroj m}ů_{že být jedním ze} č_tyř _typů_{, které M3G podporuje:}

• Ambient: svě_{tlo tohoto typu osv}ě_{tluje všechny objekty ve scén}ě _{ze všech sm}ě_rů _{a jeho}

intenzita je stejná v jakékoliv vzdálenosti. Proto jeho pozice ve scéně _{ani nasm}ě_rování

nemají na výsledné osvě_{tlení objekt}ů _{žádný vliv. Tento typ sv}ě_{tla je výpo}č_etně

nejjednodušší.

• Directional: tento svě_{telný zdroj taktéž osv}ě_{tluje všechny objekty ve scén}ě _{se stejnou}

intenzitou nezávislou na vzdálenosti. Roli zde už ovšem hraje jeho nasmě_rování. • Omnidirectional: jedná se o bodový zdroj svě_{tla, které z daného bodu vychází všemi}

smě_{ry. Umož}ň_{uje nastavit ubývání intenzity se vzdáleností od zdroje. U tohoto typu}

svě_{telného zdroje hraje roli pouze jeho pozice, nasm}ě_{rování nemá žádný vliv.}

• Spot: Tento výpoč_etně _nejnároč_ně_{jší typ sv}ě_{tla vrhá sv}ě_{telný kužel, roli zde proto}

hraje jak jeho pozice, tak jeho nasmě_{rování. Taktéž umož}ň_{uje nastavit ubývání}

intenzity s rostoucí vzdáleností a exponent intenzity svě_{tla uvnit}ř _kuželu.

U svě_{telného zdroje lze kdykoliv libovoln}ě _{jeho typ zm}ě_{nit. U typ}ů_{, kde lze nastavit ubývání}

intenzity s rostoucí vzdáleností (Omnidirectional a Spot) lze zvolit buď_{to konstantní, lineární nebo}

kvadratické ubývání. U každého zdroje svě_{tla je možné také nastavit jeho barvu zadáním její RGB}

hodnoty a intenzitu.

Jak je tomu i v jiných oblastech, také v možnostech osvě_{tlení scény je MascotCapsule zna}č_ně

jednodušší. Nelze zde vytvář_{et r}ů_{zné typy zdroj}ů _osvě_{tlení a ty pak libovoln}ě _umísť_{ovat do scény,}

jako by to byly 3D objekty. Tř_{ída Light reprezentuje jen soubor nastavení, které pak p}ř_{i vykreslování}

používá Effect3D, svázaný s konkrétním objektem ve scéně_{. U objektu t}ř_{ídy Light je možné nastavit}

smě_{rový vektor, intenzitu paralelního sv}ě_{tla a intenzitu ambietního sv}ě_{tla. Jak je vid}ě_{t, ve scén}ě _jsou

jakoby dva zdroje svě_{tla (paralelní a ambientní). Jejich vliv na objekty lze pak proto nastavovat práv}ě

Srovnáme-li tedy obě _{API z pohledu osv}ě_{tlení, M3G nabízí zcela jist}ě _{bohatší a komplexn}ě_jší

možnosti. Je ovšem zř_{ejmé, že za cenu vyšších nárok}ů _{na hardware mobilního za}ř_ízení.

5.6

Vzhled objekt

ů

Tato podkapitola pojednává o tom, jakým způ_{sobem ob}ě _{API p}ř_{istupují k uchování informací}

o vzhledu objektů _{a jejich nastavování.}

V M3G k tomuto úč_{elu slouží t}ř_{ída Appearance. Ta je složena z n}ě_{kolika dalších komponent:}

Material, PolygonMode, CompositingMode, Fog a Texture2D. Každá tato komponenta má vlastní tř_{ídu stejného názvu:}

• Material uchovává informace pro výpoč_{et osv}ě_{tlení, tj. hodnoty barev Ambient,}

Diffuse, Specular a Emmisive.

• PolygonMode uchovává nastavení týkající se vykreslování polygonů_.

o Winding – specifikuje, která strana polygonů _{bude p}ř_{ední (front face).}

o Culling – udává, zda-li budou vykresleny př_{ední, zadní nebo ob}ě _strany

polygonů_.

o Shading – stínování mů_{že být nastaveno jako FLAT nebo SMOOTH.} • CompositingMode udržuje nastavení týkající se pixelů _{(depth offset a blending).} • Fog definuje osvě_{tlení v závislosti na vzdálenosti objektu.}

• Texture2D uchovává texturu a k ní odpovídající nastavení.

Appearance obsahuje pouze reference na instance tě_{chto t}ř_{íd. To p}ř_{ináší p}ř_{edevším úsporu}

pamě_{ti, na n}ě_{kolik objekt}ů _{ve scén}ě _{tak m}ů_{že být nap}ř_{íklad aplikován stejný Material a k tomu}

postač_{í pouze jediná instance t}ř_{ídy Material.}

Po vytvoř_{ení nové instance t}ř_{ídy Appearance jsou všechny její komponenty nastaveny}

na hodnotu null. Změ_{nit to lze pomocí odpovídajících metod, p}ř_{íkladem m}ů_{že být setMaterial(). Není}

potř_{eba, aby byly nastaveny všechny komponenty. Pokud má Texture2D hodnotu null, textura prost}ě

nebude aplikována. V př_ípadě _{CompositingMode a PolygonMode rovných null bude p}ř_{i vykreslení}

použito výchozích hodnot. Když je komponenta Material nastavena na null, nebude poč_ítáno

osvě_tlení.

Ještě _{je zde vhodné zmínit, že referencí na Texture2D m}ů_{že mít Appearance i více než jednu,}

a to podle poč_{tu dostupných texturovacích jednotek.}

Tř_{ída uchovávající nastavení vzhledu objekt}ů _{ve scén}ě _{byla v rozhraní MascotCapsule nazvána}

Effect3D. Není př_{ekvapením, že na rozdíl od Appearance v M3G, je zna}č_ně _{jednodušší a neumož}ň_uje

tolik možných nastavení. V první ř_adě _umožň_{uje nastavit typ stínování, bu}ď_{to NORMAL nebo}

TOON. Př_{i použití stínování typu TOON vypadají vykreslené objekty jakoby byly pouze}

dvourozmě_rné.

Dále pak tř_{ída Effect3D obsahuje referenci na objekt typu Light, který uchovává data}

o osvě_{tlení (viz. Podkapitola 5.5 Osv}ě_{tlení scény), možnost nastavení pr}ů_{hlednosti a enviromental}

mapping. Konkrétní instance Effect3D je spojena s modelem až př_{i volání metody renderFigure}

5.7

Vykreslení scény (rendering)

V M3G existuje tř_{ída Graphics3D, která reprezentuje grafický kontext a zajiš}ť_{uje vykreslení scény}

a objektů_{. Tato t}ř_{ída umož}ň_{uje vytvo}ř_{it pouze jedinou instanci, jedná se totiž o tzv. singleton. Tuto}

instanci je tř_{eba získat metodou getInstance. V p}ř_ípadě_{, že aplikace pot}ř_{ebuje provést p}ř_ekreslení

obrazovky, zavolá metodu paint. V této metodě _{je nejprve pot}ř_{eba získat instanci Graphics3D}

a svázat ji s objektem typu Graphics z balíč_ku javax.microedition.lcdui metodou bindTarget. Tento objekt se tak stane cílem, do ně_{hož bude vykreslení provedeno. Cílem m}ů_{že být ale také objekt}

typu Image2D. Poté je možné voláním metody render scénu vykreslit a nakonec je tř_{eba ješt}ě

grafický kontext uvolnit od daného cíle metodou releaseTarget. Ukázka výše zmíně_{né t}ř_{ídy paint:}

protected void paint(Graphics g) {

Graphics3D g3d = Graphics3D.getInstance(); g3d.bindTarget(g);

g3d.render(world); //world reprezentuje ko_řen grafu scény g3d.releaseTarget();

}

Grafický kontext Graphics3D mů_{že být v jednom okamžiku svázán pouze s jedním cílovým}

objektem. Proto po zavolání metody bindTarget bude veškeré vykreslování provádě_{no do color}

bufferu daného cíle, až do zavolání metody releaseTarget.

M3G rozlišuje dva př_{ístupy k vykreslování. Prvním je takzvaný retained mode, kdy je naráz}

vykreslována celá scéna, tj. volá se metoda render s parametrem udávajícím koř_{enový uzel grafu.}

Druhým př_{ístupem je immediate mode, kdy vykreslování probíhá zvláš}ť _{po jednotlivých}

uzlech grafu scény, skupinách nebo jednotlivých objektech.

U vykreslování lze také nastavit ně_{které volby, ovliv}ň_{ující výslednou kvalitu. Mezi n}ě _patř_í

antialiasing, dithering a zda-li použít true color barevnou hloubku. Tyto funkce s sebou ale pochopitelně _př_{inášejí vyšší výpo}č_{etní nároky.}

V MascotCapsule je situace velice podobná. Vykreslovací metody poskytuje taktéž tř_{ída Graphics3D.}

Vykreslovaní ale není voláno automaticky aplikací, muže být proto provádě_{no v libovolné metod}ě_{. Je}

ovšem potř_{eba zajistit periodické volání této metody, nap}ř_{íklad z n}ě_{jaké nekone}č_{né smy}č_ky.

Ve vykreslovací metodě _{je také pot}ř_{eba svázat grafický kontext s cílem, do kterého bude vykreslení}

provedeno. Taktéž to mů_{že být objekt typu Graphics z balí}č_ku javax.microedition.lcdui

př_ípadně _{objekt typu Image z téhož balí}č_ku.

V MascotCapsule není implementován graf scény, proto nelze volat jedinou metodu nad uzlem grafu scény pro vykreslení všech objektů_{. To je t}ř_{eba provést pro každý objekt ve scén}ě _zvlášť_{. Pro}

vykreslení modelu typu Figure, nač_{teného z externího souboru, je zde metoda renderFigure. Existuje}

zde také metoda renderPrimitives, která umí vykreslit model vytvoř_{ený nebo vygenerovaný p}ř_ímo

v programu, pokud jsou metodě _př_{edány pot}ř_{ebné parametry, jako pole sou}ř_{adnic vrchol}ů_{, normály,}

textura atd.

Tyto metody ovšem neprovedou vykreslení ihned, pouze ho zaregistrují. Samotné vykreslení takto zaregistrovaných objektů _probě_{hne až p}ř_{i zavolání metody flush. Tento postup ale obchází}

metoda drawFigure, která vykreslení provede ihned bez odkladu.

Na rozdíl od M3G nelze nastavovat funkce jako antialiasing, dithering nebo true color barevnou hloubku. Jinak je ale princip vykreslování u obou API velice podobný.

6

Srovnávací aplikace

Za úč_{elem porovnání výkonu a rychlosti vykreslování obou API jsem vytvo}ř_{il srovnávací aplikaci,}

jak ve verzi pro rozhraní MG3, tak pro MascotCapsule. Tato aplikace je jakýsi benchmark, skládající se z deseti testů_{. Každý z test}ů _{probíhá 10 sekund a v pr}ů_bě_{hu tohoto} č_{asu je spo}č_{ítáno, kolikrát došlo}

k př_{ekreslení obrazovky. Cílem bylo vytvo}ř_{it rozmanité testy, nap}ř_{íklad mnoho jednoduchých objekt}ů

ve scéně_{, naopak pouze jeden jednoduchý objekt, složitý objekt, více zdroj}ů _svě_{tla, použití textur atd.}

Bě_{hem testu je zobrazován aktuální po}č_{et FPS (snímk}ů _{za sekundu) a} č_{as, do kterého se nepo}č_ítá

doba nač_{ítání model}ů _{mezi jednotlivými testy. Nakonec jsou zobrazeny výsledky, tj. názvy}

jednotlivých testů _{a po}č_{et snímk}ů_{, které byly reáln}ě _vykresleny.

Modely pro jednotlivé testy jsem vytvář_{el v 3D editoru Autodesk 3ds Max 9. Základem je vždy}

scéna s jednou kamerou, jedním nebo více svě_{tly a objektem, p}ř_ípadně _{více objekty.Modely jsem poté}

exportoval do souborů _{formátu .m3g pro verzi aplikace testující M3G API a .bac pro verzi}

MascotCapsule.

Nejprve jsem vytvoř_{il kone}č_{nou verzi této srovnávací aplikace pro M3G a následn}ě _ji

př_{epracoval do verze pro MascotCapsule. Kv}ů_{li r}ů_{zným omezením a odlišnostem mezi ob}ě_{ma API}

nejsou tyto dvě _{verze aplikace naprosto a p}ř_esně _{totožné. Jednotlivé zásadní odlišnosti jsou popsány}

níže v popisech jednotlivých testů_.

6.1

Popis jednotlivých test

ů

Základní scéna s kamerou, jedním svě_{tlem a krychlí, která rotuje.}

Test 2:

Stejná scéna jako v testu 1, ovšem na rotující krychli je aplikována textura. Ve verzi pro M3G je textura uložena př_{ímo v souboru s celou scénou. Ve verzi MascotCapsule nejsou textury uloženy}

v souborech společ_ně _{s modely, proto je textura v samostatném bitmapovém souboru .bmp.}

Test 3:

Scéna jako v př_{edchozím testu, na rozdíl od n}ě_{j obsahuje 4 bodová sv}ě_{tla typu Omnidirectional.}

Tento test je ovšem použit pouze v M3G verzi. MacsotCapsule neumožň_{uje použít 4 sv}ě_{tla, proto je}

místo testu 3 zopakován test 2.

Test 4:

Základní scéna s rotujícím složitým modelem, který má 10201 vrcholů_{. Byl vytvo}ř_{en ze základního}

objektu rovina (v 3ds Max nazvaným Plane) aplikací modifikátoru Displace, který jej podle bitmapy zdeformoval do složitého tvaru. Zde jsem opě_{t narazil na omezení MascotCapsule, a to v podob}ě

maximálního poč_{tu vrchol}ů_{, které m}ů_{že model mít, konkrétn}ě _{21854. P}ů_{vodní model v tomto testu}

tuto hranici zdaleka př_{esahoval, proto jsem jej musel zjednodušit a zmenšit po}č_{et vrchol}ů_{, t}ě_sně

pod tuto hranici. Zde jsem ale narazil na další problém. Tím je nedostatek pamě_{ti u starších model}ů

mobilních telefonů_{, pro které byl i tento zjednodušený model p}ř_{íliš pam}ěť_ově _nároč_{ný. Abych}

umožnil spuště_{ní tohoto testu i na starších telefonech, zmenšil jsem tedy složitost modelu}

na koneč_{ných 10201 vrchol}ů_.

Test 5:

Tento test je totožný s testem 4, na model je navíc aplikována textura.

Test 6:

Scéna obsahuje 140 rotujících krychlí bez textury. Ve verzi M3G obsahuje scéna 140 samostatných krychlí, ke kterým se př_{istupuje pomocí pole objekt}ů _{typu Mesh. P}ř_{i každém vykreslení nového}

snímku se v cyklu polem prochází a pro každou krychli je volána metoda provádě_{jící rotaci. Tento}

př_{ístup ovšem není možný ve verzi pro MascotCapsule. Zde nelze ze souboru .mbac získat reference}

na jednotlivé č_{asti (krychle) scény a tyto si poté uložit do pole} č_{i kolekce. Modelem lze proto rotovat}

pouze jako celkem, ne jen jednotlivými krychlemi zvlášť_{. Použil jsem proto model samostatné}

krychle z testu 1, který je v každém snímku př_íslušně _{rotován, a poté ve dvou vno}ř_{ených cyklech}

duplikován a vykreslen do požadovaného rozmístě_{ní (14 sloupc}ů_{, 10} ř_ádků_).

Test 7:

Stejný jako test 6, na rozdíl od ně_{j je v M3G verzi nasvícena scéna} č_tyř_{mi sv}ě_{tly. Ve verzi}

MascotCapsule je podobně _{jako v testu 2 a ze stejného d}ů_{vodu zopakován p}ř_{edchozí test.}

Test 8:

Opě_{t scéna se 140 rotujícími krychlemi. Na všechny krychle je navíc aplikována textura.}

Testy 9 a 10:

Poslední dva testy jsou zaměř_{eny na pr}ů_{hlednost objekt}ů_{. Scéna je složena z rotující rychle s texturou}

a dvě_{ma statickými krychlemi v pozadí. V testu 9 není použita pr}ů_{hlednost, slouží pro porovnání}

výsledků _{s testem 10, kde je rotující krychli s texturou nastavena 55% pr}ů_{hlednost. Ve verzi}

MascotCapsule opě_{t není celá scéna v jednom souboru. Modely statických krychlí v pozadí a krychle}

s texturou jsou zvlášť _{ve dvou souborech.}

Obrázek 6.5: Test 5 Obrázek 6.6: Test 6

6.2

Výsledky

Po dokonč_{ení obou verzí a otestování na softwarových emulátorech jsem srovnávací aplikaci spoušt}ě_l

na ně_{kolika mobilních telefonech a sbíral výsledky test}ů_{. Ideální pro srovnání abou API jsou}

samozř_ejmě _{telefony zna}č_{ky Sony Ericsson, které podporují jak M3G, tak MascotCapsule. Nicmén}ě

testy jsem provádě_{l i na telefonech jiných zna}č_{ek, které podporují pouze MG3 API.}

Kromě _{reálných mobilních telefon}ů _{jsem tyto testovací aplikace také pro zajímavost spoušt}ě_l

na softwarových emulátorech a taktéž sbíral výsledky. Emulátory jsem využíval př_{i vývoji a testování}

daleko č_astě_{ji, než testování aplikace p}ř_{ímo na fyzickém mobilním telefonu. P}ř_{i implementaci test}ů

pro M3G jsem používal nejč_astě_{ji emulátor od spole}č_{nosti Sun Microsystems, který je sou}č_{ástí balíku}

nástrojů _{J2ME Development Kit. Ob}č_{as jsem využíval také emulátor za}ř_{ízení s opera}č_{ním systémem}

Symbian S60, ten je souč_{ástí Nokia S60 3rd Edition SDK. Oba emulátory ovšem nepodporují rozhraní}

MascotCapsule. Proto jsem př_{i implementaci srovnávací aplikace pro toto API využíval softwarové}

emulátory od společ_{nosti Sony Ericsson. Za zmínku stojí, že vývojový balí}č_{ek Sony Ericsson SDK}

obsahuje skuteč_ně _{pestrou škálu emulátor}ů _rů_{zných model}ů_.

Následující tabulka př_{ináší p}ř_{ehled získaných výsledk}ů _{(viz. Tabulka 6.1). U každého modelu}

mobilního telefonu je uvedeno, která verze srovnávací aplikace a pro jaké API na ně_{m byla spušt}ě_na. Č_{ísla u jednotlivých test}ů _vyjadř_{ují po}č_{et snímk}ů_{, které byly b}ě_{hem každého testu za 10 sekund}

vykresleny. Zvláště _{na starších telefonech se stávalo, že n}ě_{které testy nebyly v}ů_{bec spušt}ě_ny

z dů_{vodu nedostatku volné pam}ě_{ti. V t}ě_{chto p}ř_{ípadech je v tabulce uvedeno} č_{íslo 0.}

Počet vykreslených snímků v jednotlivých testech

Telefon API Test 1 Test 2 Test 3 Test 4 Test 5 Test 6 Test 7 Test 8 Test 9 Test 10 Nokia E65 M3G 506 365 355 21 18 68 61 50 245 246 Nokia E66 M3G 827 571 571 36 29 126 129 91 446 390 Nokia N85 M3G 565 451 452 31 27 156 133 100 367 339 Sony Ericsson K800i M3G 543 376 365 10 7 80 54 45 209 176 Sony Ericsson K800i MC 724 716 719 110 99 143 144 127 709 710 Sony Ericsson K700i MC 479 443 449 12 10 63 63 61 389 330 Nokia S60 Emulator M3G 739 606 691 57 62 233 241 185 620 452 Sun WTK Emulator M3G 613 613 455 116 90 413 378 328 465 470 Sony Ericsson K750 Emulator MC 314 325 324 441 432 301 316 315 287 323 Sony Ericsson W900 Emulator MC 116 149 167 147 161 167 152 170 153 153 Siemens S65 M3G 226 181 182 8 0 0 0 0 104 108

Tabulka 6.1: Výsledky jednotlivých testů

Vysvě_tlivky:

• M3G – výsledky testů _{aplikace využívající JSR 184: Mobile 3D Graphics API} • MC – výsledky testů _{aplikace využívající rozhraní MascotCapsule V3}

Po seč_{tení výsledk}ů _{všech test}ů _{a se}ř_{azení získáme graf porovnávající výkonnost jednotlivých model}ů

mobilních telefonů_:

Následující tabulka (viz. Tabulka 6.2) př_{ináší p}ř_{ehled n}ě_{kolika vybraných údaj}ů _{o testovaných}

mobilních telefonech [12]. Dů_{ležitým sloupcem (Hardware) je údaj o použitém procesoru, p}ř_ípadně

velikosti dostupné RAM. Na tomto údaji lze sledovat, jaký vliv mají právě _{tyto parametry na rychlost}

vykreslování 3D grafiky. Podle roku uvedení na trh lze také sledovat postupný vývoj jak hardwaru, tak nárů_{stu výpo}č_{etní výkonnosti. Posledním údajem je informace o verzi použitého opera}č_ního

systému, pokud jím daný model disponuje. Operač_{ní systém mobilního za}ř_{ízení totiž m}ů_{že mít}

pochopitelně _{na rychlost vykreslování také jistý vliv.}

Výrobce Model Rok uvedení na trh Hardware Operační systém

Sony Ericsson K800i 2006 210Mhz Bez OS Sony Ericsson K700i 2004 110Mhz Bez OS

Nokia E65 2007 220MHz, 20MB Symbian S60 v9.1 Nokia E66 2008 369MHz, 128MB Symbian S60 v9.2 Nokia N85 2008 369MHz, 128MB Symbian S60 v9.3 Siemens S65 2004 100MHz Bez OS

Tabulka 6.2: Technické parametry a další informace o testovaných mobilních telefonech

6.3

Zhodnocení výsledk

ů

Podívejme se nejprve na výsledky testů _{provedených na modelu Sony Ericsson K800i, na kterém bylo}

možné spustit verze testů _{pro ob}ě _{API. Zde MascotCapsule dosahuje jednozna}č_ně _{lepších výsledk}ů

ve všech testech. Zejména u testůč_{íslo 4 a 5 (rotace složitého modelu) je po}č_{et vykreslených snímk}ů

až 10 krát vě_{tší ve prosp}ě_{ch MascotCapsule. Nicmén}ě _{je t}ř_{eba podotknout, že MascotCapsule}

podporuje pouze 8bitovou barevnou hloubku textury, což pochopitelně _př_{ináší výhodu z pohledu}

výkonu, ale na druhou stanu znač_ně _{horší vizuální kvalitu zobrazení. Také u ostatních test}ů _{je vizuální}

kvalita vykreslených modelů _subjektivně _{nižší v neprosp}ě_{ch Mascot}