Visualización de medios participativos en entornos urbanos
Transcripción
Visualización de medios participativos en entornos urbanos
Tı́tulo: Gestión de Información Urbana Tridimensional Editores: Lidia Ortega Alvarado y Ángel Luis Garcı́a Fernández Edición y maquetación propia ISBN: 978-84-694-8374-9 Jaén, 2011 c los autores Diseño de portada: Ángel Luis Garcı́a Fernández Prefacio En este libro se recogen los resultados más relevantes relacionados con la gestión de información urbana tridimensional obtenidos por los autores a partir de un proyecto de investigación presentado a la convocatoria de incentivos a proyectos de investigación de excelencia de la Junta de Andalucı́a publicada en el BOJA no 63 de 2007 y concedido en la resolución de 19 de diciembre del mismo año. En dicho proyecto se pretendı́a profundizar e innovar en el uso de sistemas de información espaciales combinados con información geométrica 3D para apoyar el análisis y la toma de decisiones, ası́ como otras aplicaciones como la navegación o el uso de terminales móviles. Los contenidos en este volumen se han agrupado en varios bloques temáticos según el aspecto tratado: En primer lugar, se recopilan trabajos sobre el tratamiento de los datos obtenidos con distintos sistemas de captura (escáneres 3D y cámaras panorámicas), de manera que se facilite la obtención de datos geométricos. El segundo bloque está dedicado a técnicas de tratamiento de modelos digitales del terreno (MDTs). Concretamente, se tratan técnicas para optimizar la visualización de MDTs en dispositivos móviles, ası́ como para añadir información geográfica en dichos modelos. El tercer capı́tulo de este bloque muestra técnicas de visualización del interior de terrenos mineros, ampliando los MDT de forma que no sólo se modela la superficie de la Tierra, sino también su interior. El tercer bloque reúne trabajos relacionados con algoritmos geométricos básicos de aplicación en sistemas de información espacial, como las operaciones booleanas, el cálculo de inclusión de puntos o la descomposición espacial. La visualización realista de entornos urbanos ocupa el cuarto bloque de esta recopilación. Se tratan los temas de aplicación automática de texturas a modelos de edificios, ası́ como la visualización utilizando efectos de luz, sombra y medios participativos (niebla, humo, etcétera). El quinto bloque recoge trabajos relacionados con el tratamiento de información urbana, tanto del interior de los edificios como del exterior. V Prefacio VI La interacción con modelos urbanos es el centro de atención de los trabajos agrupados en el sexto bloque de este libro. Se trata la problemática relativa al uso de dispositivos móviles para la visualización, ası́ como el uso de las nuevas tecnologı́as vinculadas a la web. Por último, se presentan dos aplicaciones: la primera de ellas hace uso de un sistema de información espacial 3D para la localización de empresas en un entorno urbano, mientras que la segunda permite analizar planos arquitectónicos para extraer información semántica que luego pueda ser procesada de la manera deseada en un sistema de información espacial. Creemos que con estos contenidos se cubren prácticamente todos los aspectos relacionados con la gestión de información urbana tridimensional y sus aplicaciones, y esperamos que en el futuro estas tecnologı́as sigan su desarrollo y ocupen un lugar destacado en el desarrollo de la sociedad actual. Agradecimientos La elaboración de este libro ha sido subvencionada por la Junta de Andalucı́a y los Fondos FEDER de la Unión Europea a través del proyecto de investigación P07-TIC-02773. Ası́ mismo, todos los trabajos contenidos en este libro han sido parcial o totalmente subvencionados a través de dicho proyecto. Jaén, 2011 Lidia Ortega Alvarado Ángel Luis Garcı́a Fernández Contenido Gestión de Información Urbana Tridimensional. Aplicaciones . . . . . . . . . . F.R. Feito 1 Bloque I Postprocesamiento Detección de elementos no estructurados en escenas 3D procedentes de escáneres láser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manuel J. González Muñoz, Manuel J. Lucena López, José M. Fuertes Garcı́a, Rafael J. Segura Sánchez y Antonio J. Rueda Ruiz 9 Reconstrucción de entornos tridimensionales a partir de múltiples vistas panorámicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Guadalupe Millán de la Blanca, Manuel J. Lucena López y José M. Fuertes Garcı́a Bloque II Terrenos Visualización adaptativa de grandes terrenos a través de redes celulares . 39 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez Introducción de información geográfica en terrenos 3D . . . . . . . . . . . . . . . . 71 Ángel Aguilera Garcı́a, J. Roberto Jiménez Pérez y Francisco Martı́nez del Rı́o Visualización 3D del interior de terrenos mineros . . . . . . . . . . . . . . . . . . . . . 83 M. Linarejos Rivero Cejudo Bloque III Algoritmos básicos Operaciones Booleanas sobre polı́gonos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Francisco Martı́nez del Rı́o, Ángel Aguilera Garcı́a y J. Roberto Jiménez Pérez VII VIII Contenido Algoritmos Geométricos Básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Juan J. Jiménez Delgado, Antonio Martı́nez Albalá, Félix Paulano Godino y Rubén Pulido Ramı́rez Bloque IV Visualización realista Texturización en entornos urbanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Marı́a Dolores Robles Ortega, Lidia Ortega Alvarado y Francisco R. Feito Higueruela Visualización de medios participativos en entornos urbanos . . . . . . . . . . . . 151 J. Roberto Jiménez Pérez, Francisco Martı́nez del Rı́o y Ángel Aguilera Garcı́a Bloque V Tratamiento de información urbana Estudio sobre la representación semántica y topológica de interiores de edificios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Bernardino Domı́nguez Martı́n, Ángel Luis Garcı́a Fernández y Francisco R. Feito Higueruela Mejora y ampliación de la cartografı́a urbana . . . . . . . . . . . . . . . . . . . . . . . 183 Ma Isabel Ramos Galán y José L. de la Cruz González Bloque VI Interacción Estudio sobre técnicas de visualización y navegación de entornos virtuales en dispositivos móviles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez Sistema de visualización de entornos urbanos con WebGL y X3DOM . . . . 215 Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado Bloque VII Aplicaciones SIG urbanos en 3D para aplicaciones comerciales . . . . . . . . . . . . . . . . . . . . 227 Ana Ma López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado MOSES: aplicación software para la gestión de modelos de edificios . . . . . 253 Bernardino Domı́nguez Martı́n, Francisco de A. Conde Rodrı́guez, Ángel Luis Garcı́a Fernández, Francisco R. Feito Higueruela Lista de autores Ángel Aguilera Garcı́a Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Francisco de Ası́s Conde Rodrı́guez Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Bernardino Domı́nguez Martı́n Departamento de Informática. Universidad de Jaén. e-mail: [email protected] José Luis de la Cruz González Departamento de Ingenierı́a Cartográfica, Geodésica y Fotogrametrı́a. Universidad de Jaén. e-mail: [email protected] Francisco Ramón Feito Higueruela Departamento de Informática. Universidad de Jaén. e-mail: [email protected] José Manuel Fuertes Garcı́a Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Ángel Luis Garcı́a Fernández Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Manuel Jesús González Muñoz Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Juan José Jiménez Delgado IX X Lista de autores Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Juan Roberto Jiménez Pérez Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Ana Marı́a López Estrella Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Manuel José Lucena López Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Antonio Martı́nez Albalá Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Francisco Martı́nez del Rı́o Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Guadalupe Millán de la Blanca Departamento de Informática. Universidad de Jaén. e-mail: [email protected] José Marı́a Noguera Rozúa Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Carlos Javier Ogayar Anguita Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Lidia Ortega Alvarado Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Félix Paulano Godino Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Rubén Pulido Ramı́rez Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Marı́a Isabel Ramos Galán Departamento de Ingenierı́a Cartográfica, Geodésica y Fotogrametrı́a. Universidad de Jaén. e-mail: [email protected] Lista de autores Marı́a Linarejos Rivero Cejudo Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Marı́a Dolores Robles Ortega Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Antonio Jesús Rueda Ruiz Departamento de Informática. Universidad de Jaén. e-mail: [email protected] Rafael Jesús Segura Sánchez Departamento de Informática. Universidad de Jaén. e-mail: [email protected] XI Gestión de Información Urbana Tridimensional. Aplicaciones F.R. Feito La mayor disponibilidad de geo-información está permitiendo el desarrollo de nuevas herramientas software que facilitan un mejor acceso y un mayor uso de dicha información. Es conocido que cerca de un 80 % de la información que usan las empresas o entidades tiene una componente geográfica o espacial. Partiendo de esta idea, se propuso la realización de un proyecto que pretendı́a diseñar e implementar prototipos de herramientas software para el acceso a información urbana tridimensional, de modo que fuera posible interactuar más y mejor con ella. Se tratarı́a de acceder al entorno urbano tal y como es en la realidad, es decir, a los edificios considerados como elementos tridimensionales tanto en su aspecto externo como en cuanto a sus contenidos interiores. Era y es evidente que las herramientas para gestión de información geográfica (Google Earth, por ejemplo) han evolucionado muy rápidamente en los últimos años, aunque la interacción o información que dichas herramientas ofrecen es reducida y está orientada en la mayorı́a de los casos a la visualización. A partir de la experiencia contrastada del equipo de investigación que presentaba este proyecto, se pretendı́a avanzar en el diseño e implementación de herramientas software basadas en software libre, que permitieran la gestión de la información tridimensional que existe en todo entorno urbano: se pretendı́a no sólo la visualización 3D realista de entornos urbanos, sino la interacción con la información que los edificios que componen dichos entornos urbanos tienen en su interior. La gestión y captura de información tridimensional en entornos reales no controlados, puede verse sensiblemente mejorada a través del empleo de técnicas de reconstrucción automática que, a partir de imágenes del edificio en cuestión, permitan obtener su estructura tridimensional. Gracias a ello, pueden incorporarse al sistema grandes cantidades de información a partir de fuentes fáciles de obtener y sin necesidad de equipamiento especial. Estas técnicas pueden asimismo emplearse F.R. Feito Departamento de Informática. Universidad de Jaén e-mail: [email protected] 1 2 F.R. Feito para mejorar la experiencia del usuario en su interacción con el sistema, mediante la superposición de elementos sintéticos a imágenes obtenidas del mundo real. Además, y utilizando los prototipos desarrollados, se pretendı́a ofrecer servicios a entidades y empresas públicas y privadas de modo que se facilitara un mejor y mayor desarrollo social a la vez que se generaba nuevo conocimiento de los entornos urbanos que permitiera avanzar tanto en la investigación básica como en la aplicada. El desarrollo basado en software abierto permitirı́a eliminar la dependencia que tienen, en muchos casos, esas empresas o entidades de software propietario. 1. Antecedentes Son muy diversas las herramientas que se ofertan para la gestión de geoinformación. La oficina virtual del catastro [3] o el SIGPAC [14] destacan entre los más concretos mientras que Google Earth [6] o Bing Maps [2] se encuentran entre los más genéricos. Actualmente la gestión adecuada de la geoinformación se orienta a lograr una mayor facilidad a la vez que se intenta incorporar la tercera dimensión, considerando que ésta es básica para un verdadero conocimiento y por tanto, para una gestión adecuada de la información. En los últimos años se han dado avances importantes en la disponibilidad de herramientas para el tratamiento adecuado de la tercera dimensión en la información geográfica, pero casi siempre desde el punto de vista de la visualización. Cuando se elaboró la propuesta de proyecto, no se habı́a aportado software válido y eficaz para la gestión y la interacción con la información geográfica completa, es decir, con la información tridimensional contenida en cualquier entorno geográfico, y en concreto en los entornos urbanos. Las técnicas basadas en realidad virtual (VRML y X3D fundamentalmente [17]), en imágenes o videos (Flash de Adobe [1] o Silverlight de Microsoft [16]) o en modelado 3D mediante geometrı́as sencillas y texturas (Google SketchUp [7]) destacan entre las que se están usando para la simulación de entornos tridimensionales. Por otro lado, están siendo importantes los desarrollos de herramientas SIG avanzadas basadas en software libre. En España destacan los productos gvSIG [9] (basado en licencia GPL, desarrollado inicialmente en la Comunidad Valenciana, y actualmente mantenido por la Asociación gvSIG) y el proyecto Sextante, desarrollado en Extremadura [15]. A nivel internacional destaca GRASS [8], que puede considerarse la herramienta de dominio público más avanzada en cuanto a análisis espacial. Junto a lo anterior ha ido avanzando el software disponible para la gestión y diseño de contenidos geográficos, muchos de ellos relacionados con las iniciativas sobre Infraestructura de datos espaciales, como la directiva INSPIRE de la Unión Europea (Infrastructure for Spatial Information in the European Community) [11], o el proyecto IDEE español [10]. Gestión de Información Urbana Tridimensional. Aplicaciones 3 En la página web del Open Geospatial Consortium [12] está disponible toda la información relativa a estándares abiertos para el acceso a información geográfica en la web. Ası́ mismo hay varias páginas web que recopilan información sobre herramientas GIS de dominio público disponibles en la actualidad [5, 13]. Centrándonos en el tema urbano, en España destaca el portal de la oficina virtual del catastro [3]. Tal y como allı́ se indica, se están aumentado los servicios a los ciudadanos, basados muchos de ellos en el formato WMS (Web Map Service) que es el más sencillo que se puede utilizar. Este formato, junto con el formato WFS (Web Feature Service) orientado a cartografı́a vectorial y el WCS (Web Coverage Service) orientado a cartografı́a raster son los que usan actualmente los servidores de mapas (Figuras 1 y 2). Fig. 1 Arquitectura de servicios web de información geográfica Puede encontrarse también información de interés en las comunicaciones presentadas en las distintas ediciones del congreso de software libre y abierto para aplicaciones geoespaciales. Todas ellas están disponibles a través de Internet [4]. 2. Objetivos del proyecto El proyecto que se propuso se concretaba en los siguientes objetivos fundamentales: 4 F.R. Feito Fig. 2 Funcionamiento de los servicios web de información geográfica 1. Desarrollar prototipos software, basado en software libre (bajo licencia GPL) que permitan la interacción con la información urbana tridimensional. 2. En relación a lo anterior, el diseño y mantenimiento de un servidor de mapas con información urbana tridimensional, accesible mediante el software desarrollado en el objetivo anterior. 3. Estudio y diseño de posibles aplicaciones que, desde diversos ámbitos sociales, permitieran el aprovechamiento eficaz de las herramientas desarrolladas para un mejor desarrollo local. Teniendo en cuenta la posibilidad de que parte de la información contenida en el interior de los edificios fuera considerada privada, y por tanto sujeta a la ley de protección de datos, se pretendı́a usar información relacionada con entes públicos y similares (edificios de universidades, ayuntamientos, consejerı́as, etc.). Sin perjuicio de ampliaciones futuras a otros pueblos y ciudades de Andalucı́a, el servidor de mapas se centrarı́a en los entornos urbanos de las ciudades de Jaén y Granada. Por medio de los objetivos anteriores se pretendı́a fomentar la innovación, tanto en el sector público como en el privado. Para facilitar la labor anterior, se contactó con el Departamento de Valoraciones de la Consejerı́a de Economı́a y Hacienda de la Junta de Andalucı́a y se contó con su declaración de interés en el proyecto, de forma que una vez obtenidos los primeros resultados se concretarı́an posibles formas de colaboración. De hecho uno de los doctores miembros del grupo TIC que daba soporte al proyecto, y que formaba Gestión de Información Urbana Tridimensional. Aplicaciones 5 parte del equipo investigador, trabajaba en dicha Consejerı́a, por lo que fácilmente se lograrı́a la colaboración indicada. Además se contactó con la Cámara de Comercio e Industria de Jaén, que también manifestó su interés por los resultados del proyecto y por el desarrollo de aplicaciones orientadas al desarrollo socieconómico de la provincia. Se pretendı́an realizar convenios que concretaran dichas aplicaciones. 3. Resultados esperados y obtenidos Entre los resultados cientı́ficos esperados cabı́a destacar: El diseño de algoritmos eficientes para la gestión de información urbana tridimensional El diseño e implementación de un servidor de cartografı́a urbana, con información tridimensional La elaboración de prototipos software para el acceso al servidor de mapas desde diversos tipos de terminales La adecuada visualización y gestión de la información urbana disponible El desarrollo de propotipos de aplicaciones, basadas en las herramientas anteriores La obtención de avances en la investigación básica relacionadas con los campos anteriores Tal y como podrá comprobarse con la lectura y estudio detallado de los diversos capı́tulos del libro, puede afirmarse que los objetivos previstos se han cumplido ampliamente. Es cierto que no ha sido posible ofrecer un servidor de cartografı́a 3D, pero ello ha sido debido a la falta de información global en el catastro de este tipo de datos. Sı́ se han aportado algoritmos para la generación de prototipos 3D con información de altura de edificios calculada aproximadamente. Con la evolución hacia el catastro 3D y la realidad de que la web, mediante el estándar WebGL, es ya Web 3D, puede decirse que en poco tiempo dicha información estará accesible. Referencias 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Adobe Flash Platform. http://www.adobe.com/flashplatform Bing Maps. http://www.bing.com/maps Dirección General del Catastro de España. http://www.sedecatastro.gob.es Free and Open Source Software for Geospatial conferences. http://foss4g.org FreeGIS project. http://freegis.org Google Earth. http://earth.google.es Google SketchUp. http://sketchup.google.com Open Source Geospatial Foundation. GRASS GIS. http://grass.fbk.eu gvSIG. http://www.gvsig.org Portal de Infraestructura de Datos Espaciales de España (IDEE). http://www.idee.es 6 11. 12. 13. 14. Unión Europea. Directiva INSPIRE. http://inspire.jrc.ec.europa.eu Open Geospatial Consortium. http://www.opengeospatial.org Open source GIS. http://opensourcegis.org Sistema de Información Geográfica de Identificación de http://sigpac.mapa.es/fega/visor 15. Sextante. http://www.sextantegis.com 16. Microsoft Silverlight. http://www.microsoft.com/silverlight 17. Web3D Consortium. http://www.web3d.org F.R. Feito Parcelas Agrı́colas. Bloque I Postprocesamiento Detección de elementos no estructurados en escenas 3D procedentes de escáneres láser Manuel J. González Muñoz, Manuel J. Lucena López, José M. Fuertes Garcı́a, Rafael J. Segura Sánchez y Antonio J. Rueda Ruiz 1. Introducción Los escáneres láser se están utilizando cada vez más para la adquisición de información 3D. Esto es debido a la mejora continua del hardware de estos sistemas, que a dı́a de hoy son muy asequibles y precisos. Actualmente se está generando gran cantidad de información a partir de escáneres láser, tomada de fuentes muy diversas (interiores y exteriores) para una gran variedad de propósitos: reconstrucción de modelos, análisis, medida, etc. Por esta razón, las técnicas de filtrado de datos 3D se han convertido en un tema de investigación muy activo, y en una fase muy importante para el tratamiento de este tipo de información en gran variedad de aplicaciones (visión artificial, ingenierı́a civil, arqueologı́a, medicina, etc.). Para procesar los grandes volúmenes de información generados por los escáner 3D, el software que acompaña estos dispositivos incluye herramientas de tratamiento de nubes de puntos. Con frecuencia es necesario eliminar objetos no deseados (trabajadores, equipamiento, estructuras de soporte temporales, etc.) de los datos, por lo que es necesario al menos un proceso básico de segmentación. Sin información previa que sirva de ayuda, una segmentación automática no supervisada proporciona resultados insatisfactorios [3, 1, 4]. Por esta razón, el software actual de tratamiento de nubes de puntos 3D ofrece procesos de segmentación manuales o semiautomáticos. Este tipo de tareas pueden ser extremadamente lentas y tediosas cuando se trabaja sobre escenas que contienen gran cantidad de información. La mayorı́a de los objetos no deseados existentes en las escenas de exteriores presentan propiedades geométricas similares. En general, son objetos que presentan localmente superficies no estructuradas. Podemos denominarlos objetos no estructurados. Normalmente este tipo de elementos dan lugar a agrupaciones de puntos Departamento de Informática Universidad de Jaén Campus Las Lagunillas Edif. A3 23071 - Jaén, España e-mail: {mgmunoz, mlucena, jmf, rsegura, ajrueda}@ujaen.es 9 10 M.J. González, M.J. Lucena, J.M. Fuertes, R.J. Segura y A.J. Rueda que pueden ser: longitudinales (cables), ruidosas (arbustos o ramas de los árboles), o pequeños y aislados grupos de puntos (objetos de pequeña escala). En nuestro caso, queremos detectar los elementos no estructurados de una escena usando exclusivamente la información geométrica. Tomando como partida la nube de puntos generada mediante un escáner 3D, nuestra técnica nos permite detectar este tipo de elementos y extraer ası́ las estructuras relevantes de la escena, con el objetivo de crear mallas adecuadas para las aplicaciones de ingenierı́a civil. Es importante recalcar que no queremos reducir o eliminar el ruido presente en la nube de puntos, sino identificar los objetos no estructurados presentes en la escena. Para alcanzar dicho objetivo, este trabajo propone una técnica compuesta de dos fases. La primera consiste en una difusión anisotrópica y la segunda en una regresión de planos. Para la aplicación de la técnica propuesta la información 3D procedente del escáner es colocada sobre una matriz bidimensional. Esto se consigue a partir de las coordenadas polares de cada punto relativas a la posición del escáner. El artı́culo está organizado de la siguiente manera. La Sección 2 hace la introducción al método propuesto. Los resultados experimentales, usando tanto datos reales como sintéticos, se muestran en la Sección 3. Finalmente, la Sección 4 muestra nuestras conclusiones y el trabajo futuro. 2. Método propuesto El método comienza con la obtención de las proyecciones de los puntos escaneados sobre la matriz de distancias I, donde la columna y la fila de cada punto son determinados mediante su ángulo horizontal y vertical relativos a la posición del escáner. Cada elemento de la matriz es un número real que representa la distancia al escáner del punto asignado a esa posición, o puede quedar nulo si el escáner no ha devuelto información para esa posición concreta. Nuestra técnica se compone de dos etapas. La primera aplica un proceso de difusión anisotropica sobre la matriz de distancias. Este proceso desplaza cada punto a lo largo de la lı́nea que une el punto en sı́ con el escáner. Realizando la diferencia entre los valores de la matriz resultado y los originales obtenemos las altas frecuencias de la matriz de distancias. Debido a sus caracterı́sticas geométricas, los objetos no estructurados que pretendemos identificar suelen dar lugar a grandes variaciones en los valores de la matriz resultado. No obstante, si generamos la matriz con las diferencias entre la original y la suavizada, podemos ver que no sólo aparecen grandes valores en las zonas no estructuradas. También aparecen valores significativos dentro de las regiones donde la distancia con el escáner cambia gradualmente (como el suelo o un muro inclinado con respecto al escáner). Esto es debido a que el proceso de difusión anisotrópica modifica los valores de estas regiones hasta alcanzar un valor medio, por lo que los valores extremos proporcionarán diferencias mayores. La segunda fase de nuestra técnica detecta estas variaciones en la matriz diferencia, midiendo la distancia entre Detección de elementos no estructurados en escenas 3D procedentes de escáneres láser 11 cada punto actual con un plano obtenido mediante regresión, calculado a partir de los vecinos del punto. 2.1. Difusión anisotrópica Perona y Malik [7] introdujeron una técnica de regularización no linear e iterativa conocida como difusión anisotrópica. Esta técnica regulariza imágenes en escala de grises manteniendo las discontinuidades más destacadas que con frecuencia contienen la información de aristas o bordes. El proceso puede ser generalizado para aplicarlo a imágenes en color [5] y de disparidad (distancias) [6]. Nuestra aproximación está basada en el último caso. Siendo I nuestra matriz de distancias, aplicaremos esta técnica sobre ella con el objetivo de eliminar las altas frecuencias mediante el desplazamiento de los puntos. La difusión anisotrópica modifica el valor de cada punto en función de la diferencia con sus vecinos. Esta diferencia es ponderada mediante un coeficiente de conducción c. El enfoque discreto de la difusión anisotrópica puede utilizar la discretización del operador Laplacian. Este operador se aplica sobre los cuatro vecinos más cercanos para actualizar los valores de la matriz en cada iteración: It+1 = It + λ [cN · ∇N(I) + cS · ∇S(I) + +cE · ∇E(I) + cW · ∇W (I)] (1) donde ∇ representa el operador gradiente, λ ∈ [0, 1/4], y los subı́ndices N, S, E y W representan los vecinos Norte, Sur, Este y Oeste. El coeficiente de conducción usado en la difusión anisotrópica debe devolver 1 dentro de cada región y 0 en las fronteras o lı́mites. Nosotros hemos usado la siguiente expresión para c [7]: g(x) = 1 1 + (x/K)2 (2) donde x es un estimador del gradiente en la matriz de distancias para el punto correspondiente, y K es un umbral establecido de manera que las fronteras con un contraste mayor permanecerán mientras que el resto tenderá a desaparecer. Este valor puede ser fijado manualmente o ser el estimador de ruido descrito por Canny [2]: se puede calcular el histograma acumulado de los valores absolutos del gradiente de la imagen y el valor de K ser elegido de manera que deje el 90 % de los valores del histograma por debajo. El número de iteraciones puede ser establecido manualmente. Cuando el proceso termina, obtenemos la imagen suavizada I ′ . Al comparar la imagen I ′ con la original I observamos diferencias importantes en las regiones ruidosas. Ası́ pues, calcularemos una nueva matriz M = I − I ′ . 12 2.2. M.J. González, M.J. Lucena, J.M. Fuertes, R.J. Segura y A.J. Rueda Regresión de planos Las regiones que pertenecen a objetos estructurados presentan una caracterı́stica común en M: sus valores pueden ser ajustados a un plano con un pequeño error. Nosotros utilizamos dicha propiedad de manera similar a como se hace en [8] para diferenciar entre las regiones estructuradas y no estructuradas. Para encontrar el mejor plano que se ajusta a los puntos tomamos el ı́ndice de la columna y de la fila en la matriz como las coordenadas X e Y respectivamente, y el valor almacenado en dicha posición como la coordenada Z. Para cada valor de la matriz, podemos usar su vecindad para ajustar un plano y medir la distancia entre el plano y el valor considerado. Si el valor corresponde a una región estructurada, la distancia calculada será muy pequeña (ver Figura 1). De esta manera generamos una nueva matriz de diferencias, M ′ , rellenada con las distancias entre cada punto y su correspondiente plano de regresión, permitiéndonos caracterizar las regiones no estructuradas. La fase de selección final se lleva a cabo mediante el establecimiento de un umbral sobre la matriz de diferencias M ′ obtenida tras la fase de regresión. Nosotros usamos como umbral el punto de inflexión calculado sobre el histograma de M ′ . Los puntos aislados son clasificados directamente como no estructurados. Fig. 1 Detección de puntos no estructurados. a) Conjunto estructurado de puntos: la distancia entre el punto (rojo) y el plano de regresión estimado es pequeña. b) Conjunto no estructurado de puntos: la distancia entre el punto rojo y el plano es mayor. 3. 3.1. Experimentación Configuración de los experimentos Hemos probado nuestra técnica tanto en escenas sintéticas como en reales. Las escenas sintéticas se han obtenido a partir de un mundo virtual compuesto por varios objetos estructurados simples (suelo y edificios) y otros no estructurados (árboles, arbustos y cableado eléctrico). La nube de puntos se ha generado mediante la simulación de un escaneado desde una posición concreta del mundo virtual. Con dicho sistema se obtuvieron 530.000 puntos (ver Figuras 2 y 3). Las hojas de la vegetación se han generado mediante puntos situados de forma aleatoria dentro de una esfera. La escena real (Figura 4) se ha obtenido usando un escáner láser de rango medio (Callidus CP 3200) sobre un puente de piedra antiguo rodeado de vegetación, ge- Detección de elementos no estructurados en escenas 3D procedentes de escáneres láser 13 nerando una nube de aproximadamente 400.000 puntos. La nube presenta además información correspondiente a los cables pertenecientes a la estación de escaneo. Fig. 2 Escena sintética usada en los experimentos. Fig. 3 Nube de puntos sintética usada en los experimentos, generada a partir de la escena de la Figura 2. mostrando un edificio, una farola y vegetación. Al pertenecer la escena sintética a un mundo virtual controlado, disponemos de la clasificación correcta a priori de los puntos, con lo que hemos podido comparar dicha clasificación con la obtenida tras la aplicación de nuestro método. Ası́ pues mostraremos los resultados numéricos de la imagen correspondiente a dicha escena. Para el proceso de difusión, se han usado los siguientes parámetros en todos los experimentos: 100 iteraciones, λ = 0,25, y K de manera que deja por debajo un 80 % de los valores del histograma acumulado. 14 M.J. González, M.J. Lucena, J.M. Fuertes, R.J. Segura y A.J. Rueda Fig. 4 Nube de puntos obtenida mediante escáner láser de rando medio. 3.2. Resultados obtenidos Las Figuras 5 y 6 muestran las nubes de puntos proyectadas sobre las matrices de profundidad. Como podemos ver, hay áreas extensas sin información, correspondientes principalmente al cielo, donde el rayo o pulso del escáner no consigue impactar con ningún objeto para generar la información de un punto nuevo. Estos puntos nulos serán simplemente ignorados en los procesos de las distintas fases. Fig. 5 Puntos proyectados de la escena sintética, usando el color real de la escena. Los puntos nulos se muestran en gris. Fig. 6 Puntos proyectados de la escena real, usando el color real de la escena. Los puntos nulos se muestran en blanco. Detección de elementos no estructurados en escenas 3D procedentes de escáneres láser 15 La Figura 7 muestra los resultados obtenidos sobre la nube de puntos sintética, usando la regresión de planos con una vecindad definida por una ventana de tamaño 3. Se puede ver que la mayorı́a de los puntos no estructurados han sido marcados correctamente. Algunos de los puntos estructurados, especialmente los situados en áreas de gran curvatura, han sido marcados también como puntos no estructurados. Es de especial interés el caso de las farolas, cuyos postes han sido etiquetados como no estructurados. En efecto, estos objetos son ligeramente más anchos que los cables eléctricos, por lo que podrı́an pasar perfectamente por elementos no estructurados. Fig. 7 Resultados sobre la nube sintética con colores de etiquetado (azul: aciertos sobre las regiones estructuradas; verde: aciertos sobre las regiones no estructuradas; rojo: fallos). Tamaño de la ventana de vecindad: 3. Algunos de los resultados numéricos se muestran en la Tabla 1. Los mejores resultados se han obtenido con los tamaños de ventana más pequeños, debido a la mayor tolerancia a la curvatura que podemos encontrar en la vecindad de los puntos estructurados. Tabla 1 Porcentaje de acierto conseguido sobre la escena sintética, variando el tamaño de la ventana de vecindad. Tamaño de ventana No estructurados Estructurados 3 5 7 9 97.18 % 96.77 % 97.28 % 96.53 % 92.34 % 92.00 % 89.23 % 89.98 % La Figura 8 muestra el resultado obtenido por la escena real. Se puede comprobar que la mayorı́a de los arbustos han sido seleccionados correctamente. El borde superior del puente se ha marcado también como no estructurado debido a la presencia vegetación en esta parte del puente. También podemos ver que la vegetación del suelo no ha sido marcada debido a la pequeña altura que presenta. 16 M.J. González, M.J. Lucena, J.M. Fuertes, R.J. Segura y A.J. Rueda Fig. 8 Resultados sobre la escena real. Los puntos detectados como no estructurados están marcados en rojo. Tamaño de la ventana: 9. 4. Conclusiones y trabajo futuro Nuestro método puede detectar y marcar la mayorı́a de los elementos no estructurados en escenas 3D procedentes de escaneados de exteriores. Estos elementos no estructurados corresponden en la mayorı́a de los casos a objetos no deseados de la escena escaneada (cables, vegetación, etc.). La primera fase, compuesta por un proceso de difusión anisotrópica seguido de una diferencia de matrices, elimina los componentes de bajas frecuencias de la nube de puntos. La fase de la regresión de planos detecta localmente la ausencia de estructura. Como resultado, obtenemos un etiquetado de los puntos, indicando la presencia (ausencia) de estructura local. Los resultados numéricos muestran que el método propuesto es lo suficientemente preciso para dar una estimación inicial de las estructuras de interés de una nube de puntos. Vale la pena mencionar que nuestro método está siendo actualmente usado con buenos resultados en un software de tratamiento de datos 3D, como parte de una herramienta supervisada de selección de puntos para aplicaciones de ingenierı́a. Como trabajo futuro, planeamos probar nuestro método sobre otros tipos de escenas que contengan objetos de diferentes escalas. Queremos también tomar en consideración la información de color para el proceso de selección. Finalmente nuestro método podrı́a ser combinado con técnicas de detección de objetos para seleccionar correctamente objetos compuestos, como los árboles, los cuales tienen una parte no estructurada (hojas) y otra estructurada (tronco). Agradecimientos Este trabajo ha sido parcialmente financiado por Sacyr, la Junta de Andalucı́a, el Ministerio Español de Educación y Ciencia, y la Unión Europea mediante los fondos ERDF, dentro de los proyectos 970/2007, P06-TIC-01403 y TIN2007-67474-C03-03. Referencias 1. Akinci B, Boukampa F, Gordona C, Huberb D, Lyonsb C, Parkc K (2006) A formalism for utilization of sensor systems and integrated project models for active construction quality control. Automation in Construction 15(2):124–138 2. Canny J (1986) A computational approach to edge detection. IEEE Transactions on Pattern Analysis and Machine Intelligence 8(6):679–698 Detección de elementos no estructurados en escenas 3D procedentes de escáneres láser 17 3. Johnson A, Hebert M (1999) Using spin images for efficient object recognition in cluttered 3d scenes. Pattern Analysis and Machine Intelligence, IEEE Transactions on 21(5):433–449, DOI 10.1109/34.765655 4. Kwon S, Haas C, Liapi K, Sreenivasan S, McLaughlin J (2002) Human-assisted object fitting to sparse cloud points for rapid workspace modeling in construction automation. In: Proceedings of the 19th International Symposium for Automation and Robotics in Construction, pp 357–362 5. Lucena M, Fuertes J, Pérez de la Blanca N, Ruiz N (2000) Anisotropic diffusion in colour images. In: Torres M, Sanfeliu A (eds) Pattern Recognition and Applications, IOS Press, pp 81–88 6. Mabaar M, Siebert J (2008) Smoothing disparity maps using intensity-edge guided anisotropic diffusion. In: Medical Image Understanding and Analysis 2008, 2nd-3rd July 2008, University of Dundee, Dundee, Scotland. 7. Perona P, Malik J (1990) Scale-space and edge detection using anisotropic diffusion. IEEE Transactions on Pattern Analysis and Machine Intelligence 12(7):629–639 8. Weyrich T, Pauly M, Heinzle S, Scandella S, Gross M (2004) Post-processing of scanned 3d surface data. In: Symposium On Point-Based Graphics, pp 85–94, URL http://graphics.ethz.ch/˜pauly/publications files/Pdfs/PostProcessing.pdf Reconstrucción de entornos tridimensionales a partir de múltiples vistas panorámicas Guadalupe Millán de la Blanca, Manuel J. Lucena López y José M. Fuertes Garcı́a Resumen En este trabajo presentamos un proceso de reconstrucción de estructura tridimensional a partir de múltiples imágenes esféricas. La popularización de dispositivos hardware de adquisición de imágenes esféricas plantea la cuestión de su posible uso para la reconstrucción de entornos, a partir de múltiples vistas. Para ello proponemos un método basado en la detección de puntos singulares, su emparejamiento entre varias vistas, y su posterior triangulación para ubicarlos en el espacio. En este trabajo se presentan los principales resultados obtenidos, demostrando que pueden llegar a obtenerse reconstrucciones con un nivel de precisión razonable. 1. Introducción Uno de los objetivos de la visión artificial es conseguir que un ordenador llegue a analizar una escena real como lo harı́a una persona. Para conseguir este propósito, es necesario crear un modelo 3D de dicha escena. La reconstrucción tridimensional tiene varias aplicaciones, como la navegación de un robot permitiéndole conocer en qué parte de la escena se encuentra y poder planificar sus movimientos sin necesidad de ayuda humana. También es útil para determinar magnitudes como distancias, superficies o volúmenes, lo cual puede ser aplicable para controles de calidad ya que se pueden verificar los procesos y superficies de los objetos que se estén fabricando. Otra aplicación es la digitalización de museos o monumentos históricos, para crear visitas virtuales a las cuales los usuarios pueden acceder desde Internet. Estas son algunas de las muchas utilidades existentes de la reconstrucción tridimensional. G. Millán Departamento de Informática, Universidad de Jaén M. Lucena Departamento de Informática, Universidad de Jaén, e-mail: [email protected] J.M. Fuertes Departamento de Informática, Universidad de Jaén e-mail: [email protected] 19 20 Guadalupe Millán de la Blanca, Manuel J. Lucena López y José M. Fuertes Garcı́a Este trabajo pretende establecer una metodologı́a que, a partir de imágenes panorámicas capturadas desde el Sistema de visión esférica Ladybug2 (ver Figura 1), llegue a crear un modelo de planos 3D de una escena. Para conseguir dicho objetivo, en primer lugar se han estudiado las diferentes técnicas de reconstrucción 3D, con objeto de conocer las posibilidades existentes. Algunas de estas técnicas, como la telemetrı́a láser o la luz estructurada permiten reproducir modelos muy exactos y precisos, pero con el inconveniente de emplear un equipo costoso. Otras tienen tiempos de ejecución muy altos, como la visión estéreo densa, y por ello se optó finalmente por una reconstrucción estereoscópica dispersa basada en puntos de interés, al proporcionar una solución robusta y a la vez más rápida que el resto de las técnicas investigadas. A continuación se analizaron algunos de los principales detectores de puntos de interés y de regiones en el espacio multiescala [1], implantando algunos de ellos como Harris [2], SIFT [3], y Affine-SIFT [4]. Los mejores resultados se obtubieron con el detector de regiones en el espacio multiescala Affine-SIFT ya que es el detector que más puntos detecta cuando existen deformaciones afines en los objetos de la escena. Fig. 1 Ejemplo de imagen esférica. 2. Sistema de visión esférica Ladybug 2 En este trabajo hemos utilizado el sistema digital de adquisición esférica Ladybug2, de Point Grey [8]. Este sistema cuenta con seis cámaras de 0.8 MP que permiten capturar más del 75 % del entorno donde se encuentra, una tarjeta Firewire IEEE-1394b que permite capturar imágenes en el disco a 30 fotogramas por segundo, una unidad central de adquisición de imágenes y control de software, un kit de Reconstrucción de entornos tridimensionales a partir de múltiples vistas panorámicas 21 desarrollo de software (SDK), cables para la conexión y alimentación, y sus correspondientes controladores de dispositivo. La cámara puede calibrarse usando esferas que oscilan entre los 2m y 20m de diámetro, y asumiendo que todos los puntos de la escena capturada están a la misma distancia de la cámara. Esta calibración es importante para conseguir un buen resultado en el proceso de pegado o stitching, en el cual se combinan las imágenes individuales de cada objetivo para producir una única imagen panorámica o una de alta resolución. Esta unión se realiza a partir de las zonas comunes presentes en las diferentes imágenes parciales obtenidas. Los seis objetivos que componen Ladybug2 se combinan para formar la imagen final, que puede ser de tres tipos: esfera, cúpula y panorámica. El stitching se basa en geometrı́a, no en el contenido de la imagen, para buscar la mejor panorámica. Por esto el proceso de pegado de imágenes no es perfecto, ya que existe una cierta distancia entre los objetivos, lo que provoca algunos errores de paralaje. Este problema puede condicionar la reconstrucción tridimensional, si bien en los experimentos realizados, en los que se han escogido radios de calibrado adecuados a cada escena, no ha repercutido significativamente en los resultados. 3. Reconstrucción de una escena 3D El objetivo principal de este trabajo es la obtención de una reconstrucción tridimensional de una escena a partir de varias vistas panorámicas. Para validar el método emplearemos imágenes capturadas con un sistema Ladybug2, a las que supondremos libres de errores. El proceso de reconstrucción 3D consta de tres pasos: Captura de las imágenes, situando la cámara en una serie de ubicaciones conocidas dentro de la escena. Búsqueda de puntos distinguidos y correspondencia de los mismos entre las distintas imágenes. Reconstrucción 3D propiamente dicha, a partir de un conjunto de puntos en correspondencia y de la geometrı́a de las cámaras. 3.1. Ubicación de la cámara dentro de la escena Para comenzar con el primer paso, necesitamos determinar un punto de la escena, que servirá como origen de coordenadas, y determinar la posición y orientación de la cámara en cada punto de captura. En la Figura 2 se muestra el croquis de una de las salas en las que se han realizado experimentos. 22 Guadalupe Millán de la Blanca, Manuel J. Lucena López y José M. Fuertes Garcı́a Fig. 2 Esquema de una sala para su reconstrucción tridimensional. Para cada punto de vista se han capturado imágenes con todos los valores de calibración posibles de la cámara, con objeto de determinar la repercusión de este parámetro sobre la fiabilidad del método. 3.2. Búsqueda de correspondencias entre dos imágenes El segundo paso consiste en la búsqueda de correspondencias entre las imágenes para conocer en qué lugares de cada imagen se proyecta un mismo punto de la escena. Abordaremos este problema utilizando el método de Harris [2] para extraer los puntos de interés de dos imágenes, tomadas desde diferentes puntos de vista de una escena, y posteriormente encontrar las correspondencias existentes entre ellas. Los puntos de interés que obtengamos de cada imagen deben ser invariantes a escala, rotación y transformaciones afines, para poder encontrar el mismo punto en diferentes vistas de una misma escena. Una vez obtenidos los puntos de interés de cada imagen, hay que asociarles un descriptor para encontrar correspondencias de puntos entre ambas imágenes. 3.2.1. Método SIFT afı́n Cualquier objeto cuenta con puntos interesantes que se pueden extraer para proporcionar una descripción de las caracterı́sticas del mismo. Las caracterı́sticas Affine-SIFT (ASIFT) [4] permiten caracterizar los puntos distinguidos de una imagen de forma invariante a escala, rotación o transformaciones afines. ASIFT, a diferencia del algoritmo SIFT, representa con suficiente precisión todas las distorsiones causadas por la variación de la cámara a lo largo de un eje. ASIFT Reconstrucción de entornos tridimensionales a partir de múltiples vistas panorámicas 23 simula la escala, el ángulo de longitud y de latitud (que es equivalente a la inclinación) de la cámara, y normaliza la translación y rotación, logrando una invarianza afı́n completa. El algoritmo ASIFT genera un conjunto de vectores, cada uno de ellos asociado a un punto de interés en la imagen. Estos vectores son caracterı́sticos de ese punto de la imagen y se pueden usar para reconocer ese mismo punto en otra imagen. Cada uno de estos vectores de caracterı́sticas es invariante a cualquier escalado, rotación y transformación afı́n; y es parcialmente invariante a adición de ruido y cambios en la iluminación. 3.2.2. Emparejamiento de puntos singulares Para emparejar dos imágenes debemos encontrar elementos repetidos entre ellas, por lo tanto a partir de las caracterı́sticas determinadas mediante el algoritmo ASIFT, debemos buscar aquellas que se repiten en las dos imágenes. La comparación de caracterı́sticas se basa en la similitud de los descriptores asociados a éstas en cada imagen. Puesto que los descriptores son vectores se pueden comparar mediante la distancia euclı́dea. Debido tanto a la gran cantidad de puntos, como a la alta dimensionalidad de los mismos, obtener un emparejamiento mediante la técnica del vecino más próximo es computacionalmente muy costoso. Para aliviar esta situación, hemos empleado el método best bin first (BBF), propuesto por Beis y Lowe en 1997 [7] En general muchas de las correspondencias encontradas estarán equivocadas. Para poder eliminarlas vamos a utilizar el algoritmo RANSAC (Random Sample Consensus) [6], que trata de separar las correspondencias falsas de las correctas. Este algoritmo genera varios modelos y se queda con aquel que de lugar a menos errores. La generación de los distintos modelos se hace iterativamente. Para ello se selecciona aleatoriamente un conjunto de muestras del tamaño mı́nimo para generar un modelo y se van añadiendo uno a uno los puntos que estén cerca del modelo, actualizándolo con la información añadida. Cuando, en una iteración, el conjunto inicial contiene algún punto que realmente no pertenece al modelo, es muy difı́cil que haya puntos que estén de acuerdo con el modelo inducido por las muestras iniciales y, de haberlos, lo más probable es que provoquen un error muy alto. Además, los modelos apoyados por menos de un determinado número de puntos se descartan. 3.3. Triangulación de puntos A partir de una única imagen, la profundidad de un punto en una escena no puede ser calculada. Con al menos dos imágenes, tomadas desde diferentes puntos de vista, la profundidad puede ser medida a través de la triangulación. Esto es una 24 Guadalupe Millán de la Blanca, Manuel J. Lucena López y José M. Fuertes Garcı́a Fig. 3 Emparejamiento de puntos entre dos imágenes capturadas en dos puntos de una misma escena. de las razones por las que la mayorı́a de los animales tienen dos ojos, y por la que se equipa a los sistemas autónomos con cámaras estereoscópicas. Se define visión estereoscópica (o estéreo) como aquella en la que se emplea más de una imagen para obtener una idea de tridimensionalidad. Según el número de imágenes que se emplee, se habla de visión bifocal –dos imágenes o vistas–, trifocal –tres imágenes o vistas–, cuadrifocal –cuatro imágenes o vistas– o n-focal –n imágenes o vistas–, y en cada uno de los casos se aplica una serie de restricciones basadas en la geometrı́a. Por lo tanto, a partir del conjunto de puntos en correspondencia que tenemos y de la geometrı́a de las cámaras vamos a estimar la posición tridimensional de los puntos singulares dentro de la escena. La Figura 4 representa la situación espacial de tres puntos de captura de la escena. Cada circunferencia representa una esfera de 5m de radio, y su centro es el punto donde ha sido situada la cámara. Reconstrucción de entornos tridimensionales a partir de múltiples vistas panorámicas 25 Fig. 4 Situación de Ladybug2 (vista lateral) desde tres puntos de vista diferentes en la escena. Para poder estimar las posiciones de los puntos en el espacio trabajamos con las correspondencias entre los puntos de las imágenes capturadas desde el punto 1 y el punto 2, y las imágenes capturadas desde el punto 2 y el punto 3. Por lo tanto, trabajamos con cada emparejamiento por separado y posteriormente relacionamos los puntos en el espacio 3D de ambos. En primer lugar comenzamos con la transformación de las coordenadas (xI , yI ) de cada punto en correspondencia dentro de la imagen panorámica, a diferentes sistemas de coordenadas. Coordenadas esféricas El sistema de coordenadas esféricas se utiliza para determinar la posición espacial de un punto mediante una distancia y dos ángulos. En él, un punto P queda representado por un conjunto de tres magnitudes: el radio r, el ángulo polar o colatitud θ y el azimut ϕ (Figura 5). Puesto que la imagen representa una proyección esférica de la escena, existe una correspondencia directa y proporcional entre las coordenadas (xI , yI ) de un punto en la imagen, y los valores de θ y ϕ correspondientes, siendo irrelevante el valor r del radio, que no puede ser determinado, ya que representa la distancia del punto al centro de la esfera. Por lo tanto, la relación existente entre las coordenadas horizontales de un punto P, perteneciente a la imagen panorámica capturada con Ladybug2, y las coordenadas esféricas de este punto es la siguiente: 26 Guadalupe Millán de la Blanca, Manuel J. Lucena López y José M. Fuertes Garcı́a Fig. 5 Sistema de coordenadas esféricas. πy θ = hI ϕ = 2πvxI siendo h y v el ancho y el alto de la imagen respectivamente. (1) Coordenadas cartesianas espaciales Para representar un punto P = (r, θ , ϕ ) en un sistema cartesiano tridimensional, usaremos las siguientes expresiones: x = r · sin(θ ) · cos(ϕ ) y = r · sin(θ ) · sin(ϕ ) z = r · cos(θ ) La relación inversa es la siguiente: p r = x2 + y2 + z2 (2) (3) Reconstrucción de entornos tridimensionales a partir de múltiples vistas panorámicas θ= √ x2 +y2 arctan z 27 z>0 π 2 √ z=0 2 +y2 x z<0 π + arctan z y x>0 arctan( x ) π x=0 ϕ = 2 · sgn(y) π + arctan( xy ) x < 0 (4) (5) donde la función sgn(x) vale 1 si x > 0, y −1 si x < 0. 3.3.1. Alineación de las esferas Un paso importante es comprobar que cada par de esferas está alineado, es decir, para cada par de imágenes panorámicas, tomadas desde dos puntos de vista diferentes alineados de la escena, los pı́xeles que se encuentran en el eje que une el par de esferas tienen las mismas coordenadas asociadas en todas las imágenes. Si transformamos las coordenadas de esos puntos a coordenadas esféricas, el ángulo ϕ correspondiente a cada uno de ellos debe ser el mismo (supondremos 0 por razones de simplicidad). Si no es ası́, y asumiendo que el sistema de captura se ha colocado de forma perpendicular al plano del suelo, basta con rotar las esferas con respecto a la normal del citado plano para alinearlas. Esto se consigue aplicando el mismo desplazamiento horizontal a todos los puntos de la imagen esférica. Para facilitar esta tarea podemos marcar, si fuera posible, el punto de la escena que toca el eje sobre el que se desplazan los puntos de captura, convirtiéndolo de esta forma en un punto singular. 3.3.2. Estimación del punto en el espacio 3D Una vez calculadas las coordenadas cartesianas (x, y, z) de cada emparejamiento de puntos (empleando un valor arbitrario de r), el siguiente paso es encontrar el punto 3D correspondiente a este emparejamiento. Para ello trazamos las rectas que unen los puntos que hemos calculado con los centros de las esferas a las que pertenecen. En el caso ideal, las rectas calculadas deberı́an cortarse en el punto tridimensional de la escena que dio lugar a los puntos obtenidos de emparejar las imágenes panorámicas (Figura 6). El punto donde se intersectan las dos rectas es el punto 3D que estamos buscando. Para determinar si dos rectas se intersectan, seguiremos los siguientes pasos: Punto Ar = (xr , yr , zr ) Recta r : (6) − Vector director → ur = (a, b, c) 28 Guadalupe Millán de la Blanca, Manuel J. Lucena López y José M. Fuertes Garcı́a Fig. 6 Punto estimado correspondiente a un emparejamiento de puntos entre dos imágenes panorámicas. Recta s : Punto As = (xs , ys , zs ) − Vector director → us = (a′ , b′ , c′ ) (7) Vector que relaciona las dos rectas: −−−→ Ar As = (xs − yr , ys − yr , zs − zr ) (8) Debemos comprobar que los vectores directores de éstas no son proporcionales: b c a 6= ′ 6= ′ a′ b c −−−→ − − Y a continuación hallamos el determinante formado por: → ur , → us y Ar As Si el determinante es igual a cero, las rectas se cortan en un punto: a b c a′ b′ c′ = 0 xs − xr ys − yr zs − zr (9) (10) Reconstrucción de entornos tridimensionales a partir de múltiples vistas panorámicas 29 Para hallar el punto donde se cortan dos rectas, basta con igualar las ecuaciones paramétricas de ambas, y a partir de los parámetros t y k obtenidos calculamos el punto de corte, sustituyendo en alguna de las ecuaciones: xr + at = xs + a′ k yr + bt = ys + b′ k zr + ct = zs + c′ k (11) El problema es que la mayoria de las veces no se intesectarán, sino que se cruzarán (Figura 7), ya que estamos en un espacio tridimensional. Sabremos que dos rectas se cruzan si el determinante anteriormente calculado es distinto de 0: a b c a′ b′ c′ 6= 0 (12) xs − xr ys − yr zs − zr Fig. 7 Rectas que se cruzan, pero no se cortan, en un espacio tridimensional. El vector v, perpendicular a ambas rectas, une los puntos de distancia mı́nima entre ambas. En el caso en que las rectas se crucen, una aproximación del punto 3D que queremos calcular es el punto medio de la perpendicular común que corta las dos rectas, ya que la perpendicular común coincide con la distancia mı́nima entre las dos rectas (Figura 8). Para calcular la perpendicular común entre dos rectas que se cruzan, tenemos que calcular los dos puntos de corte de esta perpendicular con ambas rectas, y a partir de estos puntos obtenemos el punto medio entre ambos. Sabemos que el producto escalar de dos vectores perpendiculares es cero, por lo que: → − − ur · → v =0 → − → us · − v =0 (13) 30 Guadalupe Millán de la Blanca, Manuel J. Lucena López y José M. Fuertes Garcı́a Fig. 8 Punto medio de la perpendicular común entre dos rectas que se cruzan. Sustituyendo, obtenemos: 3.3.3. v = Qr − Qs = Pr + ur t − Ps + us k (14) (ur · ur )t − (ur · ur ) = Pr + ur t − Ps + us k (15) Punto 3D correspondiente a dos emparejamientos También podemos obtener una triangulación 3D a partir de dos emparejamientos que coincidan en un punto. Para calcular el punto 3D buscado, hay que identificar los puntos que están presentes en ambos emparejamientos (Figura 9). Para cada punto coincidente obtenemos tres rectas, que deberı́a cortarse en un punto del espacio tridimensional. El punto donde se intersectan las tres rectas es el punto 3D que estamos buscando. El problema es que la mayoria de las veces no se intesectarán las tres rectas, ya que estamos en un espacio en 3D. Podemos encontrarnos tres casos: 1. Que se intersecten las tres rectas. 2. Que haya intersecciones y cruces. 3. Que se crucen las tres rectas. Intersección de las tres rectas Si las rectas intersectan todas en el mismo punto, serı́a el caso óptimo, calculamos este punto tal y como hemos explicado anteriormente. Si dos de las rectas intersectan con la otra en diferentes puntos, calculamos estos dos puntos y escogemos el punto medio del segmento que los une (Figura 10). Reconstrucción de entornos tridimensionales a partir de múltiples vistas panorámicas Fig. 9 Punto 3D correspondiente a dos emparejamientos entre tres imágenes panorámicas. Fig. 10 Intersección de dos rectas en dos puntos diferentes P1 y P2 . 31 32 Guadalupe Millán de la Blanca, Manuel J. Lucena López y José M. Fuertes Garcı́a Intersección y cruce En este caso escogemos el punto medio entre el punto de intersección de dos de las rectas y el de cruce de las otras dos (Figura 11). Fig. 11 Intersección y cruce de dos rectas. Cruce de tres rectas Debemos calcular la perpendicular común entre todas las rectas, con lo que obtenemos tres rectas y a cada una de estas rectas le calculamos su punto medio (Figura 12). Estos tres puntos medios forman un triángulo, por lo que para hallar nuestro punto 3D calculamos el baricentro de este triángulo. El problema de utilizar tres rectas para obtener un punto 3D a partir de dos emparejamientos es que vamos acumulando mucho error y si se inserta otro emparejamiento se acumula mucho más al tener una nueva recta. Por este motivo, para calcular un punto 3D a partir de más de dos emparejamientos debemos calcular puntos 3D de emparejamiento en emparejamiento y después comprobar si los puntos encontrados son coincidentes, si es ası́ nos quedaremos con el punto que contenga menor incertidumbre. En el apartado siguiente se explica este método con más detalle. 3.3.4. Punto 3D correspondiente a n emparejamientos Para calcular un punto 3D a partir de n emparejamientos, en primer lugar calculamos el punto correspondiente a cada emparejamiento, con lo que obtenemos n Reconstrucción de entornos tridimensionales a partir de múltiples vistas panorámicas 33 Fig. 12 Cruce de tres rectas 3D. puntos 3D. A continuación comprobamos que al menos dos de estos n puntos son coincidentes, es decir, son iguales o casi iguales. El punto que buscamos corresponderá a la ubicación tridimensional del emparejamiento que esté más cerca de los centros de las esferas de las que sale, ya que cuanto más cerca esté el punto estimado del centro de su esfera, menor será el error cometido. 3.4. Reconstrucción de la estructura a partir de los puntos triangulados El método propuesto permite obtener una nube dispersa de puntos, a partir de las diferentes vistas que hayan sido capturadas. Si queremos llevar a cabo una verdadera reconstrucción del entorno, deberemos construir un conjunto de superficies a partir de ellos, para poder asignar una posición en el espacio a todos los pı́xeles que proporciona el dispositivo de captura. Para ello, seleccionaremos todos los puntos triangulados cuyo nivel de incertidumbre se encuentre por debajo de un umbral dado, e interpoalremos una serie de planos sobre los mismos. Seguidamente, podremos proyectar los pı́xeles de las capturas sobre esos planos, calculando la intersección entre la recta que define cada pı́xel y el plano correspondiente. 34 4. Guadalupe Millán de la Blanca, Manuel J. Lucena López y José M. Fuertes Garcı́a Resultados obtenidos La metodologı́a explicada se ha aplicado en dos escenarios distintos, con las siguientes caracterı́sticas: Interior. Correspondiente a una sala, con 8 capturas con radio r = 2m. Los puntos de captura están situados a lo largo de una recta, y separados 50cm entre sı́. Exterior. Correspondiente a la entrada de un edificio, en este escenario se observa la fachada de dos edificios, uno de ellos con una escalinata. Se han realizado 12 capturas, con radio r = 10m, y con los puntos de captura separados 50cm etnre sı́, a lo largo de una lı́nea recta. En la Figura 13 puede verse la nube de puntos obtenida de la escena de interior. Como puede verse, el método propuesto permite detectar y ubicar correctamente la pared que contiene los cuadros, que es al fin y al cabo la que presenta unos emparejamientos más fiables. La Figura 14 muestra los resultados para la escena de exterior. En ella se aprecian claramente los planos correspondientes a las fachadas de los dos edificios, y un tercero asociado a la escalinata que hay a la entrada de uno de ellos. Fig. 13 Resultado para la escena de interior. Reconstrucción de entornos tridimensionales a partir de múltiples vistas panorámicas 35 Fig. 14 Resultado para la escena de exterior. 5. Conclusiones Mediante el método propuesto, hemos comprobado que es posible realizar una reconstrucción aproximada de un escenario tridimensional, a partir de una serie de capturas hechas con un dispositivo que originalmente no fue diseñado para esta tarea. El nivel de precisión obtenido depende mucho de las caracterı́sticas del dispositivo de captura, pero empleando una medida de incertidumbre e incluyendo múltiples vistas, puede aislarse un conjunto de puntos suficiente como para interpolar determinadas estructuras en la escena. Se hace necesario no obstante que aparezcan suficientes puntos singulares, que puedan detectarse y emparejarse correctamente a lo largo de las diferentes capturas. Si bien el método propuesto no permite reconstrucciones muy completas o precisas, sı́ puede servir para obtener una primera aproximación a la geometrı́a del entorno, especialmente si tenemos algún tipo de conocimiento a priori sobre la forma –plana, curvada, etc.– de los diferentes elementos que lo componen. Referencias 1. L. Alvarez and F. Morales: Affine morphological multiscale analysis of corners and multiple junctions. International Journal of Computer Vision, 25(2), pp. 95–107, 1997. 36 Guadalupe Millán de la Blanca, Manuel J. Lucena López y José M. Fuertes Garcı́a 2. C. Harris and M. Stephens: A Combined Corner and Edge Detector. Proceedings of 4th Alvey Vision Conference, pp. 147–151, 1988. 3. D. Lowe: Object recognition from local scale-invariant features. In International Conference on Computer Vision, pp. 1150–1157, 1999. 4. D. Lowe: Distinctive image features from scale-invariant keypoints. International Journal of Computer Vision, 60(2), pp. 91–110, 2004. 5. P.R. Beaudet: Rotational invariant image operators. In Proc. of the 4th. International Conference on Pattern Recognition, pp. 579–583, 1978. 6. M.A. Fischler and R.C. Bolles: Random Sample Consensus: A Paradigm for Model Fitting with Applications to Image Analysis and Automated Cartography. Comm. of the ACM, Vol 24, pp. 381–395, 1981. 7. J.S. Beis and D. Lowe: Shape indexing using approximate nearest-neighbour search in highdimensional spaces. Conference on Computer Vision and Pattern Recognition. pp. 1000–1006, 1997. 8. Point Grey Research, Inc. http://www.ptgrey.com Bloque II Terrenos Visualización adaptativa de grandes terrenos a través de redes celulares José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez Resumen Los dispositivos móviles, tales y como PDAs o teléfonos inteligentes son ubicuos y cada vez más potentes. En la actualidad es frecuente su uso como guı́as interactivas de entornos reales, y ofrecen caracterı́sticas tales como posicionamiento global (por ejemplo, mediante GPS), acceso a bases de datos espaciales, visualización de mapas y de terrenos. La visualización de terrenos en 3D es una tecnologı́a de gran importancia en un amplio conjunto de campos, entre los que destacamos la navegación personal y los Sistemas de Información Geográfica 1 . En este Capı́tulo describimos una técnica para la visualización remota de terrenos en dispositivos móviles que emplea redes inalámbricas con ancho de banda reducido, tal como GPRS o UMTS. 1. Introducción En la actualidad es frecuente la utilización de tecnologı́as móviles como guı́as interactivas de entornos reales, y ofrecen caracterı́sticas tales como posicionamiento global (por ejemplo, mediante GPS), acceso a bases de datos espaciales, visualización de mapas y de terrenos. A continuación describiremos una técnica para la visualización remota de terrenos en dispositivos móviles s través de redes inalámbricas con ancho de banda reducido (GPRS o UMTS). La Figura 1 ilustra el marco de trabajo general de nuestra propuesta. Proponemos una técnica de visualización cliente-servidor hı́brida. El cliente visualiza la geometrı́a del terreno próxima al observador, mientras que el terreno distante es representado mediante impostores. Estos impostores son generados por el servidor y enviados al cliente a través de la red. Debido a que los impostores representan terreno alejado del observador, no necesitan ser actualizados salvo que la posición del observador dentro del entorno virtual varı́e por encima de un cierto 1 Es muy habitual el uso del acrónimo GIS, del inglés Geographic Information System. 39 40 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez Localización Satélite GPS Localización Localización Datos Terreno Datos Terreno Interacción Datos Terreno 2D & 3D Servidor Red Celular Dispositivo Móvil Cliente Usuario Fig. 1 Marco de trabajo general de trasmisión de terrenos en dispositivos móviles. umbral prefijado. Esta técnica proporciona las herramientas necesarias para dividir la carga de visualización entre cliente y servidor, teniendo en cuenta los recursos disponibles en el cliente y la congestión de la red. El terreno se subdivide en bloques, y cada bloque se organiza siguiente una estructura de datos jerárquica. Este acercamiento permite hacer frente a la limitada memoria principal disponible en los dispositivos móviles, y brinda la posibilidad de emplear niveles de detalle. El cliente tan solo necesita descargar desde el servidor la cantidad más pequeña posible de bloques de terreno que le permitan visualizar la escena con un nivel de detalle adecuado en función de la vista actual. Los bloques adyacentes a distinto nivel de detalle se unen entre sı́ sin discontinuidades geométricas mediante el uso adaptativo de tiras de triángulos pre-calculadas. Esta técnica de visualización es simple, rápida y plenamente compatible con la naturaleza distribuida de nuestra aplicación. 2. Elementos de Visión en 3D En Informática Gráfica es habitual trabajar con objetos tridimensionales. No obstante, para poder visualizar un objeto 3D en una pantalla bidimensional es necesario introducir previamente una proyección que transforme al objeto 3D en una proyección del mismo en un plano 2D. En esta Sección repasaremos conceptos básicos acerca de proyecciones que serán de utilidad en secciones posteriores. En [9] puede encontrarse un estudio en profundidad sobre visión 3D. Para visualizar objetos 3D es necesario definir tres conceptos: Un volumen de visión en el mundo 3D. Una proyección sobre el plano de proyección. Una ventana de visión sobre el plano de proyección. En un primer paso, la geometrı́a de cada objeto en el mundo 3D se recorta contra el volumen de visión 3D. Aquella geometrı́a que supera este paso se proyecta sobre Visualización adaptativa de grandes terrenos a través de redes celulares 41 Fig. 2 Plano y ventana de proyección. el plano de visión y se transforma sobre la ventana de visión 2D para su visualización. Como nuestra intención es imitar la forma en la que los ojos humanos perciben el mundo 3D, emplearemos una proyección en perspectiva donde el centro de proyección sea coincidente con la posición del observador o cámara. El plano de proyección se sitúa de tal forma que su normal viene dada por el vector de dirección de la lı́nea que cruza el punto de visión, la lı́nea de visión y atraviesa el punto de referencia. Este plano de proyección también se conoce como plano de visión. El plano de visión puede situarse en cualquier lugar en relación con los objetos 3D a ser proyectados. También es necesario definir una ventana sobre el plano de visión de tal manera que su contenido sea traspasado a la pantalla. La Figura 2 ilustra estos conceptos. Bajo estas condiciones, el volumen de visión es una pirámide rectangular cuya cúspide se encuentra en la posición de la cámara y sus aristas atraviesan las esquinas de la ventana de visión. Las cuatro caras laterales de la pirámide definen los planos de recorte laterales. El volumen de visión se encuentra limitado a lo largo de la dirección de visión mediante el plano de recorte delantero y el plano de recorte trasero. Ambos planos son paralelos al plano de visión y se encuentran respectivamente a una distancia z f ront y zback relativa a la cámara y medida a lo largo de la lı́nea de visión, [9]. La Figura 3 muestra un ejemplo de volumen de visión. Entre los elementos matemáticos de la proyección en perspectiva, estamos interesados en recordar cómo se proyecta un punto 3D. En este trabajo, asumiremos que el plano de proyección se encuentra a una distancia d de la posición de la cámara. Esta distancia es conocida como distancia focal de la cámara. Es fácil ver que si P(x, y, z) es un punto 3D, entonces su proyección Pp en el plano de proyección (ver Figura 2) vendrá dada por las ecuaciones, 42 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez Fig. 3 El volumen de visión se representa en color gris. Ppx = Px d ; Pz d Pz (1) Py Pz /d (2) Ppy = Py En ocasiones, estas ecuaciones se expresan como Ppx = Px ; Pz /d Ppy = Nótese que la distancia d es tan solo un factor de escala para las coordenadas Px y Py . Además, la división por la coordenada Pz provoca que la proyección en perspectiva de objetos distantes sea más pequeña que la proyección de objetos más próximos a la cámara. 3. Visualización de Terrenos en Dispositivos Móviles A pesar de que algunos autores ya señalaron la necesidad de desarrollar métodos de visualización de terrenos capaces de funcionar de forma interactiva en entornos con recursos limitados, [27], la tendencia ha sido claramente la opuesta. Los algoritmos de visualización de terrenos han crecido tanto en complejidad como en requerimientos de cómputo. Por tanto, la visualización adaptativa de grandes terrenos a través de red en dispositivos móviles es todavı́a un campo muy poco explorado. Hasta donde alcanza nuestro conocimiento, las soluciones de visualización de terrenos propuestas en la literatura no consideran las dos propiedades que caracterizan a los dispositivos móviles: redes inalámbricas con bajo ancho de banda, y capacidades de cómputo limitadas. Visualización adaptativa de grandes terrenos a través de redes celulares 3.1. 43 Terrenos en Entornos Cliente-Servidor La mayorı́a de los métodos de visualización de terrenos en tiempo real asumen que el conjunto de datos del terreno puede alojarse completamente en memoria principal o virtual, y no consideran explı́citamente la carga de terreno de forma dinámica desde un servidor remoto [23]. Esta suposición es inasumible en el entorno de la computación móvil. La mayorı́a de los sistemas operativos para dispositivos móviles no soportan memoria virtual, o carecen directamente de memoria secundaria. Es más, la memoria principal es tan limitada que la complejidad del modelo a visualizar se restringe considerablemente. Para que un método de visualización de terrenos pueda emplearse en un entorno móvil, el conjunto de datos del terreno debe almacenarse en un servidor remoto. La mayorı́a de las técnicas de visualización de terrenos que contemplan su uso en entornos cliente-servidor se ajustan a la clasificación de métodos de visualización en el lado del cliente. Las técnicas que emplean niveles de detalle continuos necesitan considerar cada vértice o triángulo del terreno para generar la malla de triángulos a visualizar. Por tanto, es requisito que toda la geometrı́a a su mejor nivel de detalle posible este accesible simultáneamente. Esto supone un problema cuando el tamaño del modelo del terreno excede el tamaño de la memoria del dispositivo. Lindstrom et al. [17, 18] presentó una técnica para la visualización de terrenos multirresolución cuyo tamaño excede el tamaño de la memoria principal. Su enfoque consiste explotar la gestión de memoria virtual que proporcionan los sistemas operativos modernos. Desgraciadamente, esta técnica no es aplicable a dispositivos móviles, puesto que éstos suelen carecer de memoria virtual y de memoria secundaria suficiente como para almacenar un DTM complejo. Pajarola [22] y Pouderoux [24], debido a la imposibilidad de alojar el conjunto de datos completo en memoria principal, utilizan un sistema de paginación de terrenos a través de red. Su funcionamiento emplea el concepto de ventana deslizante para mantener dinámicamente en memoria un conjunto visible de bloques de terreno. Los bloques de terreno son cargados de disco o de red bajo demanda. Todas las soluciones que se basan en bloques de terreno permiten que cada bloque pueda cargarse de forma independiente desde disco o a través de red, por lo que pueden emplearse de forma natural para la visualización de grandes terrenos en entornos cliente-servidor. Dentro de éstas, las soluciones basadas en árboles de bloques permiten la carga progresiva de niveles de detalle desde disco o red. Esto es, descargar el bloque raı́z del árbol permite dibujar completamente el terreno a su nivel de detalle más bajo. Si se requiere mayor calidad, el resto de niveles del árbol pueden descargarse de forma progresiva. El BDAM, presentado por Cignoni et al. [10] asume que todo el conjunto de datos está almacenado en una unidad de almacenamiento secundario, por tanto debemos considerarlo como una técnica de visualización local. No obstante, Gobbetti [11] y Bettio [2] adaptaron BDAM a su uso en red, permitiendo a un servidor remoto alojar la geometrı́a. Estas técnicas hacen uso de algoritmos de compresión con pérdida 44 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez mediante la transformada óndula (wavelet) que incrementan los requerimientos de CPU del cliente. Además, ambas técnicas precisan de una GPU programable. Lerbour et al. [14] describe una arquitectura en red para la descarga y visualización remota de terrenos. Primeramente, el terreno se subdivide en un árbol de bloques, donde cada bloque contiene un conjunto de niveles de detalle con resolución creciente. Cada nivel de detalle añade nuevos valores de altura que no estaban presentes en el nivel anterior. El cliente lee los bloques desde un servidor remoto de forma adaptativa y bajo demanda. Mediante operaciones de fusión o división entre los valores de altura contenidos en los niveles de detalle de cada bloque, se obtiene de forma adaptativa el mapa de alturas a la resolución deseada. Esta estructura fue ideada con el objetivo principal de evitar la descarga de datos redundantes. En [15], los autores expanden su trabajo para permitir el envı́o de texturas y evitar discontinuidades geométricas entre bloques de terreno adyacentes a distinto nivel de detalle. No obstante, no se proponen soluciones para la paginación de terrenos en memoria. 3.2. Uso del Hardware Gráfico Móvil Actualmente, cada vez más dispositivos móviles de gama alta incluyen GPU. No obstante, es de esperar que esta tendencia no se extienda a dispositivos de gama media y baja, donde un precio más reducido es mejor reclamo para atraer a un segmento de mercado relativamente poco interesado en la tecnologı́a. Además, es destacable el hecho de que dispositivos móviles tan notables como Nintendo 3DS incorporen una GPU no programable. Por tanto, cualquier técnica moderna de visualización de terrenos orientada a dispositivos móviles ha de ser capaz de explotar la potencia de cómputo de la GPU, pero también de ofrecer un rendimiento suficiente en su ausencia o si ésta no es programable. Las GPUs móviles están optimizadas para dibujar tiras de triángulos [25]. Una tira de triángulos es un tipo de primitiva que almacena un conjunto de triángulos adyacentes de forma compacta. Los tres primeros vértices de la tira representan un triángulo. Cada sucesivo vértice que se añada a partir del tercero genera un nuevo triángulo. Este triángulo se dibuja empleando dicho vértice y sus dos vértices precedentes. De esta forma, pueden enviarse grandes conjuntos de triángulos a la GPU sin redundancia de vértices. La mayorı́a de las soluciones que trabajan con bloques de terreno emplean largas tiras de triángulos. Usualmente, para visualizar cada bloque se utiliza un pequeño número de tiras. Estas tiras pueden generarse al vuelo [16, 28, 22], calcularse en una etapa de procesamiento previo [10] u obtenerse mediante máscaras de ı́ndices [24, 19, 15, 13] Otro factor a considerar es el que algunas soluciones presentes en la literatura emplean los abanicos de triángulos como primitiva geométrica, [28, 30]. Estas soluciones suelen ser más fáciles de implementar y adaptarse bien a los quad-trees. No obstante, suelen generar un elevado número de primitivas individuales. Este tipo de técnicas deben evitarse cuando se trabaja con dispositivos móviles por dos razones: Visualización adaptativa de grandes terrenos a través de redes celulares 45 El envı́o de una gran cantidad de primitivas pequeñas suponen un mayor tránsito de datos CPU-GPU y un consiguiente peor desempeño. Algunas librerı́as para gráficos en dispositivos móviles solo aceptan tiras de triángulos como única primitiva. Esto ocurre en M3G [18]. Otra forma importante de aumentar el rendimiento de la GPU consiste en reducir el número de transferencias de geometrı́a entre la CPU y la GPU. Para conseguir esta reducción hay que almacenar la geometrı́a en la memoria de la GPU, y reutilizarla en tanto y en cuanto ésta no cambie. La mayorı́a de las técnicas basadas en bloques de terreno hacen uso de este principio. La geometrı́a que representa a cada bloque se almacena en memoria de la GPU y no se actualiza salvo que sea necesario modificar el nivel de detalle del bloque. Pajarola [22] propuso una solución basada dividir el terreno en una rejilla regular de bloques, y para cada bloque construir una triangulación en forma de quad-tree restrictivo. Esta triangulación se representa mediante una única tira de triángulos, que se genera mediante un recorrido recursivo de la jerarquı́a del quad-tree. Esta representación no es la más apropiada para una GPU debido a que requiere la reconstrucción de la malla y su reenvı́o a la GPU en cada marco de animación. Para atenuar este problema, Pajarola propuso retrasar el recálculo de la malla de triángulos de cada quadtree hasta que el error cometido supere un cierto umbral. Por último, es importante señalar que la mayorı́a de las técnicas más recientes requieren de una GPU programable, véase [20, 1, 30, 6, 19, 8] solo por citar algunos ejemplos. Salvo que deseemos limitar nuestras aplicaciones a dispositivos móviles de gama muy alta, este tipo de técnicas deberı́an evitarse. 3.3. Soluciones Especı́ficas para Dispositivos Móviles Pouderoux et al. [24] propuso un sistema de paginación muy simple, basado en rejillas de bloques, y especı́ficamente diseñado para dispositivos móviles. El terreno a su máxima resolución es dividido en un conjunto de bloques. El cliente descarga aquellos bloques situados alrededor de la posición del observador. Cada bloque descargado contiene todos los vértices necesarios para dibujarse a su máxima resolución. Para poder dibujar el terreno de forma adaptativa, se genera un conjunto de máscaras que permite visualizar los bloques a diversas resoluciones. A la hora de mostrar el terreno, se determinan los bloques visibles, y para cada uno de ellos se aplica la máscara adecuada en función del nivel de detalle deseado. Una máscara consiste en un vector de ı́ndices que indica a la librerı́a gráfica cómo unir los vértices del bloque para formar una tira de triángulos. Los autores afirman que consiguen visualizar una escena de 3744 triángulos a una velocidad de 7 animaciones por segundo en un dispositivo PocketPC Toshiba e800, empleando como medio de conexión una red cableada USB 2.0 a 480 Mbps. Esta técnica, aunque rápida en dispositivos muy poco potentes, es burda y padece ciertos inconvenientes. No se emplea una estructura jerárquica multirresolución, lo que impide la transmisión progresiva de bloques de terreno. Es decir, para visuali- 46 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez zar un bloque de terreno (incluso a su menor nivel de detalle), han debido descargarse previamente todos sus vértices. Además, no se resuelven las discontinuidades geométricas entre bloques adyacentes a distinto nivel de detalle. Esto hace que esta técnica no sea adecuada en la mayorı́a de las aplicaciones. De una forma similar, Wen et al. [33] también divide el mapa de alturas en una rejilla de bloques, pero cada bloque se representa mediante un quad-tree. Desgraciadamente, la vaga descripción que ofrece el artı́culo de la técnica, junto con la ausencia de una adecuada evaluación de rendimiento, no nos permite juzgar correctamente esta propuesta. Por último, se trata de una técnica de visualización local, puesto que no se aborda el problema del envı́o de terreno cliente-servidor. 4. El Método Hı́brido En esta sección describiremos nuestro método para realizar la descarga y visualización de terrenos en dispositivos móviles. Este método está especı́ficamente diseñado para utilizar redes comerciales de bajo ancho de banda, por ejemplo, GPRS y UMTS. Básicamente, nuestro método consiste en una técnica de visualización hı́brida que reparte las tareas de visualización entre un servidor remoto, generalmente dotado de grandes recursos tanto software como hardware, y un cliente móvil, usualmente con recursos muy limitados. Las principales tareas realizadas por el servidor son: 1. El almacenamiento del terreno. 2. Proporcionar al cliente aquellos bloques de terreno que estén cercanos a la posición del usuario y que sean necesarios para su visualización. 3. La generación y envı́o al cliente de imágenes bidimensionales que sirvan para reemplazar la proyección de la geometrı́a del terreno situada lejos de la posición del observador. En Informática Gráfica, estas imágenes bidimensionales pre-generadas que se emplean en lugar de geometrı́a 3D real reciben el nombre de impostores. Por otro lado, las principales tareas del cliente son las siguientes: 1. La visualización en tiempo real del terreno situado cerca de la posición del usuario. Esta visualización se realiza conforme al nivel de detalle requerido. 2. La visualización del impostor que reemplaza a el terreno real situado en el fondo de la escena. 3. Conforme el usuario varı́e su posición, solicitar al servidor actualizaciones tanto del terreno como del impostor. La frecuencia de estas peticiones pueden ajustarse de acuerdo a la capacidad del cliente, el estado de congestión de la red y la calidad de visualización requerida. En resumen, nuestro enfoque de visualización hı́brido de terrenos ofrece las siguientes ventajas: Visualización adaptativa de grandes terrenos a través de redes celulares 47 Fig. 4 Ejemplo de estructura de datos de un quadtree. Los nodos representados en gris son nodos hoja. Los nodos en blanco son nodos internos. El área de terreno a ser dibujada por el cliente puede ser menor sin que ello repercuta en una reducción de la distancia de visualización. El servidor puede emplear cualquier tipo de técnica de visualización de terrenos para la generación de los impostores, incluidas aquellas basadas en la GPU. No es necesario la generación de impostores a alta resolución, ya que las pantallas de los dispositivos móviles son pequeñas, usualmente con resoluciones de 320×240 y 640×480 pı́xeles. Este hecho permite ahorrar ancho de banda y reducir el cómputo en el servidor. 5. El Terreno La descarga y visualización adaptativa de grandes superficies de terreno en dispositivos móviles requiere emplear algoritmos y estructuras de datos que hayan sido especı́ficamente adaptados. Debido a que tanto los recursos de CPU como de memoria son muy limitados en los dispositivos móviles, nuestros algoritmos y estructuras de datos han sido diseñados persiguiendo la simplicidad, eficiencia y escalabilidad. 5.1. El QuadTree Restrictivo El término árbol cuaternario o quadtree [29] se emplea para describir una clase de estructuras de datos jerárquicas bien conocidas basadas en el principio de descomposición recursiva del espacio. Los quadtrees se emplean habitualmente para dividir un dominio inicial consistente en un espacio cuadrado de dos dimensiones en un conjunto de cuadrados anidados mediante su sucesiva división recursiva en cuatro cuadrantes. La estructura de datos de un quadtree consiste en un árbol en el que cada nodo tiene exactamente o cuatro nodos descendientes o ningún nodo descendiente. En el primer caso, el nodo recibe el nombre de nodo interno, y en el segundo se le conoce como nodo hoja, ver Figura 4. 48 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez (a) (b) Fig. 5 Ejemplos de: a) Quad-tree no restrictivo. b) Quad-tree restrictivo. El uso del quadtree para la triangulación y visualización de superficies implica seguir los siguientes pasos: 1. Obtener una rejilla uniforme de muestras de la superficie. 2. Evaluar cada región con respecto a algún criterio de aceptación (métrica de aproximación del error). 3. Dividir en cuatro cuadrantes iguales las regiones inaceptables. 4. Repetir los pasos 2 y 3 hasta que se satisfaga el criterio de aceptación en toda la superficie del terreno. 5. Generar una malla de triángulos por cada región del quadtree y visualizarla. Un quadtree restrictivo [7] es una descomposición jerárquica del espacio que deriva de la estructura de datos del quadtree. No obstante, se añade una restricción adicional que implica que cuadrantes adyacentes pueden diferir en como máximo un nivel en la jerarquı́a del quadtree, ver Figura 5. En este caso, decimos que el árbol está localmente equilibrado. 5.2. Estructura de Datos propuesta A continuación describimos nuestra estructura de datos para representar la representación del terreno. Nuestra propuesta se organiza de acuerdo a dos niveles diferentes: 1. Primer nivel. Este nivel subdivide el conjunto completo del terreno en una rejilla de bloques del mismo tamaño. Cada bloque contiene una región cuadrada del mapa de alturas que incluye (2n + 1) × (2n + 1) valores de altura, siendo n un Visualización adaptativa de grandes terrenos a través de redes celulares 49 Fig. 6 Subdivisón del terreno. Los puntos del terreno en un nodo del quadtree a un nivel de detalle l y los puntos incluidos en un nivel de detalle l + 1. número entero mayor que cero. Los bloques adyacentes comparten los valores de altura situados en las fronteras comunes. 2. Segundo nivel. Consiste en generar un conjunto de quadtrees restrictivos, [7], donde cada quadtree está asociado a un bloque de terreno. Los quadtrees empleados dividen el terreno en una estructura jerárquica de bloques de terreno, y por tanto, pertenecen a la familia de métodos de visualización de terrenos mediante árboles de bloques. El nodo raı́z del quadtree almacena la representación del terreno con el menor nivel de detalle, l = 0, incluyendo (2n0 + 1) × (2n0 + 1) valores de altura con n0 ≤ n. Entonces, el bloque de terreno almacenado en el nodo raı́z del quadtree se subdivide en otros cuatro bloques de terreno cuadrados y del mismo tamaño, definidos por los dos bisectores perpendiculares del bloque de terreno padre. Estos cuatro bloques conforman los cuatro nodos hijos del nodo raı́z del quadtree. Cada nodo resultante de la subdivisión añade un conjunto de puntos del terreno que no estaban incluidos en el nivel anterior. En nuestra solución, cada nuevo nivel de la jerarquı́a del quadtree dobla el número de puntos de la rejilla en ambas dimensiones en comparación con el nivel anterior. Por tanto, el número total de puntos empleados se cuadriplica. El número especı́fico de puntos añadidos en cada nuevo nivel es constante y depende del valor inicial de n0 . La Figura 6 ilustra esta idea para n0 = 2. Nótese que, tras la subdivisión, la disposición de los puntos en la rejilla se preserva, y por tanto, la misma regla de subdivisión puede emplearse en divisiones subsiguientes. Este proceso de subdivisión continúa de forma recursiva, y termina cuando el nivel de detalle alcanza la mayor precisión posible, esto es, cuando los nodos del quadtree incluyen todos los puntos del terreno. 50 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez Fig. 7 Conjuntos de puntos visualizados. a) Al nivel de detalle l = 0. b) Al nivel de detalle l = 1. c) Al nivel de detalle l = 2. La Figura 7 muestra los nodos del quadtree para un ejemplo de terreno con n = 3, n0 = 1 y l ∈ [0 . . . 2]. Las texturas asociadas con el terreno también se organizan con una estructura de quadtree definida como anteriormente. Nuestra estructura de datos ofrece las siguientes ventajas: Trabajos como [10, 14, 8] emplean un único quadtree. Nuestro trabajo, en cambio, divide el terreno en un conjunto de bloques y genera un quadtree para cada uno de ellos. Ası́, los quadtrees resultantes tienen menor altura y resulta posible emplear técnicas de paginación de terrenos. La estructura permite tanto la visualización como la trasmisión. Los quadtrees son estructuras multirresolución que permiten de forma natural y dinámica elegir el nivel de detalle que mejor se adecúe a las necesidades de la aplicación. El terreno se visualiza mediante largas tiras de triángulos, cuya longitud depende del valor de n0 . Estas tiras pueden alojarse en memoria de vı́deo, lo que resulta altamente eficiente en GPUs móviles [25, 31]. Los recursos de CPU requeridos para manejar la estructura son bajos. Además, no se requiere GPU programable. Cada nodo puede visualizarse de forma independiente. Los quadtrees pueden trasmitirse de forma progresiva, comenzando desde los nodos raı́z. Una vez que una raı́z ha sido recibida, toda el área de terreno cubierta por el correspondiente quadtree puede visualizarse a su menor nivel de detalle. A partir de ese momento, la calidad comienza a incrementarse conforme los sucesivos niveles de detalle se van recibiendo. Tı́picamente, los mapas de alturas de distintas regiones se proporcionan con diferentes resoluciones. Como nuestra estructura almacena una rejilla de quadtrees independientes, la altura de cada uno de éstos puede ajustarse de acuerdo con la resolución disponible en el área cubierta por el quadtree. Visualización adaptativa de grandes terrenos a través de redes celulares 5.3. 51 Base de Datos del Servidor La base de datos del servidor consiste en dos componentes. El primer componente comprende tanto el mapa de alturas del terreno como las texturas asociadas. Ambas se alojan en el disco duro del servidor, para lo cual se emplea la estructura de datos descrita previamente. El segundo componente consiste en una tabla hash indexada por los identificadores de los quadtrees. Esta tabla se emplea para determinar rápidamente el nombre del fichero que contiene un quadtree dado. Cada uno de los nodos de quadtree recibe una clave que lo identifica de forma única dentro de la estructura de datos. Esta clave está formada por dos partes bien diferenciadas. La primera de ellas consiste en un número entero que identifica el quadtree al que pertenece el nodo. Cada uno de los quadtrees que forman parte de la rejilla se enumera de forma secuencial. La segunda parte de la clave, en cambio, identifica a cada nodo individual dentro del quadtree al que pertenece. Esta parte de la clave consiste en una cadena de caracteres definida de acuerdo a la codificación Morton, [21]. Cada uno de los caracteres de la cadena toma un valor dentro de {0, 1, 2, 3}. Comenzando por el nodo raı́z, cada carácter denota sucesivamente el cuadrante en el que se localiza el nodo en la jerarquı́a del árbol. Ası́, la longitud total de esta cadena representa la profundidad del nodo en el quadtree. Las Figuras 8a y 8b ilustran los códigos para un quadtree de tres niveles. Desde el punto de vista del servidor, el conjunto de datos no es más que una base de datos con un par de claves para identificar unı́vocamente a un bloque de bytes que contiene los valores de altura y la textura de un nodo de quadtree. Esto significa que es posible emplear un gestor de base de datos ordinario. No obstante, hemos implementado nuestro propio gestor de almacenamiento, optimizado para almacenar nuestra estructura. Durante una etapa de pre-procesamiento, construimos la rejilla de bloques de terreno y de texturas. Para cada bloque, se construye un quadtree completo y equilibrado que contiene tanto terreno como textura. Entonces, cada uno de estos quadtrees se serializa en un fichero independiente. Cada fichero comienza con una cabecera de metadatos que describe al quadtree almacenado a continuación. Estos metadatos incluyen el identificador del quadtree, el tamaño del mapa de alturas cubierto por el quadtree, el número de valores de altura almacenados en cada nodo, las coordenadas UTM de la esquina inferior izquierda del bloque del terreno, y la distancia (en metros) entre valores de altura adyacentes. Nuestro enfoque, de manera similar a [18, 10, 14], optimiza la disposición de datos geométricos para mejorar la coherencia de memoria y el rendimiento en las operaciones de entrada/salida. Para minimizar el número de accesos a disco, los datos de los ficheros se almacenan de acuerdo al orden de recorrido del árbol. Esto es, los registros de los ficheros se almacenan conforme a los niveles del quadtree. El primer registro corresponde al nodo raı́z. Para cada nivel, los nodos se ordenan conforme a su código Morton asociado. Véase las Figuras 8b y 8c. De esta forma, nodos hermanos siempre se almacenan consecutivamente en disco, permitiendo su recuperación conjunta mediante una única operación de lectura. Nótese además que, dentro de un quadtree dado, el tamaño de cada nodo es constante. Por tanto, 52 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez 000 001 010 011 002 003 012 013 020 021 030 031 022 023 032 033 (a) 0 00 000 001 01 002 003 010 011 02 012 013 020 021 03 022 023 030 031 032 033 (b) Cabecera 0 00 01 02 03 000 001 002 003 010 011 012 013 ... 333 (c) Fig. 8 a) Códigos Morton para el tercer nivel de un quadtree. b) Códigos Morton para cada nivel del quadtree. c) Organización del fichero que almacena un quadtree. esta organización en disco permite calcular en tiempo constante la posición de un nodo concreto dentro del fichero. Por último, señalar que los valores de altura se discretizan y se almacenan como valores enteros de 2 bytes. 5.4. Base de Datos del Cliente La base de datos del cliente, al igual que su homóloga del servidor, almacena una rejilla de quadtrees. No obstante, esta rejilla constituye solo un pequeño subconjunto del total disponible en la base de datos del servidor. Este subconjunto define un área de terreno cuadrada centrada en la posición del observador que garantiza que pueda visualizarse la escena para cualquier posible lı́nea de visión. Dependiendo de qué datos hayan sido solicitados por el cliente, los quadtrees pueden encontrarse incompletos y sin equilibrar. Al contrario que el servidor, los datos se almacenan en la memoria principal del cliente. Pero, debido al pequeño tamaño de las memorias incluidas en los dispositivos móviles, la base de datos del cliente se actualiza de forma adaptativa. Visualización adaptativa de grandes terrenos a través de redes celulares 53 Cada nodo de quadtree de la base de datos del cliente almacena dos conjuntos de información. El primer conjunto está constituido por la geometrı́a del bloque de terreno y la textura asociada. La geometrı́a se almacena como un único vector de vértices tridimensionales, lo cual resulta óptimo para su visualización. Las coordenadas de los vértices emplean como origen la esquina inferior izquierda del nodo en cuestión. Aparte, el nodo raı́z del quadtree almacena un vector de coordenadas de textura y un conjunto de máscaras de ı́ndices [24], que son compartidos por todos los nodos de la jerarquı́a del quadtree. Estas máscaras se emplean para la visualización del quadtree. El segundo conjunto consiste en la traslación y escalado que es preciso aplicar al bloque de terreno contenido en cada nodo para su correcta visualización respecto al modelo completo del terreno. 5.5. Aritmética Entera y Precisión La mayorı́a de los métodos de visualización de terrenos emplean vértices expresados mediante números reales. No obstante, muchos dispositivos móviles de reducido costo no incluyen unidad de procesamiento de punto flotante. Por ejemplo, los dispositivos basados en la CPU ARM9. Por tanto, en nuestro método, las coordenadas de los puntos se representan mediante enteros cortos de dos bytes. Aparte de mejorar el rendimiento de las operaciones aritméticas, el tamaño de los vectores de vértices es claramente inferior si usamos enteros cortos, a si usamos valores flotantes de cuatro u ocho bytes. Dado que la memoria es un recurso escaso y preciado en los dispositivos móviles y que las redes inalámbricas son lentas, una reducción tan considerable del tamaño de las estructuras de datos empleadas es una mejora interesante. El principal inconveniente de esta estrategia es que las coordenadas absolutas referentes a la Tierra son sencillamente demasiado grandes como para poder ser representadas mediante enteros cortos. Este problema se solventa mediante la segmentación del terreno en pequeños bloques de terreno, y el almacenaje de cada uno de los bloques en coordenadas locales referentes a sus respectivos orı́genes. Existe otro problema de precisión que afecta a los valores de altura del terreno. Como el rango de los números enteros cortos oscila entre 0 y 65536, los valores de altura expresados en metros deben escalarse para cubrir todo este rango numérico. De no hacerse ası́, la resolución vertical del terreno quedarı́a reducida a un metro y la imagen generada podrı́a sufrir un visible efecto de escalonado. 6. El Panorama En nuestro método, un impostor consiste en una imagen sintética bidimensional que simula una vista amplia del terreno fı́sico situado lejos del observador. Estos impostores reciben el nombre de panoramas, [4]. 54 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez Un panorama captura la escena visible en todas las direcciones desde un punto del espacio dado. Para visualizar un panorama, éste debe previamente proyectarse sobre una forma tridimensional. El usuario debe emplazarse en el centro de esta forma, la cual se traslada de forma solidaria con el mismo. Ası́, el usuario percibe la ilusión de estar rodeado por una escena situada a una distancia infinita y que cubre los 360 grados a su alrededor. Las formas tridimensionales más empleadas son las esferas, los cilindros y los cubos. Panoramas cilı́ndricos. En un panorama cilı́ndrico, la imagen se proyecta en el lado interno de la cara curva de un cilindro, véase la Figura 9a. Este tipo de panoramas no cubre totalmente las rotaciones verticales, esto es, el usuario tiene limitada su visión hacia arriba y hacia abajo. Panoramas esféricos. Estos panoramas proyectan la imagen en el interior de una esfera, ver Figura 9b. Por tanto, cubren exactamente 360 grados en el eje horizontal y 180 grados en el vertical. Esto permite que el usuario pueda mirar hacia cualquier dirección. Como contrapartida, estos panoramas crean distorsiones en la imagen y su visualización es poco eficiente. Panoramas cúbicos. En el caso de los panoramas cúbicos, ver Figura 9c, la imagen se proyecta en las seis caras internas de un cubo. Al igual que los panoramas esféricos, los panoramas cúbicos cubren todas las posibles lı́neas de visión del observador. Pero al contrario que éstos, son altamente eficientes puesto que son geométricamente muy sencillos de visualizar. Nuestro método emplea panoramas cúbicos. Un panorama proyectado sobre un cubo suele recibir habitualmente el nombre de skybox [32] o mapa de entorno [3]. La construcción del panorama cúbico es sencilla [6]. Cada cara cubre 90 grados de visión, tanto horizontalmente como verticalmente. Para construir el panorama, el servidor coloca primero su propia cámara en las coordenadas del observador proporcionadas por el cliente. A continuación, el servidor utiliza el terreno distante para sintetizar seis imágenes ortogonales. Estas imágenes son comprimidas mediante algún algoritmo estándar de compresión de imágenes, por ejemplo JPEG, y enviadas al cliente. El cliente construye la escena final mostrada al usuario mediante composición del terreno visualizado en tiempo real y el panorama recibido del servidor, tal y como ilustra la Figura 10. La Figura 11 muestra algunos ejemplos reales de terrenos visualizados con y sin panorama. En nuestra propuesta, el servidor dibuja el terreno situado en el fondo de la escena sobre un panorama. Por otra parte, el cliente visualiza en tiempo real el terreno cercano en función de cierto nivel de detalle. No obstante, el terreno mostrado al usuario en la pantalla debe carecer de discontinuidades apreciables. Por tanto, nuestra técnica divide el terreno entre terreno cercano y panorama como se explica a continuación. Considérese que el volumen de visión del cliente esté limitado por los planos de recorte delantero y traseros, situados respectivamente a una distancia z f rontc y zbackc del punto de visión. Similarmente, considérese que el volumen de visión del servidor esté limitado por los planos de recorte situados a distancia z f ronts y zbacks . Visualización adaptativa de grandes terrenos a través de redes celulares (a) 55 (b) (c) Fig. 9 Las formas más usuales empleadas para visualizar panoramas: a) cilindro, b) esfera, c) cubo. Fig. 10 Sı́ntesis del terreno cercano, visualizado por el cliente, y el panorama, visualizado por el servidor. Ahora, requerimos que zbackc = z f ronts , esto es, que el plano de recorte trasero del cliente y el delantero del servidor sean coincidentes. Ver Figura 12. La distancia focal de la cámara es la misma tanto para cliente como para servidor. Bajo estas condiciones, el cliente visualiza el terreno próximo al observador, mientras que el alejado queda fuera de su volumen de visión. Por el contrario, el servidor recorta la parte cercana de la escena, y solamente tiene en consideración la alejada cuando construye el panorama. 56 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez (a) (b) (c) (d) (e) (f) (g) (h) Fig. 11 Escenas dibujadas por un Nokia N95. La resolución de los panoramas era de 256 × 256 pı́xeles por cara del cubo. a), c), e) y g) imágenes con panorama. b), d), f) y h) imágenes sin panorama. zbacks zbackc zfronts zfrontc Servidor Cliente Fig. 12 División del volumen de visión entre cliente y servidor. 7. Actualización del Terreno El servidor efectúa el envı́o de datos al cliente bajo demanda. Si el servidor necesita dividir un nodo hoja del quadtree para dibujar una parte del terreno con mejor nivel de detalle, entonces procede a descargar los nodos hijos desde el servidor. Mientras se efectúa la descarga, los datos disponibles localmente se emplean para visualizar la parte del terreno afectada, aunque sea a menor calidad de la deseada. Visualización adaptativa de grandes terrenos a través de redes celulares 57 Fig. 13 Al desplazarse el punto de visión, siempre se mantiene un área cuadrada de bloques activos. Cuando el usuario arranca la aplicación y comienza a navegar por la escena, el cliente inicializa la rejilla local mediante la descarga del nodo raı́z del quadtree sobre el que se encuentra el usuario. Estos datos permiten efectuar una visualización aproximada del terreno a baja resolución. Conforme el usuario se desplaza a lo largo del entorno virtual, la base de datos local se actualiza manteniendo siempre una región de terreno cuadrada alrededor del observador. Se descargan todos aquellos datos que sean precisos para la visualización, y se borran aquéllos que ya no sean necesarios. Nuestra representación del terreno se divide en dos niveles. De forma análoga, la operación de actualización de la base de datos local del cliente se descompone en dos pasos. Primeramente, se procede a actualizar la rejilla de quadtrees. Posteriormente, se actualiza de forma individual cada uno de los quadtrees contenidos en la rejilla. Primer paso. Debido al gran tamaño de la rejilla regular que divide el terreno en bloques, empleamos un esquema de ventana deslizante para seleccionar un subconjunto a trasferir al cliente. Este esquema funciona de forma análoga a los clásicos sistemas de paginación de terrenos, [22], donde el objetivo es mantener un área cuadrada activa centrada alrededor del punto de visión. Si el punto de visión se desplaza sobre un nuevo bloque (no necesariamente adyacente), entonces se descargan nuevos bloques del servidor y se borran aquellos bloques que queden fuera de la nueva área cuadrada. Ver Figura 13. Segundo paso. En el segundo paso, se procede a recorrer en sentido descendente todos los quadtrees contenidos en la rejilla local. En este recorrido se selecciona un conjunto de nodos de quadtree activos para su visualización. En el segundo paso, pueden emplearse múltiples criterios para determinar el conjunto de nodos activos. Nodos activos son aquéllos que serán visualizados durante el proceso de dibujado de la escena. Debido a que nuestro objetivo principal es reducir la carga de la CPU, empleamos una medida simple basada en la observación 58 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez de que, en general, la resolución necesaria para visualizar el terreno decrece conforme la distancia al observador incrementa. Sea e la longitud del borde del bloque de terreno cubierto por el nodo de quadtree, sea d la distancia desde el punto de vista actual al centro del bloque, y sea C un parámetro configurable que determine la calidad del terreno. Entonces, definimos la importancia de un nodo, f , como f= d e ·C (3) Para una descripción más detallada de esta expresión, puede consultarse [28]. Este criterio garantiza que la diferencia entre el nivel de detalle de dos nodos de quadtree cuyos bloques de terreno sean adyacentes es menor o igual a uno [28, 19]. Para cada nodo de quadtree visitado durante el recorrido, se evalúa la expresión de la Ecuación 3: Si f < 1 y no se ha alcanzado una profundidad máxima del árbol prefijada, digamos max depth, entonces el recorrido del árbol continúa. Si el nodo actual no tiene hijos, entonces se marca como activo y se procede a la descarga de los nodos hijos del servidor. La descarga se realiza en paralelo con la visualización. Si el nodo tiene hijos, entonces no se marca como activo pero se procede con el recorrido de sus hijos. Si f ≥ 1 o se ha alcanzado la profundidad máxima del árbol prefijada max depth, entonces el nodo se marca como activo lo que implica que será visualizado en el siguiente ciclo de dibujado. Si el nodo tiene hijos, se eliminan puesto que ya no son necesarios para la visualización del terreno. La recursividad termina. Para evitar volver a descargar nodos que han sido recientemente borrados (por ejemplo, si el observador vuelve atrás sobre sus pasos), empleamos una técnica de caché para mantener en memoria algunos de los nodos de quadtree a pesar de que ya no sean necesarios para su visualización. Nuestra técnica consiste en definir un valor umbral, σ ≥ 1, tal que aquellos nodos que satisfagan σ > f > 1 en la Ecuación 3 no son borrados ni visualizados, pero se mantienen en memoria en previsión de un posible uso futuro. 8. Actualización del Panorama Según se desprende de las ecuaciones de la proyección en perspectiva dadas en la Sección 2, conforme la distancia de la cámara a una zona del terreno se incrementa, su proyección resulta menos significativa. Además, los cambios en la proyección de puntos alejados producidos por variaciones pequeñas de la posición del observador son prácticamente inapreciables. Por tanto, enviar un nuevo panorama al cliente por cada movimiento del observador resulta en un tráfico inútil de datos. En esta sección formalizaremos el error cometido en la escena cuando el observador se desplaza pero el panorama empleado para simular terreno distante no se actualiza. Nuestra estrategia de actualización del panorama se basa en determinar Visualización adaptativa de grandes terrenos a través de redes celulares 59 Fig. 14 Traslación a lo largo del eje X. este error, y en actualizar el panorama tan solo cuando el error supere un cierto umbral prefijado. Cualquier movimiento arbitrario puede expresarse como una combinación de traslaciones y rotaciones. Debido a que los panoramas cubren 360 grados de visión alrededor del observador, cambiar la lı́nea de visión cuando el observador rota no incrementa el error del panorama mostrado. No obstante, si el observador se traslada, el panorama deberı́a cambiar. Una traslación general puede definirse como la combinación lineal de tres traslaciones ortogonales a lo largo de los ejes. Por tanto, consideraremos dos casos diferenciados. En un primer caso, el observador se desplaza a lo largo del eje X y/o Y. En el otro caso, el observador se traslada a lo largo de la lı́nea de visión. En ambos casos, la distancia d del observador hasta el plano de proyección se mantiene constante. 8.1. Traslación a lo Largo de los Ejes X e Y Sea Vs el conjunto de los puntos situados en el volumen de visión del servidor, y Vc el conjunto de puntos en el volumen de visión del cliente (ver Figura 12). Ahora, considérese que el observador se encuentra situado en un punto O, y que P ∈ Vs es un punto del terreno situado en el volumen de visión del servidor. Entonces, cuando el panorama se genera, el servidor proyecta el punto P en el punto Pp situado sobre el plano de proyección (ver Figura 14). Asumamos ahora que el observador se desplaza desde O hasta O′ a lo largo del eje X o del eje Y. Entonces, el punto P deberı́a de proyectarse ahora en Pp′ . Por tanto, si el panorama no se actualiza, el error en el punto proyectado medido en pı́xeles es 60 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez ′ εx = Ppx − Ppx ; ′ εy = Ppy − Ppy (4) Como se esperaba, cuanto mayor sea la traslación del observador, mayor será el error. Consecuentemente, conforme el observador se aleje de la posición inicial, se volverá más aparente una discontinuidad entre el terreno visualizado localmente en tiempo real y el panorama. Teniendo en cuenta la proyección en perspectiva definida en la Ecuación 1, tenemos: d d ′ Ppx = (Px + |OO′ |) (5) Ppx = Px ; Pz Pz donde |OO′ | es la distancia a lo largo del eje X desde O hasta O′ , y d es la distancia focal de la cámara. Por tanto, el error en los puntos proyectados puede expresarse como εx = Px d d − (Px + |OO′ |) Pz Pz d (Px − Px − |OO′ |) Pz d = − |OO′ | Pz = Como la coordenada Pz se encuentra en el denominador, el error se decrementa conforma la distancia entre los puntos del terreno y el plano de proyección se incrementa. Ignorando el signo, la traslación del observador a lo largo del eje X correspondiente a un umbral de error dado, εx , es |OO′ | = εx Pz d El máximo error posible para cualquier punto P(x, y, z) ∈ Vs se produce para aquellos puntos que estén situados a la menor distancia posible del observador. Ahora bien, ningún punto proyectado sobre el panorama puede encontrarse más cerca que la distancia al plano de recorte delantero del servidor, z f ronts . Es decir, Pz ≥ z f ronts ∀ P(x, y, z) ∈ Vs . Por tanto, tenemos que |OO′ | ≤ εx z f ronts d Pero, de acuerdo con nuestra defición de panorama realizada en la Sección 6, zbackc = z f ronts . Por tanto, para preservar la continuidad en la transición terrenopanorama, deberemos actualizar el panorama cada vez que la traslación del observador satisfaga la siguiente expresión: |OO′ | > εx zbackc d (6) Visualización adaptativa de grandes terrenos a través de redes celulares 61 Fig. 15 Traslación a lo largo del eje Z. De forma análoga, y si la ventana de visión no es cuadrada, también actualizaremos el panorama cada vez que se verifique: |OO′ | > εy 8.2. zbackc d (7) Traslación a lo Largo de la Dirección de Visión Teniendo en cuenta que en nuestro método, la distancia focal d se mantiene siempre constante, consideremos ahora una traslación del observador a lo largo del eje Z, como se ilustra en la Figura 15. En lo que sigue, formalizaremos solamente la componente X del error en los puntos proyectados. El mismo razonamiento debe aplicarse para el componente Y. En las mismas condiciones asumidas en la sección anterior, las componentes del punto proyectado antes y después de que el observador haya variado su posición son: d d ′ Ppx = Px ; Ppx = Px (8) Pz Pz − |OO′ | Para mantener constante la distancia d, el plano de proyección debe trasladarse de forma solidaria junto al observador. Nótese que, en general, cuando el observador se mueve a lo largo del eje Z, los puntos proyectados se desplazan simultáneamente a lo largo de ambos ejes, X e Y, del plano de proyección. El error definido por la Ecuación 4 es ′ εx = Ppx − Ppx (9) Combinando las Ecuaciones 8 y 9, tenemos 62 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez Fig. 16 Los Puntos P situados sobre el plano de recorte lateral definen el ángulo de visión abarcado por el observador situado en O. εx = Px d d − Px Pz − |OO′ | Pz Dividiendo entre Px d, obtenemos εx 1 1 = − Px d Pz − |OO′ | Pz 1 εx 1 = + ′ Pz − |OO | Px d Pz 1 Pz εx + Px d = Pz − |OO′ | Px Pz d Pz − |OO′ | = Px Pz d Pz εx + Px d |OO′ | = Pz − Px Pz d Pz εx + Px d Finalmente, y dado un umbral de error εx , la traslación permitida a lo largo del eje Z es ! d |OO′ | = Pz 1 − Pz (10) Px εx + d La expresión de la Ecuación 10 puede reescribirse en función de los parámetros que definen el volumen de visión. Considérese que P(x, y, z) es un punto arbitrario en Vs y que w denota la mitad del ancho de la ventana de visión. Entonces, ningún punto P(x, y, z) dentro del volumen de visión del servidor puede encontrarse más allá del plano de recorte lateral que corta al plano de proyección en w, ver Figura 16. Visualización adaptativa de grandes terrenos a través de redes celulares 63 En consecuencia, tenemos tan(α ) = Px w < Pz d Y por tanto Pz d > Px w (11) Reemplazando la Ecuación 11 en la Ecuación 10, obtenemos ! w d ′ = Pz 1 − |OO | ≥ Pz 1 − d εx + w w εx + d De acuerdo con la definición de panorama realizada en la Sección 6, los puntos del terreno satisfacen que Pz ≥ zbackc , (ver Figura 12). Consecuentemente, el cliente debe solicitar al servidor una actualización del panorama cada vez que se satisfaga la siguiente condición: w ′ (12) |OO | ≥ zbackc 1 − εx + w 8.3. Algoritmo para Actualizar el Panorama En nuestro método, tanto cliente como servidor necesitan compartir los siguientes parámetros: O: La posición del observador. d: La distancia focal de la cámara. w: La mitad de la anchura de la ventana de visión sobre el plano de visión. El algoritmo para actualizar el panorama puede sintetizarse en los siguientes pasos: 1. El observador se desplaza desde su posición original O hasta una nueva posición O′ . 2. El cliente visualiza el terreno cercano de acuerdo con la nueva posición O′ . 3. El cliente decide si solicitar un nuevo panorama al servidor. Si se satisface al menos uno de los criterios dados en las Ecuaciones 6, 7, o 12, entonces continuar con el paso 4. En otro caso, volver al paso 1. 4. El cliente emite una solicitud de nuevo panorama al servidor. En respuesta, el servidor proyecta el terreno distante sobre una imagen panorámica. Este panorama se envı́a al cliente, quien lo emplea como impostor para simular el terreno lejano. Volver al paso 1. 64 8.4. José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez Transición de Panoramas Cuando el cliente recibe un panorama, éste permanece válido durante un cierto periodo de tiempo que depende del criterio detallado en secciones previas. En el momento en el que dicho criterio se satisface, se emite una solicitud al servidor, el cual responde con un panorama actualizado. Los nuevos panoramas siempre reemplazan a los antiguos. No obstante, sustituir un panorama por otro produce una discontinuidad temporal en la escena fácilmente detectable por el usuario. En esta Sección proponemos una técnica que emplea multi-texturas para implementar una animación de transición que oculta de forma efectiva y eficiente el cambio entre panoramas. Si el dispositivo está dotado de una GPU programable, el efecto de transición puede implementarse mediante un programa de fragmentos. Si se carece de ella, puede conseguirse el mismo efecto mediante una función de combinación de texturas, [39]. Ya sea en un caso o en el otro, empleamos la siguiente estrategia para transformar progresivamente el panorama viejo en el nuevo: Las imágenes de ambos panoramas, el viejo y el nuevo, se aplican de manera simultánea sobre el cubo que empleamos habitualmente para proyectar el panorama. A tal fin, hacemos uso de las capacidades multi-textura que nos brindan las librerı́as gráficas tal y como OpenGL ES. Ahora, definimos una función de combinación de texturas que toma como entradas el color de ambos panoramas, c0 y c1 , y genera un color c interpolado de forma lineal en función del tiempo de acuerdo a la siguiente expresión: t − t0 t − t0 c0 + c1 c(t) = 1 − dur dur donde t0 es el instante de tiempo en el que arranca la animación, dur es la duración de la misma y t es el instante de tiempo actual, todos ellos expresados en segundos. Al principio de la animación de transición, solo es visible el color del panorama antiguo, c0 . Conforme la animación progresa, el color de este panorama se combina progresivamente con el del nuevo panorama de acuerdo a la expresión anterior. Al final de la animación, el panorama viejo deja de ser visible y puede descartarse. En nuestros experimentos, una duración de la transición dur = 0,5 segundos ofrece resultados satisfactorios. 9. Visualización En esta sección se explica cómo se lleva a cabo la visualización del terreno. La operación de actualización de la base de datos local del cliente marca algunos de los nodos de quadtree como activos. Este conjunto de nodos activos constituye el nivel de detalle con el que es preciso dibujar el terreno. Visualización adaptativa de grandes terrenos a través de redes celulares 65 Fig. 17 Representación 2D del recorte mediante el volumen de visión. Los bloques en gris no se visualizan. 9.1. Dibujado Mediante Máscaras de Índices La operación de dibujado se efectúa una vez por cada marco de animación. Se efectúa un recorrido en profundidad para cada quadtree alojado en la rejilla de la base de datos local. Durante dichos recorridos, aquellos nodos de quadtree que se encuentren totalmente fuera del volumen de visión del cliente son descartados, tal y como se ilustra en la Figura 17.Cuando se alcance un nodo marcado como activo, se dibuja y se detiene la recursividad. Los puntos contenidos en cada nodo de quadtree activo se enlazan para formar tiras de triángulos mediante el uso de máscaras de ı́ndices, [24]. Dado que el número de puntos de terreno alojados en cada nodo de un quadtree es constante (ver Sección 5.2), las máscaras de ı́ndices son iguales para todos los nodos de un mismo quadtree dado. Puesto que además, las máscaras no varı́an durante la ejecución del programa, podemos pre-calcularlas y compartirlas entre todos los nodos del mismo árbol. El bloque de terreno contenido en el nodo se visualiza como una única tira de triángulos mediante el uso de la máscara correspondiente, ver Figura 18a. No obstante, en la unión entre nodos adyacentes a distinto nivel de detalle pueden aparecer discontinuidades geométricas evidentes como las que se aprecian en la Figura 19a. Estas discontinuidades deben ser evitadas. A tal fin hacemos uso de tiras de triángulos de unión que se adaptan a la resolución de ambos nodos, tal y como se aprecia en la Figura 19b. Como se afirmó en la Sección 7, el nivel de detalle de nodos adyacentes puede diferir como mucho en una unidad. Por tanto, el número de tiras de unión necesarias es pequeño. Las tiras empleadas en nuestra técnica se ilustran en las Figuras 18b y 18c. Para determinar las tiras de triángulos necesarias para la visualización del bloque de terreno contenido en un nodo, primero debemos identificar a los cuatro nodos adyacentes. Para ello, empleamos sus respectivos códigos Morton. Si el nivel de detalle de los cuatro nodos adyacentes es igual o menor que el del nodo actual, 66 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez (a) (b) (c) Fig. 18 a) Tira de triángulo para un nodo de 9×9 (n0 = 3) valores de altura. b) Tiras de unión para nodos adyacentes con el mismo nivel de detalle. c) Tiras de unión para nodos adyacentes con distinto nivel de detalle. (a) (b) Fig. 19 a) Discontinuidad geométrica. b) Uso de tiras de triángulos de unión (en rojo) para evitar discontinuidades. entonces éste se dibuja mediante una malla de triángulos cuadrangular. Para generar esta malla se utiliza una única tira de triángulos, ver Figura 18a. Cuando el nivel de detalle de, al menos, un nodo adyacente sea mayor que el nivel de detalle del nodo actual, entonces debemos emplear tiras de unión para evitar discontinuidades geométricas en la frontera de los bloques. En este caso, los puntos del terreno de la zona interna del bloque se dibujan mediante una única tira que genera una región cuadrangular de terreno. Pero para dibujar los cuatro bordes del bloque de terreno, es preciso utilizar cuatro tiras de unión, una por cada lado del bloque de terreno. Para cada lado se selecciona la tira que coincida con la resolución del nodo adyacente a ese lado. Las Figuras 18b y 18c ilustran estas ideas. Trabajos como [15] también hacen uso de tiras de triángulos especiales para unir nodos de quadtree adyacentes. Si bien, permiten cualquier diferencia de nivel de detalle entre nodos adyacentes. Como consecuencia, el número de tiras de unión a pre-calcular es muy elevado, ya que deben contemplarse todas las posibles com- Visualización adaptativa de grandes terrenos a través de redes celulares 67 binaciones. Además, las tiras necesarias para unir nodos con diferencia de nivel de detalle mayor que uno contienen triángulos desiguales, largos y estrechos. Este hecho aumenta conforme la diferencia de nivel de detalle también aumenta. Como consecuencia, las tiras de triángulo generadas son de mala calidad. En nuestra técnica, en cambio, la diferencia entre niveles de detalle solo puede ser de cero o de uno. Por tanto, el conjunto de tiras a pre-calcular es muy reducido, y todos los triángulos necesarios son rectángulos y semejantes entre sı́, ver Figuras 18b y c. 9.2. Almacenamiento de Geometrı́a en Memoria de GPU Por lo general, el movimiento del observador suele ser suave. Por tanto, podemos explotar la coherencia espacial y temporal para reutilizar los mismos datos en diversos marcos de animación. A tal fin, almacenamos los puntos del terreno en un tipo de estructura conocida como vertex buffer object (VBO). Esta estructura se envı́a a la GPU del cliente, en donde queda almacena en memoria de vı́deo. Desde aquı́ es posible proceder a su visualización en reiteradas ocasiones sin necesidad de reenviar la geometrı́a desde memoria principal a la GPU. De esta forma, se reduce de forma drástica el trasiego de datos entre CPU y GPU. Las máscaras de ı́ndices también se almacenan como VBOs en memoria de la GPU, donde son reutilizadas para dibujar todos los nodos de la estructura. Las GPUs móviles que satisfagan las especificaciones de OpenGL ES 1.1 ó 2.0 incluyen soporte para VBOs. Esta es la forma más óptima de transferir vértices e ı́ndices a las GPUs móviles [25, 31]. Para aquellas plataformas en las que no se soporten VBOs, pueden emplearse vectores de vértices estándar, si bien entonces es preciso el envı́o de la geometrı́a a la GPU por cada marco de animación. Agradecimientos Este trabajo ha sido parcialmente financiado por el Ministerio de Ciencia e Innovación y la Eunión Europea (fondos FEDER) a través del proyecto TIN2011-25259 y la Universidad de Jaén a través del proyecto de investigación UJA2010/13/08, financiado por Caja Rural de Jaén. Referencias 1. Arul Asirvatham and Hugues Hoppe. Terrain rendering using GPU-based geometry clipmaps, volume GPU Gems 2: Programming Techniques for High-Prformance Graphics and GeneralPurpose Computation, chapter 2. Addison-Wesley Professional, 2005. 2. F. Bettio, E. Gobbetti, F. Marton, and G. Pintore. High-quality networked terrain rendering from compressed bitstreams. In Web3D ’07: Proceedings of the twelfth international conference on 3D web technology, pages 37–44, New York, USA, 2007. ACM. 3. James F. Blinn and Martin E. Newell. Texture and reflection in computer generated images. Commun. ACM, 19(10):542–547, 1976. 4. A. Boukerche, R. Jarrar, and R. W.N. Pazzi. An efficient protocol for remote virtual environment exploration on wireless mobile devices. In WMuNeP ’08: Proceedings of the 4th ACM 68 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez workshop on Wireless multimedia networking and performance modeling, pages 45–52, New York, USA, 2008. ACM. A. Boukerche, R. Jarrar, and R.W. Pazzi. A novel interactive streaming protocol for imagebased 3d virtual environment navigation. In Communications, 2009. ICC ’09. IEEE International Conference on, pages 1–6, 2009. M. Clasen and H. C. Hege. Terrain rendering using spherical clipmaps. In Proc. EuroVis, 2006. Leila De Floriani, Paola Marzano, and Enrico Puppo. Multiresolution models for topographic surface description. The Visual Computer, 12:317–345, 1996. 10.1007/BF01782231. C. Dick, J. Schneider, and R. Westermann. Efficient geometry compression for GPU-based decoding in realtime terrain rendering. Computer Graphics Forum, 28(1):67–83, 2009. J.D. Foley, A. van Dam, S.K. Feiner, and J.F. Hughes. Computer graphics: principles and practice (2nd ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, USA, 1990. P. Cignoni F. Fabio Ganovelli, E. Gobbetti, F. Marton, F. Ponchio, and R. Scopigno. BDAM – batched dynamic adaptive meshes for high performance terrain visualization. Computer Graphics Forum, 22(3):505–514, 2003. E. Gobbetti, F. Marton, P. Cignoni, M. Di Benedetto, and F. Ganovelli. C-BDAM – compressed batched dynamic adaptive meshes for terrain rendering. Computer Graphics Forum, 25(3):333–342, 2006. Java Community Process. JSR 184: Mobile 3D Graphics API for J2ME. http://www.jcp.org/en/jsr/detail?id=184, 2005. [accessed 24 March 2010]. R. Lerbour. Adaptive Streaming and Rendering of Large Terrains. PhD thesis, Université de Rennes, 2010. R. Lerbour, J.-E. Marvie, and P. Gautron. Adaptive streaming and rendering of large terrains: A generic solution. In 17th WSCG International Conference on Computer Graphics, Visualization and Computer Vision, pages 25–32, 2009. R. Lerbour, J.-E. Marvie, and P. Gautron. Adaptive real-time rendering of planetary terrains. In 18th WSCG International Conference on Computer Graphics, Visualization and Computer Vision, pages 89–96, 2010. P. Lindstrom, D. Koller, W. Ribarsky, L. F. Hodges, N. Faust, and G. A. Turner. Real-time, continuous level of detail rendering of height fields. In SIGGRAPH ’96: Proceedings of the 23rd annual conference on Computer graphics and interactive techniques, pages 109–118, New York, USA, 1996. ACM. P. Lindstrom and V. Pascucci. Visualization of large terrains made easy. In VIS ’01: Proceedings of the conference on Visualization ’01, pages 363–371, Washington, DC, USA, 2001. IEEE Computer Society. P. Lindstrom and V. Pascucci. Terrain simplification simplified: A general framework for view-dependent out-of-core visualization. IEEE Transactions on Visualization and Computer Graphics, 8(3):239–254, 2002. Y. Livny, Z. Kogan, and J. El-Sana. Seamless patches for GPU-based terrain rendering. The Visual Computer, 25(3):197–208, 2009. F. Losasso and H. Hoppe. Geometry clipmaps: terrain rendering using nested regular grids. SIGGRAPH04: ACM SIGGRAPH 2004 Papers, 23(3):769–776, 2004. G.M. Morton. A computer oriented geodetic data base and a new technique in file sequencing. Technical report, 1966. R. Pajarola. Large scale terrain visualization using the restricted quadtree triangulation. In VIS ’98: Proceedings of the conference on Visualization ’98, pages 19–26, Los Alamitos, CA, USA, 1998. IEEE Computer Society Press. R. Pajarola and E. Gobbetti. Survey of semi-regular multiresolution models for interactive terrain rendering. The Visual Computer, 23(8):583–605, 2007. J. Pouderoux and J. Marvie. Adaptive streaming and rendering of large terrains using strip masks. In GRAPHITE ’05: Proceedings of the 3rd international conference on Computer graphics and interactive techniques in Australasia and South East Asia, pages 299–306, New York, USA, 2005. ACM. Visualización adaptativa de grandes terrenos a través de redes celulares 69 25. PowerVR. PowerVR MBX. 3D Application Development Recommendations. Imagination Technologies Ltd., 2005. 26. K. Pulli, T. Aarnio, V. Miettinen, K. Roimela, and J. Vaarala. Mobile 3D graphics with OpenGL ES and M3G. Morgan Kaufmann, 2007. 27. B. Rabinovich and C. Gotsman. Visualization of large terrains in resource-limited computing environments. In VIS ’97: Proceedings of the 8th conference on Visualization ’97, pages 95– 102, Los Alamitos, CA, USA, 1997. IEEE Computer Society Press. 28. Stefan Roettger, Wolfgang Heidrich, Philipp Slusallek, and Hans-Peter Seidel. Real-time generation of continuous levels of detail for height fields. In WSCG ’98: Procedings of the 6th International Conference in Central Europe on Computer Graphics and Visualization, pages 315–322, 1998. 29. Hanan Samet. The quadtree and related hierarchical data structures. ACM Comput. Surv., 16(2):187–260, 1984. 30. J. Schneider and R. Westermann. GPU-friendly high-quality terrain rendering. Journal of WSCG, 14(1-3):49–56, 2006. 31. Andrew Senior. GPU Pro - Advanced Rendering Techniques, chapter iPhone 3GS Graphics Development and Optimization Strategies. ShaderX Book Series. A.K. Peters, 2010. 32. J. Shankel. Game Programming Gems 2, chapter Rendering Distant Scenery with Skyboxes, pages 416–420. Charles River Media, Inc., Rockland, MA, USA, 2001. 33. J. Wen, B. Zhu, and F. Wang. Real-time rendering of large terrain on mobile device. In ISPRS08, page B5: 693 ff, 2008. Introducción de información geográfica en terrenos 3D Ángel Aguilera Garcı́a, J. Roberto Jiménez Pérez y Francisco Martı́nez del Rı́o Resumen En los últimos años, con la aparición de ordenadores personales más pequeños y más potentes, se ha puesto de manifiesto la importancia de poder representar en tres dimensiones los sistemas de información geográfica (SIG) que tradicionalmente se ha estado representando en dos dimensiones. En la actualidad, con la incorporación en los diferentes dispositivos móviles de procesadores gráficos más potentes, ası́ como la agregación de elementos para poder detectar su posición geográfica y la posibilidad de conexión a diferentes redes, surge la posibilidad de poder representar información geográfica en tiempo real. Para poder llevarlo a cabo, podemos identificar tres fases, por un lado determinar cómo implementar un motor que pueda representar el terreno en 3D, por otro lado el pegado de texturas para hacer más real la escena y por último el cómo incorporar a ese terreno la información geográfica procedente de una serie de bases de datos a la que se accede a través de una red de ordenadores. En este capı́tulo mostramos una introducción sobre los diferentes formas de representar la información geográfica y nos centramos en mostrar las diferentes técnicas que se han desarrollado para poder realizar las tres tareas. La utilidad que nos proporciona el poder visualizar los SIG en 3D es múltiple y variada, dando la posibilidad de poder analizar exploratoriamente los datos, analizar la información para poder confirmar hipótesis, difundir la información, generar hipótesis y tomar decisiones. Universidad de Jaén Ángel Aguilera Garcı́a, e-mail: [email protected] Universidad de Jaén Juan Roberto Jiménez Pérez, e-mail: [email protected] Universidad de Jaén Francisco Martı́nez del Rı́o, e-mail: [email protected] 71 72 1. Ángel Aguilera Garcı́a, J. Roberto Jiménez Pérez y Francisco Martı́nez del Rı́o Introducción a la cartografı́a Una posible definición de cartografı́a podrı́a ser como el conjunto de estudios y operaciones cientı́ficas, artı́sticas y técnicas que intervienen, a partir de los resultados de las observaciones directas o de la explotación de una documentación, en el establecimiento de mapas, planos y otras formas de expresión, ası́ como en su utilización. La cartografı́a apareció mucho antes que la escritura. De hecho los primeros mapas de los que se tiene constancia son los hallados en las cuevas de Lascaux, situado al suroeste de Francia, fechados sobre el año 16.500 a.C. , tratándose muy probablemente de mapas de estrellas y constelaciones. El primer mapa terrestre que se reconoce se encuentra en la ciudad de Çatalhöyük, en Anatolia (Turquı́a) tratándose de un plano de la ciudad (ver Figuras 1 y 2) y datado en torno al año 6.200 a.C. [1]. Después de este mapa aparecen en la antigua babilonia diversos mapas en tablillas de barro, los cuales representan mapas del mundo e incluso mapas de edificios, estando datados estos sobre los años 2.300 y el 3.800 a.C. El interés por representar la información en mapas fue creciendo paulatinamente dando lugar a la geodesia. Esta se puede definir como la ciencia que estudia la forma y el tamaño de la Tierra, ası́ como la manera de localizar elementos en su superficie. Pero fue Eratóstenes (275-195 a.C.) el que utilizó el término geografı́a para referirse al estudio de la Tierra y todos los elementos que existen en ella, incluidos por supuesto los seres humanos. Posteriormente Hiparco (190-120 a.C.), fue el primero en dividir la Tierra en meridianos y paralelos, haciendo usuales los conceptos de longitud y latitud de un lugar o espacio. En la actualidad a la cartografı́a se le han ido añadiendo las nuevas tecnologı́as, apareciendo de este modo una nueva disciplina denominada geomática Fig. 1 Plano de Çatal Höyük. El plano está pintado sobre una pared y mide más de 2,5 m. Imagen cortesı́a de Ali Turan en Turkey in maps http://www.turkeyinmaps.com Fig. 2 Plano de Çatal Höyük. Recreación del plano original donde se aprecia la estructura de la ciudad. Al fondo se divisa un volcán, probablemente el Hasan Dag en erupción, todavı́a hoy visible desde Çatal Höyük Introducción de información geográfica en terrenos 3D 73 (en 1969 por B. Dubuisson) [2]. Esta se define como el tratamiento automatizado de la información geográfica. También la tecnologı́a ha proporcionado diferentes sistemas de posicionamiento geográfico como el NAVSTAR GPS o el futuro Galileo. 2. Sistema de Información Geográfica (SIG) Un Sistema de Información Geográfica (SIG) es una integración organizada de hardware, software y datos geográficos diseñada para capturar, almacenar, manipular, analizar y desplegar en todas sus formas la información geográficamente referenciada con el fin de resolver problemas complejos de planificación y gestión geográfica. El SIG funciona como una base de datos con información geográfica (datos alfanuméricos) que se encuentra asociada por un identificador común a los objetos gráficos de un mapa digital. Las principales cuestiones que puede resolver un Sistema de Información Geográfica, ordenadas de menor a mayor complejidad, son: 1. Localización: preguntar por las caracterı́sticas de un lugar concreto. 2. Condición: el cumplimiento o no de unas condiciones impuestas al sistema. 3. Tendencia: comparación entre situaciones temporales o espaciales distintas de alguna caracterı́stica. 4. Rutas: cálculo de rutas óptimas entre dos o más puntos. 5. Pautas: detección de pautas espaciales. 6. Modelos: generación de modelos a partir de fenómenos o actuaciones simuladas. Los SIG comienzan a utilizarse a partir de la década de los sesenta, progresando estos en paralelo con la evolución de los ordenadores y con la aparición, en la década de los setenta, de los satélites civiles. Aunque no fue hasta los ochenta, con el abaratamiento de los ordenadores y la aparición del GPS, cuando se empiezan a utilizar de forma masiva. Es a finales de los noventa cuando estos empiezan a evolucionar por el uso de satélites más potentes capaces de fotografiar la tierra con una resolución mayor. Las técnicas que manejan los SIG ya fueron utilizadas en el año 1854 por el Dr. John Snow, el pionero de la epidemiologı́a. En su ya famoso mapa (ver Figura 3)representó la incidencia de los casos de cólera en el distrito de Soho en Londres. Este SIG permitió a Snow localizar con precisión un pozo de agua contaminado como la fuente causante del brote. En el año 1962 Roger Tomlinson en Ottawa (Ontario, Canadá) y a cargo del Departamento Federal de Silvicultura y Desarrollo Rural, desarrolló el llamado Sistema de Información Geográfica de Canadá (Canadian Geographic Information System, CGIS) siendo este considerado el primer SIG de la historia. En 1964, Howard T. Fisher formó en la Universidad de Harvard el Laboratorio de Computación Gráfica y Análisis Espacial en la Harvard Graduate School of Design (LCGSA 1965-1991), donde se desarrollaron una serie de importantes conceptos 74 Ángel Aguilera Garcı́a, J. Roberto Jiménez Pérez y Francisco Martı́nez del Rı́o teóricos en el manejo de datos espaciales, En los setenta ya habı́a difundido código de software y sistemas germinales, tales como SYMAP, GRID y ODYSSEY. En la década de los años 70 y principios de los 80 se inició en paralelo el desarrollo de dos sistemas de dominio público. El proyecto Map Overlay and Statistical System (MOSS) se inició en 1977 en Fort Collins (Colorado, EE. UU.) bajo los auspicios de la Western Energy and Land Use Team (WELUT) y el Servicio de Pesca y Vida Silvestre de Estados Unidos (US Fish and Wildlife Service). En 1982 el Cuerpo de Ingenieros del Laboratorio de Investigación de Ingenierı́a de la Construcción del Ejército de los Estados Unidos (USA-CERL) desarrolló GRASS como herramienta para la supervisión y gestión medioambiental de los territorios bajo administración del Departamento de Defensa. En la década de los 80, M&S Computing (más tarde Intergraph), Environmental Systems Research Institute (ESRI) y CARIS (Computer Aided Resource Information System) emergerı́an como proveedores comerciales de software SIG. Los 80 y 90 fueron años de fuerte aumento de las empresas que comercializaban estos sistemas, debido el crecimiento de los SIG en estaciones de trabajo UNIX y ordenadores personales. A finales del siglo XX y principios del XXI el rápido crecimiento en los diferentes sistemas se ha consolidado, restringiéndose a un número relativamente reducido de plataformas. Fig. 3 Mapa original del Dr. John Snow. Los puntos son casos de cólera durante la epidemia en Londres de 1854. Las cruces representan los pozos de agua de los que bebı́an los enfermos Introducción de información geográfica en terrenos 3D 3. 75 Representación de los datos SIG Los datos SIG representan los objetos del mundo real, carreteras, el uso del suelo, altitudes, etc. Los objetos del mundo real se pueden dividir en dos abstracciones: objetos discretos (una casa) y continuos (cantidad de lluvia caı́da, una elevación). Existen dos formas de almacenar los datos en un SIG: Raster: imagen digital representada en mallas. Esta discretiza un espacio continuo, como es el terreno, en celdas de idéntico tamaño y se almacena una información determinada asociada a cada una de estas celdas. Vectorial: se expresan como vectores, manteniendo las caracterı́sticas geométricas de las figuras. Está formada por primitivas geométricas, con las posiciones de sus vértices en el sistema de coordenadas utilizado. Los datos independientemente del formato utilizado, ya sea en formato raster o vectorial, pueden almacenar una información continua o discreta. El formato de estos no es importante ya que existen programas que nos permiten pasar de unos tipos a otros. Para establecer la posición sobre la Tierra de los datos geográficos, se trabaja con un sistema de coordenadas en el que representar dichas posiciones. Según el estándar ISO 19111 (Spatial referencing by coordinates), existen tres sistemas de coordenadas [2]: Cartesiano: establece un espacio tridimensional donde el origen de coordenadas se sitúa en el centro de la Tierra, el eje Z se sitúa hacia el polo norte y los ejes X e Y formando el plano del ecuador, apuntando el eje X hacia el meridiano de referencia. Elipsoidal: en este las coordenadas utilizadas son la longitud, latitud y altitud. Proyectado: el cual consiste en una correspondencia biunı́voca entre los puntos de la superficie terrestre y el llamado plano de proyección. El más utilizado es la proyección UTM (Universa Transverse Mercator)(ver Figura 4). Este sistema de proyección se denomina universal, porque divide el planeta en 60 zonas o husos, de 6o de longitud, a partir de un meridiano de referencia [3, 4, 5]. Fig. 4 Usos y zonas UMT. Fig. 5 Ejemplo de grids y TIN 76 4. Ángel Aguilera Garcı́a, J. Roberto Jiménez Pérez y Francisco Martı́nez del Rı́o Modelos topográficos para la representación de terrenos Para representar terrenos los modelos topográficos que se usan suelen estar basados en mallas de polı́gonos regulares (grids) o mallas de polı́gonos irregulares de triángulos (triangulated irregular networks) TIN (ver Figura 5). Las mallas regulares están formadas por una matriz de muestras de altura separadas por una distancia constante en ambos ejes del plano horizontal. Las principales ventajas que presenta son: tener varias mallas cada una con un nivel de detalle, el renderizado es óptimo para el hardware grafico (solo se guardan los valores de las alturas ordenados en una matriz) y la distribución homogénea de los puntos, que facilita los cálculos como para ver intersecciones entre elementos. La desventaja fundamental que presenta es que el detalle del terreno es homogéneo siendo el mismo para una zona llana como para una montaña. Las mallas irregulares se forman a partir de una serie de puntos de alturas del terreno distribuidos irregularmente. A partir de estos puntos se intentan unir formando triángulos que se aproximen a triángulos rectángulos. El proceso más utilizado para la triangulación es el de Delaunay. Las mallas irregulares presentas varias desventajas como los cálculos que tiene que hacer el hardware para poder renderizar los triángulos, mayor tamaño de almacenamiento por tener que almacenar las coordenadas y la altura para cada punto. La ventaja fundamental es que permite la adaptación más próxima a las caracterı́sticas de terreno, representando zonas llanas con menos puntos y zonas más rugosas con más puntos. Ver Figura 6 5. Visualización de terrenos en tiempo real A la hora de visualizar terrenos en tiempo real nos podemos encontrar con tareas crı́ticas: el gran espacio que ocupan los datos que vamos a representar y los cálculos asociados a esos datos para poder obtener la geometrı́a 3D del terreno [6, 7]. Para intentar minimizar los tiempos de estas tareas se han utilizado técnicas de paginación y de memoria caché para los problemas de memoria y para los cálculos de Fig. 6 Triangulación de Delaunay de un terrenos Introducción de información geográfica en terrenos 3D 77 la geometrı́a se ha utilizado la representación del terreno con diferentes niveles de detalle (LOD) [8]. Dentro de la cartografı́a aparece el término generalización [9, 10], que consiste en el proceso de representar la información en un mapa adaptándola a la escala de dicho mapa. De los diferentes métodos desarrollados para la visualización de terrenos, los más destacados son: Lindstrom et al. [11] desarrollaron técnicas de visualización de terreno utilizando LOD continuos para la gestión de una geometrı́a poligonal basada en mallas regulares. Duchaineau et al. [12] presentaron la técnica denominada ROAM (Real-time Optimally Adapting Meshes). Esta técnica trata el problema de la gestión de LOD para mallas regulares de geometrı́a. Rabinovich y Gotsman [13] publicaron una técnica para visualizar el terreno a partir de datos de elevación, de una malla regular y textura procedente de imágenes aéreas o de satélite. Röttger et al. [14] desarrollaron una técnica basada en la de Lindstrom, pero utilizando estructuras quadtree en lugar de bintree y una aproximación descendente en lugar de la ascendente de Lindstrom. Hoppe [15, 16] propone una técnica, denominada mallas progresivas o PM (progressive meshes) que utiliza mallas irregulares (TIN). Leila De Floriani y Enrico Puppo [17], proponen la multitriangulación (MT) utiliza diferentes niveles de detalle siendo estos generados con TIN. Willem H. De Boer [18], publicó una técnica denominada GeoMipMapping que aplica el concepto de mipmap [42] al campo de la geometrı́a. Lindstrom y Pascucci [19], publicaron una técnica basada en mallas regulares y bintrees cuyo objetivo principal es la sencillez en sus algoritmos y estructuras de datos para conseguir un buen rendimiento, separándose de la tendencia existente hacia los algoritmos cada vez más complicados. Klein y Schilling [20], publicaron en 2002 una técnica de visualización en tiempo real de terreno multirresolución basada en una partición y organización en una estructura jerárquica de tipo quadtree adecuada para su transmisión progresiva. Cignoni et al. publicaron el algoritmo BDAM (Batched Dynamic Adaptive Meshes) [21] extendido posteriormente a escala planetaria en el P-BDAM (PlanetSized BDAM) [22]. Frank Losasso y Hugues Hoppe [23] presentaron una técnica de gestión de geometrı́a denominada Geometry Clipmaps. Alex Holkner [24] publicó otra técnica basada en el concepto de clipmap a la gestión de geometrı́a de terreno. 78 6. Ángel Aguilera Garcı́a, J. Roberto Jiménez Pérez y Francisco Martı́nez del Rı́o Incorporación de texturas a un terreno Para darle más realismo a la visualización del terreno se le debe de añadir una textura a su representación geométrica, para ello se han desarrollado diferentes técnicas, destacando las siguientes: Ed Catmull [25], esta técnica consiste en aplicar una imagen sobre los modelos geométricos de la escena visualizada. Michael Cosman [26], describe una técnica basada en la la utilización de una textura global de terreno que no se repite, cada zona de la textura tiene una posición geográfica y se dibuja en una única posición de la geometrı́a. Esta técnica también define la posibilidad de incluir un detalle fino de la textura para operaciones como despegues o aterrizajes, donde la imagen geoespecı́fica no ofrece la suficiente resolución. Christopher C. Tanner, Christopher J. Migdal y Michael T. Jones [27], presentaron una técnica de mapeado de texturas arbitrariamente grandes, a la que llamaron The Clipmap. Tobias Hüttner [28], publico una técnica que dividı́a la imagen de gran resolución en una serie de fragmentos rectangulares de igual tamaño. Rabinovich y Gotsman [13], almacenaron la textura en un servidor, dividiendo la extensión del terreno en un mosaico de trozos. Estos trozos de textura están comprimidos utilizando una técnica de wavelets progresivos. David Cline y Parris K. Egbert [29] publicaron un artı́culo sobre el uso de texturas de gran tamaño. En él describen una arquitectura software para la gestión de cualquier tipo de texturas. Jürgen Döllner et al. [30], realizaron una técnica la cual consistı́a en partir de la textura original y construir una pirámide y un árbol de fragmentos de textura a diferentes niveles de detalle, donde cada fragmento de textura está asociado a un fragmento de geometrı́a del modelo geométrico multirresolución. Reinhard Klein y Andreas Schilling [20], proponen una técnica para la gestión de textura de muy alta resolución aplicada a terrenos extensos. Cignoni et al. [21, 22], publican una técnica que gestiona la textura del terreno troceándola en porciones y organizándola mediante una estructura jerárquica de tipo quadtree. Losasso y Hoppe [23], realizaron una técnica en la que a cada nivel del clipmap de la geometrı́a se le asocia una textura, de forma que la gestión de LODs se realiza conjuntamente. Alex Holkner [24], propone una variante de Geometry Clipmaps basada en GPUs programables. Anders Brodersen [31], propone una técnica basada en la gestión de la geometrı́a uniendo esta con las texturas mediante un mosaico. Anton Ephanov y Chris Coleman, [32] desarrollan una técnica de gestión de texturas de gran tamaño, en la que introducen las dos opciones habituales para la gestión de texturas de gran tamaño: los mosaicos de texturas y los clipmaps. Introducción de información geográfica en terrenos 3D 7. 79 Representación de terrenos 3D con datos vectoriales 2D La información cartográfica suele estar almacenada en datos vectoriales 2D. Estos datos antes de representarlos sobre el terreno se tienen que adaptar a la resolución del mismo, mostrando en cada caso solo los datos más relevantes, esta técnica es lo que se conoce como generalización. La NCGIA define la generalización como ün grupo de técnicas que permiten mantener la cantidad de información presente en un mapa a pesar de reducir la cantidad de datos”. Un vez seleccionados los datos que se tienen que mostrar, tenemos que adaptarlos al terreno 3D, para ello se suelen utilizar dos métodos, o bien pasar los datos a una textura y a continuación pegarla sobre el terreno, o bien adaptar los datos vectoriales sobre la geometrı́a 3D. Los trabajos más relevantes publicados que resuelven el problema de visualizar terrenos 3d en los que se representa información vectorial 2D son: Zachary Wartell et al. [33, 34, 35] describen una técnica que adapta la geometrı́a vectorial 2D del SIG a la superficie 3D del terreno. Agrawal et al. [36] desarrollan un método en el cual se monta un sistema de visualización que divide la geometrı́a y la textura en un mosaico de trozos cuadrados de igual tamaño, manteniendo en memoria nueve de estos trozos, centrados en la posición del espectador. Schilling et al. [37], muestran un método que no sobrecarga el sistema pudiéndose utilizar el mismo sobre dispositivos móviles y a través de pagina web. Oliver Kersting y Jürgen Döllner [38], desarrollan un método que primero generalizan la información cartográfica y después la pegan en el terreno mediante una textura. Stephen Brooks y Jaqueline L. Whalley [39], describen un método hı́brido 2D/3D para la visualización de información geográfica. Martin Schneider et al. [40], publican un método que utiliza las dos ideas fundamentales para representar los datos sobre el terreno, montando los datos vectoriales sobre modelos 3D y pegándolos luego como si fuesen texturas. Martin Schneider y Reinhard Klein [41], muestran una técnica basada en la utilización del stencil buffer de openGL. Referencias 1. J. Mellaart. Excavations of Catal Hyük 1963, Anatolian Studies. Journal of the British Institute at Ankara, XIX, 1964. 2. Wolfgang Kresse and Kian Fadaie. ISO Standards for Geographic Information. Springer, 2004. 3. L. M. Bugayevskiy and John Snyder. Map Projections: A Reference Manual. CRC, 1995. 4. John P. Snyder and Philip M. Voxland. Album of Map Projections. Diane Pub., 1986. 5. John P. Snyder. Map Projections: A Working Manual. US Geological Survey, US Government Printing Office, 1987. 80 Ángel Aguilera Garcı́a, J. Roberto Jiménez Pérez y Francisco Martı́nez del Rı́o 6. James D. Foley, Andries van Dam, Steven K. Feiner, and John F. Hughes. Computer Graphics: Principles and Practice. Second Edition in C. Addison-Wesley, 1995. 7. Tomas Akenine-Möller and Eric Haines. Real-Time Rendering. Second Edition. A K Peters, 2002. 8. James H. Clark. Hierarchical geometric models for visible surface algorithms. Commun. ACM, 19(10):547-554, 1976. 9. Robert B. McMaster and K. Stuart Shea. Generalization in Digital Cartography. Association of American Geographers, 1992. 10. Paul A. Longley, Michael F. Goodchild, David J. Maguire, and David W. Rhind. Geographic Information Systems and Science. Second Edition. John Wiley & Sons, Ltd., 2005. 11. Peter Lindstrom, David Koller, William Ribarsky, Larry F. Hodges, Nick Faust, and Gregory A. Turner. Real-time, continuous level of detail rendering of height elds. In SIGGRAPH ’96: Proceedings of the 23rd annual conference on Computer graphics and interactive techniques, pages 109118, New York, NY, USA, 1996. ACM Press. 12. Mark Duchaineau, Murray Wolinsky, David E. Sigeti, Mark C. Miller, Charles Aldrich, and Mark B. Mineev-Weinstein. ROAMing terrain: real-time optimally adapting meshes. In VIS ’97: Proceedings of the 8th conference on Visualization ’97, pages 8188, Los Alamitos, CA, USA, 1997. IEEE Computer Society Press. 13. Boris Rabinovich and Craig Gotsman. Visualization of large terrains in resource-limited computing environments. In VIS ’97: Proceedings of the 8th conference on Visualization ’97, pages 95102, Los Alamitos, CA, USA, 1997. IEEE Computer Society Press. 14. Stefan Röttger, Wolfgang Heidrich, Philipp Slusallek, and Hans-Peter Seidel. Real-Time Generation of Continuous Levels of Detail for Height Fields. In Proceedings of 1998 International Conference in Central Europe on Computer Graphics and Visualization, pages 315-322, 1998. 15. Hugues Hoppe. View-dependent renement of progressive meshes. In SIGGRAPH ’97: Proceedings of the 24th annual conference on Computer graphics and interactive techniques, pages 189198, New York, NY, USA, 1997. ACM Press/Addison-Wesley Publishing Co. 16. Hugues Hoppe. Smooth view-dependent level-of-detail control and its application to terrain rendering. In VIS ’98: Proceedings of the conference on Visualization ’98, pages 3542, Los Alamitos, CA, USA, 1998. IEEE Computer Society Press. 17. Leila De Floriani, Paola Magillo, and Enrico Puppo. Efficient implementation of multitriangulations. In VIS ’98: Proceedings of the conference on Visualization ’98, pages 4350, Los Alamitos, CA, USA, 1998. IEEE Computer Society Press. 18. Willem H. de Boer. Fast Terrain Rendering Using Geometrical MipMapping. 2000. http:www.flipcode.comarticlesarticle geomipmaps.shtml. 19. Peter Lindstrom and Valerio Pascucci. Visualization of large terrains made easy. In VIS ’01: Proceedings of the conference on Visualization ’01, pages 363-371, Washington, DC, USA, 2001. IEEE Computer Society. 20. Reinhard Klein and Andreas Schilling. Effiient Multiresolution Models for Progressive Terrain Rendering. it - Information Technology, 44(6):314-321, 2002. 21. P. Cignoni, F. Ganovelli, E. Gobbetti, F. Marton, F. Ponchio, and R. Scopigno. Bdam batched dynamic adaptive meshes for high performance terrain visualization, 2003. 22. Paolo Cignoni, Fabio Ganovelli, Enrico Gobbetti, Fabio Marton, Federico Ponchio, and Roberto Scopigno. Planet-Sized Batched Dynamic Adaptive Meshes (P-BDAM). In VIS ’03: Proceedings of the 14th IEEE Visualization 2003 (VIS’03), page 20, Washington, DC, USA, 2003. IEEE Computer Society. 23. Frank Losasso and Hugues Hoppe. Geometry clipmaps: terrain rendering using nested regular grids. In SIGGRAPH ’04: ACM SIGGRAPH 2004 Papers, pages 769776, New York, NY, USA, 2004. ACM Press. 24. Alex Holkner. Hardware Based Terrain Clipmapping, 2004. http: //yallara.cs.rmit.edu.au/ aholkner/rr/ah-terrain.pdf. 25. Ed Catmull. A Subdivision Algorithm for Computer Display of Curved Surfaces. University of Utah, 1974. Introducción de información geográfica en terrenos 3D 81 26. Michael A. Cosman. Global Terrain Texture: Lowering the Cost. In Eric G. Monroe, editor, Proceedings of 1994 IMAGE VII Conference, pages 53-64. The IMAGE Society, 1994. 27. Christopher C. Tanner, Christopher J. Migdal, and Michael T. Jones. The clipmap: a virtual mipmap. In SIGGRAPH ’98: Proceedings of the 25th annual conference on Computer graphics and interactive techniques, pages 151158, New York, NY, USA, 1998. ACM Press. 28. Tobias Hüttner. High Resolution Textures. In Visualization ’98 Late Breaking Hot Topics Papers, pages 1317, November 1998. 29. David Cline and Parris K. Egbert. Interactive display of very large textures. In VIS ’98: Proceedings of the conference on Visualization ’98, pages 343350, Los Alamitos, CA, USA, 1998. IEEE Computer Society Press. 30. Jürgen Döllner, Konstantin Baumman, and Klaus Hinrichs. Texturing techniques for terrain visualization. In VIS ’00: Proceedings of the conference on Visualization ’00, pages 227-234, Los Alamitos, CA, USA, 2000. IEEE Computer Society Press. 31. Anders Brodersen. Real-time visualization of large textured terrains. In GRAPHITE ’05: Proceedings of the 3rd international conference on Computer graphics and interactive techniques in Australasia and South East Asia, pages 439442, New York, NY, USA, 2005. ACM Press. 32. Anton Ephanov and Chris Coleman. Virtual Texture: A Large Area Raster Resource for the GPU. In The Interservice/Industry Training, Simulation and Education Conference (I/ITSEC). I/ITSEC, 2006. 33. Zachary Wartell, Eunjung Kang, Tony Wasilewski, William Ribarsky, and Nickolas Faust. Rendering vector data over global, multi-resolution 3D terrain. In VISSYM ’03: Proceedings of the symposium on Data visualisation 2003, pages 213222, Aire-la-Ville, Switzerland, Switzerland, 2003. Eurographics Association. 34. David Koller, Peter Lindstrom, William Ribarsky, Larry F. Hodges, Nick Faust, and Gregory Turner. Virtual GIS: A Real-Time 3D Geographic Information System. In VIS ’95: Proceedings of the 6th conference on Visualization ’95, page 94, Washington, DC, USA, 1995. IEEE Computer Society. 35. P. Lindstrom, D. Koller, W. Ribarsky, L. Hodges, and N. Faust. An integrated global gis and visual simulation system, 1998. 36. Anupam Agrawal, M. Radhakrishna, and R. C. Joshi. Geometry-based Mapping and Rendering of Vector Data over LOD Phototextured 3D Terrain Models. In Joaquim Jorge and Vaclav Skala, editors, The 14th International Conference in Central Europe on Computer Graphics, Visualization and Computer vision - WSCG’2006, 2006. 37. Arne Schilling, Jens Basanow, and Alexander Zipf. Vector Based Mapping of Polygons on Irregular Terrain Meshes for Web 3D Map Services. In 3rd International Conference on Web Information Systems and Technologies (WEBIST), march 2007. 38. Oliver Kersting and Jürgen Döllner. Interactive 3D visualization of vector data in GIS. In GIS ’02: Proceedings of the 10th ACM international symposium on Advances in geographic information systems, pages 107-112, New York, NY, USA, 2002. ACM Press. 39. Stephen Brooks and Jacqueline L. Whalley. A 2D/3D hybrid geographical information system. In GRAPHITE ’05: Proceedings of the 3rd international conference on Computer graphics and interactive techniques in Australasia and South East Asia, pages 323330, New York, NY, USA, 2005. ACM Press. 40. M. Schneider, M. Guthe, and R. Klein. Real-time Rendering of Complex Vector Data on 3D Terrain Models. In H. Thwaites, editor, The 11th International Conference on Virtual Systems and Multimedia (VSMM2005), pages 573-582. ARCHAEOLINGUA, October 2005. 41. Martin Schneider and Reinhard Klein. Efficient and Accurate Rendering of Vector Data on Virtual Landscapes. In The 15-th International Conference in Central Europe on Computer Graphics, Visualization and Computer Vision’2007, 2007. 42. Lance Williams. Pyramidal parametrics. In SIGGRAPH ’83: Proceedings of the 10th annual conference on Computer graphics and interactive techniques, pages 111, New York, NY, USA, 1983. ACM Press. Visualización 3D del interior de terrenos mineros M. Linarejos Rivero Cejudo Resumen En este trabajo se presenta como aplicar las técnicas y las amplias posibilidades del lenguaje Matlab para la simulación y visualización de terrenos. Se han estudiado las principales funciones gráficas que ofrece este lenguaje, decidiéndonos por el uso de los slices al ser útiles para explorar conjuntos de datos volumétricos y descubrir regiones interesantes. Esta caracterı́stica los hace ideales para el tipo de datos y problema que se nos plantea en el estudio de terrenos mineros. Se ha aplicado el estudio a un ejemplo práctico sobre datos reales de terrenos mineros. 1. Introducción En este trabajo se presenta como aplicar las técnicas y las amplias posibilidades del lenguaje Matlab para la simulación y visualización de terrenos. Ası́ la Tomografı́a Eléctrica es una técnica geofı́sica empleada en el estudio del subsuelo que consiste en determinar la distribución de un parámetro fı́sico caracterı́stico del mismo (la resistividad), a partir de un número muy elevado de medidas realizadas desde la superficie del terreno o desde perforaciones. El diferente comportamiento geoeléctrico del medio permite obtener perfiles 2D e imágenes 3D de la distribución de resistividades del mismo, por lo que se trata de una de las herramientas de carácter no destructivo más eficaz para el análisis y caracterización de posibles discontinuidades del subsuelo [1]. El rango de estudio puede variar desde algunos metros hasta centenares de metros de profundidad. Esta técnica tiene enormes posibilidades de aplicación en diversos medios geológicos y en distintas problemáticas. M.L. Rivero Departamento de Informática. Universidad de Jaén EPS de Linares (Jaén) e-mail: [email protected] 83 84 M. Linarejos Rivero Cejudo En este trabajo se parte de los datos obtenidos empiricamente sobre el terreno de la Figura 1 , para obtener una simulación de la resistividad global del terreno y su posterior visualización. 2. Trabajo realizado Para la realización del trabajo se han empleado los datos proporcionados en el articulo de los profesores [2], ellos emplearon el método eléctrico de resistividades en su modalidad de tomografı́a eléctrica. El método se basa en la implantación de electrodos a lo largo de perfiles, con una separación que viene condicionada por el grado de resolución, la profundidad y los objetivos que se pretendan cubrir, de tal modo que, a menor separación mayor resolución y a mayor separación mayor profundidad. Para el caso concreto que nos ocupa, se realizaron distintos ensayos en una campaña piloto con espaciado de 3, 5 y 10 m, para conseguir que, con suficiente resolución, se pudiesen prospectar las antiguas labores superficiales que alcanzaron unos 30-40 m de profundidad. El equipo de tomografı́a eléctrica utilizado en este estudio es el modelo RESECS de la marca Deutsche Montan Technologie (DMT). Es un equipo multielectrodo con ordenador integrado capaz de gestionar hasta 960 electrodos. Se han seleccionado 3 perfiles en el entorno del pozo de San Genaro, presentando la zona una orografı́a plana. Los dos primeros perfiles son paralelos entre sı́ y separados 60 m, y el tercero, perpendicular a las dos anteriores. Los tres se han ejecutado con una configuración Wenner-Schlumberger, con un espaciado entre electrodos de 5 m. Los dos primeros se extienden a lo largo de 395 m, con 80 electrodos y una orientación N 113 E (perpendiculares al filón principal de la concesión). Por el contrario, el Perfil 3, se extiende 315 m, con 64 electrodos, y coincide con la traza del filón (N23 E). A partir de estos datos vamos a realizar un estudio de las principales funciones de Matlab para el tratamiento y la visualización de datos volumétricos con el fin de aplicar los resultados obtenidos a la simulación y visualización de terrenos mineros. 3. Matlab y su uso en Ingenierı́a Matlab es un potente lenguaje diseñado para la computación técnica. El nombre de Matlab proviene de Matrix LABoratory, dado que el tipo básico que gestiona es una matriz (array). Matlab puede ser utilizado en computación matemática, modelado y simulación, análisis y procesamiento de datos, visualización y representación de gráficos, ası́ como para el desarrollo de algoritmos. Es un lenguaje muy popular en el ámbito de la computación cientı́fica que es utilizado por estudiantes, ingenieros y cientı́ficos en universidades, institutos de investigación e industrias. Su popularidad se debe, fundamentalmente, a su potencia y su facilidad de uso. Visualización 3D del interior de terrenos mineros 85 Fig. 1 A. Mapa esquemático del distrito minero de Linares.B. Situación de la región estudiada y localización de los tres perfiles analizados. Matlab proporciona excelentes utilidades para calculos de algebra lineal, análisis de datos, procesamientos de señales, y muchos otros tipos de soluciones numéricas para cálculos cientı́ficos [4], [3]. Hay numerosas funciones para gráficos de 2D y 3D, y para animación. 86 M. Linarejos Rivero Cejudo 4. Gráficos en Matlab Los gráficos son herramientas muy utilizadas para representar todo tipo de información: información que puede proceder de cualquier campo del conocimiento, pero especialmente de las disciplinas relacionadas con las ciencias y la ingenierı́a, donde Matlab es ampliamente utilizado. Matlab incluye excelentes utilidades para visulaización: funciones básicas para visualización en 2D, gráficos en 3D con iluminación y mapa de colores y un completo manejador de gráficos (Handle Graphics) que permite diseñar sofisticados gráficos a través de la interfaz de usuario. Algunos de los principales comandos para gráficos en 2D son: plot: crear gráficos en lı́nea bidimensionales a partir de dos vectores. fplot: representatar gráficamente una función de la forma y=f(x). hist: hace histogramas loglog: crea gráficos con escala logarı́tmica en ambos ejes x,y. pcolor: crea un gráfico de color rectángular Los gráficos en 3D permiten una forma muy práctica de representar datos de más de dos variables. Podemos clasificarlos en gráficos de lı́neas y gráficos de malla y superficie. 4.1. Gráficos de lı́nea Un gráfico 3D de lı́nea está constituido por una lı́nea que se obtiene uniendo una serie de puntos en un espacio tridimensional. La forma más sencilla y básica de crear un gráfico 3D es mediante la función plot3 de Matlab, cuya sintaxis es la siguiente: plot3(x,y,z, Éspecificadores de lı́nea’, ’Propiedades’, ’Valores’). El siguiente fragmemnto de código visualiza el gráfico que se muestra en la Figura 2. t = 0:pi/50:10*pi; plot3(sin(t),cos(t),t); grid on; axis square; 4.2. Gráficos de malla y superficie Los gráficos de malla y superficie son gráficos tridimensionales utilizados para representar funciones que tienen la forma z=f(x,y), donde x e y son variables independientes , y z es la variable dependiente. Los gráficos de malla y superficie se generan en tres pasos: Visualización 3D del interior de terrenos mineros 87 35 30 25 20 15 10 5 0 1 1 0.5 0.5 0 0 −0.5 −0.5 −1 −1 Fig. 2 Ejemplo del uso de la orden plot3. 1. el primer paso es crear una malla o rejilla en el plano x-y que cubra el dominio de la función, la densidad de la rejilla debe ser definida por el usuario. Los puntos de la rejilla se pueden definir mediante dos matrices X e Y, donde la matriz X se construye a través de filas iguales, ya que en cada fila los puntos tienen las misma coordenada x. De manera similar, la matriz Y se construye con columnas idénticas. Matlab posee una función denominada meshgrid que crea automáticamente las matrices X e Y. La sintáxis de esta función es la siguiente: [X,Y]= meshgrid{x,y} donde x es un vector que representa el dominio de x, e y representa un vector con el dominio de y. 2. El segundo paso es calcular el valor de z en cada punto de la rejilla. 3. Representar el gráfico de malla o superficie: Un gráfico de malla se compone de lı́neas que unen los puntos, al igual que en el gráfico de superficie, aunque en este caso las áreas resultantes entre los huecos se rellenan con colores. a) Gráficos de malla: Se lleva a cabo mediante el comando mesh. En la Figura 3 se observa el resultado para el siguiente fragmento de código, donde X e Y 88 M. Linarejos Rivero Cejudo son las matrices con las coordenadas de rejilla, y Z la matriz con los valores de z sobre la rejilla de puntos: [X,Y] = meshgrid(-3:.125:3); Z = peaks(X,Y); mesh(X,Y,Z); axis([-3 3 -3 3 -10 5]) 5 0 −5 −10 3 2 3 1 2 0 1 0 −1 −1 −2 −2 −3 −3 Fig. 3 Ejemplo del uso de la orden mesh. b) Gráficos de superficie: Se lleva a cabo mediante el comando surf. En la Figura 4 se observa el resultado para el siguiente fragmento de código. [X,Y,Z] = peaks(30); surfc(X,Y,Z) colormap hsv axis([-3 3 -3 3 -10 5]) Variantes para los comandos mesh y surf son: meshc y surfc dibujan un contorno debajo de la malla o la superficie, o bien las ordenes meshz y surfz dibujan una cortina alrededor de la malla o superficie. Los gráficos creados tienen colores que pueden variar en función de la magnitud z, para controlar el color de las superficies y objetos gráficos Matlab proporciona la orden shading que controla el color de las superficies y de los objetos gráficos. Tiene tres posibles usos: shading flat: cada lı́nea de segmento o cada cara tiene el mismo color que el punto final del segmento o la esquina con menor ı́ndice de la cara. Visualización 3D del interior de terrenos mineros 89 5 0 −5 −10 3 2 3 1 2 0 1 0 −1 −1 −2 −2 −3 −3 Fig. 4 Ejemplo del uso de la orden surf. shading faceted: dibuja superpuestas las lı́neas de la malla. shading interp: varı́a el color de cada lı́nea de segmento o cara por interpolación. Por ejemplo, las siguientes lı́neas de código dan como resultado la esfera de la Figura 5. subplot(3,1,3) sphere(16) axis square shading interp title(’Interpolated Shading’) 5. Visualización de terrenos mineros mediante Matlab Una de las necesidades más cruciales en la computación cientı́fica es la visualización de datos volumétricos, definidos sobre espacios tridimensionales. Es la casuı́stica que se nos presenta para visualizar el valor de resistividad de un terreno minero definido para cada tripleta (x,y,z). ¿Cómo podemos visualizarlo gráficamente?. En el caso de una función de la forma z= f (x,y) definida sobre una región del plano xy podemos visualizar z o f como una superficie 3D. Pero a la hora de visualizar valores de resistividad de un terreno minero tenemos una función f (x,y,z), necesitamos una hipersuperficie 4D. Matlab proporciona una serie de funciones para visualizar datos volumétricos: isosurface, isonormal, isocolors, isocaps, smooth3, 90 M. Linarejos Rivero Cejudo Interpolated Shading 1 0 −1 1 0 −1 −1 0 1 Fig. 5 Ejemplo del uso de la orden shading. slice y slicecontour, [5] y [6]. Veamos estas funciones antes de abordar nuestro problema. isosurface: Dado un volumen V obtiene una estructura fv con las caras y los vértices de la superficie que encierra el volumen V. Esta función tiene el siguiente formato fv = isosurface(X,Y,Z,V,isovalue), se conectan los puntos que tienen el valor isovalue especificado. Una vez obtenida la estructura se le pasa a la función patch para crear el objeto gráfico. patch: Es una función para crear objetos gráficos, uno o más polı́gonos definidos por las coordenadas de sus vértices. En la Figura 6 se muestra el resultado del siguiente fragmento de código. [x,y,z,v] = flow; p = patch(isosurface(x,y,z,v,-3)); isonormals(x,y,z,v,p) set(p,’FaceColor’,’red’,’EdgeColor’,’none’); daspect([1 1 1]) view(3); axis tight Visualización 3D del interior de terrenos mineros 91 camlight lighting gouraud Fig. 6 Ejemplo del uso de la orden isosurface. smooth3: filtra los datos de un volumen V mediante la convolución de kernel determinada por dos matrices posibles: gaussiana, o box. El formato de la función es W = smooth3(V,’filter’). isocolors: calcula el color de un objeto gráfico a partir de una matriz de colores C. El formato de esta función es nc = isocolors(X,Y,Z,C,patch), en la Figura 7 se muestra una superficie coloreada de acuerdo a una matriz de color aleatoria. [x y z] = meshgrid(1:20,1:20,1:20); data = sqrt(x.ˆ2 + y.ˆ2 + z.ˆ2); cdata = smooth3(rand(size(data)),’box’,7); p = patch(isosurface(x,y,z,data,10)); isonormals(x,y,z,data,p); isocolors(x,y,z,cdata,p); set(p,’FaceColor’,’interp’,’EdgeColor’,’none’) view(150,30); daspect([1 1 1]);axis tight camlight; lighting phong; 92 M. Linarejos Rivero Cejudo Fig. 7 Ejemplo del uso de las ordenes smooth3 y isocolors. isocaps: genera de forma similar a isosurface un objeto gráfico a partir de un volumen, pero generando planos ajustados a los lı́mites de la isosurface para proporcionar un contexto visual de la misma mediante una vista de una sección transversal del interior de la isosurface. Para que se pueda apreciar este efecto en la Figura 8 se muestra una isosurface sin aplicar la orden isocaps. En la Figura 9 podemos ver el efecto de aplicar la función isocaps a la anterior figura. slice: visualiza un corte plano perpendicular a un volumen dado. El formato de la función es slice(X,Y,Z,V,sx,sy,sz,’method’), donde se dibujan cortes sobre el volumen V en los puntos de los vectores sx,sy, y sz. El color en cada punto viene determinado por el método de interpolación utilizado: lineal, cúbico o vecino más cercano. En la Figura 10 se visualiza varios cortes sobre un volumen en los puntos indicados por los vectores xslice = [-1.2,.8,2]; yslice = 2; zslice = [-2,0];, de acuerdo al siguiente fragmento de código: [x,y,z] = meshgrid(-2:.2:2,-2:.25:2,-2:.16:2); v = x.*exp(-x.ˆ2-y.ˆ2-z.ˆ2); xslice = [-1.2,.8,2]; yslice = 2; zslice = [-2,0]; slice(x,y,z,v,xslice,yslice,zslice) colormap hsv Visualización 3D del interior de terrenos mineros 93 Fig. 8 Ejemplo del uso de las ordenes smooth3 y isocolors. Los slices son útiles para explorar conjuntos de datos volumétricos y descubrir regiones interesantes, esta caracterı́stica los hace ideales para el tipo de datos y problema que se nos plantea en el estudio de terrenos mineros.Por ello será la opción elegida tal y como detallamos acontinuación. Una vez analizadas estas funciones estamos en condiciones de afrontar nuestro problema.Tal y como se indicó en la Sección 1 se pretende a partir de los datos extraı́dos empiricamente sobre un terreno, obtener una simulación de la resistividad global del terreno estudiado. Los datos empiricos son perfiles de la zona en paralelo o perpendiculares, se trata pues de datos no uniformemente espaciados que necesitan ser interpolados para conocer el valor de resistividad del resto del terreno. Para la interpolación de estos tipos de datos Matlab proporciona la función griddata3, esta función tiene el siguiente formato w = griddata3(x,y,z,v,xi,yi,zi,method), donde se obtiene una hipersuperficie de la forma w=f (x,y,z) para los datos no uniformemente espaciados de los vectores (x,y,z,v). La función griddata3 interpola la hipersuperficie en los puntos especificados por (xi,yi,zi) para obtener w, el tamaño de w es el mismo que el de xi,yi y zi, (xi,yi,zi), es un rejilla uniforme obtenida mediante la función meshgrid para las dimensiones del terreno que se quiere simular. Ası́ la función [X,Y,Z]=meshgrid(x,y,z) produce arrays tridimensionales para 94 M. Linarejos Rivero Cejudo Fig. 9 Ejemplo del uso de las ordenes smooth3 y isocolors. evaluar funciones de tres variables y visualizar volumenes tridimensionales. En el siguiente fragmento de código se han generado tres vectores aleatorios con datos no uniformes, se ha creado una rejilla desde -0.8 a 0.8 de 0.5 en 0.5. Aplicando la interpolación de la orden griddata3 se obtiene los valores de la hipersuperficie en toda la rejilla. En la Figura 11 se muestra el resultado. rand(’state’,0); x = 2*rand(5000,1)-1; y = 2*rand(5000,1)-1; z = 2*rand(5000,1)-1; v = x.ˆ2 + y.ˆ2 + z.ˆ2; d = -0.8:0.05:0.8; [xi,yi,zi] = meshgrid(d,d,d); w = griddata3(x,y,z,v,xi,yi,zi); p = patch(isosurface(xi,yi,zi,w,0.8)); isonormals(xi,yi,zi,w,p); set(p,’FaceColor’,’blue’,’EdgeColor’,’none’); view(3), axis equal, axis off, camlight, lighting phong Una vez obtenida la hipersuperficie interpolada queda visualizarla, tras el estudio realizado de las diferentes funciones que Matlab proporciona para la visualización Visualización 3D del interior de terrenos mineros 95 2 1.5 1 0.5 0 −0.5 −1 −1.5 −2 2 2 1 1 0 0 −1 −1 −2 −2 Fig. 10 Ejemplo del uso de la orden slice. de datos volumétricos la solución adoptada es visualizar mediante cortes (slicing) Fig. 11 Ejemplo del uso de la orden grid. 96 M. Linarejos Rivero Cejudo a lo largo de varios planos en 3D y visualizar los datos de estos planos mediante mapas de colores. A continuación resumimos el proceso que se ha seguido: 1. primeramente cargar los datos de los tres perfiles de los que se han tomado datos sobre el terreno, en la Figura 12 se muestra el gráfico de resistividad para los tres perfiles. 2. A partir de dichos datos crear los cuatro vectores X,Y,Z, y V, los tres primeros con las coordenadas y el último con el valor de resistividad para esas coordenadas. 3. Posteriormente creamos la rejilla de datos sobre la que se quiere visualzar los resultados, que atendiendo a los datos de los perfiles debe ser x=1:350, y=1:500, z=1:100. 4. A partir de los cuatro vectores creados (X,Y,Z, y V) interpolamos para los puntos especificados por la rejilla establecida en x, y, z, obteniendo el valor de resistividad del terreno (griddata3(X,Y,Z,V,x,y,z). 5. Una vez obtenida la hipersuperficie interpolada visualizaremos aquellos cortes del terreno que se deseen a través de la función de Matlab slice aplicando el método de interpolación nearest para determinar el color en cada punto. En la Figura 12 se muestran los tres cortes realizados mediante la orden slice en la misma zona en la que se han tomado los tres perfiles con el fin de que se observe la similitud con los resultados visualizados. 6. Conclusiones En este trabajo se ha realizado un estudio completo de las principales funciones de Matlab para tratamiento y visualización de datos volumétricos, con el fin de su aplicación para la visualización de terrenos mineros. A partir de los datos extraidos empiricamente sobre un terreno minero se ha obtenido una simulación de la resistividad global del terreno estudiado. Los datos empı́ricos utilizados son perfiles de la zona en paralelo o perpendiculares, se trata pues de datos no uniformemente espaciados que necesitan ser interpolados para conocer el valor de resistividad del resto del terreno. Para la interpolación de estos tipos de datos se ha utilizado la función griddata3 de Matlab, y para la visualización se ha optado por mostrar aquellos cortes del terreno que se deseen mediante la función (slice) aplicando el método de interpolación nearest para determinar el color en cada punto. Referencias 1. Sasaki, Y. Geophysical Prospecting, 54, 453-464. 1992 2. Martinez, J., Rey, J., Sandoval, S., Rodriguez, M. La tomografı́a eléctrica: una herramienta para la detección de huecos mineros (concesión de Arrayanes, Linares-Jaén). Geogaceta, 42, 2007 Visualización 3D del interior de terrenos mineros 97 Fig. 12 Resultados obtenidos aplicando slice sobre los datos mineros. 3. Pratap, R. A Quick Introduction for Scientist and Engineers. Getting Started with Matlab 7, Oxford University Press, 2006 4. Gilat, A. Matlab. Una introducción con ejemplos prácticos, Reverté, 2006 98 M. Linarejos Rivero Cejudo 5. The Math Works. Creating Graphical User Interfaces, Version 7. The Math Works, Inc. ,2004 6. The Math Works. Using Matlab Graphics, Version 7. The Math Works, Inc., 2004. Bloque III Algoritmos básicos Operaciones Booleanas sobre polı́gonos Francisco Martı́nez del Rı́o, Ángel Aguilera Garcı́a y J. Roberto Jiménez Pérez Resumen Algunos algoritmos que calculan operaciones Booleanas sobre polı́gonos producen como resultado un polı́gono con casi nula información topográfica. En concreto, no se conoce qué vertices forman cada uno de los contornos del polı́gono, ni se sabe si el polı́gono contiene agujeros. En este artı́culo se propone un algoritmo que, dada una descripción de un polı́gono formada por una serie de aristas no conectadas, calcula los contornos asociados al polı́gono, los contornos incluidos en otros contornos y si los contornos están incluidos en un número par o impar de contornos. 1. Introducción Las operaciones Booleanas entre polı́gonos juegan un papel importante en distintos campos aplicados como la Informática Gráfica o los Sistemas de Información Geográfica. Una de sus aplicaciones en Informática Gráfica es el recorte de polı́gonos. En este caso el polı́gono de recorte puede presentar ciertas restricciones que facilitan el cálculo de la operación. Por ejemplo, los algoritmos de Andereev [1] y de Sutherland y Hodgeman [2] precisan que el polı́gono de recorte sea convexo, mientras que el algoritmo de Liang y Barsky [3] requiere un polı́gono de recorte rectangular. Para el caso general de polı́gonos, por ejemplo, polı́gonos cóncavos, con agujeros y/o auto-intersecciones existen menos soluciones. Greiner y Hormann [4] proponen una algoritmo muy sencillo y elegante; sin embargo, en el artı́culo no se trata satisfactoriamente algunos casos degenerados, Kim y Kim [5] extienden el algoritmo Francisco Martı́nez del Rı́o Universidad de Jaén, e-mail: [email protected] Ángel Aguilera Garcı́a Universidad de Jaén, e-mail: [email protected] Juan Roberto Jiménez Pérez Universidad de Jaén, e-mail: [email protected] 101 102 Francisco Martı́nez del Rı́o, Ángel Aguilera Garcı́a y J. Roberto Jiménez Pérez para procesar correctamente los casos degenerados. Liu et al. [6] también extienden el algoritmo para que pueda trabajar con polı́gonos con agujeros y con varios contornos, aunque en el camino se pierde gran parte de la sencillez del algoritmo original. Rivero y Feito [7] y Peng et al. [8] presentan algoritmos muy elegantes, desde un punto de vista matemático, basados en las cadenas de sı́mplices de Feito [9] que resuelven las operaciones Booleanas entre polı́gonos. Desafortunadamente los algoritmos producen como resultado un polı́gono con casi nula información topográfica. En concreto, no se conoce qué vertices forman cada uno de los contornos del polı́gono, ni se sabe si el polı́gono contiene agujeros. Esto último también ocurre en el algoritmo de Martı́nez et al. [10]. En este artı́culo se propone cómo calcular la información topológica que no calculan los citados algoritmos [7, 8, 10]. Lo que resta de artı́culo se organiza de la siguiente forma. En la Sección 2 se describe la información topológica de un polı́gono que vamos a computar. La Sección 3 muestra cómo se pueden calcular los distintos contornos del polı́gono. Las Secciones 4 y 5 describen cómo se calcula la información sobre los contornos incluidos en otros contornos. La última sección muestra un análisis del orden de complejidad del algoritmo propuesto. 2. Fundamentos Dado un polı́gono que consta de varios contornos denominaremos contorno externo a aquel contorno no incluido en ningún otro contorno del polı́gono y denominaremos contorno interno a aquel contorno incluido en al menos un contorno del polı́gono. Dado un contorno interno H de un polı́gono, llamaremos contorno padre de H al contorno, P, igual a la intersección de todos los contornos que contienen a H. Dicho de otro modo, P es el contorno de menor área que contiene a H. También diremos que H es un contorno hijo de P. Se puede representar un polı́gono que consta de varios contornos de la siguiente forma: Los contornos externos y los contornos incluidos en un número par de contornos se describen listando sus vértices en orden antihorario. Los contornos incluidos en un número impar de contornos se describen listando sus vértices en orden horario. Por cada contorno se listan sus contornos hijos. Por ejemplo, en la Figura 1 se representa un polı́gono utilizando esta convención. Dada esta representación se puede calcular el área de un polı́gono como la suma con signo de las áreas de los contornos del polı́gono. En las siguientes secciones se describe un algoritmo que, dada una especificación de un polı́gono como un conjunto no conectado de aristas, calcula los contornos Operaciones Booleanas sobre polı́gonos 103 D C Q G K J M P O N E F L H A I B Contorno 1: A, B, C, D Contorno 2: E, G, F Contorno 3: H, K, J, I Contorno 4: N, L, M Contorno 5: O, P, Q Hijos del contorno 1: 2, 3 Hijos del contorno 3: 4 Fig. 1 Especificación de un polı́gono asociados al polı́gono, los contornos hijos de cada contorno y el nivel de profundidad de cada contorno—de cara a su correcta orientación. 3. Cálculo de los contornos Los algoritmos de Rivero y Feito [7] y Peng et al. [8] calculan los sı́mplices asociados a una operación Booleana entre dos polı́gonos; cada sı́mplice está asociado a una arista distinta del polı́gono. Por lo tanto, los algoritmos producen como resultado un conjunto no conectado de aristas. Dado un conjunto no conectado de aristas de un polı́gono es fácil calcular los contornos asociados al polı́gono—es decir, es fácil conectar las aristas para formar contornos—de una forma eficiente [12]. Basta con introducir en un árbol binario de búsqueda equilibrado los extremos de las aristas del polı́gono ordenados lexicográficamente. Cada extremo almacena también el otro extremo de su arista. De esta forma se puede empezar por un vértice cualquiera de un contorno y encontrar una cadena de aristas conectadas que terminan en el propio vértice en tiempo O(n log n), donde n es el número de vértices del polı́gono. 4. Cálculo de los contornos hijos En esta sección se describe el algoritmo para el cálculo de los contornos hijos y el cálculo del número de contornos que incluyen a cada contorno. El algoritmo está basado en el famoso paradigma del barrido del plano [11]. Nuestro algoritmo barre el plano de izquierda a derecha con una lı́nea vertical: la lı́nea de barrido. El estado de la lı́nea de barrido, S, consta de las aristas del polı́gono que intersectan la lı́nea de barrido ordenadas por la coordenada y en la que intersectan a la lı́nea de barrido—véase la Figura 2. Supondremos que las aristas del polı́gono no intersectan entre sı́, salvo en sus extremos. Por lo tanto, S sólo cambia cuando la lı́nea de barrido alcanza un extremo de una arista: 104 Francisco Martı́nez del Rı́o, Ángel Aguilera Garcı́a y J. Roberto Jiménez Pérez línea de barrido Fig. 2 La lı́nea de barrido (las aristas discontinuas pertenecen al estado de la lı́nea de barrido). Cuando, durante el barrido, se alcanza el extremo izquierdo de una arista, la arista debe añadirse a S. Cuando se alcanza el extremo derecho de una arista, la arista debe eliminarse de S. A continuación se describe cómo se puede utilizar S para calcular eficientemente, durante el barrido, los contornos hijos. Supongamos que la lı́nea de barrido alcanza un nuevo contorno c: una arista e de c se inserta en S. Es posible saber el contorno padre de c comprobando información sobre la arista p que precede a e en S. Una información clave es saber si p representa una transición dentro-fuera o fuera-dentro en su contorno para un rayo vertical que empieza debajo del contorno y cruza p. La Figura 3 ilustra los cuatro casos posibles. A continuación se describe cómo se procesan estos casos: 1. e no tiene una arista que le preceda en S. Por lo tanto, c no se encuentra en el interior de ningún contorno, es decir, c es un contorno externo. 2. p representa una transición fuera-dentro en el contorno c2. Por lo tanto, c es un contorno hijo de c2. 3. p representa una transición dentro-fuera en c2 y c2 es un contorno externo. En ese caso se concluye que c es un contorno externo. 4. p representa una transición dentro-fuera en c2 y c2 es un contorno interno. En ese caso c es un contorno interno y tiene por contorno padre al contorno padre de c2. A continuación se describe el algoritmo—véase la Figura 4. En primer lugar, se insertan en un vector los extremos de las aristas y se ordena el vector lexicográficamente. De este modo los extremos se procesan de izquierda a derecha en el ciclo foreach . Cada extremo se procesa de la siguiente manera. Cuando se encuentra un extremo izquierdo su arista asociada se inserta en el estado de la lı́nea de barrido (S). Operaciones Booleanas sobre polı́gonos 105 c c2 c e p e 1) 2) c c e e p c2 3) p c2 4) Fig. 3 Los cuatro casos posibles para determinar el contorno padre de c. Si la lı́nea de barrido alcanza la primera arista de un contorno entonces se comprueba si es un contorno hijo siguiendo los casos descritos previamente—los detalles de implementación se dan en la Sección 5.1. Cuando se encuentra un extremo derecho su arista asociada se elimina de S. 5. Detalles de implementación En las siguientes subsecciones se explican algunos detalles de implementación del algoritmo que calcula los contornos hijos y el número de contornos que incluyen a cada contorno. 5.1. Información de contorno hijo En esta subsección se describe la información relativa al cálculo de contornos hijos y el pseudocódigo utilizado para el cálculo de esta información. Las aristas almacenadas en S son registros con los siguientes campos: inOut: un valor lógico que almacena si la arista representa una transición dentro- fuera en su contorno asociado para un rayo vertical que comienza por debajo del contorno y cruza la arista. contornoId : un identificador entero del contorno asociado a la arista. 106 Francisco Martı́nez del Rı́o, Ángel Aguilera Garcı́a y J. Roberto Jiménez Pérez Entrada L : l i s t a de i d e n t i f i c a d o r e s de c o n t o r n o s Salida p r o f P a r : v e c t o r de b o o l h i j o s : v e c t o r de l i s t a s de i d e n t i f i c a d o r e s de c o n t o r n o s Variables v : v e c t o r o f e x t r e m o s de a r i s t a s S : ABB de a r i s t a s ( e s t a d o de l a l i n e a de b a r r i d o ) p r o c e s a d o s : v e c t o r de b o o l / / v a l o r e s i n i c i a d o s a f a l s o Algoritmo b a r r i d o p l a n o i n s e r t a r l o s e x t r e m o s de l a s a r i s t a s en v ordenar v lexicograficamente f o r e a c h e x t r e m o ex de v i f ex e s un e x t r e m o i z q u i e r d o p o s = S . i n s e r t ( ex . a r i s t a ) i f NOT p r o c e s a d o [ p o s . c o n t o r n o I d ] / / ¿ c o n t o r n o no p r o c e s a d o ? p r o c e s a d o [ pos . c o n t o r n o I d ] = v e r d a d e r o prev = S . prev ( pos ) c a l c u l a r i n f o r m a c i o n de i n c l u s i o n / / i m p l e m e n t a d o en F i g . 5 i f end else S . e r a s e ( ex . a r i s t a ) i f end f o r e a c h end Fig. 4 Algoritmo para el cálculo de contornos hijos. padreId : si el contorno asociado a la arista es un contorno externo, entonces almacena el identificador del contorno. En otro caso, almacena el identificador de su contorno padre. los dos extremos de la arista. El pseudocódigo mostrado en la Figura 5 calcula los contornos hijos teniendo en cuenta los cuatro casos analizados en la Sección 4. Los vectores profPar e hijos almacenan la información que devuelve el algoritmo. Dado un identificador de contorno id : profPar [ id ] indica si el contorno cuyo identificador es id está contenido en un número par de contornos. Esto es preciso para saber si los vértices del contorno debe enumerarse en orden horario o antihorario. hijos [ id ] almacena una lista con los identificadores de los contornos hijos del contorno cuyo identificador es id . Operaciones Booleanas sobre polı́gonos 107 i f p r e v == n u l l / / caso 1 p r o f P a r [ pos . c o n t o r n o I d ] = v e r d a d e r o pos . p a d r e I d = pos . c o n t o r n o I d e l s e i f NOT p r e v . i n O u t / / caso 2 p r o f P a r [ p o s . c o n t o r n o I d ] = NOT p r o f P a r [ p r e v . c o n t o r n o I d ] pos . p a d r e I d = prev . c o n t o r n o I d a g r e g a r pos . c o n t o r n o I d a l a l i s t a h i j o s [ prev . c o n t o r n o I d ] e l s e i f p r e v . p a d r e I d == p r e v . c o n t o r n o I d / / c a s o 3 p r o f P a r [ pos . c o n t o r n o I d ] = v e r d a d e r o pos . p a d r e I d = pos . c o n t o r n o I d else / / caso 4 p r o f P a r [ pos . c o n t o r n o I d ] = p r o f P a r [ prev . c o n t o r n o I d ] pos . p a d r e I d = prev . p a d r e I d a g r e g a r pos . c o n t o r n o I d a l a l i s t a h i j o s [ prev . p a d r e I d ] i f end Fig. 5 Pseudocódigo para calcular contornos hijos. 5.2. Aristas verticales Las aristas verticales son especiales porque intersectan a la lı́nea de barrido en más de un punto. Afortunadamente las aristas verticales no juegan ningún papel en el algoritmo, pues no representan una transición dentro-fuera o fuera-dentro en los contornos. Por lo tanto, nuestro algoritmo las elimina en una fase de procesamiento previo. 5.3. Cálculo del campo inOut El campo inOut de una arista puede calcularse fácilmente en una fase de procesamiento previo. Sea c un contorno cuyos vértices se orientan de manera antihoraria y sea e una arista no vertical de c cuyos extremos orientados son (x1 , y1 ) y (x2 , y2 ). Entonces, e representa una transición dentro-fuera en c para un rayo vertical que comienza por debajo de c y que atraviesa e si x1 > x2 ; en otro caso, e representa una transición fuera-dentro. Si los vértices de c están orientados de forma horaria, entonces e representa una transición dentro-fuera si x1 < x2 ; en otro caso, e representa una transición fuera-dentro. En caso de que se desconozca la orientación de los vértices, esta puede calcularse fácilmente teniendo en cuenta el signo del área signada del contorno. 108 5.4. Francisco Martı́nez del Rı́o, Ángel Aguilera Garcı́a y J. Roberto Jiménez Pérez Ordenación de los extremos En la Sección 4 se comentó que los extremos de las aristas se ordenan lexicográficamente. Sin embargo, algunos extremos estarán situados en la misma posición. En dicho caso se aplican las siguientes reglas: los extremos derechos preceden a los extremos izquierdos. los extremos izquierdos se ordenan en el orden ascendente de sus aristas asociadas en S. 6. Orden de complejidad En esta sección se analiza el orden de complejidad del algoritmo explicado en la Sección 4 y mostrado en la Figura 4. En el análisis denotaremos con e al número de aristas del polı́gono. En primer lugar el algoritmo descarta las aristas verticales y calcula el campo inOut de las aristas no verticales, insertando sus extremos en el vector v, lo que requiere un orden O(e). A continuación se ordena el vector v—O(e log e). Entonces empieza el barrido del plano y se procesan los extremos de las aristas en el ciclo foreach . Todas las instrucciones del ciclo tienen un orden constante, salvo las instrucciones que trabajan con S. S almacena a lo sumo e aristas, por lo tanto las instrucciones que trabajan con S—insertar, buscar, borrar y encontra el elemento previo—tienen un orden O(log e). El ciclo se ejecuta 2e veces, luego su complejidad es O(e log e). Con esto se concluye que la complejidad del algoritmo es O(e log e). Referencias 1. Andereev, R.D.: Algorithm for clipping arbitrary polygons. Computer Graphics Forum 8 (2), 183–191 (1989) 2. Sutherland, I.E., Hodgeman. G.W.: Reentrant polygon clipping. Communications of the Association for Computing Machinery 17 (1), 32–42, (1974) 3. Liang, Y.D., Barsky, B.A.: An analysis and algorithm for polygon clipping. Communications of the Association for Computing Machinery 26 (11), 868–877 (1983) 4. Greiner, G., Hormann, K.: Efficient clipping of arbitrary polygons. Association for Computing Machinery—Transactions on Graphics 17 (2), 71–83 (1998) 5. Kim, D.H., Kim, M.: An extension of polygon clipping to resolve degenerate cases. ComputerAided Design & Applications 3, 447–456 (2006) 6. Liu, Y.K., Wang, X.Q., Bao, S.Z., Gombos̆i, M., Z̆alik, B.: An algorithm for polygon clipping, and for determining polygon intersections and unions. Computers & Geosciences 33, 589–598 (2007) 7. Rivero M. Feito F.R.: Boolean operations on general planar polygons. Computers & Graphics 24 (6), 881–896 (2000) 8. Peng Y., Yong J.H., Dong W.M., Zhang H., Sun J.G.: A new algorithm for Boolean operations on general polygons. Computers & Graphics, 29 (1), 57–70 (2005) Operaciones Booleanas sobre polı́gonos 109 9. Feito F.R. Rivero M.: Geometric modelling based on simplicial chains. Computers & Graphics, 22 (5), 611–619 (1998) 10. Martı́nez F., Rueda A.J., Feito F.R.: A new algorithm for computing Boolean operations on polygons. Computers & Geosciences 35 (6), 1177–1185 (2009) 11. Preparata F.P., Shamos M.I.: Computational Geometry, An Introduction, 2nd edition. Springer-Verlag (1988) 12. Akenine-Möller T., Haines E., Hoffman N.: Real-Time Rendering, 3rd Edition. A. K. Peters, Ltd., Natick, MA, USA (2008) Algoritmos Geométricos Básicos Juan J. Jiménez Delgado, Antonio Martı́nez Albalá, Félix Paulano Godino y Rubén Pulido Ramı́rez Resumen A lo largo de este capı́tulo se incluyen algunos algoritmos geométricos básicos que pueden ser utilizados plenamente en algoritmos de bajo nivel para aplicaciones relacionadas con entornos urbanos. Este capı́tulo se divide en dos partes, la primera trata de algoritmos de inclusión y de intersección. La segunda trata de nuevas descomposiciones espaciales basadas en tri-trees y tetra-trees, aplicadas a los algoritmos anteriores, ası́ como de su implementación en GPU. 1. Introducción En este capı́tulo se establecen una serie de algoritmos básicos, como el test de inclusión punto en polı́gono y punto en sólido, ası́ como el test de intersección segmento-triángulo. Todos estos algoritmos son necesarios para optimizar el tiempo de detección de colisión entre modelos, necesitando de un cálculo robusto. Para una mayor optimización de los tiempos obtenidos, son necesarios métodos de descomposición espacial especialmente diseñados para reducir la complejidad de los modelos. Se estudian métodos de descomposición espacial basados en tritrees (2D) y su generalización a 3D, tetra-trees. Esta última se ha optimizado en la GPU mediante la programación de shaders, obteniéndose un método de cálculo de descomposición en GPU que puede ser aplicado a otros tipos de descomposiciones Jiménez J.J. Universidad de Jaén, Campus Las Lagunillas s/n A3-142, e-mail: [email protected] Martı́nez A. Universidad de Jaén, Campus Las Lagunillas s/n A3-103 e-mail: [email protected] Paulano F. Universidad de Jaén, Campus Las Lagunillas s/n A3-103 e-mail: [email protected] Pulido R. Universidad de Jaén, Campus Las Lagunillas s/n A3-103 e-mail: [email protected] 111 112 J.J. Jiménez, A. Martı́nez, F. Paulano y R. Pulido espaciales jerárquicas. Finalmente, se ha diseñado un método de descomposición espacial jerárquica exacta, que permite descomponer los modelos de manera que se optimicen las operaciones de consulta y la actualización del modelo y de la propia descomposición de manera óptima. 2. Algoritmos básicos 2.1. Test de inclusión punto en polı́gono El test de inclusión punto en polı́gono se utiliza de manera habitual en campos como la geometrı́a computacional, la informática gráfica o los sistemas de información geográfica. En muchos de estos casos, se ha de realizar no uno, sino varios test de inclusión de puntos en poliedros. El test de inclusión consiste en obtener un resultado booleano en función de si un punto está contenido en el interior o en la frontera de un polı́gono definido por una lista de vértices ordenados. En [6], se presentan nuevos algoritmos que generalizan el algoritmo basado en triángulos que permite realizar el test punto en polı́gono, de manera que puede ser aplicado en polı́gonos no convexos. Estos algoritmos no hacen uso de preprocesamiento ni de descomposiciones espaciales, por lo que son ideales para su aplicación en polı́gonos en movimiento y deformables. Con este fin, se utiliza el signo de las coordenadas baricéntricas del test de puntos con respecto a los triángulos de un recubrimiento especial del polı́gono. 2.1.1. Generalización del algoritmo basado en triángulos Con el fin de generalizar el algoritmo basado en triángulos mediante el uso de coordenadas baricéntricas, es necesario establecer las bases de la inclusión punto en triángulo. Para poder clasificar un punto con respecto a un triángulo, se utilizan tres valores únicos que representan las coordenadas baricéntricas de un punto con respecto a un triángulo en 2D. Según la definición clásica [1], las coordenadas baricéntricas (α , β , γ ) signadas de un punto P con respecto a un triángulo V0V1V2 quedan definidas por: α= |PV1V2 | |PV2V0 | |PV0V1 | ,β = ,γ = |V0V1V2 | |V0V1V2 | |V0V1V2 | (1) El algoritmo basado en triángulos [2] se basa en la sumatoria del signo de los triángulos del recubrimiento del polı́gono en el cual está situado el punto a clasificar. Dicho algoritmo comprueba el signo de cada uno de esos triángulos y suma los valores obtenidos, obteniendo una inclusión cuando la suma de dichos valores es uno. Además, considera algunos casos especiales como la inclusión de una arista Algoritmos Geométricos Básicos 113 compartida por dos triángulos del recubrimiento, considerando este caso como 21 multiplicado por el signo de cada uno de los triángulos. El algoritmo propuesto en [6] mejora al algoritmo basado en triángulos y se diferencia de él en los siguientes aspectos: Utiliza el signo de las coordenadas baricéntricas para la inclusión punto en triángulo, las cuales son independientes de la orientación del triángulo. Utiliza el signo de las coordenadas baricéntricas para comprobar los casos especiales que se dan con un punto en una arista del polı́gono o en el borde de un triángulo. Agrupa algunas situaciones relacionadas en las cuales un punto está dentro o en el borde de un triángulo: por un lado, un punto estrictamente dentro de un triángulo, por otro lado, un punto que se encuentre en una arista o vértice de un polı́gono, y por último, un punto que se encuentre en una arista con un extremo en el origen del recubrimiento. Utiliza un conjunto de situaciones relacionadas ordenadas de acuerdo a su probabilidad. Primero, si el punto está fuera del triángulo, después si el punto está estrictamente dentro del triángulo, a continuación si un punto está sobre el borde del polı́gono, y por último si el punto está en una arista original. Selecciona el origen apropiado del recubrimiento de un triángulo, de manera que se simplifique el determinante obtenido en el cálculo de las coordenadas baricéntricas. Trata de manera correcta el caso de un punto situado en el origen del recubrimiento. Tiene en cuenta los casos especiales de triángulos con área signada cero. Optimiza el calculo del signo de las coordenadas baricéntricas al obtenerlas mediante el signo de los determinantes. 2.1.2. Reducción de cálculos y optimizaciones Una de las mejoras propuestas en [6] consiste en agrupar en conjuntos diferentes situaciones que tienen un resultado común y ordenarlos. Se ha detectado que, tan sólo en polı́gonos no convexos con un gran número de concavidades y para posiciones especı́ficas del punto a comprobar, el número de triángulos en los que el punto es incluido es mayor que el número de triángulos en los que no lo está. Dado que este tipo de polı́gono no es muy común, se propone descartar primero los triángulos en los que el punto no está incluido. Observando el signo de los determinantes involucrados en el cálculo de las coordenadas baricéntricas de un punto con respecto a un triángulo (Figura 1), se pueden obtener las siguientes conclusiones: El signo del numerador se obtiene directamente utilizando la expresión PViV j + OPV j + |OVi P| = OViV j . Cuando hay simultáneamente dos signos diferentes en el numerador de dos de las coordenadas baricéntricas el signo del denominador no se deduce directa- 114 J.J. Jiménez, A. Martı́nez, F. Paulano y R. Pulido mente, pero este signo no es necesario para determinar si el punto está fuera del triángulo. Tan sólo se necesita el signo de los numeradores para obtener la posición del punto con respecto al triángulo cuando el punto esta dentro del triángulo o sobre sus bordes. La combinación de signos de los numeradores nos da un resultado para el test punto en poliedro con dos casos degenerados, uno cuando el punto está sobre el origen O del recubrimiento, y otro cuando O, Vi y V j están alineados. Fig. 1 Signos del numerador de los determinantes involucrados en el cálculo de las coordenadas baricéntricas para el caso de un triángulo con signo positivo Como origen del recubrimiento, se podrı́a utilizar el punto O = (0, 0) de manera que se simplificarı́an los determinantes involucrados en el cálculo de las coordenadas baricéntricas. No obstante, en lugar de un punto fijo, se propone utilizar como origen del recubrimiento un punto que dependa del punto a clasificar. Dado un punto a clasificar P = (x p , y p ), se propone utilizar el punto P = (x p , y p − 1) como origen del recubrimiento. Utilizando este punto, los determinantes involucrados en el cálculo de las coordenadas baricéntricas del punto P con respecto al triángulo T = OViV j del recubrimiento son los siguientes (Figura 2): Algoritmos Geométricos Básicos 115 Fig. 2 Posición del punto P con respecto al triángulo OViV j 1 0 xi x j 1 OViV j = −1 yi y j = (xi y j − x j yi + xi − x j ) 2 2 1 1 1 0 xi x j PViV j = 1 0 yi y j = 1 (xi y j − x j yi ) 2 2 1 1 1 0 0 x j OPV j = 1 −1 0 y j = − 1 x j 2 2 1 1 1 0 xi 0 |OVi P| = 12 −1 yi 0 = 21 xi 1 1 1 (2) Al realizar el cálculo del signo de estas expresiones, el factor 21 puede obviarse. Por medio de esta transformación, los cálculos necesarios para el test punto en triángulo se han simplificado y pueden reutilizarse algunos cálculos. Con el fin de obtener un nuevo algoritmo, en lugar de verificar la inclusión del punto mediante el uso del signo de las coordenadas baricéntricas, en [6] se propone utilizar también coordenadas euclı́deas. Este enfoque ofrece un nuevo mecanismo para realizar el test punto en polı́gono. Analizando cada una de las situaciones de P con respecto a el triángulo del recubrimiento OViV j , se puede obtener un algoritmo que descarta triángulos que no satisfacen están condiciones secuencialmente: Situación 1. Cuando β < 0 o γ < 0 el punto no se encuentra dentro del triángulo. Esto equivale a comprobar si xi x j > 0. 116 J.J. Jiménez, A. Martı́nez, F. Paulano y R. Pulido Situación 2. No hay inclusión de P en el triángulo para triángulos con coordenadas y negativas, es decir, si yi < 0 y y j < 0. El siguiente paso es calcular el signo de α para los triángulos no descartados en las situaciones ello, serı́a necesario calcular los signos de los determi 1 y 2. Para nantes OViV j y PViV j , pero puede evitarse si se consideran estas consideraciones adicionales: Si xi > x j , se examina la posición de la arista ViV j con respecto a los puntos P y O. Se puede ver que P está dentro de OViV j si y sólo si PViV j > 0 y xi > x j . Si xi < x j se obtienen conclusiones similares que en la situación anterior intercambiando los puntos Vi y V j . P está sobre ViV j si y sólo si (yi <= 0 o y j <= 0) y xi = x j . Finalmente, se analizan algunos casos especiales contemplados en el algoritmo. En estos casos P está sobre una arista del triángulo u O está sobre el eje ViV j : P está sobre ViV j cuando α = 0, es decir, cuando PViV j = 0 y el triángulo no fue descartado en las situaciones anteriores. P está sobre OV j cuando x j = 0 y el triángulo no fue descartado en situaciones previas. P está sobre OVi cuando xi = 0 y el triángulo no fue descartado en situaciones previas. Cuando O se encuentra en ViV j , OViV j es un triángulo degenerado pero no debe ser tratado especialmente dado que las condiciones anteriores aplicadas a este caso devuelven un resultado correcto. 2.1.3. Robustez del método Desde un punto de vista numérico, que puede verse desde la precisión de los algoritmos y desde el tratamiento de los casos degenerados, el algoritmo presentado en [6] es más robusto para el test punto en poliedro que los algoritmos tradicionales. Los errores de precisión pueden suceder en el calculo de los determinantes, en las comparaciones y en las acumulaciones: La reducción del número de términos en el cálculo de los determinantes hace aumentar la precisión. Mediante el uso del recubrimiento dinámico propuesto se reduce el número de determinantes a calcular, teniendo que realizar sólo operaciones para calcular el determinante PViV j . Los errores cometidos en el determinante PViV j o durante la representación numérica podrı́an causar errores al comparar, pudiendo causar errores al clasificar el punto en el borde del recubrimiento, pero no provocan una incorrecta clasificación en el polı́gono. Los casos degenerados se obtienen cuando el determinante del triángulo es cero o casi cero. Ya que el determinante del triángulo OViV j no se utiliza, tan sólo se Algoritmos Geométricos Básicos 117 tratan los triángulos delgados con puntos situados cerca del eje y. En esta situación, si se da un error en el cálculo de la inclusión del punto en las aristas OVi u OV j , se obtiene un resultado correcto tal y como se ha visto previamente. La inclusión del punto en una arista prácticamente vertical ViV j se resuelve utilizando el signo de las coordenadas y. Si los tres puntos son prácticamente el mismo, el algoritmo descarta el triángulo porque el punto está situado a una unidad del origen, no siendo posible la inclusión del triángulo. 2.2. Test de intersección segmento triángulo Debido a que a menudo la representación de los objetos gráficos utiliza mallas de triángulos o descomposiciones de los objetos por medio de sı́mplices, existen muchos problemas en informática gráfica que se resuelven mediante el cálculo de la intersección entre un segmento y un triángulo. Este es el caso del trazado y casting de rayos, del test de inclusión, de las operaciones booleanas entre sólidos y de la detección de colisiones. En [9] se presenta un nuevo algoritmo para la intersección entre un segmento y un triángulo en 3D. La idea del método es relativamente simple y consiste en determinar las coordenadas baricéntricas de un extremo del segmento Q1 Q2 , por ejemplo Q2 , con respecto al tetraedro Q1V1V2V3 y comprobar su signo. El uso de coordenadas baricéntricas tienes muchas ventajas, como por ejemplo la posibilidad de obtener la posición exacta de un punto con respecto a cada una de las caras de un tetraedro. Otra ventaja consiste en la posibilidad de llevar a cabo algunas simplificaciones como la compartición de cálculos basada en la interpretación geométrica de esas coordenadas en el contexto de la malla. También permiten de manera sencilla la detección de casos especiales como triángulos degenerados o segmentos coplanares. Por último, estas coordenadas pueden ser utilizadas para cálculos volumétricos y pueden usarse directamente para la interpolación de propiedades de los vértices. Mediante el uso de la definición de volumen signado, las coordenadas baricéntricas de Q2 con respecto al tetraedro Q1V1V2V3 se pueden calcular como: α= |Q2V1V2V3 | |Q1V1V2V3 | β= |Q2 Q1V3V2 | |Q1V1V2V3 | γ= |Q2 Q1V1V3 | |Q1V1V2V3 | δ= |Q2 Q1V2V1 | |Q1V1V2V3 | (3) La posición de un punto con respecto a su tetraedro puede establecerse utilizando las coordenadas baricéntricas. Un punto Q2 está dentro del tetraedro Q1V1V2V3 si α , β , γ , δ ∈ [0, 1]. Además, estas coordenadas pueden utilizarse para determinar el 118 J.J. Jiménez, A. Martı́nez, F. Paulano y R. Pulido lado donde se encuentra el punto con respecto a los planos definidos por los triángulos del tetraedro. Siendo T = ABCD un tetraedro y P un punto con coordenadas baricéntricas (α , β , γ , δ ) con respecto a T (Figura 3): Un punto con α = 0 indica que el punto está en el plano definido por BCD. Un punto con α > 0 indica que el punto está en el mismo lado que el punto A con respecto al plano definido por BCD. Un punto con α < 0 indica que el punto está en el lado opuesto del punto A con respecto al plano definido por BCD. La misma interpretación puede aplicarse a β , γ , δ con respecto a los planos definidos por ADC, ADB y ACB respectivamente. Fig. 3 Interpretación geométrica de α respecto a un tetraedro Volviendo al problema de la intersección segmento/triángulo, la intersección del segmento Q1 Q2 y el triangulo V1V2V3 se puede determinar mediante el siguiente teorema: Teorema 1 Siendo V1V2V3 un triángulo y Q1 Q2 un segmento de manera que Q1 no es coplanar con el plano definido por V1V2V3 . Q1 Q2 interseca con V1V2V3 si y sólo si sign (α ) ≤ 0 y sign (β ) ≥ 0 y sign (γ ) ≥ 0 y sign (δ ) ≥ 0 (4) Siendo (α , β , γ , δ ) las coordenadas baricéntricas de Q2 con respecto al tetraedro Q1V1V2V3 . 2.2.1. Caracterı́sticas del algoritmo El algoritmo propuesto en [9] tiene algunas propiedades que lo hacen robusto y eficiente en ciertas situaciones. Como hemos visto antes, la precisión de un algoritmo geométrico puede medirse a partir de la precisión y del tratamiento de los Algoritmos Geométricos Básicos 119 casos degenerados. Los errores de precisión pueden ocurrir tanto en las operaciones aritméticas como en las comparaciones: Los errores cometidos se minimizan con respecto a otros algoritmos ya que se llevan a cabo un menor número de operaciones y un mayor número de rechazos con menos comparaciones. Además, se evita la operación de división que es menos precisa, utilizándose tan sólo para obtener el punto de intersección. Con respecto al error cometido en las comparaciones, se ha utilizado un error predeterminado e. Dicho error podrı́a ser dependiente del volumen del tetraedro utilizado para el cálculo de las coordenadas baricéntricas, de manera que la comparación serı́a menos susceptible a errores. En ausencia de triángulos degenerados, los casos especiales o degenerados se obtienen cuando el segmento se alinea con el plano dónde está localizado el triángulo. En ese caso, el algoritmo descarta el segmento, tal y como hacen el resto de algoritmos. Es también posible descartar algunos triángulos que no están orientados en la dirección del rayo. Esta comprobación puede realizarse durante el cálculo del volumen del tetraedro Q1V1V2V3 . Si el volumen es positivo, el triángulo V1V2V3 no está orientado en la dirección del rayo, y por tanto el rayo es descartado. Si el volumen es cero Q1 y Q2 deben intercambiarse, ya que no es posible tener un segmento con Q1 en el triángulo y Q2 en el otro lado del plano. Cuando esto ocurre el segmento debe ser descartado. Si es necesario calcular el punto de intersección entre el triángulo y el segmento, este puede calcularse con un coste computacional mı́nimo: una diferencia y una división. Estos cálculos se llevan a cabo al final del algoritmo y se basan en cálculos previos. Esto supone una ventaja en el caso de que su cálculo no sea necesario. Algunos datos pueden calcularse a priori con el fin de mejorar la eficiencia del algoritmo. Por ejemplo, si la normal del triángulo se calcula al inicio del algoritmo y se almacena en la estructura del triángulo, actualizándola cuando sea necesario, se pueden evitar algunos cálculos. Una aplicación de las coordenadas baricéntricas de un punto con respecto a un triángulo consiste en su utilización para interpolar las propiedades del vértice. El algoritmo propuesto es capaz de calcular esas coordenadas con los cálculos llevados a cabo en durante el test de intersección, pudiendo utilizar esas coordenadas para realizar cálculos de renderizado. El algoritmo propuesto puede calcular las coordenadas baricéntricas del punto de intersección una vez que se ha calculado el parámetro t: βP = t param · β γP = t param · γ (5) δP = 1 − β − γ son las coordenadas baricéntricas del punto P con respecto al triángulo V1V2V3 . Al utilizar el algoritmo propuesto en mallas de triángulos, muchos cálculos pueden ser reutilizados. Para ello es necesario conocer la vecindad de los triángulos 120 J.J. Jiménez, A. Martı́nez, F. Paulano y R. Pulido o almacenar cierta información acerca de las aristas compartidas. Para las aristas compartidas el valor de una coordenada baricéntrica de Q2 se comparte entre dos tetraedros, aquellos formados por los triángulos que comparten esta arista y Q1 . Una de las ventajas del algoritmo propuesto es que permite determinar si una intersección ocurre en un vértice, en una arista, o dentro del triángulo sin coste computacional adicional. Además, para casos de no intersección, el algoritmo propuesto lleva a cabo un gran número de tests con el fin de terminar rápidamente y no llevar a cabo excesivos cálculos. Los cálculos acumulados para cada rechazo son inferiores que los cálculos llevados a cabo por otros algoritmos existentes. 2.3. Test de inclusión punto en sólido Los test de inclusión o los test punto en sólido son una operación básica en multitud de procesos dentro de la simulación 3D: clasificación de caras o lados, detección de colisiones, u operaciones booleanas, entre otros procedimientos. En [10] se presenta un nuevo test de inclusión de punto en sólido basado en algoritmos de intersección 3D eficientes y explotando la reutilización de cálculos vinculada a estructuras de descomposición espacial. El algoritmo de inclusión propuesto tiene las siguientes etapas: Generación de un segmento utilizando como extremos el punto de estudio y el centroide del sólido. Búsqueda del triángulo intersecado por el segmento generado más cercano al punto de estudio. Aplicación de un criterio de inclusión para determinar si el punto está dentro o fuera del sólido. Para el estudio de la intersección segmento-triángulo se estudiaron tres alternativas: un enfoque clásico utilizando el algoritmo de inclusión de Möler [12] y un estudio de las normales, el algoritmo de Jiménez antes descrito [9], y una versión optimizada de este último. La primera alternativa estudiada se basa en aplicar el test de intersección de Möller [12] con dos objetivos: determinar qué triángulos intersecan con el rayo y conocer también cual es el más cercano. Este enfoque es bastante eficiente pero su principal problema es el tratamiento de casos especiales, como pueden ser puntos coplanares o colineales, o segmentos tangentes al objeto. Es estos casos, el procedimiento a seguir es trazar rayos adicionales con otros puntos, lo que conlleva modificar el centroide y reclasificarlo, penalizando de esta forma gravemente al algoritmo. Otra alternativa es la utilización del enfoque de Jiménez basado en coordenadas baricéntricas descrito anteriormente [9]. En este caso el algoritmo de intersección para determinar el triángulo más cercano nos devuelve de forma directa la inclusión del punto y no es necesario hacer ningún tipo de comprobación adicional o aplicar ningún criterio, lo que supone una mejora sobre enfoques tradicionales. Algoritmos Geométricos Básicos 121 En la última alternativa, siguiendo el trabajo de Ogayar [13], se estudia la optimización de los algoritmos utilizando los datos pre-calculados en la construcción de las estructuras de descomposición espacial. En concreto, se estudia la optimización del algoritmo de Jiménez [9] aprovechando los cálculos realizados en un tetra-tree [4] previamente construido. De forma general, se pueden acelerar los cálculos precalculando los volúmenes de los tetraedros formados por el centroide del sólido y los triángulos de la malla y almacenando esos datos en la descomposición espacial. El procedimiento completo de estudio de la inclusión de un punto P en un sólido recubierto por un tetra-tree tiene dos fases: 1. Determinar la inclusión punto tetra-cono. Este proceso siempre devuelve un nodo hoja ya que el tetra-tree descompone todo el espacio sin solapamientos. Mediante la utilización de coordenadas baricéntricas y una descomposición homogénea del espacio, la complejidad de este proceso puede reducirse hasta tiempo constante. 2. Una vez determinado el tetra-cono, aplicar el test de inclusión punto-sólido tan sólo en el sub-conjunto de triángulos clasificados en el tetracono. La propia estructura almacena el signo del volumen del tetra-cono ası́ como el volumen de los tetraedros formados por el centroide y los triángulos clasificados. Con este enfoque se reducen drásticamente las operaciones a realizar en el test de Jiménez. A cambio, se necesita más espacio para almacenar la información precalculada. 3. Descomposiciones espaciales 3.1. Tri-tree. Aplicación al algoritmo punto en polı́gono El algoritmo de punto en polı́gono es fundamental en geometrı́a computacional y se aplica de manera intensiva en sistemas de información geográfica. Cuando este algoritmo se repite muchas veces con el mismo polı́gono, necesaria una estructura de datos que permita reducir el tiempo empleado en obtener una inclusión. En [5], se presenta una estructura de datos, denominada tri-tree, describiendo además su utilización en el test punto en polı́gono. Esta estructura de datos, basada en triángulos, subdivide recursivamente el espacio ocupado por el polı́gono y clasifica las aristas del polı́gono en una etapa de pre-procesamiento. La complejidad del test de inclusión mediante el uso de esta estructura es O (log n), siendo n el número de vértices del polı́gono. Por otro lado, el tiempo de construcción de la estructura es de O (n log n). 3.1.1. Tri-tree En la construcción del tri-tree, se descompone el espacio en regiones de igual tamaño con origen en el centroide del polı́gono. En su primer nivel, el tri-tree divide el 122 J.J. Jiménez, A. Martı́nez, F. Paulano y R. Pulido espacio en cuatro regiones triangulares de igual tamaño denominadas tri-conos. En los niveles sucesivos, cada región se subdivide recursivamente en dos sub-regiones, formando un árbol de regiones. Esta división puede verse en la Figura 4. Como origen del tri-cono se propone utilizar el centroide del polı́gono, no siendo necesario que el centroide se encuentre dentro del polı́gono. Fig. 4 Izqda: Un tri-cono definido por un triángulo. Centro: Subdivisión de un tri-cono. Dcha: Aristas clasificadas en un tri-cono. Para cada región, se aplica un test para clasificar las aristas del polı́gono. Una arista queda clasificada en un tri-cono si al menos una parte de la arista está dentro del tri-cono (Figura 4). Esta condición se comprueba para cada par arista/tri-cono, de manera que una arista puede estar clasificada en más de un tri-cono incluso del mismo nivel. No obstante, en un nivel especı́fico tan sólo se comprueban las aristas clasificadas en el tri-cono padre. Ese proceso se repite hasta alcanzar un criterio. Alguno de los criterios que pueden ser utilizados para subdividir un tri-cono son: El número de aristas clasificadas en un tri-cono es menor que un umbral. El nivel del tri-cono en el árbol es mayor que uno pre-establecido. El test de inclusión localiza el tri-cono en el cual se localiza el punto y lleva a cabo un test punto en polı́gono con las aristas clasificadas en el tri-cono. Con el fin de mejorar la eficiencia de la estructura de datos, se construyen dos triángulos envolventes para cada tri-cono: uno exterior que contiene todas sus aristas, y otro interior que no se solapa con ninguna de ellas (Figura 5). Estos triángulos envolventes permiten que el test de inclusión pueda rechazar de forma rápida a los puntos que se encuentran fuera del triángulo envolvente exterior y que pueda aceptar de igual manera a los puntos que están dentro del triángulo envolvente interior. En [5] se definen formalmente los conceptos asociados a esta estructura de datos. 3.1.2. Aplicación al algoritmo punto en polı́gono En [5] se estudia la adaptación de los métodos de ray-crossings y basado en triángulos al uso del tri-tree para realizar el test de inclusión. Para ambos métodos Algoritmos Geométricos Básicos 123 Fig. 5 Triángulos envolventes en un tri-cono. Izqda: Triángulo envolvente ideal. Der: Triángulo envolvente usado (más sencillo de calcular aunque menos eficiente computacionalmente) se ha demostrado que utilizando tan sólo las aristas clasificadas en un tri-cono se puede determinar la inclusión de un punto en un polı́gono. Para ello hay que descender en el árbol hasta obtener el nodo hoja en el que está incluido el punto. Después, si el punto está dentro del triángulo envolvente exterior y fuera del triángulo envolvente interior, se realiza un test punto en polı́gono utilizando tan sólo las aristas clasificadas en el tri-cono hoja en el que se encuentra en punto. El método de ray-crossings [3] lanza un rayo infinito desde el punto a clasificar y calcula el número de intersecciones con las aristas del polı́gono. Si el número de intersecciones es impar, el algoritmo devuelve que el punto esta dentro del polı́gono, y si no, devuelve que el punto está fuera. Para poder aplicar este método, es necesario decidir una dirección apropiada para el rayo. Este rayo debe cruzar las aristas del polı́gono de la misma manera que en el algoritmo original. Para asegurar esto, el rayo debe estar completamente incluido en el tri-cono. Una solución simple consiste en generar un rayo desde el punto a clasificar hasta el infinito de manera que la lı́nea que forman pase por el origen del tri-cono. Esto asegura que el rayo queda dentro del tri-cono y cruza los mismos ejes que en el método general. Otra alternativa consiste en aplicar el método de ray-crossings utilizando un rayo dirigido a través de un punto incluido en el tri-cono cuyo estado de inclusión sea conocido. Este rayo se lanza en el sentido contrario, de manera que pasa por la posición del punto y por el origen del tri-cono. Ninguno de estos dos enfoques es mejor que el otro, sino que el resultado depende de la geometrı́a del polı́gono y de las posición del origen del tri-tree. Básicamente, el rendimiento depende del número de intersecciones calculadas. El método basado en triángulos [2] se basa en el calculo de la inclusión del punto P en un conjunto de triángulos formados por un punto común y arbitrario O y cada una de las aristas del polı́gono, y en la obtención del número de triángulos en los que el punto está incluido. El algoritmo contabiliza como +1 multiplicado por el signo del triángulo para cada uno de esos triángulos, y considera algunos casos especiales como la inclusión en una arista compartida por dos triángulos del recubrimiento, computándolo como + 12 por el signo de cada uno de esos triángulos. Por último, 124 J.J. Jiménez, A. Martı́nez, F. Paulano y R. Pulido el estado de inclusión se obtiene mediante la suma de esos valores, obteniendo la inclusión en el polı́gono cuando ese valor es mayor que cero. Al igual que en el caso del método de ray-crossings, el método basado en triángulos puede aplicarse a un tri-cono. Para ello, se deben contar el numero de triángulos del recubrimiento en los cuales se incluye el punto. No obstante, tan sólo deben tenerse en cuenta los triángulos del recubrimiento que intersecan con el tri-cono. 3.2. Descomposiciones espaciales jerárquicas utilizando Geometry Shaders El principal inconveniente de implementar algoritmos geométricos en GPU es que hay que adaptar las estructuras de datos y la programación a un modelo de programación paralelizado y enfocado a la visualización, con las restricciones que esto conlleva. Por otra parte, multitud de algoritmos geométricos están basados en una descomposición espacial eficiente de los modelos. Estas descomposiciones permiten trabajar sólo con una parte de los datos, reduciendo ası́ su complejidad. En [8] se proponen una serie de directrices que permiten la construcción y posterior consulta de dichas estructuras de datos utilizando los shaders programables, aplicados a mallas de triángulos, de modo que aumente el rendimiento de las aplicaciones. Esto posibilita la utilización de la GPU para problemas que hagan uso descomposiciones espaciales jerárquicas. En el caso tratado en dicho trabajo, es conveniente que por un lado que el procesamiento en GPU sea eficiente, y por otro lado que el almacenamiento de la información facilite posteriores consultas. Para ello, debido a las limitaciones que impone la arquitectura y el modelo de programación de shaders en GPU, se propone una implementación radicalmente distinta al método tradicional. En concreto, se propone una solución que resuelve el problema de construcción de jerarquı́as y que optimiza el acceso a la información, permitiendo el uso de mallas de gran tamaño. 3.2.1. Codificación de la información La incorporación del procesador de geometrı́a al pipeline gráfico permite obtener información de los triángulos de la malla en cada unidad de ejecución del mismo. Al enviar la geometrı́a del objeto, se propone activar la unidad de ejecución en el geometry shader por cada triángulo que entre en el pipeline gráfico. Cada unidad de ejecución clasifica el triángulo en un determinado nivel de forma independiente a los demás. En [8] se propone no almacenar la información de vértices y triángulos, sino asociar un ı́ndice a cada triángulo de la malla. Suponiendo una malla formada por n triángulos, se considera utilizar una textura de n elementos para cada nivel de la jerarquı́a. Cada posición de la textura de un nivel determinado contiene el código de los nodos en los que se encuentra almacenado el triángulo correspondiente en ese nivel. Algoritmos Geométricos Básicos 125 Como un triángulo puede estar clasificado en varios nodos de un mismo nivel, el número máximo de nodos en los que se clasifica un triángulo no puede conocerse a priori, siendo posible que un triángulo este clasificado en un gran número de nodos en los niveles más profundos del árbol. Para resolver este problema, se propone establecer un número máximo de nodos del mismo nivel en los que se encuentra clasificado un triángulo. De este modo, si se supera este umbral, se detiene el descenso por el árbol de ese triángulo. En este caso, es posible enviar a la GPU la información sobre los volúmenes asociados a los nodos codificados en texturas, evitando tener que calcularlos a partir del volumen inicial. En este trabajo se propone codificar dicha información en una textura 2D a la que denomina textura de volúmenes. 3.2.2. Construcción en GPU Dada una malla de n triángulos y un número de niveles l para la jerarquı́a, se propone enviar la geometrı́a de la malla l veces para su visualización, una por nivel, para que las unidades del geometry shader se activen por cada triángulo de la malla. Además de la información de la geometrı́a, en cada triángulo debe codificarse la información del número de triángulo, para que el geometry shader pueda escribir en su posición de la textura de nivel correspondiente. De esta manera, el geometry shader emite un vértice cuya posición es el código del triángulo de entrada y cuyo color la codificación de los número de nodos de ese nivel en los que se encuentra el triángulo. Este proceso de construcción puede verse en la Figura 6. Fig. 6 Construcción de una descomposición espacial usando geometry shaders y texturas de nodos) Por tanto, para cada pasada de construcción tendremos los resultados del nivel anterior y la información de los volúmenes de la estructura jerárquica del nivel actual. Para poder pasar de un nivel al siguiente es necesario cambiar el destino de la escritura mediante Framebuffer Objects. 126 3.2.3. J.J. Jiménez, A. Martı́nez, F. Paulano y R. Pulido Utilización de la estructura Una vez construida la jerarquı́a asociada a una malla de triángulos, vamos a ver como propone tratar [8] algunas operaciones de consulta habituales: Dado un nodo, obtener la geometrı́a clasificada en dicho nodo. Habrı́a que rasterizar de nuevo la malla. Para cada ejecución del geometry shader, ante un triángulo de entrada, habrı́a que consultar en todas las texturas de nodos de todos los niveles si se encuentra el código del nodo. Este código no serı́a constante para todas las unidades de ejecución. Dada una posición en el espacio, obtener el nodo hoja que la contiene. Se puede utilizar una función que dada la posición y el nivel, obtenga el código del nodo asociado. Obtención de los nodos hijos y padre. Dado un nodo, la obtención de los nodos hijos o padre puede realizarse mediante una función que obtenga el código del nodo. Actualización de la jerarquı́a tras una deformación de la malla. Tras localizar los triángulos modificados por la deformación, habrı́a que volver a reclasificar dichos triángulos, no siendo necesario reconstruir el resto. 3.2.4. Implementación de tetra-trees Un tetra-tree [7] es una descomposición del espacio jerárquica que permite dividir todo el espacio sin solapamientos. En su primer nivel, el tetra-tree divide todo el espacio en ocho tetra-conos de igual tamaño. Un tetra-cono se puede considerar como un tetraedro cuya base se encuentra en el infinito. En los siguientes niveles de la jerarquı́a, cada tetra-cono se divide homogéneamente en cuatro nuevos tetra-conos. El tetra-tree se subdivide hasta que cumple alguna de las condiciones siguientes: Se alcanza el máximo nivel de subdivisiones preestablecido. El tetra-cono a subdividir tiene menos triángulos que un umbral. Todos los tetra-conos que forman la descomposición espacial comparten un origen común. Normalmente, se hace coincidir este origen con el centroide del objeto. Cuando se construye un tetra-tree, se clasifican los triángulos que forman el objeto en cada uno de sus tetra-conos iniciales. Los triángulos de cada tetra-cono continúan clasificándose en sus tetra-conos hijos hasta que se alcanza alguna de las condiciones de parada antes enunciadas. En la construcción de un tetra-tree, se propone utilizar una textura de volumen que contendrá los puntos que definen cada tetra-cono para todos los niveles contemplados. El centroide del objeto, común a todos los tetra-conos, debe ser una variable de entrada al procesador. La textura de nodos debe construirse según la definición antes comentada. En cada posición de la textura de nodos de nivel i la componente Z almacena la profundidad de la jerarquı́a y las coordenadas X e Y el ı́ndice del triangulo. Se establece que un triángulo no puede ser clasificado en más de cuatro nodos por nivel, sirviendo esta condición como criterio de parada. Algoritmos Geométricos Básicos 3.3. 127 Descomposiciones jerárquicas exactas La utilización de descomposiciones espaciales jerárquicas en escenas 3D con el fin de reducir la complejidad de los objetos es bastante común. No obstante, el principal problema de estos enfoques está relacionado con la actualización de las estructuras cuando se modifica la geometrı́a de los objetos, ya que cualquier deformación provoca la recomposición completa de la estructura espacial jerárquica. En [11] se aplica un procedimiento de remallado con el fin de ajustar la malla original a la descomposición espacial. Este procedimiento de remallado no afecta a la malla completa, sino tan sólo a los triángulos que no están completamente contenidos en un solo nodo de la estructura. Para ilustrar el método se hace uso de un tetra-tree [7] como descomposición espacial jerárquica. Dado que los tetra-conos pueden definirse como tetraedros con su base en el infinito, el problema de la intersección de los tetra-conos con los triángulos compartidos puede reducirse a una triple intersección triángulo-triángulo en 3D (Figura 7). La intersección triángulo-triángulo puede ser fácilmente reducida a intersecciones de tipo segmento-triángulo. Tal y como se ha visto en secciones anteriores, el algoritmo clásico utilizado para la intersección segmento-triángulo es el propuesto por Möller [12]. El principal problema de este enfoque clásico es que, para tratar con casos lı́mite, se ve forzado a lanzar rayos adicionales, perjudicando seriamente la eficiencia del algoritmo. Con el fin de superar este problema, se propone utilizar el algoritmo de intersección segmento-triángulo propuesto por Jiménez [9], el cual e comporta de forma robusta en los casos lı́mite gracias a su enfoque basado en coordenadas baricéntricas. En este sentido, el uso del tetra-tree es una ventaja dado que permite reutilizar los cálculos relacionados con las coordenadas baricéntricas de los nodos. Fig. 7 La intersección triángulo-tetracono puede expresarse fácilmente como una intersección usando el plano que contiene el triángulo 128 J.J. Jiménez, A. Martı́nez, F. Paulano y R. Pulido Tras la finalización de los cálculos de intersección, se propone estudiar los casos de intersección triángulo-triángulo con el objetivo de aplicar un patrón de división. Se proponen 11 patrones de división (Figura 8), los cuales han sido elegidos de manera que resulten lo más sencillos y eficientes posibles, intentando reducir el número de triángulos generados. Estos patrones pueden aplicarse a otras descomposiciones jerárquicas que estén compuestas o reducidas mediante tetraedros. Los casos especiales han sido divididos en casos especiales rechazados, los cuales son rechazados directamente del proceso de remallado, y casos especiales degenerados, a los cuales hay que aplicar un test de eliminación además del remallado. 4. Conclusiones En este trabajo se han desarrollado diversos algoritmos geométricos básicos que posibilitan su aplicación en entornos urbanos con un alto grado de eficiencia y robustez. Se han desarrollado tests de inclusión de puntos en polı́gonos, de puntos en sólidos y de intersección de segmentos y triángulos. Del mismo modo, se han desarrollado nuevas descomposiciones espaciales para disminuir la complejidad del problema, como tri-trees y tetra-trees, ası́ como descomposiciones espaciales jerárquicas exactas basadas en las anteriores. Finalmente estas descomposiciones se han implementado en GPU para obtener algoritmos que funcionan en tiempo real. Dicha implementación permite extenderse a otros tipos de descomposiciones espaciales jerárquicas. Agradecimientos Este trabajo ha sido parcialmente subvencionado por el Ministerio de Economı́a y Competitividad Español y la Unión Europea a través de fondos FEDER por medio del proyecto TIN2011-25259, y por la Universidad de Jaén a través del proyecto de investigación UJA2010/13/08, patrocinado por Caja Rural de Jaén. Referencias 1. Erickson, C.: Real-Time Collision Detection. Morgan Kaufmann Publishers, San Francisco (2005) 2. Feito, F.R., Torres, J.C., Ureña, A.: Orientation, simplicity and inclusion test for planar polygons. Computers & Graphics 19(4), 595–600 (1995). DOI 10.1016/S0097-8493(96)00067-2 3. Heckbert, P.: Graphics gems IV. The Graphics gems series. AP Professional (1994). URL http://books.google.es/books?id=CCqzMm -WucC 4. Jiménez, J.J.: Detección de colisiones mediante recubrimientos simpliciales. Ph.D. thesis, Universidad de Granada (2006) 5. Jiménez, J.J., Feito, F.R., Segura, R.J.: A new hierarchical trianglebased point-in-polygon data structure. Computers & Geosciences 35(9), 1843 – 1853 (2009). DOI 10.1016/j.cageo.2008.09.013. URL http://www.sciencedirect.com/science/article/pii/S0098300409001137 6. Jiménez, J.J., Feito, F.R., Segura, R.J.: Robust and optimized algorithms for the point-inpolygon inclusion test without pre-processing. Computer Graphics Forum 28(8), 2264– Algoritmos Geométricos Básicos Fig. 8 Casos de intersección y patrones de descomposición en triángulos) 129 130 7. 8. 9. 10. 11. 12. 13. J.J. Jiménez, A. Martı́nez, F. Paulano y R. Pulido 2274 (2009). DOI 10.1111/j.1467-8659.2009.01481.x. URL http://dx.doi.org/10.1111/j.14678659.2009.01481.x Jiménez, J.J., Feito, F.R., Segura, R.J., Ogáyar, C.J.: Particle oriented collision detection using simplicial coverings and tetra-trees. Computer Graphics Forum 25(1), 53–68 (2006). DOI 10.1111/j.1467-8659.2006.00917.x. URL http://dx.doi.org/10.1111/j.14678659.2006.00917.x Jiménez, J.J., Martı́nez, A., Feito, F.R.: Diseño de descomposiciones espaciales jerárquicas para mallas de triángulos utilizando geometry shaders. design of hierarchical space decompositions for triangle meshes using geometry shaders. In: CEIG09. Spanish conference on Computer Graphics, pp. 95–104 (2009). DOI 10.2312/LocalChapterEvents/CEIG/CEIG09/095-104. URL http://diglib.eg.org/EG/DL/LocalChapterEvents/CEIG/CEIG09/095-104.pdf Jiménez, J.J., Segura, R.J., Feito, F.R.: A robust segment/triangle intersection algorithm for interference tests. efficiency study. Comput. Geom. Theory Appl. 43, 474–492 (2010). DOI http://dx.doi.org/10.1016/j.comgeo.2009.10.001. URL http://dx.doi.org/10.1016/j.comgeo.2009.10.001 Martı́nez, A., Jiménez, J.J., Feito, F.R.: Inclusión en sólidos optimizada. In: CEIG 2010. Spanish conference on Computer Graphics, pp. 297–300 (2010) Martı́nez, A., Jiménez, J.J., Paulano, F., Pulido, R., Feito, F.R.: An exact hierarchical geometric model. combining remeshing and spatial decomposition. In: 19th International Conference on Computer Graphics, Visualization and Computer Vision, pp. 29–32 (2011) Möller, T., Trumbore, B.: Fast, minimum storage ray-triangle intersection. J. Graph. Tools 2(1), 21–28 (1997). URL http://dl.acm.org/citation.cfm?id=272313.272315 Ogayar, C.J., Segura, R.J., Feito, F.R.: Point in solid strategies. Computers & Graphics 29(4), 616 – 624 (2005). DOI 10.1016/j.cag.2005.05.012. URL http://www.sciencedirect.com/science/article/pii/S0097849305000944 Bloque IV Visualización realista Texturización en entornos urbanos Marı́a Dolores Robles Ortega, Lidia Ortega Alvarado y Francisco R. Feito Higueruela Resumen En este capı́tulo se describe el proceso de texturización de un entorno urbano situado sobre una superficie inclinada. En concreto, se detalla el procedimiento propuesto para texturizar de forma automática manzanas de edificios. Para facilitar el proceso, las manzanas se consideran divididas en dos partes: superior e inferior, implementándose un algoritmo genético para la selección de texturas en cada una de ellas. Estos métodos permiten obtener un conjunto adecuado de imágenes a partir de una base de datos de texturas reales, teniendo en cuenta aspectos relativos a la posición real de los edificios y su posible localización en calles con una elevada pendiente. En vista de los resultados obtenidos, se puede concluir que los métodos propuestos obtienen escenas correctas similares a las reales que, además, ocupan un espacio reducido. 1. Introducción La texturización de entornos urbanos virtuales sobre localizaciones reales posee unas caracterı́sticas muy diferentes a la creación de ciudades totalmente ficticias. Ası́, la superficie y orografı́a del terreno son parámetros que deben tenerse en cuenta para obtener resultados correctos, evitando situaciones como los de la Figura 1. En este caso se puede observar una escena no realista en la que el zócalo y el portal del edificio aparecen hundidos debajo del asfalto de la calle. El tipo de navegación permitida en el entorno virtual es otro aspecto que afecta al proceso de texturización. Para recorridos aéreos, no es necesario alcanzar un alto Marı́a Dolores Robles Ortega Universidad de Jaén, Departamento de Informática e-mail: [email protected] Lidia Ortega Alvarado Universidad de Jaén, Departamento de Informática e-mail: [email protected] Francisco R. Feito Higueruela Universidad de Jaén, Departamento de Informática e-mail: [email protected] 133 134 Marı́a Dolores Robles Ortega, Lidia Ortega Alvarado y Francisco R. Feito Higueruela Fig. 1 Situación no realista por la incorrecta texturización de la fachada nivel de detalle en la texturización de los edificios o del mobiliario urbano [1], pudiendo utilizarse técnicas de renderizado basadas en impostores como, por ejemplo, la propuesta en [8]. En cambio, en una navegación peatonal se deben utilizar mecanismos que enriquezcan el modelo mediante texturas reales o métodos procedurales y gramáticas [3, 4]. En este trabajo se propone un método del primer tipo basado en la utilización de imágenes reales de la ciudad. Evidentemente, la toma de fotografı́as de todas las manzanas para posteriormente realizar un texturizado manual de cada una de ellas serı́a muy costoso. En realidad, en la mayorı́a de los casos sólo se dispone de texturas procedentes de fotografı́as de las zonas más conocidas. Esto serı́a suficiente si la navegación se realizase únicamente por las áreas más emblemáticas de la ciudad, y la interacción se limitase a localizar algunas calles y a conocer la ruta hacia determinados emplazamientos. Sin embargo, si el usuario puede navegar libremente por cualquier zona de la escena, será necesario realizar un proceso de texturización para la ciudad completa. Por tanto, se debe diseñar un método que, a partir de un conjunto de imágenes, realice una asignación automática de las texturas y obtenga unos resultados realistas, aunque no se correspondan exactamente con el aspecto que tienen en su emplazamiento real. Para ello, todas las imágenes disponibles deben ser previamente clasificadas dependiendo de la época de construcción del edificio que representan y del barrio donde se ubican. De esta forma, la selección de las texturas para cada manzana no será aleatoria, sino que se realizará teniendo en cuenta los criterios anteriormente especificados. Gracias a esta consideración, al igual que ocurre en la realidad, los elementos de un mismo barrio tendrán una apariencia similar y no se producirán situaciones irreales como la aparición de una imagen de una fachada moderna junto a una textura que representa un edificio de un barrio antiguo en una misma manzana. En definitiva, los modelos se generarán utilizando los datos reales de geometrı́a y ubicación. El método propuesto permite además la reutilización de las texturas en diferentes modelos. A continuación se explican los principales trabajos relacionados con la texturización en escenarios urbanos. Posteriormente, se describe la fase de tratamiento previos realizada a las fotografı́as antes de almacenarlas en la base de datos, y el proceso de mapeado automático. Se explica también el mecanismo de selección de texturas implementado, basado en la utilización de algoritmos genéticos. Finalmente, se exponen los resultados obtenidos y los principales trabajos futuros. Texturización en entornos urbanos 2. 135 Trabajos previos Tal y como se ha comentado anteriormente, texturizar un entorno urbano es una tarea compleja debido a la gran cantidad de elementos geométricos que lo componen. Seguidamente se describen las principales técnicas usadas para este propósito. En la literatura se pueden encontrar algunos trabajos que utilizan métodos procedurales en el proceso de texturización de las fachadas de los edificios. En [5], por ejemplo, se describe un procedimiento para extraer elementos de una fachada y generar, a partir de los mismos, una textura que pueda utilizarse en una técnica procedural. En [6], en cambio, se propone la división de las imágenes en tres partes: una primera que se repite a lo largo de la superficie de la fachada y que representa el material de la pared (ladrillo o piedra), una segunda que contiene un conjunto único de objetos como ventanas o puertas y una tercera que almacena las coordenadas de textura. Los tres niveles se combinan mediante shaders de OpenGL. En algunos casos las técnicas procedurales no se usan de forma individual, sino conjuntamente con otro tipo de métodos. Ası́, algunos autores proponen la combinación del modelado procedural de gramáticas con el análisis de imágenes para generar una subdivisión jerárquica de fachadas [7]. También se han desarrollado herramientas interactivas que combinan las técnicas procedurales con los datos introducidos por el usuario. En [8], por ejemplo, se describe un sistema que funciona en dos fases: inicialmente el usuario determina las caracterı́sticas generales del contorno y estilo del edificio y, en una segunda etapa, el programa genera los detalles de la fachadas. Estas fases se realizan justamente al contrario en la aplicación propuesta en [9]. Ası́, primero el sistema crea automáticamente un modelo de un edificio utilizando gramáticas y después el usuario interacciona con el mismo para modificarlo. Además de las gramáticas, normalmente se utiliza un conjunto de fotografı́as como datos de entrada para generar un modelo 3D urbano. Éste es el caso del algoritmo presentado en [10], que genera un modelo 3D fotorrealista a partir de una fotografı́a completa de un lado de una calle. Para ello, mediante un método de segmentación la imagen inicial se divide a nivel de pı́xel en áreas significativas semánticamente, que posteriormente se etiquetan como un objeto especı́fico (edificio, cielo, suelo, vegetación o coche). A continuación se introduce un esquema de partición para separar los edificios en manzanas independientes. Finalmente, para cada manzana, se realiza una composición ortográfica inversa basada en parches y un método de análisis de la estructura para modelado de fachadas que reduce eficientemente el ruido y los posibles datos perdidos en la reconstrucción 3D. El sistema descrito en [11] también usa fotografı́as. Esta herramienta interactiva calcula automáticamente la estructura 3D usando los resultados de la interacción 2D y la información recuperada mediante el análisis de los datos de entrada. En este caso, los mapas de texturas se generan a través de la combinación de múltiples fotografı́as de entrada usando las técnicas de graph cut optimization [12] y Poisson blending [13]. En [14] se describe otro método que genera un modelo 3D texturizado usando los resultados de un escáner 3D de un edificio y un conjunto de imágenes 136 Marı́a Dolores Robles Ortega, Lidia Ortega Alvarado y Francisco R. Feito Higueruela previamente capturadas. Esta técnica utiliza las reglas de paralelismo y ortogonalidad que existen de forma natural en los entornos urbanos. Entre los diferentes medios disponibles para obtener las texturas, destacan las imágenes aéreas [15, 16] y los vı́deos digitales [17, 18]. Uno de los principales problemas para la mayorı́a de los algoritmos descritos anteriormente es que no es posible reutilizar las imágenes de entrada para texturizar distintos elementos. Por ello, si se desea crear el modelo completo de la ciudad, serı́a necesaria una gran cantidad de fotografı́as equivalente al menos al número total de edificios. En el método que se describe en este capı́tulo se usan fotografı́as reales de la ciudad de Jaén tomadas con una cámara Nikon D90, que son procesadas y parametrizadas según se explica en la Sección 4. Para la texturización se utilizan algoritmos genéticos porque permiten considerar requerimientos adicionales para obtener unos resultados más realistas como, por ejemplo, la pendiente de las calles, o la correcta combinación de texturas para plantas inferiores y superiores, entre otros. Al contrario que otras técnicas como Greedy, esta metodologı́a permite determinar varias soluciones correctas para los mismos datos de entrada tras distintas ejecuciones. Gracias a la variabilidad de los resultados en cada ejecución, el usuario final puede elegir el modelo que mejor se ajuste a sus necesidades. Esto es especialmente útil para generación de ciudades virtuales en aplicaciones como cine o juegos. 3. Colocación automática de las texturas en una manzana En esta sección se describe un método automático para colocar las texturas de forma correcta en el modelo 2.5D de las manzanas considerando la pendiente de las calles en la que están situadas. Inicialmente se detallan los requerimientos generales de todo el proceso para obtener unos resultados realistas. A continuación se explica la fase previa de procesamiento realizada a las fotografı́as para conseguir las texturas y sus parámetros asociados, que se almacenan en la base de datos. Finalmente, se explica el proceso de mapeado para obtener el modelo final de cada manzana. 3.1. Mapeado de texturas El mapeado de texturas (texture mapping) es una técnica para la sı́ntesis de imágenes en la que se proyecta una textura en una superficie de una escena tridimensional [19], de la misma forma que un papel se coloca en una pared. Para ello, son necesarios dos sistemas de coordenadas [20]: el espacio 2D de las texturas (texture space) y el 3D de los objetos (object space), donde se define la geometrı́a tridimensional de la escena (los polı́gonos que componen el entorno urbano, en este caso). El proceso de mapeado, por tanto, consiste en establecer una correspondencia entre el espacio 2D de la textura y el espacio 3D del objeto. Texturización en entornos urbanos 137 Escalado para ajustar la textura a lasdimensiones delmodelo 2.5D Traslación para ajustar la textura a la pendiente de la calle Fig. 2 Esquema general del proceso de texturización. En un procedimiento de mapeado de texturas clásico, dado un polı́gono compuesto por un conjunto de vértices y una textura, se realiza una asignación de las coordenadas de textura (u, v) (u, v ∈ [0, 1]) a cada vértice del polı́gono mediante un conjunto de transformaciones más o menos complejas, que podrı́an ser clasificadas en distintas categorı́as como afines, euclı́deas o de similitud, entre otras. En el caso de las manzanas, tal y como se puede observar en la Figura 2, es suficiente con utilizar transformaciones afines, puesto que la textura puede colocarse correctamente en el modelo final utilizando sólo rotaciones, escalados y traslaciones. En este ejemplo, primero se ajusta la altura y anchura de la imagen a las dimensiones de la pared donde va a ser proyectada y, después, se realiza una traslación para colocar la imagen en la posición adecuada. La rotación no es necesaria puesto que durante el proceso de tratamiento previo de las fotografı́as se realiza una corrección de perspectiva. 3.2. Requerimientos generales Debido a que existen caracterı́sticas muy diferentes en la adjudicación de texturas a bajos de manzanas y a zonas superiores, se ha decidido dividir las manzanas en dos partes, tal y como se puede observar en la Figura 3. Las texturas, por tanto, se clasifican también en dos categorı́as: superior e inferior. Para obtener unos resultados correctos tras el proceso de texturización, es necesario considerar una serie de aspectos que permitirán incrementar el realismo de los modelos generados: 138 Marı́a Dolores Robles Ortega, Lidia Ortega Alvarado y Francisco R. Feito Higueruela Fig. 3 División de las manzanas en dos partes: superior e inferior. Fig. 4 Situación no realista al texturizar esquinas de edificios. 1. El sistema deberá determinar las texturas en función de la altura de cada edificio. 2. El procedimiento debe asignar texturas adecuadas para cada zona de la ciudad. 3. Las texturas no pueden expandirse ni reducirse de manera excesiva para evitar resultados no realistas. Por tanto, el tamaño real que representa cada imagen deberá tenerse en cuenta para evitar asignaciones irreales. En el método que se está describiendo en este capı́tulo no se permite una extensión superior al 10 % de la anchura de las texturas. 4. La pendiente de las calles debe ser considerada para evitar problemas como los de la Figura 1, en las que las ventanas y las puertas de entrada aparecen hundidas debajo del asfalto de la calle. 5. Ninguna ventana o puerta puede ser colocada en medio de una esquina porque ocasionarı́a resultados no realistas (Figura 4). 6. Las texturas de parte inferior se comportan normalmente de modo diferente al resto de plantas. Se considera que una manzana tiene al menos un portal de entrada y el resto son locales comerciales o garajes. 7. Todas las texturas de la parte inferior de un edificio deben estar situadas en la misma altura a nivel de techo, como en la Figura 5. A continuación se explica el tratamiento que se realiza a las fotografı́as iniciales para obtener un conjunto de texturas que se almacenarán en la base de datos y que Texturización en entornos urbanos 139 Fig. 5 Todas las texturas de la parte inferior de un edificio deben estar colocadas a la misma altura. posteriormente serán utilizadas en el proceso de mapeado que se describe en la Sección 5. 4. Procesamiento de las imágenes La utilización de una fotografı́a real como textura no es un proceso automático, sino que es necesario realizar un tratamiento previo de la imagen para corregir posibles errores derivados de la propia captura. La primera modificación que se debe realizar es corregir la perspectiva de la fotografı́a original. Este proceso es necesario porque los modelos 2.5D de las manzanas se sitúan sin ninguna inclinación y, por tanto, las texturas deben ser también completamente verticales. Seguidamente se elimina cualquier elemento urbano situado sobre la fachada como, por ejemplo, árboles, farolas o coches, para evitar incoherencias en el modelo final. Finalmente, se obtienen texturas que contengan una única fachada. Para ello, las fotografı́as se dividen en fragmentos horizontales o verticales según corresponda. Cada una de estas nuevas texturas será clasificada según la zona de la ciudad a la que pertenezca y su tipo: garaje, portal, escaparate, etc. Una vez que las texturas han sido obtenidas y corregidas, el siguiente paso consiste en determinar la información necesaria para realizar un mapeado correcto [22]. Seguidamente se describe este proceso tanto para las texturas inferiores como para las superiores. 4.1. Parte inferior Un factor importante que se debe tener en cuenta durante el proceso de texturización para obtener resultados correctos es la pendiente de las calles. Ası́, aunque en 140 Marı́a Dolores Robles Ortega, Lidia Ortega Alvarado y Francisco R. Feito Higueruela (a) Textura original (b) Puntos de control (c) Textura final Fig. 6 Puntos de control de una textura para la parte inferior de una manzana. una ciudad plana la colocación de una textura en la parte inferior de una manzana es un proceso trivial, en el caso de calles con pendiente se deben cumplir una serie de requisitos para obtener unos resultados realistas. Por ejemplo, las puertas de entrada a los edificios y comercios deben estar situadas justo a nivel del suelo de manera que se simule correctamente la entrada a un edificio durante el proceso de navegación peatonal. Este proceso se realiza de forma previa a la asignación de las texturas y sus resultados se almacenan en la base de datos, de manera que las imágenes puedan ser reutilizadas en un amplio conjunto de manzanas de una o diferentes ciudades. El cálculo de la máxima pendiente de una textura se ilustra con un ejemplo en la Figura 6. En la Subfigura 6(a) se puede observar la fotografı́a original de un edificio de Jaén y en la Subfigura 6(b) los cuatro puntos de control asociados a la misma. Los dos primeros puntos, A y B, se corresponden con las esquinas de las puertas y se utilizarán para situar la textura en la altura correcta para permitir la entrada a los edificios. Los puntos C y D, situados en los extremos izquierdo y derecho de la imagen, evitan problemas de intersecciones de la superficie de la calle con el zócalo, las ventanas u otros elementos de la fachada. Una vez obtenidos los puntos de control, la máxima pendiente permitida de la calle donde se puede colocar la textura viene determinada por los ángulos ∠DEF = α y ∠CFE = β , como se muestra en la Figura 6(b). Sin embargo, la textura estarı́a incompleta si se situase en una calle con la máxima pendiente, puesto que la parte inferior no tiene una textura asociada. Para evitar esta situación, se incluye una franja adicional de anchura h de la textura original en esta parte de la imagen (Figura 6(c)). Como las texturas pueden ser ajustadas tanto en altura como en anchura, y el cambio de tamaño afecta a la pendiente, en la base de datos se almacena el valor máximo y mı́nimo para α y β . Otro aspecto fundamental que se debe considerar en el proceso de colocación de las texturas es evitar que una ventana o cualquier otro elemento de la fachada aparezca situado en mitad de una esquina. Para ello, es necesario determinar qué vértices Texturización en entornos urbanos 141 Fig. 7 Ejemplo de intervalos de textura indivisibles de un edificio pueden ser considerados como esquina y qué intervalos de cada textura no pueden ser divididos. Ambos elementos pueden definirse en un espacio 2D, puesto que la tercera dimensión es independiente de su valor. Ası́, por ejemplo, en el caso de los intervalos indivisibles, éstos están determinados por puntos 2D que generan una división de la textura en franjas verticales. 4.2. Parte superior Las texturas de este tipo tienen menos requisitos que las de la parte inferior, puesto que su posición es independiente de la pendiente de la calle en la que estén situadas. No obstante, al igual que en éstas, se debe considerar el problema de las esquinas para evitar que una ventana o cualquier otro elemento de la fachada aparezca situado en mitad de las mismas. Por tanto, para estas imágenes se determinarán también el conjunto de intervalos indivisibles definidos en el apartado anterior. 5. Colocación automática de las texturas Según se ha descrito anteriormente, para realizar un mapeado correcto es necesario determinar los factores de rotación, escalado y traslación. Sin embargo, en el caso de la texturización de las manzanas, la rotación se realiza previamente durante el proceso de corrección de las texturas. Por tanto, únicamente será necesario determinar los factores de escalado y traslación [23]. Seguidamente se explica el proceso de mapeado de las texturas inferiores y superiores para evitar situaciones no realistas. 142 Marı́a Dolores Robles Ortega, Lidia Ortega Alvarado y Francisco R. Feito Higueruela Fig. 8 Cálculo de la proyección del segmento del tramo con puntos de cruce C1 y C2 en la pared del edificio. 5.1. Colocación de las texturas en la parte inferior Tal y como se ha comentado anteriormente, el objetivo del escalado es ajustar la textura a las dimensiones de la pared del edificio que se va a texturizar. Para ello, se deben determinar los factores de escalado para la anchura y la altura. Este cálculo es inmediato puesto que se conocen tanto el tamaño real de la imagen que representa las texturas como el de la pared. La obtención de los valores de traslación MT es algo más complejo. Inicialmente se considera como precondición que la textura esté situada en el mismo plano XZ que la pared. Como consecuencia de esto, sólo será necesaria una traslación vertical que coloque la puerta de entrada al nivel del suelo para evitar ası́ los problemas descritos anteriormente. El proceso para obtener el valor de la traslación vertical utiliza como datos de entrada la textura, las aristas del polı́gono del edificio y su tramo asociado. Se compone de los siguientes pasos, ilustrados en la Figura 8: 1. 2. 3. 4. Se calcula el plano π , asociado a la arista del edificio. Se obtiene el segmento de tramo s entre los puntos de cruce C1 y C2 . Se proyecta el segmento s en el plano π y se obtiene la recta r. Se realiza el mapeado de la textura en la pared del edificio utilizando los datos anteriores (Figura 9): a) Se ajusta la anchura y la altura de la textura con la de la pared (wText = d y hText = h). b) Se calcula el valor de la coordenada y del punto F (yF ), es decir, la distancia vertical a la que deberı́a colocarse la puerta para obtener una texturización correcta: yF = ydG xF c) Se obtiene la traslación vertical V V = yB − yF − yE Texturización en entornos urbanos (a) Espacio del objeto 143 (b) Espacio de la textura Fig. 9 Cálculo de la altura correcta para la textura. Si en el paso 4 el mapeado de la textura se realizase directamente en la pared del edificio la posición de la puerta vendrı́a dada por las coordenadas del punto B (xB , yB ). Sin embargo, tal y como muestra la Figura 9(a), esta posición no es realista puesto que no permite una entrada de forma natural al inmueble. Por ello, la textura debe ser trasladada verticalmente hasta la posición correcta, establecida por el punto F, cuya coordenada y (yF ) se obtiene fácilmente usando semejanza de triángulos (paso 4b). Para calcular finalmente la traslación V que situará la puerta correctamente se utiliza la fórmula V = yB − yF − yE . La posición del punto E debe ser incluida porque la recta r intersecta con π a la altura de yE . 5.2. Colocación de las texturas en la parte superior Al igual que en las texturas de la parte inferior, los factores de escalado se calculan a partir de la dimensión de la pared de la manzana y del tamaño real de la imagen que representa la textura. Sin embargo, en este caso no es necesario realizar una traslación de la imagen, puesto que la posición de la textura es independiente de la pendiente de la calle. En este caso, la imagen debe colocarse justo encima de la textura de los bajos. 6. Algoritmo genético para la texturización de las manzanas 2.5D situadas en una superficie no plana Una vez descrito el procedimiento de colocación de las texturas, a continuación se detallan los algoritmos de selección utilizados para obtener un conjunto adecua- 144 Marı́a Dolores Robles Ortega, Lidia Ortega Alvarado y Francisco R. Feito Higueruela do de imágenes para texturizar tanto la parte superior como la parte inferior de una manzana. En ambos casos se explican los aspectos básicos de los métodos implementados. 6.1. Parte inferior El algoritmo propuesto selecciona un conjunto de texturas apropiado para texturizar la parte inferior de un edificio situado en una calle inclinada, pudiendo obtenerse resultados distintos en cada ejecución del algoritmo. Seguidamente se describe el procedimiento completo. Definición del problema La texturización de la parte inferior de una manzana 2.5D situada en una superficie no plana puede definirse formalmente como la obtención de un conjunto de texturas no repetidas cuya suma total se ajuste a la longitud de las aristas externas del edificio (condición 1) y que contenga una única textura de tipo portal (condición 2). Además, tras el proceso de mapeado, ninguna ventana u otro elemento de la fachada debe aparecer situado en una esquina (condición 3). Selección inicial de las texturas La selección de las texturas se realiza mediante una consulta a la base de datos que considera la zona en la que está situado el edificio, los valores de altura y anchura ası́ como la pendiente del tramo de calle. El conjunto de imágenes seleccionadas será utilizado para generar la población del algoritmo genético. Representación. Correspondencia entre el fenotipo y el genotipo Se ha utilizado una codificación discreta y, en particular, binaria. Ası́, el tamaño de los cromosomas es fijo y viene determinado por el número de texturas potenciales. Cada gen indica si la textura aparece (valor 1) o no (valor 0) en la solución final. Inicialización de la población Se realiza una asignación aleatoria pero considerando que cada cromosoma incluya una única textura de tipo portal. De esta forma, se reduce el número de cromosomas posibles de la población y se facilita el proceso de encontrar una solución. Selección Los padres se eligen mediante la estrategia de selección por torneo de tamaño 3. Operador de cruce El operador de cruce utilizado se basa en la división de los cromosomas en dos bloques: portales y resto de texturas. Posteriormente, se realiza un intercambio de estos bloques mediante un operador de cruce de un punto (single point crossover, PSX). Operador de mutación Para incrementar el espacio de búsqueda y favorecer la variabilidad de la población se han establecido dos operadores de mutación. Ambos se basan en la Texturización en entornos urbanos 145 inversión de los genes, pero se diferencian en la forma de selección: aleatoria o determinista. En el primer caso, se genera un número aleatorio que modificará el valor del gen cuando sea superior a una constante previamente establecida. En el segundo, en cambio, se modifica siempre el gen que representa la textura de mayor anchura del cromosoma. Función de evaluación Esta función evalúa el grado de cumplimiento de las condiciones establecidas en la definición del problema. Además de estos requerimientos, se consideran también aspectos relativos a la eficiencia de la solución como, por ejemplo, la preferencia por soluciones con un menor número de texturas. Estrategia de reemplazamiento Se ha utilizado una estrategia de reemplazamiento generacional que crea una nueva población en cada iteración. Se utiliza asimismo el elitismo para mantener al mejor cromosoma de cada generación. De esta forma se evita eliminar un buen individuo que podrı́a ser elegido como solución final. Condición de parada Se han establecido dos posibles condiciones de parada: encontrar una solución que obtenga el valor máximo de la función fitness o que se realicen un número predeterminado de ejecuciones. En las pruebas realizadas el algoritmo siempre ha finalizado debido a la primera condición. 6.2. Parte superior Tras describir el algoritmo genético para la parte inferior, seguidamente se detalla el procedimiento propuesto para la texturización de la parte superior. En este caso se utilizan manzanas en lugar de edificios. Definición del problema El problema de asignación de texturas de tipo superior puede definirse como la búsqueda de un subconjunto de imágenes no repetidas cuya suma de longitudes se ajusta al perı́metro de la manzana. Por tanto, las texturas seleccionadas deben cumplir dos requerimientos: 1) la suma de sus anchuras se corresponda con la de la manzana y 2) no haya ninguna textura repetida en la solución. Selección inicial de las texturas La selección de las texturas se realiza mediante una consulta a la base de datos en la que obtienen un conjunto de imágenes que se corresponden con la zona de la manzana y que podrı́an ajustarse a su anchura. Además, el número de pisos de estas texturas deberá ser igual al número de plantas de la manzana. Representación. Correspondencia entre el fenotipo y el genotipo Se utiliza una representación entera, siendo el tamaño del cromosoma un valor fijo determinado por el número de edificios de la manzana. Ası́, cada gen indica la textura para el edificio de la manzana. Inicialización de la población 146 Marı́a Dolores Robles Ortega, Lidia Ortega Alvarado y Francisco R. Feito Higueruela La población se inicializa de forma aleatoria, pero generando siempre individuos válidos. En concreto, el método implementado genera para cada gen un valor aleatorio entre 0 y el número de texturas potenciales para el edificio. Selección Al igual que para el algoritmo de la parte inferior, se utiliza el método de selección por torneo de tamaño tres. Operador de cruce Se ha utilizado un operador de cruce uniforme (Uniform Crossover) que determina a qué hijo se asigna el valor de cada padre según un valor aleatorio generado en el intervalo [0,1]. Operador de mutación En este caso se han establecido dos operadores de mutación. El primero de ellos modifica el valor de un gen seleccionado de forma aleatoria por otra textura válida. El segundo, en cambio, se utiliza para reducir el número de cromosomas no válidos y consiste en cambiar la primera textura repetida por otra imagen válida. Función de evaluación La función de evaluación diseñada comprueba el grado de cumplimiento de las dos condiciones establecidas en la definición del problema. En concreto, la primera condición no es necesario comprobarla puesto que el mecanismo de selección obtiene siempre un conjunto de texturas que la cumplen. Para valorar el segundo requerimiento, se calcula un valor proporcional al número de texturas repetidas. De esta forma, se favorecen las soluciones en las que no haya imágenes duplicadas. Estrategia de reemplazamiento Se utiliza una estrategia de reemplazamiento generacional que crea una nueva población en cada iteración, pero utilizando elitismo para mantener el mejor cromosoma de cada evaluación. Condición de parada Al igual que para el algoritmo de la parte inferior, se han establecido dos posibles razones como condición de parada: encontrar una solución que obtenga el valor máximo de la función fitness o realizar un número predeterminado de ejecuciones. 7. Resultados En esta sección se describen los resultados obtenidos tras aplicar los algoritmos genéticos descritos anteriormente a un conjunto de manzanas de la ciudad de Jaén. El problema de texturización planteado podrı́a haberse resuelto también utilizando algoritmos deterministas como, por ejemplo, métodos Greedy [21]. No obstante, estos métodos tienen un orden de ejecución elevado y, además, obtienen siempre la misma solución para el mismo conjunto de datos de entrada. En el caso de los genéticos, en cambio, en cada ejecución se obtiene una combinación diferente de Texturización en entornos urbanos 147 Fig. 10 Capturas de pantalla de la escena obtenida. texturas, lo que resulta especialmente útil para aplicaciones en las que se necesita escoger entre diferentes alternativas. En la Figura 10 se muestran algunas capturas de pantalla de la escena generada. Como se puede observar, las texturas están situadas correctamente incluso en las calles con una excesiva pendiente. En todos los casos las puertas de entrada están colocadas justo a nivel del suelo, lo que permite la entrada de forma natural a los edificios. Además, la superficie de la calle no intersecta con los zócalos ni con ningún otro elemento de la fachada. La texturización de las esquinas también se realiza de forma correcta. 148 8. Marı́a Dolores Robles Ortega, Lidia Ortega Alvarado y Francisco R. Feito Higueruela Conclusiones y trabajos futuros En este capı́tulo se han descrito las principales consideraciones que se deben tener en cuenta para texturizar un entorno urbano. En concreto, se han propuesto dos algoritmos genéticos que permiten texturizar de forma automática los modelos 2.5D de manzanas de edificios situadas en una superficie no plana. Además, se ha creado también un procedimiento de colocación automática de las texturas en el modelo final que considera aspectos fundamentales para obtener una escena realista como, por ejemplo, la posición correcta de un zócalo y la colocación de la puerta de entrada de un edificio para permitir una entrada natural. Entre los trabajos futuros puede destacarse la automatización del tratamiento previo de las texturas mediante la utilización de métodos de tratamiento digital de imágenes. Agradecimientos Este trabajo ha sido parcialmente subvencionado por el Ministerio de Ciencia e Innovación y la Unión Europea a través de los fondos FEDER bajo el proyecto de investigación TIN2011-25259 y por la Universidad de Jaén bajo el proyecto UJA2010/13/08 subvencionado por Caja Rural de Jaén. Referencias 1. Coelho, A. F. F., de Sousa, A. A. & Ferreira, F. N. 3D Modelling of Large Urban Scenes from Diverse Sources of Information ELPUB (2003) 2. Andujar, C., Brunet, P., Chica, A. & Navazo, I. Visualization of Large-Scale Urban Models through Multi-Level Relief Impostors Computer Graphics Forum 29, 2456-2468 (2010) 3. Coelho, A., Bessa, M., Sousa, A. A. & Ferreira, F. Expeditious Modelling of Virtual Urban Environments with Geospatial L-systems Computer Graphics Forum, Blackwell Publishing Ltd, 26, 769-782 (2007) 4. Müller, P., Wonka, P., Haegler, S., Ulmer, A. & Gool, L. Procedural Modeling of Buildings Proceedings of ACM SIGGRAPH 2006 / ACM Transactions on Graphics, ACM Press, 25, 614-623 (2006) 5. Ricard, J., Royan, J. & Aubault, O. From photographs to procedural facade models ACM SIGGRAPH 2007 posters, ACM, (2007) 6. Laycock, R., Ryder, G. & Day, A. Automatic generation, texturing and population of a reflective real-time urban environment Computers & Graphics, 31, 625 - 635 (2007) 7. Müller, P., Zeng, G., Wonka, P. & Van Gool, L. Image-based procedural modeling of facades ACM Transactions on Graphics-Proceedings of ACM SIGGRAPH 2007, ACM, 26 (2007) 8. Finkenzeller, D. Detailed Building Facades IEEE Comput. Graph. Appl., IEEE Computer Society Press, 28, 58-66 (2008) 9. Aliaga, D. G., Rosen, P. A. & Bekins, D. R. Style Grammars for Interactive Visualization of Architecture IEEE Transactions on Visualization and Computer Graphics, IEEE Educational Activities Department, 13, 786-797 (2007) 10. Xiao, J., Fang, T., Zhao, P., Lhuillier, M. & Quan, L. Image-based street-side city modeling ACM Trans. Graph., ACM, 2009, 28, 114:1-114:12 11. Sinha, S. N., Steedly, D., Szeliski, R., Agrawala, M. & Pollefeys, M. Interactive 3D architectural modeling from unordered photo collections ACM SIGGRAPH Asia 2008 papers, ACM, 2008, 159:1-159:10 (2008) Texturización en entornos urbanos 149 12. Agarwala, A., Dontcheva, M., Agrawala, M., Drucker, S., Colburn, A., Curless, B., Salesin, D. & Cohen, M. Interactive digital photomontage ACM Trans. Graph., ACM, 23, 294-302 (2004) 13. Pérez, P., Gangnet, M. & Blake, A. Poisson image editing ACM Trans. Graph., ACM, 22, 313-318 (2003) 14. Stamos, I. & Allen, P. Automatic registration of 2-D with 3-D imagery in urban environments Computer Vision, 2001. ICCV 2001. Proceedings. Eighth IEEE International Conference on, 2, pp. 731-736 (2001) 15. Tan, Y. K. A., Kwoh, L. K. & Ong, S. H. Large Scale Texture Mapping of Building Facades The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, XXXVII (Part B5), 687-692 (2008) 16. Wu, J. & Liu, Z. Zhang, Y. (Ed.) General Framework Of Photo-Realistic 3D Visualization of Urban Building Proceedings of the Fifth International Conference on Image and Graphics (ICIG 2009), pp. 559-564 (2009) 17. Tsai, F., Chen, C.-H., Liu, J.-K. & Hsiao, K.-H. Abdul-Rahman, A., Zlatanova, S. & Coors, V. (Eds.) Texture Generation and Mapping Using Video Sequences for 3D Building Models Innovations in 3D Geo Information Systems, Springer Berlin Heidelberg, pp. 429-438 (2006) 18. Kang, Z., Zhang, Z., Zhang, J. & Zlatanova, S. Li, J., Zlatanova, S., Fabbri, A. G., Cartwright, W., Gartner, G., Meng, L. & Peterson, M. P. (Eds.) Rapidly Realizing 3D Visualisation for Urban Street Based on Multi-Source Data Integration Geomatics Solutions for Disaster Management, Springer Berlin Heidelberg, 149-163 (2007) 19. Catmull, E. A subdivision Algorithm for Computer Display of Curved Surfaces Univ. of Utah (1974) 20. Heckbert, P. Fundamentals of texture mapping and image warping UCB/CSD 89/516, CS Division, U.C. Berkeley (1989) 21. Cormen, T., Leiserson, C., Rivest, R. & Stein, C. Introduction to Algorithms, Second Edition Greedy Algorithms The MIT Press, 370-404 (2001) 22. Robles-Ortega, M. D., Ortega, L., Feito, F. R. & Garcı́a, Á. L. Automatic texture mapping of buildings in hilly cities Computer Graphics International, CGI (2011) 23. Robles-Ortega, M. D., Ortega, L. & Feito, F. R. Ramos, P. & Sacristán, V. (Eds.) XIV Spanish Meeting on Computational Geometry A geometrical approach for automatic building texture mapping. Centre de Reserca Matemàtica, 87-90 (2011) Visualización de medios participativos en entornos urbanos J. Roberto Jiménez Pérez, Francisco Martı́nez del Rı́o y Ángel Aguilera Garcı́a Resumen Cada vez es más frecuente encontrar modelos de ciudades reales que permiten a un usuario interactuar de diversos modos con el mismo. Un aspecto en el que todavı́a hay que mejorar es en el realismo de la visualización. En este trabajo proponemos una solución para visualizar escenas de manera realista incluyendo iluminación, sombras y medios participativos. Estos elementos se han incluido teniendo en cuenta que la experiencia del usuario es importante y que por tanto, la respuesta del modelo debe ser adecuada. Nuestra solución está basada en Monte Carlo y tanto la iluminación como el medio y el modelo permanecen invariables durante la interacción. 1. Introducción Investigaciones recientes se centran en la problemática del modelado de ciudades que permitan una experiencia inmersiva al usuario, dándole la posibilidad de realizar recorridos, visitar de lugares de interés, etc. Un aspecto importante en la mejora de dicha experiencia es el realismo con que se visualiza la ciudad. Incluir una visualización realista supone añadir iluminación, cálculo de sombras, etc. En este artı́culo estudiamos la problemática que suscita la inclusión de medios participativos en el modelo de la ciudad, tales como niebla, humo, polución, etc. En general, la simulación realista de medios participativos es compleja debido a la dimensión adicional que se requiere para representarlos [5]. Normalmente, los Juan Roberto Jiménez Pérez Universidad de Jaén e-mail: [email protected] Francisco Martı́nez del Rı́o Universidad de Jaén e-mail: [email protected] Angel Aguilera Garcı́a Universidad de Jaén e-mail: [email protected] 151 152 J. Roberto Jiménez Pérez, Francisco Martı́nez del Rı́o y Ángel Aguilera Garcı́a edificios, calles y plazas se representan mediante conjuntos de polı́gonos y triángulos. Además, la dirección de propagación de la luz dentro del medio cambia continuamente debido al fenómeno de dispersión. En el caso de la visualización de ciudades existe una dificultad adicional, y es el gran tamaño de los modelos, no tanto por el número de polı́gonos que requiere sino por sus dimensiones. Dadas las peculiaridades de la visualización de medios participativos, ésta amplitud supone un reto aún no resuelto. En este artı́culo proponemos un método para la visualización realista de ciudades incluyendo medios participativos que permita interacción en tiempo real por parte del usuario. Este artı́culo se estructura del siguiente modo: la Sección 2 expone brevemente algunos resultados previos, la Sección 3 explica el método propuesto, la Sección 4 detalla los resultados obtenidos, y, por último, la Sección 5 comenta las conclusiones y el trabajo futuro. 2. Trabajos previos El método zonal [18] es una extensión a los medios participativos del algoritmo clásico de radiosidad. El color final de un pixel se obtiene al añadir al color del triángulo intersecado el de acumular cada uno de los voxeles a lo largo de la lı́nea en la dirección de vista. Languenou et al. [12] propuso una solución eficiente para la visualización de medios participativos anisótropos y no homogéneos, basada en la discretización del espacio de direcciones. De este modo, para cada voxel la radiancia se precalcula y se almacena para cada dirección de salida. El principal problema de estos métodos es que requieren elevados recursos de almacenamiento. Otras soluciones para evitar estos problemas son las siguientes. Bhate et al. [2] usar harmónicos esféricos para aproximar la función de fase anisótropa. La fase de visualización es similar a propuestas anteriormente mencionadas. Stam [23] se basa en el uso de la ecuación de difusión, que simplifica la dispersión múltiple asumiendo que puede ser representada mediante los dos primeros términos de la serie de Taylor. Por otro lado, otras propuestas se han centrado en disminuir el coste del número de factores de forma que es necesario calcular [1, 22, 20]. Estas propuestas dividen la escena en un conjunto de elementos finitos organizados jerárquicamente. Esta organización permite reducir el cálculo de factores de forma fomentando el uso del nivel adecuado dentro de la jerarquı́a. Estas técnicas se basan en medios participativos isótropos. Pérez et al. [15] elimina esta restricción y visualiza medios anisótropos mediante el uso de una técnica mixta basada en Monte Carlo. En general, las soluciones deterministas implican el uso de representaciones complejas y tienen un coste de memoria elevado. Por otro lado, las técnicas basadas en Monte Carlo disminuyen esta necesidad a costa de aumentar el ruido en las escenas [11, 14]. Este ruido se debe a que se requiere un elevado número de muestras para mitigarlo. Jensen et al. [8] presentaron una técnica basada en el uso de técnicas Visualización de medios participativos en entornos urbanos 153 de estimación de la densidad para eliminar el problema del ruido sin necesidad de incrementar sustancialmente el número de partı́culas (muestras). Jiménez et al. [10] aproximan las técnicas de estimación de la densidad para adecuarlas a los procesadores gráficos. De esta forma, consiguen resultados interactivos para medios participativos genéricos. Szirmay-Kalos et al. [24] extienden el concepto de red de lı́neas globales de haces de iluminación a medios participativos animados [4, 19, 16]. Harris y Lastra [7] presentaron un método para visualizar nubes en tiempo real, basados en la propiedad de las nubes cuya dispersión es principalmente hacia adelante. De este modo, consiguieron simular dispersión múltiple con únicamente dos direcciones. Este trabajo se basa en la propuesta de Dobashi et al. [6] que proponı́a el mismo método pero únicamente para simular dispersión simple. Biri et al. [3] propusieron un algoritmo de tiempo real para la visualización de niebla representada mediante un medio no homogéneo. El conjunto de coeficientes de extinción se representan mediante funciones eliminando la necesidad de almacenamiento. Sloan et al. [21] propusieron un método de tiempo real para la visualización de medios isótropos y teniendo en cuenta dispersión múltiple. Este método se denomina PRT (precomputed radiance transfer) y se basa en las propiedades de los harmónicos esféricos para hacer independiente los cambios en la iluminación con respecto al cálculo de la distribución de la energı́a en el medio participativo. Esta propuesta está limitada a escenas estáticas e iluminación procedente del infinito. Por otro lado, Zhou et al. [25] consigue tiempo real de humo en animación basándose en la exponenciación de los harmónicos esféricos [17]. Esta exponenciación se basa en el proceso de difusión propuesto por Stam [23]. Para una visión más en profundidad de las técnicas de visualización de medios participativos, léase [5]. 3. Metodologı́a En principio, pudiéramos pensar que cualquier método clásico de visualización de medios participativos es válido para su aplicación en entornos urbanos. La propuesta que presentamos en este trabajo se basa en los métodos de Monte Carlo para evitar un uso elevado de memoria, concretamente nos basamos en la solución de Jiménez et al. [10]. Hemos descartado las soluciones basadas en harmónicos esféricos debido a que son menos adecuadas a condiciones en las que la iluminación está cercana a la escena. A continuación detallamos el algoritmo utilizado, ası́ como su aplicación a entornos urbanos. La solución propuesta se divide en tres fases: trazado de rayos, reconstrucción y visualización. Esta fase se basa en el algoritmo clásico de trazado de partı́culas. Durante la misma, las partı́culas cargadas de energı́a son emitidas desde las fuentes de luz hacia la escena. Cada vez que se produce una interacción de la partı́cula con algún elemento de la escena (triángulos o medio participativo) se almacena la misma, y la partı́cula continua su camino con una nueva dirección y con la disminución de energı́a acorde 154 J. Roberto Jiménez Pérez, Francisco Martı́nez del Rı́o y Ángel Aguilera Garcı́a con las propiedades ópticas del elemento. Esta fase es independiente de la posición del observador. La siguiente fase, la fase de reconstrucción, obtiene como resultado una textura por cada elemento: texturas 2D para los triángulos y 3D para los medios participativos. Cada texel de dichas texturas representa la energı́a saliente desde la región correspondiente a dicho texel. Esta fase tampoco depende del punto de vista para medios isótropos y superficies difusas. Esta fase se divide en dos partes: una primera para acumular la energı́a que se refleja en la dirección de vista en un histograma y otra para aplicarle un filtro para mitigar el caracterı́stico ruido de las técnicas de Monte Carlo y ası́ disminuir el número de partı́culas que es necesario para obtener un resultado satisfactorio. Finalmente, la fase de visualización divide el volumen que representa al medio participativo en un conjunto de lonchas, las cuales se orientan perpendiculares a la dirección de vista y se proyectan en orden de atrás hacia adelante para ir acumulando la energı́a de cada uno de los voxeles. Esta fase depende de la posición del observador y debe recalcularse cada vez que se mueve. La técnica descrita hace referencia a un único medio participativo, pero para ocupar las dimensiones de una ciudad esto no es suficiente. En este trabajo proponemos replicar el medio participativo precalculado de modo que se eviten saltos en la interacción del usuario con la escena. Para ello, se seleccionan los medios participativos que se van a calcular y se sitúan en puntos caracterı́sticos del entorno. A continuación, estos medios precalculados se replican en posiciones similares a sus orı́genes. 4. Resultados Los resultados han sido obtenidos en un procesador Intel Core Duo 2.2GHz, con un 1GB de memoria RAM y una tarjeta gráfica Nvidia Quadro FX 570M. La implementación se ha basado en la plataforma SIR [13] y la escena se ha modelado utilizando el estándar MGFE [9]. La imagen de la Figura 1 muestra la calle de una ciudad en un entorno iluminado y en presencia de niebla. El medio participativo utilizado es isótropo y homogéneo. Se han lanzado 3 millones de partı́culas, y tras las interacciones se han guardado en los distintos elementos de la escena 4,285,161 millones de impactos. El tiempo requerido en la fase de trazado de rayos ha sido de 32.21 segundos, mientras que en la fase de reconstrucción, 0.49 segundos se han empleado en la construcción del histograma y 0.09 segundos en el filtrado gaussiano. La fase final de visualización requiere un tiempo prácticamente despreciable lo que permite una interacción en tiempo real por parte del usuario. La duplicación del medio participativo apenas tiene incidencia en en el tiempo requerido por la fase de visualización mientras no se requiere de almacenamiento externo. El resto de fases si se ven afectadas por las dimensiones del volumen al necesitar mayor número de fotones para su correcta visualización. Visualización de medios participativos en entornos urbanos 155 Fig. 1 Imagen de una calle de una ciudad iluminada y con niebla 5. Conclusiones y trabajo futuro Hemos presentado una propuesta para la visualización realista de entornos urbanos incluyendo medios participativos de manera interactiva. La técnica propuesta es suficientemente genérica para tratar con medios homogéneos y no homogéneos, ası́ como dispersión simple y múltiple. Esta técnica es válida tanto para iluminación diurna (el Sol) o nocturna, dado que no está restringida a una distancia mı́nima de las fuentes de luz. Además, utiliza los recursos de los procesadores gráficos en caso de que haya que reconstruir la iluminación reflejada hacia el observador para medios anisótropos. La propuesta se basa en calcular un subconjunto de medios participativos que se replican a lo largo del entorno. Queda pendiente un estudio sobre el comportamiento y la mitigación de errores en las fronteras entre dichas réplicas. Además, pretendemos superar la limitación de que las luces permanezcan estáticas durante la simulación como serı́a el caso de simular que el observador va sentado en un vehı́culo. Para ello, estudiaremos los métodos basados en harmónicos esféricos que permiten de ofrecen la ventaja de la interacción dinámica de las fuentes de luz, para superar la limitación de la distancia mı́nima entre la fuente y la escena sin acumular excesivas aproximaciones. 156 J. Roberto Jiménez Pérez, Francisco Martı́nez del Rı́o y Ángel Aguilera Garcı́a Agradecimientos Este trabajo ha sido parcialmente financiado por el Ministerio de Ciencia e Innovación y la Unión Europea (vı́a fondos FEDER) a través del proyecto TIN2011-25259. Referencias 1. N. Bhate. Application of rapid hierarchical radiosity to participating media. In Proceedings of ATARV-93: Advanced Techniques in Animation, Rendering, and Visualization, pages 43–53, Ankara, Turkey, July 1993. Bilkent University. 2. N. Bhate and A. Tokuta. Photorealistic volume rendering of media with directional scattering. In A. Chalmers, D. Paddon, and F. X. Sillion, editors, Third Eurographics Workshop on Rendering, pages 227–245, Bristol, UK, May 1992. 3. V. Biri, S. Michelin, and D. Arquès. Real-time animation of realistic fog. In P. Debevec and S. Gibson, editors, Thirteenth Eurographics Workshop on Rendering, Pisa, Italy, 2002. Poster paper. 4. C. Buchalew and D. Fussell. Illumination networks: Fast realistic rendering with general reflectance functions. In SIGGRAPH ’89: Proceedings of the 16th annual conference on Computer graphics and interactive techniques, pages 89–98, New York, NY, USA, 1989. ACM Press. 5. E. Cerezo, F. Pérez, X. Pueyo, F. J. Serón, and F. X. Sillion. A survey on participating media rendering techniques. The Visual Computer, 21(5):303–328, June 2005. 6. Y. Dobashi, K. Kaneda, H. Yamashita, T. Okita, and T. Nishita. A simple, efficient method for realistic animation of clouds. In K. Akeley, editor, Siggraph 2000, Computer Graphics Proceedings, Annual Conference Series, pages 19–28. ACM Press / ACM SIGGRAPH / Addison Wesley Longman, 2000. 7. M. J. Harris and A. Lastra. Real-time cloud rendering. In A. Chalmers and T.-M. Rhyne, editors, EG 2001 Proceedings, volume 20(3) of Computer Graphics Forum, pages 76–84. Blackwell Publishing, 2001. 8. H. W. Jensen and P. H. Christensen. Efficient simulation of light transport in scenes with participating media using photon maps. In Computer Graphics (ACM SIGGRAPH ’98 Proceedings), pages 311–320, 1998. 9. J.-R. Jiménez, I. Martı́n, and F. Pérez. MGFE: Materials and geometry format extended. http://ima.udg.es/iiia/GGG/doc/mgfehtml/mgfe.shtml. 10. J.-R. Jiménez and X. Pueyo. Interactive rendering of globally illuminated scenes including anisotropic and inhomogeneous participating media. The Visual Computer, 21(7):449–462, 2005. 11. E. P. Lafortune and Y. D. Willems. Rendering participating media with bidirectional path tracing. In X. Pueyo and P. Schröder, editors, Seventh Eurographics Workshop on Rendering, pages 91–100, Porto, Portugal, 1996. 12. E. Languenou, K. Bouatouch, and M. Chelle. Global illumination in presence of participating media with general properties. In P. S. Georgios Sakas and S. Müller, editors, Fifth Eurographics Workshop on Rendering, pages 69–85, Darmstadt, Germany, June 1994. 13. I. Martı́n, F. Pérez, and X. Pueyo. The SIR rendering architecture. Computers & Graphics, 22(5):601–609, 1998. 14. M. Pauly, T. Kollig, and A. Keller. Metropolis light transport for participating media. In B. Peroche and H. Rushmeier, editors, Eleventh Eurographics Workshop on Rendering, pages 11–22, Brno, Czech Republic, 2000. 15. F. Pérez, I. Martin, F. X. Sillion, and X. Pueyo. Acceleration of monte carlo path tracing in general environments. In Proceedings of Pacific Graphics 2000, Hong Kong, PRC, October 2000. 16. R. W. Preisendorfer. Radiative Transfer on Discrete Spaces. Pergamon Press, Oxford, England, 1965. Visualización de medios participativos en entornos urbanos 157 17. Z. Ren, R. Wang, J. Snyder, K. Zhou, X. Liu, B. Sun, P.-P. Sloan, H. Bao, Q. Peng, and B. Guo. Real-time soft shadows in dynamic scenes using spherical harmonic exponentiation. In SIGGRAPH ’06: ACM SIGGRAPH 2006 Papers, pages 977–986, New York, NY, USA, 2006. ACM. 18. H. E. Rushmeier and K. E. Torrance. The zonal method for calculating light intensities in the presence of a participating medium. Computer Graphics, 21(4):293–302, July 1987. 19. M. Sbert. The Use of Global Random Directions to Compute Radiosity: Global Monte Carlo Techniques. PhD thesis, Universitat Politècnica de Catalunya, Barcelona, Spain, 1997. 20. F. X. Sillion. A unified hierarchical algorithm for global illumination with scattering volumes and object clusters. IEEE Transactions on Visualization and Computer Graphics, 1(3), September 1995. 21. P.-P. Sloan, J. Kautz, and J. Snyder. Precomputed radiance transfer for real-time rendering in dynamic, low-frequency lighting environments. ACM Transactions on Graphics, 21(3):527– 536, July 2002. 22. L. M. Sobierajski. Global Illumination Models for Volume Rendering. PhD thesis, Department of Computer Science, State University of New York at Stony Brook, August 1994. 23. J. Stam. Multiple scattering as a diffusion process. In P. M. Hanrahan and W. Purgathofer, editors, Sixth Eurographics Workshop on Rendering, pages 41–50, Dublin, Ireland, 1995. 24. L. Szirmay-Kalos, M. Sbert, and T. Ummenhoffer. Real-time multiple scattering in participating media with illumination networks. In Rendering Techniques, pages 277–282, 2005. 25. K. Zhou, Z. Ren, S. Lin, H. Bao, B. Guo, and H.-Y. Shum. Real-time smoke rendering using compensated ray marching. In SIGGRAPH ’08: ACM SIGGRAPH 2008 papers, pages 1–12, New York, NY, USA, 2008. ACM. Bloque V Tratamiento de información urbana Estudio sobre la representación semántica y topológica de interiores de edificios Bernardino Domı́nguez Martı́n, Ángel Luis Garcı́a Fernández y Francisco R. Feito Higueruela Resumen El software relacionado con los entornos urbanos ha experimentado un crecimiento muy significativo en los últimos años. Como este tipo de software requiere la creación y manipulación de modelos urbanos, tanto de ciudades completas como de interiores de edificios, están apareciendo gran cantidad de propuestas para cubrir esta necesidad, y más concretamente para manejar la geometrı́a, topologı́a y semántica de modelos de interiores de edificios. En este capı́tulo revisaremos una serie de trabajos que tratan esta problemática, relacionados con Sistemas de Información Geográfica (GIS), Modelos de Información de Edificios (BIM), Modelos de Productos de Edificios (BPM) y Diseño Asistido por Computadora (CAD). 1. Introducción La información acerca del interior de los edificios se utiliza en aplicaciones tales como los Sistemas de Información Geográfica (GIS), Modelos de Información de Edificios (BIM), bases de datos espaciales o Diseño Asistido por Computadora (CAD). Cada aplicación utiliza distintas formas para representar la información; ası́, el estándar más extendido para manejar la información BIM en la construcción es el modelo de clases IFC (Industry Foundation Classes). Incluso en la misma área de investigación es posible encontrar variadas visiones parciales del mismo modelo, dependiendo de la aplicación especı́fica 1 . Algunas aplicaciones relacionadas con la representación de interiores son el cálculo de rutas de evacuación, navegación peatonal o de agentes por interiores, reconstrucción 3D de edificios, modelado y diseño, desarrollo de juegos, peritaje arquitectónico, etcétera. B. Domı́nguez, Á.L. Garcı́a, F.R. Feito Departamento de Informática. Universidad de Jaén e-mail: {bdmartin,algarcia,ffeito}@ujaen.es 1 A partir de ahora, se hará referencia a estas tecnologı́as por su nombre o sus siglas indistintamente 161 162 B. Domı́nguez, Á.L. Garcı́a y F.R. Feito Las múltiples combinaciones posibles entre los distintos modelos de representación y las diversas áreas de aplicación hace difı́cil encontrar técnicas y modelos comunes aplicables a un amplio espectro de trabajos. Es por esto que es útil establecer una clasificación de dichos modelos y áreas de aplicación como punto de partida antes de desarrollar nuevas propuestas. Se presentan aquı́ algunas de las contribuciones más recientes en el campo de la representación semántica y topológica de interiores de edificios. En la Sección 2 se fijan criterios para esta clasificación basados en el modelo de representación utilizado, y se resumen los principales antecedentes. Las Secciones 3 a 5 reseñan trabajos relacionados con el tratamiento de información de interiores. En la Sección 6 se presenta un análisis comparativo de estos trabajos y se trata la importancia de investigar métodos (semi)automáticos para el procesamiento de planos de plantas. Por último, en la Sección 7 se resumen las conclusiones y el trabajo futuro a desarrollar. 2. Modelos de representación Hay muchos modelos de representación disponibles en la literatura reciente, presentados en trabajos sobre distintas aplicaciones con datos arquitectónicos. Cada uno de estos modelos se centra en un conjunto reducido de datos acerca de los edificios, aplicando distintas soluciones. Estos modelos se han agrupado tradicionalmente en las áreas de GIS y BIM. Por otra parte, también se puede tener en cuenta los objetivos de los modelos de representación; esto es: representación de topologı́a, geometrı́a o semántica. Sin embargo, la mayorı́a de las propuestas presentadas son modelos hı́bridos, que utilizan varios niveles de abstracción para almacenar información de distintos tipos. En esta sección se revisan algunos trabajos basados en los estándares más comunes de BIM y GIS, ası́ como diferentes modelos para representar edificios (de acuerdo con la división en 2D, 2.5D y 3D). 2.1. Modelos de Información de Edificios y Sistemas de Información Geográfica En 1992, Björk [3] estableció los fundamentos de los sistemas BIM, presentando un modelo orientado a objetos para la representación semántica de datos de edificios. Su investigación se clasifica en el campo de los inicialmente denominados Modelos de Productos de Edificios (BPM), un nombre alternativo a los BIM. Tras estudiar y comparar algunos BPM de proyectos como RATAS, GSD, el modelo de casa de De Waard y COMBINE IDM, Björk centró su trabajo en la definición de un esquema que incluyera información sobre espacios y las entidades que los encierran (paredes, columnas, puertas y ventanas). Estudio sobre la representación semántica y topológica de interiores de edificios 163 En 1997 apareció la primera versión del estándar IFC, creado por la IAI (International Alliance for Interoperability), convirtiéndose en uno de los más populares para la representación de BIMs. La definición de este estándar está escrita con el lenguaje de modelado EXPRESS, el mismo que aparece en [3], y define un esquema [6] para el intercambio de información de edificios en todas las etapas del proceso de construcción, incluyendo información semántica sobre la estructura de los mismos. Por otra parte, los sistemas GIS son capaces de recoger cada vez más información sobre el interior de los edificios. Con este fin, CityGML [20] define un modelo de información para el almacenamiento de modelos urbanos, basado en cuatro niveles de detalle, siendo el cuarto y último (LoD-4) el dedicado a los interiores de edificios. Respecto a la representación de la geometrı́a subyacente, los sistemas BIM utilizan CSG, barrido o modelos B-Rep, mientras que los sistemas GIS sólo utilizan modelos B-Rep [19] (por ejemplo: CityGML utiliza el lenguaje GML2 [26] para la definición de información geométrica). La diversidad de modelos de representación es un obstáculo a la hora de combinar ambas tecnologı́as. Isikdag y otros [19] presentan un diagrama de casos de uso que asume que los usuarios con el rol de arquitecto crean modelos BIM. Cerovsek, por su parte, hace un estudio exhaustivo sobre la tecnologı́a BIM en [7]. Este último trabajo presenta una serie de recomendaciones acerca de cómo deben evolucionar los modelos BIM para que el desarrollo y estandarización de herramientas BIM sea más sencillo. 2.2. Modelos 2D, 2.5D y 3D Un criterio alternativo para clasificar los modelos de representación de edificios es su dimensión espacial. Los modelos de edificios pueden contener: Información 2D, como por ejemplo: planos de plantas, modelos estructurales de habitaciones y pasillos, etcétera. Información 2.5D, que implica aumentar la información 2D con datos acerca de la altura de las plantas, relaciones entre plantas contiguas o existencia de diferentes alturas dentro de la misma planta. Información 3D, representando la geometrı́a y la topologı́a de manera explı́cita. A continuación se revisan varias propuestas de modelos de representación, clasificadas de acuerdo a los criterios anteriormente expuestos. Además, se analizarán desde el punto de vista de su nivel de abstracción, esto es, el nivel de información geométrica, topológica y semántica que se almacena en cada caso: Modelos geométricos: estos modelos sólo contienen información acerca de la geometrı́a de los interiores de los edificios. Los planos de plantas CAD se incluyen en esta categorı́a, puesto que contienen datos de bajo nivel estructurados 2 Geographic Markup Language 164 B. Domı́nguez, Á.L. Garcı́a y F.R. Feito en capas [18]. La mayorı́a de los modelos CAD observados representan las paredes con dos lı́neas paralelas almacenadas de forma redundante, puesto que los extremos de las lı́neas que definen dos paredes consecutivas están repetidos en la representación. Por otra parte, puertas, ventanas, mobiliario y otros elementos tı́picos se representan como instancias de bloques [4]. Aunque hay alguna relación de conectividad en las instancias de bloques, este tipo de representación no se considera topológica. Modelos topológicos/semánticos: se pueden definir dos niveles de abstracción, aparte de las representaciones puramente geométricas: 1. Modelos con información de adyacencia/conectividad entre primitivas geométricas (por ejemplo: puntos compartidos por dos lı́neas o lados compartidos por polı́gonos). 2. Modelos que además incluyen información sobre entidades de alto nivel (habitaciones, pasillos, paredes, columnas). Las representaciones del primer nivel se clasificarán como modelos topológicos, mientras que las del segundo nivel se clasificarán como modelos semánticos. 3. Modelos 2D En esta sección se reseñan trabajos que utilizan una representación explı́cita 2D de la geometrı́a de los edificios, ası́ como otros trabajos que aunque no incluyen esta representación, están centrados en un área de aplicación que no requiere de una representación explı́cita en 2.5D o 3D. Franz y otros [14] analizan modelos de edificios desde dos puntos de vista: la arquitectura y las ciencias cognitivas. Resumen siete modelos basados en grafos utilizados en ambas áreas, y reflexionan sobre la posibilidad de migrar información entre ellos. Desde el punto de vista cognitivo, tratan tres modelos: 1. La cuadrı́cula de ocupación, utilizada en Inteligencia Artificial para la navegación de robots en espacios parcialmente ocupados. 2. El grafo de localización, utilizado para representar conectividad entre espacios. 3. El grafo de visión, utilizado para representar vistas conectadas en la navegación de robots basada en imágenes. Desde el punto de vista de la arquitectura, citan cuatro tipos de representaciones basadas en grafos: 1. El grafo de acceso entre regiones espaciales (habitaciones, por ejemplo). 2. Los mapas axiales, que representan el conjunto mı́nimo de lı́neas de visión de longitud máxima. 3. Los campos de isovistas, que representan cuencas visuales poligonales conectadas por lados si existe visibilidad mutua. Estudio sobre la representación semántica y topológica de interiores de edificios 165 4. Los grafos de visibilidad, derivados de los campos de isovistas. En este trabajo de Franz y otros se considera únicamente el tratamiento de la información topológica, puesto que no se tiene en cuenta la representación geométrica subyacente, y sólo el grafo de acceso incluye conceptos semánticos y regiones espaciales. Lamarche y Donikian [21] proponen un método de representación de la topologı́a de los espacios interiores de un edificio para la simulación de multitudes. Calculan un conjunto de celdas convexas utilizando la triangulación restringida de Delaunay del plano de la planta. Este conjunto se representa como un grafo cuyos nodos representan las celdas, y los lados las relaciones de vecindad entre celdas (Figura 1). Esta representación topológica del espacio permite identificar corredores, cruces y callejones sin salida, utilizados para hallar cuellos de botella para peatones. La representación geométrica subyacente en el trabajo de Fig. 1 Figura tomada de [21]. Arriba: plano de una planta con las celdas convexas definidas por Lamarche y Donikian. Abajo: grafo representando la accesibilidad entre celdas convexas, tal y como lo definen Lamarche y Donikian. Lamarche y Donikian está formada por celdas convexas 2D obtenidas a partir del interior de una planta de un edificio. El conjunto de celdas se obtiene a partir del resultado de cortar un modelo 3D de la planta, que se encuentra almacenado en una base de datos geométrica, con dos planos paralelos, el primero de los cuales 166 B. Domı́nguez, Á.L. Garcı́a y F.R. Feito se corresponde con el suelo, y el segundo situado a una distancia del suelo igual a la altura media de un humano. Las lı́neas resultantes se procesan utilizando el algoritmo S-MAT3 , una variante del algoritmo MAT4 [22] para obtener las celdas convexas. Respecto al contenido semántico, no se incluye ninguna información en este modelo, puesto que en las celdas convexas no se guarda información sobre la zona de la planta (habitación, pasillo, etcétera) de la que proceden. Otro trabajo interesante es el de Plümer y Gröger [28], en el que definen otra representación formal para la agregación de objetos espaciales 2D, denominada mapas anidados. Esta estructura consta básicamente de grafos planos restringidos cuyos ciclos se estructuran jerárquicamente. De esta forma, se puede modelar fácilmente la estructura jerárquica de los espacios cerrados. Las restricciones sobre los grafos vienen dadas por siete axiomas sobre los vértices, lados, caras y conectividad determinadas por los grafos planos. Por último, los autores estudian la integridad de los mapas anidados cuando se añaden o eliminan objetos, y proponen un modelo generalizado para gestionar agujeros y zonas inconexas, denominado mapas complejos. El modelo de mapas anidados y mapas complejos tiene una alta correlación entre la geometrı́a y la topologı́a, ya que existe una correspondencia unı́voca entre los nodos de los grafos y los vértices del plano 2D; ası́ mismo, los lados de los grafos se corresponden con lı́neas rectas del plano. Sin embargo, la semántica asociada a los espacios cerrados y los lados está fuera de los objetivos de ese trabajo. Stoffel y otros proponen grafos jerárquicos de regiones para modelar la estructura de un conjunto de regiones espaciales [30]. En su trabajo, las regiones espaciales se definen como secuencias cerradas y ordenadas de esquinas. También se definen algunas relaciones entre regiones, con la idea de modelar un grafo de regiones como una estructura que representa estas relaciones. La caracterı́stica jerárquica es utilizada para modelar la inclusión de un espacio dentro de otro. Las estructuras de datos utilizadas incluyen parámetros de tipo para indicar la semántica de los nodos (puertas, ventanas, etcétera) y de los grafos (habitaciones, pasillos, almacenes...). La relación entre geometrı́a, topologı́a y semántica en este trabajo es bastante fuerte, y viene dada de la siguiente manera: 1. Las esquinas que definen las regiones espaciales tienen una posición en el espacio 2D. 2. Los nodos frontera de los grafos enlazan regiones espaciales adyacentes, y tienen asociado un tipo (puerta, ventana o abertura). 3. Las relaciones de parentesco establecen una jerarquı́a entre regiones espaciales. 4. Los grafos de regiones reúnen los conceptos previamente descritos para además añadir información semántica en los nodos, incluyendo un tipo (planta, sección, habitación, etcétera). 3 4 Straight Medium Axis Transform Medium Axis Transform Estudio sobre la representación semántica y topológica de interiores de edificios 167 El trabajo de Li y otros [24] toma directamente como punto de partida una representación semántica del interior de una planta de un edificio, incluyendo habitaciones, vestı́bulos, tabiques, muros, puertas y ventanas. Esta representación está formada por un conjunto de células con significado, esto es: áreas delimitadas del modelo, ocupadas por cada uno de los elementos semánticos antes mencionados (por ejemplo, un trozo de muro se considera una célula). Estas células pueden estar vacı́as (vestı́bulos, habitaciones, puertas abiertas,...) u ocupadas (paredes, ventanas, puertas cerradas,...). Se hace entonces una descomposición regular del espacio utilizando un grafo-cuadrı́cula con un nivel de granularidad dado, y cada nodo-cuadrı́cula se etiqueta de acuerdo a la célula que la ocupa, y se conecta con sus ocho vecinos. Aplicando distintos algoritmos sobre grafos a esta estructura, se pueden resolver de manera eficiente problemas de análisis espacial y navegación de agentes (Figura 2). Este modelo de representación no Fig. 2 Figura tomada de [24]. Análisis de rutas utilizando grafos de cuadrı́culas 168 B. Domı́nguez, Á.L. Garcı́a y F.R. Feito busca conseguir una representación geométrica o topológica exacta, sino una representación discretizada sobre la que aplicar sus algoritmos. Es por esto que no se menciona ningún modelo de representación 2D de la geometrı́a de la planta. Zhi y otros [36] presentan un formalismo para trabajar con la representación de planos arquitectónicos utilizando la siguiente metodologı́a: el plano arquitectónico se convierte en un grafo de objetos que representan la estructura de paredes y aberturas, de tal forma que los ciclos representan espacios cerrados. Como las habitaciones se obtienen a partir de los ciclos mı́nimos del grafo, en este trabajo se utilizan vectores para calcular los ciclos fundamentales de área mı́nima. En este trabajo también se enumeran ocho problemas o dificultades que surgen habitualmente al procesar planos CAD, incluyendo la existencia de errores e información redundante, uso de nombres no estándar para las capas y la identificación de las relaciones entre estancias comunicadas por puertas, especialmente en aquellos casos en que una estancia tiene más de una puerta. Otras restricciones sobre los datos de entrada incluyen la adecuada división de las entidades en capas y la utilización de bloques para representar sı́mbolos y dimensiones. Si todas las restricciones indicadas se cumplen, la selección de entidades esenciales se realiza de manera semiautomática. Hahn y otros [17] trabajan sobre la generación de interiores de edificios en tiempo real. Su generador se caracteriza por: • La generación perezosa de los interiores. Esto es, sólo se genera la información para las zonas cercanas al punto de vista. • El esquema de generación implica la división del edificio en regiones temporales, y la generación de puntos clave en las localizaciones donde estas regiones han de convertirse en regiones construidas. • La utilización de un conjunto de reglas para asegurar la corrección y el realismo de los resultados. • El uso de números pseudoaleatorios en el proceso de generación de la información, lo que permite reproducir los resultados en caso de que sea necesario mediante el uso de la misma semilla. En el trabajo de Hahn y otros se tratan tanto aspectos semánticos como geométricos, puesto que el resultado de la división en regiones temporales es un conjunto de subespacios que se corresponden semánticamente con habitaciones y vestı́bulos. La topologı́a se representa parcialmente, ya que durante el proceso mantienen un árbol de generación en el que los subespacios resultado de dividir un espacio mayor están directamente relacionados con él, y estudiando la geometrı́a de los subespacios resultado de una división, se pueden construir relaciones de vecindad. Resolver la generación de interiores de edificios partiendo de un conjunto de requerimientos de alto nivel y utilizando redes bayesianas es la propuesta de Merrell y otros [25]. Ellos crean un programa arquitectónico después de entrenar una red bayesiana con datos reales, que luego convierten en un plano real aplicando una optimización sobre el espacio de posibles distribuciones de plantas. Estudio sobre la representación semántica y topológica de interiores de edificios 169 Por último, proponen la generación de modelos 3D a partir de los planos de las plantas utilizando plantillas de estilo personalizables. Su trabajo alcanza gran nivel de detalle semántico, ya que distinguen entre distintos tipos de habitaciones (dormitorios, comedor, cocina,...) para diseñar una distribución que tenga en cuenta las heurı́sticas que siguen los arquitectos (por ejemplo: las cocinas no suelen colocarse adyacentes a los baños). Como consecuencia, la geometrı́a y la estructura topológica del interior del edificio aparece de forma explı́cita. 4. Modelos 2D con altura Esta sección resume trabajos que utilizan un modelo de representación 2D con información de alturas. Aunque los autores de algunos de estos trabajos no los consideran 2.5D porque incluyen algunas caracterı́sticas propias de los modelos 3D, todos los trabajos resumidos aquı́ se basan en el uso de representaciones 2D a las que se añade información de altura. Slingsby y Raper presentaron en 2007 un interesante trabajo sobre la navegación peatonal en modelos 3D urbanos [29]. En él presentaban un estado del arte sobre el modelado 3D urbano, la navegación peatonal y el acceso a edificios, y proponı́an un modelo para representar espacios urbanos navegables consistente en una representación 2.5D de las plantas de los edificios. Para tratar las morfologı́as de planta irregulares, proponı́an el uso de cuatro elementos restrictivos: rampas, escaleras, lineas de ruptura y desplazamientos. Respecto a la relación entre geometrı́a y semántica, Slingsby y Raper proponen el uso de etiquetas para las barreras (paredes y vallas) y la asociación de aberturas y ascensores a los elementos geométricos, mientras que elementos semánticos de mayor nivel como habitaciones o pasillos no se mencionan. La información topológica permanece implı́cita a la existencia de elementos geométricos etiquetados, de forma que la búsqueda de dichos elementos permite deducir información espacial sobre la vecindad entre regiones espaciales. Tutenel y otros presentan en [32] un sistema solucionador basado en reglas para generar escenarios de interiores de edificios automáticamente. Este sistema utiliza clases para representar formas en 3D etiquetadas (por ejemplo: sofá, mesa, televisión,...), y las reglas que utiliza se definen de tres formas: 1. Algunas reglas se definen como restricciones a las etiquetas. Por ejemplo: “las cajas englobantes de objetos con la etiqueta OffLimit no pueden superponerse”, o “los objetos como platos o vasos deben estar situados sobre objetos con la etiqueta TableTop”. 2. Otras reglas se definen como relaciones entre clases, de manera que los objetos pertenecientes a dichas clases se ven afectados por esas relaciones. 3. Por último, es posible añadir reglas especı́ficas al planificador de distribuciones. 170 B. Domı́nguez, Á.L. Garcı́a y F.R. Feito El planificador de distribuciones antes mencionado es un módulo que aplica un mecanismo de backtracking que define un conjunto de reglas y ejecuta el solucionador para cada objeto que hay que situar en la planta. El solucionador calcula un conjunto de posibles localizaciones para cada objeto de acuerdo a las reglas y a los objetos que ya estén situados en la planta, y selecciona la mejor de acuerdo a un sistema de puntuaciones. Este trabajo ha sido incluido en la sección de modelos 2D con altura porque aunque la base para el cálculo de la distribución de la planta es el plano 2D, se utiliza información sobre la altura del suelo para evitar el apilamiento de objetos en las mismas coordenadas. Incluso aunque los autores no dan detalles sobre la representación de la geometrı́a y la semántica, se puede deducir que se tienen en cuenta en el solucionador. Respecto a la representación de topologı́a en este modelo, no se proporciona ninguna información. La distribución del mobiliario en una planta también es tratada en el trabajo de Germer y Schwarz [15]. Sin embargo, ellos utilizan una aproximación distinta, utilizando agentes para representar muebles. Cada agente se encarga de buscar una localización y una orientación apropiadas para el mueble que le corresponde, ası́ como encontrar un objeto con el que establecer una relación de descendencia. En este proceso, cada agente tiene tres posibles estados: 1. Búsqueda, cuando todavı́a no ha sido procesado, ha perdido su relación de descendencia o su búsqueda de localización ha fallado. 2. Establecimiento, cuando el agente ha encontrado un posible ascendiente. 3. Reposo, cuando el establecimiento ha sido satisfactorio. Este trabajo, al igual que el anterior, parte del hecho de que la existencia de las habitaciones es conocida (desde los puntos de vista geométrico y semántico), ası́ como su altura. Sin embargo, como cada habitación se trabaja de manera independiente, la información topológica no se tiene en cuenta. En [13], van Dongen propone una técnica para simular interiores de edificios sin almacenamiento de geometrı́a, para su uso en navegación virtual por las calles de un modelo urbano. Los edificios se modelan como cubos vacı́os, y en el proceso de renderizado se simula la existencia de habitaciones, objetos y personas en el interior de los edificios de la siguiente forma: 1. Se aplica una textura difusa con información de transparencia a cada edificio, de manera que si no hay transparencia se utiliza la imagen de textura, y si la hay, se aplica la simulación de interiores. 2. El algoritmo de simulación de interiores divide el interior del edificio en planos que representan tabiques y techos. Luego se aplica un algoritmo de trazado de rayos para cada pixel transparente de la textura para determinar si el primer plano visible es un tabique o un techo, y se aplica el color correspondiente al pixel. Adicionalmente, se pueden simular personas caminando dentro de los edificios añadiendo más planos. El trabajo de van Dongen se basa en técnicas de renderizado, y no necesita almacenar información semántica o topológica real. No obstante, se ha clasificado en Estudio sobre la representación semántica y topológica de interiores de edificios 171 este grupo de técnicas porque contiene alguna información acerca de plantas con altura. El plano de planta estructurado propuesto por Choi y otros [9] es una estructura semántica de alto nivel que cumple nueve principios acerca de la orientación de los objetos en el modelo, la existencia de información sobre las relaciones entre las entidades, el tratamiento de la información espacial y las relaciones, los niveles de detalle y la generación automática de un modelo 3D a partir del plano estructurado (Figura 3). Utiliza un esquema orientado a objetos para la representación del plano estructurado, y presenta algoritmos para crear esta estructura partiendo de la geometrı́a de un plano de planta. Este modelo no almacena una Fig. 3 Figura tomada de [9]. Modelo de datos para el plano de planta estructurado de Choi y otros descripción exhaustiva de la geometrı́a de los edificios. En lugar de eso, los planos arquitectónicos se utilizan para calcular sólo la información semántica relevante, como la superficie de las losas, tejados, anillos, la anchura y altura de los cimientos, vigas, aberturas, etcétera. El modelo está pensado para que lo utilicen diseñadores CAD, de forma que al añadir nuevas caracterı́sticas a un diseño, los 172 B. Domı́nguez, Á.L. Garcı́a y F.R. Feito cambios se integran en el plano estructurado, manteniendo ası́ la consistencia. Aunque la representación subyacente del modelo es 2.5D, los autores muestran algunos ejemplos de creación de contenido 3D a partir de los planos estructurados. 5. Modelos 3D Por último, se presenta un resumen de trabajos que hacen un uso más intensivo de caracterı́sticas 3D. La Red Geométrica 3D es un grafo propuesto por Choi y Lee para la representación de la conectividad entre las habitaciones de un edificio [8, 23]. Esta estructura no sólo representa la estructura 2D de la planta, sino que también modela la estructura 3D al añadir lados entre las habitaciones de plantas diferentes. La metodologı́a de creación de estos grafos implica el uso del algoritmo S-MAT mencionado en la Sección 3 para extraer la estructura de paredes. En este trabajo se consideran dos posibles entradas de datos para la creación de las redes: 1. Planos CAD vectoriales de plantas, donde las paredes se representan como polı́gonos cerrados. En este caso, los autores proponen la aplicación del algoritmo S-MAT para obtener los esqueletos de las paredes. 2. Planos ráster. Los autores presentan tres métodos para obtener una lı́nea fina a partir de las representaciones de paredes más gruesas de un pı́xel: adelgazamiento basado en diagramas de Voronoi, adelgazamiento basado en operadores matemáticos y refinado (peeling) de fronteras. Las redes geométricas 3D representan la geometrı́a, la topologı́a y la semántica, ya que utilizan modelos B-Rep de los edificios (geometrı́a) para obtener modelos topológicos denominados Modelos de Datos Combinatorios (CDM). Las redes geométricas se obtienen de los CDM, y a su vez contienen información sobre las habitaciones (semántica), además de sobre la conectividad entre habitaciones a través de las aberturas, y sobre la adyacencia entre habitaciones a través de las paredes compartidas (topologı́a). Clemen y Gielsdorf [10] proponen un método sistemático para normalizar (reducir la redundancia de) modelos geométricos. En su trabajo usan una representación generalizada de modelos consistente en sólidos formados por caras contenidas en planos, semilados y nodos. Las restricciones geométricas (planaridad, paralelismo de planos) se pueden asegurar por integridad referencial. Desde un punto de vista geométrico, este trabajo utiliza datos B-Rep como información de entrada en los métodos de reducción de la redundancia. Esta elección es apropiada, puesto que es fácil hacer corresponder ambos modelos. Respecto a la forma en que se obtienen los modelos B-Rep, este trabajo se centra en la gestión de datos topográficos de interiores. El modelo propuesto trabaja con datos Estudio sobre la representación semántica y topológica de interiores de edificios 173 inexactos procedentes de mediciones de escenarios reales, puesto que el objetivo es la estimación de la topologı́a real. Este método asume que hay redundancias en los datos obtenidos, y aplica técnicas estadı́sticas. La topologı́a aparece de forma explı́cita como relaciones entre sólidos, caras, planos, semilados y lados. Sin embargo, no se mencionan elementos semánticos de alto nivel. El problema de la conversión entre los modelos IFC y CityGML es tratado por Van Berlo y Laat en un reciente trabajo [1]. Para conseguir esto, introducen una extensión para CityGML denominada GeoBIM. Por tanto, tanto la geometrı́a subyacente como los modelos semántico y topológico son los mismos en IFC y CityGML. Las casas topológicas propuestas por Paul y Bradley [27] son una abstracción puramente matemática para la descripción de casas. Esta definición formal permite codificar casas utilizando dos estructuras: PLA (Puntos, Lı́neas y Áreas) y PLAV (Puntos, Lı́neas, Áreas y Volúmenes). Los autores demuestran que se pueden utilizar estas estructuras para representar casas en bases de datos relacionales sin pérdida de información. El modelo matemático presentado en su trabajo relaciona geometrı́a y topologı́a. Los únicos elementos semánticos que tiene en cuenta son paredes y techos. Billen y Zlatanova proponen el modelo dimensional, una abstracción topológica para objetos 3D que permite analizar relaciones complejas entre ellos [2]. Este modelo representa cuatro elementos dimensionales (0D, 1D, 2D y 3D) para cada objeto espacial, e introduce un método sistemático para analizar relaciones entre diferentes elementos dimensionales de los mismos objetos. El modelo dimensional se prueba con dos conjuntos de datos. El modelo de representación utilizado es el Modelo Espacial Simplificado [37] debido a su representación explı́cita de los objetos, el uso de un número mı́nimo de elementos (nodos y caras solamente) y los resultados satisfactorios de los tests realizados con grandes modelos 3D. Puesto que el objetivo de ese trabajo es proporcionar un marco de referencia para resolver consultas topológicas y geométricas relativas al catastro 3D, se evita la inclusión de caracterı́sticas relacionadas con la semántica de los interiores más allá de unidades catastrales 3D, edificios o tuberı́as. La representación de modelos de interiores de edificios utilizando un esquema de cuatro niveles de detalle es la propuesta de Hagedorn y otros [16]. Aunque este esquema guarda algunas similaridades con CityGML, se diferencia en que incluye información necesaria para calcular rutas. Además de los niveles de detalle, en este modelo hay tres componentes adicionales: el modelo temático, el modelo geométrico (basado en GML) y el modelo de rutas, que contiene puntos de conexión entre espacios adyacentes (Figura 4). Por tanto, los tres niveles de abstracción (geométrico, semántico y topológico) se relacionan en ese trabajo. van Treeck y Rank [31] utilizan una aproximación basada en la teorı́a de grafos para representar datos geométricos, topológicos y semánticos de un modelo de producción de edificio (BPM). Usan estructuras de datos con varios niveles de detalle; ası́, la representación geométrica de paredes, ventanas, puertas, columnas, 174 B. Domı́nguez, Á.L. Garcı́a y F.R. Feito Fig. 4 Figura tomada de [16]. Modelos temático y de rutas según el trabajo de Hagedorn y otros etcétera se hace con modelos B-Rep, mientras que la representación topológica parte de una estructura radial de lados [33] que representa relaciones entre vértices, lados, co-lados, ciclos, caras y cuerpos. De los datos almacenados en las estructuras descritas se derivan cuatro grafos distintos: el grafo estructural de componentes, el grafo de caras de habitaciones, el grafo relacional de objetos y el grafo de habitaciones (Figura 5). Por último, van Treeck y Rank proporcionan Fig. 5 Figura tomada de [31]. Modelos de grafos definidos por van Treeck y otros. De izquierda a derecha: grafo estructural de componentes, grafo de caras de habitaciones, grafo relacional de objetos y grafo de habitaciones métodos para hacer corresponder los grafos entre sı́ y obtener alguna información semántica sobre paredes, volúmenes (habitaciones) o losas. Otro trabajo interesante es el de Borrmann y Rank [5], en el que se propone un conjunto de operadores espaciales para calcular la posición relativa entre las cajas englobantes de dos objetos en el espacio 3D que representan edificios o partes de ellos. El conjunto de posiciones relativas tiene seis elementos, dos por cada eje coordenado, denominados encima, debajo, alEsteDe, alOesteDe, alNorteDe y alSurDe. Presentan dos aproximaciones para el cálculo de la posición: 1. El modelo basado en proyecciones, en el que un objeto se compara con la extrusión de otro objeto. En este caso, se introduce la estructura de datos denominada slot-tree para acelerar los cálculos. Estudio sobre la representación semántica y topológica de interiores de edificios 175 2. El modelo basado en semiespacios, en el que el primer objeto (la referencia) determina dos semiespacios, y se comprueba cuál de dichos semiespacios ocupa el segundo (el objetivo). Borrmann y Rank utilizan conjuntos sintéticos de objetos espaciales 3D representando los peores casos posibles para demostrar la eficiencia del sistema de consultas que presentan. Por otra parte, el almacenamiento de datos topológicos y semánticos está fuera de los objetivos de ese trabajo. Isikdag y otros [19] hacen hincapié en la falta de información semántica y relaciones espaciales en los modelos CAD, ası́ como en la ineficiente representación de la geometrı́a 3D en modelos geoespaciales, como motivos que dificultan la conversión entre modelos BIM y geoespaciales. Proponen escenarios de casos de uso para la implementación de BIMs en entornos geoespaciales, ası́ como el Modelo de Datos de Salida5 , que incluye clases para elementos semánticos y estructurales como paredes, columnas, plantas y aberturas. El problema de la representación de modelos CAD no variedad utilizando una estructura de datos denominada Semilado Dual6 es tratado en el trabajo de Boguslawski y Gold [4]. Esta estructura consta de, por una parte, una red de semilados que forman sólidos, de forma que para cada semilado se guardan una serie de punteros a semilados y caras adyacentes; por otra parte, se mantiene una estructura dual de sólidos conectados. En su artı́culo muestran los resultados de la aplicación de varios operadores de Euler en modelos de edificios reales representados con esta estructura. La representación presentada en este trabajo tiene una fuerte relación entre la geometrı́a y la topologı́a, pero conceptos relacionados con elementos de alto nivel semántico, como habitaciones, plantas, etcétera, parecen estar fuera de los objetivos de su trabajo. Un ejemplo de la aplicación de los BIM al diseño de videojuegos con modelos de interiores es el trabajo de Yan y otros [12]. En ese trabajo se propone una arquitectura consistente en tres módulos: BIM, intercambio y juego. El módulo BIM guarda la información sobre los edificios, mientras que el módulo de intercambio se encarga de gestionar el flujo de información entre el módulo BIM y el de juego. Para llevar a cabo esta tarea, en el módulo de intercambio se define un grafo de alto nivel con información semántica detallada, en el que cada nodo representa una habitación y cada lado representa una puerta entre habitaciones (Figura 6). Puesto que el sistema tiene módulos bien diferenciados, el de intercambio se puede sustituir por otro que se ajuste mejor al BIM con el que se trabaje en cada momento. Finalmente, Xu y otros [34] proponen un modelo que incluye aspectos geométricos, semánticos y topológicos de modelos 3D urbanos. Para conseguir esto, enriquecen los modelos urbanos 3D con un módulo temático que contiene información semántica y topológica; luego, los elementos de dicho módulo se hacen corresponder con los del modelo geométrico, manteniendo ası́ la coherencia en5 6 Output Data Model Dual Half-Edge 176 B. Domı́nguez, Á.L. Garcı́a y F.R. Feito Fig. 6 Figura tomada de [12]. Grafo de conectividad de habitaciones, de acuerdo con el trabajo de Yan y otros tre geometrı́a y semántica. Además, este trabajo también introduce una herramienta semiautomática para la integración del contenido semántico en el modelo geométrico. Los autores de este trabajo muestran como ejemplo de gestión de la información topológica con este modelo la construcción de una red topológica y una red geométrica. La primera de ellas representa las relaciones de adyacencia, conectividad y jerarquı́a, mientras que la segunda se utiliza como base para la red topológica. Estudio sobre la representación semántica y topológica de interiores de edificios 6. 177 Análisis comparativo y discusión En las secciones anteriores se ha presentado una serie de referencias sobre la representación de modelos de interiores de edificios, clasificándolos según la dimensionalidad de los datos y haciendo pequeñas reseñas de cada uno, haciendo hincapié en la topologı́a, la geometrı́a y la semántica. Ahora se propondrá un modelo que trata de enlazar estos tres aspectos, para posteriormente compararlo con los modelos revisados y plantear una reflexión sobre la aplicabilidad a diferentes áreas. 6.1. Nueva propuesta: una arquitectura de tres módulos El objetivo es plantear un sistema para la representación de interiores de edificios que cumpla con los siguientes requerimientos: 1. El sistema debe almacenar distintas vistas del mismo modelo, desde la geometrı́a de bajo nivel presente en los diseños arquitectónicos, a la semántica de alto nivel relativa a la distribución estructural y la conectividad entre espacios fı́sicos (adyacencia entre habitaciones, entre una habitación y el exterior del edificio, etcétera). 2. Toda la información almacenada debe estar relacionada a través de las distintas vistas de forma eficiente. 3. Debe ser sencillo generar modelos basados en otras representaciones a partir de la información almacenada en las vistas. Para cumplir con estos requerimientos, se plantea un sistema estructurado en tres módulos que almacenan datos sobre los planos CAD y la estructura topológica de los interiores de los edificios (Figura 7). El primer módulo representa los datos de entrada al sistema, y contiene los planos arquitectónicos CAD de las plantas. Estos planos pueden contener información sobre estructura, mobiliario, fontanerı́a, electricidad, etcétera, junto con otros datos como medidas o anotaciones. Debido a la gran variedad de posibles modelos representables en un plano CAD de una planta, se propone una serie de restricciones en el rango de datos de entrada. El segundo módulo contiene información relevante para representar la estructura del interior de un edificio (paredes, intersecciones entre paredes y aberturas), obtenida como el resultado de procesar de manera semiautomática los elementos geométricos básicos (lı́neas y bloques) contenidos en el primer módulo. El tercer módulo contiene un grafo de topologı́a, derivado de las paredes y aberturas detectadas, de forma que su grafo dual representa la subdivisión de la planta en espacios cerrados (habitaciones). Esta estructura en habitaciones reúne la información semántica, estructural (grafo de topologı́a) y geométrica (dibujo de paredes). Se han realizado pruebas con una versión preliminar de este sistema, obteniendo resultados prometedores a partir de planos CAD de plantas de edificios reales: 178 B. Domı́nguez, Á.L. Garcı́a y F.R. Feito Fig. 7 Arquitectura de tres módulos para la representación de modelos de edificios Los planos CAD han sido procesados de manera semiautomática para detectar caracterı́sticas semánticas y topológicas como paredes y habitaciones (incluyendo sus contornos internos y externos). La información geométrica de los planos CAD se ha enlazado con la información semántica obtenida semiautomáticamente. Se han implementado módulos que permiten la exportación de los modelos generados a formatos estándar como CityGML y COLLADA. 6.2. Análisis comparativo En la Tabla 1 se presenta el resumen con las caracterı́sticas principales de los trabajos revisados. También se incluyen a continuación algunas consideraciones relacionadas con la geometrı́a, conectividad y adyacencia topológica y semántica que se han tenido en cuenta a la hora de elaborar este estudio. Geometrı́a La mayorı́a de los artı́culos revisados basan sus modelos en la información geométrica. Sin embargo, no todos tratan esta información con la misma profundidad. Se distinguen las siguientes categorı́as: 1. Trabajos que no mencionan nada acerca de la geometrı́a, porque sólo se centran en la semántica. En la Tabla 1 aparecen marcados con un guión (-). Estudio sobre la representación semántica y topológica de interiores de edificios 179 2. Trabajos que mencionan elementos geométricos, pero sin dar detalles acerca de la representación subyacente, que aparecen en la Tabla 1 etiquetados con el texto implı́cita. 3. Los trabajos que en su representación incluyen vértices, lados, caras, regiones, celdas discretas, planos o volúmenes aparecen etiquetados con las siglas V, L, C, R, CD, P y Vo, respectivamente. 4. Por último, otros trabajos utilizan modelos de representación conocidos tales como IFC, CityGML, GML o BIM, y aparecen etiquetados apropiadamente en la Tabla. Topologı́a Siempre que sea posible, se distingue entre conectividad y adyacencia: Dos espacios en un modelo de un edificio están topológicamente conectados si existe una puerta o ventana entre ellos. Por tanto, los modelos que contienen información sobre aberturas mantienen conectividad topológica. la representación de conectividad es explı́cita si está representada en el modelo, o implı́cita si es posible deducirla a partir de un análisis del modelo. Dos espacios en un modelo de edificio son topológicamente adyacentes si comparten al menos un elemento (dos habitaciones compartiendo una pared, por ejemplo). La adyacencia es explı́cita si el modelo contiene información sobre las relaciones entre los espacios, o implı́cita si es posible deducirla a partir de un análisis del modelo. Semántica En la Tabla 1 se especifica qué elementos semánticos considera cada trabajo utilizando las etiquetas H (habitaciones), A (aberturas), P (pasajes), C (cruces), Pl (plantas), E (etiquetas), Pa (paredes), As (ascensores), T (techos) y Pas (pasillos). 7. Conclusiones y trabajo futuro Se han analizado una serie de trabajos sobre la representación de modelos de interiores de edificios, y se han clasificado utilizando para ello un conjunto de criterios definidos previamente. Ası́, los trabajos se han agrupado según la dimensionalidad de los datos almacenados en modelos 2D, modelos 2.5D y modelos 3D. También se ha analizado la amplia variedad de modelos de edificios dependiendo de las caracterı́sticas geométricas, semánticas y topológicas de las representaciones. Como resultado de este análisis se desprenden las siguientes conclusiones: 180 B. Domı́nguez, Á.L. Garcı́a y F.R. Feito Tabla 1 Comparación entre los trabajos revisados Grupo Artı́culo Franz y otros [14] Lamarche y Donikian [21] Plümer y Gröger [28] Stoffel y otros [30] Modelos 2D Li y otros [24] Zhi y otros [36] Hahn y otros [17] Merrell y otros [25] Slingsby y Raper [29] Tutenel y otros [32] Modelos 2.5D Germer y Schwarz [15] Van Dongen [13] Choi y otros [9] Choi y Lee [8] Clemen y Gielsdorf [10] Van Berlo y Laat [1] Paul y Bradley [27] Billen y Zlatanova [2] Hagedorn y otros [16] Modelos 3D van Treeck y Rank [31] Borrmann y Rank [5] Isikdag y otros [19] Boguslawski y otros [4] Yan y otros [12] Xu y otros [34] Nueva propuesta Topologı́a Semántica Conectividad Adyacencia implı́cita explı́cita H, A implı́cita explı́cita P, C V, L implı́cita V, L, R explı́cita implı́cita H, A, Pl CD E V, L, R explı́cita implı́cita H, A implı́cita explı́cita implı́cita H, A, Pl implı́cita explı́cita implı́cita H, A implı́cita implı́cita Pa, As, A implı́cita H implı́cita H cubos Pa, T explı́cita implı́cita H, A, Pl, Pa R explı́cita explı́cita H, A, Pas V, L, C, P explı́cita explı́cita IFC, CityGML explı́cita implı́cita H, A, Pl, Pa V, L, C, Vo explı́cita explı́cita Pa, T V, L, C, Vo implı́cita explı́cita Edificios GML explı́cita explı́cita H, A, Pl, Pa B-Rep explı́cita explı́cita H, Pa VO Edificios implı́cita implı́cita implı́cita A, Pl, Pa V, L, C explı́cita BIM BIM BIM BIM C, Vo explı́cita explı́cita H, A, Pl, Pa, T V, L explı́cita explı́cita H, A, P, Pl, Pa, T Geometrı́a Leyenda: V=vértices, L=lados, C=caras, , R=regiones, CD=Celdas Discretas, P=planos, Vo=volúmenes, H=habitaciones, A=aberturas, P=pasajes, C=cruces Pl=plantas, E=etiquetas, Pa=paredes, As=Ascensores, T=techos, Pas=pasillos Debido a la gran variedad de modelos de representación para interiores de edificios y la gran variedad de campos de aplicación, es bastante complicado unificar modelos. Por tanto, se debe pensar en problemas concretos en lugar de plantear aproximaciones genéricas. En la mayorı́a de los trabajos revisados, los modelos de edificios no se generan de forma automática, independientemente del campo de aplicación (BIM, GIS, bases de datos espaciales o modelos a medida). Ası́ pues, sigue siendo necesaria la investigación para desarrollar algoritmos que permitan extraer información semántica de planos CAD de plantas [4, 5]. El uso de formalismos es recomendable, puesto que permite aprovechar técnicas ya desarrolladas, ampliamente probadas y cuya corrección ya está demostrada. Por ejemplo: si se consigue dar a la representación forma de grafo, se puede recurrir a todo el trabajo previo ya existente sobre grafos para obtener resultados válidos. Estudio sobre la representación semántica y topológica de interiores de edificios 181 Agradecimientos Este trabajo ha sido parcialmente subvencionado por la Junta de Andalucı́a, el Ministerio de Ciencia e Innovación y la Unión Europea (fondos FEDER) a través de los proyectos de investigación, P06-TIC-01403 y TIN2007-67474-C03. Referencias 1. van Berlo, L., de Laat, R.: Integration of BIM and GIS: The development of the CityGML GeoBIM extension. In: Proceedings of the 5th International 3D GeoInfo Conference (2010) 2. Billen, R., Zlatanova, S.: 3D spatial relationships model: a useful concept for 3D cadastre? Computers, Environment and Urban Systems 27(4), 411 – 425 (2003). DOI 10.1016/S01989715(02)00040-6 3. Bjork, B.C.: A conceptual model of spaces, space boundaries and enclosing structures. Automation in Construction 1(3), 193 – 214 (1992). DOI 10.1016/0926-5805(92)90013-A 4. Boguslawski, P., Gold, C.: Rapid modelling of complex building interiors. In: Proceedings of the 5th International 3D GeoInfo Conference (2010) 5. Borrmann, A., Rank, E.: Specification and implementation of directional operators in a 3D spatial query language for building information models. Adv. Eng. Inform. 23, 32–44 (2009). URL http://portal.acm.org/citation.cfm?id=1480239.1480267 6. BuildingSMART: IFC Technical Specifications. http://buildingsmart-tech.org 7. Cerovsek, T.: A review and outlook for a ’Building Information Model’(BIM): A multistandpoint framework for technological development. Advanced Engineering Informatics 25(2), 224–244 (2011) 8. Choi, J., Lee, J.: 3D geo-network for agent-based building evacuation simulation. In: J. Lee, S. Zlatanova (eds.) 3D Geo-Information Sciences, Lecture Notes in Geoinformation and Cartography, pp. 283–299. Springer Berlin Heidelberg (2009) 9. Choi, J.W., Kwon, D.Y., Hwang, J.E., Lertlakkhanakul, J.: Real-time management of spatial information of design: A space-based floor plan representation of buildings. Automation in Construction 16(4), 449–459 (2007) 10. Clemen, C., Frank, G.: Architectural indoor surveying. an information model for 3D data capture and adjustment. In: Proceedings of the American Congress on Surveying and Mapping (2008) 11. Domı́nguez, B., Garcı́a, A.L., Feito, F.R.: An Open Source Approach to Semiautomatic 3D Scene Generation for Interactive Indoor Navigation Environments. In: Proceedings of IV Ibero-American Symposium on Computer Graphics, pp. 131–138 (2009) 12. Domı́nguez, B., Garcı́a, A.L., Feito, F.R.: Detección semiautomática de paredes, habitaciones y escaleras a partir de planos arquitectónicos CAD. In: Proceedings of XX Congreso Español de Informática Gráfica, pp. 177–186 (2010) 13. van Dongen, J.: Interior mapping. In: CGI 2008 Conference Proceedings (2008) 14. Franz, G., Mallot, H.A., Wiener, J.M.: Graph-based models of space in architecture and cognitive science - a comparative analysis. In: Proceedings of the 17th International Conference on Systems Research, Informatics and Cybernetics (2005) 15. Germer, T., Schwarz, M.: Procedural arrangement of furniture for real-time walkthroughs. Computer Graphics Forum 28(8), 2068–2078 (2009) 16. Hagedorn, B., Trapp, M., Glander, T., Dollner, J.: Towards an indoor level-of-detail model for route visualization. In: Proceedings of the 2009 Tenth International Conference on Mobile Data Management: Systems, Services and Middleware, MDM ’09, pp. 692–697. IEEE Computer Society, Washington, DC, USA (2009). URL http://dx.doi.org/10.1109/MDM.2009.118 17. Hahn, E., Bose, P., Whitehead, A.: Persistent realtime building interior generation. In: Proceedings of the 2006 ACM SIGGRAPH Symposium on Videogames, Sandbox ’06, pp. 179–186. ACM, New York, NY, USA (2006). URL http://doi.acm.org/10.1145/1183316.1183342 18. Howard, R., Bjork, B.C.: Use of standards for CAD layers in building. Automation in Construction 16(3), 290 – 297 (2007). DOI 10.1016/j.autcon.2006.06.001 182 B. Domı́nguez, Á.L. Garcı́a y F.R. Feito 19. Isikdag, U., Underwood, J., Aouad, G.: An investigation into the applicability of building information models in geospatial environment in support of site selection and fire response management processes. Advanced Engineering Informatics 22(4), 504 – 519 (2008). DOI 10.1016/j.aei.2008.06.001. PLM Challenges 20. Kolbe, T.H.: CityGML: Exchange and storage of Virtual 3D City Models. Technische Universitaet Berlin. http://www.citygml.org 21. Lamarche, F., Donikian, S.: Crowd of virtual humans: a new approach for real time navigation in complex and structured environments. Computer Graphics Forum 23, 509–518 (2004) 22. Lee, D.: Medial axis transformation of a planar shape. IEEE Transactions on Pattern Analysis and Machine Intelligence 4(4), 363–369 (1982) 23. Lee, J.: 3D data model for representing topological relations of urban features. In: Proceedings of 21st ESRI International User Conference (2001) 24. Li, X., Claramunt, C., Ray, C.: A grid graph-based model for the analysis of 2D indoor spaces. Computers, Environment and Urban Systems 34(6), 532–540 (2010). DOI 10.1016/j.compenvurbsys.2010.07.006. GeoVisualization and the Digital City - Special issue of the International Cartographic Association Commission on GeoVisualization 25. Merrell, P., Schkufza, E., Koltun, V.: Computer-generated residential building layouts. ACM Transactions on Graphics 29(6), 181:1–181:12 (2010). URL http://doi.acm.org/10.1145/1882261.1866203 26. Open Geospatial Consortium: Geographic Markup Language. http://www.opengeospatial.org/standards/gml 27. Paul, N., Bradley, P.E.: Topological houses. In: Proceedings of the 16th International Conference of Computer Science and Mathematics in Architecture and Civil Engineering (2003) 28. Pluemer, L., Groeger, G.: Nested maps - a formal, provably correct object model for spatial aggregates. In: Proceedings of the 4th ACM International Workshop on Advances in Geographic Information Systems, GIS ’96, pp. 76–83. ACM, New York, NY, USA (1996). URL http://doi.acm.org/10.1145/258319.258340 29. Slingsby, A., Raper, J.: Navigable space in 3D city models for pedestrians (2007) 30. Stoffel, E.P., Lorenz, B., Ohlbach, H.: Towards a semantic spatial model for pedestrian indoor navigation. In: J.L. Hainaut, E. Rundensteiner, M. Kirchberg, M. Bertolotto, M. Brochhausen, Y.P. Chen, S. Cherfi, M. Doerr, H. Han, S. Hartmann, J. Parsons, G. Poels, C. Rolland, J. Trujillo, E. Yu, E. Zimányie (eds.) Advances in Conceptual Modeling. Foundations and Applications, pp. 328–337. Springer Berlin / Heidelberg (2007) 31. van Treeck, C., Rank, E.: Dimensional reduction of 3D building models using graph theory and its application in building energy simulation. Eng. with Comput. 23, 109–122 (2007). URL http://portal.acm.org/citation.cfm?id=1269827.1269833 32. Tutenel, T., Bidarra, R., Smelik, R.M., de Kraker, K.J.: Rule-based layout solving and its application to procedural interior generation. In: Proceedings of the CASA workshop on 3D advanced media in gaming and simulation (3AMIGAS) (2009) 33. Weiler, K.: The radial-edge structure: a topological representation for non-manifold geometric boundary modeling. Geometric Modeling for CAD Applications (1988) 34. Xu, W., Zhu, Q., Zhang, Y.: Semantic modeling approach of 3D city models and applications in visual exploration. International Journal of Virtual Reality 9(3), 67–74 (2010) 35. Yan, W., Culp, C., Graf, R.: Integrating BIM and gaming for real-time interactive architectural visualization. Automation in Construction 20(4), 446–458 (2011). URL http://dx.doi.org/10.1016/j.autcon.2010.11.013 36. Zhi, G., Lo, S., Fang, Z.: A graph-based algorithm for extracting units and loops from architectural floor plans for a building evacuation model. Computer-Aided Design 35(1), 1–14 (2003) 37. Zlatanova, S.: 3D GIS for urban development (2000) Mejora y ampliación de la cartografı́a urbana Ma Isabel Ramos Galán y José L. de la Cruz González Resumen La necesidad de la inclusión de la tercera dimensión sobre la cartografı́a catastral urbana de la ciudad de Jaén ha supuesto la introducción de campañas de toma de datos de campo. Estos trabajos han consistido en la mayor parte de los mismos en el desarrollo de varias nivelaciones geométricas mediante las cuales se han recorrido las principales calles de interés para el proyecto. En todo momento se ha llevado un control de la calidad geométrica de los datos tomados ası́ como de la precisión de los mismos. En parte del recorrido también se ha implementado otro método de observación de datos topográficos como es la poligonal mediante estación total. Este método ha permitido tanto la dotación de altitud a la vı́a recorrida como la densificación de información planimétrica. Es importante reseñar que se han tenido en cuenta los posibles cambios de escala al superponer los datos levantados sobre la cartografı́a preexistente. Estos valores han sido cuantificados y el resultado ha dado valores poco significativos con lo cual la superposición entre los elementos cartográficos levantados y preexistentes se ha podido llevar a cabo con éxito. 1. Introducción La cartografı́a disponible para el presente proyecto consiste en el plano catastral urbano de la ciudad de Jaén en formato DXF. Sobre dicha cartografı́a se puede identificar información planimétrica de calles, manzanas, parcelas y construcciones, no estando disponible, por tanto, la información de la altimetrı́a (Figura 1). Es en este aspecto en el que se ha trabajado en esta fase del proyecto. La inclusión de la tercera dimensión sobre la información planimétrica disponible ha supuesto la necesidad de incluir campañas de toma de datos de campo. El hecho de tener que recoger todas M.I. Ramos, J.L. de la Cruz Departamento de Ingenierı́a Cartográfica, Geodésica y Fotogrametrı́a. Universidad de Jaén e-mail: {miramos,jlcruz}@ujaen.es 183 Ma Isabel Ramos Galán y José L. de la Cruz González 184 las zonas representadas en la cartografı́a inicial suponı́a una oportunidad no sólo de incorporar la cota de las calles recorridas y edificios (objetivo principal) sino al mismo tiempo poder revisar, mejorar e incluso ampliar dicha cartografı́a urbana preexistente. Fig. 1 Detalle del plano catastral urbano de la ciudad de Jaén 2. Metodologı́a Los trabajos de toma de datos de campo se desarrollaron a través de una serie de campañas en las que se llevó a cabo un minucioso recorrido de las calles de la ciudad recabando información de detalle. Se midieron las alturas de los edificios y se tomó nota del número de plantas de cada uno de ellos. 2.1. Distanciometrı́a láser Para estas tareas se utilizó un distanciómetro láser de mano, concretamente el Leica Disto D5 [3]. El Leica DISTO D5 diseñado con múltiples funciones y caracterı́sticas para hacer más sencillas las mediciones, particularmente cuando se trabaja en exteriores como es nuestro caso. Una de las ventajas de este distanciómetro de Mejora y ampliación de la cartografı́a urbana 185 mano frente a otros más comunes es la incorporación de un visor digital con x4 de zoom que permite hacer punterı́as de precisión (Figura 2). También presenta un visor telescópico para distancias largas y sensor de inclinación de hasta 45o . El rango de medición es de 0,05 m hasta 200 m con una precisión de ±1,0 mm. Fig. 2 Distanciómetro de mano empleado. Detalle de la cámara zoom incorporada. Fuente: http://www.disto.es/D5/disto D5.php El distanciómetro adquirido permite medir la distancia comprendida desde el suelo hasta el vuelo de un edificio. Para ello se sitúa el distanciómetro al pie del edificio pegado a la pared y manteniéndolo lo más vertical posible y apuntando al vuelo se toma la distancia (Figura 3). En aquellos edificios desprovistos de vuelo basta situarse al pie del edificio y apuntar hacia la parte más elevada del mismo y al suelo, como se muestra en la (Figura 4). El instrumento mide las distancias ası́ como el ángulo comprendido entre ambas direcciones. La punterı́a realizada sobre la parte superior del edificio se puede refinar con el uso del visor digital con zoom que, como ya se ha explicado, presenta el distanciómetro. También se dotó de cota a árboles, mobiliario urbano, arquetas identificadas, etc... Con el mismo instrumento se midió la anchura de las calles ası́ como del acerado. 186 Ma Isabel Ramos Galán y José L. de la Cruz González Fig. 3 Esquema de medición de altura de edificios con vuelo mediante distanciómetro láser de mano en edificios Fig. 4 Esquema de medición de altura de edificios con vuelo mediante distanciómetro láser de mano en edificios Mejora y ampliación de la cartografı́a urbana 2.2. 187 Nivelación geométrica La orografı́a de las calles se midió con precisión realizando una nivelación geométrica con nivel electrónico. El método de nivelación geométrica [1] permite determinar la diferencia de altitud entre dos puntos observados mediante visuales horizontales dirigidas sobre sendas miras verticales (Figura 5). Fig. 5 Esquema de la medida de un desnivel mediante nivelación geométrica Para llevarla a cabo se empleará el nivel, siendo éste el método de nivelación más preciso existente. El procedimiento a seguir en la observación es el siguiente: Sean A y B dos puntos cuyo desnivel se quiere determinar, para ello se estaciona un nivel aproximadamente en el punto medio entre ambos y se anotan las lecturas mA y mB realizadas sobre las miras situadas en A y en B respectivamente, (Figura 5). El desnivel entre A y B se calcula a partir de la expresión: ∆ ZAB = mA − mB (1) Siendo la altitud del punto B respecto del punto A: ZB = ZA ± ∆ ZAB (2) Siempre que sea posible, el nivel ha de colocarse equidistante entre las dos miras, ya que de esta forma el posible error por falta de horizontalidad del eje de colimación del nivel afectará por igual a las lecturas realizadas sobre la mira de espaldas y de frente y la diferencia de lecturas erróneas coincidirá con la diferencia de lecturas correctas, eliminándose este error en la observación. Asimismo, la corrección conjunta de esfericidad y refracción, al tener el mismo valor y el mismo signo en ambos casos, se eliminará. Cuando los puntos A y B entre los cuales ha de determinarse el desnivel están separados una distancia considerable o no son visibles entre sı́, será necesario estacionar más de una vez el nivel y observar la nivelación por 188 Ma Isabel Ramos Galán y José L. de la Cruz González tramos. En este caso, el desnivel total entre los puntos A y B extremos de la nivelación será la suma de los desniveles parciales calculados en los tramos intermedios (Figura 6). Fig. 6 Esquema de la medida de puntos intermedios en la nivelación geométrica Normalmente las lı́neas de nivelación tienen una longitud de varios kilómetros. En las lı́neas de nivelación sencillas sólo se tiene comprobación del resultado cuando se finaliza la nivelación. Si se comprueba, a posteriori en gabinete, que existe algún error en las medidas irremediablemente la solución pasa por volver a campo y repetir la toma de datos. Este inconveniente se evita, y al mismo tiempo se aumenta la precisión, efectuando las medidas por duplicado, es decir, haciendo lo que se llama una doble nivelación [1]. Para ello se divide el recorrido de la lı́nea en anillos (Figura 7), de tal modo que los extremos de éstos estén situados en superficies estables y que se encuentren perfectamente señalizados. Fig. 7 Esquema de un anillo y del encadenamiento de anillos En el caso de este proyecto se buscaron las confluencias de calles. A continuación, se efectúa la nivelación en un sentido: nivelación de ida, trabajando con el método del punto medio. Concluida la nivelación de ida, se inicia la de vuelta, debiendo ser paso obligado de las miras los extremos de los anillos. Hay dos tipos de lı́neas de nivelación doble: Abierta y Cerrada: Lı́neas de nivelación doble abiertas: son aquellas en las que partimos de un punto conocido y terminamos en otro punto conocido pero sin ser el mismo. Como datos de partida se dispone de las cotas o altitudes de los puntos inicial y final. Mejora y ampliación de la cartografı́a urbana 189 Lı́neas de nivelación cerradas: son aquellas en la que partimos de un punto conocido y terminamos en otro punto conocido que coincide con el de partida. Sólo se conoce la altitud del punto inicial. En gabinete hay dos etapas que tenemos que diferenciar: Control de los datos de campo • Control de los desniveles de los anillos • Control de la lı́nea de ida y de vuelta Cálculo de altitudes En este proyecto, la metodologı́a de trabajo empleada para la toma de datos de nivelación consistió en recorrer las calles a levantar fue lı́neas de nivelación cerradas en la confluencia entre calles. Se inició la medición utilizando como referencia de origen la cota del Instituto Geográfico Nacional (IGN) situada en la catedral. En la Figura 8 se muestra el recorrido que se hizo para la nivelación geométrica. A partir del punto origen se recorrió la calle Bernabé Soriano dividiendo posteriormente la nivelación en dos ramas; una transcurrirı́a por el Paseo de la Estación y la segunda hacia la Avenida de Madrid. Como ya se ha apuntado anteriormente para comprobar la corrección de los datos tomados se fueron cerrando los anillos en las calles intermedias. Finalmente, la nivelación que transcurrı́a por la Avenida de Madrid se unió con la del Paseo de la Estación a través de la calle transversal Calle Baeza siendo el punto exacto de unión el edificio del Gobierno Civil, tal y como se puede apreciar en la Figura 9. Fig. 8 Recorrido de la nivelación geométrica. Fuente: Google Earth [2] Ma Isabel Ramos Galán y José L. de la Cruz González 190 Fig. 9 Imagen de detalle de la unión de las dos lı́neas de nivelación geométrica. Fuente: Google Earth [2] Al no disponer de las alturas de los edificios en el plano catastral urbano en formato DXF disponible, al tiempo que transcurrı́a de la nivelación se fue dando cota en las esquinas de los edificios y, con la ayuda del distanciómetro de mano, se fue dando altura a dichas construcciones. 2.3. Poligonal El hecho de añadir información geométrica medida en campo a una cartografı́a preexistente, y sobre todo si se trata de recorridos lineales, supone el tener que calcular la posible deformación existente entre ambas escalas. En tal caso es preciso comprobar si se está produciendo tal efecto y en cuyo caso calcular su magnitud para poder corregirla y de ese modo poder integrar los nuevos elementos sobre la planimetrı́a preexistente. Para ello se arrancó una poligonal de precisión desde clavo NAP (Nivelación Alta Precisión) perteneciente al IGN en la escalinata de la catedral, llegando hasta el edificio que recoge las dependencias del Gobierno Civil. Se calcularon las deformaciones en la proyección en ese punto y se obtuvo que, a la escala que se estaba trabajando, las diferencias eran despreciables, por debajo de la precisión instrumental, de orden submilimétrico. Para actualizar la cartografı́a preexistente se aprovechó la poligonal de precisión para ir dando coordenadas a las vı́as mediante medidas con el distanciómetro de in- Mejora y ampliación de la cartografı́a urbana 191 frarojos de la Estación Total (instrumento empleado para la poligonal de precisión) ya que tenı́amos permiso de la alcaldesa del municipio para circular por la vı́a. Debido a conflictos burocráticos, el permiso para circular por la vı́a fue arrebatado a la altura de la Plaza de las Batallas, a la altura del Gobierno Civil, prohibiéndonos acercarnos al trazado viario. Ante este suceso se tomaron coordenadas infrarrojas en las zonas donde no estaban trabajando y ya, libres de material constructivo, se dieron coordenadas mediante distanciometrı́a láser al resto de la vı́a. El problema es que la distanciometrı́a láser aún no tiene comprobado los errores en los distintos tipos de material, ignorando por lo tanto los errores que este tipo de medida producirı́an pudiendo ası́ hacer algún quiebro anómalo la lı́nea levantada. No obstante, al realizar el encaje entre ambas cartografı́as, a actualizada y la preexistente, no se observó ningún tipo de quiebro. Para tener una idea orientativa de las cotas del resto de Jaén se optó por asignar cotas mediante navegadores GPS siempre saliendo de una cota de precisión que fue observada desde el Gobierno Civil encontrándose el punto más utilizado frente a la puerta del Restaurante-Hamburgueserı́a que se muestra en la Figura 10, en el mismo Paseo de la Estación. Para esta tarea y este trabajo se eligieron unas zonas de Jaén por ser representativas de la orografı́a del terreno. Fig. 10 Imagen detalle del recorrido. Fuente: Google Earth [2] En primer lugar se tomo por GPS toda la zona que se habı́a tomado por nivelación densificando los puntos por si al trabajo informático le hacı́a falta más densidad de datos bajando hasta el Restaurante-Hamburgueserı́a incluyendo la zona conocida Ma Isabel Ramos Galán y José L. de la Cruz González 192 como las Protegidas situadas entre la avenida de Madrid y el paseo de la Estación (Figura 10). En un segundo trabajo se optó por dar cotas a la parte baja, parte norte, del hospital y el barrio conocido como Peñamefecit. Saliendo de la cota obtenida situada en el Restaurante-Hamburgueserı́a (Figura 11). Fig. 11 Imagen detalle del recorrido. Fuente: Google Earth [2] En una tercera campaña se tomó toda la parte noreste de Jaén hasta llegar al cementerio antiguo enlazando los datos hasta llegar al cruce de la Avenida de Madrid con la Avenida de Ruiz Jiménez (Figura 12). Finalmente se planificó la observación de la franja del Paseo de la Estación Avenida de Madrid hasta llegar a la Plaza de Jaén por la Paz, tomando datos de la zona Av. de España, más conocida como el Bulevar, a ambos lados del parque de dicha zona y en el propio parque, pudiendo ası́ realizar un modelo 3D de una zona muy amplia de Jaén (Figura 13). 2.4. Resultado La última fase de este apartado del proyecto consistió en integrar los datos levantados con la cartografı́a preexistente. Para ello, y con el objeto de tratar la información espacial como datos 3D a los cuales se les pudiese adjuntar todo tipo Mejora y ampliación de la cartografı́a urbana Fig. 12 Imagen detalle del recorrido. Fuente: Google Earth [2] Fig. 13 Imagen detalle del recorrido. Fuente: Google Earth [2] 193 194 Ma Isabel Ramos Galán y José L. de la Cruz González de información temática, se integraron ambos conjuntos de datos (preexistentes y observados) en un software GIS; en este caso, MapInfo Profesional [4] (Figura 14). Fig. 14 Cartografı́a catastral urbana de la ciudad de Jaén integrada en el software GIS MapInfo Professional Referencias 1. Domı́nguez Garcı́a-Tejero, F. Topografı́a General y Aplicada. Ediciones Mundi-Prensa. ISBN: 8471147211. 1998 2. Google Inc. Google Earth 6.1.0.5001 http://earth.google.com 3. Leica Geosystems AG CH-9435 Heerbrugg. (Switzerland). http://http://www.leicageosystems.com 4. MapInfo Corporation, (eds.). MapInfo Professional v. 9.0. Reference Guide. New York. 2009 Bloque VI Interacción Estudio sobre técnicas de visualización y navegación de entornos virtuales en dispositivos móviles José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez Resumen En este capı́tulo ofrecemos una introducción al mundo de los dispositivos móviles y ahondamos en sus bondades y problemáticas. También proporcionamos unas consideraciones generales e identificamos los puntos en los que la computación móvil difiere de la computación habitual en ordenadores de escritorio. También repasamos las tecnologı́as más habituales que es posible encontrar dentro del mundo de los dispositivos móviles, asi como las plataformas existentes, sistemas operativos y estándares de desarrollo para gráficos tridimensionales. Los dispositivos móviles sufren unas severas restricciones en su potencia de cómputo y capacidad de almacenamiento. Estas restricciones han provocado que numerosos investigadores hayan desarrollado técnicas especı́ficas para la visualización interactiva de escenas 3D en estos dispositivos. Para terminar, se presentan las principales propuestas para la visualización de escenas 3D genéricas en dispositivos móviles existentes en la literatura. 1. Introduction En los últimos años, la aparición de la telefonı́a móvil ha supuesto un cambio social importante. Según la International Telecommunications Union, en 2008 habı́a 3.3 miles de millones de personas (la mitad de la población mundial) que empleaban dispositivos móviles [8]. Es más, podemos considerar al teléfono móvil como el dispositivo dotado de capacidades gráficas más extendido [1]. Aparte de lo anecdótico de los datos, es evidente que las posibilidades que se brindan ante esta situación son numerosas. Los primeros dispositivos móviles (terminales de telefonı́a móvil, agendas electrónicas portátiles o PDAs, etc.) no dejaban de ser aparatos diseñados para cumplir su función especı́fica, y sus prestaciones se limitaban a lo estrictamente necesario para cumplir dichas funciones. Sin embargo, la paulatina inclusión de nuevos servicios ha ido acompañada con un aumento espectacular en las prestaciones y funcionali- 197 198 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez dades de estos dispositivos. Incluso han surgido sistemas operativos diseñados especı́ficamente para los mismos, donde Symbian OS, iOS o Android son sólo algunos ejemplos. Hoy en dı́a puede afirmarse que los dispositivos móviles se han convertido en pequeños ordenadores personales con capacidad de procesamiento prácticamente similar a los ordenadores de hace diez años. No obstante, la forma de trabajar con los dispositivos móviles sigue difiriendo enormemente a la forma de trabajar con ordenadores personales. La computación móvil ofrece una serie de ventajas inéditas en otros entornos que han sido la razón de su éxito: 1. Ubicuidad. Puedes trasportarlos siempre contigo. 2. Conectividad. Están siempre conectados a una red de datos. 3. Localización. Pueden obtener su localización geográfica, por ejemplo, a través del sistema GPS. Permiten acceder a servicios basados en la posición del usuario. 4. Interfaz multimodal. Teclados, pantallas táctiles y multitáctiles, voz, acelerómetros. . . Su pequeño tamaño añade nuevas formas de interacción con el usuario. Por el contrario, los dispositivos móviles presentan una serie de inconvenientes que han de tenerse presentes a la hora de desarrollar software para ellos [2]. Su limitado tamaño restringe la complejidad que es posible imbuir al hardware. Y no menos importante, provoca graves limitaciones en la capacidad de disipar el calor y de obtener alimentación eléctrica. Entre otros inconvenientes de los dispositivos móviles, destacamos los siguientes: 1. Ahorro de baterı́a. Los dispositivos móviles requieren de una baterı́a para su funcionamiento. Las baterı́as son costosas y pesadas, por lo que la reducción del consumo energético es el factor que determina el diseño de los dispositivos móviles. Procesador, procesador gráfico, memoria, sistema operativo, etc. son diseñados anteponiendo la eficiencia energética al rendimiento. El software también debe diseñarse con este problema en mente. 2. Limitaciones del procesador. Debido a las razones anteriores, los procesadores existentes para dispositivos móviles suelen carecer de operaciones complejas. Ası́, por ejemplo, la familia de procesadores ARM9, presente aún en muchos dispositivos, carece de procesador de coma flotante (FPU). Además, las memorias cachés suelen estar muy limitadas. Todo ello hace que el rendimiento del sistema se ralentice. Con los procesadores gráficos, el problema es análogo. 3. Modelo de memoria limitado y escaso. A diferencia de los ordenadores convencionales en los que el procesador es capaz de direccionar un tamaño de memoria muy amplio (del orden de Gigabytes), en los dispositivos móviles la cantidad de memoria disponible es mucho más escasa. Además ésta debe compartirse con el resto de aplicaciones y datos del sistema. El uso de dispositivos de almacenamiento secundario (usualmente tarjetas extraı́bles de memoria flash no volátil) para segmentación y paginación de memoria virtual no es útil debido a los elevados tiempos de acceso que padecen. 4. Comunicaciones limitadas. El acceso a Internet desde dispositivos móviles requiere el uso de tecnologı́as inalámbricas tales como 2G y 3G. El ancho de banda Estudio sobre técnicas de visualización y navegación en dispositivos móviles 199 ofrecido por dichas conexiones es generalmente más estrecho que el ofrecido por una conexión cableada. Además, estas conexiones suelen ser costosas y tienen coberturas limitadas. Redes inalámbricas de área local, tal y como IEEE 802.11 son más rápidas y económicas, pero tienen un rango de alcance aún más limitado. 5. Interfaz de usuario. Las pantallas y teclados tienen a ser muy pequeños, lo cual dificulta su uso y la cantidad de información que pueden trasmitir. 6. Fragmentación. Las tecnologı́as móviles cambian constantemente. Esto, unido a las constantes luchas comerciales por parte de múltiples fabricantes para hacerse con el mercado, ha dado lugar a un gran número de plataformas, tecnologı́as y librerı́as, a menudo similares pero incompatibles entre sı́ [39]. A la vista de lo anterior, el desarrollo de software es especialmente complejo y, en cierto sentido, anacrónico. Algunos aspectos de la programación que habı́an sido superados gracias a las mejoras en el hardware son ahora rescatados del olvido. 2. Tecnologı́as Móviles Pese al auge de los dispositivos móviles y el rápido incremento de sus prestaciones, aún existı́a un gran inconveniente que impedı́a en cierto modo su eclosión como dispositivos de entretenimiento e información avanzada. La amplia difusión que la Informática Gráfica ha tenido en el campo de los ordenadores personales se ha debido en gran medida al abaratamiento e inclusión en los equipos de GPUs con gran capacidad de procesamiento. Hasta ahora esa posibilidad no estaba disponible en los dispositivos móviles. Sin embargo, los fabricantes de GPUs han sido conscientes de las amplias posibilidades que supone este mercado, diseñado hardware gráfico adaptado para su uso móvil. En [2] podemos leer una revisión sobre las caracterı́sticas de las GPUs para dispositivos móviles. Antes de la llegada este hardware gráfico de bajo consumo, no era posible visualizar gráficos 3D realistas de manera interactiva. Sus limitadas prestaciones y el uso de librerı́as de visualización por software solo permitı́an mostrar escenas triviales. Hasta hace pocos años, ni siquiera era posible visualizar un cubo con sombreado de Gouraud de forma interactiva. Aparte del hardware gráfico, otro factor determinante ha sido la importante mejora en la tecnologı́a empleada para las pantallas. Los primeros dispositivos móviles de consumo disponı́an de pantallas pequeñas (48 × 48 pı́xeles) y monocromáticas. Hoy en dı́a, los modelos más avanzados ofrecen 24 bits de color (16.7 millones de colores) y resoluciones VGA (640 × 480 pı́xeles) o WVGA (480 × 800 pı́xeles). A continuación se describen las múltiples tecnologı́as y librerı́as gráficas (APIs) que pueden emplearse en el desarrollo de aplicaciones con gráficos 3D para dispositivos móviles. Para ampliar información, puede consultarse [8]. La Sección 2.1 revisa las diferentes tecnologı́as y estándares gráficos existentes en el mercado de los dispositivos móviles. La Sección 2.1 ofrece una visión general de las distintas plataformas y sistemas operativos especializados que es habitual encontrar al trabajar con dispositivos móviles. 1971 ARP, first successfull commercial cellphone network, is launched in Finland. Generation 0G. It was not possible to move from cell to cell seamlessly. 1970 1982 Mobira Senator, Nokia first cellphone. 1980 1979 NTT, first 1G commercial cellphone network is launched in Japan. 1979 April 3, 1973. Motorola’s Dr. Martin Cooper made the first handheld cellular phone call in public. He called his rival Joel Engel at Bell Labs. 1973 1984 Psion launches Psion Organiser I, first pocket computer. Motorola DynaTAC 8000X, first commercial cellphone. Price: $3.995.. 1983 1991 Radiolinja, first GSM (2G) network , is launched in Finland. Psion launches EPOC16, a multitask operating system for mobile devices. 1989 Nintendo launches Game Boy, equipped with a green LCD screen. 1990 Sega launches Game Gear, equipped with a color LCD screen. 1990 Microsoft launches Pocket PC 2000 USA allows civilians to use the GPS system. US Robotics launches lau PalmPilot, Pil first PDA with Palm OS. wit 1996 Microsoft launches Windows CE 1.0. NTT DoCoMo, first 3G network, is launched in Japan. Nintendo launches Game Boy Advance. EDGE and GPRS networks (2.5G) are launched. Nokia launches N-Gage, hybrid phonevideoconsole. M3G 1.0 Nokia N93, first OpenGL ES 1.1 and M3G cellphone with 3D graphics hardware . 2006 KT launches the first commercial WiMAX network in Seoul. 2010 Apple launches iPhone 3GS and iTouch 3rd generation, with OpenGL ES 2.0. 2009 Nintendo announces Nintendo 3DS, with OpenGL ES 1.1 and 3D display. 2008 2010 HTC Dream, Apple first cellphone launches iPad, with Android with OpenGL and OpenGL ES 2.0 ES 1.0 RIM launches the first Blackberry OpenGL ES 1.1 OpenGL ES 2.0 cellphone. 2004 2007 2002 M3G 1.1 2005 Nokia 6630, first cellphone with OpenGL ES and M3G. Apple launches iPhone and PDA iTouch with iOS, OpenGL ES 1.1. Nintendo launches Nintendo DS. 2001 2003 J-Phone OpenGL ES 1.0 launches the first cellphones with a builtin 3D engine. 2000 Ericsson R380, firsh smartphone equipped with Symbian OS, an evolution of EPOC. 2000 IBM Simon, first cellphone with advanced features: agenda, email, fax... Price: $899. 1994 Nokia 3410, first cellphone outside Japan with a builtin 3D engine: NokiaGL API. Sony launches PSP. 200 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez Fig. 1 40 años de historia de gráficos en dispositivos móviles. Por último, en la Figura 1 mostramos una lı́nea de tiempo que refleja los mayores hitos ocurridos en la historia de los dispositivos móviles durante los últimos 40 Estudio sobre técnicas de visualización y navegación en dispositivos móviles 201 años. Se tienen en especial consideración los hechos relacionados con la Informática Gráfica. 2.1. Estándares Gráficos La inclusión de hardware gráfico de alto rendimiento en los dispositivos móviles no sirve de nada si no está acompañado de un conjunto de librerı́as y estándares especializados que permitan el desarrollo de software especı́fico que aproveche todo el potencial de dichos dispositivos. Las dos librerı́as gráficas más extendidas que permiten sacar partido al hardware gráfico de los dispositivos móviles son OpenGL ES y M3G [39]. La primera generalmente se emplea con el lenguaje de programación C o C++, mientras que la segunda ha sido diseñada para su uso desde Java Mobile Edition (JME). OpenGL ES [23] es un subconjunto de la librerı́a gráfica OpenGL, especı́ficamente diseñada para dispositivos integrados. Entre éstos, se encuentran teléfonos móviles, agendas digitales personales (PDAs) y videoconsolas. Consiste en un subconjunto bien definido de OpenGL. Ofrece una interfaz flexible potente y de bajo nivel que abstrae al software del hardware gráfico subyacente. Es libre de royalties e independiente de la plataforma. OpenGL ES incluye perfiles de compilación para sistemas de punto fijo y para sistemas de punto flotante, ası́ como la especificación EGL que permite el enlazado de sus aplicaciones en sistemas de ventanas. Actualmente se han desarrollado dos versiones de OpenGL ES. Para una comparación entre sı́, véase [9, 38]. A continuación resumimos las caraterı́sticas más importantes de ambas: OpenGL ES 1.x ha sido diseñado a partir de la especificación OpenGL 1.5, y ofrece operaciones aceleradas, alta calidad de imagen y elevado rendimiento, asegurando además un consumo de baterı́a reducido. Permite su uso tanto en dispositivos que disponen de hardware acelerador 3D, como en dispositivos que realizan la visualización enteramente por software. No permite la programación de la GPU. OpenGL ES 2.X [31] ha sido diseñado especı́ficamente para dispositivos dotados de hardware gráfico programable. La principal novedad frente a OpenGL ES 1.x reside en que OpenGL ES 2.0 elimina toda la funcionalidad ofrecida por el proceso gráfico fijo de la GPU. Esto fuerza al desarrollador a escribir programas de vértices y de fragmentos. OpenGL ES es la librerı́a para gráficos 3D oficial en Symbian OS, la plataforma Android, iOS, Nintendo 3DS y PlayStation 3, entre otros. M3G (JSR-184) [18], por otro lado, es una librerı́a de alto nivel y orientada a objetos para Java Mobile Edition (JME). Ha sido diseñada para implementarse sobre OpenGL ES 1.0. De esta forma, OpenGL ES proporciona a M3G toda la funcionalidad de bajo nivel (tal y como transformaciones, iluminación, rasterización, etc.), 202 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez mientras que M3G ofrece caracterı́sticas avanzadas como grafos de escena y animación. Su función es ofrecer una interfaz para Java estandarizada y de mayor nivel que OpenGL ES. Ası́, OpenGL ES proporciona máxima eficiencia y flexibilidad para el desarrollo de aplicaciones nativas. M3G, por otro lado, añade las caracterı́sticas necesarias para un desarrollo eficiente sobre Java. La especificación 2.0 de M3G (JSR-297) [20], aún en desarrollo, se construirá sobre OpenGL ES 1.1 ó 2.0, y permitirá opcionalmente el uso de GPU programable. También existe la posibilidad de realizar directamente llamadas a la librerı́a OpenGL ES desde Java a través de la librerı́a Java Bindings para OpenGL ES (JSR239) [19]. Esta especificación define un paquete opcional para JME que ofrece una interfaz estándar para Java muy similar a la librerı́a original para C de OpenGL ES. No obstante, esta especificación no goza de mucho apoyo por parte de la industria, y la mayorı́a de los dispositivos móviles con hardware 3D no la incluyen. El sistema operativo es el software encargado de proporcionar a las aplicaciones servicios tales como gestión de procesos e hilos, gestión de memoria, acceso a ficheros y redes, etc. También se encarga de gestionar la interfaz de usuario. Debido a sus limitaciones, los dispositivos móviles requieren de sistemas operativos especı́ficos y adaptados a sus posibilidades. En esta sección describimos algunos de los sistemas operativos y plataformas móviles más destacadas. La lista no es exhaustiva, pues su objetivo es ofrecer al lector una imagen general del mercado y del potencial gráfico de las distintas plataformas. 2.1.1. Windows Mobile Windows Mobile [29] es un sistema operativo para dispositivos móviles basado en la interfaz Win32 de Microsoft. Está diseñada para su uso en Pocket PCs, Smartphones y Portable Media Centers. A dı́a de hoy, los dispositivos basados en Windows Mobile y dotados con hardware gráfico 3D son muy escasos. Entre éstos, los modelos más populares son las PDAs Dell Axim X50v y X51v, equipadas con una GPU Intel 2700G. Estos modelos han sido ampliamente utilizados en el ámbito cientı́fico. Estos dispositivos pueden programarse mediante la librerı́a gráfica especı́fica de Microsoft, Direct3D Mobile, si bien los fabricantes suelen proporcionar controladores para OpenGL ES. La versión de OpenGL ES disponible para las PDAs Dell Axim es la 1.0. En 2010, Microsoft presentó Windows Phone 7, su nueva plataforma móvil, con el objetivo de reemplazar a Windows Mobile. Todos aquellos dispositivos móviles que quieran incluir Windows Phone deben satisfacer una serie de requisitos impuestos por Microsoft, entre los que se encuentra la aceleración gráfica por hardware [42]. Al contrario que la mayorı́a de plataformas móviles, Windows Phone 7 no soporta OpenGL ES. En su lugar, es preciso emplear una librerı́a especı́fica de Microsoft. Estudio sobre técnicas de visualización y navegación en dispositivos móviles 2.1.2. 203 Android Android [28] es una plataforma software y un sistema operativo para teléfonos móviles basada en el núcleo de Linux. Ha sido desarrollado por Google. Sólo se permite el desarrollo de software en el lenguaje Java de forma inmediata, que se ejecuta dentro de una máquina virtual. No obstante, no soporta las librerı́as estándar de JME, sino que debe emplearse una librerı́a especı́fica desarrollada por Google. Por tanto, una aplicación para Android no podrá adaptarse a otro dispositivo con JME salvo realizando grandes cambios. Sin embargo, es posible desarrollar software de forma nativa en C++ mediante el NDK de Android, que permite acceso a todos los recursos del sistema a bajo nivel. Como contrapartida, el programa debe ir compilado para todas las posibles CPUs que puedan ejecutar Android para conseguir una portabilidad efectiva. En términos gráficos, Android soporta la tanto OpenGL ES 1.0 como OpenGL ES 2.0 a través de una especificación propietaria similar (pero no igual) a JME Java Bindings para OpenGL ES. 2.1.3. iOS iOS [32] es un sistema operativo diseñado por Apple Inc. y basado en una variante del núcleo Mach del sistema operativo Mac OS X. Es empleado por el teléfono móvil iPhone, y por los dispositivos portátiles iTouch e iPad. El modelo iPhone 3G incorpora una GPU modelo PowerVR MBX, y soporta la especificación 1.1 de OpenGL ES. En cambio, modelos más recientes como el iPhone 3GS, el iPhone 4 o el iPad incorporan GPUs de la serie PowerVR SGX, que cumplen la especificación 2.0 de OpenGL ES. Apple proporciona su propio entorno de desarrollo para crear aplicaciones destinadas a iOS, denominado Cocoa. El lenguaje de programación habitual en esta plataforma es el Objective-C. Este lenguaje es un superconjunto de C, el cual ha sido extendido mediante ciertos elementos sintácticos y semánticos para permitir el desarrollo dirigido a objetos. Todas las llamadas a la librerı́a nativa del sistema deben de realizarse desde el lenguaje Objective-C, propiedad de Apple, lo cual dificulta la elaboración de software fácilmente transportable a distintos dispositivos. No obstante, se permite que código escrito en ANSI C y C++ pueda entremezclarse y enlazarse libremente con código Objective-C dentro del mismo ejecutable. Por tanto, si se aı́slan las partes de código que deban acceder a la librerı́a nativa del sistema, es posible transportar código C++ con OpenGL ES existente al iPhone. 2.1.4. Symbian OS S60 Symbian OS [5] es un sistema operativo diseñado especı́ficamente para teléfonos móviles y otros dispositivos con recursos limitados. Existen en el mercado algunos 204 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez teléfonos con Symbian OS y dotados de aceleración 3D por hardware. Por ejemplo, los Nokia N93 y N95, que incluyen una GPU PowerVR MBX. Estos dispositivos pueden programarse tanto con M3G (desde JME) como con OpenGL ES (desde C++). La especificación de OpenGL ES soportada es la 1.1. 2.1.5. Videoconsolas Portátiles Nintendo 3DS es una videoconsola portátil fabricada por Nintendo y anunciada a finales de 2010, con fecha de lanzamiento en 2011. Está equipada con una GPU DMP Pica200, y soporta la especificación de OpenGL ES 1.1. Este dispositivo demuestra que a las GPUs móviles no programables aún le quedan largos años de vida. Pese a que diversos y costosos teléfonos móviles de alta gama incluyen GPUs con proceso gráfico programable (compatibles con OpenGL ES 2.0), dispositivos de ocio electrónico de bajo coste siguen implementando OpenGL ES 1.1. PSP NGP es otra videoconsola portátil fabricada por Sony y anunciada en Enero de 2011. Al contrario que el dispositivo anterior, esta videoconsola incorpora una GPU PowerVR de la serie SGX compatible con OpenGL ES 2.0. 2.2. Redes Celulares Las redes de telefonı́a móvil están basadas en una red de celdas, donde cada celda dispone de un transmisor conocido como estación base. La capa de comunicación de las redes celulares pueden emplear diversas tecnologı́as, tales como General Packet Radio System (GPRS), su mejora Enhanced Data rates for GSM Evolution (EDGE). La generación de tecnologı́as de telefonı́a móvil formada por GPRS y EDGE se le conoce como telefonı́a móvil “2G” o de segunda generación. A EDGE también se le conoce como “2.5G” Más recientemente ha aparecido la tecnologı́a de red Universal Mobile Telecommunication System (UMTS) y su mejora High-Speed Downlink Packet Access (HSDPA). De forma análoga, a la generación de tecnologı́as que comprende a ambas se la denomina “3G” o de tercera generación, y HSDPA en particular también se le denomina “3.5G”. 3. Visualización 3D en Dispositivos Móviles En esta sección, repasaremos el estado del arte en el campo de la visualización de escenas genéricas tridimensionales en dispositivos móviles. No nos adentraremos a discutir aplicaciones especı́ficas, videojuegos ni herramientas de desarrollo, que escapan del ámbito de este trabajo. La navegación interactiva a través de mundos 3D complejos requiere la habilidad de poder visualizar la escena a un número de imágenes por segundo aceptable, Estudio sobre técnicas de visualización y navegación en dispositivos móviles 205 mientras se mantiene la calidad de la escena lo más alto posible. A lo largo de los años, se han propuesto diversas técnicas para acelerar la visualización de escenas y objetos complejos en dispositivos móviles. Los métodos de visualización local expuestos en la Sección 3.1 asumen que el modelo a visualizar cabe completamente en la memoria del dispositivo móvil. No obstante, debido a que es habitual que los dispositivos móviles se encuentren conectados a una red, es viable el uso de técnicas de visualización en las que el modelo 3D esté almacenado en un servidor remoto. En general, podemos clasificar los métodos de visualización cliente-servidor en tres grandes categorı́as, en función de dónde se realiza la tarea de visualización de geometrı́a, [27]: Métodos de visualización en el lado del servidor, en los que todas las tareas de visualización recaen en un servidor gráfico remoto. Métodos de visualización en el lado del cliente, en los que la visualización recaen en el lado del cliente. Métodos de visualización hı́bridos, en los que cliente y servidor se reparten las tareas encaminadas a la visualización de la escena. 3.1. Visualización Local Las técnicas de visualización local almacenan toda la escena a visualizar en el propio dispositivo. No necesitan mantener conexión con ningún servidor remoto. Son más simples de implementar y la experiencia del usuario no se ve mermada por congestión o cortes de red. No obstante, el tamaño de la escena a representar queda limitado por el tamaño de la memoria del dispositivo. Este tipo de métodos son habitualmente empleados en videojuegos. En la literatura cientı́fica, la mayorı́a de los trabajos propuestos para dispositivos móviles tratan de buscar estrategias más eficientes de dibujar una escena que la simple visualización directa. No obstante, estas técnicas siguen limitadas por la capacidad de cómputo y de almacenamiento de los dispositivos móviles. En dispositivos móviles que carezcan de hardware acelerador 3D, la transformación y dibujado de primitivas geométricas puede suponer una gran carga de cómputo a la CPU. Esto supone un derroche importante si la mayorı́a de los triángulos de la escena cubren menos de un pı́xel de la pantalla. Algunos autores [13, 14] proponen simplificar la visualización mediante el dibujado de puntos en lugar de triángulos. Estas técnicas de visualización basadas en puntos aproximan geometrı́as complejas mediante un conjunto de puntos situados sobre la superficie de los objetos. El número de puntos a dibujar depende de la complejidad de los objetos y del tamaño de la pantalla. Duguet y Drettakis [13] avanzan en esta lı́nea, y proponen generar conjuntos estructurados de puntos mediante el uso de una jerarquı́a de volúmenes envolventes. Esta técnica permite ajustar el nivel de detalle en función de los requerimientos de velocidad y de la pantalla. También resultan más eficientes en memoria puesto que no se requiere tener todo el modelo simultáneamente en memoria. 206 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez No obstante, con la creciente inclusión de GPUs en los dispositivos móviles de gama alta, estas técnicas basadas en visualización de puntos carecen de utilidad, puesto que el dibujado y transformación de los triángulos recae sobre la GPU. Huang et al. [16] propone otra técnica para simplificar la visualización en dispositivos móviles basada en la visualización expresiva o no fotorrealı́stica. Su trabajo expone cómo superar las limitaciones del dispositivo móvil empleado (PDA Dell Axim x51v) para conseguir diversos efectos interactivos. Estos efectos son interesantes para herramientas de diseño asistido por ordenador (CAD). Entre otros, se incluyen extracción de siluetas, visualización del interior del modelo mediante cortes, inclusión de anotaciones, etc. Yang et al. [48] propone otra aplicación de CAD orientada a su uso en dispositivos móviles. Su trabajo se centra en describir un algoritmo compacto de triangulación basado en la triangulación secuencial y restringida de Delaunay. Mediante este algoritmo, un dispositivo móvil es capaz de calcular la malla de triángulos que aproxima a las entidades geométricas almacenadas en un fichero STEP (STandard for Exchange of Product model data), usualmente piezas mecánicas. Una vez calculada la triangulación, se procede a su dibujado mediante OpenGL ES. La ubicuidad de los dispositivos móviles ha animado a muchos investigadores y empresas privadas a desarrollar aplicaciones de navegación tridimensional en entornos urbanos. Los primeros acercamientos, tal y como 3DCityInfo [41] o LAMP3D [7] empleaban el visor de VRML Cortona, desarrollado por ParallelGraphics. Obtenı́an, en el mejor de los casos, velocidades de 5 animaciones por segundo. Posteriormente, NaviTime [4] aplicó comercialmente esta idea con éxito en la ciudad de Tokio. En [36] podemos encontrar un análisis de trabajos sobre visualización urbana en 3D para dispositivos móviles. La ubicuidad de estos dispositivos también puede aprovecharse en el interior de los edificios. Silva et al. [45] emplea un octree para clasificar espacialmente escenas de interiores. Ası́, es posible descartar partes ocultas de la escena y acelerar la visualización. Afirman obtener velocidades interactivas (30 animaciones por segundo) en un teléfono con GPU, Nokia N82, en la visualización de una escena de interior con 6191 triángulos sin texturas. Por último, la visualización de volúmenes en dispositivos móviles es un tema muy poco explorado en la literatura. En ordenadores personales suelen aplicarse dos tipos de técnicas, ambas basadas en texturas: Empleo de tres conjuntos de lonchas bidimensionales alineadas con los ejes [43]. Empleo de una textura tridimensional [11]. En dispositivos móviles, el soporte de texturas tridimensionales se ofrece mediante una extensión opcional de OpenGL ES 2.0, poco implementada por los fabricantes. Para solventar esta ausencia, Moser et al. [30] emplea la técnica de las lonchas bidimensional en un dispositivo Dell Axim x51v, dotado de hardware acelerador 3D. Los autores afirman visualizar un modelo volumétrico de resolución 633 vóxeles a una velocidad de 1.5 imágenes por segundo en una pantalla de resolución 640 × 480 pı́xeles. Para aumentar la velocidad, los autores proponen reducir el número de fragmentos a procesar por la GPU. A tal fin, reducen la resolución Estudio sobre técnicas de visualización y navegación en dispositivos móviles 207 de la imagen a dibujar y posteriormente la escalan hasta que ocupe toda la pantalla del dispositivo. Limitando la resolución a 128 × 128 pı́xeles, afirman conseguir una velocidad de 9.9 animaciones por segundo. 3.2. Visualización en el Lado del Servidor En los métodos en el lado del servidor, existe un servidor remoto que lleva a cabo la visualización de la escena 3D. La imagen o conjunto de imágenes resultantes son enviadas al cliente, quien solo debe mostrarlas en la pantalla. Debido a que el cliente se limita a visualizar imágenes pre-generadas, los requerimientos de computación en el lado del cliente son independientes de la complejidad de la escena. Por tanto, estos métodos resultan muy apropiados para visualizar modelos geométricamente complejos en dispositivos con muy poca capacidad de cómputo o de almacenamiento. No obstante, estas técnicas presentan una serie de problemas: 1. Interactividad. La capacidad de interactuar en tiempo real con la escena se ve reducida debido a la alta dependencia con la red. Las altas latencias inherentes de las redes inalámbricas pueden provocar fácilmente congestión de red y caı́da del rendimiento. 2. Escalabilidad. Se requiere de un servidor con gran capacidad de cómputo. Un incremento en el número de clientes conectados concurrentemente al servidor puede incrementar con facilidad los tiempos de respuesta del mismo. El problema de enviar imágenes a través de una red ha sido muy estudiado, y podemos encontrar numerosas propuestas en la literatura. Chang et al. y Bouatouch et al. [10, 22] propusieron técnicas de visualización remota basada en imágenes. El servidor proporciona una serie de imágenes (fotogramas clave) al cliente, y éste es capaz de calcular los fotogramas intermedios. Para ello, el servidor también proporciona el mapa de profundidad1 de cada imagen. Para calcular los fotogramas intermedios, es preciso aplicar a cada pı́xel de la última imagen recibida una traslación en función del desplazamiento de la cámara. El problema de estas técnicas es cómo situar la cámara para que no aparezcan agujeros en la imagen. Proporcionar una solución general a este problema es una tarea complicada. Por dicha razón, estas soluciones tienen un ámbito de aplicación muy restringido. [22] aplicó esta técnica para la visualización de escenas urbanas. Tanto Aranha et al. [3] como Jeong y Kaufman [21] han propuesto sistemas de visualización remotos en los que el servidor genera una secuencia de imágenes mediante trazado de rayos. Estas imágenes son comprimidas y enviadas al dispositivo cliente para su visualización. Aranha se limitó a experimentar con un PC que simulaba a un dispositivo móvil. Jeong y Kaufman, por otro lado emplearon una PDA 1 Es habitual denominar al mapa de profundidad por su nombre en inglés, z-buffer. 208 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez real para visualizar escenas médicas. Afirman conseguir una velocidad de 5 imágenes por segundo a través de una conexión inalámbrica de área local IEEE 802.11b con el servidor. Lamberti et al. [24] presentó un sistema completo de visualización remota basado en el envı́o de un flujo de vı́deo MPEG a través de la red. En el lado del servidor emplean un clúster de ordenadores dotados de hardware gráfico y capaces de repartirse las tareas de visualización entre sı́ mediante el uso de un software llamado Chromium [17]. Los autores afirman conseguir la visualización remota en una PDA a 30 imágenes por segundo y resolución de 240 × 240 en un clúster de 8 PCs. No obstante, los autores admiten que dicho clúster no es lo suficientemente potente como para generar simultáneamente dos flujos de vı́deo distintos para dos clientes. (por ejemplo, dos clientes que navegan por distintas partes de una misma escena). Wen et al. [47] propone una solución que combina el uso de una estructura multirresolución para la visualización de terrenos en un servidor, junto con su visualización remota en un cliente móvil mediante envı́o de vı́deo por red. Por desgracia, el artı́culo presenta una descripción muy superficial de la técnica, y no se ofrecen resultados de rendimiento en el cliente ni de uso de la red. Boukerche [6] y Pazzi [37] han presentado técnicas alternativas para la visualización remota basada en imágenes. Estos autores consiguen reducir el consumo de ancho de banda mediante el uso de técnicas de predicción de movimientos y de envı́o parcial y progresivo de imágenes panorámicas. No obstante, estas técnicas limitan severamente los movimientos del observador, y no se comportan bien en escenas dinámicas. 3.3. Visualización en el Lado del Cliente En los métodos en el lado del cliente, el cliente descarga la geometrı́a y las texturas de la escena desde un servidor remoto y realiza la visualización de forma local. Este tipo de técnicas no precisan que el servidor posea ningún tipo de capacidad gráfica, por lo que reducen la carga de trabajo del servidor. Como contrapartida, este tipo de técnicas son más exigentes con el cliente, que debe poseer la capacidad de cómputo y de almacenamiento suficientes como para poder trabajar con escenas de la calidad requerida. Los métodos de visualización en el lado del cliente son apropiados para aplicaciones en las que la interacción en tiempo real es primordial, siempre y cuando asumamos que el cliente posea la capacidad de almacenar y visualizar la escena correspondiente. El concepto de trasmisión de escenas 3D bajo demanda de acuerdo a la región de interés ha atraı́do un considerable interés cientı́fico. Schneider [44] y Teler [46] emplearon la idea de nivel de detalle para trasmitir datos de manera adaptativa en función de criterios tales como el ancho de banda y la capacidad de cómputo disponibles. No obstante, estos autores no trabajaron explı́citamente con dispositivos móviles. Estudio sobre técnicas de visualización y navegación en dispositivos móviles 209 En el caso de los dispositivos móviles, y comparado con la gran cantidad de literatura que versa sobre técnicas de visualización en el lado del servidor, la cantidad de trabajos publicados sobre métodos en el lado del cliente es reducida. En esta sección repasaremos los trabajos al respecto que han sido publicados que abordan especı́ficamente este problema en dispositivos móviles. Un ejemplo tı́pico de métodos de visualización 3D en el lado del cliente lo constituyen los sistemas de visualización y navegación sobre terrenos. Dado que los conjuntos de datos de terrenos empleados en este tipo de aplicaciones exceden con frecuencia el orden de gigabytes o terabytes, es fácil exceder el tamaño de la memoria de cualquier ordenador convencional. Este hecho ha motivado a numerosos investigadores a desarrollar técnicas cliente-servidor en las que el modelo de datos completo reside en un servidor remoto. La literatura al respecto es amplia Por otro lado, Lluch et al. [26, 25] presentó un sistema cliente-servidor para la visualización de modelos multirresolución en un cliente móvil. Para visualizar un modelo 3D, el cliente proporciona al servidor los parámetros de la vista. El servidor extrae una malla de triángulos que representa al modelo con el nivel de detalle deseado, y lo recorta según el volumen de visión. Esta malla simplificada se envı́a al cliente para su visualización. Cada vez que la vista cambia, el servidor extrae la geometrı́a de las nuevas partes visibles y las proporciona al cliente. El problema de esta técnica es la considerable latencia experimentada cuando la vista cambia y el modelo debe actualizarse. Esto limita el método a modelos de baja complejidad geométrica y a redes inalámbricas de área local. En [33, 34, 35], Nurminen describe su proyecto m-LOMA 3D Map. Se ofrece una solución completa cliente-servidor para la navegación virtual por entornos urbanos mediante dispositivos móviles. Un servidor aloja la geometrı́a y texturas de los edificios, y los trasmite de forma progresiva al cliente bajo demanda a través de una red inalámbrica. Para aumentar la eficiencia, se propone el uso de algoritmos de visibilidad. En una etapa de pre-procesamiento, la escena se divide en una rejilla tridimensional de bloques cúbicos. Entonces, para cada bloque se determina el conjunto de bloques potencialmente visibles. En tiempo de ejecución se emplea esta estructura para reducir el número de edificios a descargar y visualizar. 3.4. Visualización Hı́brida Los métodos hı́bridos persiguen repartir el cómputo entre el servidor y el cliente con el objetivo de mejorar el rendimiento del cliente. Ante la dificultad de representar gráficos foto realistas en dispositivos móviles poco potentes, algunos autores propusieron soluciones cliente-servidor hı́bridas basadas en visualización expresiva o no fotorrealı́stica. En esta lı́nea, Hekmatzada et al. [15] y Diepstraten et al. [12], presentaron trabajos en los que el servidor lleva a cabo técnicas de procesamiento de imagen sobre los modelos 3D a fin de extraer en tiempo real primitivas sencillas, tal y como lı́neas o siluetas. El uso de estas primitivas en lugar de la geometrı́a real permite reducir 210 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez el ancho de banda necesario para su trasmisión al cliente, ası́ como aumentar la velocidad de visualización de la escena. Quillet et al. [40] propuso un trabajo similar orientado a la navegación por escenas urbanas. Un servidor emplea algoritmos de detección de fronteras para extraer las caracterı́sticas principales de la textura de las fachadas. Con esta información se genera una representación vectorial de la fachada mediante lı́neas. El cliente descarga la geometrı́a de los edificios y la textura vectorial desde el servidor, y visualiza una imagen no fotorrealista. Es preciso remarcar que todas estas técnicas muestran una representación monocroma y distante con la realidad, lo que dificulta la comprensión de la escena por parte del usuario. Otro tipo de técnicas hı́bridas dividen el modelo 3D en dos partes. Una parte es dibujada por el servidor, y la otra parte es dibujada por el cliente. Estas técnicas persiguen reducir la complejidad geométrica de la escena mediante el reemplazo partes de la misma por imágenes bidimensionales generadas por el servidor. No obstante, determinar qué parte de la escena ha de ser visualizada por el servidor o el cliente no es una tarea trivial. 4. Conclusiones En este Capı́tulo se han presentado distintas técnicas de visualización de gráficos 3D en dispositivos móviles. Se ha presentado el estado actual del tema, mostrando las principales diferencias respecto de las aplicaciones habituales de ordenadores de escritorio, ası́ como las propuestas más importantes publicadas en la literatura actual. Agradecimientos Este trabajo ha sido parcialmente financiado por el Ministerio de Ciencia e Innovación y la Eunión Europea (fondos FEDER) a través del proyecto TIN2011-25259, y la Universidad de Jaén a través del proyecto de investigación UJA2010/13/08, financiado por Caja Rural de Jaén. Referencias 1. Tomas Akenine-Möller and Jacob Ström. Graphics for the masses: a hardware rasterization architecture for mobile phones. ACM Transactions on Graphics, 22:801–808, 2003. 2. Tomas Akenine-Möller and Jacob Ström. Graphics processing units for handhelds. Proceedings of the IEEE, 96(5):779 –789, 2008. 3. Matt Aranha, Piotr Dubla, Kurt Debattista, Thomas Bashford-Rogers, and Alan Chalmers. A physically-based client-server rendering solution for mobile devices. In MUM ’07: Proceedings of the 6th international conference on Mobile and ubiquitous multimedia, pages 149–154, New York, NY, USA, 2007. ACM. 4. M. Arikawa, S. Konomi, and K. Ohnishi. Navitime: Supporting pedestrian navigation in the real world. Pervasive Computing, IEEE, 6(3):21–29, 2007. Estudio sobre técnicas de visualización y navegación en dispositivos móviles 211 5. S. Babbin. Developing Software for Symbian OS 2nd Edition: A Beginner’s Guide to Creating Symbian OS v9 Smartphone Applications in C++. Wiley Publishing, 2nd edition, 2007. 6. A. Boukerche, R. Jarrar, and R.W. Pazzi. A novel interactive streaming protocol for imagebased 3d virtual environment navigation. In Communications, 2009. ICC ’09. IEEE International Conference on, pages 1–6, 2009. 7. Stefano Burigat and Luca Chittaro. Location-aware visualization of vrml models in gps-based mobile guides. In Web3D ’05: Proceedings of the tenth international conference on 3D Web technology, pages 57–64, New York, NY, USA, 2005. ACM. 8. T. Capin, K. Pulli, and T. Akenine-Moller. The state of the art in mobile graphics research. Computer Graphics and Applications, IEEE, 28(4):74–84, 2008. 9. Ken Catterall. GPU Pro - Advanced Rendering Techniques, chapter Migration to OpenGL ES 2.0. ShaderX Book Series. A.K. Peters, 2010. 10. Chun-Fa Chang and Shyh-Haur Ger. Enhancing 3d graphics on mobile devices by imagebased rendering. In PCM ’02: Proceedings of the Third IEEE Pacific Rim Conference on Multimedia, pages 1105–1111, London, UK, 2002. Springer-Verlag. 11. Timothy J. Cullip and Ulrich Neumann. Accelerating volume reconstruction with 3d texture hardware. Technical report, Chapel Hill, NC, USA, 1994. 12. Joachim Diepstraten, Martin Gorke, and Thomas Ertl. Remote line rendering for mobile devices. In CGI ’04: Proceedings of the Computer Graphics International, pages 454–461, Washington, DC, USA, 2004. IEEE Computer Society. 13. Florent Duguet and George Drettakis. Flexible point-based rendering on mobile devices. IEEE Computer Graphics and Applications, 24(4):57–63, 2004. 14. Zhiying He and Xiaohui Liang. A multiresolution object space point-based rendering approach for mobile devices. In AFRIGRAPH ’07: Proceedings of the 5th international conference on Computer graphics, virtual reality, visualisation and interaction in Africa, pages 7–13, New York, NY, USA, 2007. ACM. 15. D. Hekmatzada, Jan Meseth, and Reinhard Klein. Non-photorealistic rendering of complex 3d models on mobile devices. In 8th Annual Conference of the International Association for Mathematical Geology, volume 2, pages 93–98. Alfred-Wegener-Stiftung, 2002. 16. Jingshu Huang, Brian Bue, Avin Pattath, David S. Ebert, and Krystal M. Thomas. Interactive illustrative rendering on mobile devices. IEEE Computer Graphics and Applications, 27:48– 56, 2007. 17. Greg Humphreys, Mike Houston, Ren Ng, Randall Frank, Sean Ahern, Peter D. Kirchner, and James T. Klosowski. Chromium: a stream-processing framework for interactive rendering on clusters. ACM Trans. Graph., 21(3):693–702, 2002. 18. Java Community Process. JSR 184: Mobile 3D Graphics API for J2ME. http://www.jcp.org/en/jsr/detail?id=184, 2005. [accessed 24 March 2010]. 19. Java Community Process. Jsr 239: Java binding for the opengles api. http://www.jcp.org/en/jsr/detail?id=239, 2006. [accessed 24 March 2010]. 20. Java Community Process. JSR 297: Mobile 3D Graphics API 2.0. http://www.jcp.org/en/jsr/detail?id=297, 2009. [accessed 24 September 2010]. 21. S. Jeong and A. E. Kaufman. Interactive wireless virtual colonoscopy. The Visual Computer, 23(8):545–557, 2007. 22. Kadi Bouatouch, Gérald Point, and Gwenola Thomas. A Client-Server Approach to Image-Based Rendering on Mobile Terminals. Research Report RR-5447, INRIA, 2005. http://www.inria.fr/rrrt/rr-5447.html. 23. Khronos Group. OpenGL ES - The standard for embedded accelerated 3D graphics. http://www.khronos.org/, 2010. [accessed 24 March 2010]. 24. Fabrizio Lamberti and Andrea Sanna. A streaming-based solution for remote visualization of 3d graphics on mobile devices. IEEE Transactions on Visualization and Computer Graphics, 13(2):247–260, 2007. 25. Javier Lluch, Rafa Gaitán, Miguel Escrivá, and Emilio Camahort. Multiresolution 3d rendering on mobile devices. In Vassil Alexandrov, Geert van Albada, Peter Sloot, and Jack Dongarra, editors, Computational Science – ICCS 2006, volume 3992 of Lecture Notes in Computer Science, pages 287–294. Springer Berlin / Heidelberg, 2006. 212 José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez 26. Javier Lluch, Rafael Gaitán, Emilio Camahort, and Roberto Vivó. Interactive threedimensional rendering on mobile computer devices. In ACE ’05: Proceedings of the 2005 ACM SIGCHI International Conference on Advances in computer entertainment technology, pages 254–257, Valencia, Spain, 2005. ACM. 27. Ioana M. Martin. Adaptive rendering of 3d models over networks using multiple modalities. Technical Report RC 21722, IBM T.J. Watson Research Center, 2000. 28. Reto Meier. Professional Android 2 Application Development. Wrox Press Ltd., Birmingham, UK, UK, 1st edition, 2010. 29. Microsoft Corporation. Microsoft Developer Network Library (MSDN). Windows Mobile. http://msdn.microsoft.com/en-us/library/bb847935.aspx, 2010. [accessed 1 November 2010]. 30. M. Moser and D. Weiskopf. Interactive Volume Rendering on Mobile Devices. In Workshop on Vision, Modelling, and Visualization VMV ’08, pages 217–226, 2008. 31. A. Munshi, D. Ginsburg, and D. Shreiner. OpenGLES 2.0 Programming Guide. AddisonWesley Professional, 2008. 32. M. Neuburg. Programming iOS 4: Fundamentals of iPhone, iPad, and iPod touch Development. O’Reilly, 2011. 33. A. Nurminen. m-loma - a mobile 3d city map. In Web3D ’06: Proceedings of the eleventh international conference on 3D web technology, pages 7–18. ACM, 2006. 34. A. Nurminen. Mobile, hardware-accelerated urban 3d maps in 3g networks. In Web3D ’07: Proceedings of the twelfth international conference on 3D web technology, pages 7–16. ACM, 2007. 35. A. Nurminen. Mobile 3d city maps. IEEE Computer Graphics and Applications, 28:20–31, 2008. 36. A. Nurminen. Mobile Three-Dimensional City Maps. PhD thesis, Helsinki University of Technology, 2009. 37. R.W.N. Pazzi, A. Boukerche, and Tingxue Huang. Implementation, measurement, and analysis of an image-based virtual environment streaming protocol for wireless mobile devices. Instrumentation and Measurement, IEEE Transactions on, 57(9):1894–1907, 2008. 38. PowerVR. Migration from OpenGL ES 1.0 to OpenGL ES 2.0. Imagination Technologies Ltd., 2009. 39. K. Pulli, T. Aarnio, V. Miettinen, K. Roimela, and J. Vaarala. Mobile 3D graphics with OpenGL ES and M3G. Morgan Kaufmann, 2007. 40. Jean-Charles Quillet, Gwenola Thomas, Xavier Granier, Pascal Guitton, and Jean-Eudes Marvie. Using expressive rendering for remote visualization of large city models. In Web3D ’06: Proceedings of the eleventh international conference on 3D web technology, pages 27–35, New York, NY, USA, 2006. ACM. 41. Ismo Rakkolainen and Teija Vainio. A 3d city info for mobile users. Computers & Graphics, 25(4):619–625, 2001. Intelligent Interactive Assistance and Mobile Multimedia Computing. 42. Nick Randolph and Christopher Fairbairn. Professional Windows Phone 7 Application Development: Building Applications and Games Using Visual Studio, Silverlight, and XNA. Wrox, 2010. 43. C. Rezk-Salama, K. Engel, M. Bauer, G. Greiner, and T. Ertl. Interactive volume on standard pc graphics hardware using multi-textures and multi-stage rasterization. In HWWS ’00: Proceedings of the ACM SIGGRAPH/EUROGRAPHICS workshop on Graphics hardware, pages 109–118, New York, NY, USA, 2000. ACM. 44. Bengt-Olaf Schneider and Ioana M. Martin. An adaptive framework for 3d graphics over networks. Computers & Graphics, 23(6):867–874, 1999. 45. Wendel B. Silva and Maria Andréia Formico Rodrigues. A lightweight 3d visualization and navigation system on handheld devices. In SAC ’09: Proceedings of the 2009 ACM symposium on Applied Computing, pages 162–166, New York, NY, USA, 2009. ACM. 46. Eyal Teler and Dani Lischinski. Streaming of complex 3d scenes for remote walkthroughs. In Computer Graphics Forum, pages 200–1, 2001. 47. J. Wen, Y.G. Wu, and F. Wang. An approach for navigation in 3D models on mobile devices. In CMRT09: City Models, Roads and Traffic, pages 109–114, Paris, France, 2009. Estudio sobre técnicas de visualización y navegación en dispositivos móviles 213 48. Sang Wook Yang, Young Choi, and Hyun Chan Lee. Cad data visualization on mobile devices using sequential constrained delaunay triangulation. Computer-Aided Design, 41(5):375–384, 2009. Sistema de visualización de entornos urbanos con WebGL y X3DOM Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado Resumen La visualización e interacción con grandes escenas urbanas en una aplicación web es un problema complejo para entornos urbanos tridimensionales. En este capı́tulo se propone un prototipo para visualizar un modelo urbano a través de una arquitectura cliente-servidor usando software libre como WebGL y X3DOM. El sistema desarrollado permite además que los usuarios puedan navegar libremente por la escena y obtengan información adicional sobre los edificios o el mobiliario urbano. Para conseguir este objetivo, se ha diseñado una base de datos geo-espacial, implementada en MySQL que almacena información temática y geométrica sobre el entorno urbano. La comunicación entre la base de datos y el modelo X3D para obtener la información adicional se realiza utilizando Ajax. 1. Introducción El modelado 3D de ciudades (3DCM, 3D City Modeling) tiene un amplio rango de aplicaciones en ingenierı́a, construcción o arquitectura. Evidentemente, la disponibilidad de estas aplicaciones a través de Internet es una caracterı́stica deseable. Sin embargo, para alcanzar este objetivo deben resolverse algunos problemas previos entre los que destaca el procesamiento de grandes escenas urbanas. Por lo general, el tamaño de una ciudad es demasiado grande para ser transmitido a través de un sistema cliente-servidor, especialmente cuando se genera a partir de los datos de un sistema de información geográfica (SIG) real. Por tanto, es necesario un proceso de simplificación para reducir el tamaño de la escena y mejorar el rendimiento. Para ello podrı́an utilizarse técnicas de niveles de detalle (LOD) o un método de oclusión. Marı́a Dolores Robles Ortega Universidad de Jaén, Departamento de Informática e-mail: [email protected] Lidia Ortega Alvarado Universidad de Jaén, Departamento de Informática e-mail: [email protected] 215 216 Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado Otro aspecto importante en este tipo de aplicaciones es la interacción con los elementos urbanos para obtener información adicional, que podrı́a estar almacenada bien en una base de datos o bien en los propios modelos. La primera opción es más flexible puesto que permite modificar la información sin tener que alterar el modelo urbano. Evidentemente, el lenguaje de visualización es un aspecto fundamental en cualquier aplicación web, puesto que debe cumplir los requerimientos descritos anteriormente. En la actualidad existen algunas herramientas como, por ejemplo, el estándar ISO X3D [1] para visualizar archivos 3D en Internet. Sin embargo, este lenguaje requiere la instalación de un plugin en el navegador. Para evitar este problema, actualmente se están desarrollando nuevas tecnologı́as como WebGL y X3DOM que pueden visualizar un modelo 3D en una página web sin instalar ningún programa adicional. WebGL is un nuevo estándar para visualización de gráficos 3D en Internet que se complementa con otras tecnologı́as como el futuro estándar HTML5 [2]. X3DOM, por su parte, es una librerı́a [7] que permite la integración directa de la escena X3D en la estructura DOM (Document Object Model) de HTML5. Por tanto, el uso de X3DOM permite la visualización directa de la escena en un navegador web, insertando directamente la representación del mundo virtual en el código HTML. X3DOM se está utilizando actualmente en diferentes proyectos [3, 4]. En este capı́tulo se propone una aplicación web para navegación e interacción con entornos urbanos usando X3DOM y Ajax [5]. Se ha diseñado además una base de datos para almacenar la información geométrica y temática de los elementos de la escena [6]. Ası́, los usuarios pueden navegar libremente por la escena virtual y obtener información adicional sobre los edificios o el mobiliario urbano simplemente pulsando sobre ellos. 2. Implementación de la aplicación A continuación se describen las principales caracterı́sticas del prototipo diseñado para gestionar y visualizar la información urbana a través de un sistema clienteservidor. Inicialmente se explican las entidades de la base de datos y posteriormente el proceso realizado para generar la escena X3D a partir de esta información. 2.1. Descripción El sistema desarrollado permite tanto la visualización como la gestión y almacenamiento de datos urbanos 3D. En concreto, el método está enfocado principalmente a la visualización realista, la reducción de la geometrı́a, la navegación peatonal libre en la escena y la interacción con los edificios para obtener nuevos datos sobre ellos. Sistema de visualización de entornos urbanos con WebGL y X3DOM 217 Fig. 1 Esquema general de la aplicación El proceso se resume en la Figura 1, que muestra que la información almacenada en la base de datos se obtiene a través de un Sistema de Información Geográfica (SIG) 2D. La interconexión entre el SIG 2D y la base de datos se realiza mediante un módulo java, que utiliza el patrón DAO (Data Access Object) para transmitir la información. En cuanto a la generación de los modelos X3D de los edificios, se realiza mediante otra función java que obtiene la información relativa a la geometrı́a de las plantas y su altura mediante consultas a la base de datos usando el driver JDBC. Estos archivos X3D serán también almacenados en la base de datos, de forma que puedan ser reutilizados para generar el modelo final que se visualizará en la página web. Los usuarios pueden además moverse libremente por toda la escena y obtener nuevos datos sobre los edificios. Este proceso se describe con más detalle en la Sección 3. Seguidamente se describen las caracterı́sticas más importantes de la base de datos geo-espacial. 2.2. Base de datos geo-espacial La base de datos de la aplicación que se está describiendo debe almacenar tanto información geométrica como alfanumérica de las diferentes entidades urbanas. Entre los opciones disponibles, se decidió utilizar MySQL puesto que es software libre y permite establecer una conexión entre PHP y otras tecnologı́as web. A continuación se describen las tablas más importantes que la componen. En el SIG 2D que se utiliza como datos de entrada, los edificios se almacenan como polı́gonos que representan la geometrı́a de su planta. En la base de datos, esta geometrı́a se almacena utilizando un campo de tipo Polygon. Además de la planta, se dispone también de la altura del edificio, por lo que la generación del modelo 2.5D asociado puede realizarse de forma inmediata. Respecto a los datos temáticos, se dispone también de información significativa relacionada con los edificios como una breve descripción, horarios de apertura, servicios, etc. Gracias a esta estructura, es posible combinar en una única consulta criterios geométricos y temáticos. Por 218 Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado Fig. 2 Esquema de las entidades de mobiliario urbano de la base de datos ejemplo, a partir de la base de datos se podrı́an obtener los edificios más cercanos a un punto o los edificios más antiguos de la ciudad. Además de los edificios, un elemento fundamental en cualquier ciudad es el mobiliario urbano. Sin embargo, su gestión es generalmente compleja, debido a la gran cantidad de categorı́as diferentes que pueden ser consideradas. Para simplificar este proceso, tal y como se observa en la Figura 2, se ha creado una entidad que almacena los datos comunes a cualquier tipo de mobiliario. En concreto, los campos de esta tabla son: código único de identificación, descripción, URL del archivo X3D, punto que indica la posición donde se ubica y dirección de la calle. El resto de información especı́fica que depende de cada categorı́a en particular se almacena en tablas independientes. De esta forma, gracias a este diseño el sistema puede ser fácilmente extensible, puesto que el manejo de nuevas entidades requiere únicamente la inclusión de una nueva tabla en la base de datos. Actualmente se han considerado tres tablas: paradas de autobús, farolas y buzones. En el caso de las paradas de autobús se han incluido datos relativos a las rutas y horarios. 2.3. Generación de la escena X3D Debido al tamaño de las ciudades, no es posible realizar un proceso de modelado manual de todos los edificios. Por esta razón, en este capı́tulo se propone un método que permite crear de forma automática los modelos urbanos X3D de los edificios a partir de la geometrı́a de su planta y de su altura asociada. Ası́, las plantas se utilizan como base para generar los objetos 2.5D cuya altura se obtiene a través de una consulta a la base de datos. En concreto, se ha implementado un módulo java que permite crear todas las caras del modelo X3D de un edificio usando el nodo Sistema de visualización de entornos urbanos con WebGL y X3DOM 219 IndexedFaceSet, que posteriormente se visualizará usando WebGL y X3DOM. En general, WebGL muestra correctamente cualquier nodo de geometrı́a de X3D. Sin embargo, la dimensión de la escena generada utilizando este procedimiento podrı́a causar problemas durante el proceso de visualización utilizando un navegador WebGL. Por ello, es necesario un método que disminuya el tamaño y la complejidad del modelo. Para este propósito podrı́an usarse herramientas como impostores [8] o técnicas de simplificación dependientes del punto de vista [9]. En la aplicación desarrollada se utilizan niveles de detalle, que son directamente soportados por X3D. Este tipo de nodo permite que un modelo pueda tener múltiples representaciones incluyendo versiones en alta resolución (cuando los usuarios están más cerca) o baja resolución (cuando se observan a una distancia mayor). Por tanto, este tipo de técnicas puede utilizarse para mejorar el rendimiento de las escenas [10]. Especı́ficamente, la escena generada tiene tres niveles de detalle: edificios, manzanas de edificios y elementos no visibles. El primero de ellos es el modelo más elaborado, que será visible cuando el usuario esté situado a una distancia inferior a 500 metros. En el caso de que el usuario esté entre 500 y 1000 metros de distancia, se visualizará el modelo de las manzanas. Finalmente, para una distancia mayor, no se mostrará ningún modelo. Gracias a que únicamente se visualizan los edificios más cercanos, la memoria y los recursos necesarios para mostrar la escena en el cliente se reducen significativamente. Una vez explicado el procedimiento para modelar de forma automática la geometrı́a urbana, a continuación se describe el proceso de interacción con los edificios y el mobiliario urbano. 3. Interacción con los elementos urbanos usando X3DOM La interacción entre aplicaciones web y bases de datos geo-espaciales para permitir una interacción en tiempo real es un reto importante para los sistemas de información urbana tridimensionales. En este capı́tulo se propone un prototipo basado en una arquitectura cliente-servidor en el que el cliente visualiza e interactúa con el mundo urbano virtual, mientras que el servidor proporciona la información geométrica y temática. La aplicación se ha implementado utilizando software libre como WebGL, X3DOM, MySQL y Ajax. A continuación se describe el proceso para obtener y visualizar la información asociada tanto a la geometrı́a urbana como al mobiliario urbano. En la escena urbana, ciertos elementos como edificios o mobiliario urbano son sensibles a la interacción del usuario. Ası́, cuando éste pulsa sobre ellos utilizando el ratón, se genera una consulta a la base de datos para obtener la información asociada, que se mostrará mediante una ventana en el cliente. En el caso del mobiliario urbano se pueden acceder a datos como las lı́neas de una parada de autobús o los horarios de apertura de una tienda. 220 Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado Para implementar esta funcionalidad es necesario crear una función que controle los eventos. Al contrario que con la geometrı́a, la gestión de eventos en X3DOM es generalmente distinta a la de X3D. Por ejemplo, en X3D para controlar la pulsación con el ratón sobre un modelo se debe usar un tipo especial de nodo denominado sensor de toque (touch sensor). Este nodo genera el evento de pulsación (clicking), que puede ser enviado a otros nodos mediante la utilización de sentencias ROUTE. Ası́, el campo de salida de un sensor de este tipo puede ser conectado con un campo de entrada de cualquier otro nodo (un script, generalmente). Sin embargo, en X3DOM los sensores de toque pueden ser reemplazados por los eventos onClick de HTML. En cualquier caso, la acción de pulsar con el ratón sobre objetos sensibles de la escena genera una consulta a la base de datos geo-espacial. Como, por motivos de seguridad, las funciones JavaScript no pueden acceder directamente al repositorio, se debe establecer un mecanismo alternativo para realizar este proceso. En el prototipo diseñado se utiliza la tecnologı́a Ajax y PHP para conseguir este propósito. Ajax puede definirse como un conjunto de tecnologı́as utilizadas en el cliente que permiten crear aplicaciones web interactivas. Permite recuperar datos desde el servidor de forma ası́ncrona en segundo plano, favoreciendo ası́ un incremento de la interactividad y la creación de interfaces dinámicas en las páginas web. En la aplicación desarrollada en este trabajo, Ajax obtiene la información adicional sobre los edificios o el mobiliario urbano utilizando código PHP. Finalmente, una vez finalizado todo el proceso descrito anteriormente, la aplicación visualiza la información obtenida. Para ello se utiliza la librerı́a JQuery [11], compatible con la mayorı́a de los navegadores disponibles actualmente. 4. Resultados El prototipo ha sido probado usando los navegadores Firefox y Google Chrome. En ambos casos los usuarios pueden moverse libremente por el modelo 3D de la ciudad y obtener información adicional sobre algunos elementos urbanos, tal y como se puede observar en la Figura 3. En este ejemplo, se muestra una ventana con información sobre los horarios de apertura de un edificio, obtenida tras pulsar sobre el modelo 3D del edificio. En cuanto a la visualización gráfica, en las Figuras 4 y 5 se puede observar que se ha generado una escena realista en la que se permite la navegación tanto peatonal como en modo vuelo. Para texturizar los modelos de los edificios se han utilizado fotografı́as reales de la ciudad de Jaén. Gracias al uso de técnicas de niveles de detalle la carga de datos se reduce significativamente, puesto que inicialmente sólo se visualizan los modelos más sencillos y sólo se descarga el modelo real (más complejo) cuando los usuarios están cerca del edificio. Por lo tanto, se puede concluir que este tipo de herramientas permiten mejorar el tiempo de respuesta y la interacción con la escena. Sistema de visualización de entornos urbanos con WebGL y X3DOM 221 Fig. 3 Información adicional sobre horarios de apertura 5. Conclusiones y trabajo futuro En este capı́tulo se ha descrito un prototipo de una aplicación web para visualizar un modelo urbano usando tecnologı́as y software libre como WebGL y X3DOM. Se ha implementado asimismo una base de datos geo-espacial que almacena información temática y geométrica sobre los diferentes elementos urbanos. La aplicación desarrollada es interactiva, puesto que los usuarios pueden obtener información adicional sobre las entidades de la escena simplemente pulsando sobre ellas durante el proceso de navegación. El movimiento de los usuarios no está predeterminado, por lo que éstos pueden moverse libremente por todo el modelo urbano. El sistema propuesto puede ser usado en diferentes campos de aplicación como, por ejemplo, portales turı́sticos, aplicaciones de ingenierı́a y construcción, etc. Además, es fácilmente extensible, ya que se pueden generar nuevos elementos in- 222 Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado Fig. 4 Perspectiva aérea de la aplicación Fig. 5 Perspectiva peatonal de la aplicación teractivos mediante la inclusión de nuevos datos en la base de datos y la creación de sensores de toque (touch sensors) en los modelos 3D. Con el objetivo de reducir la carga de datos en el cliente y mejorar el tiempo de respuesta, se han utilizado nodos LOD. Gracias a esta técnica, inicialmente sólo se visualizan los edificios más cercanos. No obstante, en trabajos futuros, se pretende utilizar un método de oclusión para determinar de forma exacta el conjunto de edificios visibles desde una posición del observador, lo que permitirı́a mejorar el rendimiento final de la aplicación. Agradecimientos Este trabajo ha sido parcialmente subvencionado por el Ministerio de Ciencia e Innovación y la Unión Europea a través de los fondos FEDER bajo el proyecto de investigación TIN2011-25259 y por la Universidad de Jaén bajo el proyecto UJA2010/13/08 subvencionado por Caja Rural de Jaén. Referencias 1. W3C ISO/IEC 19775:2004 - Extensible 3D, X3D (2004) 2. Marrin, C. WebGL Specification Khronos WebGL Working Group (2011) Sistema de visualización de entornos urbanos con WebGL y X3DOM 223 3. Zollo, F., Caprini, L., Gervasi, O. & Costantini, A. X3DMMS: an X3DOM tool for molecular and material sciences Proceedings of the 16th International Conference on 3D Web Technology, ACM, 129-136 (2011) 4. Behr, J., Jung, Y., Drevensek, T. & Aderhold, A. Dynamic and interactive aspects of X3DOM Proceedings of the 16th International Conference on 3D Web Technology, ACM, 81-87 (2011) 5. Holdener, A. Ajax: The Definitive Guide O’Reilly Media (2008) 6. Robles Ortega, M. D., Ortega, L., Feito, F.R. & González, M.J. Navigation and interaction in urban environments using WebGL International Conference on Computer Graphics Theory and Applications (GRAPP 2012), 2012 7. Behr, J., Eschler, P., Jung, Y. & Zöllner, M. X3DOM: a DOM-based HTML5/X3D integration model Proceedings of the 14th International Conference on 3D Web Technology, ACM, 127135 (2009) 8. Andújar, C., Brunet, P., Chica, A. & Navazo, I. Visualization of Large-Scale Urban Models through Multi-Level Relief Impostors Computer Graphics Forum, 29, 2456-2468 (2010) 9. De Floriani, L., Kobbelt, L. & Puppo, E. A survey on data structures for level-of-detail models Advances in multiresolution for geometric modelling, 49-74 (2005) 10. Brutzman, D. & Daly, L. X3D: Extensible 3D Graphics for Web Authors Denise E. M. Penrose, (2007) 11. http://jquery.com/ Bloque VII Aplicaciones SIG urbanos en 3D para aplicaciones comerciales Ana Ma López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado Resumen Los SIG y la visualización tridimensional son utilizados cada vez en un mayor número de áreas. Por otro lado, la popularización de Internet hace que la sociedad tenga cada vez más acceso a todo tipo de datos, entre ellos, información geográfica. La mayorı́a de empresas y profesionales autónomos están interesados en aparecer en portales web para dar a conocer sus productos y servicios a la mayor cantidad de gente posible. Este capı́tulo pretende explicar el procedimiento a seguir para integrar todos estos conceptos con el fin de desarrollar un prototipo de aplicación web interactiva con algunas capacidades SIG que permita la obtención de información empresarial y la navegación en 2.5D en un entorno urbano. De esta forma, a través de un navegador Web, el usuario podrá buscar los distintos comercios de la ciudad clasificados por categorı́as, obtener información de ellos y localizarlos visualmente a distintos niveles de detalle. 1. Introducción Un Sistema de Información Geográfica (SIG) se puede definir como la unión de un conjunto de elementos, herramientas y utilidades que almacenan y manejan información referenciada espacialmente; es decir, información que tiene asociada una posición determinada en el espacio. Dicha posición vendrá definida por unas coordenadas X e Y concretas, en el caso de estar utilizando una representación bidimensional. Ana Ma López Estrella Universidad de Jaén, Campus Las Lagunillas s/n, 23071 - Jaén e-mail: [email protected] Ma Dolores Robles Ortega Universidad de Jaén, Campus Las Lagunillas s/n, 23071 - Jaén e-mail: [email protected] Lidia Ortega Alvarado Universidad de Jaén, Campus Las Lagunillas s/n, 23071 - Jaén e-mail: [email protected] 227 228 Ana Ma López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado Por lo general, los SIG ofrecen potentes capacidades de análisis y edición de datos espaciales, lo que los hace muy útiles en diferentes ámbitos. Pero además de esto, brindan la posibilidad de visualizar los datos que manejan. Actualmente la mayor parte de ellos trabajan en dos dimensiones, tanto a nivel de análisis como de visualización, mostrando los datos en mapas organizados en diferentes capas. Sin embargo, hoy en dı́a estamos asistiendo a un importante cambio. En los últimos años, el 3D se ha ido abriendo paso en áreas como el cine, los videojuegos, la televisión e incluso la telefonı́a móvil. Presentar un mundo virtual en tres dimensiones acerca al usuario a una representación mucho más realista de su entorno. Pero esta inclusión de la tercera coordenada en las aplicaciones gráficas, y sobre todo en los SIGs, no es algo trivial y, aunque está prácticamente resuelto a nivel de visualización y modelado, todavı́a encontramos muchos problemas en lo referente al análisis espacial e interacción [2]. Otro aspecto importante en lo que respecta a las tecnologı́as de la información es la Web. El acceso a Internet está disponible cada vez en una mayor variedad de dispositivos y a un coste menor, por lo que su uso se extiende de manera rápida. Por esta razón, no es de extrañar que los comercios y empresas que ofrecen servicios públicos estén interesadas en aparecer en tantos portales web como les sea posible, ya que de esta manera pueden darse a conocer de una manera rápida y cómoda, llegando ası́ a clientes que jamás sabrı́an de su existencia si no fuese por ello. La posibilidad de acceder a Internet a través de banda ancha hace que una gran cantidad de aplicaciones cuya implementación a través de la Web era impensable antes, ahora sea posible. Este hecho, junto con el auge que en los últimos años está teniendo el 3D, da lugar a la aparición de la llamada Web 3D, término que se refiere a toda aquella aplicación accesible desde un navegador que ofrece la posibilidad de visualizar y en ocasiones interactuar con gráficos en tres dimensiones para cumplir diferentes finalidades (tiendas virtuales, museos interactivos, etc.). Se obtienen ideas interesantes al integrar todos los términos y tecnologı́as que acabamos de ver. Los SIG y la visualización tridimensional son utilizados cada vez en un mayor número de áreas. Parece lógico por tanto que, aunque algunas tareas no estén del todo resueltas, ambos aspectos traten de unirse, dando lugar a los denominados SIG 3D. Además, la popularización de Internet hace que la sociedad tenga cada vez más acceso a todo tipo de datos, entre ellos, información geográfica. Hoy en dı́a existe una gran cantidad de aplicaciones disponibles a través de la red que manejan datos georreferenciados, ya sea de ciudades, comercios, etc. El ejemplo más famoso y conocido por todos es Google Maps. Ya que la forma más sencilla y utilizada hoy en dı́a para buscar cualquier tipo de información es recurrir al acceso a Internet, la mayorı́a de empresas y profesionales autónomos están interesados en aparecer en portales web para dar a conocer sus productos y servicios a la mayor cantidad de gente posible. Pero esto no sólo beneficia a los empresarios y comerciantes, sino también a quien busca dichos servicios. Hoy en dı́a cuando una persona necesita algo concreto pero no sabe dónde encontrarlo, lo primero que hace es realizar una consulta en un buscador. Sin embargo el usuario no estará sólo interesado en conocer el nombre del lugar al que ha de ir, sino también su localización. Y si además de indicársele la di- SIG urbanos en 3D para aplicaciones comerciales 229 rección, ésta viene acompañada con un mapa donde pueda verse de manera visual la ubicación, entonces el usuario podrá escoger el comercio que más le convenga según sus intereses (cercanı́a, proximidad a otros comercios, etc.). Sin embargo, plasmar una gran cantidad de datos (comercios o empresas) sobre un plano bidimensional a veces puede dar como resultado una imagen saturada en la que es difı́cil distinguir un local de otro. Una visualización de este entorno urbano a una distancia más cercana y en tres dimensiones podrı́a proporcionar una mayor claridad a la hora de interpretar el territorio que se está visualizando y de distinguir los diferentes puntos de interés. Al ser más realista, este tipo de representación harı́a que el usuario reconociese mejor la zona a la que se está accediendo, ya que también podrı́a distinguir los edificios que la componen, tal y como si estuviera en la ubicación real. Teniendo en cuenta todo lo presentado aquı́, este capı́tulo pretende explicar a grandes rasgos el procedimiento a seguir y los aspectos a tener en cuenta a la hora de integrar en una aplicación web datos espaciales procedentes de cualquier entorno urbano y su mundo empresarial, representando dicha información en tres dimensiones de manera que se le permita al usuario una visualización más intuitiva, realista y atractiva de la realidad que en el caso de los entornos bidimensionales. De esta forma se obtendrá un prototipo de un Sistema de Información Geográfica que permita la obtención de información empresarial y la navegación en 2.5D (término que será definido más adelante) en un entorno urbano con el fin de que, a través de un navegador web, el usuario pueda buscar los distintos comercios de la ciudad clasificados por categorı́as, obtener información de ellos y localizarlos visualmente a distintos niveles de detalle. 2. Conceptos previos El propósito que acabamos de definir se relaciona con varios conceptos (el 3D, la Web, la representación de entornos urbanos, etc.), y los une con el fin de crear una aplicación que trabaje como un buscador de comercios que no sólo proporcione información de los servicios concretos que éstos prestan, sino también su localización. En el presente apartado se hará un breve repaso a la situación actual de todos estos conceptos y sus relaciones entre sı́. 2.1. Los SIG y la Web Hoy en dı́a los Sistemas de Información Geográfica cumplen un importante papel en multitud de campos: planificación urbana y gestión territorial, medioambiente, equipamiento social, marketing geográfico, transporte y tráfico, gestión de infraestructuras, censos, catastros e incluso se pueden aplicar a la enseñanza [4]. En ocasiones las necesidades que se pretenden cubrir con ellos requieren que éstos sean 230 Ana Ma López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado accesibles desde casi cualquier parte. Por ejemplo, un GPS dejarı́a de cumplir su funcionalidad si no se pudiese trasladar de un sitio a otro. Por esta razón, resulta interesante unir las capacidades de los SIGs con el alto grado de flexibilidad que ofrecen las aplicaciones web en lo referente a accesibilidad. Actualmente, muchos sitios web populares manejan datos referenciados espacialmente. Es el caso de aplicaciones tan conocidas como Google Maps. Estas aplicaciones han sido construidas utilizando funcionalidades de los SIG, y son presentadas al usuario centrando su objetivo en la facilidad de uso y ocultando su funcionamiento interior [9]. 2.2. El modelado de entornos tridimensionales Por otro lado, como ya se ha mencionado anteriormente, la visualización tridimensional está siendo incorporada a todo tipo de dispositivos. Para representar una escena en 3D es necesario llevar a cabo el proceso de modelado. En ocasiones, éste será manual, en otras, se requiere que sea automático. Mientras que los entornos ficticios suelen ser inventados y creados a mano, la representación virtual de localizaciones reales necesita captar la geometrı́a para poder copiar la realidad de la forma más fideligna posible. Durante años de investigación se han propuesto muchos métodos para conseguir hacer esto de la manera más automatizada posible. Las técnicas más estudiadas hasta ahora tratan de construir la escena partiendo de imágenes [23, 21, 3]. Sin embargo, este método impone muchas restricciones, ya que la información que dichas imágenes proporcionan es insuficiente para construir un entorno realmente representativo. Estudios recientes optan por utilizar escáneres láser 3D, ya que calcan la escena que se quiere representar permitiendo ası́ obtener la geometrı́a de estructuras complejas [11, 22]. La tecnologı́a que utiliza esta técnica se conoce como LIDAR. El uso de estos escáneres 3D como fuente de datos obtiene nubes de puntos que suelen ser demasiado densas para poder tratarlas en tiempo real, por lo que generalmente es necesario simplificarlas enormemente para ser accesibles sobre todo vı́a Internet, lo que hace que pierdan parte de su riqueza. 2.3. Los SIG y el 3D Conforme va incrementándose la oferta en el mercado de la funcionalidad del 3D, también va surgiendo la necesidad de llevar a cabo diferentes actividades teniendo en cuenta la tercera dimensión: planificación urbana [12], actividades relacionadas con el catastro [20], monitorización medioambiental, etc. Aunque hace bastante tiempo que la unión de los SIGs con la visualización en 3D empezó a plantearse, el nivel de éxito que se ha alcanzado en ello es todavı́a muy débil. Las tareas que actualmente soporta un SIG 2D son: la captura, estructuración, manipulación, análisis SIG urbanos en 3D para aplicaciones comerciales 231 y presentación de datos [19]. Con la investigación en el campo de los Sistemas de Información geográfica 3D se pretende llegar a ofrecer la misma funcionalidad. Un estudio realizado por Zlatanova et al [26] describe diferentes sistemas de manejo de datos espaciales existentes en el mercado que incorporan ciertas funcionalidades para el trabajo con las tres dimensiones, como ArcGIS 3D Analyst de ESRI, AutoCAD o MapInfo (ver Fig.1.). Sin embargo, concluye que, aunque éstos se muestran eficientes en lo referente a la visualización, su funcionalidad en términos de estructuración, manipulación, interacción y análisis de datos 3D está todavı́a en fase de investigación. Fig. 1 Ejemplo de ciudad 3D generada por MapInfo Más adelante, otro estudio parecido realizado por los mismos autores [25] muestra los beneficios que conllevarı́a la estandarización de una estructura de datos espacial. Ası́ pues, un aspecto importante a la hora de hacer progresos en estos puntos débiles es la elección de un modelo topológico que aporte tanta robustez y flexibilidad como sea necesario. En este tema existen muchas propuestas; por ejemplo, Cambray [5] propone el uso de los modelos CAD para representar los objetos en 3D combinado con DTM (Digital Terrain Model) para llegar a conseguir un SIG 3D. Pilouk [18] enfocó su trabajo en el uso de la estructura de datos TIN y en una base de datos relacional para datos espaciales en 2D y 2.5D, y más tarde desarrolló una estructura propia denominada Tetrahedron Network (TEN). Otros autores proponen modelos orientados a objetos como [15] y [1]. Cada una de estos modelos de representación propuestos tienen sus ventajas e inconvenientes; sin embargo, aún no se ha llegado a ningún consenso en este tema. 232 2.4. Ana Ma López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado La Web 3D Además de todo lo expuesto anteriormente, cuando lo que se quiere es integrar el 3D dentro de una aplicación web, es importante tener en cuenta no sólo la cantidad de datos sobre la geometrı́a que se va a transmitir del cliente al servidor (problema que no está del todo resuelto a pesar de la rapidez de las conexiones de hoy en dı́a), sino también el tiempo que le llevará a la máquina cliente procesar la información para poder mostrarla finalmente. Además de mantener la geometrı́a de los elementos de la escena en estructuras de datos especiales para optimizar esta tarea, existen diversas técnicas que se pueden implementar para mejorar la interacción. Una de ellas es mantener la información dividida en diferentes niveles de detalle (LOD, Level Of Detail) para agilizar el proceso de visualización. De esta forma, en un entorno 3D que permita la navegación, se irá extrayendo de manera progresiva información geométrica más detallada sólo de aquellas partes de la escena a las que el observador o la cámara se vaya acercando, simplificando la geometrı́a de las partes que quedan alejadas [8] [10]. Otra manera de agilizar el proceso de visualización de gráficos es la llamada representación en 2.5D. Se trata de una simplificación del 3D en la que el volumen se simula mediante barridos de polı́gonos en dos dimensiones. De esta forma, lo que realmente se visualiza es el levantamiento de un polı́gono, colocando una gran cantidad de capas bidimensionales a diferentes alturas para dar la sensación tridimensional (Fig. 2). Fig. 2 Extrusión de un rectángulo con Google SketchUp. SIG urbanos en 3D para aplicaciones comerciales 233 Fig. 3 Modelo de la Catedral de Jaén en Google Earth 2.5. Entornos urbanos 3D: Investigación y ejemplos de aplicaciones reales Como se ha mencionado antes, mientras que la manipulación y el análisis de datos geográficos se encuentran todavı́a en fase de investigación, la visualización de datos espaciales en 3D es ya posible gracias, en la mayorı́a de los casos, a las herramientas CAD. Existen multitud de aplicaciones especializadas en ello, también en la representación y modelado de entornos urbanos en concreto. Un ejemplo de ello es City Engine, un software avanzado para la creación de ciudades en 3D. Además de esto, la investigación sigue adelante para conseguir todas las capacidades de los SIG en tres dimensiones. Existen multitud de trabajos dedicados al estudio de la generación de entornos urbanos; por ejemplo, Moser recoge una visión general de las capacidades de análisis de los SIG 3D para el modelado de ciudades virtuales en [17]. También existen estudios que orientan esta creación de ciudades 3D a la Web. Zlatanova y Tempfli en [27] presentan un prototipo de un modelo de SIG que integra una topologı́a 3D junto con una interfaz para la realización de consultas y la visualización a través de la red, generando de manera semi-automática los edificios y objetos tridimensionales. Coors [7] propone también un modelo de datos orientado a consulta realizando en este mismo trabajo una serie de pruebas sobre una ciudad tridimensional de aproximadamente unos 20.000 edificios, y consiguiendo la eficiencia suficiente como para que el prototipo sea accesible a través de Internet. Por último, Cheng et al. en [6] describe un modelo multi-escala junto con un sistema web de consulta para la localización de edificios 3D compuesto por cuatro niveles de detalle diferentes: modelo de bloque, modelo de textura genérica, modelo foto-realista económico y modelo foto-realista detallado. Como se mencionó en la introducción, una de las aplicaciones interesantes de los SIG es la representación de entornos urbanos y la localización de servicios al público dentro de dichos entornos. A la hora de buscar sitios web que proporcionen 234 Ana Ma López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado datos geográficos de ciudades y actúen como buscadores de empresas y comercios en ellas, podemos encontrar varios ejemplos, como MapQuest, Páginas Amarillas o, el más conocido hoy en dı́a, Google Maps. Sin embargo, ninguna de ella por sı́ sola proporciona representaciones tridimensionales de los datos geográficos con los que trabaja. Podemos decir que la aplicación que ha llevado más lejos la unión de los SIG con la Web y el 3D es Google Earth (Figura 3). Con la ayuda de los usuarios, que pueden crear y compartir modelos en tres dimensiones de los edificios que deseen utilizando su software de modelado SketchUp, esta aplicación de Google intenta obtener modelos de ciudades enteras tridimensionales. También se ha añadido a Google Maps recientemente MapsGL, que incorpora a los mapas la posibilidad de ver cada uno de los edificios en 3D simplificados. A pesar de estos ejemplos, aún no existe ninguna aplicación que genere los edificios de un entorno urbano en tres dimensiones de forma automática y localice, en su interior y por plantas, los comercios que se encuentran en él. 3. Metodologı́a Tal y como se mencionó en la sección de introducción, nuestro principal objetivo es proporcionar un método semiautomático para integrar un conjunto de datos espaciales urbanos en dos dimensiones junto con una base de datos de empresas, con el fin de generar una aplicación web interactiva con algunas de las capacidades de un SIG 3D. En este apartado se describe el proceso general a llevar a cabo para la obtención de este prototipo. Los principales requerimientos funcionales que se van a tener en cuenta son: 1. El prototipo debe proporcionar la visualización del entorno urbano a diferentes niveles de detalle (LOD): plano, manzanas y edificio. La transición de un nivel de detalle a otro se realizará en relación con una empresa que el usuario haya seleccionado previamente. Es decir, en un principo, el SIG mostrará el entorno urbano en su nivel de detalle más alejado (el plano). Para pasar al siguiente nivel (manzanas) el usuario deberá seleccionar una empresa o comercio concreto obteniendo ası́ sólo su entorno más cercano de forma más detallada. Al pasar al siguiente LOD, aparecerá únicamente el edificio al que pertenezca la empresa seleccionada. 2. La navegación (al menos a nivel de zoom, desplazamiento y rotación de la escena) debe ser posible en cualquier lugar de la ciudad, ası́ como el filtrado de empresas y comercios por categorı́a. 3. Las empresas y comercios deben poder ser localizadas por categorı́a en cada uno de los niveles de detalle, llegando incluso a poder visualizarse en la planta correspondiente del edificio al que pertenezcan. 4. Además de la localización, la aplicación debe proporcionar al usuario alguna información más sobre el comercio que éste seleccione. SIG urbanos en 3D para aplicaciones comerciales 235 5. Parte de la información sobre los comercios que mantiene el prototipo debe poder ser modificada y actualizada por los empresarios. Para ello se crearán dos perfiles de usuario: uno básico al que podrá acceder cualquier persona que desee localizar comercios o servicios, y otro de empresario que le permitirá a éste, una vez identificado en el sistema, modificar algunos de los datos sobre su empresa. Además, se van a tener el cuenta los siguientes requerimientos no funcionales: 1. El sistema debe responder en tiempo real ante cualquier interacción del usuario, independientemente del tipo de conexión a Internet que éste posea, siempre y cuando se encuentre dentro de unos lı́mites razonables. 2. El sistema debe ser accesible desde cualquier máquina remota que disponga de un navegador web sencillo y conexión a Internet, sin necesidad de ningún software adicional. 3. La interfaz debe ser intuitiva y usable de manera que ésta no suponga un problema a la hora de que un usuario utilice la aplicación por primera vez. Señalaremos que el entorno para el que se desarrollará este prototipo será el marco urbano de la ciudad de Jaén. A grandes rasgos, el proceso general de desarrollo será el siguiente: el tratamiento de los datos espaciales para adaptar la información de la que se dispone a nuestras necesidades se realizará utilizando MapInfo. Una vez hecho esto, los datos temáticos que se hayan obtenido se migrarán a una base de datos previamente diseñada (se utilizará MySQL). A ellos se accederá desde el modelo (implementado utilizando Java, JSP y Servlet), a través de JDBC, para obtener la información que se desee en cada momento. Los gráficos serán implementados utilizando O3D. La geometrı́a real en 2D de edificios y manzanas será obtenida de los ficheros .MIF y .MID que proporciona MapInfo. A partir de ella, se obtendrá el modelo en 2.5D mediante extrusión. En los siguientes apartados se explica más detenidamente dicho proceso. 3.1. Diseño de la base de datos En esta sección se va a describir la estructura que debe tener la base de datos que manejará la información necesaria para el desarrollo del prototipo. Partimos para ello de un conjunto de datos espaciales obtenidos gracias a la Oficina Virtual del Catastro, que nos proporciona la información georreferenciada y la geometrı́a en 2D de las plantas de los edificios, manzanas y portales. Además también nos aporta otros datos de interés tales como la altura y el número de plantas de cada edificio o el nombre de las calles. Por otro lado, la Cámara de Comercio de Jaén nos proporciona la base de datos empresarial, en la que cada empresa y comercio viene indicada junto su la dirección postal. En este caso concreto, basándonos en la descripción de funcionalidades que la aplicación debe cumplir, y a pesar de que estamos tratando de obtener un prototipo 236 Ana Ma López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado Fig. 4 Esquema conceptual de la base de datos del prototipo que guarda una relación estrecha con los Sistemas de Información Geográfica, no se ha considerado necesario utilizar una base de datos espacial. La razón es que para cumplir con los requerimientos de nuestro sistema, no necesitamos implementar operaciones espaciales en las que sea imprescindible mantener la geometrı́a de las entidades. El esquema conceptual de la base de datos que dará soporte a nuestro sistema queda como se muestra en la Figura 4. Como refleja la estructura de nuestra base de datos, cada empresa estará ubicada en un portal (R3), cada portal está situado en un edificio (R4) y a su vez éste pertenecerá a una manzana concreta (R5). Una gran parte de las entidades identificadas en el esquema se podrı́an considerar entidades espaciales (empresa, portal, edificio y manzana). Sin embargo, como acabamos de mencionar, prácticamente no es necesario almacenar en la base de datos la geometrı́a de estas entidades para realizar operaciones espaciales con ellas, ya que lo único que necesitamos es saber a qué portal pertenece cada empresa, a qué edificio pertenece cada portal y a qué manzana pertenece cada edificio, información que SIG urbanos en 3D para aplicaciones comerciales 237 nos viene dada en los datos de los que disponemos. Por lo tanto, no será necesario obtenerla mediante operaciones espaciales de inclusión ni de ningún otro tipo. Por otro lado recordemos que, al seleccionar una empresa concreta, la aplicación debe pasar a un segundo nivel de detalle en el que se visualicen las manzanas más cercanas a la empresa seleccionada, lo que, en un principio, supondrı́a el cálculo de áreas de influencia o de la distancia del edificio donde se encuentra el comercio a todas las manzanas para seleccionar las más cercanas. Sin embargo, debido al gran volumen de datos con los que se trabajará, realizar esta tarea puede llevar demasiado tiempo, limitando ası́ la capacidad de interacción con el usuario. Por esta razón realizaremos un preprocesamiento y almacenaremos las cinco manzanas más cercanas a cada una de las empresas (relación R6). Aunque en la base de datos no almacenaremos la información espacial de las entidades, sı́ tendremos distribuidas en ficheros las coordenadas y la geometrı́a de manzanas y edificios para su posterior visualización. Los datos espaciales de estas entidades y de los portales están a nuestra disposición gracias a la Oficina Virtual del Catastro. Sin embargo, en los datos que poseemos de las empresas la única información que tenemos acerca de su ubicación es su dirección. Por esta razón debemos realizar un proceso de geocodificación (que será explicado en la siguiente sección), en el que se puedan obtener las coordenadas de dichas empresas para posteriormente situarlas sobre las escenas a dibujar. Una vez obtenidas, las almacenaremos en la base de datos (atributos posX y posY de la entidad empresa). 3.2. Geocodificación de las empresas Cuando nos enfrentamos ante un problema relacionado con los Sistemas de Información Geográfica, en ocasiones, los datos de los que disponemos son simplemente datos temáticos, y, aunque frecuentemente tenemos la dirección de las entidades, éstas no tienen asociadas ningún tipo coordenadas espaciales. Este es el caso en que nos encontramos en lo referente a nuestra base de datos de comercios: no disponemos de la información geográfica referente a las empresas. Los únicos datos que tenemos sobre su situación son la dirección de cada uno de ellos. Por tanto, para obtener sus coordenadas automáticamente y poder ubicarlas el lugar correspondiente dentro del plano de Jaén, debemos realizar un proceso previo de geocodificación. Geocodificar una tabla de entidades en una base de datos es básicamente asignar coordenadas X e Y a cada registro; es decir, calcular la localización de cada uno de ellos en la superficie sobre la que se está trabajando. Zandbergen [24] realiza un estudio comparativo de las diferentes técnicas de geocodificación. Sin embargo, únicamente menciona cómo localizar las entidades en un entorno bidimensional. Serı́a interesante realizar este proceso de ubicación considerando las diferentes plantas de los edificios, puesto que en muchas ocasiones en los entornos urbanos se sitúan servicios como consultas privadas de médicos o abogados que se encuentran no sólo en los locales de las plantas bajas, sino también en 238 Ana Ma López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado pisos más altos. Además, existen también edificios completos dedicados únicamente a albergar empresas. Uno de los métodos para realizar el proceso de geocodificación utiliza las direcciones postales de las entidades a situar: calle, número, código postal, zona (paı́s, ciudad...), etc. Las calles tienen nombres únicos dentro de zonas concretas, y las zonas tienen nombres únicos dentro de determinadas regiones. Además, se utilizan los códigos postales, que están ordenados jerárquicamente asignando los primeros caracteres a zonas grandes y los siguientes a áreas más pequeñas dentro de éstas. Atendiendo a esto, la dirección postal de una entidad es útil para poder georreferenciarla. Una de las maneras en las que se suele realizar el proceso de geocodificación es mediante el emparejamiento de información geográfica disponible en otras tablas con la información que necesitamos situar en el mapa. Por esta razón, para poder geocodificar una lista de entidades, es necesario disponer al menos de otra tabla que tenga asociada información espacial al mismo nivel de detalle que necesitamos llegar con la geocodificación. En ocasiones, este proceso puede resultar difı́cil debido a la amplia variedad de términos y abreviaturas diferentes con las que identificar una dirección concreta. Otras veces, cuando no se dispone de información real para emparejar, la geocodificación se puede realizar estimando las coordenadas X e Y del punto concreto mediante interpolación, localizando en la capa de las calles el punto en el lugar más aproximado a la realidad según los algoritmos utilizados. En el caso del prototipo que se pretende desarrollar, disponemos de una serie de comercios de los que sólo conocemos su dirección escrita, y necesitamos asignarles unas coordenadas X e Y que nos permitan situarlos fı́sicamente sobre un mapa para desarrollar nuestro SIG. La dirección incluye la calle, el número de portal, la planta y la puerta. Por otra parte, como ya se indicó, la oficina del Catastro nos proporciona información espacial referente a calles y portales. No disponemos de información referida a la distribución interna de cada edificio, por lo que la puerta tampoco podremos utilizarla en nuestra geolocalización. Por tanto, en un principio, llegaremos al nivel de detalle de calle y número. Ésta será la información que utilizaremos para nuestro proceso. De esta forma, teniendo situados sobre un mapa los portales, y conociendo en qué portal está situado cada comercio, podremos geocodificar a nivel de portal. Aunque no es nuestro caso, en ocasiones tendremos que tener en cuenta que puede haber información ambigua. Por ejemplo, si estuviésemos tratando de geolocalizar comercios en diferentes ciudades, debemos contar con la posibilidad de que existan calles con el mismo nombre en ciudades distintas, y por tanto, un comercio podrı́a ser asignado a más de un par de coordenadas X e Y. En este caso, a la hora de geocodificar se deberı́a incluir además un campo que indique la ciudad a la que se refiere cada tabla (los comercios y la información espacial), como el código postal o el propio nombre de la ciudad. Existe una gran variedad de herramientas potentes incrustadas en software SIG comercial e incluso servicios web para realizar el proceso de geocodificación, como la API de Google o de Yahoo [14]. Concretamente, para el desarrollo de este prototipo se ha utilizado la herramienta de geocodificación de MapInfo. SIG urbanos en 3D para aplicaciones comerciales 3.2.1. 239 Proceso de geocodificación con MapInfo Como ya se ha mencionado anteriormente, disponemos de una tabla proporcionada por la Oficina Virtual del Catastro que recoge los distintos portales de la ciudad ubicados espacialmente que, además tienen asociados una serie de datos temáticos entre los cuales se encuentran la calle y el número. Además, tenemos la base de datos de comercios, que nos proporciona, entre otras cosas, información acerca de la dirección postal de cada uno de ellos. Por tanto, para realizar el proceso de geocodificación, utilizando MapInfo trataremos de emparejar los campos de dirección de ambas tablas, asignando ası́ a cada comercio las coordenadas X e Y del portal cuya dirección coincida con la de la empresa. Sin embargo, previamente ha sido necesario hacer algunas adaptaciones en los datos. En primer lugar, exportar la base de datos de comercios a formato de MapInfo. En segundo lugar, como acabamos decir, nuestro objetivo es geocodificar a partir de dos campos: la calle y el número de portal. Sin embargo, MapInfo tiene en cuenta un sólo campo a la hora de realizar el proceso. Por tanto, para poder llevar a cabo la operación será necesario que en ambas tablas exista un campo único que contenga la dirección entera (calle y número de portal) para que podamos indicarle a MapInfo que ejecute el proceso a partir de dicho campo. Una vez unificados en un sólo atributo la calle y el número de portal, comenzamos el proceso de geocodificación, disponible en MapInfo en el menú Tabla. Aparece entonces un cuadro de diálogo como el que se muestra en la Figura 5. Fig. 5 Inicio del proceso de geocodificación con MapInfo Aquı́ es donde se debe indicar la tabla que se desea geocodificar (Comercios), la columna que se quiera emparejar para hacerlo (Calle numero), la tabla que contiene la información espacial que utilizaremos para emparejar el campo dirección y asignar coordenadas X e Y a los comercios (Portales01), y el campo de esta última 240 Ana Ma López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado tabla que se utilizará (Calle Numero). Además también se puede escoger un campo que indique la región en la que se geocodificará (que en nuestro caso no es necesario) y la opción de geocodificar de manera interactiva en lugar de automática. Para comenzar se intentará hacer de manera automática. Una vez rellenado el cuadro de diálogo, al aceptar, MapInfo muestra los resultados obtenidos (ver Figura 6). Fig. 6 Resultados en el primer intento de Geocodificación. Lo que ha ocurrido al intentar asignar coordenadas X e Y a los comercios es que MapInfo busca coincidencias exactas de direcciones entre las dos tablas implicadas. Sin embargo, si nos fijamos, existen diferencias en la forma en que están expresadas las direcciones en la tabla de comercios y en la tabla de portales, como se puede apreciar en la Figura 7. Fig. 7 Diferentes formas de expresar una única calle en dos tablas diferentes. Como podemos observar, en la tabla de Comercios la dirección está expresada con una abreviatura (CL) seguida del nombre de la calle y el número. Sin embargo, en la tabla de portales tenemos la palabra completa “Calle” seguida del resto de la dirección. En el resto de registros ocurre lo mismo. MapInfo busca coincidencias exactas en los nombres de las direcciones para emparejar registros. El proceso de matching no es sensible a mayúsculas y minúsculas, sin embargo, la dirección debe coincidir letra por letra para que se asocie un comercio a una dirección concreta. Por SIG urbanos en 3D para aplicaciones comerciales 241 Fig. 8 Empresas geocodificadas sobre el mapa. defecto, MapInfo asocia algunas abreviaturas a sus correspondientes palabras; sin embargo, estas equivalencias están definidas únicamente en inglés. Esta es la razón por la que, en un primer intento, no ha sido posible geocodificar ningún comercio. Para solucionar este problema, MapInfo incluye un fichero de abreviaciones llamado MAPINFOW.ABB, donde están definidas las equivalencias por defecto que acabamos de mencionar. El fichero es editable, por tanto, simplemente añadiendo las abreviaciones que queramos que se tengan en cuenta para nuestro proceso de geocodificación en el formato correcto, este problema deberı́a estar solucionado. Otra forma de dar solución a este problema serı́a sustituir en una de las tablas una de las palabras (por ejemplo, la abreviatura “CL”) por la otra (la palabra “calle”). Otro problema que nos puede surgir es el hecho de que una dirección puede estar expresada de diferentes maneras, no sólo por las abreviaturas utilizadas, sino porque, en muchas ocasiones, por ejemplo, al almacenar el nombre de una calle pueden omitirse determinantes o artı́culos. Esto dificulta el proceso de geocodificación en MapInfo. Si en una tabla una dirección viene indicada como “Paseo de la Estación 45”, y en la otra tabla implicada viene expresada como “Paseo Estación 45”, el proceso automático de geocodificación no emparejará dichas direcciones. Sin embargo, existe un modo interactivo de geolocalización en MapInfo que en ocasiones soluciona este tipo de problemas. Si marcamos la casilla de “Modo Interactivo” en lugar de “Modo automático” en el cuadro de diálogo mostrado anteriormente, MapInfo emparejará las coincidencias exactas y, cada vez que encuentre un registro con una dirección que no consiga localizar en la tabla que contiene la información espacial, se detendrá, dando a elegir al usuario entre un conjunto de opciones encontradas que MapInfo considera similares. 242 Ana Ma López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado Por tanto, la manera más usual de geocodificar es ejecutar primero el proceso de manera automática para conseguir a priori encontrar todas las coincidencias posibles y, a continuación, ejecutarlo de manera interactiva para intentar emparejar manualmente aquellos registros que no haya sido posible en el paso anterior. Todo este proceso ha permitido obtener la localización espacial de las empresas, convirtiéndolas en entidades espaciales, como muestra la Figura 8. Ahora, debemos obtener sus coordenadas X e Y para llegar a conseguir una base de datos tal y como la hemos especificado en el apartado anterior. Para ello, se han empleado las funciones CentroidX() y CentroidY() que MapInfo proporciona para insertar dos nuevos campos en la tabla de comercios que representen las coordenadas en dos dimensiones. 3.2.2. Geocodificación 3D Como se ha comentado anteriormete, serı́a interesante geocodificar considerando las diferentes plantas de los edificios. Tenemos ya las coordenadas en las que cada uno de nuestros comercios están situados. Sin embargo, el objetivo de este capı́tulo es desarrollar un prototipo de SIG que los sitúe también en escenas tridimensionales. La geocodificación en tres dimensiones actualmente no está resuelta. Existen estudios que proponen técnicas para ello. Por ejemplo, Lee desarrolla en [13] una técnica de geocodificación en tres dimensiones para el interior de edificios (a microescala) con el fin de localizar las actividades humanas en el espacio y tiempo, resaltando los beneficios que ésta tendrı́a para la mejora de la velocidad de respuesta ante situaciones de emergencia en interiores. Sin embargo, para el desarrollo de este prototipo, necesitamos ubicar comercios no sólo en el interior de un edificio, sino a nivel de toda una zona urbana completa. Se hará para ello una aproximación a la geocodificación en tres dimensiones. En nuestra base de datos de comercios, como se ha comentado al principio, disponemos de la información del número de planta en que cada negocio está localizado. Por tanto, una vez geolocalizados los comercios en dos dimensiones, para geocodificar en 3D, elevaremos las coordenadas X e Y al crear las escenas virtuales de la aplicación en tres dimensiones a una altura determinada dependiendo del número de planta en que se encuentre el local. Esto tiene la ventaja de que, si existiese por ejemplo un edificio completo de oficinas, no se visualizarán aglomeradas en el mismo punto como ocurre si sólo se ubican atendiendo a coordenadas bidimensionales. 3.3. Generación del modelo 3D Para el desarrollo de este prototipo se pretende llevar a cabo una generación automática de los modelos tridimensionales; es decir, de las manzanas y los edificios que se representarán nuestro entorno urbano. Para ello, se partirá de los datos espaciales proporcionados por la Oficina Virtual del Catastro, en formato de MapInfo. SIG urbanos en 3D para aplicaciones comerciales 243 A través de este software se pueden exportar los datos a un formato de intercambio fácilmente interpretable. El formato MIF (MapInfo Interchange Format) es un formato versátil que asocia los datos temáticos a los elementos gráficos. Se trata de un formato editable y relativamente fácil de generar y leer. Las tablas espaciales en este formato constan de dos archivos: los gráficos están almacenados en un archivo .MIF y los datos de texto se incluyen en un archivo .MID. La estructura de este último es sencilla: una lı́nea por cada registro en la que se representan los datos temáticos separados mediante un delimitador: ‘‘0000201VG3800S’’,‘‘00002’’,2 ‘‘0000206VG3800S’’,‘‘00002’’,3 ‘‘0000204VG3800S’’,‘‘00002’’,2 ‘‘0000310VG3800S’’,‘‘00003’’,2 ... El archivo .MIF está formado por dos partes: una cabecera que contiene información como la versión de MapInfo, el juego de caracteres utilizado o los nombres de las columnas y el tipo de los datos temáticos, y una sección de datos, encabezada por la palabra DATA, en las que encontramos las coordenadas que forman las entidades espaciales: ... Data Region 1 10 18,12648648648787 4,916788321158366 17,978918918918165 4,7124087591281665 17,951891891891137 4,674452554747245 17,769189189188182 4,420437956208458 17,583243243242112 4,694890510936669 17,573513513512758 4,7087591240712765 17,714054054055186 4,948175182484471 17,798378378379386 5,091240875912408 17,842162162163042 5,167153284674252 18,12648648648787 4,916788321158366 Pen (1,2,0) Brush (2,16777215,16777215) Center 17,84972972972822 4,7934306569288685 Region 1 5 19,461621621620488 3,10072992700594 19,661081081080074 3,456934306559826 244 Ana Ma López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado 19,75567567567467 3,624817518259052 20,093513513512505 3,3810218977979827 19,461621621620488 3,10072992700594 Pen (1,2,0) ... Ası́, por ejemplo, el fragmento que acabamos de ver contiene la información de dos entidades diferentes. La palabra REGION indica que se trata de objetos compuestos por uno o más polı́gonos, según indique el número que le acompaña (si la entidad fuese un punto estarı́a encabezada por la palabra POINT, LINE indicarı́a que se trata de una lı́nea, etc.). A continuación, en el caso de una entidad Región el fichero señala el número de pares de coordenadas por las que está compuesta dicha entidad y, por último, muestra cada una de ellas [16]. Cada lı́nea del fichero .MID guarda una correspondencia uno a uno con las entidades espaciales que aparecen en el fichero .MIF. Es decir, en el caso del ejemplo, la primera lı́nea del fichero .MID corresponderı́a a los datos temáticos asociados a la primera región definida en el fichero .MIF, la segunda lı́nea a la segunda región, etc. Ası́, para la generación de los modelos 3D de nuestra plataforma se han utilizado estos ficheros de MapInfo. Para representar una manzana o edificio concreto, en primer lugar, se ha realizado una búsqueda en el archivo .MID de la clave de éste llevando un contador para almacenar la posición en la que aparece y, a continuación, se ha buscado en el archivo .MIF la entidad espacial situada en dicha posición recogiendo ası́ sus coordenadas. A partir de ellas, para representar los edificios en tres dimensiones, se ha creado un prisma elevando la planta de cada uno de ellos a una altura que vendrá determinada por el número de pisos que contenga el edificio. Esta manera de aproximar una representación en tres dimensiones se conoce como 2.5D. Se trata de realizar un barrido o extrusión a lo largo del eje Z del polı́gono que representa la planta de la entidad, dando ası́ volumen a nuestros edificios y manzanas. 3.4. Tecnologı́as de implementación de gráficos 3D en la Web Una adecuada elección de las tecnologı́as a utilizar durante el desarrollo del prototipo es esencial para el funcionamiento satisfactorio de éste. A continuación se hace un breve repaso de algunos los lenguajes de programación, de descripción o librerı́as existentes en el panorama actual, comentando las caracterı́sticas esenciales de cada uno de ellos: VRML (Virtual Reality Modeling Language): Se trata del primer estándar ISO de la Web que surgió en lo referente a la visualización en tres dimensiones. Para crear una escena con este lenguaje de descripción sólo es necesario un editor de texto simple, aunque existen algunos con caracterı́sticas más especializadas que facilitan el SIG urbanos en 3D para aplicaciones comerciales 245 desarrollo (como por ejemplo VRMLPad). La visualización de los resultados requiere únicamente estar en disposición de un navegador y tener instalado un plugin sobre él que actúe como visualizador (como Cortona o BSConctact). Aunque en VRML muchas de las funciones básicas de una aplicación interactiva están ya implementadas (movimientos de cámara, etc.), su principal problema reside en la interactividad; un archivo de gran tamaño con un modelo muy detallado verá bastantes restringidas sus posibilidades de interacción. X3D(eXtensible 3D): Surgió como una nueva versión de VRML cuyas principales novedades se centran fundamentalmente en la integración de VRML 2.0. con XML. Con ello se pretendı́a, entre otras cosas, conseguir una mejor integración con el resto de tecnologı́as del Word Wide Web. Al ser extensible, permite el uso de nuevos componentes. Sin embargo, X3D es un estándar en desuso en la actualidad. El apoyo recibido por parte de grandes compañı́as hacia este lenguaje es escaso. Además, en ocasiones el rendimiento que se consigue mediante su uso no es el deseado. O3D: Se trata de una API de software libre escrita en Javascript que desarrolló Google para crear aplicaciones web con gráficos 3D interactivas. Esta librerı́a provee al usuario de un grafo de escena parecido al que proporcionan C3DL o Java3D. Para poder ejecutar aplicaciones desarrolladas en O3D basta con tener un navegador web e instalar un sencillo plugin de visualización sobre él. Este plugin se comunica directamente con el hardware, por lo que la velocidad de renderizado depende en gran medida de la tarjeta gráfica. A principios de mayo de 2010, pasado un año de su presentación y después de varios meses sin noticias sobre los avances de su proyecto O3D, Google anunció su decisión de cambiar la dirección de su proyecto para desarrollar una API que trabaje bajo lo que pretende convertirse en un estándar de tecnologı́as para la visualización de gráficos 3D en la Web: WebGL. WebGL: WebGL es una especificación estándar, manejada por el consorcio de tecnologı́a Khronos Group, que permite representar gráficos 3D acelerados por hardware en páginas Web. Se trata también, de una librerı́a escrita bajo JavaScript; aunque en esta ocasión el lenguaje de script sirve como enlace para utilizar la implementación nativa de OpenGL ES 2.0. Para la representación de gráficos en 3D WebGL utiliza el elemento canvas de HTML 5, por lo que no necesita la adición de ningún plugin en el navegador. Una clara desventaja de esta opción es que en la actualidad Internet Explorer no tiene intención de dar soporte a esta tecnologı́a. XML-3D: Se trata de la tecnologı́a de visualización 3D para web cuyo nacimiento ha sido más reciente de todas las citadas hasta ahora. La propuesta fue presentada por un equipo de desarrollo de la Universidad de Saarland en Hanover. XML3D está diseñado para ser integrado con las tecnologı́as estándares de W3C como HTML, DOM y CSS entre otros. En la actualidad se encuentra en una fase muy temprana de desarrollo. Ana Ma López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado 246 3.4.1. Elección de la tecnologı́a de implementación La elección de la tecnologı́a de implementación de gráficos en la Web por la que nos decantamos vino marcada por el momento en que se hizo la elección. Se descartó desde un principio el uso de VRML y X3D debido a la fase de estancamiento en la que se encuentran, donde cada vez son usados por menos desarrolladores. En lo referente a XML3D, esta tecnologı́a se encontraba, y se encuentra aún, en una fase de desarrollo muy temprana y la documentación y ejemplos disponibles es muy escasa, por lo que fue descartado también. En cuanto a las dos tecnologı́as restantes, WebGL y O3D, cuando se comenzó a implementar este prototipo, fueron varios los motivos que llevaron al descarte de WebGL: en primer lugar, además de ser una tecnologı́a muy reciente de la cual apenas se encontraba documentación, aún no estaba implementado de forma directa en ninguno de los principales navegadores. Para utilizarlo en Firefox era necesaria la descarga de una de sus versiones en estado alfa llamada Minefield y configurar un par de parámetros. En Google Chrome ocurre algo similar, siendo diferente la configuración dependiendo del sistema operativo utilizado. Internet Explorer, el navegador más utilizado no da soporte a WebGL. Además de estos problemas con los navegadores, no todas las tarjetas gráficas eran compatibles con esta tecnologı́a. Las tarjetas de Intel, por ejemplo, muy comunes sobre todo en ordenadores portátiles con Windows, necesitan la instalación adicional de un software de renderizado de Firefox, con el que los gráficos serı́an procesados por el procesador del computador y no por la tarjeta gráfica, permitiendo ası́ el funcionamiento de aplicaciones con WebGL, pero con un rendimiento muy bajo. Todo esto, llevó a la elección de O3D como API para la implementación del prototipo. Sin embargo, hoy en dı́a el desarrollo de WebGL ha evolucionado de manera my rápida. Todo apunta a que WebGL se convertirá en un futuro en el estándar por excelencia para este tipo de aplicaciones. Se trata de una tecnologı́a apoyada por la mayorı́a de las grandes compañı́as involucradas en el desarrollo Web, incluido Google. Además no necesita la instalación de plugin alguno en el navegador. Por todo ello la mejor elección en la actualidad serı́a WebGL. 4. Resultados El proceso descrito en la sección anterior nos lleva a la obtención del prototipo que fue planteado al comienzo del capı́tulo: El prototipo proporciona la visualización del entorno urbano de Jaén en tres niveles de detalle diferentes. El zoom y el desplazamiento y rotación de la escena son posibles en cualquier parte del entorno urbano. El prototipo proporciona la búsqueda de empresas por categorı́a en todo el entorno urbano. SIG urbanos en 3D para aplicaciones comerciales 247 Fig. 9 Aspecto inicial del prototipo web. Las empresas y comercios son ubicadas en su lugar correspondiente, llegando a poder visualizarse situadas en la planta a la que pertenecen. El prototipo es capaz de proporcionar al usuario, además de la ubicación de los comercios, información más detallada sobre ellos. Parte de la información de los comercios puede ser modificada por los empresarios tras identificarse en el sistema. Para ello se ha creado un perfil de usuario especı́fico. Fig. 10 Categorı́as y empresa seleccionada sobre el mapa 248 Ana Ma López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado La Figura 9 presenta el aspecto inicial del prototipo web. En él aparece, a la izquierda, el apartado de login para el empresario; en el centro, el plano de la ciudad de Jaén y el panel de navegación; y a la derecha, el listado de categorı́as además de el cuadro donde aparecerá la información de la empresa seleccionada. Al escoger una o varias categorı́as de la lista, aparecerán sobre el mapa todas aquellas empresas que pertenezcan a dicha categorı́a. Si además se selecciona alguna, la información asociada a ella será mostrada en el cuadro de información de la derecha, tal y como muestra la Figura 10. Fig. 11 Segundo LOD: manzanas. Una vez seleccionado un comercio o servicio, al acceder al siguiente nivel de detalle se podrán visualizar las manzanas más próximas a éste (Figura 11). Por último, a nivel de detalle de edificio, la empresa escogida se verá ubicada en la planta correspondiente (Figura 12). Como se ha mencionado anteriormente, la aplicación web también tendrá un espacio reservado para los empresarios, donde éstos podrán cambiar parte de la información de las empresas a las que están asociados, como se puede ver en la Figura 13. 5. Conclusiones y lı́neas futuras En este apartado se verán las conclusiones finales a las que se ha podido llegar, ası́ como las posibles mejoras que se pueden aplicar al prototipo ya obtenido. SIG urbanos en 3D para aplicaciones comerciales 249 Fig. 12 Tercer LOD: edificio. Fig. 13 Espacio para empresarios. 5.1. Conclusiones El 3D está cada vez más presente en las nuevas tecnologı́as como modelo de visualización, ya que de esta forma al usuario se le permite ver escenas con un realismo superior y la inmersión del usuario que se consigue en el entorno virtual es mayor. Los Sistemas de Información Geográfica (SIG) también ganan en funcionalidad cuando utilizan información tridimensional. Hasta hace relativamente poco, las representaciones de entornos urbanos en SIG solı́an ser en dos dimensiones; sin embargo, este tipo de sistemas poco a poco van adquiriendo capacidades para la representación y el procesamiento de información en tres dimensiones. Ejemplos de 250 Ana Ma López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado esta incorporación del 3D a los SIG son Google Earth o pequeñas funcionalidades para la generación de 3D a partir del barrido de la planta de las entidades espaciales añadidas a aplicaciones como MapInfo. Sin embargo, a la investigación en este tema todavı́a le queda un largo camino por recorrer. Por otro lado, hace ya tiempo que Internet se está convirtiendo en el medio de acceso a la información más utilizado. Diferentes comercios, empresas y organizaciones aprovechan esta situación para darse a conocer gracias a la red. Estar localizable a través de Internet es importante para captar clientes. Además, facilita a los usuarios la búsqueda de información. El objetivo principal de este capı́tulo era describir la metodologı́a seguida para desarrollar un prototipo de un Sistema de Información Geográfica que permitiese la obtención de información empresarial y la navegación en 2.5D en entornos urbanos, de manera que, a través de un simple navegador web, el usuario puediera buscar las distintas empresas de la ciudad por categorı́as, obtener información de ellas y localizarlas visualmente a distintos niveles de detalle, incluso llegando a situarlas en la planta correspondiente del edificio al que pertenecen. Tras llevar a cabo la metodologı́a descrita en la Sección 3, se ha conseguido obtener un prototipo que cumple los requisitos definidos al comienzo. No obstante, la aplicación deja bastantes lı́neas abiertas para su mejora. 5.2. Trabajo futuro El objetivo planteado en este capı́tulo ha sido cumplido. Sin embargo, todavı́a quedan muchos frentes abiertos y las posibilidades de mejora son muy amplias. A continuación se comentan una serie de puntos en los que se describen las lı́neas de trabajo futuro que se llevarán a cabo: Situar las empresas no sólo a nivel de planta sino teniendo en cuenta también la estructura interior del edificio: En el LOD más detallado del prototipo se sitúa la empresa en su planta correspondiente, asignándole el centro de la geometrı́a del edificio. Otra mejora relativa a esta geocodificación serı́a situar el comercio no sólo en la planta a la que pertenece, sino colocarlo también en el propio local, dependiendo de la puerta a la que pertenezca (por ejemplo, 3o A, o 6o B). Para poder implementar esto serı́a necesario conocer también la geometrı́a interior de cada edificio. Aumentar la capacidad de navegación dentro del entorno urbano: En este prototipo el nivel de navegación proporcionado en las escenas es bastante limitado: únicamente es posible hacer zoom y girar la escena para poder visualizarla por completo. Sin embargo, una buena mejora serı́a proporcionar una mayor capacidad de navegación, en la que el usuario pudiera moverse a nivel de peatón entre los distintos edificios y manzanas de la escena. Para ello habrı́a que tener en cuenta la topologı́a de las calles y limitar las posibilidades de movimiento del usuario a las trayectorias que corresponden a la información espacial de dichas calles. SIG urbanos en 3D para aplicaciones comerciales 251 Migración de la aplicación a WebGL: Como se ha mencionado anteriormente, Google abandonó su proyecto de O3D para centrarse en colaborar con WebGL, que promete convertirse en el estándar de visualización Web al integrarse perfectamente con HTML5. Para adaptar el prototipo a la tendencia actual se deberı́a migrar la aplicación a WebGL. Posibilidad de visualizar los distintos niveles de detalle de cualquier punto del plano: El prototipo obtenido es capaz de visualizar el entorno de manzanas cercano a una empresa o comercio especı́fico. Es decir, es necesario seleccionar un comercio concreto para poder pasar a la siguiente vista. Una opción que mejorarı́a la funcionalidad del sistema serı́a poder mostrar el entorno cercano de cualquier punto, sin importar si existe o no una empresa en dicha localización. De esta forma, el usuario podrı́a escoger un punto cualquiera del mapa y visualizar el entorno que lo rodea. En definitiva, son muchas las mejoras que se pueden proponer, al igual que ocurre con todo sistema software. Sin embargo, este prototipo cumple los objetivos planteados, ası́ como los requisitos definidos al comienzo. Referencias 1. Abdul-Rahman, A.: The design and implementation of two and three-dimensional triangular irregular network (tin) based gis. Ph.D. thesis, University of Glasgow, UK. (2000) 2. Abdul-Rahman, A., Pilouk, M.: Spatial Data Modelling for 3D GIS, 1st edn. Springer Publishing Company, Incorporated (2007) 3. Baillard, C., Zisserman, A.: A plane-sweep strategy for the 3D reconstruction of buildings from multiple images. In: ISPRS Congress and Exhibition. Amsterdam (2000) 4. Bosque Sendra, J.: Sistemas de información geográfica, 2 a ed. edn. Rialp, Madrid (2000) 5. de Cambray, B.: Three-dimensional (3d) modelling in a geographical database. In: in Proceedings of the 11 th International Symposium on Computer-Assisted Cartography, AutoCarto’11, pp. 338–347 (1993) 6. Cheng, C., Rau, J., Chou, Y., WT, C.: Web-based 3-d gis for location query in real estate application. In: Proceedings of the 7th FIG Regional Conference. Spatial Data Serving People: Land Governance and the Environment - Building the Capacity. Hanoi, Vietnam (2009) 7. Coors, V.: 3d-gis in networking environments. Computers, Environment and Urban Systems 27(4), 345 – 357 (2003). DOI 10.1016/S0198-9715(02)00035-2 8. Coors, V., Flick, S.: Integrating levels of detail in a web-based 3d-gis. In: Proceedings of the 6th ACM international symposium on Advances in geographic information systems, GIS ’98, pp. 40–45. ACM, New York, NY, USA (1998). DOI 10.1145/288692.288701 9. Davis, S.: GIS for Web Developers: Adding Where to Your Web Applications. Pragmatic Bookshelf, Raleigh, NC (2007) 10. Emgard, L., Zlatanova, S.: Implementation alternatives for an integrated 3d information model. In: P. Oosterom, S. Zlatanova, F. Penninga, E.M. Fendel (eds.) Advances in 3D Geoinformation Systems, Lecture Notes in Geoinformation and Cartography, pp. 313–329. Springer Berlin Heidelberg (2008) 11. Kada, M., Haala, N., Becker, S.: Improving the realism of existing 3d city models. In: 3D-GIS, pp. 405–415 (2006) 12. Köninger, A., Bartel, S.: 3d-gis for urban purposes. GeoInformatica 2, 79–103 (1998) 252 Ana Ma López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado 13. Lee, J.: 3d gis for geo-coding human activity in micro-scale urban environments. In: M.J. Egenhofer, C. Freksa, H.J. Miller (eds.) Geographic Information Science, Lecture Notes in Computer Science, vol. 3234, pp. 162–178. Springer Berlin / Heidelberg (2004) 14. Lewis, A., Purvis, M., Sambells, J., Turner, C., Lewis, A., Purvis, M., Sambells, J., Turner, C.: Geocoding addresses. In: Beginning Google Maps Applications with Rails and Ajax, pp. 69–96. Apress (2007) 15. de la Losa, A., Cervelle, B.: 3d topological modeling and visualisation for 3d gis. Computers & Graphics 23(4), 469 – 478 (1999). DOI 10.1016/S0097-8493(99)00066-7 16. MapInfo, C.: MapInfo Professional User Guide. MapInfo Corporation (2003) 17. Moser, J., Albrecht, F., Kosar, B.: Beyond visualisation: 3d gis analyses for virtual city models. In: 5th International Conference on 3D GeoInformation, vol. XXXVIII-4/W15, pp. 143–146 (2010) 18. Pilouk, M.: Integrated modelling for 3d gis. Ph.D. thesis, ITC, The Netherlands (1996) 19. Raper, J.F., Maguire, D.J.: Design models and functionality in gis. Computers & Geosciences 18(4), 387 – 394 (1992). DOI 10.1016/0098-3004(92)90067-2 20. Stoter, J., Salzmann, M.: Towards a 3d cadastre: where do cadastral needs and technical possibilities meet? Computers, Environment and Urban Systems 27(4), 395 – 410 (2003). DOI 10.1016/S0198-9715(02)00039-X 21. Sturm, P.F., Maybank, S.J.: A method for interactive 3d reconstruction of piecewise planar objects from single images. In: In Proc. BMVC, pp. 265–274 (1999) 22. Teo, T.A., Rau, J.Y., Chen, L.C., Liu, J.K., Hsu, W.C.: Reconstruction of complex buildings using lidar and 2d maps. In: 3D-GIS, pp. 345–354 (2006) 23. Zabrodsky, H., Weinshall, D.: Using bilateral symmetry to improve 3d reconstruction from image sequences. Computer Vision and Image Understanding 67(1), 48 – 57 (1997). DOI 10.1006/cviu.1996.0506 24. Zandbergen, P.A.: A comparison of address point, parcel and street geocoding techniques. Computers, Environment and Urban Systems 32(3), 214 – 232 (2008). DOI 10.1016/j.compenvurbsys.2007.11.006 25. Zlatanova, S., Abdul Rahman, A., Pilouk, M.: 3d gis: Current status and perspectives. In: Proceedings of the Joint Conference on Geo-spatial theory, Processing and Applications (2002) 26. Zlatanova, S., Abdul Rahman, A., Pilouk, M.: Trends in 3d gis development. Journal of Geospatial Engineering pp. 1–10 (2002) 27. Zlatanova, S., Tempfli, K.: Modelling for 3d gis: Spatial analysis and visualisation through web. In: Proc of IAPRS, vol. XXXIII, pp. 1257–1264 (2000) MOSES: aplicación software para la gestión de modelos de edificios Bernardino Domı́nguez Martı́n, Francisco de A. Conde Rodrı́guez, Ángel Luis Garcı́a Fernández, Francisco R. Feito Higueruela Resumen Los Sistemas de Información Geográfica están evolucionando hacia sistemas donde los datos están distribuidos en una escena 3D con la que los usuarios pueden interactuar. Por tanto, es necesario disponer de aplicaciones software para crear y mantener contenidos digitales urbanos y arquitectónicos de manera sencilla. Aquı́ tratamos los requerimientos y el diseño de la interfaz de una herramienta para hacer más sencilla la creación, validación y refinamiento de contenidos de interiores tomando como datos de entrada planos vectoriales de plantas de edificios. 1. Introducción La Informática Gráfica está cada dı́a más integrada en nuestra vida diaria. Su influencia está cambiando la forma en que nos entretenemos, investigamos o hacemos negocios. Por ejemplo: es posible visualizar los resultados de un proceso de ingenierı́a que podrı́a estar llevándose a cabo a miles de quilómetros de distancia y analizarlos ası́ fácilmente. Otros ejemplos de aplicaciones de Informática Gráfica son aquellos que ofrecen a los usuarios la visualización de entornos urbanos y/o tours virtuales por edificios c c interesantes: herramientas como Google Earth o Microsoft Virtual Earth permiten a los usuarios ver modelos 3D georreferenciados de edificios y monumentos que están almacenados en servidores remotos. También hay sitios web que permiten navegar por el interior de museos, universidades, empresas, etcétera. Sin embargo, para poder ofertar este tipo de aplicaciones es necesario crear en primer lugar los contenidos 3D que se van a mostrar. Dependiendo de la aplicación, los modelos pueden ser únicamente cajas vacı́as que representen la apariencia externa de los edificios, o modelos detallados de los interiores de dichos edificios. Este B. Domı́nguez, F.Conde, Á.L. Garcı́a, F.R. Feito Departamento de Informática. Universidad de Jaén e-mail: {bdmartin,fconde,algarcia,ffeito}@ujaen.es 253 254 B. Domı́nguez, F. Conde, Á.L. Garcı́a y F.R. Feito último tipo de modelos suele crearse manualmente, utilizando herramientas como el R R c 3ds Max de Autodesk , Google SketchUp Pro o Blender; estas aplicaciones permiten importar planos CAD 2D en algún formato popular (normalmente DXF o DWG), y a partir de esa información es necesario hacer un trabajo manual para crear los modelos 3D correspondientes [2]. En todo este proceso es fundamental tener la información CAD estructurada correctamente en capas, ya que mucha de esa información no es relevante para crear los modelos (por ejemplo: la localización de la instalación de fontanerı́a no es relevante para una vista 3D de una sala de un museo). Si el plano CAD está estructurado en capas, es posible seleccionar sólo aquellas que contienen información necesaria. Serı́a por tanto deseable disponer de una aplicación que pudiera crear automáticamente un modelo de interior a partir de un plano de planta; esto es: paredes, puertas, ventanas, habitaciones, pasillos, etcétera. Los modelos de información de edificios 1 creados de esta manera podrı́an servir para aplicaciones de visitas virtuales, ası́ como otro tipo de aplicaciones tales como simulación de iluminación, acústica o de incendios [9], o incluso juegos [12]. Yin y otros publicaron recientemente un estudio sobre métodos para generar este tipo de modelos [13]. Todos estos métodos intentan ser independientes de la geometrı́a del plano; sin embargo, la mayorı́a de las veces es necesario corregir el resultado manualmente. En este capı́tulo se hace una pequeña introducción para explicar algunos conceptos sobre el problema; luego se presentan los requerimientos que una aplicación para la detección semiautomática de elementos semánticos en un plano deberı́a cumplir. Además, también se trata el diseño de la interfaz para esta aplicación. Todo este proceso de análisis es necesario para llevar a cabo el desarrollo de una aplicación que pueda ser aceptada por usuarios que normalmente no serán profesionales de la Informática, sino de Arquitectura e Ingenierı́a. 2. Conceptos previos Como la aplicación software que se quiere desarrollar está centrada en la carga y procesamiento de planos arquitectónicos almacenados en formato DXF, esta sección repasa algunos conceptos básicos sobre el formato DXF y cómo tendrı́a que procesarse teniendo en cuenta el objetivo final. En la documentación técnica de R Autodesk se puede encontrar una descripción detallada del formato [1]. 1 Building Information Models o BIMs a partir de ahora MOSES: aplicación software para la gestión de modelos de edificios 2.1. 255 Estructura de un fichero DXF Las tres unidades principales de información en un fichero DXF son las capas, los bloques y las entidades. Otros conceptos como clases y tablas no son útiles en este caso, ası́ que no se revisarán aquı́. Entidades: la entidad es la unidad mı́nima de información en un plano en DXF. Los tipos básicos de entidades son: lı́neas, definidas por sus puntos de inicio y fin, arcos de circunferencia, definidos por el centro de la circunferencia, el radio y los ángulos de inicio y fin, polilı́neas como secuencias de puntos unidos por segmentos rectos o curvos, e inserciones, que son instancias de bloques (definidos a continuación) colocados en una posición concreta y modificados por un factor de escalado y un ángulo de rotación. Bloques: son definiciones abstractas de elementos dibujables, descritos en un sistema de coordenadas local y formados por entidades de las descritas anteriormente. Cada fichero DXF incluye en su cabecera la definición de los bloques que posteriormente se instancian. Los bloques se usan para agrupar elementos que se repiten habitualmente (ventanas, puertas, elementos de mobiliario, equipamientos de baño, etcétera). Cada bloque tiene un nombre único en el fichero. Capas: son agrupaciones lógicas de entidades de un plano. Para cada capa se define un color, tipo y estilo de lı́nea, etcétera, que definen el aspecto con el que se dibujará. Las capas se utilizan para agrupar elementos que tienen el mismo significado (paredes, columnas, aberturas, muebles, instalaciones eléctricas, equipamiento de baño, escaleras y ascensores, comunicaciones, fontanerı́a...). Cada capa tiene un nombre único en el fichero. Un fichero DXF se estructura como sigue: empieza con algunas definiciones de clases y tablas; luego aparecen las definiciones de los bloques que se van a utilizar; finalmente, aparece la información sobre las capas y entidades del plano. 2.2. Estructura estándar de un plano La estructura de un fichero DXF no limita de ninguna manera cómo debe organizarse un plano real de la planta de un edificio, o lo que es lo mismo: el formato define la estructura de un dibujo, no la semántica de un plano. Es por esto que se hace necesario establecer algunas pautas a seguir a la hora de dibujar un plano para que los algoritmos que lo procesen funcionen correctamente. Las pautas que se fijan son las siguientes: Debe haber al menos tres capas: una para las aberturas, otra para las paredes, y una tercera para las escaleras. El nombre de estas capas no es relevante. Las paredes se dibujan utilizando lı́neas simples sin información de conectividad. Como tienen grosor, cada pared se dibuja con un par de lı́neas, sin ningún tipo de información topológica asociada. 256 B. Domı́nguez, F. Conde, Á.L. Garcı́a y F.R. Feito Las aberturas (puertas y ventanas) se definen como bloques. Cada bloque estará alineado con su sistema de coordenadas local, mientras que sus instancias estarán trasladadas, rotadas y escaladas cuanto sea necesario. El nombre de los bloques no es relevante. En este trabajo se considera que las columnas están integradas en la capa de paredes. Otras posibilidades se estudiarán en el futuro. 2.3. Detección de elementos semánticos Para este proceso, se introduce el concepto de punto clave como entidad semántica para representar las principales caracterı́sticas detectadas en un plano; esto es: ventanas, puertas, tramos de escaleras e intersecciones entre paredes [5]. En cuanto a las intersecciones entre paredes, hay varios tipos de puntos clave, dependiendo del número de paredes que se intersectan, y de si las paredes son tabiques (por tanto de menor grosor) o muros exteriores (mayor grosor): Punto clave L entre tabiques Punto clave L entre muros exteriores Punto clave T entre tabiques Punto clave T entre tabique y muro exterior Cada ventana, puerta y tramo de escaleras se representa también mediante un punto clave. El siguiente algoritmo procesa las capas seleccionadas de un plano para detectar el conjunto de puntos clave. 2.3.1. Detección y corrección de irregularidades Un paso previo para el resto de algoritmos es la detección y corrección de irregularidades. Los segmentos del plano se procesan automáticamente para detectar y eliminar lı́neas duplicadas, lı́neas de longitud cero y lı́neas que están contenidas en otras lı́neas. Este proceso se aplica una sola vez, y el resultado que produce se usa como entrada para el resto de algoritmos. 2.3.2. Detección de paredes En primer lugar, este proceso busca los pares de segmentos paralelos y suficientemente próximos como para poder ser representaciones de paredes. Luego los trocea para obtener pares cuyas respectivas proyecciones de uno sobre otro coinciden completamente; estos pares se consideran representaciones de paredes. Finalmente, calcula el segmento que pasa por el medio de cada par. MOSES: aplicación software para la gestión de modelos de edificios 2.3.3. 257 Agrupamiento El conjunto de puntos clave de las paredes se calcula aplicando algoritmos de clustering sobre los extremos de los segmentos calculados en la etapa anterior. Cada cluster contendrá los extremos de los segmentos que representan paredes adyacentes, y el representante del cluster se considera como punto clave de pared. El conjunto de puntos clave se completa con los correspondientes a las puertas y ventanas. Almacenando en un grafo la información de conectividad entre paredes es posible detectar habitaciones cerradas. 2.3.4. Detección de escaleras El algoritmo para detectar escaleras se basa en la misma idea que el de detección de paredes: basta buscar conjuntos de segmentos paralelos y equidistantes en la capa de escaleras. 2.3.5. Detección de puntos clave y habitaciones utilizando reglas Este proceso utiliza un conjunto de reglas para encontrar puntos clave. Para cada instancia de puerta se crea un punto clave, y siguiendo en sentido horario los pares de segmentos de la capa de paredes que están en posiciones adyacentes a dicho punto, se detectan habitaciones cerradas. Cada vez que en este recorrido se llega al final de un par, y dependiendo de la configuración geométrica, se aplica una regla para encontrar la posición y tipo del siguiente punto clave y el siguiente par de segmentos a seguir. Cuando se llega al punto de partida, los puntos clave detectados forman una habitación cerrada [4]. 3. Requerimientos de la aplicación El proceso clásico de la Ingenierı́a de Software consta de tres etapas: análisis, diseño e implementación. El objetivo de la fase de análisis es obtener una descripción lo más detallada posible de lo que necesita el usuario y las capacidades que el software debe poseer para cubrir esas necesidades. Esta es una etapa clave en el proceso, puesto que el resto de etapas dependen de su resultado. Aquı́ se describen los requerimientos de la aplicación. En primer lugar, se enumeran las caracterı́sticas básicas que debe poseer la aplicación: Debe ser capaz de cargar planos de plantas almacenados en un formato ampliaR mente aceptado. El formato DXF de Autodesk es una buena opción, puesto que se diseñó pensando en el intercambio de información entre aplicaciones CAD, y hoy en dı́a es muy utilizado [1]. 258 B. Domı́nguez, F. Conde, Á.L. Garcı́a y F.R. Feito Como la aplicación va a manejar dibujos arquitectónicos cuya información suele estar dividida en capas, es necesario permitir al usuario elegir qué capas contienen información relevante sobre los elementos arquitectónicos a detectar. El software debe permitir al usuario seleccionar los bloques que contienen información importante sobre los elementos a detectar. Es necesario extraer de los planos información relativa a elementos arquitectónicos como paredes, habitaciones, pasillos, escaleras, puertas o ventanas, de manera que se puedan generar los elementos 3D correspondientes. Esto implica obtener el significado semántico de diferentes conjuntos de elementos geométricos (curvas, lı́neas, puntos arcos, inserciones, ...) que se incluyen en el plano. La información semántica obtenida tras el proceso de detección ha de almacenarse en una base de datos, para que la creación de objetos 3D pueda llevarse a cabo fácilmente y cuantas veces sea necesaria a partir de un único análisis. Como el objetivo de esta aplicación es muy especı́fico, sus usuarios no van a ser de cualquier tipo, sino que serán personas familiarizadas con trminologı́a y conceptos propios de arquitectura e ingenierı́a. Estos usuarios estan acostumbrados a trabajar con ordenadores, y especialmente con software de CAD/CAM y su filosofı́a de trabajo en capas. Otras caracterı́sticas deseables para mejorar la experiencia de uso son las siguientes: La aplicación permitirá tratar cada planta de un edificio como un proyecto. Un proyecto puede guardarse y cargarse posteriormente. El usuario podrá seleccionar y/o deseleccionar capas y bloques a su antojo. La información semántica detectada podrá visualizarse sobre el plano original para poder comprobar su corrección. El proceso de detección será semiautomático. Esto es: el usuario podrá personalizar la forma en que se aplican los algoritmos de detección, ası́ como seleccionar áreas en el plano para las que se definan distintos valores de los parámetros de detección. Además, en algunos casos será necesario recurrir a la intervención del usuario para resolver situaciones ambiguas o inesperadas. Todas las acciones del usuario podrán deshacerse, de tal forma que se puedan compensar posibles errores en el uso de la aplicación. 4. Análisis de la aplicación La interfaz de una aplicación es fundamental para que ésta sea exitosa. Debe proporcionar al usuario medios eficientes, intuitivos y fáciles de aprender para obtener los resultados que desea, explotando al máximo las capacidades del software. Esta sección se centra en los requerimientos y caracterı́sticas que la interfaz de usuario de la aplicación debe cumplir. Ası́ mismo, se plantean algunas soluciones efectivas para cumplir con dichos requerimientos. MOSES: aplicación software para la gestión de modelos de edificios 4.1. 259 Análisis de tareas El proceso de diseño de la interfaz de usuario de una aplicación requiere de un análisis detallado de las tareas que ésta va a permitir, en el cual se recogerán todas las acciones del usuario que producen cambios en el estado de la aplicación. Teniendo en cuenta esto, y que para hacer más flexible la interacción se han separado la selección de parámetros y la ejecución de los algoritmos, se consideran las siguientes tareas: 1. Crear un nuevo proyecto: la aplicación finaliza todos los procesos que estuvieran en marcha (permitiendo guardar o descartar los últimos cambios realizados si procede) y prepara el entorno para introducir una nueva planta. 2. Cargar un proyecto existente: la aplicación lee los datos de un proyecto existente y almacenado previamente en un fichero, y muestra en una ventana toda la información sobre la planta que representa. 3. Cerrar proyecto: la aplicación cierra el proyecto actual, permitiendo al usuario guardar o descartar los últimos cambios realizados. 4. Guardar proyecto: la aplicación guarda el proyecto actual. Si es la primera vez que se guarda el proyecto, se solicita al usuario un nombre de fichero. 5. Guardar proyecto como: misma tarea que la anterior, pero pidiendo siempre un nombre de fichero, incluso si el proyecto ya se habı́a guardado anteriormente. 6. Salir: la aplicación termina, permitiendo al usuario guardar o descartar los últimos cambios que no hayan sido guardados. 7. Cargar fichero DXF: la aplicación carga y analiza un fichero DXF seleccionado por el usuario, y visualiza su contenido en la ventana. Se muestran dos listas conteniendo los nombres de las capas y los bloques. 8. Cambiar las capas seleccionadas: la aplicación permite al usuario seleccionar algunos elementos de la lista de capas. El dibujo se actualiza para mostrar sólo las entidades contenidas en las capas seleccionadas. 9. Ver la definición de un bloque: antes de ejecutar algunos algoritmos, es necesario que el usuario seleccione los nombres de los bloques que han de detectarse. A través de esta tarea, el usuario puede ver el aspecto visual de cada bloque, y ası́ estar seguro de su elección. 10. Cambiar el zoom: la aplicación actualiza el dibujo cuando el usuario indica un nuevo valor de zoom. 11. Pan: la aplicación actualiza el dibujo cuando el usuario hace clic con el ratón y arrastra el dibujo dentro de la ventana. 12. Seleccionar área: el usuario selecciona un área rectangular del dibujo. Luego, la aplicación calcula y almacena las entidades seleccionadas. Esta selección será tenida en cuenta para la ejecución de los algoritmos. 13. Cambiar la selección de capas para paredes, aberturas y tramos de escaleras: el usuario selecciona algunos elementos de la lista de capas para que sean consideradas como capas de paredes, aberturas o escaleras por los algoritmos de detección. 260 B. Domı́nguez, F. Conde, Á.L. Garcı́a y F.R. Feito 14. Cambiar la selección de bloques para aberturas: el usuario selecciona algunos elementos de la lista de bloques para que sean considerados como bloques de puertas o ventanas por los algoritmos de detección. 15. Cambiar el umbral para la detección de paredes: el usuario indica un nuevo valor para este umbral. 16. Cambiar el umbral para el clustering de puntos: el usuario indica un nuevo valor para este umbral. 17. Aplicar el umbral para la detección de paredes y la extracción de puntos: previamente a esta tarea, es necesario haber seleccionado la/s capas con la información de paredes y aberturas, los bloques que representan aberturas, y haber fijado el umbral de detección de paredes. Opcionalmente, puede existir un área seleccionada. En esta tarea se lanzan los algoritmos para la detección de paredes y puntos (Sección 2.3.2). 18. Aplicar el umbral para el agrupamiento de puntos: una vez que se ha construido el conjunto preliminar de puntos, se lanza el algoritmo de clustering de puntos (Sección 2.3.3). 19. Aplicar el umbral para la detección de escaleras: si las capas con información de escaleras y el umbral de anchura están seleccionados, se lanza el algoritmo de detección de escaleras (Sección 2.3.4). 20. Detección de puntos basada en reglas: se lanza el algoritmo de detección de puntos clave utilizando reglas, siempre que todos los parámetros mencionados anteriormente hayan sido previamente fijados (Sección 2.3.5). 21. Añadir un punto clave: la aplicación coloca un nuevo punto clave en el plano. El usuario selecciona su tipo y ubicación haciendo clic con el ratón en un punto del plano o introduciendo sus coordenadas. 22. Borrar un punto clave: la aplicación borra un punto clave seleccionado por el usuario. 23. Cambiar el tipo de un punto clave: la aplicación cambia el tipo de un punto clave seleccionado por el usuario. 24. Mover un punto clave: la aplicación mueve un punto clave cuando el usuario hace clic con el ratón sobre él y lo arrastra o indica sus nuevas coordenadas con el teclado. 25. Añadir habitación: la aplicación añade una nueva habitación al modelo como un conjunto ordenado de puntos clave seleccionados por el usuario. 26. Borrar habitación: la aplicación borra una habitación seleccionada por el usuario. 27. Exportar la planta a la base de datos: la aplicación almacena la planta actual en una base de datos, con toda la información detectada por los algoritmos. La planta se guarda como parte de un edificio. 28. Borrar una planta de la base de datos: la aplicación borra una planta de un edificio de la base de datos. 29. Borrar un edificio de la base de datos: la aplicación borra un edificio y todas sus plantas de la base de datos. MOSES: aplicación software para la gestión de modelos de edificios 4.2. 261 Estructura de las tareas Es necesario describir el proceso completo de realización de cada tarea desde el momento en que el usuario la inicia hasta que se termina, de manera análoga a como se hace al describir casos de uso, incluyendo ası́ los pasos de la interacción entre el usuario y el sistema. Normalmente, una tarea tiene la siguiente estructura: (1) el usuario lanza la tarea interactuando con la aplicación; (2) la aplicación pide al usuario los parámetros necesarios para ejecutar la tarea; (3) se ejecuta la tarea, y el resultado se muestra a través de la interfaz de la aplicación. Por ejemplo, la tarea 17 se describirı́a ası́: 1. El usuario inicia la tarea al hacer clic en un botón de la interfaz. 2. La aplicación ejecuta el algoritmo de detección de paredes en las capas y bloques seleccionados, utilizando los umbrales especificados previamente por el usuario. 3. La interfaz muestra el resultado de la ejecución del algoritmo. 4.3. Arquitectura de la interacción En esta fase se analiza cómo se combinan las tareas descritas anteriormente, de forma que se construye una lógica de interacción consistente. Después de este análisis, se definen los caminos permitidos en el flujo de la interacción con el usuario, evitando ası́ la posibilidad de que aparezcan algunos errores en la implementación de la aplicación. El análisis de la arquitectura de la interacción tiene dos etapas: Construir un árbol jerárquico con todas las tareas del sistema (distintas de las tareas relacionadas con los usuarios y mencionadas anteriormente). La raı́z del árbol es un nodo que representa a la aplicación completa, mientras que el siguiente nivel representa las tareas que forman parte del cauce principal de ejecución. Los niveles inferiores representan los cauces que siguen cada una de las tareas representadas. Es posible que para llevar a cabo una tarea no haga falta seguir todas sus tareas hijas secuencialmente, por tanto, es necesario definir el conjunto de caminos de ejecución permitidos para cada tarea que no ocupa un nodo hoja en el árbol. La interfaz de usuario ha de diseñarse de acuerdo con estos caminos, activando o desactivando controles según corresponda. Otro tema importante es determinar los estados de espera activa, provocados por aquellas tareas que tienen un tiempo de ejecución largo durante el cual el usuario no puede hacer nada. Estos estados deben tenerse en cuenta mientras se diseña e implementa la aplicación, porque cuando la aplicación esté en esos estados deberá proporcionar al usuario información sobre qué está pasando, ası́ como permitirle cancelar el trabajo, manteniéndose en un estado consistente. 262 B. Domı́nguez, F. Conde, Á.L. Garcı́a y F.R. Feito El resultado del análisis de la arquitectura de la interacción se plasma en el ası́ llamado diagrama HTA2 [3]. El diagrama HTA para esta aplicación es el siguiente: 0. Aplicación para edición de edificios 1. Nuevo proyecto 2. Abrir un proyecto 2.1. Elegir el proyecto 2.2. Esperar a la carga del proyecto 3. Guardar el proyecto 4. Guardar el proyecto como 5. Editar un proyecto 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. 5.9. Cargar un fichero DXF Cambiar la selección de capas Cambiar la selección de bloques representando puertas y ventanas Cambiar los valores de umbral Ver un bloque Cambiar el zoom Pan Seleccionar un área Detección de habitaciones 5.9.1. Cambiar la selección de capas y bloques para los algoritmos 5.9.2. Detección de irregularidades 5.9.3. Detección de paredes 5.9.4. Detección de puntos clave 5.9.5. Búsqueda de vértices 5.9.6. Agrupamiento 5.9.7. Detección de escaleras 5.10. Posprocesamiento semiautomático 5.10.1. Añadir un punto clave 5.10.2. Borrar un punto clave 5.10.3. Cambiar el tipo de un punto clave 5.10.4. Mover un punto clave 5.10.5. Añadir una habitación 5.10.6. Borrar una habitación 6. Cerrar el proyecto 7. Gestión de la base de datos 7.1. Exportar la planta a la base de datos 7.2. Borrar una planta de la base de datos 7.3. Borrar un edificio de la base de datos 8. Salir 2 Hierarchical Task Analysis MOSES: aplicación software para la gestión de modelos de edificios 263 El último paso del estudio de la arquitectura de la interacción consiste en especificar los caminos permitidos para tareas no atómicas (situadas en nodos intermedios del árbol). Estos caminos se representarán utilizando expresiones regulares, de forma que la concatenación de tareas implica su ejecución secuencial, la barra (|) separa alternativas, y el asterisco (*) detrás de una tarea o grupo de tareas indica que se pueden repetir una o más veces, o incluso ninguna. La tarea Abrir un proyecto (2) es siempre secuencial, ası́ que su camino permitido es 2 → 2.1 2.2 La tarea Editar un proyecto (5) siempre empieza por la subtarea Cargar un fichero DXF (5.1). Luego se puede realizar cualquier otra subtarea del mismo nivel. Por tanto, el camino permitido para esta tarea es 5 → 5.1 ( 5.2 | 5.3 | 5.4 | 5.5 | 5.6 | 5.7 | 5.8 | 5.9 | 5.10 )* Asumiendo que no hay ninguna selección inicial, la tarea Detección de habitaciones (5.9) empezará siempre por la subtarea Cambiar la selección de capas y bloques para los algoritmos (5.9.1). Luego se puede realizar cualquiera de las subtareas del mismo nivel, incluyendo la antes mencionada. Ası́, el camino permitido es 5.9 → 5.9.1 ( 5.9.1 | 5.9.2 | 5.9.3 | 5.9.4 | 5.9.5 | 5.9.6 | 5.9.7 )* Se permiten todos los posibles caminos para la tarea Posprocesamiento semiautomático: 5.10 → ( 5.10.1 | 5.10.2 | 5.10.3 | 5.10.4 | 5.10.5 | 5.10.6 )* También se permiten todos los posibles caminos para la tarea Gestión de la base de datos: 7 → ( 7.1 | 7.2 | 7.3 )* Es más complicado representar los caminos de ejecución permitidos para la aplicación completa, ya que éstos dependen del estado de la aplicación. No es sencillo crear una expresión regular apropiada si se quieren evitar situaciones tales como guardar un proyecto que no ha sido modificado o editar un proyecto cuando no hay ningún proyecto abierto. En lugar de esto, se muestra un diagrama de estado que modela los caminos permitidos. La definición de los estados de la aplicación se basa en tres parámetros: (1) si hay un proyecto abierto o no, (2) si el proyecto tiene asignado un nombre de fichero o no, y (3) si el proyecto ha sido modificado o no. Estos tres parámetros definen ocho posibles estados de la aplicación, de los cuales sólo cinco son válidos, puesto que cuando no hay abierto un proyecto, los otros dos parámetros no tienen sentido. A estos cinco estados se les añaden dos estados más: un estado de error al que se llega por cualquier camino no permitido (de esta forma se asegura la completitud del diagrama), y un estado final, al que se llega cuando la aplicación termina. La Tabla 1 resume estos estados. Las tareas 1 a 8 del diagrama HTA definen las transiciones entre los estados. La Tabla 2 muestra para cada par estado/tarea el nuevo estado resultante. 4.4. Arquitectura cliente-servidor Esta aplicación es parte de un sistema cliente-servidor para la generación, gestión y visualización de información de interiores. Este sistema permite almacenar no 264 B. Domı́nguez, F. Conde, Á.L. Garcı́a y F.R. Feito Tabla 1 Resumen de estados Proyecto abierto Proyecto con nombre asignado Proyecto modificado No Irrelevante Irrelevante Sı́ No No Sı́ No Sı́ Sı́ Sı́ No Sı́ Sı́ Sı́ Estado de error Estado final (la aplicación termina) Estado q1 q2 q3 q4 q5 qE qF Tabla 2 Transiciones entre estados Tareas 1 2 3 4 5 6 7 8 q1 q2 q4 qE qE qE qE q1 qF q2 q2 q4 qE qE q3 q1 q2 qF Estados q3 q4 q5 q2 q2 q2 q4 q4 q4 q4 qE q4 q4 q4 q4 q3 q5 q5 q1 q1 q1 q3 q4 q5 qF qF qF qE qE qE qE qE qE qE qE qE qF qF qF qF qF qF qF qF qF sólo la geometrı́a y la topologı́a de la escena, sino también otros datos que se pueden añadir al resultado final para proporcionar al usuario datos adicionales conforme navega por la misma. Como se hace uso de una base de datos para el almacenamiento, es posible separar los procesos de extracción de información y generación del modelo 3D, y por tanto se hace más fácil ampliar el sistema incluyendo distintos formatos de salida de datos sólo con cambiar el módulo que genera la salida. El sistema se basa en la arquitectura cliente-servidor, como se muestra en la Figura 1. El servidor procesa los planos de las plantas y extrae la información necesaria para generar el modelo 3D. Esta información se guarda en una base de datos que opcionalmente puede guardar datos adicionales sobre el edificio, tales como la ubicación de negocios, despachos, etcétera. Los clientes, por su parte, envı́an peticiones al servidor para recibir de éste una descripción detallada de la planta correspondiente del edificio que se esté visitando, codificada utilizando un formato de fichero 3D estándar, de tal forma que se pueda visualizar con un visor estándar o un navegador web debidamente configurado. 4.5. Estructura de la base de datos Se ha utilizado una base de datos relacional con datos espaciales para almacenar las caracterı́sticas significativas de los planos. Para gestionarla, se ha elegido el popular gestor de bases de datos MySQL, puesto que sus capacidades espaciales son MOSES: aplicación software para la gestión de modelos de edificios 265 Fig. 1 Flujo de trabajo del sistema propuesto suficientes para el propósito de esta aplicación, y además se ajustan a las especificaciones del Open Geospatial Consortium (OGC) [11, 10]. En esta base de datos no sólo se pueden almacenar datos de tipos estándar (enteros, reales, cadenas de texto, etcétera), sino también datos de tipo geométrico como puntos, polilı́neas o polı́gonos. Ası́ mismo, el gestor de bases de datos proporciona funciones espaciales que permiten operar con estos datos. La Figura 2 muestra una vista simplificada de la estructura de la base de datos. Los atributos y algunas relaciones se han omitido para facilitar la lectura del diagrama. Se han incluido otro tipo de relaciones en la base de datos para poder representar comportamientos jerárquicos entre los datos almacenados, de forma que es posible obtener información topológica mediante las consultas adecuadas. Dos elementos de naturaleza especial son los ascensores y los tramos de escaleras, que podrı́an asociarse a más de una planta simultáneamente. Sin embargo, se ha optado por replicarlos por cada planta que relacionan; esto supone cierta redundancia en la base de datos, pero como normalmente hay muy pocos elementos de estos tipos en un edificio, no es significativa. 5. 5.1. Diseño de la interfaz de usuario Diseño de ventanas En la etapa anterior del diseño se han definido las tareas a llevar a cabo por la aplicación, ası́ como la arquitectura de la interacción. El siguiente paso es por tanto 266 B. Domı́nguez, F. Conde, Á.L. Garcı́a y F.R. Feito Door Building 1 1 Window has 1 1 1 1 * has has Stairs part-of part-of * 1 1 Keypoint has * * Floor 1 1 1 part-of has 1 Room 1 has Elevator * 1 Corridor * part-of Fig. 2 Vista simplificada de la estructura de la base de datos el diseño de la interfaz de usuario. Se pueden aplicar las siguientes directrices al diseño de ventanas: La ventana principal de la aplicación contendrá controles para lanzar todas las tareas del primer nivel del diagrama HTA. Cada ventana secundaria, diálogo emergente, marco interno o pestaña contendrá controles para lanzar subtareas. Los caminos de ejecución prohibidos se evitarán mediante la desactivación de los controles correspondientes en la interfaz, de manera que se libera al usuario de la responsabilidad de elegir el camino correcto. La Figura 3 muestra la ventana principal de la aplicación. Esta ventana se ha dividido en varias zonas relacionadas con las tareas descritas en el diagrama HTA: la barra principal contiene botones para lanzar la mayorı́a de las tareas del primer nivel del diagrama, excepto la tarea Editar un proyecto, que se subdivide y se activa desde otros controles; concretamente, la tarea Cargar un fichero DXF está disponible desde la barra principal de la aplicación, mientras que las tareas Cambiar la selección de capas, Ver un bloque y Detección de habitaciones se lanzan desde pestañas situadas a la derecha de la ventana principal, y las tareas Cambiar el zoom, Pan y Seleccionar un área no se lanzan mediante controles, sino utilizando un dispositivo apuntador. La subtarea restante, Posprocesamiento semiautomático, se lleva a cabo utilizando botones de un marco interno. La interfaz incluye también una barra de menú estándar que organiza algunas de las tareas antes mencionadas utilizando los menús tı́picos: Archivo, Editar, Herramientas y Vista. MOSES: aplicación software para la gestión de modelos de edificios 267 8 1 2 3 4 6 5.1 7.1 7.2 7.3 5.2 5.10.1 5.10.2 5.10.3 5.10.5 5.9.1 5.10.6 5.10.4 5.9.6 5.9.3 5.9.5 5.9.2 5.9.7 5.9.4 2.1 5.2 5.5 Fig. 3 Ventana principal de la aplicación. Los números muestran desde dónde se lanza cada tarea del HTA 5.2. Diseño del modelo Como paso previo a la implementación, es necesario diseñar el sistema utilizando una metodologı́a adecuada. Para este objetivo, se ha utilizado la metodologı́a UML [6]. En esta sección se tratará en primer lugar la conveniencia de utilizar algunos patrones de diseño conocidos; luego se mostrará el diagrama UML para la aplicación completa. Para hacer este diseño, se han tenido en cuenta los siguientes principios: Los componentes de la aplicación deben estar delimitados claramente, para evitar ası́ el acoplamiento y hacer la implementación más sencilla. Modificaciones futuras de la aplicación no deberı́an provocar cambios en los componentes ya implementados, sino que bastará con añadir nuevos componentes dentro de la arquitectura existente. 5.2.1. Patrones de diseño Se han utilizado algunos patrones de diseño conocidos en el desarrollo de la aplicación [8, 7]. Éstos son: Modelo-Vista-Controlador, instrucción, estrategia, estado y observador. A continuación se resume brevemente qué es cada uno de ellos, y cómo se han utilizado en la aplicación. 268 B. Domı́nguez, F. Conde, Á.L. Garcı́a y F.R. Feito Patrón Modelo-Vista-Controlador La arquitectura Modelo-Vista-Controlador (MVC) se utiliza para dividir la aplicación en tres partes: una (el modelo) se encarga de manejar y procesar los datos; otra (la vista) gestiona la interfaz de usuario; la tercera (el controlador) dirige el intercambio de información entre el modelo y la vista. El flujo de control es como sigue: La vista captura las acciones del usuario sobre la interfaz, y notifica de las mismas al controlador. El controlador decide cómo procesar las acciones del usuario, y si es necesario, actualiza el modelo. La vista sólo tiene acceso de lectura al modelo, para que pueda actualizarse por sı́ misma. Cualquier cambio en el modelo se notifica a la vista utilizando el patrón observador (descrito más adelante). Patrón Estrategia El patrón estrategia permite elegir entre distintas implementaciones de un algoritmo o una clase. Para cada algoritmo o clase para los que hay varias implementaciones posibles se define una clase estrategia, y las implementaciones concretas se encapsulan en subclases de ésta. Un objeto contexto contiene la información que permite decidir qué implementación se utiliza en cada ocasión. En el diseño de esta aplicación se ha utilizado este patrón en dos tipos de situaciones: El modelo, la vista y el controlador son estrategias. Esto permite en el caso del modelo, distinguir entre el comportamiento (las operaciones soportadas por el modelo) y la representación interna de los datos; en el caso de la vista, posibilita el poder cambiar la interfaz de usuario sin importar el modelo utilizado. La implementación del controlador, por su parte, ha de ser coherente con las del modelo y la vista. Algunos de los algoritmos para la detección de caracterı́sticas a partir de planos de plantas están todavı́a en desarrollo. En esta situación, el uso del patrón estrategia es muy útil para poder probar fácilmente distintos algoritmos para el mismo problema. Patrón Instrucción En los requerimientos de la aplicación se indicaba que para hacerla más flexible era necesario que se permitiera al usuario deshacer/rehacer sus acciones, y para hacer esto se utiliza el patrón instrucción. Hace falta identificar cada instrucción, definiendo cómo se hace, se deshace y se rehace, y determinando qué información hay que almacenar para cada una de estas actividades. El patrón instrucción se aplica de la siguiente forma: MOSES: aplicación software para la gestión de modelos de edificios 269 Hay una clase abstracta que modela el comportamiento de una instrucción genérica, y que contiene los métodos hacer y deshacer. Cada instrucción se encapsula en una subclase de la anterior que contendrá los parámetros necesarios para rehacer la instrucción. Se mantiene un registro de las instrucciones ejecutadas, deshechas y rehechas en una pila. Se permite deshacer la última instrucción ejecutada y rehacer la última instrucción deshecha. Patrón Observador Para que el patrón MVC funcione correctamente, es necesario que la vista sea informada de los cambios en el modelo. No serı́a eficiente hacer que la vista interrogara al modelo cada cierto tiempo para actualizarse, y no es buena idea que el modelo llame directamente a métodos de la vista. En esta situación se aplica el patrón observador. En este patrón intervienen dos elementos: el observador, que espera notificaciones de eventos, y el sujeto, que es la clase observada. Cada observador se registra en tantos sujetos como sea necesario. Cada sujeto mantiene una lista de observadores, de los cuales no conoce nada más que la forma de notificarles sus cambios. Cada observador puede responder de distinta manera ante la notificación de cambios en los sujetos. En la arquitectura MVC, por ejemplo, la vista se registra como observadora del modelo, y cuando el modelo notifica a sus observadores algún cambio, ésta se actualiza de la manera adecuada. Patrón Estado Este patrón se utiliza cuando el comportamiento de un objeto depende de su estado. Se pretende ası́ evitar acoplamiento entre clases (para decidir qué hacer, un método de un objeto no debe consultar a otros objetos). Los objetos tienen estados internos que condicionan su comportamiento, y una clase contexto puede cambiar su estado actual. De esta forma, los objetos no conocen quién ha provocado el cambio en su estado. Este patrón se aplica en dos circunstancias diferentes: Para guardar el estado de la aplicación, ya que como se comentó en la Sección 4.3, el flujo principal de la aplicación depende de si hay un proyecto abierto o no, ası́ como de si tiene nombre de fichero asignado. Para gestionar la interacción con el dibujo del plano. La aplicación responde de distinta forma ante las acciones con el dispositivo apuntador del usuario sobre el dibujo (clic, clic+arrastre, ...), dependiendo de su estado (insertando elementos o moviendo el dibujo, por ejemplo). 270 5.2.2. B. Domı́nguez, F. Conde, Á.L. Garcı́a y F.R. Feito Diagrama de clases UML Para facilitar su comprensión, el diagrama completo de clases para esta aplicación se ha dividido en varios diagramas simplificados que se muestran a continuación. El primer diagrama (Figura 4) muestra la arquitectura MVC de la aplicación, ası́ como los patrones observador, estado y estrategia. <<interface>> ViewInterface <<interface>> ModelInterface <<interface>> ModelChangedObserver implements <<interface>> StackChangedObserver implements implements implements reads registers itself notifies Model updates View implements sends events registers itself implements Controller implements implements <<interface>> VisualizationChangedObserver <<interface>> ControllerInterface <<interface>> ApplicationStateChangedObserver <<interface>> CanvasStateChangedObserver Fig. 4 Modelo-Vista-Controlador. Patrones observador, estado y estrategia Las clases Modelo, Vista y Controlador heredan de las correspondientes interfaces (aplicando el patrón estrategia). Podrı́an añadirse nuevas implementaciones de estas clases para probar otras posibilidades, sin necesidad de cambiar el resto del sistema. Se utilizan algunos observadores para gestionar eventos ası́ncronos. Para cada tipo de observador hay una interfaz que debe ser implementada por cada clase observadora. En estas interfaces sólo hay un método, que debe ser implementado por cada observador, y es el que invoca el sujeto para notificar a los observadores. - El modelo (sujeto) utiliza ModelChangedObserver para informar a la vista (observador) cuando ha sido modificado por el controlador. Sólo entonces la vista accede al modelo para actualizar la interfaz de la aplicación. MOSES: aplicación software para la gestión de modelos de edificios 271 - El comportamiento basado en VisualizationChangedObserver es similar al anterior. El controlador (sujeto) notifica a la vista (observador) cuando el usuario solicita que aparezcan o desaparezcan elementos del dibujo. La vista actualiza la interfaz apropiadamente. - El controlador (sujeto) se sirve de ApplicationStateChangedObserver y CanvasStateChangedObserver para notificar a la vista cuando hay algún cambio en alguno de estos estados. El controlador actualiza los estados de activación de los controles de la interfaz y almacena el estado actual. - StackChangedObserver se describe más adelante. La vista se registra como ModelChangedObserver en el modelo, como VisualizationChangedObserver, CanvasStateChangedObserver y ApplicationStateChangedObserver en el controlador, y como StackChangedObserver en la pila de instrucciones (descrita más adelante). El segundo diagrama (Figura 5) muestra un ejemplo de la arquitectura de clases para el patrón instrucción, la instrucción en la que se basa el ejemplo es la de cargar un fichero DXF (LoadDXFCommand). UndoManager View <<interface>> StackChangedObserver -instance registers itself notifies +invoker UndoStack AbstractCommand <<interface>> UndoableEdit AbstractUndoableEdit adds itself LoadDXFCommand +receiver Controller +client +receiver Model Fig. 5 Patrón instrucción La clase principal del patrón instrucción es UndoStack. Esta clase es un singleton (una clase con una única instancia en la aplicación) que permite añadir nuevas instrucciones, deshacerlas y rehacerlas, ası́ como consultar si la pila está vacı́a. Toda instrucción tiene un invocador (la vista), un receptor (el modelo) y un cliente (el controlador). La vista es un StackChangedObserver de la pila, de tal forma 272 B. Domı́nguez, F. Conde, Á.L. Garcı́a y F.R. Feito que se actualiza la interfaz de la aplicación para mostrar qué instrucciones pueden rehacerse o deshacerse. Cada instrucción hereda de AbstractCommand, una clase abstracta que define un método para ejecutar la instrucción. El tercer diagrama (Figura 6) muestra la arquitectura del modelo, es decir: la representación lógica de los datos manejados por la aplicación. En esta representación, la clase principal del modelo es Project, cuyos objetos representan proyectos abiertos y editables por el usuario. Un proyecto tiene tres submodelos, representados en la figura mediante rectángulos grises: Door DXFModel Window Model Layer Block Keypoint Project SemanticModel references Entity Room GeometricModel Line GeometricBlock Insert Polyline Arc GeometricLayer DrawableLine Color Point2D Fig. 6 Modelo La clase DXFModel representa un plano cargado de un fichero DXF. Contiene listas de capas y bloques, que almacenan a su vez objetos de la clase Entity, de la cual heredan Line, Polyline, Arc e Insert, que representan los elementos básicos del plano utilizando objetos de la clase Point2D. La clase GeometricModel representa el plano mediante un conjunto de lı́neas coloreadas. Se genera a partir de la creación de un objeto DXFModel siguiendo los siguientes pasos: (1) las lı́neas se incluyen tal cual, (2) los arcos se convierten en conjuntos de segmentos, (3) las polilı́neas se separan en segmentos, y (4) las inserciones de bloques se transforman (aplicando los escalados, rotaciones y traslaciones correspondientes), y se descomponen en segmentos, recursivamente si es necesario. La clase SemanticModel contiene los resultados de la detección, esto es: habitaciones formadas por puntos clave, ventanas, puertas y tramos de escaleras. El último diagrama de esta sección (Figura 7) muestra la implementación del patrón estado. La interfaz ApplicationState define los métodos posibles para cada acción. Ası́, la clase que representa cada estado implementa esta interfaz, y su MOSES: aplicación software para la gestión de modelos de edificios 273 comportamiento y el siguiente estado al que pase la aplicación depende de la implementación de sus métodos. El controlador tiene en cuenta los estados anterior y actual de la aplicación, y notifica a la vista cuando el estado cambia. <<interface>> AppState AppStateQ1 AppStateQ2 AppStateQ3 AppStateQ4 AppStateQ5 Controller Fig. 7 Estados de la aplicación 6. Resultados y ejemplos Se muestran ahora algunos ejemplos de uso de la aplicación, junto con los resultados obtenidos al aplicar los algoritmos implementados. El primer ejemplo muestra el proceso de detección de paredes y habitaciones utilizando el enfoque basado en la detección de paredes. Este proceso consta de los siguientes pasos: 1. 2. 3. 4. 5. 6. 7. 8. Carga del fichero DXF y selección de capas visibles (Figura 8) Selección de capas con paredes, aberturas y escaleras (Figura 9) Selección de bloques correspondientes a puertas y ventanas (Figura 10) Detección de irregularidades en la capa de paredes (Figura 11) Detección de paredes (Figura 12) Búsqueda de vértices en las capas de paredes y aberturas (Figura 13) Agrupamiento (Figura 14) Detección de escaleras (Figura 15) El segundo ejemplo muestra cómo se detectan los puntos clave y las habitaciones utilizando el enfoque basado en reglas. Este proceso consta de los siguientes pasos: 1. 2. 3. 4. 5. Carga de un fichero DXF y selección de capas visibles (Figura 8) Selección de capas con paredes, aberturas y escaleras (Figura 9) Selección de bloques correspondientes a puertas y ventanas (Figura 10) Detección de irregularidades en la capa de paredes (Figura 11) Detección de puntos clave y habitaciones (Figura 16) 274 B. Domı́nguez, F. Conde, Á.L. Garcı́a y F.R. Feito Fig. 8 Selección de capas visibles Fig. 9 Selección de capas con paredes, aberturas y escaleras Fig. 10 Selección de bloques correspondientes a aberturas MOSES: aplicación software para la gestión de modelos de edificios 275 Fig. 11 Detección de irregularidades Fig. 12 Detección de paredes En la URL http://baeza.ujaen.es/ bdmartin/demo.zip está disponible para su descarga un vı́deo que muestra el funcionamiento de la aplicación. 276 Fig. 13 Búsqueda de vértices Fig. 14 Agrupamiento Fig. 15 Detección de escaleras B. Domı́nguez, F. Conde, Á.L. Garcı́a y F.R. Feito MOSES: aplicación software para la gestión de modelos de edificios 277 Fig. 16 Detección de puntos clave y habitaciones 7. Conclusiones y trabajo futuro Se ha presentado el análisis de requerimientos, el diseño de interfaz y la implementación de una aplicación para la detección de elementos semánticos tales como paredes, habitaciones, puertas, ventanas y escaleras en planos CAD de plantas de edificios. En primer lugar, se han comentado algunos conceptos sobre la estructura de los planos. Luego, se han descrito el análisis de requerimientos y la interfaz de usuario, el diseño y la implementación de la aplicación. Por último, se han mostrado algunos ejemplos de uso de la aplicación. El trabajo futuro consisitirá básicamente en la incorporación de nuevos algoritmos de detección a la aplicación, puesto que el diseño flexible utilizado facilita esta tarea, sin necesidad de modificar el resto del código. Agradecimientos Este trabajo ha sido parcialmente subvencionado por la Junta de Andalucı́a, el Ministerio de Ciencia e Innovación y la Unión Europea (fondos FEDER) a través de los proyectos de investigación P06-TIC-01403 y TIN2007-67474-C03. Referencias 1. Autodesk, Inc.: AutoCAD 2009 DXF Reference (2009) 2. Brito, A.: Blender 3D: Architecture, Buildings, and Scenery. Packt Publishing (2008) 3. Dix, A., Finlay, J.E., Abowd, G.D., Beale, R.: Human-Computer Interaction, 3rd edn. Prentice Hall (2003) 278 B. Domı́nguez, F. Conde, Á.L. Garcı́a y F.R. Feito 4. Domı́nguez, B., Garcı́a, A.L., Feito, F.R.: An Open Source Approach to Semiautomatic 3D Scene Generation for Interactive Indoor Navigation Environments. In: Proceedings of IV Ibero-American Symposium on Computer Graphics, pp. 131–138 (2009) 5. Domı́nguez, B., Garcı́a, A.L., Feito, F.R.: Detección semiautomática de paredes, habitaciones y escaleras a partir de planos arquitectónicos CAD. In: Proceedings of XX Congreso Español de Informática Gráfica, pp. 177–186 (2010) 6. Fowler, M.: UML Distilled. Addison-Wesley, Boston (2004) 7. Freeman, E., Freeman, E., Sierra, K., Bates, B.: Head First Design Patterns. O’Reilly (2004) 8. Gamma, E., Helm, R., Johnson, R., Vlissides, J.M.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional Computing Series (1994) 9. Li, Y., He, Z.: 3D indoor navigation: a framework of combining BIM with 3D GIS. In: Proceedings of the 44th ISOCARP Congress (2008) 10. MySQL AB: MySQL 5.1 Reference Manual. http://dev.mysql.com/doc 11. Open Geospatial Consortium, Inc.: http://www.opengeospatial.org 12. Yan, W., Culp, C., Graf, R.: Integrating bim and gaming for real-time interactive architectural visualization. Automation in Construction 20(4), 446–458 (2011) 13. Yin, X., Wonka, P., Razdan, A.: Generating 3D building models from architectural drawings: a survey. IEEE Computer Graphics and Applications 29(1), 20–30 (2009)