ELO 329: Diseño y Programación Orientada a Objetos
Proyecto Grupal
Utilización de LWJGL para Java 3D

Integrantes: Carlos Ibáñez, Gabriel Juri, Andrés Medina, Lukas Pérez

Definición del Proyecto: La siguiente aplicación es una extensión de la librería de creación de juegos Light Weight Java Game Library (LWJGL) sobre la cual se ha creado un espacio de simulación sobre la cual el usuario pueda crear naves y ellas puedan bajo su propia inteligencia artificial básica, buscar y destruir a las naves rivales.

Se genera un entorno gráfico 3D con manejo de cámara para poder apreciar la acción de diferentes puntos de vista.

La idea principal del proyecto es probar y demostrar las capacidades que ofrece la plataforma java para la creación de juegos no necesariamente básicos.

 

Desarrollo:

  El desarrollo del proyecto se separó en Simulación y motor3D. la cual cada solución debía incluir.
Simulación.

La solución del motor 3D debía incluir:

Análisis:

Casos de uso:

Caso1:

Nombre: Crear naves en la batalla espacial.

Descripción:  El sistema permite al usuario, agregar naves en un espacio vacío del campo de batalla por medio de un click sobre       este.

Secuencia Normal:

1) Programa es abierto.

2) Usuario hace click en la ventana 2D (en un espacio vacío del campo de batalla).

3) El listener del mouse escucha el click.

4) Se crea un objeto nave en el espacio, el cual es visualizable.

5) El objeto comienza a moverse en busca de naves enemigas

Secuencia Alternativa:

2A1) Usuario hace click en la ventana 2D (en un lugar ocupado por otra nave).

3A1) La aplicación detecta esto y elimina ambas naves.

 

Caso2:

Nombre: Movimiento en campo de batalla 3D.

Descripción:  El sistema permite al usuario, moverse libremente en el campo de batalla 3D utilizando los controles del teclado. Los controles permitidos son los de desplazamiento y rotación y están dados por las teclas A,W,S,D, FLECHA ARRIBA, FLECHA ABAJO, FLECHA IZQUIERDA Y FLECHA DERECHA.

Secuencia Normal:

1) Programa es abierto.

2) Usuario selecciona la ventana 3D.

3) Usuario presiona alguna de las teclas de desplazamiento o rotación.

4) El sistema detecta la tecla presionada por el usuario.

5) El sistema realiza los cambios en los sistemas coordenados según lo requiera la acción hecha por el usuario.

Secuencia Alternativa: 

3A1) Usuario presiona una tecla que distinta a las definidas previamente como controles permitidos.

4A1) El sistema no detecta la tecla presionada por el usuario por lo que no realiza ninguna acción.

 

Diagramas:

-          Diagrama de Secuencia :                                                                  - Diagrama de  clases:                                                           - Diagrama de Estado

                                                                       

 

Prueba:

Problemas al compilar


Las 2 problemáticas principales al momento de generar el makefile fueron las de linkear las librerías externas y hacer que compile bien. La solución para esto fue colocar los packetes respectivos en directorios específicos y ordenadamente, dado que en el caso contrario, el proyecto no compilaría.

Dificultades de la parte de simulación:

El programa se ralentizaba mucho dado a que las balas al salir de los límites de World no eran eliminada. Se solucionó aplicando su destrucción al salir de los límites.

Se encontró una dificultad de diseño ya que se requería definir movimientos completos y fluidos a partir de movimientos pequeños de la nave*. La solución a esto fue la de generar un enum con los movimientos, uno de estos valores se llama "FREE" y solo cuando la nave estaba con este estado de movimiento, entonces el estado de comportamiento podía cambiar. Caso contrario, la nave estaría completando un movimiento como "FORWARD" que se mueve 10 unidades  hacia la dirección a la que apunta.

*Con nave se hace referencia a SElement.

Se encontraron dificultades al momento de diseñar la inteligencia al chocar contra la pared. Se decidió que  la nave simplemente "choca" contra la pared. Lo que en términos de objetos se traduce que el objeto World llama al método stop() de la nave (único método que cambia el estado de la nave sin importar el movimiento que esté realizando). La otra alternativa era que el objeto sensor detectara que estaba en frente de una pared, pero se detectó tarde esta alternativa.

Dificultades presentes en la ejecución del programa:

Entre los requisitos mínimos para el correcto funcionamiento está el hecho de poseer instalado OpenGL, como también los drivers necesarios para el correcto funcionamiento del hardware de video en el PC donde se correrá el programa. Se presentaron una serie de errores derivados a no tener este tipo de elementos instalados en el PC donde se realizaron las pruebas. Una vez configurado correctamente el equipo, las dificultades desaparecieron.

Dificultades en el motor3D

Comprensión de Conceptos3D


Debo agradecer los cursos de procesamiento digital de imagen y de video del profesor Marcos Zuñiga. Ya que hubo muchos conceptos explicados, como proyectivas, que  guiaron en todos elementos necesarios para cumplir el proyecto.

Comprensión del frame de OpenGl


La comprensión del frame3D no fue fácil, se tuvo que implementar cada concepto3D. Y para cado uno de ellos tuvo su estudio previo y sus problemas. Como:

Finalmente, se solucionaron muchos de estos problemas al usar una librería llamada GLApp. La cual incluía un mejor manejo sobre todo lo mencionando.

Montar modelos 3D


Un gran salto fue el uso de modelos3D usando Mesh. Este problema se solucionó ya que GlApp incluía un script que cargaba Mesh, que son un conjunto de indicaciones para crear un polígono, y los montaba en una dirección en la tarjeta de video.

Mesh


Al tener una poderosa herramienta, el montaje de Mesh. Entro un nuevo problema. ¿Cómo Creo Mesh?
La solución fue el uso del poderoso editor 3D, Maya. Se tuvo que aprender de Modelación. El cual abarco la creación de polígonos y su editación, para finalmente terminar con su textura y planos UV. Luego entro el dilema de como exportar los polígonos creados a java, La solución fue la creación de *.obj, la cual no viene por defecto en maya.
Al traspasar el Mesh a java, se creo un gran Bloque Negro. Investigando se comprendió que un Mesh no solo era compuesto por un .obj, sino también por un archivo .mtl que contiene toda la información de los materiales y sus texturas. Maya por defecto me entregaba el mesh con un material que absorbía toda la luz, simulando un cuerpo negro. La solución fue editar sus atributos, los cuales estaban ordenados de la forma RGB y con abreviaciones

Estudio de rotaciones.


Hay un concepto que tuve que comprender que los objetos que yo deseaba mostrar no podían ser representados como Puntos, Sino como planos 3D. Ha base de un estudio de rotaciones en distintos ejes y uso de angulos de Euler. Citas
http://inside.mines.edu/~gmurray/ArbitraryAxisRotation/
http://www.gregslabaugh.name/publications/euler.pdf

Ensamblaje.


El único problema al ensamblar es que el motor3D funciona como hebra, por lo tanto se tubo que modificar un poco la Simulación para que trabajara de forma atómica.





Código:

Codigos del Proyecto

Presentacion

 

 

Desea saber más?

http://lwjgl.org/

http://potatoland.org/code/gl/