E80 PROYECTOS INFOMÁTICOS Memoria Técnica del Proyecto

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