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:
Simulación.
- Uso de detector de colisiones. Se uso un modelo de colisión a base de mayas
- Modelo de estado para cada elemento.
- AI básica
- Interfaz con usuario
La solución del motor 3D debía incluir:
- Construcción de frame3D
- Construcción de mundo3D
- Uso de luces
- Maquetación de polígonos, uso de mesh
- Rotación y traslaciones en el mundo3D
Análisis:
Casos
de uso:
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:
- La creación del frame tiene varios atributos, uno de ellos es la profundidad del mundo 3D. Me llevo tiempo en entender porque un cubo, al Aplicar un render, su resultado era un cuadrado.
- Luces. Aparte del estudio de luces, la complejidad de este problema es que Lwjgl tiene muchas formas como definir una luz. La cual incluye sus atributos de luz difusa, ambiental y especular. Aparte su capacidad de emisión y que tipo de luz es. ¿Focal o direccional? Si es direccional, cuál es su dirección. También lwjgl te restringe el uso de luces, solo pueden existir 8 fuentes de luces. Aparte de todos esos problemas los comandos de luces no aceptan como argumento las primitivas de java, era necesario hacer float sin puntos flotantes.
- Las Primitivas de openGl también fueron un problema. Primero se trabajó con puntos, luego vértices y aristas. Esferas y finalmente de Polígonos. La creación de polígonos fue tediosa, ya que Lwjgl solo reconoce caras en una sola dirección.
- La creación de múltiples objetos también creo problemas. Ya que OpenGl recrea el mundo 3D con un puntero, el cual rota, traslada, escala, ect. Entonces muchas iteraciones dependían de acciones anteriores. Su solución fue el comando PushMatrix el cual crea un nuevo puntero con los atributos de su antecesor, que finalmente es desechado con PopMatrix.
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
- Ks Luz especulas
- Kd Luz Difusa
- Ka Luz Ambiental
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:
Desea saber más?