Monograa Mobile 3D Graphics (JSR 184) OpenGL ES (JSR 239) Grupo 4

Monograa Mobile 3D Graphics (JSR 184) OpenGL ES (JSR 239) Grupo 4 Roseane Midori Miya Sileno Rocco Tatiane Silvia Leite 22 de Abril - 2008 1 Introduc~ao Esta monograa tem como objetivo apresentar duas diferentes APIs utilizadas no desenvolvimento de aplicac~oes gracas 3D, sendo elas a API JSR 184 e JSR 239. Ser~ao descritas as principais caractersticas de cada biblioteca, assim como exemplos de codigos e descric~ao dos princpios de programac~ao de aplicac~oes 3D. 2 Mobile 3D - JSR 184 2.1 Introduc~ao A API Mobile 3D Graphics foi desenvolvida para a plataforma J2ME como um pacote opcional para ser utilizado com os pers MIDP. Esta API foi denida pala comunidade Java (JCP) como JSR-184 [2], sendo esta a primeira especicac~ao 3D para dispositivos moveis. Esta especicac~ao foi liderada pela Nokia, mas contou com um grande grupo de membros colaboradores, como Sun Microsystem, Sony Ericson, Symbian, Motorola dentre outros [3]. Existe uma incrvel variedade de areas que podem fazer uso da API 3D, o que inclui jogos, interfaces com o usuario, aplicac~ao de screen saver, visualizac~ao de mapas e mensagens animadas, dentre outras. Em todas as areas e comum a necessidade de criac~ao simples de conteudo, mas em algumas 1

delas sera necessario tambem grande processamento de polgonos, enquanto em outras sera necessario alta qualidade no processamento de imagens. Assim, para atender a todas essas diferentes necessidades ela suporta tanto aplicac~oes de alto nvel, quanto de baixo nvel. A exist^encia de interfaces ecientes e gracos 3D interativos e possvel gracas a possibilidade de alto e baixo nvel de programac~ao. O diferencial da API Mobile 3D e possibilitar a utilizac~ao de gracos 3D mesmo em dispositivos moveis que possuem um poder de processamento mais limitado, assim como uma menor quantidade de memoria. Estes dispositivos em geral tambem n~ao possuem suporte de hardware para gracos 3D ou operac~oes de ponto utuante. Porem, com a rapida evoluc~ao destes dispositivos com relac~ao a processamento, memoria e ate mesmo displays e cores, esta API pode ser usada mais amplamente e com uma preocupac~ao menor com a otimizac~ao do codigo desenvolvido. A API Mobile 3D funciona em cima da vers~ao 1.1 do CLDC (Connected Limited Device Conguration) [4], e tambem sobre o perl MIDP (Mobile Information Device Prole) [5] a partir da vers~ao 2.0. O CLDC e uma congurac~ao que dene os recursos da maquina virtual e as bibliotecas principais para J2ME, sendo que dentre elas esta a capacidade de ponto utuante. Ja o MIDP consiste em um perl para dispositivos portateis, denindo APIs como a de interface com o usuario, redes e conectividade, armazenamento, entre outros. Atualmente a capacidade de processamento e memoria dos dispositivos moveis lancados no mercado est~ao surpreendendo, porem o mercado e composto por uma maioria que n~ao t^em efetivamente hardware para calculo de ponto utuante, assim a API precisou balancear e encontrar um equilbrio entre a velocidade obtida atraves de operac~oes de inteiro e a facilidade de programac~ao fornecida por operac~oes de ponto utuante. Calculos que exigem um processamento mais rapido aceitam par^ametros inteiros de 8 ou 16 bits, e outros calculos podem ser realizados com a matematica de ponto utuante para facilitar a programac~ao da aplicac~ao. A Figura 1 apresenta o relacionamento da API com as outras estruturas. A partir da vers~ao 2.2 do software J2ME Wireless Toolkit ja e fornecido o suporte a API jsr-184. Mas ao desenvolver qualquer aplicativo utilizando esta API deve-se atentar para o fato de que esta API e um pacote opcional, e portanto, apesar de funcionar no simulador fornecido pelo Wireless toolkit, alguns dispositivos moveis podem n~ao suportar esta API e n~ao sera possvel executar a aplicac~ao desenvolvida. 2

Figura 1: A pilha de camadas da Mobile 3D Graphics API 2.2 Especicac~ao A API Mobile 3D Graphics e denida no pacote javax.microedition.m3g, possibilitando o uso facil da API para renderizac~ao de gracos 3D nos seus dois modos de operac~ao. O M3G fornece aos desenvolvedores dois modos para desenhar gracos 3D: immediate mode e retained mode. No immediate mode, os comandos gracos s~ao mandados diretamente para o pipeline graco e executados imediatamente pelo mecanismo de renderizac~ao do dispositivo. Neste modo o desenvolvedor deve escrever um codigo que diz ao mecanismo de renderizac~ao exatamente o que renderizar a cada quadro de animac~ao. Alem disso, a cena normalmente possui uma c^amera e um conjunto de luzes associados, mas que n~ao s~ao necessariamente parte dela. Usando o immediate mode e possvel renderizar objetos individualmente. No retained mode sempre e usado um grafo de cena que conecta todos os objetos geometricos do mundo 3D em uma estrutura de arvore 2, e tambem especica a c^amera, luzes e background. Este modo funciona com um nvel mais alto de informac~ao sobre cada objeto, guardando caractersticas como estrutura geometrica, posic~ao e apar^encia de quadro pra quadro. E possvel utilizar estes modos separadamente ou ao mesmo tempo, dependendo da tarefa a ser executada. O formato de arquivo especco da API Mobile 3D possibilita a criac~ao de estruturas de mesh, hierarquia de cenas, materiais, texturas, keyframes de animac~ao, luz, dentre outras, que s~ao carregados pela classe Loader e depois manipuladas dentro da aplicac~ao 3D. A renderizac~ao e feita pela classe Graphics3D. A classe World e a raiz de um grafo de cena. A classe Object3D e a base para todos os objetos que s~ao carregados de um arquivo e que podem ser renderizados. No total a API Mobile 3D e composta por 30 classes divididas em 6 grupos: classes basicas, classes para nos de grafo de cena, classes para carga de arquivos e funcionalidades de baixo nvel, classes para atributos visuais, 3

classes modicadoras e classes para animac~ao e tratamento de colis~ao. A seguir s~ao descritas brevemente todas as classes do pacote M3G. AnimationController - Controla a posic~ao, velocidade e peso de uma sequ^encia de animac~ao. Essa classe pode ser usada para controlar as caractersticas de qualquer elemento de uma animac~ao; por exemplo, pode controlar o brilho e a movimentac~ao da luz. AnimationTrack - Associa uma sequ^encia de keyframes com um objeto do tipo AnimationCrontroller e com uma propriedade animavel, que e uma variavel (scalar ou vetor) que o sistema de animac~ao pode atualizar diretamente. Appearance - Um conjunto de componentes que dene os atributos de renderizac~ao de um Mesh ou um Sprint3D. Background - Dene se e como o viewport sera limpado. No retained mode, o objeto Background associado com o World e utilizado. No immediate mode, o objeto Background e passado como par^ametro. Camera - Um dos elementos do grafo de cena que dene a posic~ao do campo de vis~ao na cena e a projec~ao de 3D para 2D. CompositingMode - Um componente da classe Appearance que encapsula atributos de composic~ao por pixels. Fog - Um componente da classe Appearance que encapsula atibutos para fogging. Graphics3D - Classe unica de gracos 3D que pode ser vinculado a um alvo de renderizac~ao. Toda a renderizac~ao deve ser feita atraves do metodo render() dessa classe. Group - Um no do grafo de cena que armazena um conjunto de nos como lhos. Image2D - Uma imagem bidimensional que pode ser utilizada com textura, fundo ou sprite. As imagens 2D pode ser mutaveis, que podem ser atualizadas a qualquer momento, e imutaveis, que s~ao criadas pelo construtor da classe e n~ao podem ser modicadas depois. IndexBuer - Classe abstrata que dene como conectar vertices para formar um objeto geometrico. 4

KeyframeSequence - Encapsula os dados de uma animac~ao como uma sequ^encia de keyframes com timestamps e valores, que representam um caracterstica da animac~ao em um determinado instante. Pode ser associado com multiplos alvos de animac~ao. Light - Um no do grafo de cena que representa diferentes tipos de fontes de luz, que s~ao utilizadas para determinar a cor de cada objeto. Loader - Responsavel por ler e carregar os nos do grafo de cena. Carregar um grafo de cena a partir de um arquivo M3G e a forma mais utilizada para se construir uma cena 3D. Material - Um componente da classe Appearance que encapsula atributos de material para os calculos de luz. Outros atirbutos para a luz s~ao denidos nas classes Light, PolygonMode e VertexBuer. Mesh - Um no do grafo de cena que representam um objeto 3D denido como uma superfcie poligonal. Essa classe representa objetos mesh convencionais, ou seja, que s~ao rgidos. Suas subclasses MorphingMesh e SkinnedMesh extendem as caractersticas do Mesh e conseguem transformar verticas independentemente. MorphingMesh - Um no do grafo de cena que representa um mesh polignal do tipo vertx-morphing. Node - Classe abstrata para todos os nos do grafo de cena. Existem 5 tipos diferentes de nos: - Camera, que dene a projec~ao de 3D para 2D assim como a posic~ao de visualizac~ao da cena; - Mesh, que dene um objeto 3D constitudo de tri^angulos com propriedades de material associadas; - Sprite3D, que dene uma imagem 2D com a posic~ao no espaco 3D; - Light, que dene a posic~ao, direc~ao, cor e outros atributos de uma fonte de luz; - Group, que serve como raiz para um grafo de cena. Object3D - Classe abstrata para todos os objetos que fazem parte do World da aplicac~ao. Isso inclui o proprio objeto World, outros nos do grafo de cena, animac~oes, texturas, etc. PolygonMode - Um componente da classe Appearance que encapsula atributos de polgonos, inlcuindo caractersticas relacionadas a culling das faces, winding de polgonos, calculos de luz, correc~ao de perspectiva e shading. 5

RayIntersection - Armazena a refer^encia para um Mesh or Sprite3D que sofreu intersecc~ao e informac~oes referentes ao ponto de intersecc~ao. Um objeto RayIntersection e preenchido pelo metodo pick() na classe Group. SkinnedMesh - Um no do grafo de cena que representa um polgono mesh animado. Sprite3D - Um no do grafo de cena que representa uma imagem 2D em uma posic~ao 3D. Essa e uma alternativa para a texturizac~ao geometrica, mas apresenta uma serie de restric~oes. E renderizada como um array retangular de pixels com uma profundidade constante. Texture2D - Um componente da classe Appearance que encapsula uma imagem de textura 2D e um conjunto de atributos especicando como a imagem deve ser aplicada nos sub-meshs. Transform - Uma matriz generica 4x4 de numeros de ponto-utuante que representa uma transformac~ao. Transformable - Classe abstrata para Node e Texture2D que dene metodos para manipulac~ao de nos e transformac~ao de texturas. TriangleStripArray - Dene um array de triangle strips. Em um triangle strip os primeiros 3 ndices de vertices denem o primeiro tri^angulo e cada proximo ndice dene um novo tri^angulo juntamente com os 2 ultimos ndices. VertexArray - Array de vetores inteiros que representam as posic~oes dos vertices, os vetores normais, cores ou coordenadas de textura. VertexBuer - Armazena refer^encias para objetos VertexArray que contem posic~oes, cores, vetores normais e coordenadas de textura para um conjunto de vertices. World - No especial do tipo Group que e a raiz de um grafo de cena. 2.3 Desenvolvimento A seguir s~ao explicadas as estruturas basicas de uma aplicac~ao baseada na API Mobile 3D, incluindo exemplos e princpios de programac~ao 3D. 6

Figura 2: Estrutura de um grafo de cena 2.3.1 Grafo de cena O grafo de cena e uma estrutura de dados em arvore na qual cada folha dene um tipo de estrutura 3D, como por exemplo c^amera, fonte de luz, mesh, material, etc. Na API Mobile 3D o grafo de cena contem objetos de classes que extendem Object3D; alem disso todo o grafo de cena t^em como no raiz um objeto World. E possvel carregar um grafo de cena a partir de um arquivo M3G. O arquivo carregado pode ser renderizado no retained mode, caso contenha um grafo de cena, ou ainda no immediate mode, caso contenha apenas uma estrutura simples, como um mesh. Quando a aplicac~ao possui muitos objetos 3D em cena a estrutura de grafo e a melhor forma de se organizar os objetos e de modica-los; o programador consegue inserir e retirar objetos apenas inserindo e retirando nos no grafo. 7

2.3.2 World A classe World prov^e uma forma de manter todo o grafo de cena 3D concentrada em uma forma unica, simples de ser acessada. Um objeto World pode conter um grande numero de meshes, fontes de luz, c^ameras, etc. A classe World e o no raiz de um grafo de cena e n~ao pode, assim, conter nos pai. Um World pode ser criado manualmente pelo programador e novos nos podem ser inseridos nele. Normalmente, porem, o que se faz e carregar um World a partir de um arquivo M3G e depois modicar o seu conteudo de acordo com a aplicac~ao. Os arquivos M3G podem conter desde simples estruturas mesh ate complexos grafos de cena, com diversas c^ameras, luzes, materiais, etc. Durante o processo de carregamento da cena o objeto Loader extrai o conteudo do arquivo M3G e constroi todas as estruturas necessarias para o grafo de cena, instanciando os objetos, inicializando-os, criando as ligac~oes entre os nos do grafo, etc. Devido a complexidade e exig^encias de memoria e processamento que esse processo requer, e recomendado que o programador utilize ferramentas 3D, com o 3D Studio Max, para eliminar dados desnecessarios dos arquivos M3G a serem carregados. 2.3.3 Loader A classe Loader foi desenvolvida para facilitar a escrita e leitura de estruturas de grafo de cena em arquivos. E possvel, porem, realizar a gravac~ao e leitura do arquivo manualmente, para ns de otimizac~ao da aplicac~ao. Os arquivos de formato compatvel com a API Mobile 3D t^em extens~ao.m3g. Quando um arquivo M3G e lido, todos os objetos que extendem Object3D s~ao transformados em um array, que pode ser acessado pelo desenvolvedor. O exemplo de cogido a seguir mostra o processo de carregamento do arquivo. Object3D[] obj = null; try { obj = Loader.load(file); } catch (Exception e) { } World loadedworld = (World) obj[0]; O array obj possui todos os objetos do grafo de cena. O no raiz (obj[0]) e do tipo World e deve ser utilizado para se obter acesso aos outros objetos da cena. E possvel tambem acessar os objetos diretamente a partir do array obj, mas normalmente essa tarefa e feita a partir de um objeto World. 8

2.3.4 Object3D Todas as classes, com excec~ao as classes: Loader, Transform, RayIntersection e Graphics3D, s~ao extendidas do pacote javax.microedition.m3g.object3d. A classe Object3D fornece um conjunto de funcionalidades basicas comuns a todas as classes. Usando estes metodos fornecidos, qualquer classe derivada da Object3D pode ser facilmente animada com controladores referenciaveis, que utilizam um codigo de identicac~ao para cada informac~ao, possibilitando encontra-la na cena. 2.3.5 Graphics3D O World inteiro ou quaisquer nos da cena podem ser renderizados atraves de uma requisicde coordenadas ~ao do Graphics3D especicando uma c^amera. A renderizac~ao da c^amera pode ser selecionada manualmente ou pode ser usada a c^amera padr~ao (default). Existem quatro modos diferentes de renderizac~ao. O primeiro modo, conhecido como retained mode, e usado quando todo o grafo de cena e renderizado. Neste modo, a c^amera ativa e as luzes s~ao setadas pelo Mundo que sera renderizado. Os outros modos, conhecidos como immediate mode, tambem possuem uma c^amera ativa e um conjunto de luzes ativas. O segundo modo e usado para renderizac~ao de apenas alguns grafos de cena selecionados. O terceiro e quarto modos s~ao utilizados para renderizac~ao de um unico submesh. Estes modos podem ser muito uteis para os diversos truques gracos, tais como renderizac~ao de textura. Alem disso, as aplicac~oes que utilizam algum tipo de algoritmo de otimizac~ao de visualizac~ao podem se beneciar da renderizac~ao de meshes com estes metodos. 2.3.6 Camera A classe Camera e uma classe responsavel em transformar as coordenadas do espaco 3D para o espaco de coordenadas da tela. E possvel denir diversas c^ameras, tanto no immediate mode quanto no retained mode. Teoricamente qualquer numero de c^ameras e permitido, o que signica que e possvel criar diferentes ^angulos de visualizac~ao, bem como os efeitos especiais por rotac~ao apenas trabalhando com os par^ametros das c^ameras. 2.3.7 Luz A API JSR-184 suporta 4 tipos diferentes de luzes, cada uma com complexidade computacional diferente. Os tipos de luzes s~ao: 9

Luz ambiente (Ambient light): dene a intensidade geral dos objetos na cena. A luz ambiente ilumina toda a cena com a mesma quantidade de luz, diminuindo os calculos, ja que sua localizac~ao e direcionamento podem ser desconsiderados. Luz direcional (Directional light): dene apenas a direc~ao de onde a luz esta vindo. A sua posic~ao ou dist^ancia dos objetos, n~ao tem qualquer efeito, embora esta possa ser livremente posicionada na cena. Esta luz e boa para simular fontes distantes de luz, tais como um sistema de luz solar. Luz omni (Omni light): dene um ponto de fonte luminosa. Essa luz afeta objetos em todas as direc~oes ao seu redor. Uma curva de atenuac~ao (linear ou quadratica) pode ser setada para que a iluminac~ao perca a intensidade quando aumenta-se a dist^ancia entre a luz e a superfcie do alvo. Luz spot (Spot light): dene a direc~ao, a posic~ao e o raio da luz. E uma especie de cone apontando para o espaco a ser iluminado. A luz spot n~ao atinge objetos que se encontram fora do seu cone ^angulo. A seguir e apresentado um exemplo de codigo mostrando como setar o modo de luz e a gura 3 que demonstra o efeito dos diversos modos de luz. // Create light. _light = new Light(); _lightmode = LIGHT_OMNI; setlightmode(_light, _lightmode); Transform lighttransform = new Transform(); lighttransform.posttranslate(0.0f, 0.0f, 3.0f); _graphics3d.resetlights(); _graphics3d.addlight(_light, lighttransform); /** * Sets the light mode. * * @param light light to be modified. * @param mode light mode. */ protected void setlightmode(light light, int mode) { switch (mode) { case LIGHT_AMBIENT: light.setmode(light.ambient); light.setintensity(2.0f); break; case LIGHT_DIRECTIONAL: 10

Figura 3: Tipos de luz light.setmode(light.directional); light.setintensity(1.0f); break; case LIGHT_OMNI: light.setmode(light.omni); light.setintensity(2.0f); break; case LIGHT_SPOT: light.setmode(light.spot); light.setspotangle(20.0f); light.setintensity(2.0f); break; // no default } } 3 OpenGL ES - JSR 239 3.1 Introduc~ao A OpenGL ES (Open Graphics Library for Embedded Systems ) e uma API graca para renderizac~ao de imagens 3D. Seu porte para a linguagem Java foi especicado pela JSR 239 [6], proposto pela propria Sun Microsystems. Em termos genericos ela pode ser denida como um sub-conjunto da API graca OpenGL, projetada para sistemas embarcados como telefones celulares, PDAs e consoles de jogos. Ela e denida e promovida pelo Khronos Group [7], um consorcio de industrias de software e hardware gracos interessadas em APIs abertas para gracos e multimdia. A OpenGL ES veio para preencher a necessidade dos desenvolvedores que ja s~ao familiares com OpenGL, facilitando o porte das varias aplicac~oes 11

Figura 4: OpenGL ES roadmap (fonte: www.khronos.org) em OpenGL de desktops para sistemas embarcados. Muito difundida atualmente, ja foi adotada como API graca padr~ao para varias plataformas e dispositivos, dentre eles: Symbian OS, Android, iphone, PlayStation 3. 3.2 Especicac~ao O desenvolvimento atual do OpenGL ES segue duas grandes linhas em paralelo: 1.x e 2.x. A linha \1.x" enfatiza a acelerac~ao graca por hardware, e e principalmente focada nos dispositivos que ainda n~ao possuem processamento de ponto-utuante, necessitando portanto de todo um suporte para func~oes que trabalhem apenas com dados inteiros. A linha \2.x" ja se preocupa em incorporar todas as funcionalidades de programac~ao graca, como a manipulac~ao de pontos utuantes e utilizac~ao de pipelines para processamento de shaders. OpenGL ES possui dois proles: "Common Prole" e "Safety Critial Prole". O "Common Prole" e especicado para entretenimento (console de jogos, celulares, etc), enquanto o "Safety Critical Prole" e mais focado em aplicac~oes comerciais crticas, onde a conanca e a garantia s~ao pontos essenciais (como em aviac~ao, telas automotivas, etc). A API contem cerca de 20 classes ao todo, sendo grande maioria interfaces de acesso ao pacote EGL e as primitivas (GL). Principais classes/interfaces do pacote EGL s~ao: 12

EGLContext { classe base para obter uma instancia do EGL e do GL. EGLDisplay { classe representativa do display do dispositivo. EGLCong { encapsula as possiveis congurac~oes de video do dispositivo. Para selecionar o modo desejado, deve-se descrev^e-lo de acordo com as caractersticas desejadas (ex: numero de bits para cada cor, se tera transpar^encia ou n~ao), e ent~ao chamar egl.eglchoosecong passando os atributos desejados. Caso o dispositivo tenha algum modo que atenda aos requisitos apresentados, sera ent~ao retornada uma inst^ancia do EGLCong. EGLSurface { interface entre o display do dispositivo e a congurac~ao de video desejada. Principais interfaces do pacote opengles s~ao: EGL / EGL10 / EGL11 { interfaces de acesso as func~oes/metodos da EGL. A classe EGL e a classe base, da qual deriva-se a classe EGL10 (EGL vers~ao 1.0), e desta deriva-se a classe representativa da vers~ao 1.1 (EGL11). GL / GL10 / GL11 - interfaces de acesso as func~oes/metodos da OpenGL. A classe GL e a classe base, da qual deriva-se a classe GL10 (GL vers~ao 1.0), e desta deriva-se a classe representativa da vers~ao 1.1 (GL11). Principais classes do pacote java.nio s~ao: ByteBuer / FloatBuer / IntBuer / ShortBuer { classes auxiliares para manipulac~ao de arrays de dados, de acordo com o tipo de dado a ser usado. 3.3 Comparac~oes com outras APIs 3.3.1 Comparac~ao com OpenGL Apesar de ja existir uma especicac~ao com o intuito de portar o OpenGL para Java (JSR 231), a JSR 239 se diferencia dessa por: utilizac~ao de double-buering por padr~ao; aus^encia do par de primitivas \glbegin / glend" (usada na renderizac~ao de polgonos), em favor do uso de arrays de vertices (vertex arrays); presenca de tipos de dados inteiros para coordenadas de vertices, devido principalmente a aus^encia de unidades de processamento de ponto utuante (FPU) em alguns sistemas embarcados. 13

Figura 5: Abstrac~ao das camadas de acesso 3.3.2 Comparac~ao com Mobile 3D Em comparac~ao com a JSR 184 (Mobile 3D Graphics), apesar de ambas proverem a mesma funcionalidade, a diferenca basica entre elas esta na interface. A JSR 184 e, alem de oferecer as caractersticas de desenvolvimento do OpenGL ES, atraves do immediate mode oferece uma interface mais alto nvel, proporcionando uma maior facilidade para tratar objetos 3D. Na tabela 1 mostra 2 exemplos de codigo em OpenGL ES e Mobile 3D. Tabela 1: Exemplos de codigos do OpenGL ES e Mobile 3D OpenGL ES gl.gltranslatef(0.f, 0.f, -30.f); gl.glrotatef(1.0f, 1.0f, 2.0f, 0.0f); gl.glrotatef(1.0f, -0.1f, 0.0f, -5.0f); gl.glvertexpointer(3, GL10.GL BYTE, 0, cubevertices); gl.glcolorpointer(4, GL10.GL UNSIGNED BYTE, 0, cubecolors); Mobile 3D troo = (Group)myWorld.nd(POGOROO ID); tcams = (Group)myWorld.nd(CAMERA ID);.... troo.setorientation(dirroo, 0, 0, 1); tcams.setorientation(dircam, 0, 0, 1); Isso tambem pode ser observado na gura 5, que demonstra o nivel de abstrac~ao do codigo em relac~ao ao sistema operacional: 3.4 Desenvolvimento A JSR 239 se concentra no pacote javax.microedition.khronos.opengles. Com o intuito de separar a implementac~ao da JSR 239 dos detalhes especcos de cada plataforma/hardware, foi criada a EGL (Nativa Platform 14

Figura 6: Exemplo de uso Graphics Interface). Ela e uma camada de interface para ger^encia de recursos gracos (obtenc~ao do display, sincronizac~ao da renderizac~ao, etc), cando entre o OpenGL ES e o sistema operacional nativo. Essa interface se encontra no pacote javax.microedition.khronos.egl. Um exemplo de utilizac~ao da OpenGL ES pode ser encontrado no toolkit de desenvolvimento de Midlets da Sun (Sun Java Wireless Toolkit 2.5.2 for CLDC [1]): OpenGLESDemo (gura 6). A seguir e mostrado codigo OpenGl ES referente a gura 6. private void drawscene() { // Make the context current on this thread egl.eglmakecurrent(egldisplay, eglwindowsurface, eglwindowsurface, eglcontext); // Perform setup and clear background using GL egl.eglwaitnative(egl10.egl_core_native_engine, g); updatestate(width, height); gl.glclear(gl10.gl_color_buffer_bit GL10.GL_DEPTH_BUFFER_BIT); gl.glfinish(); // Wait for GL to complete egl.eglwaitgl(); // Draw a green square using MIDP g.setcolor(0, 255, 0); g.fillrect(20, 20, width - 40, height - 40); // Draw the scene using GL egl.eglwaitnative(egl10.egl_core_native_engine, g); gl.glmatrixmode(gl10.gl_modelview); gl.glloadidentity(); 15

gl.gltranslatef(0.f, 0.f, -30.f); gl.glrotatef((float)(time * 29.77f), 1.0f, 2.0f, 0.0f); gl.glrotatef((float)(time * 22.311f), -0.1f, 0.0f, -5.0f); gl.glvertexpointer(3, GL10.GL_BYTE, 0, cubevertices); gl.glcolorpointer(4, GL10.GL_UNSIGNED_BYTE, 0, cubecolors); gl.glnormalpointer(gl10.gl_byte, 0, cubenormals); gl.gldrawelements(gl10.gl_triangles, 6 * 6, GL10.GL_UNSIGNED_BYTE, cubeindices); gl.glfinish(); time += 0.1f; egl.eglwaitgl(); // Release the context egl.eglmakecurrent(egldisplay, EGL10.EGL_NO_SURFACE, EGL10.EGL_NO_SURFACE, EGL10.EGL_NO_CONTEXT); // Draw a red square using MIDP g.setcolor(255, 0, 0); g.fillrect((width / 2) - 25, (height / 2) - 25, 50, 50); } 4 Conclus~ao A API JSR-184 conseguiu combinar a facilidade de desenvolvimento da linguagem Java para o de aplicac~oes gracas, mesmo tendo como foco dispositivos moveis, que possuem poucos recursos de hardware e, consequentemente, deveriam exigir maiores otimizac~oes e conhecimento do programador. O amplo conjunto de classes disponvel torna simples o desenvolvimento de aplicac~oes complexas e abre caminho para o surgimento de novas aplicac~oes para o mercado de dispositivos moveis. O OpenGL ES tambem oferece uma otima biblioteca para os desenvolvedores acostumados com a programac~ao em OpenGL. Apesar de ser uma boa opc~ao, a biblioteca OpenGL ES ainda n~ao e disponibilizada em tantos dispositivos quanto a API Mobile 3D. Ambas bibliotecas disponibilizam recursos para desenvolvedores que buscam novos desaos para as aplicac~oes tridimensionais. Esta monograa apresenta uma breve descric~ao dos topicos mais relevantes destas APIs, porem podem ser encontradas mais informac~oes nas especi- cac~oes das bibliotecas. 16

Refer^encias [1] Sun Java Wireless Toolkit for CLDC - http://java.sun.com/products/sjwtoolkit/download.html - Visitado em 18/04/2008 [2] JSR 184: Mobile 3D graphics API for J2ME - http://jcp.org/en/jsr/detail?id=184 - Visitado em 18/04/2008 [3] Getting Started With the Mobile 3D Graphics API for J2ME - http://developers.sun.com/mobility/apis/articles/3dgraphics/ - Visitado em 18/04/2008 [4] JSR-139 Connected Limited Device Conguration 1.1 - http://jcp.org/aboutjava/communityprocess/nal/jsr139/index.html - Visitado em 18/04/2008 [5] Mobile Information Device Prole (MIDP) - http://java.sun.com/products/midp/ - Visitado em 18/04/2008 [6] JSR 239: JavaTM Binding for the OpenGL ES API - http://jcp.org/en/jsr/detail?id=239 - Visitado 18/04/2008 [7] Khronos Group - http://www.khronos.org/opengles/ - Visitado em 18/04/2008 [8] "Developing Mobile 3D Applications with OpenGL ES and M3G"{ SIG- GRAPH 2005 course - http://people.csail.mit.edu/kapu/siggraph course/ - Visitado em 18/04/2008 [9] Wikipedia Mobile 3D Graphics API - http://en.wikipedia.org/wiki/m3g - Visitado em 18/04/2008 [10] Wikipedia OpenGL ES - http://en.wikipedia.org/wiki/opengl ES - Visitado em 18/04/2008 17