Tecnologias de Jogosde Vídeo

Abel J. P. Gomes & Gonçalo Amador

LAB. 2

Departamento de InformáticaUniversidade da Beira Interior

Portugal2013

Copyright 2009-2013 All rights reserved.

LAB. 2

GESTÃO DE CENAS1. Objetivos2. Conceitos3. Exercícios teóricos e de programação4. Trabalho futuro

Lab. 2

GESTÃO DE CENAS 3D

Nesta lição prático-laboratorial aprender-se-á como manipular e gerir o grafode cenas 3D do sub-motor gráfico (“graphics engine”) do motor de jogosJMOGE. Para facilitar a aprendizagem todas as classes que constituem o sub-motor encontram num projeto aparte, e todas as alterações a realizar a estedeverão ser adicionadas (NÃO SUBSTITUIR CLASSES NO MOTOR!) ao motorJMOGE.

1. Objetivos específicos de aprendizagem

Terminada esta ficha de trabalho, o aluno deve saber e ser capaz de:

1. Identificar quais as classes especificas do JMOGE referentes à gestãode cena e as suas finalidades.

2. Adicionar ou remover objetos do grafo de cena, i.e., jogadores,obstáculos, etc.

3. Alterar objetos que fazem parte do grafo de cena, i.e., o chão e acaixa delimitadora do mundo.

4. Adicionar objetos distintos com texturas distintas.

5. Adicionar câmaras distintas, i.e., na terceira pessoa, na primeirapessoa, vista em perspetiva e vista de cima em 2D.

6. Controlar o avatar de um jogador via rato e teclado.

2. Grafo de Cena

O grafo de cena do motor gráfico do JMOGE é uma árvore de dois níveis, comose ilustra na Fig.1:

Na raiz da árvore da Fig. 1 encontra-se a cena que corresponde à classe scene.java.A cena contém um nó de transformação (TransformNode) referente a ela própria,root node. Os jogadores, obstáculos e as balas presentes na cena estãoarmazenados em duas tabelas de hash e numa lista de nós de transformação,respetivamente. Cada nó de transformação da cena, com exceção do root node, temassociada uma malha de polígonos. A cena tem ainda associados dois nós detransformação individuais, um para a caixa que representa os limites da cena(SkyBox) e um nó que representa o chão da cena (Floor).

Figure 1: Grafo de Cena do JMOGE.

Na raiz da árvore da Fig. 1 encontra-se a cena que corresponde à classescene.java. A cena contém um nó de transformação (TransformNode)referente a ela própria. Os jogadores, obstáculos e as balas presentes na cenaestão armazenados numa tabela de hash e em duas listas de nós detransformação, respetivamente. Cada nó de transformação da cena, comexceção do nó que representa a própria cena, tem associada uma malha detriângulos ou, mais geralmente, uma malha de polígonos. A cena tem aindaassociados dois nós de transformação individuais, um para a caixa querepresenta os limites da cena (SkyBox) e um nó que representa o chão dacena (Floor).

Diga-se desde já que cada jogador, cada obstáculo e cada bala presente nacena têm associada uma “bounding box”. No entanto, o conceito de “boundingbox” será abordado mais tarde com a profundidade devida numa outra ficha,mais concretamente aquela referente à temática de deteção de colisões. Nãoobstante a “bounding box” é geometria, ainda que auxiliar para uso nadeteção de colisões.

Na Fig. 2, como se assinala com uma elipse vermelha, estão indicadas asclasses que dizem respeito ao grafo de cena, que aparece incluído no móduloreferente à geometria.

Figure 2: As classes do grafo de cena do JMOGE.

O observador mais atento irá reparar em diretorias adicionais na diretoriageometry, de referir, generators e generators/parametricSurfaces. Asclasses relativas a estas diretorias, servem para gerar terrenos ou labirintos, epara (através de superfícies paramétricas) filtrar artifícios visuais nos terrenosgerados. A geração de terrenos e filtros bem como a geração de labirintosserão abordados em fichas pratico-laboratoriais futuras.

3. Texturas e COLLADA

Como se mostra na Fig. 3, todas as texturas do mundo ou dos modelosgeométricos encontram-se na diretoria data.

Figure 3: Modelos e texturas do JMOGE.

Mais propriamente, os modelos geométricos (no formato Collada 1.4.1) estãoguardados na sub-diretoria models. Para cada modelo as suas texturas (seeste as tiver) encontram-se na diretoria do mesmo, e.g., as texturas do modeloduck bem como o modelo encontram-se na diretoria,“imput\data\models\dae\duck”.

De referir que os modelos podiam ser noutro formato que não Collada, e.g.,OBJ, MD2, etc. No entanto tal carecia da adição de “parsers” que permitaminterpretar os dados noutros formatos para uma mesh. É importante aindareferir que os modelos Collada carregados não suportam animações, ainda queo formato as suporte. Ambas estas funcionalidades são possíveis melhorias arealizar no JMOGE.

Note-se que todas as texturas que tenham a palavra “world” nos seus nomessão tidas como tendo nomes fixos, pelo que se os nomes forem alterados nocódigo fonte do motor, então os nomes dos ficheiros respetivos terão tambémde ser alterados.

O carregar de modelos para o grafo de cena bem como a gestão deste é feitona classe GameMain.java no JMOGE ou na classe Main.java nos projetosdisponíveis para cada ficha prático-laboratorial. A classe GameMain.java noJMOGE é a classe onde a lógica de jogo, carregar de modelos, carregartexturas, etc deverá ser implementada. Os projetos referentes a cada fichaapenas pretendem facilitar a aprendizagem isolada de cada módulo do JMOGE.

4. Exercícios teóricos e de programação

Exercício 1. Na versão disponibilizada do projeto scenGraph o projeto ao correr não faránada, exceto mostrar uma janela em roxo e o número de frames por segundo,calculados via a classe FPSCounter.java. A razão prende-se com a nãoatualização da posição para onde a camera, inicializada na classe Main.java(GameMain.java no JMOGE), no método gameInit.

O primeiro exercício consiste em atualizar a posição de um jogador em funçãoda sua rotação e translação. As alterações a realizar serão feitas na classeKinematics.java, referente à cinemática de movimento. De forma aidentificar o que é necessário, nesta e futuras fichas prático-laboratoriais,deverá sempre consultar os “Action Items”, no Netbeans 7.2.1, apósselecionada uma classe qualquer do projeto a alterar, neste caso oscenGraph. Caso não tenha o botão essa opção deverá proceder a umconjunto de passos, como ilustrado na Fig. 4:

Figure 4: Ativar e consultar os “Action Items” no Netbeans 7.2.1.

E de seguida implementar a atualização de posição recorrendo a coordenadaspolares. Nos “TODOS: ….” referentes à classe Kinematics.java. Nesta e emfuturas fichas pratico-laboratoriais, os links e informações e dicas adicionaisencontram-se após cada um destes “TODOS: ….”. No caso particular dascoordenadas polares é importante lembrar que no sistema de eixos de GL em3D os eixos X, Y e Z correspondem respetivamente no sistema de eixoscartesiano em 3D aos eixos X, Z e Y. A atualização via coordenadas polaresencontra-se ilustrada na Fig. 5:

Figure 5: Atualização da posição no sistema de coordenadas polares.

É importante ter em conta que isto é somente a Fig. 5 apenas ilustra aatualização de coordenadas cartesianas no sistema de coordenadas polares.No entanto, isto carece de uma consideração sobre a velocidade do objeto,bala ou jogador, i.e., assume-se constante ou variável. Esta é a ultimaconsideração a ter em conta neste exercício. Após concluído este exercício, umboneco na terceira pessoa deve ser carregado como ilustrado na Fig. 6:

Figure 6: Atualização da posição no sistema de coordenadas polares.

Exercício 2. Se tentar controlar o boneco com o rato e teclado no entanto nada acontece, amenos que a tecla W seja premida. Falta então utilizar o gestor de input deperiféricos, já criado e inicializado. Primeiramente procure por ocorrências doobjeto “mouseKeyBoardHandler”, na classe Main.java. De seguida énecessário atualizar a rotação (via rato) e translação do jogador via (teclado).Siga as instruções dos últimos 2 “TODOS: …”, da classe Main.java. Apósconcluir este exercício o boneco deverá rodas via rato e transladar via asteclas W, A, S e D.

Exercício 3. O avatar atualmente controlado pelo jogador sente-se sozinho, neste mundovirtual. De forma a resolver a solidão do avatar, vamos carregar outrosmodelos para o grafo de cena. Antes de realizar esta tarefa é importantemencionar que todos os modelos e texturas já foram carregados. Basta apenasclonar essa informação para um novo objeto do tipo jogador. Para adicionar 2novos jogadores é necessário com algumas alterações repetir o processorealizado para adicionar o jogador principal. Na classe Main.java siga asinstruções dos primeiros 2 “TODOS: …”. Note que o jogador principal éadicionado imediatamente antes do jogador 2 com exceção dos objetos novos,já facultados, o processo é semelhante. Se o exercício for concluído comsucesso existem dois novos objetos na cena. Rode o jogador principal eencontre-os.

Exercício 4. Vamos agora alterar ou remover os limites da cena. Para tal basta comentar nasecção de código no método initGame da classe principal do motor/jogoGameRenderer.java:

1. scene.setFloor(floor);2. …3. scene.setSkyBox(skyBox);

Seguidamente vamos correr o jogo/motor. O código neste mesmo método queprecede estas chamadas inicializa o chão ou os limites do mundo, i.e., associaa informação da geometria a elementos das texturas, carrega texturas, etc.Estas chamadas apenas incluem o skybox e o chão na cena.

Agora descomente o código comentado previamente, e substitua a chamada(assumindo que no início da classe GameRenderer, stupidGame edukeBeanEm estão a false e spaceGame está a true):

1. skyBox = Scene.buildSkyBox(size/5, "/data/textures/World_5/SkyBox2");

Por uma das seguintes opções, cujas texturas estão na diretoria data:

1. skyBox = Scene.buildSkyBox(size/5, "/input/data/textures/World_5/SkyBox2");2. skyBox = Scene.buildSkyBox(size/5, "/input/data/textures/World_3/SkyBox2");3. skyBox = Scene.buildSkyBox(size/5, "/input/data/textures/World_1/SkyBox2");

Exercício 5. Vamos agora alterar o tipo de câmara utilizado. Na classe Camera.java,consulte os valores que CameraType pode tomar. De seguida na classeMain.java, no método gameInit, altere o tipo de câmara, na seguinte linhade código:

1. scene.addCamera(new Camera(size, playerId, Camera.CameraType.THIRD_PERSON));

Exercício 6. Repetir todas as alterações, dos exercícios 1 ao 4, no projeto do JMOGE. Todosos “TODOS: …” de um projeto de uma ficha pratico-laboratorial encontram-seno JMOGE com o mesmo identificador, neste caso “TODO: (SceneGraph)...”.É de salientar que fazer copy paste dos ficheiros é má ideia pois existemclasses já adaptadas no JMOGE para fichas futuras, e.g., scene.java. Após re--implementar todos os exercícios no JMOGE, teste o motor com e semargumentos.

Exercício 7. Vamos agora avaliar os conhecimentos adquiridos com algumas questõesteóricas:

1. Porque razão os modelos são carregados todos somente 1 vez paracada modelo existente, e clonados para cada novo jogador?

2. Porque razão é que os modelos dos jogadores 2 e 3 estão,acidentalmente, a vermelho?

3. Porque razão existem estruturas de dados para objetos, jogadores,Skybox e chão?

4. Tudo presente no grafo de cena é desenhado visível ou não. Existealguma otimização aparente que lhe parece ser possivel recorrendo aografo de cena? Se sim qual?

5. Porque razão é na classe mesh.java utilizado o método glDrawArrayspara desenhar múltiplos triângulos de uma só vez e não o desenho decada triângulo um a um (como ensinado na cadeira de computaçãográfica).

5. Trabalho futuro

Se o aluno tiver um projeto de “culling” ou sombras neste momento podecomeçar a a debruçar-se sobre o dito projeto. O aluno deverá provavelmentenecessitar de alterar o método render na classe scene.java, e ainda ométodo renderGeometryNode das classes mesh.java e/outransformGroup.java.

Além dos projetos existem diversas expansões ao JMOGE que findada estaficha podem ser alvo de estudo, algumas a titulo de sugestão:

1 - Possibilitar a um avatar realizar rotação e translação nos eixos X, Y e Z, aoinvés de somente sobre o plano XZ. Para implementar tal funcionalidade serianecessário implementar a atualização de posição através de coordenascilíndricas ou esféricas. E talvez alterar algo na classetransformGroup.java. , nos métodos responsáveis pela atualização darotação e translação.

2 – Adicionar suporte para outros dispositivos de E/S que não o rato e oteclado, e.g., GamePad, WiiMote, Kinect, etc. As classes para cada novodispositivo deverão ser colocadas no JMOGE na directoria “input/devices/” eimplementar o interface Input.java.

3 - Permitir o carregar de modelos em formatos que não Collada. Isto resume-se a escrever um parser para cada formato adicional. Que estenda as classesabstratas na diretoria “input/data/formats”. Para cada novo formato adicionaruma diretoria, e.g., para OBJ “input/data/formats/obj”, e implementar ai oparser para o formato. Uma alteração ainda mais significativa seria suportaranimações nos formatos que as suportam, e.g., MD2 ou Collada. De referir,que animação pode ser via distintas técnicas, e.g., animação por esqueleto ouvia key-frames.