E80 PROYECTOS INFOMÁTICOS Memoria Técnica del Proyecto
Transcripción
E80 PROYECTOS INFOMÁTICOS Memoria Técnica del Proyecto
DEPARTAMENT D’INFORMÀTICA UNIVERSITAT JAUME I E80 PROYECTOS INFOMÁTICOS INGENIERÍA INFORMÁTICA Curso 2004--2005 Memoria Técnica del Proyecto SIMULADOR DE SOBRE-VUELOS 3D Proyecto presentado por el Alumno Ausiàs Josep Martínez Diranzo Dirigido por Michael Gould Carlson Castellón, a 1 de septiembre de 2005 RESUMEN En este trabajo se ha realizado un visualizador de vuelos en tres dimensiones. Esta aplicación intenta ofrecer al usuario, de una forma sencilla e intuitiva, la posibilidad de crear escenarios virtuales a partir de datos geográficos en dos dimensiones. PALABRAS CLAVE SIG, SIMULADOR, VUELO, 3D, GEOMIPMAPPING 3 ÍNDICE 1. Introducción general. .................................................................................. 7 1.1. Objetivos y motivación del proyecto. ................................................ 7 1.2. Descripción del entorno general del proyecto. ................................... 7 2. Descripción del proyecto. ........................................................................... 9 2.1. Introducción al problema a resolver................................................... 9 2.2. Descripción técnica del proceso del proyecto .................................... 19 2.2.1. Información inicial................................................................. 19 2.2.2. Estimación de recursos. ......................................................... 20 2.2.3. Planificación de tareas y temporal.......................................... 21 2.2.4. Seguimiento y control del proyecto. ....................................... 22 2.2.5. Procesos y actividades intermedios. ....................................... 23 2.2.6. Resultado final....................................................................... 26 2.2.7. Aplicación práctica. ............................................................... 31 3. Conclusiones. ............................................................................................. 35 4. Posibles extensiones del proyecto. .............................................................. 37 5. Bibliografía................................................................................................. 43 6. Anexos. ...................................................................................................... 45 5 1. Introducción general. 1.1. Objetivos y motivación del proyecto. Cada vez es más frecuente el uso de los SIG (Sistemas de Información Geográfica), en todos los ámbitos, desde el uso doméstico de calcular la ruta óptima de un viaje, hasta las más avanzadas técnicas de ingeniería civil. No obstante, la mayoría de los SIG actuales se basan en tecnología 2D de superposición de capas y se tiende a usar entornos tridimensionales, cada vez más. Así, el objetivo de este proyecto, es realizar un sobrevuelo en tres dimensiones sobre un entorno virtual, a partir de las altitudes de una zona geográfica determinada, aprovechando al máximo las prestaciones de las modernas aceleradoras gráficas y la posibilidad que el usuario añada sus propios datos del terreno. El entorno deberá ser interactivo, es decir, que el usuario podrá volar libremente por la escena recreada, de una manera sencilla e intuitiva. Los entornos simulados podrán tener dimensiones considerables; así pues, con el fin de crear un entorno ágil y amigable en una máquina doméstica, el programa realizado tendrá que minimizar el coste computacional de los polígonos necesarios. 1.2. Descripción del entorno general del proyecto. La visualización avanzada de gráficos por imagen de síntesis, tiene cada vez mayores capacidades, debido a los avances en la tecnología hardware y en el software. La industria del cine, la arquitectura, el diseño industrial, etc. hacen uso intensivo de estas técnicas, cada vez con resultados más reales y complejos. El campo de la geociencia no evoluciona a la misma velocidad. Es difícil ver representaciones de terrenos 3D de alta calidad, es decir, representaciones virtuales de proyectos arquitectónicos no construidos, que se confundan, o se parezcan mucho, a la realidad. La mayor parte de las veces lo que se ve son ortoimágenes superpuestas sobre un modelo digital del terreno, lo cual no presenta un gran desafío desde el punto de vista metodológico. La mayor parte de las modernas herramientas SIG incorporan aplicaciones de visualización en tres dimensiones, pero estas funciones suelen ser muy básicas: perspectivas, efectos de niebla, posibilidad de crear diseños de vuelos animados sobre modelos digitales del terreno, etc. Estas aplicaciones acarrean grandes costes desde el punto de vista de su desarrollo a nivel de software, y los SIG las incluyen como algo accesorio, ya que el núcleo central de sus funciones debe de estar, lógicamente, en el análisis geográfico. Esta es la principal diferencia con respecto a otros campos: tendemos a usar para la visualización 3D las mismas herramientas que usamos para el análisis geográfico, y como ya hemos comentado, un SIG no está especializado en la visualización 3D. 7 Si queremos realizar simulaciones virtuales realmente buenas, que se confundan con la realidad o que se asemeje bastante a ella, debemos utilizar herramientas que manejen múltiples métodos de rendering, sombras, reflexiones especulares, texturas complejas, integración de luces... etc. Difícilmente vamos a encontrar esas funciones en un SIG, por caro que sea. La solución pasa por migrar los datos salidos de las herramientas SIG a una aplicación 3D especializada. En este proyecto, trataremos de implementar dicha aplicación. El objetivo de la visualización de terrenos es la creación de una parte de un mundo, real o ficticio, en una forma tridimensional interactiva. Este objetivo requiere la unión de varios campos: Diseño asistido por computador (CAD, Computer Aided Design), Sistemas de Información Geográfica (SIG), informática gráfica y topografía. La visualización digital del terreno tiene muchas y variadas aplicaciones, podemos destacar: • Turismo virtual (planificación de viajes). • Educación. • Urbanismo: uso de tierras, planificación urbanística. • Ingeniería civil, infraestructuras. • Visualización meteorológica y topología ambiental. • Diplomacia. • Aeronáutica. • Juegos y entretenimiento. • Uso militar. telecomunicaciones, servicios públicos y otras Éstos son sólo algunos de los numerosos usos de la visualización digital del terreno. A pesar de la disparidad de los campos de aplicación, todos ellos tienen una necesidad en común: poseer una herramienta potente que cree entornos virtuales para manejar eficientemente grandes cantidades de información. Como podemos intuir, cada uso tiene sus particularidades, así pues, una aplicación de ingeniería civil requerirá una gran resolución, y un juego 3D, una gran velocidad de ejecución. Estas exigencias suelen entrar en conflicto, por ejemplo, el manejo de enormes cantidades de datos, provoca la ralentización de la ejecución. Para subsanar estos conflictos se usan algoritmos (quadtree1, ROAM2, Geomipmapping3) que intentan llegar a un compromiso entre velocidad de ejecución y resolución. 1 Stefan Röttger http://wwwvis.informatik.uni-stuttgart.de/~roettger/data/Papers/TERRAIN.PDF Duchaineau, M. http://www.llnl.gov/graphics/ROAM 3 Willem H. de Boer, http://www.connectii.net/emersion 2 8 2. Descripción del proyecto. 2.1. Introducción al problema a resolver. Existen muy diversas formas de implementar un programa visualizador de vuelos, la más eficiente y comúnmente utilizada para su realización, se basa en la modelación de una red de polígonos. De esta forma, se pueden visualizar grandes zonas geográficas interactivamente. El principal problema es el gran número de polígonos que deben renderizarse por segundo, para conseguir una velocidad aceptable. En esta sección se tratarán éste y otros problemas relacionados, llegando a soluciones de compromiso. Empezamos con una red de polígonos que se extiende a lo largo de los ejes X y Z (figura 1), al no tener definidas las alturas de los puntos (coordenadas Y), tenemos una superficie plana. Podríamos relacionar esta monótona representación con un paisaje llano, pero incluso éstos suelen tener algún relieve. Figura 1: Red de polígonos sin alturas definidas. Con el fin de dar relieve a la representación, usaremos un mapa de alturas. En nuestro caso será una matriz de puntos con una resolución de 8 bits (256 niveles de grises). Esta imagen define las elevaciones del terreno a representar (figura 2); la posición del punto en la matriz define los valores de los ejes X y Z en la red de vértices, y su valor concreta la altitud del ángulo representado, es decir, el eje Y. Figura 2: Mapa de alturas. Al cargar el mapa de alturas sobre la red de vértices obtenemos una representación tridimensional del terreno. Como podemos observar en la figura 3, la escena se asemeja considerablemente al relieve de un paisaje real. Puede verse cómo las zonas más oscuras 9 del mapa de alturas se corresponden con las zonas deprimidas de la escena, y las más claras, con las elevadas. Cabe preguntarse si 8 bits de resolución son suficientes. Ésta definición nos permite distinguir entre 256 tonos de grises, que representarán las diferentes alturas. En un primer momento, podríamos pensar que esta resolución es insuficiente al haber montes de miles de metros, pero si lo consideramos con detenimiento, nos daremos cuenta de que no hace falta tener una resolución de un metro de altitud, con una resolución de 20 metros de altura, nos sobra con 256 tonos. Se podrían usar 16 bits, de esta manera conseguiríamos 65.536 niveles de grises, muchos más de los necesarios (el monte más alto del mundo, el Everest, mide 8.848 metros), además este derroche de memoria ralentizaría mucho la aplicación. Figura 3: Imagen creada a partir del mapa de alturas de la figura 2. Esta sencilla representación del terreno, usa una malla de polígonos estática: toda la zona tiene el mismo nivel de detalle, sea plana o abrupta, cercana o lejana. Por esta razón, la mayoría de las computadoras con altas prestaciones gráficas, tienen grandes dificultades en mostrar incluso terrenos de tamaño medio a una velocidad aceptable. Como podemos intuir, esta implementación derrocha gran cantidad de información al representar muchos polígonos inútiles, ya sea por estar muy lejos o tratarse de una zona plana. La solución más sencilla es reducir la complejidad de la escena, no obstante esto no es deseable. Para subsanar este problema, surgieron los algoritmos de nivel continuo de detalle CLOD (Continuous Level of Detail), que representan una malla dinámica de polígonos, y proporcionan triángulos extra en las zonas que requieren un mayor nivel de detalle. Los algoritmos CLOD requieren más investigación, son más complejos de implementar, y exigen más ciclos de CPU que los algoritmos de fuerza bruta. Entonces, ¿Por qué molestarnos con los algoritmos CLOD? Sencillamente, para crear simuladores de terreno más realistas, detallados y, sobretodo, más rápidos. El lema de los algoritmos CLOD es muy sencillo, e ilustra perfectamente su idea básica: “Mayor detalle es añadido cuando mayor detalle es necesitado”. Por ejemplo, si tenemos un terreno bastante llano (figura 4), necesitaremos menos resolución que en un terreno más accidentado (figura 5), éstos algoritmos proporcionarían triángulos extra a la segunda figura. 10 Figura 4: Terreno suave. Figura 5:Terreno más accidentado. Existen varios algoritmos CLOD, entre ellos podemos destacar los tres siguientes: • Algoritmo quadtree de Stefan Roettger. • Algoritmo ROAM (Real-time Optimally Adapting Meshes) de Mark Duchaineau. • Algoritmo geomipmapping de Willem H. Boer. EL ALGORITMO GEOMIPMAPPING. En nuestro proyecto hemos usado el algoritmo geomipmapping de Willem H. Boer, por tratarse de un método CLOD sencillo, que ahorra gran cantidad de trabajo a la GPU. Seguidamente pasamos a detallar este algoritmo. Para empezar, procuraremos que los polígonos más cercanos al observador sean los más detallados. A una cierta distancia, cambiaremos uniformemente a un nivel de detalle menor, y así sucesivamente conforme el paisaje sea más lejano. Esto hará que a mayor distancia respecto al observador, se tenga menor resolución, tal como ocurre en la realidad. En la figura 6, puede verse cómo las áreas cercanas a la posición del observador tienen un nivel de detalle (LOD) 0, el mayor nivel de definición. Cuando las áreas son un poco más lejanas, su nivel de detalle cambia a 1, que es el segundo nivel, y en las zonas más alejadas, el nivel cambia a 2, el más bajo representado en la imagen. Figura 6: Distintos niveles de resolución. 11 En la figura 7, se muestra la disposición original de los triángulos en el algoritmo geomipmapping. Si se usan buffers de vértices, las tiras de triángulos definen el camino a seguir para renderizar los parches. Sin embargo, como la implementación de buffers de vértices es muy dependiente del API (Application Programming Interface) usado, hemos optado por utilizar un modo inmediato de renderización, pues así resulta mucho más fácil convertirlo a la sintaxis de otros API. Utilizar un buffer de vértices para renderizar, proporciona un gran incremento de velocidad en algunas implementaciones de terreno, ya que reduce el overhead (coste estructural) presente cuando se envía cada vértice. Además, la mayoría de las tarjetas gráficas, prefieren que la información de los vértices les llegue en la forma del buffer de vértices, por lo tanto, se recomienda usar buffers de vértices para renderizar terrenos, alcanzando mayores velocidades. Figura 7: Disposición original de los triángulos según el nivel de resolución. Figura 8: Disposición de los triángulos utilizado según el nivel de resolución. De todos modos, la disposición de los polígonos mostrada en la figura 8, proporciona una gran ventaja: nos permite fácilmente renderizar un vértice cuando se necesita, situación bastante frecuente. Hasta ahora, los algoritmos CLOD no han presentado ningún problema, es en este momento cuando surge uno: el cracking (craqueo). Esto ocurre, en el caso del geomipmapping, cuando una zona con una alta resolución linda con una con menor resolución (figura 9). 12 Figura 9: Dos zonas contiguas con diferentes niveles de detalle. Como puede observase en la figura 10, este problema provoca enormes roturas y discontinuidades, no deseadas, en los terrenos de las escenas recreadas. Figura 10: Imagen de una escena sin soluciones anti-cracking. Existen dos formas de solucionar el cracking. La primera sería añadir vértices a la zona con menor nivel de detalle, no obstante, estos vértices podrían tener la misma altura que los de la zona con mayor detalle. Esta solución no parece la más idónea al tener que reordenar la zona. La otra solución, y la que nosotros hemos adoptado, ha sido omitir algunos de los vértices de la zona con más detalle (figura 11). Este procedimiento resuelve el cracking perfectamente, y sin esfuerzo. Figura 11: Eliminación del cracking mediante omisión de vértices. 13 Ya sabemos la causa del cracking, y cómo solucionarlo. Ahora, la cuestión es cuándo aplicar el método anti-cracking. La solución pasa por hacer un test a las zonas contiguas, cuando se está renderizando un área en concreto (figura 12). Si la zona vecinal tiene un nivel de detalle distinto, habrá que omitir algunos vértices. Figura 12: Zonas vecinas que deberán ser testadas. Por ejemplo, si la zona de la derecha tiene un nivel de detalle más bajo que la actual, entonces sólo se tendrán que omitir los vértices del extremo derecho de esta área (ver figura 13). Figura 13: Vértices a omitirse si la zona derecha tiene menor detalle. TEXTURAS. Una vez tenemos representado nuestro relieve mediante una malla, le hemos aplicado texturas que añaden veracidad a la escena. En nuestro caso, hemos generado una textura compleja a partir de varias muestras. Hemos usado el mapa de alturas para generar una textura que coincida con él. A cada uno de los píxeles de nuestro mapa de texturas, le hemos asociado una muestra en función de la altura. Será muy difícil que un píxel corresponda completamente con una textura, así que solemos combinar varias para crear la textura asociada a cada píxel (interpolando los valores de color RGB). En la figura 14, podemos observar una línea de presencia de textura; en función de la altura del píxel, se asociará una combinación de las muestras. 14 Figura 14: Línea de presencia de textura. Hemos creado una función que calcula el porcentaje de cada muestra por regiones. El caso trivial se da si la altura de la región es equivalente al valor óptimo, si es así, entonces la tesela actual tendrá el 100% de la textura de muestra y no tendremos que interpolar. En las siguientes figuras podemos ver las cuatro muestras empleadas. Figura 15: Zona baja. Figura 16: Zona mediabaja Figura 17: Zona media-alta. Figura 18: Zona alta. A continuación, para conseguir una mayor realismo de la textura sin derrochar recursos, le hemos añadido un mapa de detalles. Éste es una imagen en escala de grises, como el de la figura 19, que se repite muchas veces en el terreno, añadiendo matices como grietas, protuberancias, rocas y otros efectos que dan realismo a la escena. Figura 19: Ejemplo de un mapa de detalle. No ha supuesto un gran esfuerzo añadir un mapa de detalles a nuestra aplicación, ha sido suficiente con implementar dos funciones, una de carga, y una de descarga del mapa. Existen dos formas de aplicar los detalles: usar hardware de múltiple texturización, o simplemente hacer dos renderizaciones separadas. Debido a que la malla del terreno puede llegar a ser bastante grande, la mejor opción es utilizar hardware. No obstante, esta implementación depende de la tarjeta gráfica usada, por eso hemos optado por hacer dos 15 renderizaciones separadas. Para implementar el código, hemos puesto el color base en la primera renderización de la textura, y en la segunda añadimos el mapa de detalle. En las figuras 20 y 21, se hace una comparación de dos escenas, una sin mapa de detalles, y la otra él. Los resultados son mejores cuando se usa, como puede observarse. Figura 20: Textura sin detalles. Figura 21: Textura con detalles. ILUMINACIÓN. Como hemos visto, texturizar el terreno nos ha aportado mayor nivel de detalle, ahora la iluminación de la escena contribuirá a aumentar su nivel de veracidad. En una simulación, como en la realidad, la luz juega un papel determinante. El objetivo es conseguir iluminar nuestra escena lo más rápido posible y con el mayor nivel de credibilidad. Existen muy diversos y complejos algoritmos de iluminación global, cuyo estudio requerirían mucho tiempo y esfuerzo, superando en creces los recursos destinados al proyecto que nos ocupa. Podríamos optar por usar iluminación hardware, pero estas técnicas presentan dos grandes problemas: en primer lugar, son muy dependientes de la API, y en segundo lugar, son bastante ineficientes en la representación de las mallas dinámicas. Por todo ello, hemos usado una sencilla función que carga, o genera, un mapa de luz, utilizado en nuestra simulación. Los mapas de luz son similares a los de alturas, salvo que sólo contienen información sobre la iluminación. Podríamos optar por calcularlo en cada frame, pero es preferible calcularlo al inicio de la simulación y recalcularlo, cada vez que sea necesario. La función empleada nos permite escoger entre tres tipos de iluminación: luz basada por alturas, cargar un mapa de luz (previamente creado), y luz slope (en pendiente). La iluminación basada en alturas es simple y poco realista. Esta opción, hace que los vértices altos sean más luminosos que los bajos, es decir, la altura de un vértice indica su iluminación. La figura 22 ilustra gráficamente la dinámica de este método. En dicha figura, el vértice A debería ser casi negro, el vértice B un poco más claro y el C completamente iluminado. 16 Figura 22: Iluminación basada en altura. Como se puede ver en la figura 22, este método de iluminación hace que las áreas altas sean más luminosas, y las deprimidas sean más oscuras. Figura 23: Ejemplo de iluminación basada en alturas. El inconveniente de este algoritmo es su falta de realismo, no tiene en cuenta la posibilidad de que la luz ilumine directamente el suelo. Tal como se muestra en la figura 24, los puntos A y B deberían tener la misma luminosidad, posibilidad no contemplada en este algoritmo. Figura 24: Problema de la iluminación basada en alturas. 17 La función empleada también nos permite cargar un mapa de luz previamente creado. Para ello, hemos reutilizado parte del código empleado en la carga / descarga de los ficheros de alturas (teniendo en cuenta que la manipulación de la iluminación usa variables distintas). El mapa de iluminación también será guardado en un fichero RAW de escala de grises, y se manipulará de forma similar al de alturas. En las figuras 25, 26 y 27, podemos observar los mapas de luz correspondientes a las escenas de la figuras 28, 29 y 30 respectivamente. Figura 25: Mapa de luces 1. Figura 26: Mapa de luces 2. Figura 27: Mapa de luces 3. Figura 28: Escena con mapa de luces 1. Figura 29: Escena con mapa de luces 2. Figura 30: Escena con mapa de luces 3. Como se ilustra en las figuras anteriores, la luz de las escenas, es exactamente como la del mapa de luces asociado, debido a que éste define exactamente la iluminación de la escena. Se observa que las zonas más oscuras del mapa de luces son las más sombrías en la escena recreada, y las más claras, las que tienen mayor luminosidad. De esta forma, el usuario puede crear previamente los mapas de luz, pudiendo definir la iluminación deseada. Nuestra función nos proporciona una última técnica de iluminación: luz slope (en pendiente). Este método es muy simple, y proporciona resultados satisfactorios. Su técnica consiste en ensombrecer los vértices según su altura en relación con los vértices cercanos. Básicamente, se verifica si otros vértices cercanos ensombrecen al actual. Un ejemplo sería posicionarse enfrente de un gran edificio que esté impidiendo la llegada de la luz solar directa (figura 31), el edificio proyectaría una sombra sobre nosotros. 18 Figura 32: Ejemplo de iluminación en pendiente. Figura 31: Ejemplo de iluminación en pendiente. Como puede verse, los rayos de la fuente de luz no alcanzarán nuestra posición debido al gran edificio que los obstruye. El resultado final es que nos encontramos en una zona sombría. Este es el mismo concepto que intentamos obtener en la iluminación en pendiente: sombrear vértices a los que no llegan directamente la luz. En la figura 32, la fuente de luz emite rayos en todas las direcciones, pero en nuestro caso, ninguno alcanza al vértice B, ya que el vértice A está obstaculizándolos. Que un vértice no reciba luz directamente, no significa que esté completamente a oscuras; los vértices reflejan sobre los otros, parte de la luz que les llega, iluminándolos ligeramente. Por ello, este algoritmo tiene en cuenta esta iluminación indirecta. Cuando se calcula la iluminación de un vértice, el método resta la altura del vértice anterior (en la dirección especificada por el usuario), a la altura del actual; se intenta así calcular la sombra que se proyectará en el siguiente vértice. Con el fin de conseguir un mayor realismo en la escena final, hemos añadido los siguientes efectos: una representación del cielo, una simulación del agua, detección de colisión y una pérdida de visión. Estas ampliaciones no representan en sí, parte de un terreno, por ello las detallaremos en sucesivas secciones. 2.2. Descripción técnica del proceso del proyecto. 2.2.1. Información Inicial. La información geográfica utilizada ha sido datos de alturas topográficas. En nuestro caso, el formato de archivo elegido ha sido RAW (crudo, en inglés), porque es muy simple de usar. Este formato, contiene sólo datos puros, para facilitar la carga de datos de alturas. La resolución adoptada ha sido de 8 bits, permitiendo distinguir 256 niveles de grises, los cuales podrán representar el mismo número de alturas diferentes. Con esta definición se consigue un compromiso entre calidad de imagen y velocidad de ejecución. 19 2.2.2. Estimación de recursos. Los recursos estimados para acometer el desarrollo de la aplicación son los siguientes: • Recursos humanos: o Estudiante de quinto curso de ingeniería informática. o Director de proyecto, profesor en sistemas de información geográfica. • Recursos hardware: o Ordenador personal Pentium 4, con tarjeta gráfica aceleradora 3D, con un mínimo de 16 MB de memoria gráfica. o Conexión a Internet. • Recursos software: o Herramientas ofimáticas para la creación de toda la documentación relativa al proyecto. o Entorno de desarrollo de programación: Microsoft Visual Studio 6.0. o Mapas topográficos de la zona a recrear. o Programa de edición de imagen: Adobe Photoshop 7.0. o Visualizador de archivos PDF, Adobe Reader 7.0. o Visualizador de archivos DPR 1.0, Valenciano. • Instituto Cartográfico Recursos económicos: Innecesarios, al tratarse de un proyecto final de carrera. 20 2.2.3. Planificación de tareas y temporal. La realización del proyecto debería durar 150 horas, correspondientes a los 15 créditos de la asignatura E80. No obstante, se han excedido este número de horas. En el gráfico 1, queda detallada la distribución del tiempo en porcentajes: Planificación Temporal Preparación de la presentación 3,0% Redacción del proyecto 15,0% Análisis del trabajo a realizar 1,1% Búsqueda bibliográfica 3,0% Lectura de documentación 12,0% Instalación software 1,1% Tratamiento de mapas 3,0% Adaptación al nuevo software 3,0% Búsqueda de cartografía 1,8% Pruebas del software 9,0% Implementación 39,0% Diseño previo de la aplicación 9,0% Gráfico 1: Distribución temporal de las tareas. A continuación, se muestra un listado con la planificación inicial de las tareas a realizar, para llevar a cabo el proyecto, así como el calendario previsto. Id Nombre de la tarea Duració n Fecha inicio Fecha final 1 Análisis del trabajo a 2 horas realizar 01/11/2004 02/11/2004 2 Búsqueda bibliográfica 03/11/2004 05/11/2004 3 Lectura documentación 4 Instalación software 5 Adaptación software 6 Diseño previo aplicación 5 horas de 20 horas 06/11/2004 30/11/2004 al 2 horas 01/12/2004 02/12/2004 nuevo 5 horas 03/12/2004 04/12/2004 de --- Época de exámenes la 15 horas 05/12/2004 23/12/2004 ---------- 24/12/2005 25/02/2005 21 7 Implementación 65 horas 26/02/2005 14/04/2005 8 Pruebas del software 15 horas 15/04/2005 30/04/2005 9 Búsqueda de cartografía 3 horas 01/05/2005 03/05/2005 10 Tratamiento de mapas 5 horas 04/05/2005 07/05/2005 11 Redacción del proyecto 25 horas 08/05/2005 01/06/2005 --- Época de exámenes ---------- 02/06/2005 25/06/2005 12 Preparación presentación de la 5 horas 27/06/2005 01/07/2005 Tabla 1: Planificación temporal de las tareas. Como puede observarse, todas las tareas han sido realizadas de forma secuencial, al haber una única persona dedicada al desarrollo del proyecto. Si no se tratase de un proyecto final de carrera, podrían contratarse varias personas, de esta manera, se llevarían a cabo tareas en paralelo, lo cual permitiría reducir el coste temporal, a costa de incrementar el económico. 2.2.4. Seguimiento y control del proyecto. Conforme a la planificación inicial, el coste temporal es de 167 horas. Los costes económicos de la contratación de personal, compra de equipos informáticos y software se han omitido al tratarse de un proyecto final de carrera. A continuación puede verse un listado con el desarrollo real de las tareas del proyecto: Id Nombre de la tarea Duració n Fecha inicio Fecha final 1 Análisis del trabajo a 2 horas realizar 01/11/2004 02/11/2004 2 Búsqueda bibliográfica 03/11/2004 06/11/2004 3 Lectura documentación 4 Instalación software 5 Adaptación software 6 Diseño previo aplicación al 6 horas de 24 horas 07/11/2004 02/11/2004 2 horas 03/12/2004 05/12/2004 nuevo 6 horas 06/12/2004 10/12/2004 de la 16 horas 11/12/2004 28/12/2004 22 --- Época de exámenes ---------- 24/12/2005 25/02/2005 7 Implementación 72 horas 26/02/2005 19/04/2005 8 Pruebas del software 25 horas 20/04/2005 05/05/2005 9 Búsqueda de cartografía 3 horas 06/05/2005 07/05/2005 --- Época de exámenes ---------- 07/06/2005 25/06/2005 10 Tratamiento de mapas 7 horas 11 Redacción del proyecto 30 horas 01/07/2005 25/07/2005 12 Preparación presentación de la 5 horas 26/06/2005 30/06/2005 26/07/2005 28/07/2005 Tabla 2: Seguimiento temporal del proyecto. En el seguimiento del proyecto, se han producido retrasos en algunas de las tareas programadas. El coste temporal del proyecto es de 28 días más que el planificado inicialmente, con un número total de 198 horas, 31 más de las previstas. En el anexo se adjunta un diagrama Gantt, que ilustra gráficamente la planificación y el seguimiento temporal del proyecto. 2.2.5. Procesos y actividades intermedios. En esta sección se van a analizar las herramientas seleccionadas para el desarrollo de este proyecto (lenguajes, librerías, editores, etc), y los motivos de su elección. En la actualidad, hay muchas aplicaciones informáticas con funcionalidades parecidas, por ello y para escoger las que más se ajustan a los requerimientos del proyecto, hemos efectuado una selección. Veamos los objetivos más importantes que deberá cumplir nuestro simulador: • Interactividad: La aplicación deberá ser interactiva, permitiendo al usuario volar por todo el escenario recreado. • Velocidad de ejecución: Se intentará que la simulación se ejecute rápidamente, para conseguir que sea amigable al usuario. • Extensibilidad: El programa deberá poder ser ampliado en nuevas versiones. Con el fin de facilitar la extensibilidad se usarán herramientas de uso común. El código será accesible y se podrá modificar libremente, pudiendo agregar nuevas operaciones, que no se incluyen en la aplicación original. • Tratamiento de gráficos: Se necesitará usar funciones de librerías gráficas. 23 Teniendo en cuenta los requisitos, vamos a describir las herramientas que se han decidido utilizar, su historia y sus características más importantes. Lenguaje de programación C++. El C++ es un derivado del C. Este lenguaje apareció en la década de los 70 de la mano de Dennis Ritchie, para la programación en sistemas operativos UNIX. Surgió como un lenguaje generalista recomendado para programadores expertos, pues no llevaba implementadas muchas funciones que facilitan la comprensión de un lenguaje. Aunque esto, en un principio puede ser un problema, en la práctica es su mayor virtud, ya que permite al programador un mayor control sobre lo que está haciendo. A principios de los años ochenta, un programador llamado Bjarne Stroustrup, creó lo que se conoce como C++. Necesitaba ciertas facilidades de programación, incluidas en otros lenguajes pero no en C, como las clases y objetos, conceptos muy en boga en la programación actual. Para ello rediseñó el C, ampliando sus posibilidades pero manteniendo su mayor cualidad: permitir al programador en todo momento tener controlado lo que está haciendo, consiguiendo así una mayor rapidez que en los otros lenguajes. C++ es un lenguaje evolucionado de C cuya principal mejora es la programación orientada a objetos. Además, C++ incorpora estas otras mejoras: • Totalmente adaptado a la programación orientada a objetos. • Completa funcionalidad bajo plataformas UNIX y Windows. • Lenguaje de más bajo nivel que la mayoría de sus competidores. • Se adapta a la perfección con el resto de componentes seleccionados. Por estos motivos, C++ ha sido el lenguaje de programación elegido, y el entorno de desarrollo empleado el Microsoft Visual Studio C++. Librería gráfica OpenGL. Ha sido el elegido este estándar libre sobre gráficos por computadora, ampliamente conocido y utilizado. Seguidamente pasamos a detallar su historia y características. En 1982 nació en la Universidad de Stanford el concepto de graphics machine y fue utilizado por Silicon Graphics Corporation en su propia estación Silicon IRIS para crear un renderizador. Así nació la librería IRIS GL. A raíz de esto, en el año 1992, muchas empresas del hardware y software se pusieron de acuerdo para desarrollar conjuntamente una librería gráfica libre: OpenGL. Entre estas empresas destacaban Silicon Graphics Inc., Microsoft, IBM Corporation, Sun Microsystems, Digital Equipment Corporation (DEC), Hewlett-Packard Corporation, Intel e Intergraph Corporation. Así nació OpenGL (Open Graphics Library). La característica de ser abierta, significa que un programa escrito para una plataforma, puede ser fácilmente convertible a cualquier tipo de plataforma, obteniendo prácticamente los mismos resultados. Esta era la principal novedad, ya que liberaba a los programadores de tener que escribir programas para un hardware específico. Desde el punto de vista del programador, OpenGL es una API, para interactuar con dispositivos gráficos y aceleradoras 3D. Contiene cerca de 150 comandos que nos ayudan 24 a definir objetos, aplicar transformaciones a esos objetos, cambiar sus propiedades (color, textura, luz...), la posición de la cámara, etc. OpenGL es una librería gráfica, y por tanto, no posee funciones para el control de audio, red o control de entrada. OpenGL incorpora un gran número de funciones de gran utilidad en el manejo de gráficos, además: • Permite el tratamiento de imágenes. • Utiliza el hardware gráfico disponible en el sistema sobre el que trabaja. • Soporta un gran número de dispositivos gráficos. • Se adapta perfectamente a las otras herramientas seleccionadas. Microsoft Word 2000. Es el editor de textos de la suite ofimática Microsoft Office 2000, su gran difusión lo han convertido casi, en un estándar de hecho. Por este motivo, éste ha sido el editor de textos elegido para la realización de la documentación del proyecto. Microsoft Project 2000. Este programa, también asociado a la suite ofimática utilizada, es idóneo para la planificación de proyectos, facilitando el seguimiento de las escalas de tiempo y los recursos empleados. Por ello, hemos elegido esta aplicación en la planificación de las tareas y en la elaboración de los diagramas de Gantt asociados. Microsoft PowerPoint 2000. Esta aplicación, también forma parte de la suite ofimática empleada, además, es muy usada en la presentación de trabajos. Por ello, la hemos empleado para la elaboración de las diapositivas de la presentación del proyecto. Adobe Photoshop 7.0. Éste conocido programa de tratamiento de imagen, es uno de los más versátiles y potentes del mercado. Por estas propiedades, este programa ha sido empleado para preparar los mapas de las escenas a representar. Visualizador de Archivos DPR 1.0 del Instituto Cartográfico Valenciano. Este programa nos ha permitido visualizar los archivos de mapas en formato DPR disponibles libremente en la página web www.gva.es/icv/. Éstos datos nos han sido de gran utilidad para recrear las lugares deseados. La instalación de todas estas aplicaciones se ha llevado a cabo sin incidentes destacables. 25 2.2.6. Resultado final. Con todas las herramientas instaladas, y el tiempo y documentación necesarios, se ha conseguido implementar el visualizador de vuelos 3D. Esta aplicación es capaz de crear un escenario virtual que simula una zona geográfica, a partir de datos sobre el relieve de una zona. Además, permite al usuario navegar libremente por el sitio recreado. Con el fin de crear una escena más real se han añadido varios efectos: una capa de agua que recree el mar, una bóveda celeste, la detección de colisión con el terreno y una pérdida de visión por niebla. El AGUA. El planeta tierra, tiene la superficie cubierta por tres cuartas partes de agua, por lo tanto este elemento es protagonista de muchos paisajes. Veremos dos algoritmos de implementación del agua: uno sencillo y otro algo más complejo, pero mucho más real. El más sencillo consiste en cargar una textura con la imagen del agua sobre una red de vértices, y hacer que éstos suban y bajen regularmente una altura determinada. Nosotros, hemos usado la implementación un poco más compleja pero mucho más realista. Seguidamente pasamos a detallarla. Este algoritmo tiene varias fases y ciertos requerimientos: • Un buffer de vértices y normales: debido a que la malla del agua es dinámica, necesitamos acción de iluminación en tiempo real para conseguir mayor realismo. • Actualización en tiempo real de las normales de los vértices: de este modo, se consigue que la iluminación realista logre añadir más “profundidad” al agua. • Cálculos de vértices para crear una serie de olas y ondas realistas. • Generación automática de coordinación de textura para el mapa de reflejo del agua: así, el agua dará la sensación de estar reflejando su alrededor. Hemos empezado creando una malla muy teselada de polígonos. A continuación, le hemos aplicado un mapa de reflejo y manipulando los vértices de la malla, creamos una serie de olas. Una vez hecho esto, necesitamos usar hardware de luces para realzar el realismo del agua, así que generamos dinámicamente las normales de los vértices para la malla. Las coordenadas X y Z de la red permanecen constantes. Con el fin de crear las ondas del agua, hemos alterado sólo las coordenadas Y de la malla, esto nos introduce en una nueva tarea: alterar los valores Y del buffer de vértices para crear ondas y olas realistas. Ya hemos comentado dos tipos de buffers utilizados: el buffer de vértices y buffer de normales. Ahora, vamos a centrarnos en el buffer de fuerza; éste contiene toda la información sobre todas las fuerzas externas que actúan sobre un cierto ángulo, en el buffer de vértices. 26 Figura 33: Fuerzas de alrededor que actúan en el vértice Vc. La figura 33 muestra cómo calcular el valor de la fuerza que actúa sobre el vértice actual (Vc), asignándole la suma de las fuerzas de su alrededor. De esta forma las ondas se propagan tal y como se ilustra en la figura 34. Figura 34: Propagación de una onda. Cada frame será actualizado por el buffer de fuerza, que almacenará todas las fuerzas exteriores que actúan sobre cada uno de los vértices del agua. A cada vértice se le asignará la suma de las fuerzas que actúan a su alrededor (ocho vértices). Una vez aplicadas las fuerzas a los vértices, deberemos vaciar el buffer para que esté listo en el próximo frame, llenándolo con valores nuevos. EL CIELO. Un espacio abierto es impensable sin la presencia de cielo; éste, ya sea nublado o soleado, de día o de noche, es omnipresente en un entorno exterior. La forma más sencilla de recrearlo es coloreando el fondo de la pantalla de azul claro, pero esta forma es poco realista, ya que el cielo no es solamente azul. Una mejor manera de recrearlo, sería introducir la escena dentro de un cubo hueco (figura 35). 27 Figura 35: Patrón recortable de un cubo. Cada una de las caras interiores de dicho cubo serían texturizadas con imágenes del cielo (figura 36). Figura 36: Cubo desplegado con texturas del cielo. Las sky-boxes (cajas-cielo), ofrecen resultados convincentes, en función de la calidad de las texturas utilizadas, ya que las de baja calidad son muy visibles porque están ensanchadas a lo largo del polígono. Utilizar sky-boxes en entornos exteriores plantea algunos problemas; por ejemplo, si se utiliza niebla, pueden aparecer efectos no deseados en función de su configuración. Si la niebla está centrada en el observador, la caja-cielo puede llegar a apagarse. Otro efecto más inquietante, es que la niebla pueda acumularse en los vértices de la caja-cielo, y así desvelar sus polígonos. Estos efectos pueden ser reducidos modificando cuidadosamente los parámetros de la niebla, o subdividiendo cada una de las caras de la caja-cielo; pero esto podría afectar significativamente la representación. Esta implementación puede ser mejorada, así pues, nuestra idea básica ha sido la creación de una cúpula hueca que envuelve la escena. A este “techo” (ecuación 1), se le ha asignado internamente una textura que recrea el cielo deseado: soleado, nublado, diurno, nocturno, estrellado, etc. La ventaja de usar un sky-dome (cúpula celeste), para la representación de escenas al exterior, es el realismo que puede alcanzarse; además, la niebla consigue renderizarse más uniformemente. También permite, en tiempo de ejecución, cambiar individualmente el color de los vértices, permitiendo crear algunos efectos nuevos, como simular la luz del sol en diferentes momentos del día. 28 Ecuación 1: Ecuación utilizada que describe todos los puntos en una esfera 3D. Una esfera, como la definida por la ecuación 1, tiene infinitos puntos, por ello, en nuestra implementación, hemos definido unos límites de resolución. Por ejemplo, en un rango de 0º a 360º, podemos avanzar en saltos de 20º, así, para representar la esfera, necesitaríamos 18 vértices (360º/20º) por columna. Cuanto más pequeños escojamos los saltos, mayor número de vértices necesitaremos para definir la esfera. La ecuación vista, define una esfera completa, nosotros sólo necesitamos la mitad (figura 37), para ello, cuando hemos implementado nuestra función sólo hemos recorrido la mitad de columnas que definen una esfera. Figura 37: Cúpula utilizada para simular el cielo. Otra gran ventaja de usar una cúpula celeste, es que para conseguir un buen resultado no necesitamos usar varias texturas, solamente se necesita una (figura 38). Para renderizar la textura en la malla de vértices, simplemente hemos enviado el buffer de vértices y el de textura al API renderizador, allí son renderizados y proporcionan el deseado efecto del cielo. Figura 38: Ejemplo de textura utilizada en una cúpula celeste. Además, para crear un ambiente más real, hacemos que la semiesfera rote sobre su eje, de este modo, hemos conseguido que las posibles nubes se muevan dando un efecto de viento. 29 DETECCIÓN DE COLISIÓN. El siguiente efecto añadido ha sido la detección de colisión con el terreno. Gracias a éste, no podremos atravesar los terrenos como si se tratasen de una cortina de humo. Necesitamos añadir límites a la malla del terreno que la cámara no pueda nunca sobrepasar; para ello tendremos que impedir que el observador pueda posicionarse entre la altura 0 y la del terreno. La implementación ha sido muy sencilla. Como se ilustra la figura 39, se ha limitado la altura mínima del vuelo del observador; ésta es la altura del terreno en el punto donde se encuentra, es decir, el valor Y del terreno en el vértice (X, Z), es la mínima altitud de la cámara en dicho punto. Figura 39: Técnica empleada de detección de colisión. PÉRDIDA DE VISIÓN. Para finalizar, se ha añadido pérdida de visión por niebla. En nuestra aplicación hemos usado neblina proporcionada por la librería gráfica OpenGL, basada en los vértices. Esta niebla, también llamada volumétrica, no depende de la posición del observador. Una vez le proporcionemos las coordenadas de máxima y mínima altitud, la niebla permanece entre los límites marcados por toda la aplicación; gracias a esto, se pueden crear algunos efectos como la pérdida de vista bajo el agua. Como podemos ver en las figuras 40 y 41, ésta ha sido la solución que le hemos dado al agua de nuestro simulador. Figura 41: Efecto de niebla dentro del agua. Figura 40: Efecto niebla fuera del agua. Todos estos efectos, junto a la simulación del terreno ya comentada anteriormente, nos permiten simular un paisaje bastante real (figuras 42 y 43), en el que el usuario puede navegar sin límites, incluso por debajo del agua y, gracias al control de colisión, no atravesar terrenos. 30 Figura 42: Paisaje sin texturas. Figura 43: Paisaje con texturas y detalles. 2.2.7. Aplicación práctica. Como hemos comentado anteriormente, la visualización digital del terreno tiene muy diversas aplicaciones, que van desde la diversión hasta aplicaciones militares o de ingeniería. Este simulador puede usarse en muchos de estos campos. Una aplicación directa sería un juego 3D, o hacer turismo virtual por un paisaje deseado, y ampliando la aplicación, se podría usar para simulaciones militares o de ingeniería civil. A continuación se mostrará un ejemplo práctico del funcionamiento de la aplicación. En primer lugar, el usuario deberá encontrar las alturas de la zona geográfica deseada. Para recrear lugares de la Comunidad Valenciana recomendamos la página web http://www.gva.es/icv/ (figura 44), del Instituto Geográfico Valenciano, allí se pueden hallar gran cantidad de mapas descargables gratuitamente. Figura 44: Página web del instituto geográfico valenciano. Una vez tengamos los datos de la zona, se debe proceder a adecuarlos a nuestro simulador (figuras 45 y 46). Para ello se utilizará un editor de imágenes (en nuestro caso, Abobe Photoshop 7.0), para pintar las zonas entre curvas de nivel, las cuales marcan las diferentes alturas. 31 Figura 46: Imagen tratada. Figura 45: Imagen sin tratar. Guardaremos la imagen tratada con el nombre de “alturas”, con formato RAW, en el mismo directorio donde tengamos guardada nuestra aplicación. Llegados a este punto, sólo tendremos que ejecutar el simulador; la escena recreada será la del mapa tratado. En este ejemplo, la escena recreada corresponde a parte de los términos municipales de Benicàssim y Orpesa, que engloban el paraje natural del Desierto de las Palmas, en la provincia de Castellón. En las figuras 47 y 48 podemos comparar una imagen fotográfica real, con una imagen capturada del simulador de la misma zona geográfica. Figura 47: Fotografía real de Orpesa. Figura 48: Imagen capturada del simulador. 32 En las siguientes figuras, pueden observarse diversas iluminaciones. Figura 49: Imagen diurna. Figura 50: Imagen al anochecer. Figura 51: Imagen de tormenta. Figura 52: Imagen nocturna. 33 34 3. Conclusiones. La representación 3D de terrenos, juega, cada vez más, un rol importante en el dominio de los Sistemas de Información Geográfica. En este trabajo, hemos conseguido realizar un simulador de vuelo que nos permite representar, en tres dimensiones, una zona geográfica concreta. Para examinar diferentes tipos de informaciones procedentes de bases de datos geográficas, es necesario mostrar las alturas del terreno en un escenario interactivo. Debido a la inherente complejidad geométrica, este objetivo es frecuentemente inalcanzable, aún con las nuevas generaciones de potentes computadoras gráficas, a no ser que el tamaño de los datos originales se reduzca, y disminuya el número de polígonos a representar sin comprometer la calidad visual. En los últimos años, la mayoría de los algoritmos han estado centrados en la reducción global de la resolución del terreno. Un reciente enfoque, llamado nivel continuo de detalle, CLOD (Continuous Level of Detail), introduce una técnica jerárquica de teselar la malla de vértices. Como hemos visto, existen varios algoritmos de éste tipo (quadtree de Stefan Roettger, ROAM (Real-time Optimally Adapting Meshes) de Mark Duchaineau, geomipmapping de Willem H. Boer), que permiten crear simuladores del terreno más realistas, detallados y rápidos. En nuestro caso, hemos optado por el algoritmo geomipmapping, al tratarse de un método sencillo, que ahorra gran cantidad de trabajo a la GPU, además, hemos estudiado como acelerarlo y reducir el craqueo producido por los cambios en el nivel de detalle. Gracias a este algoritmo, hemos obtenido los resultados deseados de nuestro simulador, que es capaz de recrear virtualmente un terreno, y moverlo a una velocidad satisfactoria en un ordenador doméstico. Con el fin de recrear una escena más realista, la hemos completado con diversos efectos añadidos: una capa de agua que simula el mar, una bóveda celeste, la detección de colisión y una pérdida de visión por niebla. Estos efectos han conseguido su objetivo: añadir veracidad a la escena recreada, sin ralentizar sensiblemente su ejecución. En cuanto al desarrollo del proyecto, ha sufrido un ligero retraso respecto al tiempo planificado. Sin embargo, su realización ha sido llevada a cabo dentro de ciertos límites temporales. Al tratarse de un proyecto final de carrera, sólo ha trabajado en él un alumno, realizando secuencialmente todas las tareas. Sería especialmente interesante la formación de un grupo de trabajo, con el fin de perfeccionar y desarrollar nuevos métodos de representación digital del terreno. Otra posibilidad, sería investigar en colaboración con otras universidades u organizaciones, para realizar proyectos de gran envergadura, destinando más recursos humanos y económicos. En la realización de este proyecto, hemos conocido y profundizado en la situación actual de la simulación de terrenos por ordenador. Este apasionante campo, donde todavía queda mucho por explorar, presenta grandes desafíos a los amantes de la computación. Su principal objetivo, conseguir mover enormes cantidades de información a grandes velocidades, constituye uno de los mayores retos de la informática actual. Este campo de investigación crece rápidamente; cada vez son mejores los algoritmos de representación de terrenos, y las máquinas aumentan enormemente su velocidad de ejecución, haciendo posible la representación de escenas que, hace pocos años, resultaban impensables. 35 Personalmente, encuentro muy interesantes dos campos de la computación: los Sistemas de Información Geográfica (SIG), y la informática gráfica. La representación virtual de una zona geográfica es la unión de estos dos campos, al tener que recurrir necesariamente a ellos para su realización. Por ello, no es de extrañar, que además de haber aprendido mucho en los campos antes mencionados, haya disfrutado realizando este proyecto final de carrera. En conclusión, hemos realizado un simulador de vuelo en tres dimensiones, que satisface los requisitos establecidos inicialmente: “sobrevuelo interactivo, en un entorno virtual, a partir de datos sobre las altitudes de una zona geográfica determinada, donde el usuario puede volar libremente por la escena recreada de una manera sencilla e intuitiva”. 36 4. Posibles extensiones del proyecto. Son muchas y muy variadas las posibles aplicaciones de la visualización tridimensional de terrenos. Es por ello, que también son numerosas las potenciales extensiones del proyecto realizado, en este apartado citaremos algunas de ellas. APLICACIÓN DEL VISUALIZADOR 3D A UNA CUEVA VIRTUAL. Una ampliación interesante de este proyecto sería proyectarlo en una hardware específico, que le proporcionara mayor realismo. Una cueva virtual es un espacio donde un cluster, con varios proyectores de imagen, recrea entornos 3D. En un principio, uno de los objetivos de este proyecto era ser probado en una cueva virtual; no obstante, la falta de tiempo (150 horas) y medios (la cueva no se encuentra operativa), han impedido la consecución de dicho propósito. Para realizar esta adaptación, se habría utilizado WireGL4 (Scalable Graphics System for Clusters), que haría de interface entre nuestro código (escrito en C++, utilizando OpenGL) y el cluster de la cueva. WireGL es un sistema para renderizarización escalable interactiva en un cluster. Éste proporciona, al conocido API OpenGL, la posibilidad de ejecutarse en cada nodo de un cluster, uniendo virtualmente varias aceleradoras gráficas. WireGL también utiliza técnicas para reensamblar en una imagen la serie de parches repartidos por el cluster. Además, puede funcionar en gran número de dispositivos de salida, desde visualizaciones independientes hasta proyecciones en múltiples proyectores. Combinando la potencia gráfica virtual, la conocida y ordenada semántica de OpenGL, y la escalabilidad de los clusters, podemos crear visualizaciones sustentadas por renderizaciones de 70.000.000 de triángulos por segundo, con refresco interactivo, utilizando 16 nodos de renderización. En la figura 53, puede observarse el funcionamiento de WireGL. En este ejemplo, cada nodo renderiza en paralelo una superficie distinta utilizando OpenGL. Cada uno es responsable de sus correspondientes porciones coloreadas del objeto. En la configuración mostrada, la visualización se divide en 16 porciones, gestionadas por sus nodos. Estas porciones son reensambladas en una única imagen. Figura 53: Funcionamiento del WireGL. 4 W. Blanke, C. Bajaj, D. Fussel, and X. Zhang. The Metabuffer: A Scalable Multiresolution Multidisplay 3D Graphics System Using Commodity Rendering Engines. University of Texas. http://www.cs.virginia.edu/~gfx/pubs/wiregl/ 37 En la siguiente figura, se muestra la arquitectura de un sistema que usa WireGL. Éste es implementado como un controlador de gráficos que intercepta las llamadas de las aplicaciones al hardware gráfico. A continuación, distribuye la carga a varios servidores de renderización y éstos están conectados a proyectores que muestran la salida final. Figura 54: Diagrama de arquitectura de sistema con WireGL. Como hemos visto, la utilización de WireGL, facilitaría enormemente la visualización del proyecto en una cueva virtual y se obtendrían simulaciones espectaculares. JUEGO DE SIMULACIÓN. Una de las aplicaciones más extendidas, comentadas anteriormente, es el entretenimiento. Muchos de los juegos existentes en el mercado hacen uso intensivo de la visualización tridimensional del terreno. Una ampliación del proyecto presentado podría ser la realización de un juego de simulación. Limitando la altura de la cámara, no sólo podríamos simular vuelos, sino también simular recorridos en coche, o en submarino, impidiendo alturas mayores a la de la superficie del agua. Ilustración 1: Imagen del juego de simulación Falcon 4. Esta aplicación directa, no requeriría muchos esfuerzos adicionales. Además, podría ser comercializada. 38 CREACIÓN DE MUNDOS VIRTUALES. Como hemos visto a lo largo del proyecto, la simulación realizada recrea escenarios tridimensionales a partir de datos en dos dimensiones. En nuestro caso, hemos recreado dos zonas geográficas: las islas Columbretes, y los términos municipales de Benicàssim y Orpesa. No obstante, se pueden recrear otras zonas, reales o virtuales; podemos crear mundos completamente imaginarios a partir de imágenes creadas en un editor. Otra posible extensión del proyecto sería la creación de un editor de imágenes, que podría adjuntarse al simulador. De esta forma el usuario podría crear mundos virtuales, que no corresponden a ninguna zona geográfica. TURISMO VIRTUAL. El presente proyecto puede ser ampliado con el fin de hacer turismo virtual. Con una mejora, se podrían simular lugares de interés turístico más detalladamente, así, se recrearían posibles viajes. Con el fin de escoger, sin sorpresas desagradables, el viaje deseado, los turistas podrían visualizar una simulación de su futuro viaje, visitando los lugares que les resulten más interesantes. Esta aplicación también podría ser comercializada, y sería una opción interesante tanto para el consumidor doméstico como para las agencias de viajes. SIMULACIONES MILITARES. Desde su creación, los ejércitos han tenido que desarrollar sistemas de entrenamiento para sus unidades. Estos sistemas han evolucionado conforme al ingenio de sus monitores, desde los tiempos más remotos hasta los actuales, paralelamente al desarrollo de la tecnología. Las maniobras militares, además de muy peligrosas, suelen ser extremadamente caras y, por lo tanto, poco reproducibles. Por todo ello, son ya varios los ejércitos que instruyen a sus soldados haciendo uso de simuladores por ordenador. Ilustración 2: Simulador de combate de la empresa L3 Communications. No sólo se prepara a los pilotos de avión en vuelos simulados, también se forma de este modo a los ejércitos de tierra y mar. Son muy numerosas las aplicaciones desarrolladas con este fin: Simulador de tiro con armas portátiles, Subcalibres, Simulador 39 de manejo de VC (vehículo de combate) TAM, Simuladores tipo duelo para tanques, Simulador tipo duelo para fracciones de combate, Simulador de tiro para tanques y armas antitanque... Estas herramientas permiten simular con total fidelidad escenarios bélicos sin riesgos ni coste alguno. El presente proyecto podría ser ampliado y adaptado para uso militar, ofreciendo la posibilidad de usar diversos tipos de armamento y vehículos militares. ARQUITECTURA E INGENIERÍA CIVIL. Una de las aplicaciones más interesantes de la visualización digital del terreno se establece en la arquitectura y en la ingeniería civil. En estos campos donde se consiguen simulaciones de gran valor. En la arquitectura, podemos destacar la simulación, con una gran calidad, de futuros edificios, así como la integración de los mismos en el entorno donde serán construidos. En la ilustración 3, pueden verse las fases de la construcción de un edificio en el lugar donde se ubicará. Se podría pensar que la visualización de terrenos no tiene nada que ver con esta recreación, pero la ubicación de la escena en un terreno real hace que su visualización sea una de las protagonistas. Ilustración 3: Fases de la construcción de un edificio En la siguiente imagen puede verse una reproducción de la ciudad de Filadelfia. La perfección de la recreación es tan alta que resulta muy difícil distinguirla de la realidad. Ilustración 4: Imagen virtual de Filadelfia. En el campo de la ingeniería civil existen muy diversos usos: representación sobre terrenos virtuales de carreteras, puentes, puertos, vías férreas, canalizaciones de agua, líneas de eléctricas y telefónicas, explotación de recursos naturales, etc. Todas estas aplicaciones hacen de la visualización digital de terrenos una herramienta imprescindible para la ingeniería en general. 40 Ilustración 6: Representación de una cantera. Ilustración 5: Representación de una vía férrea. El simulador realizado en este proyecto podría ser ampliado y adaptado a muchas de las aplicaciones anteriormente mencionadas. Un ejemplo sería añadir herramientas para poder representar carreteras sobre los terrenos visualizados, de esta forma podrían estudiarse diversos trazados de una futura vía. SISTEMA DE INFORMACIÓN GEOGRÁFICA. La última extensión del proyecto que comentaremos es la posibilidad de añadir datos geográficos a las escenas representadas. Nuestro simulador nos permite recrear zonas geográficas reales, pero no proporciona la posibilidad de añadir información adicional a las escenas: nombres de lugares, texturas reales, carreteras, vías férreas, ciudades, etc... Con el fin de crear un verdadero SIG tridimensional, resultaría muy interesante dotar de estas herramientas a la aplicación realizada. Figura 55: Ejemplo de SIG 3D: NASA World Wind 1.3. 41 42 5. Bibliografía. DIRECCIONES DE INTERNET (URL). 1. Virtual Terrain Project. www.vterrain.org 2. Real-Time Generation of Continuous Levels of Detail for Height Fields. Stefan Röttger Wolfgang Heidrich, Philipp Slusallek, Hans-Peter Seidel. Universidad de ErlangenNürnberg. http://wwwvis.informatik.uni-stuttgart.de/~roettger/data/Papers/TERRAIN.PDF 3. ROAMing Terrain: Real-time Optimally Adapting Meshes. Mark Duchaineau, Murray Wolinsky, David E. Sigeti, Mark C. Miller, Charles Aldrich, Mark B. Mineev-Weinstein. http://www.llnl.gov/graphics/ROAM/ 4. Fast Terrain Rendering Using Geometrical MipMapping. Willem H. de Boer. http://www.connectii.net/emersion 5. Sky Domes. Luis R. Sempé. http://www.spheregames.com 6. Explorations in the use of Augmented Reality for Geographic Visualization. Nick. R. Hedley, Mark Billinghurst, Lori Postner, Richard May University of Washington, Seattle, USA, Hirokazu Kato Hiroshima City University, Ozuka-Higashi, Asaminami-ku Hiroshima, Japan. http://www.hitl.washington.edu/publications/r-2002-63/r-2002-63.pdf 7. Interactive Realtime Terrain Visualization for Virtual Set Applications. Arnfried Griesert Oliver Walczak, Jens Herder Competence Center ITV Virtual Sets and Virtual Environments Laboratory Fraunhofer Institut Medienkommunikation, University of Applied Sciences Sankt Augustin Josef-Gockeln-Str. Duesseldorf, Germany http://vsvr.medien.fh-duesseldorf.de/~herder/publications/hc2003herder.pdf 8. QOTA: A Fast, Multi-Purpose Algorithm For Terrain Following In Virtual Environments. John W. Barrus Richard C. Waters. MERL - A Mitsubishi Electric Research Laboratory. http://www.merl.com/papers/docs/TR96-17.pdf 9. Acquisition and Display of Real-Time Atmospheric Data on Terrain. Tian-yue Jiang, William Ribarsky, Tony Wasilewski, Nickolas Faust, Brendan Hannigan, and Mitchell Parry GVU Center, Georgia Institute of Technology. http://coweb.cc.gatech.edu:8888/csl/uploads/58/vissym01.format2.pdf 10. LOD-based Clustering Techniques for Optimizing Large-scale Terrain Storage and Visualization. Xiaohong Bao y Renato Pajarola. Universidad de California, Irvine. http://www.ics.uci.edu/~pajarola/pub/UCI-ICS-02-16.pdf 11. The Software Required for the Computer Generation of Virtual Environments. Michael J. Zyda*, David R. Pratt, John S. Falby, Chuck Lombardo and Kristen M. Kelleher. Naval Postgraduate School Department of Computer Science, Monterey, California. http://online.cs.nps.navy.mil/SavageProjects/Students/Neushul/Thesis/References/The%20S oftware%20Required%20for%20the%20Computer%20Generation%20of%20Virtual%20E nvironments.pdf 12. Hypermedia and Networking in the Development of Large-Scale Virtual Environments. Michael J. Zyda, Chuck Lombardo, and David R. Pratt Naval Postgraduate School Department of Computer Science Monterey, California. http://www.npsnet.org/~zyda/pubs/ICAT93.pdf 13. BATTLEVIEW: TOURING A VIRTUAL BATTLEFIELD M. Pauline Baker Robert J. Stein National Center for Supercomputing Applications University of Illinois. http://vis.iu.edu/Publications/BattleView.pdf 43 14. The Development and Software Design of a Cost Effective, Mobile CAVE. John Wilkinson, Cris Kania, Kavi Jivan, Janice Cawthorn. NASA Langley Research Center. Hampton. http://develop.larc.nasa.gov/remote/cave/cavetechpaper.pdf 15. Navigation in Virtual Environments. Christoph Vetter. http://www-users.itlabs.umn.edu/classes/Fall-2004/csci8980-1/slides/navigation.pdf 16. Computer 3-d site model generation based on aerial images. Sergei Y. Zheltov, Yuri B. Blokhinov, Alexander A. Stepanov, Sergei V. Skryabin, Alexander V. Sibiryakov, State Research Institute of Aviation Systems (GosNIIAS) 7, Victorenko str., Moscow, 125319, Russia. http://www.dcs.gla.ac.uk/~sibiryaa/Orlando97.PDF 17. WireGL: A Scalable Graphics System for Clusters. Greg Humphreys, Matthew Eldridge, Ian Buck, Gordon Stoll, Matthew Everett, Pat Hanrahan. Stanford University, Intel Corporation. http://www.cs.virginia.edu/~gfx/pubs/wiregl/clust_papi.pdf 18. Instituto Geográfico Valenciano. http://www.gva.es/icv/ LIBROS. • 3D Terrain Programming. Trent Polack. Premier Press. • OpenGL Programming Guide 3ª Edición. Mason Woo, Jackie Neider, Tom Davis ADDISON-WESLEY. • Curso Práctico de Programación en C y C++ 1ª Edición. Jorge Badenas, José Luis Llopis, Col·lecció Material Docent, Óscar Coltell Universitat Jaume I. • Prácticas de Informática Gráfica 1ª Edición. Miguel Chover, Joaquín Huerta, Ricardo Quirós, Inmaculada Remolar, José Ribelles. Col·lecció Material Docent (UJI), Universitat Jaume I. • Biblioteca de Consulta Microsoft Encarta 2005. 1993-2004 Microsoft Corporation. 44 6. Anexos. DIAGRAMA DE GANTT. Figura 56: Diagrama de Gantt del proyecto. 45 GLOSARIO DE TÉRMINOS. Término Definición Algoritmo Conjunto finito de instrucciones o pasos que sirven para ejecutar una tarea o resolver un problema. Un programa de software es la trascripción, en lenguaje de programación, de un algoritmo. API Application Programming Interface, (interfaz de programación de la aplicación). Conjunto de especificaciones de comunicación entre componentes software. Buffer Área de memoria de almacenamiento temporal. CAD Computer Aided Design, (diseño asistido por computador). CLOD Continuous Level of Detail, (nivel continuo del detalle). Cluster Grupo de computadoras conectadas localmente, que trabajan conjuntamente como una unidad. CPU Central Processing Unit, (unidad central de proceso). Frame Fotograma, fotografía. GPU Graphics Processing Unit, (unidad gráfica de proceso). Normal Se dice de la perpendicular en el punto de contacto al plano o recta tangentes a una superficie o línea curvas. OpenGL Open Graphics Library, (biblioteca de gráficos abierta). Biblioteca gráfica desarrollada originalmente por Silicon Graphics Incorporated. Ortoimagen Imagen fotográfica corregida geométricamente sobre la que se pueden realizar mediciones a la escala de la misma. Overhead Gastos estructurales. Espacio requerido para estructurar la memoria en un disco. Píxel Picture element, (elemento de la imagen). Menor unidad en la que se descompone una imagen digital. Render Proceso mediante el cual el ordenador crea una imagen partiendo de la descripción de las características de los objetos que contiene. SIG Sistema de información geográfica (en inglés, GIS). Slope Grado de desviación de una superficie sobre la horizontal, medida como cociente numérico, como por ciento, o grados. Tesela Cada una de las piezas con que se forma un mosaico. Topografía Conjunto de particularidades que presenta un terreno en su configuración superficial. URL Universal Resource Locator (localizador universal de recursos). WireGL Scalable Graphics System for Clusters, (Sistema de gráficos escalables para clusters). 46