Tecnologias de Jogos de Vídeo

Transcrição

1 Tecnologias de Jogos de Vídeo Abel J. P. Gomes & Gonçalo Amador LAB. 2 Departamento de Informática Universidade da Beira Interior Portugal 2013 Copyright All rights reserved.

2 1. Objetivos 2. Conceitos 3. Exercícios teóricos e de programação 4. Trabalho futuro LAB. 2 GESTÃO DE CENAS

3 Lab. 2 GESTÃO DE CENAS 3D Nesta lição prático-laboratorial aprender-se-á como manipular e gerir o grafo de cenas 3D do sub-motor gráfico ( graphics engine ) do motor de jogos JMOGE. Para facilitar a aprendizagem todas as classes que constituem o submotor encontram num projeto aparte, e todas as alterações a realizar a este deverão ser adicionadas (NÃO SUBSTITUIR CLASSES NO MOTOR!) ao motor JMOGE. 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ão de 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 a caixa delimitadora do mundo. 4. Adicionar objetos distintos com texturas distintas. 5. Adicionar câmaras distintas, i.e., na terceira pessoa, na primeira pessoa, 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, como se 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ão armazenados 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, tem associada uma malha de polígonos. A cena tem ainda associados dois nós de transformação individuais, um para a caixa que representa os limites da cena (SkyBox) e um nó que representa o chão da cena (Floor).

4 Figure 1: Grafo de Cena do JMOGE. 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. Os jogadores, obstáculos e as balas presentes na cena estão armazenados numa tabela de hash e em duas listas de nós de transformação, respetivamente. Cada nó de transformação da cena, com exceção do nó que representa a própria cena, tem associada uma malha de triângulos ou, mais geralmente, uma malha de polígonos. A cena tem ainda associados dois nós de transformação individuais, um para a caixa que representa os limites da cena (SkyBox) e um nó que representa o chão da cena (Floor). Diga-se desde já que cada jogador, cada obstáculo e cada bala presente na cena têm associada uma bounding box. No entanto, o conceito de bounding box será abordado mais tarde com a profundidade devida numa outra ficha, mais concretamente aquela referente à temática de deteção de colisões. Não obstante a bounding box é geometria, ainda que auxiliar para uso na deteção de colisões. Na Fig. 2, como se assinala com uma elipse vermelha, estão indicadas as classes que dizem respeito ao grafo de cena, que aparece incluído no módulo referente à geometria.

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

6 O observador mais atento irá reparar em diretorias adicionais na diretoria geometry, de referir, generators e generators/parametricsurfaces. As classes relativas a estas diretorias, servem para gerar terrenos ou labirintos, e para (através de superfícies paramétricas) filtrar artifícios visuais nos terrenos gerados. A geração de terrenos e filtros bem como a geração de labirintos serão abordados em fichas pratico-laboratoriais futuras. 3. Texturas e COLLADA Como se mostra na Fig. 3, todas as texturas do mundo ou dos modelos geométricos encontram-se na diretoria data. Figure 3: Modelos e texturas do JMOGE.

7 Mais propriamente, os modelos geométricos (no formato Collada 1.4.1) estão guardados na sub-diretoria models. Para cada modelo as suas texturas (se este as tiver) encontram-se na diretoria do mesmo, e.g., as texturas do modelo duck 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 permitam interpretar os dados noutros formatos para uma mesh. É importante ainda referir que os modelos Collada carregados não suportam animações, ainda que o formato as suporte. Ambas estas funcionalidades são possíveis melhorias a realizar no JMOGE. Note-se que todas as texturas que tenham a palavra world nos seus nomes são tidas como tendo nomes fixos, pelo que se os nomes forem alterados no código fonte do motor, então os nomes dos ficheiros respetivos terão também de ser alterados. O carregar de modelos para o grafo de cena bem como a gestão deste é feito na classe GameMain.java no JMOGE ou na classe Main.java nos projetos disponíveis para cada ficha prático-laboratorial. A classe GameMain.java no JMOGE é a classe onde a lógica de jogo, carregar de modelos, carregar texturas, etc deverá ser implementada. Os projetos referentes a cada ficha apenas 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ão atualizaçã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ção da sua rotação e translação. As alterações a realizar serão feitas na classe Kinematics.java, referente à cinemática de movimento. De forma a identificar o que é necessário, nesta e futuras fichas prático-laboratoriais, deverá sempre consultar os Action Items, no Netbeans 7.2.1, após selecionada uma classe qualquer do projeto a alterar, neste caso o scengraph. Caso não tenha o botão essa opção deverá proceder a um conjunto de passos, como ilustrado na Fig. 4:

8 Figure 4: Ativar e consultar os Action Items no Netbeans E de seguida implementar a atualização de posição recorrendo a coordenadas polares. Nos TODOS:. referentes à classe Kinematics.java. Nesta e em futuras fichas pratico-laboratoriais, os links e informações e dicas adicionais encontram-se após cada um destes TODOS:.. No caso particular das coordenadas polares é importante lembrar que no sistema de eixos de GL em 3D os eixos X, Y e Z correspondem respetivamente no sistema de eixos cartesiano em 3D aos eixos X, Z e Y. A atualização via coordenadas polares encontra-se ilustrada na Fig. 5: Figure 5: Atualização da posição no sistema de coordenadas polares.

9 É importante ter em conta que isto é somente a Fig. 5 apenas ilustra a atualizaçã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 ultima consideração a ter em conta neste exercício. Após concluído este exercício, um boneco 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, a menos que a tecla W seja premida. Falta então utilizar o gestor de input de periféricos, já criado e inicializado. Primeiramente procure por ocorrências do objeto 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ós concluir este exercício o boneco deverá rodas via rato e transladar via as teclas W, A, S e D.

10 Exercício 3. O avatar atualmente controlado pelo jogador sente-se sozinho, neste mundo virtual. De forma a resolver a solidão do avatar, vamos carregar outros modelos para o grafo de cena. Antes de realizar esta tarefa é importante mencionar que todos os modelos e texturas já foram carregados. Basta apenas clonar essa informação para um novo objeto do tipo jogador. Para adicionar 2 novos jogadores é necessário com algumas alterações repetir o processo realizado para adicionar o jogador principal. Na classe Main.java siga as instruçõ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 com sucesso existem dois novos objetos na cena. Rode o jogador principal e encontre-os. Exercício 4. Vamos agora alterar ou remover os limites da cena. Para tal basta comentar na secção de código no método initgame da classe principal do motor/jogo GameRenderer.java: 1. scene.setfloor(floor); scene.setskybox(skybox); Seguidamente vamos correr o jogo/motor. O código neste mesmo método que precede estas chamadas inicializa o chão ou os limites do mundo, i.e., associa a 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 e dukebeanem 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 classe Main.java, no método gameinit, altere o tipo de câmara, na seguinte linha de código: 1. scene.addcamera(new Camera(size, playerid, Camera.CameraType.THIRD_PERSON));

11 Exercício 6. Repetir todas as alterações, dos exercícios 1 ao 4, no projeto do JMOGE. Todos os TODOS: de um projeto de uma ficha pratico-laboratorial encontram-se no JMOGE com o mesmo identificador, neste caso TODO: (SceneGraph).... É de salientar que fazer copy paste dos ficheiros é má ideia pois existem classes 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 sem argumentos. Exercício 7. Vamos agora avaliar os conhecimentos adquiridos com algumas questões teóricas: 1. Porque razão os modelos são carregados todos somente 1 vez para cada 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. Existe alguma otimização aparente que lhe parece ser possivel recorrendo ao grafo de cena? Se sim qual? 5. Porque razão é na classe mesh.java utilizado o método gldrawarrays para desenhar múltiplos triângulos de uma só vez e não o desenho de cada triângulo um a um (como ensinado na cadeira de computação gráfica). 5. Trabalho futuro Se o aluno tiver um projeto de culling ou sombras neste momento pode começar a a debruçar-se sobre o dito projeto. O aluno deverá provavelmente necessitar de alterar o método render na classe scene.java, e ainda o método rendergeometrynode das classes mesh.java e/ou transformgroup.java. Além dos projetos existem diversas expansões ao JMOGE que findada esta ficha 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, ao invés de somente sobre o plano XZ. Para implementar tal funcionalidade seria necessário implementar a atualização de posição através de coordenas cilíndricas ou esféricas. E talvez alterar algo na classe transformgroup.java., nos métodos responsáveis pela atualização da rotação e translação.

12 2 Adicionar suporte para outros dispositivos de E/S que não o rato e o teclado, e.g., GamePad, WiiMote, Kinect, etc. As classes para cada novo dispositivo deverão ser colocadas no JMOGE na directoria input/devices/ e implementar o interface Input.java. 3 - Permitir o carregar de modelos em formatos que não Collada. Isto resumese a escrever um parser para cada formato adicional. Que estenda as classes abstratas na diretoria input/data/formats. Para cada novo formato adicionar uma diretoria, e.g., para OBJ input/data/formats/obj, e implementar ai o parser para o formato. Uma alteração ainda mais significativa seria suportar animaçõ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 ou via key-frames.