Visualización de medios participativos en entornos urbanos

Transcripción

Tı́tulo: Gestión de Información Urbana Tridimensional
Editores: Lidia Ortega Alvarado y Ángel Luis Garcı́a Fernández
Edición y maquetación propia
ISBN: 978-84-694-8374-9
Jaén, 2011
c los autores
Diseño de portada: Ángel Luis Garcı́a Fernández
Prefacio
En este libro se recogen los resultados más relevantes relacionados con la gestión de información urbana tridimensional obtenidos por los autores a partir de un
proyecto de investigación presentado a la convocatoria de incentivos a proyectos de
investigación de excelencia de la Junta de Andalucı́a publicada en el BOJA no 63
de 2007 y concedido en la resolución de 19 de diciembre del mismo año. En dicho
proyecto se pretendı́a profundizar e innovar en el uso de sistemas de información
espaciales combinados con información geométrica 3D para apoyar el análisis y la
toma de decisiones, ası́ como otras aplicaciones como la navegación o el uso de
terminales móviles.
Los contenidos en este volumen se han agrupado en varios bloques temáticos
según el aspecto tratado:
En primer lugar, se recopilan trabajos sobre el tratamiento de los datos obtenidos con distintos sistemas de captura (escáneres 3D y cámaras panorámicas), de
manera que se facilite la obtención de datos geométricos.
El segundo bloque está dedicado a técnicas de tratamiento de modelos digitales
del terreno (MDTs). Concretamente, se tratan técnicas para optimizar la visualización de MDTs en dispositivos móviles, ası́ como para añadir información
geográfica en dichos modelos. El tercer capı́tulo de este bloque muestra técnicas
de visualización del interior de terrenos mineros, ampliando los MDT de forma
que no sólo se modela la superficie de la Tierra, sino también su interior.
El tercer bloque reúne trabajos relacionados con algoritmos geométricos básicos
de aplicación en sistemas de información espacial, como las operaciones booleanas, el cálculo de inclusión de puntos o la descomposición espacial.
La visualización realista de entornos urbanos ocupa el cuarto bloque de esta recopilación. Se tratan los temas de aplicación automática de texturas a modelos
de edificios, ası́ como la visualización utilizando efectos de luz, sombra y medios
participativos (niebla, humo, etcétera).
El quinto bloque recoge trabajos relacionados con el tratamiento de información
urbana, tanto del interior de los edificios como del exterior.
V
Prefacio
VI
La interacción con modelos urbanos es el centro de atención de los trabajos agrupados en el sexto bloque de este libro. Se trata la problemática relativa al uso de
dispositivos móviles para la visualización, ası́ como el uso de las nuevas tecnologı́as vinculadas a la web.
Por último, se presentan dos aplicaciones: la primera de ellas hace uso de un sistema de información espacial 3D para la localización de empresas en un entorno
urbano, mientras que la segunda permite analizar planos arquitectónicos para extraer información semántica que luego pueda ser procesada de la manera deseada
en un sistema de información espacial.
Creemos que con estos contenidos se cubren prácticamente todos los aspectos
relacionados con la gestión de informació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 elaboración de este libro ha sido subvencionada por la Junta de Andalucı́a
y los Fondos FEDER de la Unión Europea a través del proyecto de investigación P07-TIC-02773.
Ası́ mismo, todos los trabajos contenidos en este libro han sido parcial o totalmente subvencionados
a través de dicho proyecto.
Jaén, 2011
Lidia Ortega Alvarado
Ángel Luis Garcı́a Fernández
Contenido
Gestión de Información Urbana Tridimensional. Aplicaciones . . . . . . . . . .
F.R. Feito
1
Bloque I Postprocesamiento
Detección de elementos no estructurados en escenas 3D procedentes de
escáneres láser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manuel J. González Muñoz, Manuel J. Lucena López, José M. Fuertes
Garcı́a, Rafael J. Segura Sánchez y Antonio J. Rueda Ruiz
9
Reconstrucción de entornos tridimensionales a partir de múltiples vistas
panorámicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Guadalupe Millán de la Blanca, Manuel J. Lucena López y José M. Fuertes
Garcı́a
Bloque II Terrenos
Visualización adaptativa de grandes terrenos a través de redes celulares . 39
José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura
Sánchez
Introducción de información geográfica en terrenos 3D . . . . . . . . . . . . . . . . 71
Ángel Aguilera Garcı́a, J. Roberto Jiménez Pérez y Francisco Martı́nez del
Rı́o
Visualización 3D del interior de terrenos mineros . . . . . . . . . . . . . . . . . . . . . 83
M. Linarejos Rivero Cejudo
Bloque III Algoritmos básicos
Operaciones Booleanas sobre polı́gonos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Francisco Martı́nez del Rı́o, Ángel Aguilera Garcı́a y J. Roberto Jiménez
Pérez
VII
VIII
Contenido
Algoritmos Geométricos Básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Juan J. Jiménez Delgado, Antonio Martı́nez Albalá, Félix Paulano Godino y
Rubén Pulido Ramı́rez
Bloque IV Visualización realista
Texturización en entornos urbanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Marı́a Dolores Robles Ortega, Lidia Ortega Alvarado y Francisco R. Feito
Higueruela
Visualización de medios participativos en entornos urbanos . . . . . . . . . . . . 151
J. Roberto Jiménez Pérez, Francisco Martı́nez del Rı́o y Ángel Aguilera
Garcı́a
Bloque V Tratamiento de información urbana
Estudio sobre la representación semántica y topológica de interiores de
edificios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Bernardino Domı́nguez Martı́n, Ángel Luis Garcı́a Fernández y Francisco R.
Feito Higueruela
Mejora y ampliación de la cartografı́a urbana . . . . . . . . . . . . . . . . . . . . . . . 183
Ma Isabel Ramos Galán y José L. de la Cruz González
Bloque VI Interacción
Estudio sobre técnicas de visualización y navegación de entornos
virtuales en dispositivos móviles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura
Sánchez
Sistema de visualizació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 López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega
Alvarado
MOSES: aplicación software para la gestión de modelos de edificios . . . . . 253
Bernardino Domı́nguez Martı́n, Francisco de A. Conde Rodrı́guez, Ángel
Luis Garcı́a Fernández, Francisco R. Feito Higueruela
Lista de autores
Ángel Aguilera Garcı́a
Departamento de Informática. Universidad de Jaén.
e-mail: [email protected]
Francisco de Ası́s Conde Rodrı́guez
Bernardino Domı́nguez Martı́n
José Luis de la Cruz González
Departamento de Ingenierı́a Cartográfica, Geodésica y Fotogrametrı́a. Universidad
de Jaén.
Francisco Ramón Feito Higueruela
José Manuel Fuertes Garcı́a
Ángel Luis Garcı́a Fernández
Manuel Jesús González Muñoz
Juan José Jiménez Delgado
IX
X
Lista de autores
Juan Roberto Jiménez Pérez
Ana Marı́a López Estrella
Manuel José Lucena López
Antonio Martı́nez Albalá
Francisco Martı́nez del Rı́o
Guadalupe Millán de la Blanca
José Marı́a Noguera Rozúa
Carlos Javier Ogayar Anguita
Félix Paulano Godino
Rubén Pulido Ramı́rez
Marı́a Isabel Ramos Galán
Departamento de Ingenierı́a Cartográfica, Geodésica y Fotogrametrı́a. Universidad
de Jaén.
Lista de autores
Marı́a Linarejos Rivero Cejudo
Marı́a Dolores Robles Ortega
Antonio Jesús Rueda Ruiz
Rafael Jesús Segura Sánchez
XI
Gestión de Información Urbana Tridimensional.
Aplicaciones
F.R. Feito
La mayor disponibilidad de geo-información está permitiendo el desarrollo de
nuevas herramientas software que facilitan un mejor acceso y un mayor uso de dicha
información. Es conocido que cerca de un 80 % de la información que usan las
empresas o entidades tiene una componente geográfica o espacial.
Partiendo de esta idea, se propuso la realización de un proyecto que pretendı́a
diseñar e implementar prototipos de herramientas software para el acceso a información urbana tridimensional, de modo que fuera posible interactuar má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 gestión de información geográfica (Google Earth, por ejemplo) han evolucionado muy rápidamente en los últimos
años, aunque la interacción o información que dichas herramientas ofrecen es reducida y está orientada en la mayorı́a de los casos a la visualización.
A partir de la experiencia contrastada del equipo de investigación que presentaba
este proyecto, se pretendı́a avanzar en el diseño e implementación de herramientas
software basadas en software libre, que permitieran la gestión de la información
tridimensional que existe en todo entorno urbano: se pretendı́a no sólo la visualización 3D realista de entornos urbanos, sino la interacción con la información que los
edificios que componen dichos entornos urbanos tienen en su interior.
La gestión y captura de información tridimensional en entornos reales no controlados, puede verse sensiblemente mejorada a través del empleo de técnicas de
reconstrucción automática que, a partir de imágenes del edificio en cuestión, permitan obtener su estructura tridimensional. Gracias a ello, pueden incorporarse al
sistema grandes cantidades de información a partir de fuentes fáciles de obtener y
sin necesidad de equipamiento especial. Estas técnicas pueden asimismo emplearse
F.R. Feito
Departamento de Informática. Universidad de Jaén
1
2
F.R. Feito
para mejorar la experiencia del usuario en su interacción con el sistema, mediante
la superposición de elementos sintéticos a imágenes obtenidas del mundo real.
Además, y utilizando los prototipos desarrollados, se pretendı́a ofrecer servicios
a entidades y empresas pú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 investigación bá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 gestión de geoinformación. La oficina virtual del catastro [3] o el SIGPAC [14] destacan entre los más
concretos mientras que Google Earth [6] o Bing Maps [2] se encuentran entre los
más genéricos.
Actualmente la gestión adecuada de la geoinformación se orienta a lograr una
mayor facilidad a la vez que se intenta incorporar la tercera dimensión, considerando
que ésta es básica para un verdadero conocimiento y por tanto, para una gestión
adecuada de la información.
En los últimos años se han dado avances importantes en la disponibilidad de
herramientas para el tratamiento adecuado de la tercera dimensión en la información
geográfica, pero casi siempre desde el punto de vista de la visualización. Cuando se
elaboró la propuesta de proyecto, no se habı́a aportado software válido y eficaz
para la gestión y la interacción con la información geográfica completa, es decir,
con la información tridimensional contenida en cualquier entorno geográfico, y en
concreto en los entornos urbanos.
Las técnicas basadas en realidad virtual (VRML y X3D fundamentalmente [17]),
en imá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 están usando para la simulación de entornos tridimensionales.
Por otro lado, están siendo importantes los desarrollos de herramientas SIG avanzadas basadas en software libre. En España destacan los productos gvSIG [9] (basado en licencia GPL, desarrollado inicialmente en la Comunidad Valenciana, y actualmente mantenido por la Asociación gvSIG) y el proyecto Sextante, desarrollado
en Extremadura [15].
A nivel internacional destaca GRASS [8], que puede considerarse la herramienta
de dominio público más avanzada en cuanto a análisis espacial.
Junto a lo anterior ha ido avanzando el software disponible para la gestión y
diseño de contenidos geográficos, muchos de ellos relacionados con las iniciativas
sobre Infraestructura de datos espaciales, como la directiva INSPIRE de la Unión
Europea (Infrastructure for Spatial Information in the European Community) [11],
o el proyecto IDEE español [10].
Gestión de Información Urbana Tridimensional. Aplicaciones
3
En la página web del Open Geospatial Consortium [12] está disponible toda la
información relativa a estándares abiertos para el acceso a información geográfica en la web. Ası́ mismo hay varias páginas web que recopilan información sobre
herramientas GIS de dominio público disponibles en la actualidad [5, 13].
Centrándonos en el tema urbano, en España destaca el portal de la oficina virtual
del catastro [3]. Tal y como allı́ se indica, se están aumentado los servicios a los
ciudadanos, basados muchos de ellos en el formato WMS (Web Map Service) que
es el má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 información geográfica
Puede encontrarse también información de interés en las comunicaciones presentadas en las distintas ediciones del congreso de software libre y abierto para
aplicaciones geoespaciales. Todas ellas están disponibles a travé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 información geográfica
1. Desarrollar prototipos software, basado en software libre (bajo licencia GPL) que
permitan la interacción con la información urbana tridimensional.
2. En relación a lo anterior, el diseño y mantenimiento de un servidor de mapas con
información urbana tridimensional, accesible mediante el software desarrollado
en el objetivo anterior.
3. Estudio y diseño de posibles aplicaciones que, desde diversos á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 información contenida en
el interior de los edificios fuera considerada privada, y por tanto sujeta a la ley de
protección de datos, se pretendı́a usar información relacionada con entes pú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 Jaén y
Granada.
Por medio de los objetivos anteriores se pretendı́a fomentar la innovación, tanto
en el sector público como en el privado.
Para facilitar la labor anterior, se contactó con el Departamento de Valoraciones
de la Consejerı́a de Economı́a y Hacienda de la Junta de Andalucı́a y se contó con su
declaración de interés en el proyecto, de forma que una vez obtenidos los primeros
resultados se concretarı́an posibles formas de colaboración. De hecho uno de los
doctores miembros del grupo TIC que daba soporte al proyecto, y que formaba
Gestión de Información Urbana Tridimensional. Aplicaciones
5
parte del equipo investigador, trabajaba en dicha Consejerı́a, por lo que fácilmente
se lograrı́a la colaboración indicada.
Además se contactó con la Cámara de Comercio e Industria de Jaén, que también
manifestó su interés por los resultados del proyecto y por el desarrollo de aplicaciones orientadas al desarrollo socieconó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 diseño de algoritmos eficientes para la gestión de información urbana tridimensional
El diseño e implementación de un servidor de cartografı́a urbana, con información tridimensional
La elaboración de prototipos software para el acceso al servidor de mapas desde
diversos tipos de terminales
La adecuada visualización y gestión de la información urbana disponible
El desarrollo de propotipos de aplicaciones, basadas en las herramientas anteriores
La obtención de avances en la investigación básica relacionadas con los campos
anteriores
Tal y como podrá 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 información global en el catastro de este tipo
de datos. Sı́ se han aportado algoritmos para la generación de prototipos 3D con
información de altura de edificios calculada aproximadamente. Con la evolución
hacia el catastro 3D y la realidad de que la web, mediante el estándar WebGL, es ya
Web 3D, puede decirse que en poco tiempo dicha información estará 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
Dirección General del Catastro de Españ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 España (IDEE). http://www.idee.es
6
11.
12.
13.
14.
Unió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 Información Geográfica de Identificació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
Detección de elementos no estructurados en
escenas 3D procedentes de escáneres láser
Manuel J. González Muñoz, Manuel J. Lucena López, José M. Fuertes Garcı́a,
Rafael J. Segura Sánchez y Antonio J. Rueda Ruiz
1.
Introducción
Los escáneres láser se están utilizando cada vez más para la adquisición de informació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 está generando gran
cantidad de información a partir de escáneres láser, tomada de fuentes muy diversas (interiores y exteriores) para una gran variedad de propósitos: reconstrucción de
modelos, análisis, medida, etc. Por esta razón, las técnicas de filtrado de datos 3D se
han convertido en un tema de investigación muy activo, y en una fase muy importante para el tratamiento de este tipo de información en gran variedad de aplicaciones
(visión artificial, ingenierı́a civil, arqueologı́a, medicina, etc.).
Para procesar los grandes volúmenes de información generados por los escáner
3D, el software que acompañ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 básico de segmentación. Sin información previa que sirva de ayuda, una segmentación automática no supervisada
proporciona resultados insatisfactorios [3, 1, 4]. Por esta razón, el software actual
de tratamiento de nubes de puntos 3D ofrece procesos de segmentación manuales o
semiautomáticos. Este tipo de tareas pueden ser extremadamente lentas y tediosas
cuando se trabaja sobre escenas que contienen gran cantidad de información.
La mayorı́a de los objetos no deseados existentes en las escenas de exteriores
presentan propiedades geomé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 Informática
Universidad de Jaén
Campus Las Lagunillas Edif. A3
23071 - Jaén, España
e-mail: {mgmunoz, mlucena, jmf, rsegura, ajrueda}@ujaen.es
9
10
M.J. Gonzá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 árboles),
o pequeños y aislados grupos de puntos (objetos de pequeña escala).
En nuestro caso, queremos detectar los elementos no estructurados de una escena
usando exclusivamente la información geométrica. Tomando como partida la nube
de puntos generada mediante un escáner 3D, nuestra té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 técnica compuesta de dos
fases. La primera consiste en una difusión anisotrópica y la segunda en una regresión
de planos. Para la aplicación de la técnica propuesta la información 3D procedente
del escáner es colocada sobre una matriz bidimensional. Esto se consigue a partir de
las coordenadas polares de cada punto relativas a la posición del escáner.
El artı́culo está organizado de la siguiente manera. La Sección 2 hace la introducción al método propuesto. Los resultados experimentales, usando tanto datos reales
como sintéticos, se muestran en la Sección 3. Finalmente, la Sección 4 muestra
nuestras conclusiones y el trabajo futuro.
2.
Método propuesto
El método comienza con la obtenció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 ángulo horizontal y vertical relativos a la posición del
escáner. Cada elemento de la matriz es un número real que representa la distancia al
escáner del punto asignado a esa posición, o puede quedar nulo si el escáner no ha
devuelto información para esa posición concreta.
Nuestra técnica se compone de dos etapas. La primera aplica un proceso de difusió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 escá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 geomé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 sólo aparecen grandes valores en las zonas no
estructuradas. También aparecen valores significativos dentro de las regiones donde
la distancia con el escáner cambia gradualmente (como el suelo o un muro inclinado
con respecto al escáner). Esto es debido a que el proceso de difusión anisotrópica
modifica los valores de estas regiones hasta alcanzar un valor medio, por lo que los
valores extremos proporcionarán diferencias mayores. La segunda fase de nuestra
técnica detecta estas variaciones en la matriz diferencia, midiendo la distancia entre
Detección de elementos no estructurados en escenas 3D procedentes de escáneres láser
11
cada punto actual con un plano obtenido mediante regresión, calculado a partir de
los vecinos del punto.
2.1.
Difusión anisotrópica
Perona y Malik [7] introdujeron una técnica de regularización no linear e iterativa
conocida como difusión anisotrópica. Esta técnica regulariza imágenes en escala de
grises manteniendo las discontinuidades más destacadas que con frecuencia contienen la información de aristas o bordes. El proceso puede ser generalizado para aplicarlo a imágenes en color [5] y de disparidad (distancias) [6]. Nuestra aproximación
está basada en el último caso. Siendo I nuestra matriz de distancias, aplicaremos
esta técnica sobre ella con el objetivo de eliminar las altas frecuencias mediante el
desplazamiento de los puntos.
La difusión anisotrópica modifica el valor de cada punto en función de la diferencia con sus vecinos. Esta diferencia es ponderada mediante un coeficiente de
conducción c. El enfoque discreto de la difusión anisotrópica puede utilizar la discretización del operador Laplacian. Este operador se aplica sobre los cuatro vecinos
más cercanos para actualizar los valores de la matriz en cada iteració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 conducción usado en la difusión anisotrópica debe devolver
1 dentro de cada región y 0 en las fronteras o lı́mites. Nosotros hemos usado la
siguiente expresió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 permanecerán mientras que el resto tenderá 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 nú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.
Regresión de planos
Las regiones que pertenecen a objetos estructurados presentan una caracterı́stica
común en M: sus valores pueden ser ajustados a un plano con un pequeñ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 posició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 región estructurada, la distancia calculada
será muy pequeñ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 regresión, permitiéndonos caracterizar las regiones no estructuradas.
La fase de selección final se lleva a cabo mediante el establecimiento de un umbral sobre la matriz de diferencias M ′ obtenida tras la fase de regresión. Nosotros
usamos como umbral el punto de inflexión calculado sobre el histograma de M ′ . Los
puntos aislados son clasificados directamente como no estructurados.
Fig. 1 Detección de puntos
no estructurados. a) Conjunto
estructurado de puntos: la distancia entre el punto (rojo) y
el plano de regresión estimado es pequeña. b) Conjunto
no estructurado de puntos: la
distancia entre el punto rojo y
el plano es mayor.
3.
3.1.
Experimentación
Configuración de los experimentos
Hemos probado nuestra técnica tanto en escenas sintéticas como en reales. Las
escenas sintéticas se han obtenido a partir de un mundo virtual compuesto por varios
objetos estructurados simples (suelo y edificios) y otros no estructurados (árboles,
arbustos y cableado eléctrico). La nube de puntos se ha generado mediante la simulación de un escaneado desde una posición concreta del mundo virtual. Con dicho
sistema se obtuvieron 530.000 puntos (ver Figuras 2 y 3). Las hojas de la vegetación
se han generado mediante puntos situados de forma aleatoria dentro de una esfera.
La escena real (Figura 4) se ha obtenido usando un escáner láser de rango medio
(Callidus CP 3200) sobre un puente de piedra antiguo rodeado de vegetación, ge-
13
nerando una nube de aproximadamente 400.000 puntos. La nube presenta además
información correspondiente a los cables pertenecientes a la estación de escaneo.
Fig. 2 Escena sintética usada
en los experimentos.
Fig. 3 Nube de puntos sintética usada en los experimentos,
generada a partir de la escena
de la Figura 2. mostrando un
edificio, una farola y vegetación.
Al pertenecer la escena sintética a un mundo virtual controlado, disponemos de
la clasificación correcta a priori de los puntos, con lo que hemos podido comparar
dicha clasificación con la obtenida tras la aplicación de nuestro método. Ası́ pues
mostraremos los resultados numéricos de la imagen correspondiente a dicha escena.
Para el proceso de difusión, se han usado los siguientes pará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
Fig. 4 Nube de puntos obtenida mediante escáner lá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 áreas extensas sin información, correspondientes principalmente al cielo, donde el rayo o pulso del escáner no consigue
impactar con ningún objeto para generar la información de un punto nuevo. Estos
puntos nulos serán simplemente ignorados en los procesos de las distintas fases.
Fig. 5 Puntos proyectados de
la escena sinté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.
15
La Figura 7 muestra los resultados obtenidos sobre la nube de puntos sintética,
usando la regresión de planos con una vecindad definida por una ventana de tamañ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
áreas de gran curvatura, han sido marcados también como puntos no estructurados.
Es de especial interés el caso de las farolas, cuyos postes han sido etiquetados como
no estructurados. En efecto, estos objetos son ligeramente más anchos que los cables
eléctricos, por lo que podrı́an pasar perfectamente por elementos no estructurados.
Fig. 7 Resultados sobre la
nube sintética con colores de
etiquetado (azul: aciertos sobre las regiones estructuradas;
verde: aciertos sobre las regiones no estructuradas; rojo:
fallos). Tamaño de la ventana
de vecindad: 3.
Algunos de los resultados numéricos se muestran en la Tabla 1. Los mejores
resultados se han obtenido con los tamaños de ventana más pequeñ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 sintética, variando el tamaño de la ventana de vecindad.
Tamañ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 también como no estructurado debido a la presencia vegetación en esta parte del puente. También podemos ver que la vegetación
del suelo no ha sido marcada debido a la pequeña altura que presenta.
16
Fig. 8 Resultados sobre la
escena real. Los puntos detectados como no estructurados
están marcados en rojo. Tamaño de la ventana: 9.
4.
Conclusiones y trabajo futuro
Nuestro mé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, vegetación, etc.).
La primera fase, compuesta por un proceso de difusión anisotrópica seguido de
una diferencia de matrices, elimina los componentes de bajas frecuencias de la nube de puntos. La fase de la regresió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 numéricos muestran que el método propuesto es lo suficientemente preciso para dar una estimación inicial de las estructuras de interés de una nube
de puntos.
Vale la pena mencionar que nuestro método está siendo actualmente usado con
buenos resultados en un software de tratamiento de datos 3D, como parte de una
herramienta supervisada de selección de puntos para aplicaciones de ingenierı́a.
Como trabajo futuro, planeamos probar nuestro método sobre otros tipos de escenas que contengan objetos de diferentes escalas. Queremos también tomar en consideración la información de color para el proceso de selección. Finalmente nuestro
método podrı́a ser combinado con técnicas de detección de objetos para seleccionar
correctamente objetos compuestos, como los á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 Español de Educación y Ciencia, y la Unió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
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, Pé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
Reconstrucción de entornos tridimensionales a
partir de múltiples vistas panorámicas
Guadalupe Millán de la Blanca, Manuel J. Lucena López y José M. Fuertes Garcı́a
Resumen En este trabajo presentamos un proceso de reconstrucción de estructura
tridimensional a partir de múltiples imágenes esféricas. La popularización de dispositivos hardware de adquisición de imágenes esféricas plantea la cuestión de su
posible uso para la reconstrucción de entornos, a partir de múltiples vistas. Para ello
proponemos un método basado en la detección de puntos singulares, su emparejamiento entre varias vistas, y su posterior triangulació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 precisión razonable.
1.
Introducción
Uno de los objetivos de la visión artificial es conseguir que un ordenador llegue
a analizar una escena real como lo harı́a una persona. Para conseguir este propósito,
es necesario crear un modelo 3D de dicha escena. La reconstrucción tridimensional
tiene varias aplicaciones, como la navegación de un robot permitiéndole conocer en
qué parte de la escena se encuentra y poder planificar sus movimientos sin necesidad
de ayuda humana. También es útil para determinar magnitudes como distancias,
superficies o volúmenes, lo cual puede ser aplicable para controles de calidad ya que
se pueden verificar los procesos y superficies de los objetos que se estén fabricando.
Otra aplicación es la digitalización de museos o monumentos históricos, para crear
visitas virtuales a las cuales los usuarios pueden acceder desde Internet. Estas son
algunas de las muchas utilidades existentes de la reconstrucción tridimensional.
G. Millán
Departamento de Informática, Universidad de Jaén
M. Lucena
Departamento de Informática, Universidad de Jaén, e-mail: [email protected]
J.M. Fuertes
Departamento de Informática, Universidad de Jaén e-mail: [email protected]
19
20
Este trabajo pretende establecer una metodologı́a que, a partir de imágenes panorámicas capturadas desde el Sistema de visión esfé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 técnicas de reconstrucción
3D, con objeto de conocer las posibilidades existentes. Algunas de estas técnicas,
como la telemetrı́a lá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 ejecución muy altos, como la visión estéreo densa, y por ello se
optó finalmente por una reconstrucción estereoscópica dispersa basada en puntos de
interés, al proporcionar una solución robusta y a la vez más rápida que el resto de
las técnicas investigadas.
A continuación se analizaron algunos de los principales detectores de puntos de
interé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 más puntos detecta cuando existen deformaciones afines en los objetos
de la escena.
Fig. 1 Ejemplo de imagen esférica.
2.
Sistema de visión esférica Ladybug 2
En este trabajo hemos utilizado el sistema digital de adquisición esférica Ladybug2, de Point Grey [8]. Este sistema cuenta con seis cámaras de 0.8 MP que permiten capturar más del 75 % del entorno donde se encuentra, una tarjeta Firewire
IEEE-1394b que permite capturar imágenes en el disco a 30 fotogramas por segundo, una unidad central de adquisición de imágenes y control de software, un kit de
Reconstrucción de entornos tridimensionales a partir de múltiples vistas panorámicas
21
desarrollo de software (SDK), cables para la conexión y alimentación, y sus correspondientes controladores de dispositivo.
La cámara puede calibrarse usando esferas que oscilan entre los 2m y 20m de
diámetro, y asumiendo que todos los puntos de la escena capturada están a la misma distancia de la cámara. Esta calibración es importante para conseguir un buen
resultado en el proceso de pegado o stitching, en el cual se combinan las imágenes
individuales de cada objetivo para producir una única imagen panorámica o una de
alta resolución. Esta unión se realiza a partir de las zonas comunes presentes en
las diferentes imágenes parciales obtenidas. Los seis objetivos que componen Ladybug2 se combinan para formar la imagen final, que puede ser de tres tipos: esfera,
cúpula y panorámica.
El stitching se basa en geometrı́a, no en el contenido de la imagen, para buscar
la mejor panorámica. Por esto el proceso de pegado de imá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 reconstrucció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.
Reconstrucción de una escena 3D
El objetivo principal de este trabajo es la obtención de una reconstrucción tridimensional de una escena a partir de varias vistas panorámicas. Para validar el
método emplearemos imágenes capturadas con un sistema Ladybug2, a las que supondremos libres de errores.
El proceso de reconstrucción 3D consta de tres pasos:
Captura de las imágenes, situando la cámara en una serie de ubicaciones conocidas dentro de la escena.
Búsqueda de puntos distinguidos y correspondencia de los mismos entre las distintas imágenes.
Reconstrucción 3D propiamente dicha, a partir de un conjunto de puntos en correspondencia y de la geometrı́a de las cámaras.
3.1.
Ubicación de la cámara dentro de la escena
Para comenzar con el primer paso, necesitamos determinar un punto de la escena,
que servirá como origen de coordenadas, y determinar la posición y orientación de
la cá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
Fig. 2 Esquema de una sala para su reconstrucción tridimensional.
Para cada punto de vista se han capturado imágenes con todos los valores de
calibración posibles de la cámara, con objeto de determinar la repercusión de este
parámetro sobre la fiabilidad del método.
3.2.
Búsqueda de correspondencias entre dos imágenes
El segundo paso consiste en la búsqueda de correspondencias entre las imágenes
para conocer en qué lugares de cada imagen se proyecta un mismo punto de la
escena. Abordaremos este problema utilizando el método de Harris [2] para extraer
los puntos de interés de dos imágenes, tomadas desde diferentes puntos de vista de
una escena, y posteriormente encontrar las correspondencias existentes entre ellas.
Los puntos de interés que obtengamos de cada imagen deben ser invariantes a
escala, rotación y transformaciones afines, para poder encontrar el mismo punto en
diferentes vistas de una misma escena. Una vez obtenidos los puntos de interés de
cada imagen, hay que asociarles un descriptor para encontrar correspondencias de
puntos entre ambas imágenes.
3.2.1.
Método SIFT afı́n
Cualquier objeto cuenta con puntos interesantes que se pueden extraer para
proporcionar una descripció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, rotación o transformaciones afines.
ASIFT, a diferencia del algoritmo SIFT, representa con suficiente precisión todas
las distorsiones causadas por la variación de la cámara a lo largo de un eje. ASIFT
23
simula la escala, el ángulo de longitud y de latitud (que es equivalente a la inclinación) de la cámara, y normaliza la translación y rotación, logrando una invarianza
afı́n completa.
El algoritmo ASIFT genera un conjunto de vectores, cada uno de ellos asociado a
un punto de interé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, rotación
y transformación afı́n; y es parcialmente invariante a adición de ruido y cambios en
la iluminación.
3.2.2.
Emparejamiento de puntos singulares
Para emparejar dos imá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 imágenes. La comparación de
caracterı́sticas se basa en la similitud de los descriptores asociados a é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 técnica del vecino más próximo es
computacionalmente muy costoso. Para aliviar esta situación, hemos empleado el
método best bin first (BBF), propuesto por Beis y Lowe en 1997 [7]
En general muchas de las correspondencias encontradas estará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 generación de los distintos modelos se hace iterativamente. Para ello se
selecciona aleatoriamente un conjunto de muestras del tamaño mı́nimo para generar
un modelo y se van añadiendo uno a uno los puntos que estén cerca del modelo,
actualizándolo con la información añadida.
Cuando, en una iteración, el conjunto inicial contiene algún punto que realmente
no pertenece al modelo, es muy difı́cil que haya puntos que estén de acuerdo con
el modelo inducido por las muestras iniciales y, de haberlos, lo más probable es
que provoquen un error muy alto. Además, los modelos apoyados por menos de un
determinado número de puntos se descartan.
3.3.
Triangulación de puntos
A partir de una única imagen, la profundidad de un punto en una escena no
puede ser calculada. Con al menos dos imágenes, tomadas desde diferentes puntos
de vista, la profundidad puede ser medida a través de la triangulación. Esto es una
24
Fig. 3 Emparejamiento de puntos entre dos imá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 autónomos con cámaras estereoscópicas.
Se define visión estereoscópica (o estéreo) como aquella en la que se emplea
más de una imagen para obtener una idea de tridimensionalidad. Según el número
de imágenes que se emplee, se habla de visión bifocal –dos imágenes o vistas–, trifocal –tres imágenes o vistas–, cuadrifocal –cuatro imágenes o vistas– o n-focal –n
imá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 cámaras vamos a estimar la posición
tridimensional de los puntos singulares dentro de la escena.
La Figura 4 representa la situació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 cámara.
25
Fig. 4 Situació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 imágenes capturadas desde el punto 1 y
el punto 2, y las imá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 transformación de las coordenadas (xI , yI )
de cada punto en correspondencia dentro de la imagen panorámica, a diferentes
sistemas de coordenadas.
Coordenadas esféricas
El sistema de coordenadas esféricas se utiliza para determinar la posición espacial de un punto mediante una distancia y dos ángulos. En él, un punto P queda
representado por un conjunto de tres magnitudes: el radio r, el ángulo polar o colatitud θ y el azimut ϕ (Figura 5).
Puesto que la imagen representa una proyección esfé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 relación existente entre las coordenadas horizontales de un punto P, perteneciente a la imagen panorámica capturada con Ladybug2,
y las coordenadas esféricas de este punto es la siguiente:
26
Fig. 5 Sistema de coordenadas esfé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 relación inversa es la siguiente:
p
r = x2 + y2 + z2
(2)
(3)
θ=

√

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 función sgn(x) vale 1 si x > 0, y −1 si x < 0.
3.3.1.
Alineación de las esferas
Un paso importante es comprobar que cada par de esferas está alineado, es decir,
para cada par de imágenes panorá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 imágenes. Si
transformamos las coordenadas de esos puntos a coordenadas esféricas, el á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 esfé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, convirtiéndolo de esta forma en un
punto singular.
3.3.2.
Estimació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 imágenes
panorá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
Fig. 6 Punto estimado correspondiente a un emparejamiento de puntos entre dos imágenes panorá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 éstas no son proporcionales:
b
c
a
6= ′ 6= ′
a′
b
c
−−−→
−
−
Y a continuació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)
29
Para hallar el punto donde se cortan dos rectas, basta con igualar las ecuaciones
paramétricas de ambas, y a partir de los pará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 intesectarán, sino que se cruzará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 aproximación del punto 3D que queremos calcular es el punto medio de la perpendicular común que corta las dos rectas,
ya que la perpendicular común coincide con la distancia mı́nima entre las dos rectas
(Figura 8).
Para calcular la perpendicular comú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
Fig. 8 Punto medio de la perpendicular comú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
También podemos obtener una triangulación 3D a partir de dos emparejamientos
que coincidan en un punto. Para calcular el punto 3D buscado, hay que identificar los
puntos que está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 intesectará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.
Intersección de las tres rectas
Si las rectas intersectan todas en el mismo punto, serı́a el caso ó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).
Fig. 9 Punto 3D correspondiente a dos emparejamientos entre tres imágenes panorámicas.
Fig. 10 Intersección de dos rectas en dos puntos diferentes P1 y P2 .
31
32
Intersección y cruce
En este caso escogemos el punto medio entre el punto de intersección de dos de
las rectas y el de cruce de las otras dos (Figura 11).
Fig. 11 Intersección y cruce de dos rectas.
Cruce de tres rectas
Debemos calcular la perpendicular comú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 triángulo, por lo que para hallar nuestro
punto 3D calculamos el baricentro de este triá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
más al tener una nueva recta. Por este motivo, para calcular un punto 3D a partir
de más de dos emparejamientos debemos calcular puntos 3D de emparejamiento en
emparejamiento y despué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 método con má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
33
Fig. 12 Cruce de tres rectas 3D.
puntos 3D. A continuación comprobamos que al menos dos de estos n puntos son
coincidentes, es decir, son iguales o casi iguales. El punto que buscamos corresponderá a la ubicación tridimensional del emparejamiento que esté más cerca de los
centros de las esferas de las que sale, ya que cuanto más cerca esté el punto estimado
del centro de su esfera, menor será el error cometido.
3.4.
Reconstrucción de la estructura a partir de los puntos
triangulados
El mé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 reconstrucción del entorno, deberemos construir un conjunto de superficies a
partir de ellos, para poder asignar una posició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 intersección entre la recta que define cada
pı́xel y el plano correspondiente.
34
4.
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 está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 mé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 má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.
35
Fig. 14 Resultado para la escena de exterior.
5.
Conclusiones
Mediante el método propuesto, hemos comprobado que es posible realizar una
reconstrucción aproximada de un escenario tridimensional, a partir de una serie de
capturas hechas con un dispositivo que originalmente no fue diseñado para esta
tarea.
El nivel de precisión obtenido depende mucho de las caracterı́sticas del dispositivo de captura, pero empleando una medida de incertidumbre e incluyendo mú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 método propuesto no permite reconstrucciones muy completas o precisas, sı́ puede servir para obtener una primera aproximación a la geometrı́a del entorno, especialmente si tenemos algú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
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
Visualización adaptativa de grandes terrenos a
través de redes celulares
José M. Noguera Rozúa, Carlos J. Ogayar Anguita y Rafael J. Segura Sánchez
Resumen Los dispositivos móviles, tales y como PDAs o teléfonos inteligentes
son ubicuos y cada vez má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,
visualización de mapas y de terrenos. La visualización de terrenos en 3D es una
tecnologı́a de gran importancia en un amplio conjunto de campos, entre los que
destacamos la navegación personal y los Sistemas de Información Geográfica 1 . En
este Capı́tulo describimos una técnica para la visualización remota de terrenos en
dispositivos móviles que emplea redes inalámbricas con ancho de banda reducido,
tal como GPRS o UMTS.
1.
Introducción
En la actualidad es frecuente la utilización de tecnologı́as mó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, visualización de mapas y de terrenos. A continuación describiremos una técnica para la
visualización remota de terrenos en dispositivos móviles s través de redes inalámbricas con ancho de banda reducido (GPRS o UMTS). La Figura 1 ilustra el marco de
trabajo general de nuestra propuesta.
Proponemos una técnica de visualización cliente-servidor hı́brida. El cliente visualiza la geometrı́a del terreno próxima al observador, mientras que el terreno distante es representado mediante impostores. Estos impostores son generados por el
servidor y enviados al cliente a través de la red. Debido a que los impostores representan terreno alejado del observador, no necesitan ser actualizados salvo que
la posición del observador dentro del entorno virtual varı́e por encima de un cierto
1
Es muy habitual el uso del acrónimo GIS, del inglés Geographic Information System.
39
40
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 trasmisión de terrenos en dispositivos móviles.
umbral prefijado. Esta técnica proporciona las herramientas necesarias para dividir
la carga de visualización entre cliente y servidor, teniendo en cuenta los recursos
disponibles en el cliente y la congestión de la red.
El terreno se subdivide en bloques, y cada bloque se organiza siguiente una estructura de datos jerárquica. Este acercamiento permite hacer frente a la limitada
memoria principal disponible en los dispositivos móviles, y brinda la posibilidad de
emplear niveles de detalle. El cliente tan solo necesita descargar desde el servidor
la cantidad más pequeña posible de bloques de terreno que le permitan visualizar la
escena con un nivel de detalle adecuado en función de la vista actual. Los bloques
adyacentes a distinto nivel de detalle se unen entre sı́ sin discontinuidades geométricas mediante el uso adaptativo de tiras de triángulos pre-calculadas. Esta técnica de
visualización es simple, rápida y plenamente compatible con la naturaleza distribuida de nuestra aplicación.
2.
Elementos de Visión en 3D
En Informática Gráfica es habitual trabajar con objetos tridimensionales. No obstante, para poder visualizar un objeto 3D en una pantalla bidimensional es necesario
introducir previamente una proyección que transforme al objeto 3D en una proyección del mismo en un plano 2D. En esta Sección repasaremos conceptos básicos
acerca de proyecciones que serán de utilidad en secciones posteriores. En [9] puede
encontrarse un estudio en profundidad sobre visión 3D.
Para visualizar objetos 3D es necesario definir tres conceptos:
Un volumen de visión en el mundo 3D.
Una proyección sobre el plano de proyección.
Una ventana de visión sobre el plano de proyección.
En un primer paso, la geometrı́a de cada objeto en el mundo 3D se recorta contra
el volumen de visión 3D. Aquella geometrı́a que supera este paso se proyecta sobre
Visualización adaptativa de grandes terrenos a través de redes celulares
41
Fig. 2 Plano y ventana de proyección.
el plano de visión y se transforma sobre la ventana de visión 2D para su visualización.
Como nuestra intención es imitar la forma en la que los ojos humanos perciben el mundo 3D, emplearemos una proyección en perspectiva donde el centro de
proyección sea coincidente con la posición del observador o cámara. El plano de
proyección se sitúa de tal forma que su normal viene dada por el vector de dirección
de la lı́nea que cruza el punto de visión, la lı́nea de visión y atraviesa el punto de
referencia. Este plano de proyección también se conoce como plano de visión. El
plano de visión puede situarse en cualquier lugar en relación con los objetos 3D a
ser proyectados. También es necesario definir una ventana sobre el plano de visión
de tal manera que su contenido sea traspasado a la pantalla. La Figura 2 ilustra estos
conceptos.
Bajo estas condiciones, el volumen de visión es una pirámide rectangular cuya
cúspide se encuentra en la posición de la cámara y sus aristas atraviesan las esquinas
de la ventana de visión. Las cuatro caras laterales de la pirámide definen los planos
de recorte laterales. El volumen de visión se encuentra limitado a lo largo de la dirección de visión mediante el plano de recorte delantero y el plano de recorte
trasero. Ambos planos son paralelos al plano de visión y se encuentran respectivamente a una distancia z f ront y zback relativa a la cámara y medida a lo largo de la
lı́nea de visión, [9]. La Figura 3 muestra un ejemplo de volumen de visión.
Entre los elementos matemáticos de la proyección en perspectiva, estamos interesados en recordar cómo se proyecta un punto 3D. En este trabajo, asumiremos que
el plano de proyección se encuentra a una distancia d de la posición de la cámara.
Esta distancia es conocida como distancia focal de la cámara. Es fácil ver que si
P(x, y, z) es un punto 3D, entonces su proyección Pp en el plano de proyección (ver
Figura 2) vendrá dada por las ecuaciones,
42
Fig. 3 El volumen de visió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 =
Nótese que la distancia d es tan solo un factor de escala para las coordenadas Px y Py .
Además, la división por la coordenada Pz provoca que la proyección en perspectiva
de objetos distantes sea más pequeña que la proyección de objetos más próximos a
la cámara.
3.
Visualización de Terrenos en Dispositivos Móviles
A pesar de que algunos autores ya señalaron la necesidad de desarrollar métodos
de visualizació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 visualización de terrenos han crecido tanto en complejidad como en requerimientos de cómputo. Por tanto, la visualización adaptativa de grandes terrenos
a través de red en dispositivos móviles es todavı́a un campo muy poco explorado.
Hasta donde alcanza nuestro conocimiento, las soluciones de visualización de
terrenos propuestas en la literatura no consideran las dos propiedades que caracterizan a los dispositivos móviles: redes inalámbricas con bajo ancho de banda, y
capacidades de cómputo limitadas.
3.1.
43
Terrenos en Entornos Cliente-Servidor
La mayorı́a de los métodos de visualizació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 dinámica desde un servidor remoto [23]. Esta suposición es inasumible en el entorno de la
computación móvil. La mayorı́a de los sistemas operativos para dispositivos móviles no soportan memoria virtual, o carecen directamente de memoria secundaria. Es
más, la memoria principal es tan limitada que la complejidad del modelo a visualizar
se restringe considerablemente.
Para que un método de visualización de terrenos pueda emplearse en un entorno
móvil, el conjunto de datos del terreno debe almacenarse en un servidor remoto.
La mayorı́a de las técnicas de visualización de terrenos que contemplan su uso en
entornos cliente-servidor se ajustan a la clasificación de métodos de visualización
en el lado del cliente.
Las técnicas que emplean niveles de detalle continuos necesitan considerar cada
vértice o triángulo del terreno para generar la malla de triángulos a visualizar. Por
tanto, es requisito que toda la geometrı́a a su mejor nivel de detalle posible este
accesible simultáneamente. Esto supone un problema cuando el tamaño del modelo
del terreno excede el tamaño de la memoria del dispositivo.
Lindstrom et al. [17, 18] presentó una técnica para la visualización de terrenos
multirresolución cuyo tamaño excede el tamaño de la memoria principal. Su enfoque consiste explotar la gestión de memoria virtual que proporcionan los sistemas
operativos modernos. Desgraciadamente, esta técnica no es aplicable a dispositivos
móviles, puesto que é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 paginación de terrenos
a través de red. Su funcionamiento emplea el concepto de ventana deslizante para
mantener diná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 través de red, por lo
que pueden emplearse de forma natural para la visualización de grandes terrenos
en entornos cliente-servidor. Dentro de éstas, las soluciones basadas en árboles de
bloques permiten la carga progresiva de niveles de detalle desde disco o red. Esto
es, descargar el bloque raı́z del árbol permite dibujar completamente el terreno a su
nivel de detalle más bajo. Si se requiere mayor calidad, el resto de niveles del árbol
pueden descargarse de forma progresiva.
El BDAM, presentado por Cignoni et al. [10] asume que todo el conjunto de datos
está almacenado en una unidad de almacenamiento secundario, por tanto debemos
considerarlo como una técnica de visualizació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 técnicas hacen uso de algoritmos de compresión con pérdida
44
mediante la transformada óndula (wavelet) que incrementan los requerimientos de
CPU del cliente. Además, ambas técnicas precisan de una GPU programable.
Lerbour et al. [14] describe una arquitectura en red para la descarga y visualización remota de terrenos. Primeramente, el terreno se subdivide en un árbol de
bloques, donde cada bloque contiene un conjunto de niveles de detalle con resolución creciente. Cada nivel de detalle añ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 fusión o divisió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 resolució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 geométricas entre bloques de terreno adyacentes a distinto nivel de detalle.
No obstante, no se proponen soluciones para la paginación de terrenos en memoria.
3.2.
Uso del Hardware Gráfico Móvil
Actualmente, cada vez más dispositivos mó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 más reducido es mejor reclamo para atraer a un segmento
de mercado relativamente poco interesado en la tecnologı́a. Además, es destacable
el hecho de que dispositivos móviles tan notables como Nintendo 3DS incorporen
una GPU no programable. Por tanto, cualquier técnica moderna de visualización
de terrenos orientada a dispositivos móviles ha de ser capaz de explotar la potencia
de cómputo de la GPU, pero también de ofrecer un rendimiento suficiente en su
ausencia o si ésta no es programable.
Las GPUs móviles están optimizadas para dibujar tiras de triángulos [25]. Una
tira de triángulos es un tipo de primitiva que almacena un conjunto de triángulos
adyacentes de forma compacta. Los tres primeros vértices de la tira representan un
triángulo. Cada sucesivo vértice que se añada a partir del tercero genera un nuevo
triángulo. Este triángulo se dibuja empleando dicho vértice y sus dos vértices precedentes. De esta forma, pueden enviarse grandes conjuntos de triángulos a la GPU
sin redundancia de vértices.
La mayorı́a de las soluciones que trabajan con bloques de terreno emplean largas
tiras de triángulos. Usualmente, para visualizar cada bloque se utiliza un pequeño
número de tiras. Estas tiras pueden generarse al vuelo [16, 28, 22], calcularse en
una etapa de procesamiento previo [10] u obtenerse mediante máscaras de ı́ndices
[24, 19, 15, 13]
Otro factor a considerar es el que algunas soluciones presentes en la literatura
emplean los abanicos de triángulos como primitiva geométrica, [28, 30]. Estas soluciones suelen ser más fáciles de implementar y adaptarse bien a los quad-trees. No
obstante, suelen generar un elevado número de primitivas individuales. Este tipo de
técnicas deben evitarse cuando se trabaja con dispositivos móviles por dos razones:
45
El envı́o de una gran cantidad de primitivas pequeñas suponen un mayor tránsito
de datos CPU-GPU y un consiguiente peor desempeño.
Algunas librerı́as para gráficos en dispositivos móviles solo aceptan tiras de
triángulos como única primitiva. Esto ocurre en M3G [18].
Otra forma importante de aumentar el rendimiento de la GPU consiste en reducir
el número de transferencias de geometrı́a entre la CPU y la GPU. Para conseguir esta
reducción hay que almacenar la geometrı́a en la memoria de la GPU, y reutilizarla
en tanto y en cuanto ésta no cambie. La mayorı́a de las té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 solución basada dividir el terreno en una rejilla regular
de bloques, y para cada bloque construir una triangulación en forma de quad-tree
restrictivo. Esta triangulación se representa mediante una única tira de triángulos,
que se genera mediante un recorrido recursivo de la jerarquı́a del quad-tree. Esta
representación no es la más apropiada para una GPU debido a que requiere la reconstrucción de la malla y su reenvı́o a la GPU en cada marco de animación. Para
atenuar este problema, Pajarola propuso retrasar el recálculo de la malla de triángulos de cada quadtree hasta que el error cometido supere un cierto umbral.
Por último, es importante señalar que la mayorı́a de las técnicas más recientes
requieren de una GPU programable, véase [20, 1, 30, 6, 19, 8] solo por citar algunos
ejemplos. Salvo que deseemos limitar nuestras aplicaciones a dispositivos móviles
de gama muy alta, este tipo de técnicas deberı́an evitarse.
3.3.
Soluciones Especı́ficas para Dispositivos Móviles
Pouderoux et al. [24] propuso un sistema de paginación muy simple, basado en
rejillas de bloques, y especı́ficamente diseñado para dispositivos móviles. El terreno
a su máxima resolución es dividido en un conjunto de bloques. El cliente descarga aquellos bloques situados alrededor de la posición del observador. Cada bloque
descargado contiene todos los vértices necesarios para dibujarse a su máxima resolución. Para poder dibujar el terreno de forma adaptativa, se genera un conjunto
de má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 máscara adecuada en función del nivel de detalle deseado. Una máscara
consiste en un vector de ı́ndices que indica a la librerı́a gráfica cómo unir los vértices
del bloque para formar una tira de triángulos.
Los autores afirman que consiguen visualizar una escena de 3744 triángulos a
una velocidad de 7 animaciones por segundo en un dispositivo PocketPC Toshiba
e800, empleando como medio de conexión una red cableada USB 2.0 a 480 Mbps.
Esta técnica, aunque rápida en dispositivos muy poco potentes, es burda y padece
ciertos inconvenientes. No se emplea una estructura jerárquica multirresolución, lo
que impide la transmisión progresiva de bloques de terreno. Es decir, para visuali-
46
zar un bloque de terreno (incluso a su menor nivel de detalle), han debido descargarse previamente todos sus vértices. Además, no se resuelven las discontinuidades
geométricas entre bloques adyacentes a distinto nivel de detalle. Esto hace que esta
técnica no sea adecuada en la mayorı́a de las aplicaciones.
De una forma similar, Wen et al. [33] también divide el mapa de alturas en una
rejilla de bloques, pero cada bloque se representa mediante un quad-tree. Desgraciadamente, la vaga descripción que ofrece el artı́culo de la técnica, junto con la
ausencia de una adecuada evaluación de rendimiento, no nos permite juzgar correctamente esta propuesta. Por último, se trata de una técnica de visualización local,
puesto que no se aborda el problema del envı́o de terreno cliente-servidor.
4.
El Método Hı́brido
En esta sección describiremos nuestro método para realizar la descarga y visualización de terrenos en dispositivos móviles. Este método está especı́ficamente diseñado para utilizar redes comerciales de bajo ancho de banda, por ejemplo, GPRS
y UMTS.
Básicamente, nuestro método consiste en una técnica de visualización hı́brida
que reparte las tareas de visualización entre un servidor remoto, generalmente dotado de grandes recursos tanto software como hardware, y un cliente mó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 estén cercanos a la posición del usuario y que sean necesarios para su visualización.
3. La generación y envı́o al cliente de imágenes bidimensionales que sirvan para
reemplazar la proyección de la geometrı́a del terreno situada lejos de la posición
del observador.
En Informática Gráfica, estas imá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 visualización en tiempo real del terreno situado cerca de la posición del usuario. Esta visualización se realiza conforme al nivel de detalle requerido.
2. La visualización del impostor que reemplaza a el terreno real situado en el fondo
de la escena.
3. Conforme el usuario varı́e su posició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 congestión de la red y la calidad
de visualización requerida.
En resumen, nuestro enfoque de visualización hı́brido de terrenos ofrece las siguientes ventajas:
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 área de terreno a ser dibujada por el cliente puede ser menor sin que ello
repercuta en una reducción de la distancia de visualización.
El servidor puede emplear cualquier tipo de técnica de visualización de terrenos
para la generación de los impostores, incluidas aquellas basadas en la GPU.
No es necesario la generación de impostores a alta resolución, ya que las pantallas de los dispositivos móviles son pequeñas, usualmente con resoluciones de
320×240 y 640×480 pı́xeles. Este hecho permite ahorrar ancho de banda y reducir el cómputo en el servidor.
5.
El Terreno
La descarga y visualización adaptativa de grandes superficies de terreno en dispositivos mó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 móviles, nuestros algoritmos y estructuras
de datos han sido diseñados persiguiendo la simplicidad, eficiencia y escalabilidad.
5.1.
El QuadTree Restrictivo
El término árbol cuaternario o quadtree [29] se emplea para describir una clase
de estructuras de datos jerárquicas bien conocidas basadas en el principio de descomposició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 división recursiva en
cuatro cuadrantes. La estructura de datos de un quadtree consiste en un árbol en
el que cada nodo tiene exactamente o cuatro nodos descendientes o ningú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
(a)
(b)
Fig. 5 Ejemplos de: a) Quad-tree no restrictivo. b) Quad-tree restrictivo.
El uso del quadtree para la triangulación y visualización de superficies implica
seguir los siguientes pasos:
1. Obtener una rejilla uniforme de muestras de la superficie.
2. Evaluar cada región con respecto a algún criterio de aceptación (métrica de aproximació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 aceptación en toda la
superficie del terreno.
5. Generar una malla de triángulos por cada región del quadtree y visualizarla.
Un quadtree restrictivo [7] es una descomposición jerárquica del espacio que
deriva de la estructura de datos del quadtree. No obstante, se añade una restricción
adicional que implica que cuadrantes adyacentes pueden diferir en como máximo
un nivel en la jerarquı́a del quadtree, ver Figura 5. En este caso, decimos que el árbol
está localmente equilibrado.
5.2.
Estructura de Datos propuesta
A continuación describimos nuestra estructura de datos para representar la representació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 tamaño. Cada bloque contiene una región cuadrada del
mapa de alturas que incluye (2n + 1) × (2n + 1) valores de altura, siendo n un
49
Fig. 6 Subdivisó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.
nú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 está asociado a un bloque de terreno. Los quadtrees empleados dividen el terreno en una estructura jerárquica de bloques de terreno, y
por tanto, pertenecen a la familia de métodos de visualización de terrenos mediante árboles de bloques.
El nodo raı́z del quadtree almacena la representació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 tamañ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 subdivisión añade un conjunto de puntos del terreno que no estaban incluidos
en el nivel anterior. En nuestra solución, cada nuevo nivel de la jerarquı́a del quadtree dobla el número de puntos de la rejilla en ambas dimensiones en comparación
con el nivel anterior. Por tanto, el número total de puntos empleados se cuadriplica.
El número especı́fico de puntos añadidos en cada nuevo nivel es constante y depende del valor inicial de n0 . La Figura 6 ilustra esta idea para n0 = 2. Nótese que, tras
la subdivisión, la disposición de los puntos en la rejilla se preserva, y por tanto, la
misma regla de subdivisión puede emplearse en divisiones subsiguientes.
Este proceso de subdivisión continúa de forma recursiva, y termina cuando el
nivel de detalle alcanza la mayor precisión posible, esto es, cuando los nodos del
quadtree incluyen todos los puntos del terreno.
50
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 tambié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 ú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 técnicas de paginación de terrenos.
La estructura permite tanto la visualización como la trasmisión.
Los quadtrees son estructuras multirresolución que permiten de forma natural y
dinámica elegir el nivel de detalle que mejor se adecúe a las necesidades de la
aplicación.
El terreno se visualiza mediante largas tiras de triángulos, cuya longitud depende
del valor de n0 . Estas tiras pueden alojarse en memoria de vı́deo, lo que resulta
altamente eficiente en GPUs móviles [25, 31].
Los recursos de CPU requeridos para manejar la estructura son bajos. Ademá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 á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 éstos puede ajustarse de acuerdo con la
resolución disponible en el área cubierta por el quadtree.
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
rá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
única dentro de la estructura de datos. Esta clave está formada por dos partes bien
diferenciadas. La primera de ellas consiste en un nú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 codificació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 carácter denota sucesivamente el
cuadrante en el que se localiza el nodo en la jerarquı́a del árbol. Ası́, la longitud total
de esta cadena representa la profundidad del nodo en el quadtree. Las Figuras 8a
y 8b ilustran los códigos para un quadtree de tres niveles.
Desde el punto de vista del servidor, el conjunto de datos no es má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 continuación. Estos metadatos incluyen el identificador del quadtree,
el tamaño del mapa de alturas cubierto por el quadtree, el nú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 disposición de
datos geométricos para mejorar la coherencia de memoria y el rendimiento en las
operaciones de entrada/salida. Para minimizar el número de accesos a disco, los datos de los ficheros se almacenan de acuerdo al orden de recorrido del á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 código Morton asociado. Véase las Figuras 8b y 8c. De esta forma, nodos hermanos siempre se almacenan consecutivamente en disco, permitiendo
su recuperación conjunta mediante una única operación de lectura. Nótese además
que, dentro de un quadtree dado, el tamaño de cada nodo es constante. Por tanto,
52
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) Códigos Morton para el tercer nivel de un quadtree. b) Códigos Morton para cada nivel
del quadtree. c) Organización del fichero que almacena un quadtree.
esta organización en disco permite calcular en tiempo constante la posición de un
nodo concreto dentro del fichero. Por último, señ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 homóloga del servidor, almacena una
rejilla de quadtrees. No obstante, esta rejilla constituye solo un pequeño subconjunto
del total disponible en la base de datos del servidor. Este subconjunto define un
área de terreno cuadrada centrada en la posición del observador que garantiza que
pueda visualizarse la escena para cualquier posible lı́nea de visión. Dependiendo
de qué 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 pequeño tamaño de las memorias
incluidas en los dispositivos móviles, la base de datos del cliente se actualiza de
forma adaptativa.
53
Cada nodo de quadtree de la base de datos del cliente almacena dos conjuntos
de información. El primer conjunto está constituido por la geometrı́a del bloque de
terreno y la textura asociada. La geometrı́a se almacena como un único vector de
vértices tridimensionales, lo cual resulta óptimo para su visualización. Las coordenadas de los vértices emplean como origen la esquina inferior izquierda del nodo en
cuestión. Aparte, el nodo raı́z del quadtree almacena un vector de coordenadas de
textura y un conjunto de máscaras de ı́ndices [24], que son compartidos por todos los
nodos de la jerarquı́a del quadtree. Estas máscaras se emplean para la visualización
del quadtree. El segundo conjunto consiste en la traslación y escalado que es preciso
aplicar al bloque de terreno contenido en cada nodo para su correcta visualización
respecto al modelo completo del terreno.
5.5.
Aritmética Entera y Precisión
La mayorı́a de los métodos de visualización de terrenos emplean vértices expresados mediante números reales. No obstante, muchos dispositivos mó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 método, las coordenadas de los puntos se representan mediante enteros cortos de dos bytes. Aparte de
mejorar el rendimiento de las operaciones aritméticas, el tamaño de los vectores de
vé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 móviles y que las redes inalámbricas son lentas, una reducción
tan considerable del tamañ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 segmentación del terreno en pequeñ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 precisión que afecta a los valores de altura del terreno.
Como el rango de los números enteros cortos oscila entre 0 y 65536, los valores de
altura expresados en metros deben escalarse para cubrir todo este rango numérico.
De no hacerse ası́, la resolució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 método, un impostor consiste en una imagen sintética bidimensional
que simula una vista amplia del terreno fı́sico situado lejos del observador. Estos
impostores reciben el nombre de panoramas, [4].
54
Un panorama captura la escena visible en todas las direcciones desde un punto
del espacio dado. Para visualizar un panorama, é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
ilusión de estar rodeado por una escena situada a una distancia infinita y que cubre
los 360 grados a su alrededor. Las formas tridimensionales má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, véase la Figura 9a. Este tipo de
panoramas no cubre totalmente las rotaciones verticales, esto es, el usuario tiene
limitada su visión hacia arriba y hacia abajo.
Panoramas esfé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 dirección. Como contrapartida, estos panoramas crean distorsiones en
la imagen y su visualización es poco eficiente.
Panoramas cúbicos. En el caso de los panoramas cúbicos, ver Figura 9c, la imagen se proyecta en las seis caras internas de un cubo. Al igual que los panoramas
esféricos, los panoramas cúbicos cubren todas las posibles lı́neas de visión del
observador. Pero al contrario que éstos, son altamente eficientes puesto que son
geométricamente muy sencillos de visualizar.
Nuestro método emplea panoramas cúbicos. Un panorama proyectado sobre un
cubo suele recibir habitualmente el nombre de skybox [32] o mapa de entorno [3].
La construcción del panorama cúbico es sencilla [6]. Cada cara cubre 90 grados de
visión, tanto horizontalmente como verticalmente. Para construir el panorama, el
servidor coloca primero su propia cámara en las coordenadas del observador proporcionadas por el cliente. A continuación, el servidor utiliza el terreno distante para sintetizar seis imágenes ortogonales. Estas imágenes son comprimidas mediante
algún algoritmo estándar de compresión de imágenes, por ejemplo JPEG, y enviadas
al cliente.
El cliente construye la escena final mostrada al usuario mediante composició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 función de cierto nivel de detalle. No obstante, el terreno mostrado al
usuario en la pantalla debe carecer de discontinuidades apreciables. Por tanto, nuestra técnica divide el terreno entre terreno cercano y panorama como se explica a
continuación.
Considérese que el volumen de visión del cliente esté limitado por los planos
de recorte delantero y traseros, situados respectivamente a una distancia z f rontc y
zbackc del punto de visión. Similarmente, considérese que el volumen de visión del
servidor esté limitado por los planos de recorte situados a distancia z f ronts y zbacks .
(a)
55
(b)
(c)
Fig. 9 Las formas má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 cámara es la misma tanto para cliente como para servidor.
Bajo estas condiciones, el cliente visualiza el terreno próximo al observador,
mientras que el alejado queda fuera de su volumen de visión. Por el contrario, el
servidor recorta la parte cercana de la escena, y solamente tiene en consideración la
alejada cuando construye el panorama.
56
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
Fig. 11 Escenas dibujadas por un Nokia N95. La resolución de los panoramas era de 256 × 256
pı́xeles por cara del cubo. a), c), e) y g) imágenes con panorama. b), d), f) y h) imágenes sin
panorama.
zbacks
zbackc
zfronts
zfrontc
Servidor
Cliente
Fig. 12 División del volumen de visión entre cliente y servidor.
7.
Actualización del Terreno
El servidor efectú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 efectúa la descarga, los datos disponibles localmente se emplean para
visualizar la parte del terreno afectada, aunque sea a menor calidad de la deseada.
57
Fig. 13 Al desplazarse el punto de visión, siempre se mantiene un área cuadrada de bloques activos.
Cuando el usuario arranca la aplicació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 visualización
aproximada del terreno a baja resolución. Conforme el usuario se desplaza a lo largo
del entorno virtual, la base de datos local se actualiza manteniendo siempre una
región de terreno cuadrada alrededor del observador. Se descargan todos aquellos
datos que sean precisos para la visualización, y se borran aquéllos que ya no sean
necesarios.
Nuestra representación del terreno se divide en dos niveles. De forma análoga, la
operación de actualizació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 tamañ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 análoga a los
clásicos sistemas de paginación de terrenos, [22], donde el objetivo es mantener
un área cuadrada activa centrada alrededor del punto de visión. Si el punto de
visió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 á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 visualización.
En el segundo paso, pueden emplearse múltiples criterios para determinar el conjunto de nodos activos. Nodos activos son aquéllos que será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 observación
58
de que, en general, la resolució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 parámetro configurable que determine
la calidad del terreno. Entonces, definimos la importancia de un nodo, f , como
f=
d
e ·C
(3)
Para una descripción más detallada de esta expresió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 evalúa la expresión
de la Ecuación 3:
Si f < 1 y no se ha alcanzado una profundidad máxima del árbol prefijada, digamos max depth, entonces el recorrido del árbol continú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 visualizació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 máxima del árbol prefijada max depth,
entonces el nodo se marca como activo lo que implica que será visualizado en el
siguiente ciclo de dibujado. Si el nodo tiene hijos, se eliminan puesto que ya no
son necesarios para la visualización del terreno. La recursividad termina.
Para evitar volver a descargar nodos que han sido recientemente borrados (por
ejemplo, si el observador vuelve atrás sobre sus pasos), empleamos una técnica de
caché para mantener en memoria algunos de los nodos de quadtree a pesar de que ya
no sean necesarios para su visualización. Nuestra técnica consiste en definir un valor
umbral, σ ≥ 1, tal que aquellos nodos que satisfagan σ > f > 1 en la Ecuación 3
no son borrados ni visualizados, pero se mantienen en memoria en previsión de un
posible uso futuro.
8.
Actualización del Panorama
Según se desprende de las ecuaciones de la proyección en perspectiva dadas en la
Sección 2, conforme la distancia de la cámara a una zona del terreno se incrementa,
su proyección resulta menos significativa. Además, los cambios en la proyección de
puntos alejados producidos por variaciones pequeñas de la posición del observador
son prácticamente inapreciables. Por tanto, enviar un nuevo panorama al cliente por
cada movimiento del observador resulta en un tráfico inútil de datos.
En esta secció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 actualización del panorama se basa en determinar
59
Fig. 14 Traslació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 combinación de
traslaciones y rotaciones. Debido a que los panoramas cubren 360 grados de visión alrededor del observador, cambiar la lı́nea de visió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 traslación general puede definirse como la combinació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 visión.
En ambos casos, la distancia d del observador hasta el plano de proyección se
mantiene constante.
8.1.
Traslación a lo Largo de los Ejes X e Y
Sea Vs el conjunto de los puntos situados en el volumen de visión del servidor, y
Vc el conjunto de puntos en el volumen de visión del cliente (ver Figura 12). Ahora,
considé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 visión del servidor. Entonces, cuando
el panorama se genera, el servidor proyecta el punto P en el punto Pp situado sobre
el plano de proyecció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
′
εx = Ppx
− Ppx ;
′
εy = Ppy
− Ppy
(4)
Como se esperaba, cuanto mayor sea la traslación del observador, mayor será el
error. Consecuentemente, conforme el observador se aleje de la posición inicial, se
volverá más aparente una discontinuidad entre el terreno visualizado localmente en
tiempo real y el panorama.
Teniendo en cuenta la proyección en perspectiva definida en la Ecuació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 cá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 proyección se
incrementa. Ignorando el signo, la traslación del observador a lo largo del eje X
correspondiente a un umbral de error dado, εx , es
|OO′ | = εx
Pz
d
El máximo error posible para cualquier punto P(x, y, z) ∈ Vs se produce para aquellos puntos que estén situados a la menor distancia posible del observador. Ahora bien, ningún punto proyectado sobre el panorama puede encontrarse má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 defición de panorama realizada en la Sección 6,
zbackc = z f ronts . Por tanto, para preservar la continuidad en la transición terrenopanorama, deberemos actualizar el panorama cada vez que la traslación del observador satisfaga la siguiente expresión:
|OO′ | > εx
zbackc
d
(6)
61
Fig. 15 Traslación a lo largo del eje Z.
De forma análoga, y si la ventana de visión no es cuadrada, también actualizaremos
el panorama cada vez que se verifique:
|OO′ | > εy
8.2.
zbackc
d
(7)
Traslación a lo Largo de la Dirección de Visión
Teniendo en cuenta que en nuestro método, la distancia focal d se mantiene siempre constante, consideremos ahora una traslació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 sección anterior, las componentes del
punto proyectado antes y después de que el observador haya variado su posición
son:
d
d
′
Ppx = Px ;
Ppx
= Px
(8)
Pz
Pz − |OO′ |
Para mantener constante la distancia d, el plano de proyección debe trasladarse de
forma solidaria junto al observador. Nótese que, en general, cuando el observador
se mueve a lo largo del eje Z, los puntos proyectados se desplazan simultáneamente
a lo largo de ambos ejes, X e Y, del plano de proyección. El error definido por la
Ecuación 4 es
′
εx = Ppx − Ppx
(9)
Combinando las Ecuaciones 8 y 9, tenemos
62
Fig. 16 Los Puntos P situados sobre el plano de recorte lateral definen el ángulo de visió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 traslación permitida a lo largo del eje
Z es
!
d
|OO′ | = Pz 1 − Pz
(10)
Px εx + d
La expresión de la Ecuación 10 puede reescribirse en función de los parámetros que
definen el volumen de visión. Considérese que P(x, y, z) es un punto arbitrario en Vs
y que w denota la mitad del ancho de la ventana de visión. Entonces, ningún punto
P(x, y, z) dentro del volumen de visión del servidor puede encontrarse más allá del
plano de recorte lateral que corta al plano de proyección en w, ver Figura 16.
63
En consecuencia, tenemos
tan(α ) =
Px
w
<
Pz
d
Y por tanto
Pz
d
>
Px
w
(11)
Reemplazando la Ecuación 11 en la Ecuación 10, obtenemos
!
w
d
′
= Pz 1 −
|OO | ≥ Pz 1 − d
εx + w
w εx + d
De acuerdo con la definición de panorama realizada en la Sección 6, los puntos
del terreno satisfacen que Pz ≥ zbackc , (ver Figura 12). Consecuentemente, el cliente
debe solicitar al servidor una actualización del panorama cada vez que se satisfaga
la siguiente condición:
w
′
(12)
|OO | ≥ zbackc 1 −
εx + w
8.3.
Algoritmo para Actualizar el Panorama
En nuestro método, tanto cliente como servidor necesitan compartir los siguientes parámetros:
O: La posición del observador.
d: La distancia focal de la cámara.
w: La mitad de la anchura de la ventana de visión sobre el plano de visión.
El algoritmo para actualizar el panorama puede sintetizarse en los siguientes pasos:
1. El observador se desplaza desde su posición original O hasta una nueva posición
O′ .
2. El cliente visualiza el terreno cercano de acuerdo con la nueva posició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 panorá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.
Transición de Panoramas
Cuando el cliente recibe un panorama, éste permanece vá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 fácilmente detectable por el usuario. En esta
Sección proponemos una técnica que emplea multi-texturas para implementar una
animación de transición que oculta de forma efectiva y eficiente el cambio entre
panoramas.
Si el dispositivo está dotado de una GPU programable, el efecto de transición
puede implementarse mediante un programa de fragmentos. Si se carece de ella,
puede conseguirse el mismo efecto mediante una función de combinació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 imágenes de ambos panoramas, el viejo y el nuevo, se aplican de manera
simultá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
gráficas tal y como OpenGL ES. Ahora, definimos una función de combinació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 función del tiempo de acuerdo a la siguiente
expresión:
t − t0
t − t0
c0 +
c1
c(t) = 1 −
dur
dur
donde t0 es el instante de tiempo en el que arranca la animación, dur es la duración
de la misma y t es el instante de tiempo actual, todos ellos expresados en segundos.
Al principio de la animación de transición, solo es visible el color del panorama
antiguo, c0 . Conforme la animación progresa, el color de este panorama se combina
progresivamente con el del nuevo panorama de acuerdo a la expresión anterior. Al
final de la animación, el panorama viejo deja de ser visible y puede descartarse.
En nuestros experimentos, una duración de la transición dur = 0,5 segundos ofrece
resultados satisfactorios.
9.
Visualización
En esta sección se explica cómo se lleva a cabo la visualización del terreno. La
operación de actualizació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.
65
Fig. 17 Representación 2D del recorte mediante el volumen de visión. Los bloques en gris no se
visualizan.
9.1.
Dibujado Mediante Máscaras de Índices
La operación de dibujado se efectúa una vez por cada marco de animación. Se
efectú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 visió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 triángulos mediante el uso de máscaras de ı́ndices, [24]. Dado que el número
de puntos de terreno alojados en cada nodo de un quadtree es constante (ver Sección 5.2), las máscaras de ı́ndices son iguales para todos los nodos de un mismo
quadtree dado. Puesto que además, las máscaras no varı́an durante la ejecución del
programa, podemos pre-calcularlas y compartirlas entre todos los nodos del mismo
árbol.
El bloque de terreno contenido en el nodo se visualiza como una única tira de
triángulos mediante el uso de la máscara correspondiente, ver Figura 18a. No obstante, en la unión entre nodos adyacentes a distinto nivel de detalle pueden aparecer
discontinuidades geométricas evidentes como las que se aprecian en la Figura 19a.
Estas discontinuidades deben ser evitadas. A tal fin hacemos uso de tiras de triángulos de unión que se adaptan a la resolución de ambos nodos, tal y como se aprecia
en la Figura 19b. Como se afirmó en la Sección 7, el nivel de detalle de nodos adyacentes puede diferir como mucho en una unidad. Por tanto, el número de tiras de
unión necesarias es pequeño. Las tiras empleadas en nuestra técnica se ilustran en
las Figuras 18b y 18c.
Para determinar las tiras de triángulos necesarias para la visualización del bloque
de terreno contenido en un nodo, primero debemos identificar a los cuatro nodos
adyacentes. Para ello, empleamos sus respectivos códigos Morton. Si el nivel de
detalle de los cuatro nodos adyacentes es igual o menor que el del nodo actual,
66
(a)
(b)
(c)
Fig. 18 a) Tira de triángulo para un nodo de 9×9 (n0 = 3) valores de altura. b) Tiras de unión
para nodos adyacentes con el mismo nivel de detalle. c) Tiras de unión para nodos adyacentes con
distinto nivel de detalle.
(a)
(b)
Fig. 19 a) Discontinuidad geométrica. b) Uso de tiras de triángulos de unión (en rojo) para evitar
discontinuidades.
entonces éste se dibuja mediante una malla de triángulos cuadrangular. Para generar
esta malla se utiliza una única tira de triá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 unión para evitar
discontinuidades geométricas en la frontera de los bloques. En este caso, los puntos
del terreno de la zona interna del bloque se dibujan mediante una única tira que
genera una región cuadrangular de terreno. Pero para dibujar los cuatro bordes del
bloque de terreno, es preciso utilizar cuatro tiras de unión, una por cada lado del
bloque de terreno. Para cada lado se selecciona la tira que coincida con la resolución
del nodo adyacente a ese lado. Las Figuras 18b y 18c ilustran estas ideas.
Trabajos como [15] también hacen uso de tiras de triángulos especiales para unir
nodos de quadtree adyacentes. Si bien, permiten cualquier diferencia de nivel de
detalle entre nodos adyacentes. Como consecuencia, el número de tiras de unión
a pre-calcular es muy elevado, ya que deben contemplarse todas las posibles com-
67
binaciones. Además, las tiras necesarias para unir nodos con diferencia de nivel
de detalle mayor que uno contienen triángulos desiguales, largos y estrechos. Este
hecho aumenta conforme la diferencia de nivel de detalle también aumenta. Como
consecuencia, las tiras de triángulo generadas son de mala calidad. En nuestra té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 triángulos
necesarios son rectá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 animació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 visualización en reiteradas ocasiones sin necesidad de
reenviar la geometrı́a desde memoria principal a la GPU. De esta forma, se reduce
de forma drástica el trasiego de datos entre CPU y GPU. Las máscaras de ı́ndices
también se almacenan como VBOs en memoria de la GPU, donde son reutilizadas
para dibujar todos los nodos de la estructura. Las GPUs móviles que satisfagan las
especificaciones de OpenGL ES 1.1 ó 2.0 incluyen soporte para VBOs. Esta es la
forma más óptima de transferir vértices e ı́ndices a las GPUs móviles [25, 31]. Para
aquellas plataformas en las que no se soporten VBOs, pueden emplearse vectores
de vértices estándar, si bien entonces es preciso el envı́o de la geometrı́a a la GPU
por cada marco de animación.
Agradecimientos Este trabajo ha sido parcialmente financiado por el Ministerio de Ciencia e
Innovación y la Eunión Europea (fondos FEDER) a través del proyecto TIN2011-25259 y la Universidad de Jaén a través del proyecto de investigación UJA2010/13/08, financiado por Caja Rural
de Jaé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.
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, Université 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.
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.
Introducción de información geográfica en
terrenos 3D
Ángel Aguilera Garcı́a, J. Roberto Jiménez Pérez y Francisco Martı́nez del Rı́o
Resumen En los últimos años, con la aparición de ordenadores personales más pequeños y más potentes, se ha puesto de manifiesto la importancia de poder representar en tres dimensiones los sistemas de información geográfica (SIG) que tradicionalmente se ha estado representando en dos dimensiones.
En la actualidad, con la incorporación en los diferentes dispositivos móviles de procesadores gráficos más potentes, ası́ como la agregación de elementos para poder
detectar su posición geográfica y la posibilidad de conexión a diferentes redes, surge la posibilidad de poder representar información geográfica en tiempo real. Para
poder llevarlo a cabo, podemos identificar tres fases, por un lado determinar cómo
implementar un motor que pueda representar el terreno en 3D, por otro lado el pegado de texturas para hacer más real la escena y por último el cómo incorporar a
ese terreno la información geográfica procedente de una serie de bases de datos a la
que se accede a través de una red de ordenadores. En este capı́tulo mostramos una
introducción sobre los diferentes formas de representar la información geográfica y
nos centramos en mostrar las diferentes técnicas que se han desarrollado para poder
realizar las tres tareas.
La utilidad que nos proporciona el poder visualizar los SIG en 3D es múltiple y
variada, dando la posibilidad de poder analizar exploratoriamente los datos, analizar la información para poder confirmar hipótesis, difundir la información, generar
hipótesis y tomar decisiones.
Ángel Aguilera Garcı́a, e-mail: [email protected]
Juan Roberto Jiménez Pérez, e-mail: [email protected]
Francisco Martı́nez del Rı́o, e-mail: [email protected]
71
72
1.
Introducción a la cartografı́a
Una posible definición de cartografı́a podrı́a ser como el conjunto de estudios y
operaciones cientı́ficas, artı́sticas y técnicas que intervienen, a partir de los resultados de las observaciones directas o de la explotación de una documentación, en
el establecimiento de mapas, planos y otras formas de expresión, ası́ como en su
utilización.
La cartografı́a apareció 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 año 16.500 a.C. , tratándose muy
probablemente de mapas de estrellas y constelaciones.
El primer mapa terrestre que se reconoce se encuentra en la ciudad de Çatalhöyük,
en Anatolia (Turquı́a) tratándose de un plano de la ciudad (ver Figuras 1 y 2) y datado en torno al año 6.200 a.C. [1].
Despué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 años 2.300 y el 3.800 a.C. El interés por representar
la información en mapas fue creciendo paulatinamente dando lugar a la geodesia.
Esta se puede definir como la ciencia que estudia la forma y el tamaño de la Tierra,
ası́ como la manera de localizar elementos en su superficie. Pero fue Eratóstenes
(275-195 a.C.) el que utilizó el té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 añadiendo las nuevas
tecnologı́as, apareciendo de este modo una nueva disciplina denominada geomática
Fig. 1 Plano de Çatal Höyük.
El plano está pintado sobre
una pared y mide más de 2,5
m. Imagen cortesı́a de Ali
Turan en Turkey in maps
http://www.turkeyinmaps.com
Fig. 2 Plano de Çatal Höyük.
Recreación del plano original
donde se aprecia la estructura
de la ciudad. Al fondo se divisa un volcán, probablemente
el Hasan Dag en erupción, todavı́a hoy visible desde Çatal
Höyük
Introducción de información geográfica en terrenos 3D
73
(en 1969 por B. Dubuisson) [2]. Esta se define como el tratamiento automatizado de
la información geográfica. También la tecnologı́a ha proporcionado diferentes sistemas de posicionamiento geográfico como el NAVSTAR GPS o el futuro Galileo.
2.
Sistema de Información Geográfica (SIG)
Un Sistema de Información Geográfica (SIG) es una integración organizada de
hardware, software y datos geográficos diseñada para capturar, almacenar, manipular, analizar y desplegar en todas sus formas la información geográficamente referenciada con el fin de resolver problemas complejos de planificación y gestión
geográfica.
El SIG funciona como una base de datos con información geográfica (datos alfanuméricos) que se encuentra asociada por un identificador común a los objetos
gráficos de un mapa digital.
Las principales cuestiones que puede resolver un Sistema de Información Geográfica, ordenadas de menor a mayor complejidad, son:
1. Localización: preguntar por las caracterı́sticas de un lugar concreto.
2. Condición: el cumplimiento o no de unas condiciones impuestas al sistema.
3. Tendencia: comparación entre situaciones temporales o espaciales distintas de
alguna caracterı́stica.
4. Rutas: cálculo de rutas óptimas entre dos o más puntos.
5. Pautas: detección de pautas espaciales.
6. Modelos: generación de modelos a partir de fenómenos o actuaciones simuladas.
Los SIG comienzan a utilizarse a partir de la década de los sesenta, progresando estos en paralelo con la evolución de los ordenadores y con la aparición, en la
década de los setenta, de los satélites civiles. Aunque no fue hasta los ochenta, con
el abaratamiento de los ordenadores y la aparició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 satélites más potentes capaces de fotografiar la tierra con una
resolución mayor.
Las técnicas que manejan los SIG ya fueron utilizadas en el año 1854 por el
Dr. John Snow, el pionero de la epidemiologı́a. En su ya famoso mapa (ver Figura
3)representó la incidencia de los casos de cólera en el distrito de Soho en Londres.
Este SIG permitió a Snow localizar con precisión un pozo de agua contaminado
como la fuente causante del brote.
En el año 1962 Roger Tomlinson en Ottawa (Ontario, Canadá) y a cargo del
Departamento Federal de Silvicultura y Desarrollo Rural, desarrolló el llamado Sistema de Información Geográfica de Canadá (Canadian Geographic Information System, CGIS) siendo este considerado el primer SIG de la historia.
En 1964, Howard T. Fisher formó en la Universidad de Harvard el Laboratorio de
Computación Gráfica y Análisis Espacial en la Harvard Graduate School of Design
(LCGSA 1965-1991), donde se desarrollaron una serie de importantes conceptos
74
teóricos en el manejo de datos espaciales, En los setenta ya habı́a difundido código
de software y sistemas germinales, tales como SYMAP, GRID y ODYSSEY.
En la década de los años 70 y principios de los 80 se inició en paralelo el desarrollo de dos sistemas de dominio público. El proyecto Map Overlay and Statistical
System (MOSS) se inició 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 Investigación de Ingenierı́a de la Construcción del
Ejército de los Estados Unidos (USA-CERL) desarrolló GRASS como herramienta
para la supervisión y gestión medioambiental de los territorios bajo administración
del Departamento de Defensa.
En la década de los 80, M&S Computing (má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 añ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 rápido crecimiento en los diferentes sistemas se ha consolidado, restringiéndose a un número relativamente reducido
de plataformas.
Fig. 3 Mapa original del Dr. John Snow. Los puntos son casos de cólera durante la epidemia en
Londres de 1854. Las cruces representan los pozos de agua de los que bebı́an los enfermos
3.
75
Representació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 elevació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 idéntico tamaño y se almacena una información determinada asociada a cada una de estas celdas.
Vectorial: se expresan como vectores, manteniendo las caracterı́sticas geométricas de las figuras. Está formada por primitivas geométricas, con las posiciones
de sus vértices en el sistema de coordenadas utilizado.
Los datos independientemente del formato utilizado, ya sea en formato raster
o vectorial, pueden almacenar una informació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 posición sobre la Tierra de los datos geográficos, se trabaja
con un sistema de coordenadas en el que representar dichas posiciones. Según el
estándar ISO 19111 (Spatial referencing by coordinates), existen tres sistemas de
coordenadas [2]:
Cartesiano: establece un espacio tridimensional donde el origen de coordenadas
se sitúa en el centro de la Tierra, el eje Z se sitú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 proyección. El más utilizado es la
proyección UTM (Universa Transverse Mercator)(ver Figura 4). Este sistema de
proyecció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.
Modelos topográficos para la representación de terrenos
Para representar terrenos los modelos topográficos que se usan suelen estar basados en mallas de polı́gonos regulares (grids) o mallas de polı́gonos irregulares de
triángulos (triangulated irregular networks) TIN (ver Figura 5).
Las mallas regulares está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 óptimo para el hardware grafico (solo se guardan los valores de las
alturas ordenados en una matriz) y la distribución homogénea de los puntos, que
facilita los cálculos como para ver intersecciones entre elementos. La desventaja
fundamental que presenta es que el detalle del terreno es homogéneo siendo el mismo para una zona llana como para una montañ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
triángulos que se aproximen a triángulos rectángulos. El proceso más utilizado para
la triangulación es el de Delaunay. Las mallas irregulares presentas varias desventajas como los cálculos que tiene que hacer el hardware para poder renderizar los
triángulos, mayor tamaño de almacenamiento por tener que almacenar las coordenadas y la altura para cada punto. La ventaja fundamental es que permite la adaptación
más próxima a las caracterı́sticas de terreno, representando zonas llanas con menos
puntos y zonas más rugosas con más puntos. Ver Figura 6
5.
Visualizació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 cá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 técnicas de paginación y de memoria caché para los problemas de memoria y para los cálculos de
Fig. 6 Triangulación de Delaunay de un terrenos
77
la geometrı́a se ha utilizado la representación del terreno con diferentes niveles de
detalle (LOD) [8].
Dentro de la cartografı́a aparece el término generalización [9, 10], que consiste
en el proceso de representar la información en un mapa adaptándola a la escala de
dicho mapa.
De los diferentes métodos desarrollados para la visualización de terrenos, los
más destacados son:
Lindstrom et al. [11] desarrollaron técnicas de visualización de terreno utilizando LOD continuos para la gestión de una geometrı́a poligonal basada en mallas
regulares.
Duchaineau et al. [12] presentaron la técnica denominada ROAM (Real-time
Optimally Adapting Meshes). Esta técnica trata el problema de la gestión de
LOD para mallas regulares de geometrı́a.
Rabinovich y Gotsman [13] publicaron una técnica para visualizar el terreno a
partir de datos de elevación, de una malla regular y textura procedente de imágenes aéreas o de satélite.
Röttger et al. [14] desarrollaron una técnica basada en la de Lindstrom, pero utilizando estructuras quadtree en lugar de bintree y una aproximación descendente
en lugar de la ascendente de Lindstrom.
Hoppe [15, 16] propone una técnica, denominada mallas progresivas o PM (progressive meshes) que utiliza mallas irregulares (TIN).
Leila De Floriani y Enrico Puppo [17], proponen la multitriangulación (MT)
utiliza diferentes niveles de detalle siendo estos generados con TIN.
Willem H. De Boer [18], publicó una técnica denominada GeoMipMapping que
aplica el concepto de mipmap [42] al campo de la geometrı́a.
Lindstrom y Pascucci [19], publicaron una té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, separándose de la tendencia existente
hacia los algoritmos cada vez más complicados.
Klein y Schilling [20], publicaron en 2002 una técnica de visualización en tiempo real de terreno multirresolución basada en una partición y organización en una
estructura jerárquica de tipo quadtree adecuada para su transmisió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 técnica de gestión de geometrı́a denominada Geometry Clipmaps.
Alex Holkner [24] publicó otra técnica basada en el concepto de clipmap a la
gestión de geometrı́a de terreno.
78
6.
Incorporación de texturas a un terreno
Para darle más realismo a la visualización del terreno se le debe de añadir una textura a su representación geométrica, para ello se han desarrollado diferentes técnicas, destacando las siguientes:
Ed Catmull [25], esta técnica consiste en aplicar una imagen sobre los modelos
geométricos de la escena visualizada.
Michael Cosman [26], describe una técnica basada en la la utilización de una
textura global de terreno que no se repite, cada zona de la textura tiene una posición geográfica y se dibuja en una única posición de la geometrı́a. Esta técnica
tambié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 resolución.
Christopher C. Tanner, Christopher J. Migdal y Michael T. Jones [27], presentaron una técnica de mapeado de texturas arbitrariamente grandes, a la que llamaron The Clipmap.
Tobias Hüttner [28], publico una técnica que dividı́a la imagen de gran resolución en una serie de fragmentos rectangulares de igual tamaño.
Rabinovich y Gotsman [13], almacenaron la textura en un servidor, dividiendo
la extensión del terreno en un mosaico de trozos. Estos trozos de textura están
comprimidos utilizando una técnica de wavelets progresivos.
David Cline y Parris K. Egbert [29] publicaron un artı́culo sobre el uso de texturas de gran tamaño. En él describen una arquitectura software para la gestión de
cualquier tipo de texturas.
Jürgen Döllner et al. [30], realizaron una técnica la cual consistı́a en partir de la
textura original y construir una pirámide y un árbol de fragmentos de textura a
diferentes niveles de detalle, donde cada fragmento de textura está asociado a un
fragmento de geometrı́a del modelo geométrico multirresolución.
Reinhard Klein y Andreas Schilling [20], proponen una técnica para la gestión
de textura de muy alta resolución aplicada a terrenos extensos.
Cignoni et al. [21, 22], publican una técnica que gestiona la textura del terreno
troceándola en porciones y organizándola mediante una estructura jerárquica de
tipo quadtree.
Losasso y Hoppe [23], realizaron una técnica en la que a cada nivel del clipmap
de la geometrı́a se le asocia una textura, de forma que la gestión de LODs se
realiza conjuntamente.
Alex Holkner [24], propone una variante de Geometry Clipmaps basada en
GPUs programables.
Anders Brodersen [31], propone una técnica basada en la gestión de la geometrı́a
uniendo esta con las texturas mediante un mosaico.
Anton Ephanov y Chris Coleman, [32] desarrollan una técnica de gestión de
texturas de gran tamaño, en la que introducen las dos opciones habituales para la
gestión de texturas de gran tamaño: los mosaicos de texturas y los clipmaps.
7.
79
Representación de terrenos 3D con datos vectoriales 2D
La información cartográfica suele estar almacenada en datos vectoriales 2D. Estos datos antes de representarlos sobre el terreno se tienen que adaptar a la resolución
del mismo, mostrando en cada caso solo los datos más relevantes, esta técnica es lo
que se conoce como generalización. La NCGIA define la generalización como ün
grupo de técnicas que permiten mantener la cantidad de informació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 métodos, o bien pasar los datos a una
textura y a continuación pegarla sobre el terreno, o bien adaptar los datos vectoriales
sobre la geometrı́a 3D.
Los trabajos más relevantes publicados que resuelven el problema de visualizar
terrenos 3d en los que se representa información vectorial 2D son:
Zachary Wartell et al. [33, 34, 35] describen una técnica que adapta la geometrı́a
vectorial 2D del SIG a la superficie 3D del terreno.
Agrawal et al. [36] desarrollan un método en el cual se monta un sistema de visualización que divide la geometrı́a y la textura en un mosaico de trozos cuadrados de igual tamaño, manteniendo en memoria nueve de estos trozos, centrados
en la posición del espectador.
Schilling et al. [37], muestran un método que no sobrecarga el sistema pudiéndose utilizar el mismo sobre dispositivos móviles y a través de pagina web.
Oliver Kersting y Jürgen Döllner [38], desarrollan un método que primero generalizan la información cartográfica y después la pegan en el terreno mediante
una textura.
Stephen Brooks y Jaqueline L. Whalley [39], describen un método hı́brido
2D/3D para la visualización de información geográfica.
Martin Schneider et al. [40], publican un método que utiliza las dos ideas fundamentales para representar los datos sobre el terreno, montando los datos vectoriales sobre modelos 3D y pegándolos luego como si fuesen texturas.
Martin Schneider y Reinhard Klein [41], muestran una técnica basada en la
utilización del stencil buffer de openGL.
Referencias
1. J. Mellaart. Excavations of Catal Hyü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
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-Mö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 Rö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.
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 Hü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. Jürgen Dö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 Jürgen Dö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.
Visualización 3D del interior de terrenos mineros
Resumen En este trabajo se presenta como aplicar las técnicas y las amplias posibilidades del lenguaje Matlab para la simulación y visualización de terrenos. Se han
estudiado las principales funciones gráficas que ofrece este lenguaje, decidiéndonos
por el uso de los slices al ser útiles para explorar conjuntos de datos volumé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 práctico sobre datos reales de terrenos mineros.
1.
Introducción
En este trabajo se presenta como aplicar las técnicas y las amplias posibilidades
del lenguaje Matlab para la simulación y visualización de terrenos. Ası́ la Tomografı́a Eléctrica es una técnica geofı́sica empleada en el estudio del subsuelo que
consiste en determinar la distribución de un parámetro fı́sico caracterı́stico del mismo (la resistividad), a partir de un número muy elevado de medidas realizadas desde
la superficie del terreno o desde perforaciones. El diferente comportamiento geoeléctrico del medio permite obtener perfiles 2D e imágenes 3D de la distribución de
resistividades del mismo, por lo que se trata de una de las herramientas de carácter
no destructivo más eficaz para el análisis y caracterización de posibles discontinuidades del subsuelo [1]. El rango de estudio puede variar desde algunos metros hasta
centenares de metros de profundidad. Esta técnica tiene enormes posibilidades de
aplicación en diversos medios geológicos y en distintas problemáticas.
M.L. Rivero
EPS de Linares (Jaén)
83
84
En este trabajo se parte de los datos obtenidos empiricamente sobre el terreno de
la Figura 1 , para obtener una simulación de la resistividad global del terreno y su
posterior visualización.
2.
Trabajo realizado
Para la realización del trabajo se han empleado los datos proporcionados en el
articulo de los profesores [2], ellos emplearon el método eléctrico de resistividades
en su modalidad de tomografı́a eléctrica. El método se basa en la implantación de
electrodos a lo largo de perfiles, con una separación que viene condicionada por
el grado de resolución, la profundidad y los objetivos que se pretendan cubrir, de
tal modo que, a menor separación mayor resolución y a mayor separación mayor
profundidad. Para el caso concreto que nos ocupa, se realizaron distintos ensayos en
una campaña piloto con espaciado de 3, 5 y 10 m, para conseguir que, con suficiente
resolución, se pudiesen prospectar las antiguas labores superficiales que alcanzaron
unos 30-40 m de profundidad. El equipo de tomografı́a elé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 configuració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
orientación N 113 E (perpendiculares al filón principal de la concesión). Por el contrario, el Perfil 3, se extiende 315 m, con 64 electrodos, y coincide con la traza del
filón (N23 E).
A partir de estos datos vamos a realizar un estudio de las principales funciones
de Matlab para el tratamiento y la visualización de datos volumétricos con el fin de
aplicar los resultados obtenidos a la simulación y visualización de terrenos mineros.
3.
Matlab y su uso en Ingenierı́a
Matlab es un potente lenguaje diseñado para la computación técnica. El nombre
de Matlab proviene de Matrix LABoratory, dado que el tipo básico que gestiona es
una matriz (array). Matlab puede ser utilizado en computación matemática, modelado y simulación, análisis y procesamiento de datos, visualización y representación
de gráficos, ası́ como para el desarrollo de algoritmos. Es un lenguaje muy popular
en el ámbito de la computación cientı́fica que es utilizado por estudiantes, ingenieros
y cientı́ficos en universidades, institutos de investigación e industrias. Su popularidad se debe, fundamentalmente, a su potencia y su facilidad de uso.
85
Fig. 1 A. Mapa esquemático del distrito minero de Linares.B. Situación de la región estudiada y
localización de los tres perfiles analizados.
Matlab proporciona excelentes utilidades para calculos de algebra lineal, análisis
de datos, procesamientos de señales, y muchos otros tipos de soluciones numéricas
para cálculos cientı́ficos [4], [3]. Hay numerosas funciones para gráficos de 2D y
3D, y para animación.
86
4.
Gráficos en Matlab
Los gráficos son herramientas muy utilizadas para representar todo tipo de información: informació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
visulaización: funciones básicas para visualización en 2D, gráficos en 3D con iluminación y mapa de colores y un completo manejador de gráficos (Handle Graphics)
que permite diseñar sofisticados gráficos a través de la interfaz de usuario.
Algunos de los principales comandos para gráficos en 2D son:
plot: crear gráficos en lı́nea bidimensionales a partir de dos vectores.
fplot: representatar gráficamente una función de la forma y=f(x).
hist: hace histogramas
loglog: crea gráficos con escala logarı́tmica en ambos ejes x,y.
pcolor: crea un gráfico de color rectángular
Los gráficos en 3D permiten una forma muy práctica de representar datos de más
de dos variables. Podemos clasificarlos en gráficos de lı́neas y gráficos de malla y
superficie.
4.1.
Gráficos de lı́nea
Un gráfico 3D de lı́nea está constituido por una lı́nea que se obtiene uniendo
una serie de puntos en un espacio tridimensional. La forma más sencilla y básica de crear un gráfico 3D es mediante la función plot3 de Matlab, cuya sintaxis
es la siguiente: plot3(x,y,z, Éspecificadores de lı́nea’, ’Propiedades’, ’Valores’). El
siguiente fragmemnto de código visualiza el grá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.
Gráficos de malla y superficie
Los gráficos de malla y superficie son grá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 gráficos de malla y superficie se
generan en tres pasos:
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 funció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 travé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 idénticas. Matlab posee una función denominada meshgrid que crea automáticamente
las matrices X e Y. La sintáxis de esta funció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 gráfico de malla o superficie: Un gráfico de malla se compone de
lı́neas que unen los puntos, al igual que en el gráfico de superficie, aunque en este
caso las áreas resultantes entre los huecos se rellenan con colores.
a) Gráficos de malla: Se lleva a cabo mediante el comando mesh. En la Figura
3 se observa el resultado para el siguiente fragmento de código, donde X e Y
88
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) Gráficos de superficie: Se lleva a cabo mediante el comando surf. En la Figura 4 se observa el resultado para el siguiente fragmento de có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 gráficos creados tienen colores
que pueden variar en función de la magnitud z, para controlar el color de las
superficies y objetos gráficos Matlab proporciona la orden shading que controla
el color de las superficies y de los objetos grá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.
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 interpolación. Por ejemplo, las siguientes lı́neas de código dan como resultado la esfera
de la Figura 5.
subplot(3,1,3)
sphere(16)
axis square
shading interp
title(’Interpolated Shading’)
5.
Visualización de terrenos mineros mediante Matlab
Una de las necesidades más cruciales en la computación cientı́fica es la visualización de datos volumé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). ¿Cómo podemos visualizarlo gráficamente?. En el caso de una función de la forma z= f (x,y) definida sobre una regió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 función f (x,y,z),
necesitamos una hipersuperficie 4D. Matlab proporciona una serie de funciones para
visualizar datos volumétricos: isosurface, isonormal, isocolors, isocaps, smooth3,
90
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
vértices de la superficie que encierra el volumen V. Esta funció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 función
patch para crear el objeto gráfico.
patch: Es una función para crear objetos gráficos, uno o más polı́gonos definidos
por las coordenadas de sus vértices. En la Figura 6 se muestra el resultado del
siguiente fragmento de có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
91
camlight
lighting gouraud
Fig. 6 Ejemplo del uso de la orden isosurface.
smooth3: filtra los datos de un volumen V mediante la convolución de kernel determinada por dos matrices posibles: gaussiana, o box. El formato de la función
es W = smooth3(V,’filter’).
isocolors: calcula el color de un objeto gráfico a partir de una matriz de colores
C. El formato de esta funció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
Fig. 7 Ejemplo del uso de las ordenes smooth3 y isocolors.
isocaps: genera de forma similar a isosurface un objeto grá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 secció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 función isocaps a la anterior figura.
slice: visualiza un corte plano perpendicular a un volumen dado. El formato de
la funció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 método de interpolación utilizado: lineal, cúbico o vecino
má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 có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
93
Los slices son útiles para explorar conjuntos de datos volumé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 será la
opción elegida tal y como detallamos acontinuación.
Una vez analizadas estas funciones estamos en condiciones de afrontar nuestro
problema.Tal y como se indicó en la Sección 1 se pretende a partir de los datos
extraı́dos empiricamente sobre un terreno, obtener una simulació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 interpolación de estos tipos de datos Matlab proporciona la función griddata3, esta funció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 función griddata3 interpola la
hipersuperficie en los puntos especificados por (xi,yi,zi) para obtener w, el tamaño
de w es el mismo que el de xi,yi y zi, (xi,yi,zi), es un rejilla uniforme obtenida
mediante la función meshgrid para las dimensiones del terreno que se quiere simular. Ası́ la función [X,Y,Z]=meshgrid(x,y,z) produce arrays tridimensionales para
94
evaluar funciones de tres variables y visualizar volumenes tridimensionales. En el
siguiente fragmento de có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
interpolació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 visualización
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 volumétricos la solución adoptada es visualizar mediante cortes (slicing)
Fig. 11 Ejemplo del uso de la orden grid.
96
a lo largo de varios planos en 3D y visualizar los datos de estos planos mediante
mapas de colores. A continuació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 grá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 ú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 través de la función de Matlab slice aplicando el
método de interpolació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 visualización de datos volumétricos, con el fin de su
aplicación para la visualización de terrenos mineros. A partir de los datos extraidos empiricamente sobre un terreno minero se ha obtenido una simulació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 interpolación de estos tipos de datos se ha utilizado la función griddata3 de Matlab, y para la visualización se ha optado por mostrar aquellos
cortes del terreno que se deseen mediante la función (slice) aplicando el método de
interpolació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 eléctrica: una herramienta
para la detección de huecos mineros (concesión de Arrayanes, Linares-Jaén). Geogaceta, 42,
2007
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 introducción con ejemplos prácticos, Reverté, 2006
98
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 básicos
Operaciones Booleanas sobre polı́gonos
Francisco Martı́nez del Rı́o, Ángel Aguilera Garcı́a y J. Roberto Jiménez Pérez
Resumen Algunos algoritmos que calculan operaciones Booleanas sobre polı́gonos
producen como resultado un polı́gono con casi nula información topográfica. En
concreto, no se conoce qué 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 descripció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 están incluidos en un número par o impar de contornos.
1.
Introducción
Las operaciones Booleanas entre polı́gonos juegan un papel importante en distintos campos aplicados como la Informática Gráfica o los Sistemas de Información
Geográfica.
Una de sus aplicaciones en Informática Gráfica es el recorte de polı́gonos. En
este caso el polı́gono de recorte puede presentar ciertas restricciones que facilitan el
cálculo de la operació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 có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
Universidad de Jaén, e-mail: [email protected]
Ángel Aguilera Garcı́a
101
102
para procesar correctamente los casos degenerados. Liu et al. [6] tambié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 matemá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 información topográfica. En concreto, no se conoce qué vertices forman cada uno de los contornos del
polı́gono, ni se sabe si el polı́gono contiene agujeros. Esto último también ocurre en
el algoritmo de Martı́nez et al. [10].
En este artı́culo se propone cómo calcular la información topológica que no calculan los citados algoritmos [7, 8, 10].
Lo que resta de artı́culo se organiza de la siguiente forma. En la Sección 2 se describe la información topológica de un polı́gono que vamos a computar. La Sección
3 muestra cómo se pueden calcular los distintos contornos del polı́gono. Las Secciones 4 y 5 describen cómo se calcula la información sobre los contornos incluidos
en otros contornos. La última sección muestra un aná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 ningú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 intersección de todos los contornos que contienen a H. Dicho
de otro modo, P es el contorno de menor área que contiene a H. Tambié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 número par de contornos
se describen listando sus vértices en orden antihorario.
Los contornos incluidos en un número impar de contornos se describen listando
sus vé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 convención.
Dada esta representación se puede calcular el área de un polı́gono como la suma con
signo de las áreas de los contornos del polı́gono.
En las siguientes secciones se describe un algoritmo que, dada una especificación
de un polı́gono como un conjunto no conectado de aristas, calcula los contornos
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 Especificació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 orientación.
3.
Cálculo de los contornos
Los algoritmos de Rivero y Feito [7] y Peng et al. [8] calculan los sı́mplices
asociados a una operación Booleana entre dos polı́gonos; cada sı́mplice está 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 fácil calcular los
contornos asociados al polı́gono—es decir, es fácil conectar las aristas para formar
contornos—de una forma eficiente [12]. Basta con introducir en un árbol binario
de búsqueda equilibrado los extremos de las aristas del polı́gono ordenados lexicográficamente. Cada extremo almacena también el otro extremo de su arista. De
esta forma se puede empezar por un vértice cualquiera de un contorno y encontrar una cadena de aristas conectadas que terminan en el propio vértice en tiempo
O(n log n), donde n es el número de vértices del polı́gono.
4.
Cálculo de los contornos hijos
En esta sección se describe el algoritmo para el cálculo de los contornos hijos
y el cálculo del número de contornos que incluyen a cada contorno. El algoritmo
está 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—véase la Figura 2. Supondremos que las aristas del
polı́gono no intersectan entre sı́, salvo en sus extremos. Por lo tanto, S sólo cambia
cuando la lı́nea de barrido alcanza un extremo de una arista:
104
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 añadirse a S.
Cuando se alcanza el extremo derecho de una arista, la arista debe eliminarse de
S.
A continuación se describe có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 información sobre la arista p que precede a e en S. Una
información clave es saber si p representa una transició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 continuación se describe có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 ningún contorno, es decir, c es un contorno externo.
2. p representa una transición fuera-dentro en el contorno c2. Por lo tanto, c es un
contorno hijo de c2.
3. p representa una transició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 transició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 continuación se describe el algoritmo—véase la Figura 4. En primer lugar, se
insertan en un vector los extremos de las aristas y se ordena el vector lexicográ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).
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
implementación se dan en la Sección 5.1. Cuando se encuentra un extremo derecho
su arista asociada se elimina de S.
5.
Detalles de implementación
En las siguientes subsecciones se explican algunos detalles de implementación
del algoritmo que calcula los contornos hijos y el número de contornos que incluyen
a cada contorno.
5.1.
Información de contorno hijo
En esta subsección se describe la información relativa al cálculo de contornos
hijos y el pseudocódigo utilizado para el cálculo de esta información.
Las aristas almacenadas en S son registros con los siguientes campos:
inOut: un valor lógico que almacena si la arista representa una transició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
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 cá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 pseudocódigo mostrado en la Figura 5 calcula los contornos hijos teniendo en
cuenta los cuatro casos analizados en la Sección 4. Los vectores profPar e hijos almacenan la información que devuelve el algoritmo. Dado un identificador de contorno
id :
profPar [ id ] indica si el contorno cuyo identificador es id está contenido en un
número par de contornos. Esto es preciso para saber si los vé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 .
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 Pseudocódigo para calcular contornos hijos.
5.2.
Aristas verticales
Las aristas verticales son especiales porque intersectan a la lı́nea de barrido en
más de un punto. Afortunadamente las aristas verticales no juegan ningún papel en
el algoritmo, pues no representan una transición dentro-fuera o fuera-dentro en los
contornos. Por lo tanto, nuestro algoritmo las elimina en una fase de procesamiento
previo.
5.3.
Cálculo del campo inOut
El campo inOut de una arista puede calcularse fácilmente en una fase de procesamiento previo. Sea c un contorno cuyos vé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 transició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
transición fuera-dentro. Si los vértices de c están orientados de forma horaria, entonces e representa una transición dentro-fuera si x1 < x2 ; en otro caso, e representa
una transición fuera-dentro.
En caso de que se desconozca la orientación de los vértices, esta puede calcularse
fácilmente teniendo en cuenta el signo del área signada del contorno.
108
5.4.
Ordenación de los extremos
En la Sección 4 se comentó que los extremos de las aristas se ordenan lexicográficamente. Sin embargo, algunos extremos estarán situados en la misma posició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 sección se analiza el orden de complejidad del algoritmo explicado en la
Sección 4 y mostrado en la Figura 4. En el análisis denotaremos con e al nú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 continuació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)
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-Möller T., Haines E., Hoffman N.: Real-Time Rendering, 3rd Edition. A. K. Peters,
Ltd., Natick, MA, USA (2008)
Algoritmos Geométricos Básicos
Juan J. Jiménez Delgado, Antonio Martı́nez Albalá, Félix Paulano Godino y Rubén
Pulido Ramı́rez
Resumen A lo largo de este capı́tulo se incluyen algunos algoritmos geométricos
bá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 inclusión y de intersección. La segunda trata de
nuevas descomposiciones espaciales basadas en tri-trees y tetra-trees, aplicadas a
los algoritmos anteriores, ası́ como de su implementación en GPU.
1.
Introducción
En este capı́tulo se establecen una serie de algoritmos básicos, como el test de
inclusión punto en polı́gono y punto en sólido, ası́ como el test de intersección
segmento-triángulo. Todos estos algoritmos son necesarios para optimizar el tiempo
de detección de colisión entre modelos, necesitando de un cálculo robusto.
Para una mayor optimización de los tiempos obtenidos, son necesarios métodos
de descomposición espacial especialmente diseñados para reducir la complejidad
de los modelos. Se estudian métodos de descomposición espacial basados en tritrees (2D) y su generalización a 3D, tetra-trees. Esta última se ha optimizado en la
GPU mediante la programación de shaders, obteniéndose un método de cálculo de
descomposición en GPU que puede ser aplicado a otros tipos de descomposiciones
Jiménez J.J.
Universidad de Jaén, Campus Las Lagunillas s/n A3-142, e-mail: [email protected]
Martı́nez A.
Universidad de Jaén, Campus Las Lagunillas s/n A3-103 e-mail: [email protected]
Paulano F.
Pulido R.
111
112
J.J. Jiménez, A. Martı́nez, F. Paulano y R. Pulido
espaciales jerárquicas. Finalmente, se ha diseñado un método de descomposición
espacial jerárquica exacta, que permite descomponer los modelos de manera que se
optimicen las operaciones de consulta y la actualización del modelo y de la propia
descomposición de manera óptima.
2.
Algoritmos básicos
2.1.
Test de inclusión punto en polı́gono
El test de inclusión punto en polı́gono se utiliza de manera habitual en campos
como la geometrı́a computacional, la informática gráfica o los sistemas de información geográfica. En muchos de estos casos, se ha de realizar no uno, sino varios
test de inclusión de puntos en poliedros. El test de inclusión consiste en obtener un
resultado booleano en función de si un punto está contenido en el interior o en la
frontera de un polı́gono definido por una lista de vértices ordenados.
En [6], se presentan nuevos algoritmos que generalizan el algoritmo basado en
triá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
aplicación en polı́gonos en movimiento y deformables. Con este fin, se utiliza el
signo de las coordenadas baricéntricas del test de puntos con respecto a los triángulos de un recubrimiento especial del polı́gono.
2.1.1.
Generalización del algoritmo basado en triángulos
Con el fin de generalizar el algoritmo basado en triángulos mediante el uso de
coordenadas baricéntricas, es necesario establecer las bases de la inclusión punto
en triángulo. Para poder clasificar un punto con respecto a un triángulo, se utilizan tres valores únicos que representan las coordenadas baricéntricas de un punto
con respecto a un triángulo en 2D. Según la definición clásica [1], las coordenadas
baricéntricas (α , β , γ ) signadas de un punto P con respecto a un triángulo V0V1V2
quedan definidas por:
α=
|PV1V2 |
|PV2V0 |
|PV0V1 |
,β =
,γ =
|V0V1V2 |
|V0V1V2 |
|V0V1V2 |
(1)
El algoritmo basado en triángulos [2] se basa en la sumatoria del signo de los
triángulos del recubrimiento del polı́gono en el cual está situado el punto a clasificar.
Dicho algoritmo comprueba el signo de cada uno de esos triángulos y suma los
valores obtenidos, obteniendo una inclusión cuando la suma de dichos valores es
uno. Además, considera algunos casos especiales como la inclusión de una arista
113
compartida por dos triángulos del recubrimiento, considerando este caso como 21
multiplicado por el signo de cada uno de los triángulos.
El algoritmo propuesto en [6] mejora al algoritmo basado en triángulos y se diferencia de él en los siguientes aspectos:
Utiliza el signo de las coordenadas baricéntricas para la inclusión punto en
triángulo, las cuales son independientes de la orientación del triángulo.
Utiliza el signo de las coordenadas baricéntricas para comprobar los casos especiales que se dan con un punto en una arista del polı́gono o en el borde de un
triángulo.
Agrupa algunas situaciones relacionadas en las cuales un punto está dentro o
en el borde de un triángulo: por un lado, un punto estrictamente dentro de un
triángulo, por otro lado, un punto que se encuentre en una arista o vértice de un
polı́gono, y por ú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 está fuera del triángulo, después si el punto está estrictamente dentro del triángulo, a continuación si un punto está sobre el borde
del polı́gono, y por último si el punto está en una arista original.
Selecciona el origen apropiado del recubrimiento de un triángulo, de manera
que se simplifique el determinante obtenido en el cálculo de las coordenadas
baricéntricas.
Trata de manera correcta el caso de un punto situado en el origen del recubrimiento.
Tiene en cuenta los casos especiales de triángulos con área signada cero.
Optimiza el calculo del signo de las coordenadas baricéntricas al obtenerlas mediante el signo de los determinantes.
2.1.2.
Reducción de cálculos y optimizaciones
Una de las mejoras propuestas en [6] consiste en agrupar en conjuntos diferentes
situaciones que tienen un resultado común y ordenarlos. Se ha detectado que, tan
sólo en polı́gonos no convexos con un gran número de concavidades y para posiciones especı́ficas del punto a comprobar, el número de triángulos en los que el punto
es incluido es mayor que el número de triángulos en los que no lo está. Dado que
este tipo de polı́gono no es muy común, se propone descartar primero los triángulos
en los que el punto no está incluido. Observando el signo de los determinantes involucrados en el cálculo de las coordenadas baricéntricas de un punto con respecto
a un triángulo (Figura 1), se pueden obtener las siguientes conclusiones:
El
signo
del numerador
se obtiene directamente utilizando la expresión PViV j +
OPV j + |OVi P| = OViV j .
Cuando hay simultáneamente dos signos diferentes en el numerador de dos de
las coordenadas baricéntricas el signo del denominador no se deduce directa-
114
mente, pero este signo no es necesario para determinar si el punto está fuera del
triángulo.
Tan sólo se necesita el signo de los numeradores para obtener la posición del
punto con respecto al triángulo cuando el punto esta dentro del triángulo o sobre
sus bordes.
La combinación de signos de los numeradores nos da un resultado para el test
punto en poliedro con dos casos degenerados, uno cuando el punto está sobre el
origen O del recubrimiento, y otro cuando O, Vi y V j están alineados.
Fig. 1 Signos del numerador de los determinantes involucrados en el cálculo de las coordenadas
baricéntricas para el caso de un triá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 cálculo de las coordenadas baricé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 cálculo de las coordenadas baricéntricas del punto P con respecto al triángulo T = OViV j
del recubrimiento son los siguientes (Figura 2):
115
Fig. 2 Posición del punto P con respecto al triá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 cálculo del signo de estas expresiones, el factor 21 puede obviarse. Por medio de esta transformación, los cálculos necesarios para el test punto en
triángulo se han simplificado y pueden reutilizarse algunos cálculos.
Con el fin de obtener un nuevo algoritmo, en lugar de verificar la inclusión del
punto mediante el uso del signo de las coordenadas baricéntricas, en [6] se propone
utilizar tambié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 triángulo del recubrimiento OViV j , se puede obtener un algoritmo
que descarta triángulos que no satisfacen están condiciones secuencialmente:
Situación 1. Cuando β < 0 o γ < 0 el punto no se encuentra dentro del triángulo.
Esto equivale a comprobar si xi x j > 0.
116
Situación 2. No hay inclusión de P en el triángulo para triángulos con coordenadas y negativas, es decir, si yi < 0 y y j < 0.
El siguiente paso es calcular el signo de α para los triá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 posición de la arista ViV j con respecto
a los puntos P y
O. Se puede ver que P está dentro de OViV j si y sólo si PViV j > 0 y xi > x j .
Si xi < x j se obtienen conclusiones similares que en la situación anterior intercambiando los puntos Vi y V j .
P está sobre ViV j si y só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 está sobre una arista del triángulo u O está sobre el eje ViV j :
P está sobre ViV j cuando α = 0, es decir, cuando PViV j = 0 y el triángulo no
fue descartado en las situaciones anteriores.
P está sobre OV j cuando x j = 0 y el triángulo no fue descartado en situaciones
previas.
P está sobre OVi cuando xi = 0 y el triángulo no fue descartado en situaciones
previas.
Cuando O se encuentra en ViV j , OViV j es un triá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 método
Desde un punto de vista numérico, que puede verse desde la precisión de los
algoritmos y desde el tratamiento de los casos degenerados, el algoritmo presentado
en [6] es más robusto para el test punto en poliedro que los algoritmos tradicionales.
Los errores de precisión pueden suceder en el calculo de los determinantes, en
las comparaciones y en las acumulaciones:
La reducción del número de términos en el cálculo de los determinantes hace
aumentar la precisión. Mediante el uso del recubrimiento dinámico propuesto se
reduce el número de determinantes a calcular,
teniendo que realizar sólo operaciones para calcular el determinante PViV j .
Los errores cometidos en el determinante PViV j o durante la representación
numérica podrı́an causar errores al comparar, pudiendo causar errores al clasificar el punto en el borde del recubrimiento, pero no provocan una incorrecta
clasificación en el polı́gono.
Los casos degenerados se obtienen cuando el determinante
del triángulo es cero
o casi cero. Ya que el determinante del triángulo OViV j no se utiliza, tan sólo se
117
tratan los triángulos delgados con puntos situados cerca del eje y. En esta situación,
si se da un error en el cálculo de la inclusión del punto en las aristas OVi u OV j , se
obtiene un resultado correcto tal y como se ha visto previamente. La inclusión del
punto en una arista prácticamente vertical ViV j se resuelve utilizando el signo de las
coordenadas y. Si los tres puntos son prácticamente el mismo, el algoritmo descarta
el triángulo porque el punto está situado a una unidad del origen, no siendo posible
la inclusión del triángulo.
2.2.
Test de intersección segmento triángulo
Debido a que a menudo la representación de los objetos gráficos utiliza mallas
de triángulos o descomposiciones de los objetos por medio de sı́mplices, existen
muchos problemas en informática gráfica que se resuelven mediante el cálculo de la
intersección entre un segmento y un triángulo. Este es el caso del trazado y casting
de rayos, del test de inclusión, de las operaciones booleanas entre sólidos y de la
detección de colisiones.
En [9] se presenta un nuevo algoritmo para la intersección entre un segmento
y un triángulo en 3D. La idea del método es relativamente simple y consiste en
determinar las coordenadas baricéntricas de un extremo del segmento Q1 Q2 , por
ejemplo Q2 , con respecto al tetraedro Q1V1V2V3 y comprobar su signo. El uso de
coordenadas baricéntricas tienes muchas ventajas, como por ejemplo la posibilidad
de obtener la posició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 compartición de cálculos basada en la interpretación geométrica de
esas coordenadas en el contexto de la malla. También permiten de manera sencilla
la detección de casos especiales como triángulos degenerados o segmentos coplanares. Por último, estas coordenadas pueden ser utilizadas para cálculos volumétricos
y pueden usarse directamente para la interpolación de propiedades de los vértices.
Mediante el uso de la definición de volumen signado, las coordenadas baricé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 posición de un punto con respecto a su tetraedro puede establecerse utilizando las coordenadas baricéntricas. Un punto Q2 está dentro del tetraedro Q1V1V2V3 si
α , β , γ , δ ∈ [0, 1]. Además, estas coordenadas pueden utilizarse para determinar el
118
lado donde se encuentra el punto con respecto a los planos definidos por los triángulos del tetraedro. Siendo T = ABCD un tetraedro y P un punto con coordenadas
baricéntricas (α , β , γ , δ ) con respecto a T (Figura 3):
Un punto con α = 0 indica que el punto está en el plano definido por BCD.
Un punto con α > 0 indica que el punto está en el mismo lado que el punto A
con respecto al plano definido por BCD.
Un punto con α < 0 indica que el punto está en el lado opuesto del punto A con
respecto al plano definido por BCD.
La misma interpretación puede aplicarse a β , γ , δ con respecto a los planos definidos por ADC, ADB y ACB respectivamente.
Fig. 3 Interpretación geométrica de α respecto a un tetraedro
Volviendo al problema de la intersección segmento/triángulo, la intersección del
segmento Q1 Q2 y el triangulo V1V2V3 se puede determinar mediante el siguiente
teorema:
Teorema 1 Siendo V1V2V3 un triá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 sólo
si
sign (α ) ≤ 0 y sign (β ) ≥ 0 y sign (γ ) ≥ 0 y sign (δ ) ≥ 0
(4)
Siendo (α , β , γ , δ ) las coordenadas baricé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 precisión de un algoritmo geométrico puede medirse a partir de la precisión y del tratamiento de los
119
casos degenerados. Los errores de precisión pueden ocurrir tanto en las operaciones
aritméticas como en las comparaciones:
Los errores cometidos se minimizan con respecto a otros algoritmos ya que se
llevan a cabo un menor número de operaciones y un mayor número de rechazos con menos comparaciones. Además, se evita la operación de división que es
menos precisa, utilizándose tan sólo para obtener el punto de intersecció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 cálculo de las coordenadas baricéntricas, de manera que la
comparación serı́a menos susceptible a errores.
En ausencia de triángulos degenerados, los casos especiales o degenerados se obtienen cuando el segmento se alinea con el plano dónde está localizado el triángulo.
En ese caso, el algoritmo descarta el segmento, tal y como hacen el resto de algoritmos.
Es también posible descartar algunos triángulos que no están orientados en la dirección del rayo. Esta comprobación puede realizarse durante el cálculo del volumen
del tetraedro Q1V1V2V3 . Si el volumen es positivo, el triángulo V1V2V3 no está orientado en la direcció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 triángulo y Q2 en el otro lado del plano. Cuando esto ocurre el segmento debe
ser descartado.
Si es necesario calcular el punto de intersección entre el triángulo y el segmento,
este puede calcularse con un coste computacional mı́nimo: una diferencia y una
división. Estos cálculos se llevan a cabo al final del algoritmo y se basan en cálculos
previos. Esto supone una ventaja en el caso de que su cá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 triángulo se calcula al inicio del algoritmo
y se almacena en la estructura del triángulo, actualizándola cuando sea necesario, se
pueden evitar algunos cálculos.
Una aplicación de las coordenadas baricéntricas de un punto con respecto a un
triángulo consiste en su utilización para interpolar las propiedades del vértice. El algoritmo propuesto es capaz de calcular esas coordenadas con los cálculos llevados a
cabo en durante el test de intersección, pudiendo utilizar esas coordenadas para realizar cálculos de renderizado. El algoritmo propuesto puede calcular las coordenadas
baricéntricas del punto de intersección una vez que se ha calculado el parámetro t:
βP = t param · β
γP = t param · γ
(5)
δP = 1 − β − γ
son las coordenadas baricéntricas del punto P con respecto al triángulo V1V2V3 .
Al utilizar el algoritmo propuesto en mallas de triángulos, muchos cálculos pueden ser reutilizados. Para ello es necesario conocer la vecindad de los triángulos
120
o almacenar cierta información acerca de las aristas compartidas. Para las aristas
compartidas el valor de una coordenada baricéntrica de Q2 se comparte entre dos
tetraedros, aquellos formados por los triángulos que comparten esta arista y Q1 .
Una de las ventajas del algoritmo propuesto es que permite determinar si una
intersección ocurre en un vértice, en una arista, o dentro del triángulo sin coste
computacional adicional. Además, para casos de no intersección, el algoritmo propuesto lleva a cabo un gran número de tests con el fin de terminar rápidamente y
no llevar a cabo excesivos cálculos. Los cálculos acumulados para cada rechazo son
inferiores que los cálculos llevados a cabo por otros algoritmos existentes.
2.3.
Test de inclusión punto en sólido
Los test de inclusión o los test punto en sólido son una operación básica en multitud de procesos dentro de la simulación 3D: clasificación de caras o lados, detección
de colisiones, u operaciones booleanas, entre otros procedimientos.
En [10] se presenta un nuevo test de inclusión de punto en sólido basado en algoritmos de intersección 3D eficientes y explotando la reutilización de cálculos vinculada a estructuras de descomposición espacial. El algoritmo de inclusión propuesto
tiene las siguientes etapas:
Generación de un segmento utilizando como extremos el punto de estudio y el
centroide del sólido.
Búsqueda del triángulo intersecado por el segmento generado más cercano al
punto de estudio.
Aplicación de un criterio de inclusión para determinar si el punto está dentro o
fuera del sólido.
Para el estudio de la intersección segmento-triángulo se estudiaron tres alternativas: un enfoque clásico utilizando el algoritmo de inclusión de Möler [12] y un
estudio de las normales, el algoritmo de Jiménez antes descrito [9], y una versión
optimizada de este último.
La primera alternativa estudiada se basa en aplicar el test de intersección de
Möller [12] con dos objetivos: determinar qué triángulos intersecan con el rayo
y conocer también cual es el má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 utilización del enfoque de Jiménez basado en coordenadas
baricéntricas descrito anteriormente [9]. En este caso el algoritmo de intersección
para determinar el triángulo más cercano nos devuelve de forma directa la inclusión
del punto y no es necesario hacer ningún tipo de comprobación adicional o aplicar
ningún criterio, lo que supone una mejora sobre enfoques tradicionales.
121
En la última alternativa, siguiendo el trabajo de Ogayar [13], se estudia la optimización de los algoritmos utilizando los datos pre-calculados en la construcción de
las estructuras de descomposición espacial. En concreto, se estudia la optimización
del algoritmo de Jiménez [9] aprovechando los cálculos realizados en un tetra-tree
[4] previamente construido. De forma general, se pueden acelerar los cálculos precalculando los volúmenes de los tetraedros formados por el centroide del sólido y
los triángulos de la malla y almacenando esos datos en la descomposición espacial.
El procedimiento completo de estudio de la inclusión de un punto P en un sólido
recubierto por un tetra-tree tiene dos fases:
1. Determinar la inclusión punto tetra-cono. Este proceso siempre devuelve un nodo
hoja ya que el tetra-tree descompone todo el espacio sin solapamientos. Mediante
la utilización de coordenadas baricéntricas y una descomposición homogénea del
espacio, la complejidad de este proceso puede reducirse hasta tiempo constante.
2. Una vez determinado el tetra-cono, aplicar el test de inclusión punto-sólido tan
sólo en el sub-conjunto de triá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 triángulos clasificados.
Con este enfoque se reducen drásticamente las operaciones a realizar en el test
de Jiménez. A cambio, se necesita más espacio para almacenar la información precalculada.
3.
Descomposiciones espaciales
3.1.
Tri-tree. Aplicació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 información geográ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 inclusión.
En [5], se presenta una estructura de datos, denominada tri-tree, describiendo
además su utilización en el test punto en polı́gono. Esta estructura de datos, basada
en triá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 inclusión mediante el uso de esta estructura es O (log n), siendo n el número
de vértices del polı́gono. Por otro lado, el tiempo de construcción de la estructura es
de O (n log n).
3.1.1.
Tri-tree
En la construcción del tri-tree, se descompone el espacio en regiones de igual tamaño con origen en el centroide del polı́gono. En su primer nivel, el tri-tree divide el
122
espacio en cuatro regiones triangulares de igual tamaño denominadas tri-conos. En
los niveles sucesivos, cada región se subdivide recursivamente en dos sub-regiones,
formando un árbol de regiones. Esta divisió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 triángulo. Centro: Subdivisión de un tri-cono. Dcha:
Aristas clasificadas en un tri-cono.
Para cada regió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 está dentro
del tri-cono (Figura 4). Esta condición se comprueba para cada par arista/tri-cono,
de manera que una arista puede estar clasificada en más de un tri-cono incluso del
mismo nivel. No obstante, en un nivel especı́fico tan só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 número de aristas clasificadas en un tri-cono es menor que un umbral.
El nivel del tri-cono en el árbol es mayor que uno pre-establecido.
El test de inclusió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 triá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 triángulos envolventes
permiten que el test de inclusión pueda rechazar de forma rápida a los puntos que
se encuentran fuera del triángulo envolvente exterior y que pueda aceptar de igual
manera a los puntos que están dentro del triángulo envolvente interior.
En [5] se definen formalmente los conceptos asociados a esta estructura de datos.
3.1.2.
Aplicación al algoritmo punto en polı́gono
En [5] se estudia la adaptación de los métodos de ray-crossings y basado en
triángulos al uso del tri-tree para realizar el test de inclusión. Para ambos métodos
123
Fig. 5 Triángulos envolventes en un tri-cono. Izqda: Triángulo envolvente ideal. Der: Triángulo
envolvente usado (más sencillo de calcular aunque menos eficiente computacionalmente)
se ha demostrado que utilizando tan sólo las aristas clasificadas en un tri-cono se
puede determinar la inclusión de un punto en un polı́gono. Para ello hay que descender en el árbol hasta obtener el nodo hoja en el que está incluido el punto. Después,
si el punto está dentro del triángulo envolvente exterior y fuera del triángulo envolvente interior, se realiza un test punto en polı́gono utilizando tan sólo las aristas
clasificadas en el tri-cono hoja en el que se encuentra en punto.
El método de ray-crossings [3] lanza un rayo infinito desde el punto a clasificar y
calcula el número de intersecciones con las aristas del polı́gono. Si el número de intersecciones es impar, el algoritmo devuelve que el punto esta dentro del polı́gono, y
si no, devuelve que el punto está fuera. Para poder aplicar este método, es necesario
decidir una direcció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
solució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 método general. Otra alternativa consiste en aplicar el método de ray-crossings utilizando un
rayo dirigido a través de un punto incluido en el tri-cono cuyo estado de inclusión
sea conocido. Este rayo se lanza en el sentido contrario, de manera que pasa por la
posició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 posición del origen del tri-tree. Básicamente, el rendimiento depende del número
de intersecciones calculadas.
El método basado en triángulos [2] se basa en el calculo de la inclusión del punto
P en un conjunto de triángulos formados por un punto común y arbitrario O y cada
una de las aristas del polı́gono, y en la obtención del número de triángulos en los que
el punto está incluido. El algoritmo contabiliza como +1 multiplicado por el signo
del triángulo para cada uno de esos triángulos, y considera algunos casos especiales
como la inclusión en una arista compartida por dos triángulos del recubrimiento,
computándolo como + 12 por el signo de cada uno de esos triángulos. Por último,
124
el estado de inclusión se obtiene mediante la suma de esos valores, obteniendo la
inclusión en el polı́gono cuando ese valor es mayor que cero. Al igual que en el
caso del método de ray-crossings, el método basado en triángulos puede aplicarse
a un tri-cono. Para ello, se deben contar el numero de triángulos del recubrimiento
en los cuales se incluye el punto. No obstante, tan sólo deben tenerse en cuenta los
triángulos del recubrimiento que intersecan con el tri-cono.
3.2.
Descomposiciones espaciales jerárquicas utilizando
Geometry Shaders
El principal inconveniente de implementar algoritmos geométricos en GPU es
que hay que adaptar las estructuras de datos y la programación a un modelo de programación paralelizado y enfocado a la visualización, con las restricciones que esto
conlleva. Por otra parte, multitud de algoritmos geométricos están basados en una
descomposición espacial eficiente de los modelos. Estas descomposiciones permiten trabajar sólo con una parte de los datos, reduciendo ası́ su complejidad.
En [8] se proponen una serie de directrices que permiten la construcción y posterior consulta de dichas estructuras de datos utilizando los shaders programables,
aplicados a mallas de triángulos, de modo que aumente el rendimiento de las aplicaciones. Esto posibilita la utilización de la GPU para problemas que hagan uso
descomposiciones espaciales jerá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 información facilite posteriores consultas. Para ello, debido a las limitaciones que impone la
arquitectura y el modelo de programación de shaders en GPU, se propone una implementación radicalmente distinta al método tradicional. En concreto, se propone
una solución que resuelve el problema de construcción de jerarquı́as y que optimiza
el acceso a la información, permitiendo el uso de mallas de gran tamaño.
3.2.1.
Codificación de la información
La incorporación del procesador de geometrı́a al pipeline gráfico permite obtener
información de los triángulos de la malla en cada unidad de ejecución del mismo.
Al enviar la geometrı́a del objeto, se propone activar la unidad de ejecución en el
geometry shader por cada triángulo que entre en el pipeline gráfico. Cada unidad de
ejecución clasifica el triángulo en un determinado nivel de forma independiente a
los demás. En [8] se propone no almacenar la información de vértices y triángulos,
sino asociar un ı́ndice a cada triángulo de la malla. Suponiendo una malla formada
por n triángulos, se considera utilizar una textura de n elementos para cada nivel de
la jerarquı́a. Cada posición de la textura de un nivel determinado contiene el código
de los nodos en los que se encuentra almacenado el triángulo correspondiente en ese
nivel.
125
Como un triángulo puede estar clasificado en varios nodos de un mismo nivel, el
número máximo de nodos en los que se clasifica un triángulo no puede conocerse
a priori, siendo posible que un triángulo este clasificado en un gran número de nodos en los niveles más profundos del árbol. Para resolver este problema, se propone
establecer un número máximo de nodos del mismo nivel en los que se encuentra clasificado un triángulo. De este modo, si se supera este umbral, se detiene el descenso
por el árbol de ese triángulo.
En este caso, es posible enviar a la GPU la información sobre los volúmenes
asociados a los nodos codificados en texturas, evitando tener que calcularlos a partir
del volumen inicial. En este trabajo se propone codificar dicha información en una
textura 2D a la que denomina textura de volúmenes.
3.2.2.
Construcción en GPU
Dada una malla de n triángulos y un número de niveles l para la jerarquı́a, se
propone enviar la geometrı́a de la malla l veces para su visualización, una por nivel,
para que las unidades del geometry shader se activen por cada triángulo de la malla.
Además de la información de la geometrı́a, en cada triángulo debe codificarse la
información del número de triángulo, para que el geometry shader pueda escribir
en su posición de la textura de nivel correspondiente. De esta manera, el geometry
shader emite un vértice cuya posición es el código del triángulo de entrada y cuyo
color la codificación de los número de nodos de ese nivel en los que se encuentra el
triángulo. Este proceso de construcción puede verse en la Figura 6.
Fig. 6 Construcción de una descomposición espacial usando geometry shaders y texturas de nodos)
Por tanto, para cada pasada de construcción tendremos los resultados del nivel
anterior y la información de los volúmenes de la estructura jerá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.
Utilización de la estructura
Una vez construida la jerarquı́a asociada a una malla de triá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 ejecución del geometry shader, ante un triángulo
de entrada, habrı́a que consultar en todas las texturas de nodos de todos los niveles si se encuentra el código del nodo. Este código no serı́a constante para todas
las unidades de ejecución.
Dada una posición en el espacio, obtener el nodo hoja que la contiene. Se puede
utilizar una función que dada la posición y el nivel, obtenga el código del nodo
asociado.
Obtención de los nodos hijos y padre. Dado un nodo, la obtención de los nodos
hijos o padre puede realizarse mediante una función que obtenga el código del
nodo.
Actualización de la jerarquı́a tras una deformación de la malla. Tras localizar
los triángulos modificados por la deformación, habrı́a que volver a reclasificar
dichos triángulos, no siendo necesario reconstruir el resto.
3.2.4.
Implementación de tetra-trees
Un tetra-tree [7] es una descomposición del espacio jerá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 tamañ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 homogéneamente en cuatro nuevos tetra-conos.
El tetra-tree se subdivide hasta que cumple alguna de las condiciones siguientes:
Se alcanza el máximo nivel de subdivisiones preestablecido.
El tetra-cono a subdividir tiene menos triángulos que un umbral.
Todos los tetra-conos que forman la descomposición espacial comparten un origen común. Normalmente, se hace coincidir este origen con el centroide del objeto.
Cuando se construye un tetra-tree, se clasifican los triángulos que forman el objeto
en cada uno de sus tetra-conos iniciales. Los triángulos de cada tetra-cono continúan
clasificándose en sus tetra-conos hijos hasta que se alcanza alguna de las condiciones de parada antes enunciadas.
En la construcción de un tetra-tree, se propone utilizar una textura de volumen
que contendrá los puntos que definen cada tetra-cono para todos los niveles contemplados. El centroide del objeto, común a todos los tetra-conos, debe ser una variable
de entrada al procesador. La textura de nodos debe construirse según la definición
antes comentada. En cada posició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 triángulo no puede ser clasificado en más de cuatro
nodos por nivel, sirviendo esta condición como criterio de parada.
3.3.
127
Descomposiciones jerárquicas exactas
La utilización de descomposiciones espaciales jerárquicas en escenas 3D con el
fin de reducir la complejidad de los objetos es bastante común. No obstante, el principal problema de estos enfoques está relacionado con la actualización de las estructuras cuando se modifica la geometrı́a de los objetos, ya que cualquier deformación
provoca la recomposición completa de la estructura espacial jerárquica.
En [11] se aplica un procedimiento de remallado con el fin de ajustar la malla
original a la descomposición espacial. Este procedimiento de remallado no afecta a
la malla completa, sino tan sólo a los triángulos que no están completamente contenidos en un solo nodo de la estructura. Para ilustrar el método se hace uso de un
tetra-tree [7] como descomposición espacial jerárquica.
Dado que los tetra-conos pueden definirse como tetraedros con su base en el
infinito, el problema de la intersección de los tetra-conos con los triángulos compartidos puede reducirse a una triple intersección triángulo-triángulo en 3D (Figura 7).
La intersección triángulo-triángulo puede ser fácilmente reducida a intersecciones
de tipo segmento-triángulo. Tal y como se ha visto en secciones anteriores, el algoritmo clásico utilizado para la intersección segmento-triángulo es el propuesto por
Möller [12]. El principal problema de este enfoque clá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 intersección segmento-triángulo propuesto por Jiménez [9], el cual e
comporta de forma robusta en los casos lı́mite gracias a su enfoque basado en coordenadas baricéntricas. En este sentido, el uso del tetra-tree es una ventaja dado que
permite reutilizar los cálculos relacionados con las coordenadas baricéntricas de los
nodos.
Fig. 7 La intersección triángulo-tetracono puede expresarse fácilmente como una intersección
usando el plano que contiene el triángulo
128
Tras la finalización de los cálculos de intersección, se propone estudiar los casos
de intersección triángulo-triángulo con el objetivo de aplicar un patrón de división.
Se proponen 11 patrones de división (Figura 8), los cuales han sido elegidos de manera que resulten lo más sencillos y eficientes posibles, intentando reducir el número
de triángulos generados. Estos patrones pueden aplicarse a otras descomposiciones
jerárquicas que esté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 eliminación además del remallado.
4.
Conclusiones
En este trabajo se han desarrollado diversos algoritmos geométricos básicos que
posibilitan su aplicación en entornos urbanos con un alto grado de eficiencia y robustez. Se han desarrollado tests de inclusión de puntos en polı́gonos, de puntos en
sólidos y de intersección de segmentos y triá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 jerárquicas exactas basadas en las anteriores. Finalmente estas descomposiciones se han implementado en GPU para obtener algoritmos que funcionan en tiempo real. Dicha
implementación permite extenderse a otros tipos de descomposiciones espaciales
jerárquicas.
Agradecimientos Este trabajo ha sido parcialmente subvencionado por el Ministerio de Economı́a y Competitividad Español y la Unión Europea a través de fondos FEDER por medio del
proyecto TIN2011-25259, y por la Universidad de Jaén a través del proyecto de investigación
UJA2010/13/08, patrocinado por Caja Rural de Jaén.
Referencias
1. Erickson, C.: Real-Time Collision Detection. Morgan Kaufmann Publishers, San Francisco
(2005)
2. Feito, F.R., Torres, J.C., Ureñ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. Jiménez, J.J.: Detección de colisiones mediante recubrimientos simpliciales. Ph.D. thesis,
Universidad de Granada (2006)
5. Jimé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. Jimé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–
Fig. 8 Casos de intersección y patrones de descomposición en triángulos)
129
130
7.
8.
9.
10.
11.
12.
13.
2274 (2009). DOI 10.1111/j.1467-8659.2009.01481.x. URL http://dx.doi.org/10.1111/j.14678659.2009.01481.x
Jiménez, J.J., Feito, F.R., Segura, R.J., Ogá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
Jiménez, J.J., Martı́nez, A., Feito, F.R.: Diseño de descomposiciones espaciales jerárquicas para mallas de triá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
Jimé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., Jiménez, J.J., Feito, F.R.: Inclusión en sólidos optimizada. In: CEIG 2010.
Spanish conference on Computer Graphics, pp. 297–300 (2010)
Martı́nez, A., Jimé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)
Mö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
Visualización realista
Texturizació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 texturización de un entorno urbano situado sobre una superficie inclinada. En concreto, se detalla el procedimiento
propuesto para texturizar de forma automática manzanas de edificios. Para facilitar
el proceso, las manzanas se consideran divididas en dos partes: superior e inferior,
implementándose un algoritmo genético para la selección de texturas en cada una
de ellas. Estos métodos permiten obtener un conjunto adecuado de imágenes a partir de una base de datos de texturas reales, teniendo en cuenta aspectos relativos a
la posición real de los edificios y su posible localización en calles con una elevada
pendiente. En vista de los resultados obtenidos, se puede concluir que los métodos
propuestos obtienen escenas correctas similares a las reales que, además, ocupan un
espacio reducido.
1.
Introducción
La texturización de entornos urbanos virtuales sobre localizaciones reales posee
unas caracterı́sticas muy diferentes a la creación de ciudades totalmente ficticias.
Ası́, la superficie y orografı́a del terreno son pará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 zócalo y el portal del
edificio aparecen hundidos debajo del asfalto de la calle.
El tipo de navegación permitida en el entorno virtual es otro aspecto que afecta
al proceso de texturización. Para recorridos aéreos, no es necesario alcanzar un alto
Universidad de Jaén, Departamento de Informática e-mail: [email protected]
Francisco R. Feito Higueruela
133
134
Marı́a Dolores Robles Ortega, Lidia Ortega Alvarado y Francisco R. Feito Higueruela
Fig. 1 Situación no realista
por la incorrecta texturización
de la fachada
nivel de detalle en la texturización de los edificios o del mobiliario urbano [1], pudiendo utilizarse técnicas de renderizado basadas en impostores como, por ejemplo,
la propuesta en [8]. En cambio, en una navegación peatonal se deben utilizar mecanismos que enriquezcan el modelo mediante texturas reales o métodos procedurales
y gramáticas [3, 4]. En este trabajo se propone un método del primer tipo basado en
la utilización de imá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 sólo se dispone de texturas procedentes de fotografı́as
de las zonas más conocidas. Esto serı́a suficiente si la navegación se realizase únicamente por las áreas más emblemáticas de la ciudad, y la interacció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, será necesario realizar un proceso de texturización para la ciudad completa. Por
tanto, se debe diseñar un método que, a partir de un conjunto de imágenes, realice
una asignación automá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 imágenes disponibles deben ser previamente clasificadas
dependiendo de la época de construcción del edificio que representan y del barrio
donde se ubican. De esta forma, la selección de las texturas para cada manzana no
será aleatoria, sino que se realizará teniendo en cuenta los criterios anteriormente
especificados. Gracias a esta consideración, al igual que ocurre en la realidad, los
elementos de un mismo barrio tendrán una apariencia similar y no se producirán situaciones irreales como la aparició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 generarán utilizando los datos reales de geometrı́a y
ubicación. El método propuesto permite además la reutilización de las texturas en
diferentes modelos.
A continuación se explican los principales trabajos relacionados con la texturizació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 automático. Se explica también el mecanismo de selección de
texturas implementado, basado en la utilización de algoritmos genéticos. Finalmente, se exponen los resultados obtenidos y los principales trabajos futuros.
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 geométricos que lo componen. Seguidamente se describen las principales técnicas usadas para este propósito.
En la literatura se pueden encontrar algunos trabajos que utilizan métodos procedurales en el proceso de texturizació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 técnica
procedural. En [6], en cambio, se propone la división de las imá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 ú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 técnicas procedurales no se usan de forma individual, sino
conjuntamente con otro tipo de métodos. Ası́, algunos autores proponen la combinación del modelado procedural de gramáticas con el análisis de imágenes para
generar una subdivisión jerárquica de fachadas [7]. También se han desarrollado
herramientas interactivas que combinan las té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 aplicación propuesta en [9]. Ası́, primero el sistema crea automáticamente un modelo de un edificio
utilizando gramáticas y después el usuario interacciona con el mismo para modificarlo.
Además de las gramáticas, normalmente se utiliza un conjunto de fotografı́as como datos de entrada para generar un modelo 3D urbano. É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 método de segmentación la
imagen inicial se divide a nivel de pı́xel en áreas significativas semánticamente, que
posteriormente se etiquetan como un objeto especı́fico (edificio, cielo, suelo, vegetación o coche). A continuación se introduce un esquema de partición para separar
los edificios en manzanas independientes. Finalmente, para cada manzana, se realiza una composición ortográfica inversa basada en parches y un método de análisis
de la estructura para modelado de fachadas que reduce eficientemente el ruido y los
posibles datos perdidos en la reconstrucción 3D.
El sistema descrito en [11] también usa fotografı́as. Esta herramienta interactiva
calcula automáticamente la estructura 3D usando los resultados de la interacción
2D y la información recuperada mediante el análisis de los datos de entrada. En
este caso, los mapas de texturas se generan a través de la combinación de múltiples
fotografı́as de entrada usando las técnicas de graph cut optimization [12] y Poisson
blending [13]. En [14] se describe otro método que genera un modelo 3D texturizado usando los resultados de un escáner 3D de un edificio y un conjunto de imágenes
136
previamente capturadas. Esta té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
imágenes aé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 imá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 número total de edificios.
En el método que se describe en este capı́tulo se usan fotografı́as reales de la
ciudad de Jaén tomadas con una cámara Nikon D90, que son procesadas y parametrizadas según se explica en la Sección 4.
Para la texturización se utilizan algoritmos genéticos porque permiten considerar requerimientos adicionales para obtener unos resultados más realistas como, por
ejemplo, la pendiente de las calles, o la correcta combinación de texturas para plantas inferiores y superiores, entre otros. Al contrario que otras té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 ejecución, el usuario final puede elegir el modelo que mejor se ajuste
a sus necesidades. Esto es especialmente útil para generación de ciudades virtuales
en aplicaciones como cine o juegos.
3.
Colocación automática de las texturas en una manzana
En esta sección se describe un método automá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 están situadas. Inicialmente se detallan los requerimientos generales
de todo el proceso para obtener unos resultados realistas. A continuación se explica
la fase previa de procesamiento realizada a las fotografı́as para conseguir las texturas
y sus pará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 técnica para la sı́ntesis de
imá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.
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 texturización.
En un procedimiento de mapeado de texturas clásico, dado un polı́gono compuesto por un conjunto de vértices y una textura, se realiza una asignación de las
coordenadas de textura (u, v) (u, v ∈ [0, 1]) a cada vértice del polı́gono mediante un
conjunto de transformaciones má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 só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, después, se realiza una traslación para
colocar la imagen en la posición adecuada. La rotación no es necesaria puesto que
durante el proceso de tratamiento previo de las fotografı́as se realiza una corrección
de perspectiva.
3.2.
Requerimientos generales
Debido a que existen caracterı́sticas muy diferentes en la adjudicació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 también en dos categorı́as: superior e inferior.
Para obtener unos resultados correctos tras el proceso de texturización, es necesario considerar una serie de aspectos que permitirán incrementar el realismo de los
modelos generados:
138
Fig. 3 División de las manzanas en dos partes: superior e
inferior.
Fig. 4 Situación no realista
al texturizar esquinas de
edificios.
1. El sistema deberá determinar las texturas en funció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 tamaño real que representa cada imagen
deberá tenerse en cuenta para evitar asignaciones irreales. En el método que se
está describiendo en este capı́tulo no se permite una extensió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 continuación se explica el tratamiento que se realiza a las fotografı́as iniciales
para obtener un conjunto de texturas que se almacenarán en la base de datos y que
139
Fig. 5 Todas las texturas de la parte inferior de un edificio deben estar colocadas a la misma altura.
posteriormente serán utilizadas en el proceso de mapeado que se describe en la
Sección 5.
4.
Procesamiento de las imágenes
La utilización de una fotografı́a real como textura no es un proceso automático,
sino que es necesario realizar un tratamiento previo de la imagen para corregir posibles errores derivados de la propia captura. La primera modificació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 sitúan sin ninguna inclinación y,
por tanto, las texturas deben ser también completamente verticales. Seguidamente
se elimina cualquier elemento urbano situado sobre la fachada como, por ejemplo,
árboles, farolas o coches, para evitar incoherencias en el modelo final. Finalmente,
se obtienen texturas que contengan una única fachada. Para ello, las fotografı́as se
dividen en fragmentos horizontales o verticales según corresponda. Cada una de estas nuevas texturas será clasificada segú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 informació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 texturización para obtener resultados correctos es la pendiente de las calles. Ası́, aunque en
140
(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 colocació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 navegación
peatonal. Este proceso se realiza de forma previa a la asignación de las texturas y
sus resultados se almacenan en la base de datos, de manera que las imágenes puedan
ser reutilizadas en un amplio conjunto de manzanas de una o diferentes ciudades.
El cálculo de la má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 Jaé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 utilizará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 zócalo,
las ventanas u otros elementos de la fachada.
Una vez obtenidos los puntos de control, la máxima pendiente permitida de la
calle donde se puede colocar la textura viene determinada por los á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 máxima pendiente, puesto que la parte
inferior no tiene una textura asociada. Para evitar esta situació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 tamaño afecta a la pendiente, en la base de datos se almacena el valor
máximo y mı́nimo para α y β .
Otro aspecto fundamental que se debe considerar en el proceso de colocació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 qué vértices
141
Fig. 7 Ejemplo de intervalos
de textura indivisibles
de un edificio pueden ser considerados como esquina y qué intervalos de cada textura no pueden ser divididos. Ambos elementos pueden definirse en un espacio 2D,
puesto que la tercera dimensión es independiente de su valor. Ası́, por ejemplo, en
el caso de los intervalos indivisibles, éstos están determinados por puntos 2D que
generan una divisió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 posición es independiente de la pendiente de la calle en la que estén
situadas. No obstante, al igual que en é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 imágenes se determinarán
también el conjunto de intervalos indivisibles definidos en el apartado anterior.
5.
Colocación automática de las texturas
Según se ha descrito anteriormente, para realizar un mapeado correcto es necesario determinar los factores de rotación, escalado y traslación. Sin embargo, en el
caso de la texturización de las manzanas, la rotación se realiza previamente durante el proceso de corrección de las texturas. Por tanto, únicamente será necesario
determinar los factores de escalado y traslación [23]. Seguidamente se explica el
proceso de mapeado de las texturas inferiores y superiores para evitar situaciones
no realistas.
142
Fig. 8 Cálculo de la proyección del segmento del tramo con puntos de cruce C1 y C2 en la pared
del edificio.
5.1.
Colocació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 cálculo es
inmediato puesto que se conocen tanto el tamaño real de la imagen que representa
las texturas como el de la pared.
La obtención de los valores de traslación MT es algo más complejo. Inicialmente
se considera como precondición que la textura esté situada en el mismo plano XZ
que la pared. Como consecuencia de esto, sólo será necesaria una traslació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 traslació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 texturización
correcta:
yF = ydG xF
c) Se obtiene la traslación vertical V
V = yB − yF − yE
(a) Espacio del objeto
143
(b) Espacio de la textura
Fig. 9 Cá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 posició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 posició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 posición correcta, establecida
por el punto F, cuya coordenada y (yF ) se obtiene fácilmente usando semejanza de
triángulos (paso 4b). Para calcular finalmente la traslación V que situará la puerta
correctamente se utiliza la fórmula V = yB − yF − yE . La posición del punto E debe
ser incluida porque la recta r intersecta con π a la altura de yE .
5.2.
Colocació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 dimensión de la pared de la manzana y del tamaño real de la
imagen que representa la textura. Sin embargo, en este caso no es necesario realizar
una traslación de la imagen, puesto que la posició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 genético para la texturización de las manzanas
2.5D situadas en una superficie no plana
Una vez descrito el procedimiento de colocación de las texturas, a continuación
se detallan los algoritmos de selección utilizados para obtener un conjunto adecua-
144
do de imágenes para texturizar tanto la parte superior como la parte inferior de una
manzana. En ambos casos se explican los aspectos básicos de los mé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 ejecución del algoritmo. Seguidamente se describe el
procedimiento completo.
Definición del problema
La texturización de la parte inferior de una manzana 2.5D situada en una superficie no plana puede definirse formalmente como la obtención de un conjunto de
texturas no repetidas cuya suma total se ajuste a la longitud de las aristas externas
del edificio (condición 1) y que contenga una única textura de tipo portal (condición 2). Además, tras el proceso de mapeado, ninguna ventana u otro elemento
de la fachada debe aparecer situado en una esquina (condición 3).
Selección inicial de las texturas
La selección de las texturas se realiza mediante una consulta a la base de datos
que considera la zona en la que está situado el edificio, los valores de altura
y anchura ası́ como la pendiente del tramo de calle. El conjunto de imágenes
seleccionadas será utilizado para generar la población del algoritmo genético.
Representación. Correspondencia entre el fenotipo y el genotipo
Se ha utilizado una codificación discreta y, en particular, binaria. Ası́, el tamaño
de los cromosomas es fijo y viene determinado por el número de texturas potenciales. Cada gen indica si la textura aparece (valor 1) o no (valor 0) en la solución
final.
Inicialización de la población
Se realiza una asignación aleatoria pero considerando que cada cromosoma incluya una única textura de tipo portal. De esta forma, se reduce el número de
cromosomas posibles de la población y se facilita el proceso de encontrar una
solución.
Selección
Los padres se eligen mediante la estrategia de selección por torneo de tamaño 3.
Operador de cruce
El operador de cruce utilizado se basa en la divisió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 mutación
Para incrementar el espacio de búsqueda y favorecer la variabilidad de la población se han establecido dos operadores de mutación. Ambos se basan en la
145
inversión de los genes, pero se diferencian en la forma de selección: aleatoria o
determinista. En el primer caso, se genera un número aleatorio que modificará 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.
Función de evaluación
Esta función evalúa el grado de cumplimiento de las condiciones establecidas
en la definición del problema. Además de estos requerimientos, se consideran
también aspectos relativos a la eficiencia de la solución como, por ejemplo, la
preferencia por soluciones con un menor número de texturas.
Estrategia de reemplazamiento
Se ha utilizado una estrategia de reemplazamiento generacional que crea una
nueva población en cada iteración. Se utiliza asimismo el elitismo para mantener
al mejor cromosoma de cada generación. De esta forma se evita eliminar un buen
individuo que podrı́a ser elegido como solución final.
Condición de parada
Se han establecido dos posibles condiciones de parada: encontrar una solución
que obtenga el valor máximo de la función fitness o que se realicen un número
predeterminado de ejecuciones. En las pruebas realizadas el algoritmo siempre
ha finalizado debido a la primera condición.
6.2.
Parte superior
Tras describir el algoritmo genético para la parte inferior, seguidamente se detalla
el procedimiento propuesto para la texturización de la parte superior. En este caso
se utilizan manzanas en lugar de edificios.
Definición del problema
El problema de asignación de texturas de tipo superior puede definirse como la
búsqueda de un subconjunto de imá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 solución.
Selección inicial de las texturas
La selección de las texturas se realiza mediante una consulta a la base de datos
en la que obtienen un conjunto de imágenes que se corresponden con la zona de
la manzana y que podrı́an ajustarse a su anchura. Además, el número de pisos de
estas texturas deberá ser igual al número de plantas de la manzana.
Representación. Correspondencia entre el fenotipo y el genotipo
Se utiliza una representación entera, siendo el tamaño del cromosoma un valor
fijo determinado por el número de edificios de la manzana. Ası́, cada gen indica
la textura para el edificio de la manzana.
Inicialización de la población
146
La población se inicializa de forma aleatoria, pero generando siempre individuos
válidos. En concreto, el método implementado genera para cada gen un valor
aleatorio entre 0 y el número de texturas potenciales para el edificio.
Selección
Al igual que para el algoritmo de la parte inferior, se utiliza el método de selección por torneo de tamaño tres.
Operador de cruce
Se ha utilizado un operador de cruce uniforme (Uniform Crossover) que determina a qué hijo se asigna el valor de cada padre según un valor aleatorio generado
en el intervalo [0,1].
Operador de mutación
En este caso se han establecido dos operadores de mutación. El primero de ellos
modifica el valor de un gen seleccionado de forma aleatoria por otra textura válida. El segundo, en cambio, se utiliza para reducir el número de cromosomas no
válidos y consiste en cambiar la primera textura repetida por otra imagen válida.
Función de evaluación
La función de evaluación diseñada comprueba el grado de cumplimiento de las
dos condiciones establecidas en la definición del problema. En concreto, la primera condición no es necesario comprobarla puesto que el mecanismo de selección obtiene siempre un conjunto de texturas que la cumplen. Para valorar el
segundo requerimiento, se calcula un valor proporcional al número de texturas
repetidas. De esta forma, se favorecen las soluciones en las que no haya imágenes
duplicadas.
Estrategia de reemplazamiento
Se utiliza una estrategia de reemplazamiento generacional que crea una nueva
población en cada iteración, pero utilizando elitismo para mantener el mejor cromosoma de cada evaluación.
Condición de parada
Al igual que para el algoritmo de la parte inferior, se han establecido dos posibles razones como condición de parada: encontrar una solución que obtenga
el valor máximo de la función fitness o realizar un número predeterminado de
ejecuciones.
7.
Resultados
En esta sección se describen los resultados obtenidos tras aplicar los algoritmos
genéticos descritos anteriormente a un conjunto de manzanas de la ciudad de Jaén.
El problema de texturización planteado podrı́a haberse resuelto también utilizando algoritmos deterministas como, por ejemplo, métodos Greedy [21]. No obstante,
estos métodos tienen un orden de ejecución elevado y, además, obtienen siempre
la misma solución para el mismo conjunto de datos de entrada. En el caso de los
genéticos, en cambio, en cada ejecución se obtiene una combinación diferente de
147
Fig. 10 Capturas de pantalla de la escena obtenida.
texturas, lo que resulta especialmente ú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 están situadas correctamente incluso en las
calles con una excesiva pendiente. En todos los casos las puertas de entrada están
colocadas justo a nivel del suelo, lo que permite la entrada de forma natural a los edificios. Además, la superficie de la calle no intersecta con los zócalos ni con ningún
otro elemento de la fachada. La texturización de las esquinas también se realiza de
forma correcta.
148
8.
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 genéticos que permiten texturizar de forma automática los modelos
2.5D de manzanas de edificios situadas en una superficie no plana. Además, se ha
creado también un procedimiento de colocación automática de las texturas en el
modelo final que considera aspectos fundamentales para obtener una escena realista
como, por ejemplo, la posición correcta de un zócalo y la colocación de la puerta de
entrada de un edificio para permitir una entrada natural.
Entre los trabajos futuros puede destacarse la automatización del tratamiento
previo de las texturas mediante la utilización de métodos de tratamiento digital de
imágenes.
Agradecimientos Este trabajo ha sido parcialmente subvencionado por el Ministerio de Ciencia
e Innovación y la Unión Europea a través de los fondos FEDER bajo el proyecto de investigación
TIN2011-25259 y por la Universidad de Jaén bajo el proyecto UJA2010/13/08 subvencionado por
Caja Rural de Jaé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. Mü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. Mü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)
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. Pé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, 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. & Sacristán, V. (Eds.) XIV Spanish
Meeting on Computational Geometry A geometrical approach for automatic building texture
mapping. Centre de Reserca Matemàtica, 87-90 (2011)
Visualización de medios participativos en
entornos urbanos
J. Roberto Jiménez Pérez, Francisco Martı́nez del Rı́o y Ángel Aguilera Garcı́a
Resumen Cada vez es má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 visualización. En este trabajo proponemos una solución para visualizar escenas de manera realista incluyendo
iluminació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 solución está basada en Monte
Carlo y tanto la iluminación como el medio y el modelo permanecen invariables
durante la interacción.
1.
Introducción
Investigaciones recientes se centran en la problemática del modelado de ciudades
que permitan una experiencia inmersiva al usuario, dándole la posibilidad de realizar recorridos, visitar de lugares de interés, etc. Un aspecto importante en la mejora
de dicha experiencia es el realismo con que se visualiza la ciudad. Incluir una visualización realista supone añadir iluminación, cálculo de sombras, etc. En este artı́culo
estudiamos la problemática que suscita la inclusión de medios participativos en el
modelo de la ciudad, tales como niebla, humo, polución, etc.
En general, la simulación realista de medios participativos es compleja debido
a la dimensión adicional que se requiere para representarlos [5]. Normalmente, los
Universidad de Jaén e-mail: [email protected]
Angel Aguilera Garcı́a
151
152
edificios, calles y plazas se representan mediante conjuntos de polı́gonos y triángulos. Además, la dirección de propagación de la luz dentro del medio cambia continuamente debido al fenómeno de dispersión. En el caso de la visualización de
ciudades existe una dificultad adicional, y es el gran tamaño de los modelos, no
tanto por el número de polı́gonos que requiere sino por sus dimensiones. Dadas las
peculiaridades de la visualización de medios participativos, ésta amplitud supone un
reto aún no resuelto.
En este artı́culo proponemos un método para la visualización realista de ciudades
incluyendo medios participativos que permita interacción en tiempo real por parte
del usuario.
Este artı́culo se estructura del siguiente modo: la Sección 2 expone brevemente
algunos resultados previos, la Sección 3 explica el método propuesto, la Sección 4
detalla los resultados obtenidos, y, por último, la Sección 5 comenta las conclusiones
y el trabajo futuro.
2.
Trabajos previos
El método zonal [18] es una extensión a los medios participativos del algoritmo
clásico de radiosidad. El color final de un pixel se obtiene al añadir al color del
triángulo intersecado el de acumular cada uno de los voxeles a lo largo de la lı́nea
en la dirección de vista. Languenou et al. [12] propuso una solución eficiente para la
visualización de medios participativos anisótropos y no homogéneos, basada en la
discretización del espacio de direcciones. De este modo, para cada voxel la radiancia
se precalcula y se almacena para cada dirección de salida.
El principal problema de estos métodos es que requieren elevados recursos de almacenamiento. Otras soluciones para evitar estos problemas son las siguientes. Bhate et al. [2] usar harmónicos esféricos para aproximar la función de fase anisótropa. La fase de visualización es similar a propuestas anteriormente mencionadas.
Stam [23] se basa en el uso de la ecuación de difusión, que simplifica la dispersión
múltiple asumiendo que puede ser representada mediante los dos primeros términos
de la serie de Taylor.
Por otro lado, otras propuestas se han centrado en disminuir el coste del número
de factores de forma que es necesario calcular [1, 22, 20]. Estas propuestas dividen
la escena en un conjunto de elementos finitos organizados jerárquicamente. Esta organización permite reducir el cálculo de factores de forma fomentando el uso del nivel adecuado dentro de la jerarquı́a. Estas técnicas se basan en medios participativos
isótropos. Pérez et al. [15] elimina esta restricción y visualiza medios anisótropos
mediante el uso de una té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 té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 número de muestras
para mitigarlo. Jensen et al. [8] presentaron una técnica basada en el uso de técnicas
Visualización de medios participativos en entornos urbanos
153
de estimación de la densidad para eliminar el problema del ruido sin necesidad de
incrementar sustancialmente el número de partı́culas (muestras). Jiménez et al. [10]
aproximan las técnicas de estimación de la densidad para adecuarlas a los procesadores gráficos. De esta forma, consiguen resultados interactivos para medios participativos genéricos. Szirmay-Kalos et al. [24] extienden el concepto de red de lı́neas
globales de haces de iluminación a medios participativos animados [4, 19, 16].
Harris y Lastra [7] presentaron un método para visualizar nubes en tiempo real,
basados en la propiedad de las nubes cuya dispersión es principalmente hacia adelante. De este modo, consiguieron simular dispersión múltiple con únicamente dos
direcciones. Este trabajo se basa en la propuesta de Dobashi et al. [6] que proponı́a
el mismo método pero únicamente para simular dispersión simple. Biri et al. [3]
propusieron un algoritmo de tiempo real para la visualización de niebla representada mediante un medio no homogéneo. El conjunto de coeficientes de extinción se
representan mediante funciones eliminando la necesidad de almacenamiento.
Sloan et al. [21] propusieron un método de tiempo real para la visualización
de medios isótropos y teniendo en cuenta dispersión múltiple. Este método se denomina PRT (precomputed radiance transfer) y se basa en las propiedades de los
harmónicos esféricos para hacer independiente los cambios en la iluminación con
respecto al cálculo de la distribución de la energı́a en el medio participativo. Esta
propuesta está limitada a escenas estáticas e iluminación procedente del infinito. Por
otro lado, Zhou et al. [25] consigue tiempo real de humo en animación basándose
en la exponenciación de los harmónicos esféricos [17]. Esta exponenciación se basa
en el proceso de difusión propuesto por Stam [23].
Para una visión más en profundidad de las técnicas de visualización de medios
participativos, léase [5].
3.
Metodologı́a
En principio, pudiéramos pensar que cualquier método clásico de visualización
de medios participativos es válido para su aplicación en entornos urbanos. La propuesta que presentamos en este trabajo se basa en los métodos de Monte Carlo para
evitar un uso elevado de memoria, concretamente nos basamos en la solución de
Jiménez et al. [10]. Hemos descartado las soluciones basadas en harmónicos esféricos debido a que son menos adecuadas a condiciones en las que la iluminación
está cercana a la escena.
A continuación detallamos el algoritmo utilizado, ası́ como su aplicación a entornos urbanos. La solución propuesta se divide en tres fases: trazado de rayos,
reconstrucción y visualización.
Esta fase se basa en el algoritmo clá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 interacción de la partı́cula con algún elemento
de la escena (triángulos o medio participativo) se almacena la misma, y la partı́cula
continua su camino con una nueva dirección y con la disminución de energı́a acorde
154
con las propiedades ópticas del elemento. Esta fase es independiente de la posición
del observador.
La siguiente fase, la fase de reconstrucción, obtiene como resultado una textura
por cada elemento: texturas 2D para los triángulos y 3D para los medios participativos. Cada texel de dichas texturas representa la energı́a saliente desde la región
correspondiente a dicho texel. Esta fase tampoco depende del punto de vista para
medios isótropos y superficies difusas. Esta fase se divide en dos partes: una primera para acumular la energı́a que se refleja en la dirección de vista en un histograma
y otra para aplicarle un filtro para mitigar el caracterı́stico ruido de las técnicas de
Monte Carlo y ası́ disminuir el número de partı́culas que es necesario para obtener
un resultado satisfactorio.
Finalmente, la fase de visualización divide el volumen que representa al medio
participativo en un conjunto de lonchas, las cuales se orientan perpendiculares a la
dirección de vista y se proyectan en orden de atrás hacia adelante para ir acumulando la energı́a de cada uno de los voxeles. Esta fase depende de la posición del
observador y debe recalcularse cada vez que se mueve.
La técnica descrita hace referencia a un ú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 interacción del usuario con la escena. Para ello, se seleccionan los medios participativos
que se van a calcular y se sitúan en puntos caracterı́sticos del entorno. A continuació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 gráfica Nvidia Quadro FX 570M. La
implementación se ha basado en la plataforma SIR [13] y la escena se ha modelado
utilizando el está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 isótropo y homogé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 reconstrucción, 0.49 segundos se han empleado en la construcción del
histograma y 0.09 segundos en el filtrado gaussiano. La fase final de visualización
requiere un tiempo prácticamente despreciable lo que permite una interacción en
tiempo real por parte del usuario.
La duplicación del medio participativo apenas tiene incidencia en en el tiempo
requerido por la fase de visualización mientras no se requiere de almacenamiento
externo. El resto de fases si se ven afectadas por las dimensiones del volumen al
necesitar mayor número de fotones para su correcta visualización.
155
Fig. 1 Imagen de una calle de una ciudad iluminada y con niebla
5.
Hemos presentado una propuesta para la visualización realista de entornos urbanos incluyendo medios participativos de manera interactiva. La técnica propuesta
es suficientemente genérica para tratar con medios homogéneos y no homogéneos,
ası́ como dispersión simple y múltiple. Esta técnica es válida tanto para iluminación
diurna (el Sol) o nocturna, dado que no está restringida a una distancia mı́nima de
las fuentes de luz. Además, utiliza los recursos de los procesadores gráficos en caso
de que haya que reconstruir la iluminación reflejada hacia el observador para medios
anisó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 mitigación de errores en las fronteras entre dichas réplicas.
Además, pretendemos superar la limitación de que las luces permanezcan estáticas durante la simulación como serı́a el caso de simular que el observador va sentado
en un vehı́culo. Para ello, estudiaremos los métodos basados en harmónicos esféricos que permiten de ofrecen la ventaja de la interacción dinámica de las fuentes de
luz, para superar la limitación de la distancia mı́nima entre la fuente y la escena sin
acumular excesivas aproximaciones.
156
Innovación y la Unión Europea (vı́a fondos FEDER) a travé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. Arquè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. Pérez, X. Pueyo, F. J. Seró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. Jiménez, I. Martı́n, and F. Pérez. MGFE: Materials and geometry format extended.
http://ima.udg.es/iiia/GGG/doc/mgfehtml/mgfe.shtml.
10. J.-R. Jimé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. Schrö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. Müller, editors, Fifth Eurographics Workshop on Rendering, pages 69–85, Darmstadt, Germany, June 1994.
13. I. Martı́n, F. Pé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. Pé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.
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 Politè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 información urbana
Estudio sobre la representación semántica y
topológica de interiores de edificios
Bernardino Domı́nguez Martı́n, Ángel Luis Garcı́a Fernández y Francisco R. Feito
Higueruela
Resumen El software relacionado con los entornos urbanos ha experimentado un
crecimiento muy significativo en los últimos años. Como este tipo de software requiere la creación y manipulación de modelos urbanos, tanto de ciudades completas
como de interiores de edificios, están apareciendo gran cantidad de propuestas para
cubrir esta necesidad, y más concretamente para manejar la geometrı́a, topologı́a y
semántica de modelos de interiores de edificios. En este capı́tulo revisaremos una
serie de trabajos que tratan esta problemática, relacionados con Sistemas de Información Geográfica (GIS), Modelos de Información de Edificios (BIM), Modelos de
Productos de Edificios (BPM) y Diseño Asistido por Computadora (CAD).
1.
Introducción
La información acerca del interior de los edificios se utiliza en aplicaciones tales como los Sistemas de Información Geográfica (GIS), Modelos de Información
de Edificios (BIM), bases de datos espaciales o Diseño Asistido por Computadora
(CAD). Cada aplicación utiliza distintas formas para representar la información; ası́,
el estándar más extendido para manejar la información BIM en la construcción es
el modelo de clases IFC (Industry Foundation Classes). Incluso en la misma área
de investigación es posible encontrar variadas visiones parciales del mismo modelo,
dependiendo de la aplicación especı́fica 1 .
Algunas aplicaciones relacionadas con la representación de interiores son el
cálculo de rutas de evacuación, navegación peatonal o de agentes por interiores,
reconstrucción 3D de edificios, modelado y diseño, desarrollo de juegos, peritaje
arquitectónico, etcétera.
B. Domı́nguez, Á.L. Garcı́a, F.R. Feito
e-mail: {bdmartin,algarcia,ffeito}@ujaen.es
1
A partir de ahora, se hará referencia a estas tecnologı́as por su nombre o sus siglas indistintamente
161
162
B. Domı́nguez, Á.L. Garcı́a y F.R. Feito
Las múltiples combinaciones posibles entre los distintos modelos de representación y las diversas áreas de aplicación hace difı́cil encontrar técnicas y modelos
comunes aplicables a un amplio espectro de trabajos. Es por esto que es útil establecer una clasificación de dichos modelos y áreas de aplicación como punto de partida
antes de desarrollar nuevas propuestas.
Se presentan aquı́ algunas de las contribuciones más recientes en el campo de la
representación semántica y topológica de interiores de edificios. En la Sección 2 se
fijan criterios para esta clasificación basados en el modelo de representación utilizado, y se resumen los principales antecedentes. Las Secciones 3 a 5 reseñan trabajos
relacionados con el tratamiento de información de interiores. En la Sección 6 se presenta un análisis comparativo de estos trabajos y se trata la importancia de investigar
métodos (semi)automáticos para el procesamiento de planos de plantas. Por último,
en la Sección 7 se resumen las conclusiones y el trabajo futuro a desarrollar.
2.
Modelos de representación
Hay muchos modelos de representación disponibles en la literatura reciente, presentados en trabajos sobre distintas aplicaciones con datos arquitectó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 áreas de GIS y BIM. Por otra parte, también se puede tener en cuenta
los objetivos de los modelos de representación; esto es: representación de topologı́a,
geometrı́a o semántica. Sin embargo, la mayorı́a de las propuestas presentadas son
modelos hı́bridos, que utilizan varios niveles de abstracción para almacenar información de distintos tipos.
En esta sección se revisan algunos trabajos basados en los estándares más comunes de BIM y GIS, ası́ como diferentes modelos para representar edificios (de
acuerdo con la división en 2D, 2.5D y 3D).
2.1.
Modelos de Información de Edificios y Sistemas de
Información Geográfica
En 1992, Björk [3] estableció los fundamentos de los sistemas BIM, presentando
un modelo orientado a objetos para la representación semántica de datos de edificios. Su investigació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, Björk centró su trabajo en la definición de un
esquema que incluyera información sobre espacios y las entidades que los encierran
(paredes, columnas, puertas y ventanas).
Estudio sobre la representación semántica y topológica de interiores de edificios
163
En 1997 apareció la primera versión del estándar IFC, creado por la IAI (International Alliance for Interoperability), convirtiéndose en uno de los más populares
para la representación de BIMs. La definición de este estándar está escrita con el
lenguaje de modelado EXPRESS, el mismo que aparece en [3], y define un esquema [6] para el intercambio de información de edificios en todas las etapas del
proceso de construcción, incluyendo información semántica sobre la estructura de
los mismos.
Por otra parte, los sistemas GIS son capaces de recoger cada vez más información
sobre el interior de los edificios. Con este fin, CityGML [20] define un modelo de
información para el almacenamiento de modelos urbanos, basado en cuatro niveles
de detalle, siendo el cuarto y último (LoD-4) el dedicado a los interiores de edificios.
Respecto a la representación de la geometrı́a subyacente, los sistemas BIM utilizan CSG, barrido o modelos B-Rep, mientras que los sistemas GIS sólo utilizan
modelos B-Rep [19] (por ejemplo: CityGML utiliza el lenguaje GML2 [26] para la
definición de información geométrica). La diversidad de modelos de representación
es un obstá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 último trabajo presenta
una serie de recomendaciones acerca de cómo deben evolucionar los modelos BIM
para que el desarrollo y estandarización de herramientas BIM sea más sencillo.
2.2.
Modelos 2D, 2.5D y 3D
Un criterio alternativo para clasificar los modelos de representación de edificios
es su dimensión espacial. Los modelos de edificios pueden contener:
Información 2D, como por ejemplo: planos de plantas, modelos estructurales de
habitaciones y pasillos, etcétera.
Información 2.5D, que implica aumentar la informació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.
Información 3D, representando la geometrı́a y la topologı́a de manera explı́cita.
A continuación se revisan varias propuestas de modelos de representación, clasificadas de acuerdo a los criterios anteriormente expuestos. Además, se analizarán
desde el punto de vista de su nivel de abstracción, esto es, el nivel de información
geométrica, topológica y semántica que se almacena en cada caso:
Modelos geométricos: estos modelos sólo contienen informació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
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 están repetidos en
la representación. Por otra parte, puertas, ventanas, mobiliario y otros elementos
tı́picos se representan como instancias de bloques [4]. Aunque hay alguna relación de conectividad en las instancias de bloques, este tipo de representación no
se considera topológica.
Modelos topológicos/semánticos: se pueden definir dos niveles de abstracción,
aparte de las representaciones puramente geométricas:
1. Modelos con información de adyacencia/conectividad entre primitivas geométricas (por ejemplo: puntos compartidos por dos lı́neas o lados compartidos por
polı́gonos).
2. Modelos que además incluyen información sobre entidades de alto nivel (habitaciones, pasillos, paredes, columnas).
Las representaciones del primer nivel se clasificarán como modelos topológicos,
mientras que las del segundo nivel se clasificarán como modelos semánticos.
3.
Modelos 2D
En esta sección se reseñan trabajos que utilizan una representación explı́cita 2D
de la geometrı́a de los edificios, ası́ como otros trabajos que aunque no incluyen
esta representación, están centrados en un área de aplicación que no requiere de una
representació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 áreas, y reflexionan sobre la posibilidad de migrar información entre ellos. Desde el punto de vista cognitivo, tratan tres modelos:
1. La cuadrı́cula de ocupación, utilizada en Inteligencia Artificial para la navegación de robots en espacios parcialmente ocupados.
2. El grafo de localización, utilizado para representar conectividad entre espacios.
3. El grafo de visión, utilizado para representar vistas conectadas en la navegación de robots basada en imá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 visión de
longitud máxima.
3. Los campos de isovistas, que representan cuencas visuales poligonales conectadas por lados si existe visibilidad mutua.
165
4. Los grafos de visibilidad, derivados de los campos de isovistas.
En este trabajo de Franz y otros se considera únicamente el tratamiento de
la información topológica, puesto que no se tiene en cuenta la representación
geométrica subyacente, y sólo el grafo de acceso incluye conceptos semánticos
y regiones espaciales.
Lamarche y Donikian [21] proponen un método de representación de la topologı́a de los espacios interiores de un edificio para la simulación de multitudes.
Calculan un conjunto de celdas convexas utilizando la triangulació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 representación topológica del espacio permite identificar corredores, cruces y callejones sin salida, utilizados para hallar cuellos de
botella para peatones. La representación geomé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 está 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 geométrica, con dos planos paralelos, el primero de los cuales
166
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 semántico, no se incluye ninguna información en este modelo, puesto que en las celdas convexas no se guarda información sobre la zona
de la planta (habitación, pasillo, etcétera) de la que proceden.
Otro trabajo interesante es el de Plümer y Gröger [28], en el que definen otra
representación formal para la agregación de objetos espaciales 2D, denominada
mapas anidados. Esta estructura consta básicamente de grafos planos restringidos cuyos ciclos se estructuran jerárquicamente. De esta forma, se puede modelar
fácilmente la estructura jerárquica de los espacios cerrados. Las restricciones sobre los grafos vienen dadas por siete axiomas sobre los vértices, lados, caras y
conectividad determinadas por los grafos planos. Por último, los autores estudian la integridad de los mapas anidados cuando se añ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 correlación entre
la geometrı́a y la topologı́a, ya que existe una correspondencia unı́voca entre los
nodos de los grafos y los vértices del plano 2D; ası́ mismo, los lados de los grafos
se corresponden con lı́neas rectas del plano. Sin embargo, la semántica asociada
a los espacios cerrados y los lados está fuera de los objetivos de ese trabajo.
Stoffel y otros proponen grafos jerá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. Tambié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
jerárquica es utilizada para modelar la inclusión de un espacio dentro de otro.
Las estructuras de datos utilizadas incluyen parámetros de tipo para indicar la
semántica de los nodos (puertas, ventanas, etcétera) y de los grafos (habitaciones, pasillos, almacenes...).
La relación entre geometrı́a, topologı́a y semántica en este trabajo es bastante
fuerte, y viene dada de la siguiente manera:
1. Las esquinas que definen las regiones espaciales tienen una posició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 reúnen los conceptos previamente descritos para
además añadir información semántica en los nodos, incluyendo un tipo (planta, sección, habitación, etcétera).
3
4
Straight Medium Axis Transform
Medium Axis Transform
167
El trabajo de Li y otros [24] toma directamente como punto de partida una representación semántica del interior de una planta de un edificio, incluyendo habitaciones, vestı́bulos, tabiques, muros, puertas y ventanas. Esta representación
está formada por un conjunto de células con significado, esto es: áreas delimitadas del modelo, ocupadas por cada uno de los elementos semánticos antes mencionados (por ejemplo, un trozo de muro se considera una célula). Estas células pueden estar vacı́as (vestı́bulos, habitaciones, puertas abiertas,...) u ocupadas
(paredes, ventanas, puertas cerradas,...). Se hace entonces una descomposició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 cé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 análisis
espacial y navegación de agentes (Figura 2). Este modelo de representación no
Fig. 2 Figura tomada de [24]. Análisis de rutas utilizando grafos de cuadrı́culas
168
busca conseguir una representación geométrica o topológica exacta, sino una representación discretizada sobre la que aplicar sus algoritmos. Es por esto que no
se menciona ningún modelo de representación 2D de la geometrı́a de la planta.
Zhi y otros [36] presentan un formalismo para trabajar con la representación de
planos arquitectónicos utilizando la siguiente metodologı́a: el plano arquitectó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 área mı́nima.
En este trabajo también se enumeran ocho problemas o dificultades que surgen
habitualmente al procesar planos CAD, incluyendo la existencia de errores e información redundante, uso de nombres no estándar para las capas y la identificación de las relaciones entre estancias comunicadas por puertas, especialmente en
aquellos casos en que una estancia tiene más de una puerta. Otras restricciones
sobre los datos de entrada incluyen la adecuada división de las entidades en capas y la utilización de bloques para representar sı́mbolos y dimensiones. Si todas
las restricciones indicadas se cumplen, la selección de entidades esenciales se
realiza de manera semiautomática.
Hahn y otros [17] trabajan sobre la generación de interiores de edificios en tiempo
real. Su generador se caracteriza por:
• La generación perezosa de los interiores. Esto es, sólo se genera la información para las zonas cercanas al punto de vista.
• El esquema de generación implica la división del edificio en regiones temporales, y la generación de puntos clave en las localizaciones donde estas
regiones han de convertirse en regiones construidas.
• La utilización de un conjunto de reglas para asegurar la corrección y el realismo de los resultados.
• El uso de números pseudoaleatorios en el proceso de generación de la informació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 semánticos como geométricos, puesto que el resultado de la división en regiones temporales es un conjunto
de subespacios que se corresponden semánticamente con habitaciones y vestı́bulos. La topologı́a se representa parcialmente, ya que durante el proceso mantienen un árbol de generación en el que los subespacios resultado de dividir un
espacio mayor están directamente relacionados con él, y estudiando la geometrı́a
de los subespacios resultado de una división, se pueden construir relaciones de
vecindad.
Resolver la generació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 arquitectónico después de entrenar
una red bayesiana con datos reales, que luego convierten en un plano real aplicando una optimización sobre el espacio de posibles distribuciones de plantas.
169
Por último, proponen la generación de modelos 3D a partir de los planos de las
plantas utilizando plantillas de estilo personalizables.
Su trabajo alcanza gran nivel de detalle semántico, ya que distinguen entre distintos tipos de habitaciones (dormitorios, comedor, cocina,...) para diseñar una
distribución que tenga en cuenta las heurı́sticas que siguen los arquitectos (por
ejemplo: las cocinas no suelen colocarse adyacentes a los baños). Como consecuencia, la geometrı́a y la estructura topológica del interior del edificio aparece
de forma explı́cita.
4.
Modelos 2D con altura
Esta sección resume trabajos que utilizan un modelo de representación 2D con
informació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 añade información de altura.
Slingsby y Raper presentaron en 2007 un interesante trabajo sobre la navegación peatonal en modelos 3D urbanos [29]. En él presentaban un estado del arte
sobre el modelado 3D urbano, la navegación peatonal y el acceso a edificios, y
proponı́an un modelo para representar espacios urbanos navegables consistente
en una representació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 relación entre geometrı́a y semántica, Slingsby y Raper proponen
el uso de etiquetas para las barreras (paredes y vallas) y la asociación de aberturas
y ascensores a los elementos geométricos, mientras que elementos semánticos de
mayor nivel como habitaciones o pasillos no se mencionan. La información topológica permanece implı́cita a la existencia de elementos geométricos etiquetados, de forma que la búsqueda de dichos elementos permite deducir informació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 automáticamente. Este sistema utiliza clases para representar formas en 3D etiquetadas (por ejemplo: sofá, mesa,
televisió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 último, es posible añadir reglas especı́ficas al planificador de distribuciones.
170
El planificador de distribuciones antes mencionado es un mó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 estén situados en la planta, y selecciona la mejor de acuerdo
a un sistema de puntuaciones.
Este trabajo ha sido incluido en la sección de modelos 2D con altura porque
aunque la base para el cálculo de la distribución de la planta es el plano 2D, se
utiliza informació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
representación de la geometrı́a y la semántica, se puede deducir que se tienen
en cuenta en el solucionador. Respecto a la representación de topologı́a en este
modelo, no se proporciona ninguna información.
La distribución del mobiliario en una planta también es tratada en el trabajo de
Germer y Schwarz [15]. Sin embargo, ellos utilizan una aproximación distinta,
utilizando agentes para representar muebles. Cada agente se encarga de buscar
una localización y una orientación apropiadas para el mueble que le corresponde,
ası́ como encontrar un objeto con el que establecer una relación de descendencia.
En este proceso, cada agente tiene tres posibles estados:
1. Búsqueda, cuando todavı́a no ha sido procesado, ha perdido su relación de
descendencia o su búsqueda de localizació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 geométrico y semántico),
ası́ como su altura. Sin embargo, como cada habitación se trabaja de manera
independiente, la información topológica no se tiene en cuenta.
En [13], van Dongen propone una técnica para simular interiores de edificios sin
almacenamiento de geometrı́a, para su uso en navegació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 informació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 simulación de interiores.
2. El algoritmo de simulació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 añadiendo más planos.
El trabajo de van Dongen se basa en técnicas de renderizado, y no necesita almacenar información semántica o topológica real. No obstante, se ha clasificado en
171
este grupo de técnicas porque contiene alguna información acerca de plantas con
altura.
El plano de planta estructurado propuesto por Choi y otros [9] es una estructura
semántica de alto nivel que cumple nueve principios acerca de la orientación de
los objetos en el modelo, la existencia de información sobre las relaciones entre
las entidades, el tratamiento de la información espacial y las relaciones, los niveles de detalle y la generación automática de un modelo 3D a partir del plano
estructurado (Figura 3). Utiliza un esquema orientado a objetos para la representació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
descripción exhaustiva de la geometrı́a de los edificios. En lugar de eso, los planos arquitectónicos se utilizan para calcular sólo la información semántica relevante, como la superficie de las losas, tejados, anillos, la anchura y altura de los
cimientos, vigas, aberturas, etcétera. El modelo está pensado para que lo utilicen
diseñadores CAD, de forma que al añadir nuevas caracterı́sticas a un diseño, los
172
cambios se integran en el plano estructurado, manteniendo ası́ la consistencia.
Aunque la representación subyacente del modelo es 2.5D, los autores muestran
algunos ejemplos de creación de contenido 3D a partir de los planos estructurados.
5.
Modelos 3D
Por último, se presenta un resumen de trabajos que hacen un uso más intensivo
de caracterı́sticas 3D.
La Red Geométrica 3D es un grafo propuesto por Choi y Lee para la representación de la conectividad entre las habitaciones de un edificio [8, 23]. Esta
estructura no sólo representa la estructura 2D de la planta, sino que también modela la estructura 3D al añadir lados entre las habitaciones de plantas diferentes.
La metodologı́a de creación de estos grafos implica el uso del algoritmo S-MAT
mencionado en la Sección 3 para extraer la estructura de paredes.
En este trabajo se consideran dos posibles entradas de datos para la creació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 aplicación del algoritmo S-MAT para obtener los esqueletos de las paredes.
2. Planos ráster. Los autores presentan tres métodos para obtener una lı́nea fina
a partir de las representaciones de paredes más gruesas de un pı́xel: adelgazamiento basado en diagramas de Voronoi, adelgazamiento basado en operadores matemáticos y refinado (peeling) de fronteras.
Las redes geométricas 3D representan la geometrı́a, la topologı́a y la semántica,
ya que utilizan modelos B-Rep de los edificios (geometrı́a) para obtener modelos
topológicos denominados Modelos de Datos Combinatorios (CDM). Las redes
geométricas se obtienen de los CDM, y a su vez contienen información sobre las
habitaciones (semántica), además de sobre la conectividad entre habitaciones a
través de las aberturas, y sobre la adyacencia entre habitaciones a través de las
paredes compartidas (topologı́a).
Clemen y Gielsdorf [10] proponen un método sistemático para normalizar (reducir la redundancia de) modelos geométricos. En su trabajo usan una representación generalizada de modelos consistente en sólidos formados por caras contenidas en planos, semilados y nodos. Las restricciones geométricas (planaridad,
paralelismo de planos) se pueden asegurar por integridad referencial.
Desde un punto de vista geométrico, este trabajo utiliza datos B-Rep como información de entrada en los métodos de reducción de la redundancia. Esta elección
es apropiada, puesto que es fácil hacer corresponder ambos modelos. Respecto a
la forma en que se obtienen los modelos B-Rep, este trabajo se centra en la gestión de datos topográficos de interiores. El modelo propuesto trabaja con datos
173
inexactos procedentes de mediciones de escenarios reales, puesto que el objetivo
es la estimación de la topologı́a real. Este método asume que hay redundancias
en los datos obtenidos, y aplica técnicas estadı́sticas. La topologı́a aparece de
forma explı́cita como relaciones entre sólidos, caras, planos, semilados y lados.
Sin embargo, no se mencionan elementos semánticos de alto nivel.
El problema de la conversión entre los modelos IFC y CityGML es tratado por
Van Berlo y Laat en un reciente trabajo [1]. Para conseguir esto, introducen una
extensión para CityGML denominada GeoBIM. Por tanto, tanto la geometrı́a
subyacente como los modelos semántico y topológico son los mismos en IFC y
CityGML.
Las casas topológicas propuestas por Paul y Bradley [27] son una abstracción puramente matemática para la descripción de casas. Esta definición formal permite
codificar casas utilizando dos estructuras: PLA (Puntos, Lı́neas y Áreas) y PLAV
(Puntos, Lı́neas, Áreas y Volúmenes). Los autores demuestran que se pueden utilizar estas estructuras para representar casas en bases de datos relacionales sin
pérdida de información. El modelo matemático presentado en su trabajo relaciona geometrı́a y topologı́a. Los únicos elementos semánticos que tiene en cuenta
son paredes y techos.
Billen y Zlatanova proponen el modelo dimensional, una abstracción topoló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 método sistemá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 representación utilizado es el Modelo Espacial Simplificado [37] debido a su representación explı́cita de los objetos, el uso de un nú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 topológicas y geométricas relativas al catastro 3D, se evita la
inclusión de caracterı́sticas relacionadas con la semántica de los interiores más
allá de unidades catastrales 3D, edificios o tuberı́as.
La representació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 información necesaria para calcular rutas.
Además de los niveles de detalle, en este modelo hay tres componentes adicionales: el modelo temático, el modelo geométrico (basado en GML) y el modelo
de rutas, que contiene puntos de conexión entre espacios adyacentes (Figura 4).
Por tanto, los tres niveles de abstracción (geométrico, semántico y topológico) se
relacionan en ese trabajo.
van Treeck y Rank [31] utilizan una aproximación basada en la teorı́a de grafos
para representar datos geométricos, topológicos y semánticos de un modelo de
producción de edificio (BPM). Usan estructuras de datos con varios niveles de detalle; ası́, la representación geométrica de paredes, ventanas, puertas, columnas,
174
Fig. 4 Figura tomada de [16]. Modelos temático y de rutas según el trabajo de Hagedorn y otros
etcétera se hace con modelos B-Rep, mientras que la representación topológica parte de una estructura radial de lados [33] que representa relaciones entre
vé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 ú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
métodos para hacer corresponder los grafos entre sı́ y obtener alguna información
semántica sobre paredes, volú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 posició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 cálculo de la posición:
1. El modelo basado en proyecciones, en el que un objeto se compara con la
extrusión de otro objeto. En este caso, se introduce la estructura de datos denominada slot-tree para acelerar los cálculos.
175
2. El modelo basado en semiespacios, en el que el primer objeto (la referencia) determina dos semiespacios, y se comprueba cuál de dichos semiespacios
ocupa el segundo (el objetivo).
Borrmann y Rank utilizan conjuntos sinté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 topológicos
y semánticos está fuera de los objetivos de ese trabajo.
Isikdag y otros [19] hacen hincapié en la falta de información semántica y relaciones espaciales en los modelos CAD, ası́ como en la ineficiente representación
de la geometrı́a 3D en modelos geoespaciales, como motivos que dificultan la
conversión entre modelos BIM y geoespaciales. Proponen escenarios de casos
de uso para la implementación de BIMs en entornos geoespaciales, ası́ como el
Modelo de Datos de Salida5 , que incluye clases para elementos semánticos y
estructurales como paredes, columnas, plantas y aberturas.
El problema de la representació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 só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 sólidos conectados. En su artı́culo muestran los resultados de
la aplicación de varios operadores de Euler en modelos de edificios reales representados con esta estructura.
La representación presentada en este trabajo tiene una fuerte relación entre la
geometrı́a y la topologı́a, pero conceptos relacionados con elementos de alto nivel semántico, como habitaciones, plantas, etcétera, parecen estar fuera de los
objetivos de su trabajo.
Un ejemplo de la aplicación de los BIM al diseñ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 módulos: BIM, intercambio y juego. El módulo BIM
guarda la información sobre los edificios, mientras que el módulo de intercambio
se encarga de gestionar el flujo de información entre el módulo BIM y el de juego. Para llevar a cabo esta tarea, en el módulo de intercambio se define un grafo
de alto nivel con información semántica detallada, en el que cada nodo representa una habitación y cada lado representa una puerta entre habitaciones (Figura
6). Puesto que el sistema tiene mó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 geométricos, semánticos y topológicos de modelos 3D urbanos. Para conseguir esto, enriquecen los modelos urbanos 3D con un módulo temático que contiene información semántica y topológica; luego, los elementos de dicho módulo se hacen
corresponder con los del modelo geométrico, manteniendo ası́ la coherencia en5
6
Output Data Model
Dual Half-Edge
176
Fig. 6 Figura tomada de [12]. Grafo de conectividad de habitaciones, de acuerdo con el trabajo de
Yan y otros
tre geometrı́a y semántica. Además, este trabajo también introduce una herramienta semiautomática para la integración del contenido semántico en el modelo
geométrico.
Los autores de este trabajo muestran como ejemplo de gestión de la información topológica con este modelo la construcción de una red topológica y una
red geomé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
topológica.
6.
177
Análisis comparativo y discusión
En las secciones anteriores se ha presentado una serie de referencias sobre la
representación de modelos de interiores de edificios, clasificándolos según la dimensionalidad de los datos y haciendo pequeñas reseñas de cada uno, haciendo
hincapié en la topologı́a, la geometrı́a y la semántica. Ahora se propondrá un modelo que trata de enlazar estos tres aspectos, para posteriormente compararlo con los
modelos revisados y plantear una reflexión sobre la aplicabilidad a diferentes áreas.
6.1.
Nueva propuesta: una arquitectura de tres módulos
El objetivo es plantear un sistema para la representació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 diseños arquitectónicos, a la semántica de alto nivel relativa a la distribución estructural y la conectividad entre espacios fı́sicos
(adyacencia entre habitaciones, entre una habitación y el exterior del edificio,
etcétera).
2. Toda la información almacenada debe estar relacionada a través de las distintas
vistas de forma eficiente.
3. Debe ser sencillo generar modelos basados en otras representaciones a partir de
la información almacenada en las vistas.
Para cumplir con estos requerimientos, se plantea un sistema estructurado en
tres módulos que almacenan datos sobre los planos CAD y la estructura topológica
de los interiores de los edificios (Figura 7). El primer módulo representa los datos
de entrada al sistema, y contiene los planos arquitectónicos CAD de las plantas.
Estos planos pueden contener información sobre estructura, mobiliario, fontanerı́a,
electricidad, etcé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 módulo contiene informació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 semiautomática los elementos
geométricos básicos (lı́neas y bloques) contenidos en el primer módulo.
El tercer módulo contiene un grafo de topologı́a, derivado de las paredes y aberturas detectadas, de forma que su grafo dual representa la subdivisión de la planta en
espacios cerrados (habitaciones). Esta estructura en habitaciones reúne la información semántica, estructural (grafo de topologı́a) y geométrica (dibujo de paredes).
Se han realizado pruebas con una versión preliminar de este sistema, obteniendo
resultados prometedores a partir de planos CAD de plantas de edificios reales:
178
Fig. 7 Arquitectura de tres módulos para la representación de modelos de edificios
Los planos CAD han sido procesados de manera semiautomática para detectar
caracterı́sticas semánticas y topológicas como paredes y habitaciones (incluyendo sus contornos internos y externos).
La información geométrica de los planos CAD se ha enlazado con la información
semántica obtenida semiautomáticamente.
Se han implementado módulos que permiten la exportación de los modelos generados a formatos estándar como CityGML y COLLADA.
6.2.
Análisis comparativo
En la Tabla 1 se presenta el resumen con las caracterı́sticas principales de los
trabajos revisados. También se incluyen a continuación algunas consideraciones relacionadas con la geometrı́a, conectividad y adyacencia topológica y semá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 información
geométrica. Sin embargo, no todos tratan esta información con la misma profundidad. Se distinguen las siguientes categorı́as:
1. Trabajos que no mencionan nada acerca de la geometrı́a, porque sólo se centran
en la semántica. En la Tabla 1 aparecen marcados con un guión (-).
179
2. Trabajos que mencionan elementos geométricos, pero sin dar detalles acerca de
la representación subyacente, que aparecen en la Tabla 1 etiquetados con el texto
implı́cita.
3. Los trabajos que en su representación incluyen vértices, lados, caras, regiones,
celdas discretas, planos o volúmenes aparecen etiquetados con las siglas V, L, C,
R, CD, P y Vo, respectivamente.
4. Por último, otros trabajos utilizan modelos de representació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 están topológicamente conectados si
existe una puerta o ventana entre ellos. Por tanto, los modelos que contienen información sobre aberturas mantienen conectividad topológica. la representación
de conectividad es explı́cita si está representada en el modelo, o implı́cita si es
posible deducirla a partir de un análisis del modelo.
Dos espacios en un modelo de edificio son topológicamente adyacentes si comparten al menos un elemento (dos habitaciones compartiendo una pared, por
ejemplo). La adyacencia es explı́cita si el modelo contiene información sobre
las relaciones entre los espacios, o implı́cita si es posible deducirla a partir de un
análisis del modelo.
Semántica
En la Tabla 1 se especifica qué elementos semá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.
Se han analizado una serie de trabajos sobre la representació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 según la dimensionalidad
de los datos almacenados en modelos 2D, modelos 2.5D y modelos 3D.
También se ha analizado la amplia variedad de modelos de edificios dependiendo
de las caracterı́sticas geométricas, semánticas y topológicas de las representaciones.
Como resultado de este análisis se desprenden las siguientes conclusiones:
180
Tabla 1 Comparación entre los trabajos revisados
Grupo
Artı́culo
Franz y otros [14]
Lamarche y Donikian [21]
Plümer y Grö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
Semá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=vértices, L=lados, C=caras, , R=regiones, CD=Celdas Discretas,
P=planos, Vo=volú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 representación para interiores de edificios y la gran variedad de campos de aplicación, es bastante complicado unificar
modelos. Por tanto, se debe pensar en problemas concretos en lugar de plantear
aproximaciones genéricas.
En la mayorı́a de los trabajos revisados, los modelos de edificios no se generan
de forma automática, independientemente del campo de aplicación (BIM, GIS,
bases de datos espaciales o modelos a medida). Ası́ pues, sigue siendo necesaria
la investigación para desarrollar algoritmos que permitan extraer información
semántica de planos CAD de plantas [4, 5].
El uso de formalismos es recomendable, puesto que permite aprovechar técnicas
ya desarrolladas, ampliamente probadas y cuya corrección ya está demostrada.
Por ejemplo: si se consigue dar a la representación forma de grafo, se puede
recurrir a todo el trabajo previo ya existente sobre grafos para obtener resultados
válidos.
181
Agradecimientos Este trabajo ha sido parcialmente subvencionado por la Junta de Andalucı́a, el
Ministerio de Ciencia e Innovación y la Unión Europea (fondos FEDER) a través de los proyectos
de investigació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.: Detección semiautomática de paredes, habitaciones
y escaleras a partir de planos arquitectónicos CAD. In: Proceedings of XX Congreso Español
de Informática Grá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
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. Zimá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 ampliación de la cartografı́a urbana
Resumen La necesidad de la inclusión de la tercera dimensión sobre la cartografı́a
catastral urbana de la ciudad de Jaén ha supuesto la introducción de campañas de
toma de datos de campo. Estos trabajos han consistido en la mayor parte de los
mismos en el desarrollo de varias nivelaciones geométricas mediante las cuales se
han recorrido las principales calles de interés para el proyecto. En todo momento
se ha llevado un control de la calidad geométrica de los datos tomados ası́ como
de la precisión de los mismos. En parte del recorrido también se ha implementado
otro método de observación de datos topográficos como es la poligonal mediante
estación total. Este método ha permitido tanto la dotación de altitud a la vı́a recorrida como la densificación de información planimétrica. Es importante reseñ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 superposición entre los
elementos cartográficos levantados y preexistentes se ha podido llevar a cabo con
éxito.
1.
Introducción
La cartografı́a disponible para el presente proyecto consiste en el plano catastral
urbano de la ciudad de Jaén en formato DXF. Sobre dicha cartografı́a se puede identificar información planimétrica de calles, manzanas, parcelas y construcciones, no
estando disponible, por tanto, la información de la altimetrı́a (Figura 1). Es en este
aspecto en el que se ha trabajado en esta fase del proyecto. La inclusión de la tercera
dimensión sobre la información planimétrica disponible ha supuesto la necesidad de
incluir campañ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 Cartográfica, Geodésica y Fotogrametrı́a. Universidad de Jaén
e-mail: {miramos,jlcruz}@ujaen.es
183
184
las zonas representadas en la cartografı́a inicial suponı́a una oportunidad no só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 Jaén
2.
Metodologı́a
Los trabajos de toma de datos de campo se desarrollaron a través de una serie
de campañas en las que se llevó a cabo un minucioso recorrido de las calles de la
ciudad recabando información de detalle. Se midieron las alturas de los edificios y
se tomó nota del número de plantas de cada uno de ellos.
2.1.
Distanciometrı́a láser
Para estas tareas se utilizó un distanciómetro láser de mano, concretamente el
Leica Disto D5 [3]. El Leica DISTO D5 diseñado con múltiples funciones y caracterı́sticas para hacer más sencillas las mediciones, particularmente cuando se trabaja
en exteriores como es nuestro caso. Una de las ventajas de este distanciómetro de
185
mano frente a otros más comunes es la incorporación de un visor digital con x4 de
zoom que permite hacer punterı́as de precisión (Figura 2). También presenta un visor telescópico para distancias largas y sensor de inclinación de hasta 45o . El rango
de medición es de 0,05 m hasta 200 m con una precisión de ±1,0 mm.
Fig. 2 Distanciómetro de mano empleado. Detalle de la cámara zoom incorporada. Fuente:
http://www.disto.es/D5/disto D5.php
El distanciómetro adquirido permite medir la distancia comprendida desde el
suelo hasta el vuelo de un edificio. Para ello se sitúa el distanciómetro al pie del
edificio pegado a la pared y manteniéndolo lo má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 más elevada del mismo y al suelo, como se muestra en la
(Figura 4). El instrumento mide las distancias ası́ como el á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 distanciómetro.
También se dotó de cota a árboles, mobiliario urbano, arquetas identificadas,
etc... Con el mismo instrumento se midió la anchura de las calles ası́ como del
acerado.
186
Fig. 3 Esquema de medición de altura de edificios con vuelo mediante distanciómetro láser de
mano en edificios
Fig. 4 Esquema de medición de altura de edificios con vuelo mediante distanciómetro láser de
mano en edificios
2.2.
187
Nivelación geométrica
La orografı́a de las calles se midió con precisión realizando una nivelación
geométrica con nivel electrónico. El método de nivelación geomé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 nivelación geométrica
Para llevarla a cabo se empleará el nivel, siendo éste el método de nivelación más
preciso existente. El procedimiento a seguir en la observació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 expresió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 colimación del nivel afectará por igual a las lecturas realizadas sobre la mira de espaldas
y de frente y la diferencia de lecturas erróneas coincidirá con la diferencia de lecturas correctas, eliminándose este error en la observación. Asimismo, la corrección
conjunta de esfericidad y refracción, al tener el mismo valor y el mismo signo en
ambos casos, se eliminará. Cuando los puntos A y B entre los cuales ha de determinarse el desnivel están separados una distancia considerable o no son visibles entre
sı́, será necesario estacionar más de una vez el nivel y observar la nivelación por
188
tramos. En este caso, el desnivel total entre los puntos A y B extremos de la nivelación será la suma de los desniveles parciales calculados en los tramos intermedios
(Figura 6).
Fig. 6 Esquema de la medida de puntos intermedios en la nivelación geométrica
Normalmente las lı́neas de nivelación tienen una longitud de varios kilómetros.
En las lı́neas de nivelación sencillas sólo se tiene comprobación del resultado cuando
se finaliza la nivelación. Si se comprueba, a posteriori en gabinete, que existe algún
error en las medidas irremediablemente la solución pasa por volver a campo y repetir
la toma de datos. Este inconveniente se evita, y al mismo tiempo se aumenta la
precisión, efectuando las medidas por duplicado, es decir, haciendo lo que se llama
una doble nivelación [1]. Para ello se divide el recorrido de la lı́nea en anillos (Figura
7), de tal modo que los extremos de éstos estén situados en superficies estables y que
se encuentren perfectamente señ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 continuación, se efectúa la nivelación en un sentido: nivelación de ida, trabajando con el
método del punto medio. Concluida la nivelació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 nivelación doble: Abierta y Cerrada:
Lı́neas de nivelació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.
189
Lı́neas de nivelación cerradas: son aquellas en la que partimos de un punto conocido y terminamos en otro punto conocido que coincide con el de partida. Só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
Cálculo de altitudes
En este proyecto, la metodologı́a de trabajo empleada para la toma de datos de
nivelación consistió en recorrer las calles a levantar fue lı́neas de nivelación cerradas
en la confluencia entre calles.
Se inició la medición utilizando como referencia de origen la cota del Instituto Geográfico Nacional (IGN) situada en la catedral. En la Figura 8 se muestra el
recorrido que se hizo para la nivelación geométrica. A partir del punto origen se
recorrió la calle Bernabé Soriano dividiendo posteriormente la nivelación en dos ramas; una transcurrirı́a por el Paseo de la Estación y la segunda hacia la Avenida de
Madrid. Como ya se ha apuntado anteriormente para comprobar la corrección de los
datos tomados se fueron cerrando los anillos en las calles intermedias. Finalmente,
la nivelación que transcurrı́a por la Avenida de Madrid se unió con la del Paseo de la
Estación a través de la calle transversal Calle Baeza siendo el punto exacto de unión
el edificio del Gobierno Civil, tal y como se puede apreciar en la Figura 9.
Fig. 8 Recorrido de la nivelación geométrica. Fuente: Google Earth [2]
190
Fig. 9 Imagen de detalle de la unión de las dos lı́neas de nivelación geomé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 nivelación se fue dando
cota en las esquinas de los edificios y, con la ayuda del distanciómetro de mano, se
fue dando altura a dichas construcciones.
2.3.
Poligonal
El hecho de añadir información geomé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 deformación existente entre ambas escalas. En tal caso es preciso
comprobar si se está 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 arrancó una poligonal de precisión desde clavo
NAP (Nivelación Alta Precisió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 proyección en ese punto y se obtuvo que, a la
escala que se estaba trabajando, las diferencias eran despreciables, por debajo de la
precisión instrumental, de orden submilimétrico.
Para actualizar la cartografı́a preexistente se aprovechó la poligonal de precisión
para ir dando coordenadas a las vı́as mediante medidas con el distanciómetro de in-
191
frarojos de la Estación Total (instrumento empleado para la poligonal de precisión)
ya que tenı́amos permiso de la alcaldesa del municipio para circular por la vı́a. Debido a conflictos burocrá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, prohibié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 láser al resto de la vı́a. El problema
es que la distanciometrı́a láser aú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 algún quiebro anómalo la lı́nea levantada. No obstante,
al realizar el encaje entre ambas cartografı́as, a actualizada y la preexistente, no se
observó ningún tipo de quiebro.
Para tener una idea orientativa de las cotas del resto de Jaén se optó por asignar
cotas mediante navegadores GPS siempre saliendo de una cota de precisión que fue
observada desde el Gobierno Civil encontrándose el punto más utilizado frente a la
puerta del Restaurante-Hamburgueserı́a que se muestra en la Figura 10, en el mismo
Paseo de la Estación. Para esta tarea y este trabajo se eligieron unas zonas de Jaé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 nivelación
densificando los puntos por si al trabajo informático le hacı́a falta más densidad de
datos bajando hasta el Restaurante-Hamburgueserı́a incluyendo la zona conocida
192
como las Protegidas situadas entre la avenida de Madrid y el paseo de la Estación
(Figura 10).
En un segundo trabajo se optó por dar cotas a la parte baja, parte norte, del
hospital y el barrio conocido como Peñamefecit. Saliendo de la cota obtenida situada
en el Restaurante-Hamburgueserı́a (Figura 11).
En una tercera campaña se tomó toda la parte noreste de Jaén hasta llegar al cementerio antiguo enlazando los datos hasta llegar al cruce de la Avenida de Madrid
con la Avenida de Ruiz Jiménez (Figura 12).
Finalmente se planificó la observación de la franja del Paseo de la Estación Avenida de Madrid hasta llegar a la Plaza de Jaén por la Paz, tomando datos de la
zona Av. de España, má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 Jaén (Figura 13).
2.4.
Resultado
La última fase de este apartado del proyecto consistió en integrar los datos levantados con la cartografı́a preexistente. Para ello, y con el objeto de tratar la información espacial como datos 3D a los cuales se les pudiese adjuntar todo tipo
193
194
de información temá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 Jaé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
Interacción
Estudio sobre técnicas de visualización y
navegación de entornos virtuales en dispositivos
móviles
Resumen En este capı́tulo ofrecemos una introducción al mundo de los dispositivos
móviles y ahondamos en sus bondades y problemáticas. También proporcionamos
unas consideraciones generales e identificamos los puntos en los que la computación
móvil difiere de la computación habitual en ordenadores de escritorio. También repasamos las tecnologı́as más habituales que es posible encontrar dentro del mundo
de los dispositivos móviles, asi como las plataformas existentes, sistemas operativos
y estándares de desarrollo para gráficos tridimensionales. Los dispositivos móviles
sufren unas severas restricciones en su potencia de cómputo y capacidad de almacenamiento. Estas restricciones han provocado que numerosos investigadores hayan
desarrollado técnicas especı́ficas para la visualización interactiva de escenas 3D en
estos dispositivos. Para terminar, se presentan las principales propuestas para la visualización de escenas 3D genéricas en dispositivos móviles existentes en la literatura.
1.
Introduction
En los últimos años, la aparición de la telefonı́a móvil ha supuesto un cambio social importante. Según la International Telecommunications Union, en 2008 habı́a
3.3 miles de millones de personas (la mitad de la población mundial) que empleaban
dispositivos móviles [8]. Es más, podemos considerar al teléfono móvil como el dispositivo dotado de capacidades gráficas más extendido [1]. Aparte de lo anecdótico
de los datos, es evidente que las posibilidades que se brindan ante esta situación son
numerosas.
Los primeros dispositivos móviles (terminales de telefonı́a móvil, agendas electrónicas portátiles o PDAs, etc.) no dejaban de ser aparatos diseñados para cumplir su
función especı́fica, y sus prestaciones se limitaban a lo estrictamente necesario para
cumplir dichas funciones. Sin embargo, la paulatina inclusión de nuevos servicios
ha ido acompañada con un aumento espectacular en las prestaciones y funcionali-
197
198
dades de estos dispositivos. Incluso han surgido sistemas operativos diseñados especı́ficamente para los mismos, donde Symbian OS, iOS o Android son sólo algunos
ejemplos. Hoy en dı́a puede afirmarse que los dispositivos móviles se han convertido
en pequeños ordenadores personales con capacidad de procesamiento prácticamente
similar a los ordenadores de hace diez años.
No obstante, la forma de trabajar con los dispositivos móviles sigue difiriendo
enormemente a la forma de trabajar con ordenadores personales. La computación
móvil ofrece una serie de ventajas inéditas en otros entornos que han sido la razón
de su éxito:
1. Ubicuidad. Puedes trasportarlos siempre contigo.
2. Conectividad. Están siempre conectados a una red de datos.
3. Localización. Pueden obtener su localización geográfica, por ejemplo, a través
del sistema GPS. Permiten acceder a servicios basados en la posición del usuario.
4. Interfaz multimodal. Teclados, pantallas táctiles y multitáctiles, voz, acelerómetros. . . Su pequeño tamaño añade nuevas formas de interacción con el usuario.
Por el contrario, los dispositivos móviles presentan una serie de inconvenientes
que han de tenerse presentes a la hora de desarrollar software para ellos [2]. Su
limitado tamañ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 alimentación eléctrica. Entre otros inconvenientes de los dispositivos
móviles, destacamos los siguientes:
1. Ahorro de baterı́a. Los dispositivos móviles requieren de una baterı́a para su
funcionamiento. Las baterı́as son costosas y pesadas, por lo que la reducción
del consumo energético es el factor que determina el diseño de los dispositivos
móviles. Procesador, procesador gráfico, memoria, sistema operativo, etc. son
diseñados anteponiendo la eficiencia energética al rendimiento. El software también debe diseñarse con este problema en mente.
2. Limitaciones del procesador. Debido a las razones anteriores, los procesadores
existentes para dispositivos móviles suelen carecer de operaciones complejas.
Ası́, por ejemplo, la familia de procesadores ARM9, presente aún en muchos
dispositivos, carece de procesador de coma flotante (FPU). Además, las memorias cachés suelen estar muy limitadas. Todo ello hace que el rendimiento del
sistema se ralentice. Con los procesadores gráficos, el problema es análogo.
3. Modelo de memoria limitado y escaso. A diferencia de los ordenadores convencionales en los que el procesador es capaz de direccionar un tamaño de memoria
muy amplio (del orden de Gigabytes), en los dispositivos móviles la cantidad de
memoria disponible es mucho más escasa. Además é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 volátil)
para segmentación y paginación de memoria virtual no es útil debido a los elevados tiempos de acceso que padecen.
4. Comunicaciones limitadas. El acceso a Internet desde dispositivos móviles requiere el uso de tecnologı́as inalámbricas tales como 2G y 3G. El ancho de banda
Estudio sobre técnicas de visualización y navegación en dispositivos móviles
199
ofrecido por dichas conexiones es generalmente más estrecho que el ofrecido por
una conexión cableada. Además, estas conexiones suelen ser costosas y tienen
coberturas limitadas. Redes inalámbricas de área local, tal y como IEEE 802.11
son más rápidas y económicas, pero tienen un rango de alcance aún más limitado.
5. Interfaz de usuario. Las pantallas y teclados tienen a ser muy pequeños, lo cual
dificulta su uso y la cantidad de información que pueden trasmitir.
6. Fragmentación. Las tecnologı́as móviles cambian constantemente. Esto, unido a
las constantes luchas comerciales por parte de múltiples fabricantes para hacerse
con el mercado, ha dado lugar a un gran nú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, anacrónico. Algunos aspectos de la programación que habı́an sido
superados gracias a las mejoras en el hardware son ahora rescatados del olvido.
2.
Tecnologı́as Móviles
Pese al auge de los dispositivos móviles y el rápido incremento de sus prestaciones, aún existı́a un gran inconveniente que impedı́a en cierto modo su eclosión
como dispositivos de entretenimiento e información avanzada. La amplia difusión
que la Informática Gráfica ha tenido en el campo de los ordenadores personales se
ha debido en gran medida al abaratamiento e inclusión en los equipos de GPUs con
gran capacidad de procesamiento. Hasta ahora esa posibilidad no estaba disponible
en los dispositivos móviles. Sin embargo, los fabricantes de GPUs han sido conscientes de las amplias posibilidades que supone este mercado, diseñado hardware
gráfico adaptado para su uso móvil. En [2] podemos leer una revisión sobre las
caracterı́sticas de las GPUs para dispositivos móviles.
Antes de la llegada este hardware gráfico de bajo consumo, no era posible visualizar gráficos 3D realistas de manera interactiva. Sus limitadas prestaciones y el uso
de librerı́as de visualización por software solo permitı́an mostrar escenas triviales.
Hasta hace pocos años, ni siquiera era posible visualizar un cubo con sombreado de
Gouraud de forma interactiva.
Aparte del hardware gráfico, otro factor determinante ha sido la importante mejora en la tecnologı́a empleada para las pantallas. Los primeros dispositivos móviles
de consumo disponı́an de pantallas pequeñas (48 × 48 pı́xeles) y monocromáticas.
Hoy en dı́a, los modelos má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 continuación se describen las múltiples tecnologı́as y librerı́as gráficas (APIs)
que pueden emplearse en el desarrollo de aplicaciones con gráficos 3D para dispositivos móviles. Para ampliar información, puede consultarse [8].
La Sección 2.1 revisa las diferentes tecnologı́as y estándares gráficos existentes
en el mercado de los dispositivos móviles. La Sección 2.1 ofrece una visión general
de las distintas plataformas y sistemas operativos especializados que es habitual
encontrar al trabajar con dispositivos mó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
Fig. 1 40 años de historia de gráficos en dispositivos móviles.
Por último, en la Figura 1 mostramos una lı́nea de tiempo que refleja los mayores
hitos ocurridos en la historia de los dispositivos móviles durante los últimos 40
201
años. Se tienen en especial consideración los hechos relacionados con la Informática
Gráfica.
2.1.
Estándares Gráficos
La inclusión de hardware gráfico de alto rendimiento en los dispositivos móviles
no sirve de nada si no está acompañado de un conjunto de librerı́as y estándares
especializados que permitan el desarrollo de software especı́fico que aproveche todo
el potencial de dichos dispositivos.
Las dos librerı́as gráficas más extendidas que permiten sacar partido al hardware
gráfico de los dispositivos móviles son OpenGL ES y M3G [39]. La primera generalmente se emplea con el lenguaje de programación C o C++, mientras que la
segunda ha sido diseñada para su uso desde Java Mobile Edition (JME).
OpenGL ES [23] es un subconjunto de la librerı́a gráfica OpenGL, especı́ficamente diseñada para dispositivos integrados. Entre éstos, se encuentran teléfonos
mó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 gráfico subyacente. Es libre de royalties
e independiente de la plataforma.
OpenGL ES incluye perfiles de compilación para sistemas de punto fijo y para
sistemas de punto flotante, ası́ como la especificación EGL que permite el enlazado
de sus aplicaciones en sistemas de ventanas.
Actualmente se han desarrollado dos versiones de OpenGL ES. Para una comparación entre sı́, véase [9, 38]. A continuación resumimos las caraterı́sticas más
importantes de ambas:
OpenGL ES 1.x ha sido diseñado a partir de la especificación OpenGL 1.5, y
ofrece operaciones aceleradas, alta calidad de imagen y elevado rendimiento,
asegurando ademá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 visualización enteramente por software. No permite la programación
de la GPU.
OpenGL ES 2.X [31] ha sido diseñado especı́ficamente para dispositivos dotados de hardware grá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 gráfico fijo de la GPU. Esto fuerza al desarrollador a escribir programas
de vértices y de fragmentos.
OpenGL ES es la librerı́a para grá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 diseñ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, iluminación, rasterización, etc.),
202
mientras que M3G ofrece caracterı́sticas avanzadas como grafos de escena y animación. Su función es ofrecer una interfaz para Java estandarizada y de mayor nivel
que OpenGL ES. Ası́, OpenGL ES proporciona máxima eficiencia y flexibilidad para el desarrollo de aplicaciones nativas. M3G, por otro lado, añade las caracterı́sticas
necesarias para un desarrollo eficiente sobre Java.
La especificación 2.0 de M3G (JSR-297) [20], aún en desarrollo, se construirá sobre OpenGL ES 1.1 ó 2.0, y permitirá opcionalmente el uso de GPU programable.
También existe la posibilidad de realizar directamente llamadas a la librerı́a
OpenGL ES desde Java a través de la librerı́a Java Bindings para OpenGL ES (JSR239) [19]. Esta especificación define un paquete opcional para JME que ofrece una
interfaz estándar para Java muy similar a la librerı́a original para C de OpenGL ES.
No obstante, esta especificación no goza de mucho apoyo por parte de la industria,
y la mayorı́a de los dispositivos móviles con hardware 3D no la incluyen.
El sistema operativo es el software encargado de proporcionar a las aplicaciones
servicios tales como gestión de procesos e hilos, gestión de memoria, acceso a ficheros y redes, etc. También se encarga de gestionar la interfaz de usuario. Debido a sus
limitaciones, los dispositivos móviles requieren de sistemas operativos especı́ficos y
adaptados a sus posibilidades. En esta sección describimos algunos de los sistemas
operativos y plataformas móviles más destacadas. La lista no es exhaustiva, pues su
objetivo es ofrecer al lector una imagen general del mercado y del potencial gráfico
de las distintas plataformas.
2.1.1.
Windows Mobile
Windows Mobile [29] es un sistema operativo para dispositivos móviles basado en la interfaz Win32 de Microsoft. Está diseñ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 gráfico 3D son muy escasos. Entre éstos, los modelos más populares son las
PDAs Dell Axim X50v y X51v, equipadas con una GPU Intel 2700G. Estos modelos
han sido ampliamente utilizados en el ámbito cientı́fico.
Estos dispositivos pueden programarse mediante la librerı́a gráfica especı́fica de
Microsoft, Direct3D Mobile, si bien los fabricantes suelen proporcionar controladores para OpenGL ES. La versión de OpenGL ES disponible para las PDAs Dell
Axim es la 1.0.
En 2010, Microsoft presentó Windows Phone 7, su nueva plataforma móvil, con
el objetivo de reemplazar a Windows Mobile. Todos aquellos dispositivos móviles
que quieran incluir Windows Phone deben satisfacer una serie de requisitos impuestos por Microsoft, entre los que se encuentra la aceleración gráfica por hardware
[42]. Al contrario que la mayorı́a de plataformas móviles, Windows Phone 7 no
soporta OpenGL ES. En su lugar, es preciso emplear una librerı́a especı́fica de Microsoft.
2.1.2.
203
Android
Android [28] es una plataforma software y un sistema operativo para teléfonos
móviles basada en el núcleo de Linux. Ha sido desarrollado por Google. Sólo se
permite el desarrollo de software en el lenguaje Java de forma inmediata, que se
ejecuta dentro de una máquina virtual. No obstante, no soporta las librerı́as estándar
de JME, sino que debe emplearse una librerı́a especı́fica desarrollada por Google.
Por tanto, una aplicación para Android no podrá 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 términos gráficos, Android soporta la tanto OpenGL
ES 1.0 como OpenGL ES 2.0 a través de una especificación propietaria similar (pero
no igual) a JME Java Bindings para OpenGL ES.
2.1.3.
iOS
iOS [32] es un sistema operativo diseñado por Apple Inc. y basado en una variante del núcleo Mach del sistema operativo Mac OS X. Es empleado por el teléfono
móvil iPhone, y por los dispositivos portátiles iTouch e iPad. El modelo iPhone
3G incorpora una GPU modelo PowerVR MBX, y soporta la especificación 1.1 de
OpenGL ES. En cambio, modelos más recientes como el iPhone 3GS, el iPhone 4 o
el iPad incorporan GPUs de la serie PowerVR SGX, que cumplen la especificación
2.0 de OpenGL ES.
Apple proporciona su propio entorno de desarrollo para crear aplicaciones destinadas a iOS, denominado Cocoa. El lenguaje de programación habitual en esta
plataforma es el Objective-C. Este lenguaje es un superconjunto de C, el cual ha
sido extendido mediante ciertos elementos sintácticos y semá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 elaboración de software fácilmente transportable a distintos dispositivos. No obstante, se permite que
código escrito en ANSI C y C++ pueda entremezclarse y enlazarse libremente con
código Objective-C dentro del mismo ejecutable. Por tanto, si se aı́slan las partes
de código que deban acceder a la librerı́a nativa del sistema, es posible transportar
código C++ con OpenGL ES existente al iPhone.
2.1.4.
Symbian OS S60
Symbian OS [5] es un sistema operativo diseñado especı́ficamente para teléfonos
móviles y otros dispositivos con recursos limitados. Existen en el mercado algunos
204
teléfonos con Symbian OS y dotados de aceleració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 especificación de OpenGL ES soportada es la 1.1.
2.1.5.
Videoconsolas Portátiles
Nintendo 3DS es una videoconsola portátil fabricada por Nintendo y anunciada
a finales de 2010, con fecha de lanzamiento en 2011. Está equipada con una GPU
DMP Pica200, y soporta la especificación de OpenGL ES 1.1. Este dispositivo demuestra que a las GPUs móviles no programables aún le quedan largos años de
vida. Pese a que diversos y costosos teléfonos móviles de alta gama incluyen GPUs
con proceso gráfico programable (compatibles con OpenGL ES 2.0), dispositivos
de ocio electrónico de bajo coste siguen implementando OpenGL ES 1.1.
PSP NGP es otra videoconsola portá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 móvil están basadas en una red de celdas, donde cada celda
dispone de un transmisor conocido como estación base. La capa de comunicació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 generación de tecnologı́as de telefonı́a móvil formada por GPRS y EDGE se le
conoce como telefonı́a móvil “2G” o de segunda generación. A EDGE también se
le conoce como “2.5G” Má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 análoga, a la generación de tecnologı́as que
comprende a ambas se la denomina “3G” o de tercera generación, y HSDPA en
particular también se le denomina “3.5G”.
3.
Visualización 3D en Dispositivos Móviles
En esta sección, repasaremos el estado del arte en el campo de la visualización
de escenas genéricas tridimensionales en dispositivos móviles. No nos adentraremos
a discutir aplicaciones especı́ficas, videojuegos ni herramientas de desarrollo, que
escapan del ámbito de este trabajo.
La navegación interactiva a través de mundos 3D complejos requiere la habilidad de poder visualizar la escena a un número de imágenes por segundo aceptable,
205
mientras se mantiene la calidad de la escena lo más alto posible. A lo largo de los
años, se han propuesto diversas técnicas para acelerar la visualización de escenas y
objetos complejos en dispositivos móviles.
Los métodos de visualización local expuestos en la Sección 3.1 asumen que
el modelo a visualizar cabe completamente en la memoria del dispositivo móvil.
No obstante, debido a que es habitual que los dispositivos móviles se encuentren
conectados a una red, es viable el uso de técnicas de visualización en las que el
modelo 3D esté almacenado en un servidor remoto. En general, podemos clasificar
los métodos de visualización cliente-servidor en tres grandes categorı́as, en función
de dónde se realiza la tarea de visualización de geometrı́a, [27]:
Métodos de visualización en el lado del servidor, en los que todas las tareas de
visualización recaen en un servidor gráfico remoto.
Métodos de visualización en el lado del cliente, en los que la visualización
recaen en el lado del cliente.
Métodos de visualización hı́bridos, en los que cliente y servidor se reparten las
tareas encaminadas a la visualización de la escena.
3.1.
Visualización Local
Las técnicas de visualización local almacenan toda la escena a visualizar en el
propio dispositivo. No necesitan mantener conexión con ningún servidor remoto.
Son más simples de implementar y la experiencia del usuario no se ve mermada por
congestión o cortes de red. No obstante, el tamaño de la escena a representar queda
limitado por el tamaño de la memoria del dispositivo.
Este tipo de métodos son habitualmente empleados en videojuegos. En la literatura cientı́fica, la mayorı́a de los trabajos propuestos para dispositivos móviles
tratan de buscar estrategias más eficientes de dibujar una escena que la simple visualización directa. No obstante, estas técnicas siguen limitadas por la capacidad de
cómputo y de almacenamiento de los dispositivos móviles.
En dispositivos móviles que carezcan de hardware acelerador 3D, la transformación y dibujado de primitivas geométricas puede suponer una gran carga de cómputo
a la CPU. Esto supone un derroche importante si la mayorı́a de los triángulos de la
escena cubren menos de un pı́xel de la pantalla. Algunos autores [13, 14] proponen
simplificar la visualización mediante el dibujado de puntos en lugar de triángulos.
Estas técnicas de visualización basadas en puntos aproximan geometrı́as complejas mediante un conjunto de puntos situados sobre la superficie de los objetos. El
número de puntos a dibujar depende de la complejidad de los objetos y del tamañ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 volúmenes
envolventes. Esta técnica permite ajustar el nivel de detalle en función de los requerimientos de velocidad y de la pantalla. También resultan más eficientes en memoria
puesto que no se requiere tener todo el modelo simultáneamente en memoria.
206
No obstante, con la creciente inclusión de GPUs en los dispositivos móviles de
gama alta, estas técnicas basadas en visualización de puntos carecen de utilidad,
puesto que el dibujado y transformación de los triángulos recae sobre la GPU.
Huang et al. [16] propone otra técnica para simplificar la visualización en dispositivos móviles basada en la visualización expresiva o no fotorrealı́stica. Su trabajo
expone cómo superar las limitaciones del dispositivo móvil empleado (PDA Dell
Axim x51v) para conseguir diversos efectos interactivos. Estos efectos son interesantes para herramientas de diseño asistido por ordenador (CAD). Entre otros, se
incluyen extracción de siluetas, visualización del interior del modelo mediante cortes, inclusión de anotaciones, etc.
Yang et al. [48] propone otra aplicación de CAD orientada a su uso en dispositivos móviles. Su trabajo se centra en describir un algoritmo compacto de triangulación basado en la triangulación secuencial y restringida de Delaunay. Mediante
este algoritmo, un dispositivo móvil es capaz de calcular la malla de triángulos que
aproxima a las entidades geométricas almacenadas en un fichero STEP (STandard
for Exchange of Product model data), usualmente piezas mecánicas. Una vez calculada la triangulación, se procede a su dibujado mediante OpenGL ES.
La ubicuidad de los dispositivos móviles ha animado a muchos investigadores y
empresas privadas a desarrollar aplicaciones de navegació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] aplicó comercialmente esta idea con éxito en la ciudad de
Tokio. En [36] podemos encontrar un análisis de trabajos sobre visualización urbana
en 3D para dispositivos móviles.
La ubicuidad de estos dispositivos tambié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 visualización. Afirman obtener velocidades interactivas (30 animaciones por segundo) en
un teléfono con GPU, Nokia N82, en la visualización de una escena de interior con
6191 triángulos sin texturas.
Por último, la visualización de volúmenes en dispositivos móviles es un tema
muy poco explorado en la literatura. En ordenadores personales suelen aplicarse
dos tipos de té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 móviles, el soporte de texturas tridimensionales se ofrece mediante una extensión opcional de OpenGL ES 2.0, poco implementada por los fabricantes. Para solventar esta ausencia, Moser et al. [30] emplea la técnica de las
lonchas bidimensional en un dispositivo Dell Axim x51v, dotado de hardware acelerador 3D. Los autores afirman visualizar un modelo volumétrico de resolución
633 vóxeles a una velocidad de 1.5 imágenes por segundo en una pantalla de resolución 640 × 480 pı́xeles. Para aumentar la velocidad, los autores proponen reducir
el número de fragmentos a procesar por la GPU. A tal fin, reducen la resolución
207
de la imagen a dibujar y posteriormente la escalan hasta que ocupe toda la pantalla
del dispositivo. Limitando la resolución a 128 × 128 pı́xeles, afirman conseguir una
velocidad de 9.9 animaciones por segundo.
3.2.
Visualización en el Lado del Servidor
En los métodos en el lado del servidor, existe un servidor remoto que lleva a cabo
la visualización de la escena 3D. La imagen o conjunto de imágenes resultantes son
enviadas al cliente, quien solo debe mostrarlas en la pantalla.
Debido a que el cliente se limita a visualizar imágenes pre-generadas, los requerimientos de computación en el lado del cliente son independientes de la complejidad de la escena. Por tanto, estos métodos resultan muy apropiados para visualizar
modelos geométricamente complejos en dispositivos con muy poca capacidad de
cómputo o de almacenamiento. No obstante, estas té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 inalámbricas pueden provocar fácilmente congestión de red y caı́da
del rendimiento.
2. Escalabilidad. Se requiere de un servidor con gran capacidad de cómputo. Un
incremento en el número de clientes conectados concurrentemente al servidor
puede incrementar con facilidad los tiempos de respuesta del mismo.
El problema de enviar imágenes a travé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 técnicas de visualización
remota basada en imágenes. El servidor proporciona una serie de imágenes (fotogramas clave) al cliente, y éste es capaz de calcular los fotogramas intermedios.
Para ello, el servidor también proporciona el mapa de profundidad1 de cada imagen. Para calcular los fotogramas intermedios, es preciso aplicar a cada pı́xel de la
última imagen recibida una traslación en función del desplazamiento de la cámara.
El problema de estas técnicas es cómo situar la cámara para que no aparezcan agujeros en la imagen. Proporcionar una solución general a este problema es una tarea
complicada. Por dicha razón, estas soluciones tienen un ámbito de aplicación muy
restringido. [22] aplicó esta técnica para la visualización de escenas urbanas.
Tanto Aranha et al. [3] como Jeong y Kaufman [21] han propuesto sistemas de
visualización remotos en los que el servidor genera una secuencia de imágenes mediante trazado de rayos. Estas imágenes son comprimidas y enviadas al dispositivo
cliente para su visualización. Aranha se limitó a experimentar con un PC que simulaba a un dispositivo móvil. Jeong y Kaufman, por otro lado emplearon una PDA
1
Es habitual denominar al mapa de profundidad por su nombre en inglés, z-buffer.
208
real para visualizar escenas médicas. Afirman conseguir una velocidad de 5 imágenes por segundo a través de una conexión inalámbrica de área local IEEE 802.11b
con el servidor.
Lamberti et al. [24] presentó un sistema completo de visualización remota basado en el envı́o de un flujo de vı́deo MPEG a través de la red. En el lado del servidor
emplean un clúster de ordenadores dotados de hardware gráfico y capaces de repartirse las tareas de visualización entre sı́ mediante el uso de un software llamado
Chromium [17]. Los autores afirman conseguir la visualización remota en una PDA
a 30 imágenes por segundo y resolución de 240 × 240 en un clúster de 8 PCs. No
obstante, los autores admiten que dicho clúster no es lo suficientemente potente como para generar simultá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 solución que combina el uso de una estructura multirresolución para la visualización de terrenos en un servidor, junto con su visualización remota en un cliente móvil mediante envı́o de vı́deo por red. Por desgracia,
el artı́culo presenta una descripción muy superficial de la técnica, y no se ofrecen
resultados de rendimiento en el cliente ni de uso de la red.
Boukerche [6] y Pazzi [37] han presentado técnicas alternativas para la visualización remota basada en imágenes. Estos autores consiguen reducir el consumo
de ancho de banda mediante el uso de técnicas de predicción de movimientos y de
envı́o parcial y progresivo de imágenes panorámicas. No obstante, estas técnicas
limitan severamente los movimientos del observador, y no se comportan bien en
escenas dinámicas.
3.3.
Visualización en el Lado del Cliente
En los mé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 visualización de forma local.
Este tipo de técnicas no precisan que el servidor posea ningún tipo de capacidad
gráfica, por lo que reducen la carga de trabajo del servidor. Como contrapartida, este tipo de técnicas son más exigentes con el cliente, que debe poseer la capacidad de
cómputo y de almacenamiento suficientes como para poder trabajar con escenas de
la calidad requerida. Los métodos de visualización en el lado del cliente son apropiados para aplicaciones en las que la interacció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 trasmisión de escenas 3D bajo demanda de acuerdo a la región
de interés ha atraı́do un considerable interés cientı́fico. Schneider [44] y Teler [46]
emplearon la idea de nivel de detalle para trasmitir datos de manera adaptativa en
función de criterios tales como el ancho de banda y la capacidad de cómputo disponibles. No obstante, estos autores no trabajaron explı́citamente con dispositivos
móviles.
209
En el caso de los dispositivos móviles, y comparado con la gran cantidad de literatura que versa sobre técnicas de visualización en el lado del servidor, la cantidad
de trabajos publicados sobre métodos en el lado del cliente es reducida. En esta
sección repasaremos los trabajos al respecto que han sido publicados que abordan
especı́ficamente este problema en dispositivos móviles.
Un ejemplo tı́pico de métodos de visualización 3D en el lado del cliente lo constituyen los sistemas de visualización y navegació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 fácil exceder el tamaño de la memoria de cualquier ordenador convencional. Este hecho ha motivado a numerosos
investigadores a desarrollar té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] presentó un sistema cliente-servidor para la
visualización de modelos multirresolución en un cliente móvil. Para visualizar un
modelo 3D, el cliente proporciona al servidor los parámetros de la vista. El servidor extrae una malla de triángulos que representa al modelo con el nivel de detalle
deseado, y lo recorta según el volumen de visión. Esta malla simplificada se envı́a
al cliente para su visualizació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 técnica es la considerable latencia experimentada cuando la vista cambia y
el modelo debe actualizarse. Esto limita el método a modelos de baja complejidad
geométrica y a redes inalámbricas de área local.
En [33, 34, 35], Nurminen describe su proyecto m-LOMA 3D Map. Se ofrece
una solución completa cliente-servidor para la navegación virtual por entornos urbanos mediante dispositivos móviles. Un servidor aloja la geometrı́a y texturas de
los edificios, y los trasmite de forma progresiva al cliente bajo demanda a través de
una red inalá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 cúbicos. Entonces, para cada bloque se determina el
conjunto de bloques potencialmente visibles. En tiempo de ejecución se emplea esta
estructura para reducir el número de edificios a descargar y visualizar.
3.4.
Visualización Hı́brida
Los métodos hı́bridos persiguen repartir el cómputo entre el servidor y el cliente
con el objetivo de mejorar el rendimiento del cliente.
Ante la dificultad de representar gráficos foto realistas en dispositivos móviles
poco potentes, algunos autores propusieron soluciones cliente-servidor hı́bridas basadas en visualizació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 té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
el ancho de banda necesario para su trasmisión al cliente, ası́ como aumentar la
velocidad de visualización de la escena.
Quillet et al. [40] propuso un trabajo similar orientado a la navegación por escenas urbanas. Un servidor emplea algoritmos de detección de fronteras para extraer
las caracterı́sticas principales de la textura de las fachadas. Con esta información se
genera una representació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 técnicas muestran una representación monocroma y distante con la realidad, lo que dificulta la comprensión de la escena por
parte del usuario.
Otro tipo de té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 técnicas
persiguen reducir la complejidad geométrica de la escena mediante el reemplazo
partes de la misma por imágenes bidimensionales generadas por el servidor. No
obstante, determinar qué 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 técnicas de visualización de gráficos
3D en dispositivos mó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 más importantes publicadas en la literatura
actual.
Innovación y la Eunión Europea (fondos FEDER) a través del proyecto TIN2011-25259, y la Universidad de Jaén a través del proyecto de investigación UJA2010/13/08, financiado por Caja Rural
de Jaén.
Referencias
1. Tomas Akenine-Möller and Jacob Ström. Graphics for the masses: a hardware rasterization
architecture for mobile phones. ACM Transactions on Graphics, 22:801–808, 2003.
2. Tomas Akenine-Möller and Jacob Strö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.
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
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.
Jsr 239: Java binding for the opengles api.
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, Gé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 Gaitán, Miguel Escrivá, 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
26. Javier Lluch, Rafael Gaitán, Emilio Camahort, and Roberto Vivó. 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
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 André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.
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 visualización de entornos urbanos
con WebGL y X3DOM
Resumen La visualización e interacción con grandes escenas urbanas en una aplicación web es un problema complejo para entornos urbanos tridimensionales. En
este capı́tulo se propone un prototipo para visualizar un modelo urbano a través de
una arquitectura cliente-servidor usando software libre como WebGL y X3DOM.
El sistema desarrollado permite además que los usuarios puedan navegar libremente por la escena y obtengan información adicional sobre los edificios o el mobiliario
urbano. Para conseguir este objetivo, se ha diseñado una base de datos geo-espacial,
implementada en MySQL que almacena información temática y geométrica sobre
el entorno urbano. La comunicación entre la base de datos y el modelo X3D para
obtener la información adicional se realiza utilizando Ajax.
1.
Introducción
El modelado 3D de ciudades (3DCM, 3D City Modeling) tiene un amplio rango
de aplicaciones en ingenierı́a, construcción o arquitectura. Evidentemente, la disponibilidad de estas aplicaciones a travé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 tamaño de una ciudad es demasiado grande para ser transmitido a través de un
sistema cliente-servidor, especialmente cuando se genera a partir de los datos de un
sistema de información geográfica (SIG) real. Por tanto, es necesario un proceso de
simplificación para reducir el tamaño de la escena y mejorar el rendimiento. Para
ello podrı́an utilizarse técnicas de niveles de detalle (LOD) o un método de oclusión.
215
216
Otro aspecto importante en este tipo de aplicaciones es la interacción con los
elementos urbanos para obtener información adicional, que podrı́a estar almacenada
bien en una base de datos o bien en los propios modelos. La primera opción es más
flexible puesto que permite modificar la información sin tener que alterar el modelo
urbano.
Evidentemente, el lenguaje de visualización es un aspecto fundamental en cualquier aplicación web, puesto que debe cumplir los requerimientos descritos anteriormente. En la actualidad existen algunas herramientas como, por ejemplo, el estándar
ISO X3D [1] para visualizar archivos 3D en Internet. Sin embargo, este lenguaje
requiere la instalación de un plugin en el navegador. Para evitar este problema, actualmente se están desarrollando nuevas tecnologı́as como WebGL y X3DOM que
pueden visualizar un modelo 3D en una página web sin instalar ningún programa
adicional.
WebGL is un nuevo estándar para visualización de gráficos 3D en Internet que se
complementa con otras tecnologı́as como el futuro estándar HTML5 [2]. X3DOM,
por su parte, es una librerı́a [7] que permite la integración directa de la escena
X3D en la estructura DOM (Document Object Model) de HTML5. Por tanto, el
uso de X3DOM permite la visualización directa de la escena en un navegador web,
insertando directamente la representación del mundo virtual en el código HTML.
X3DOM se está utilizando actualmente en diferentes proyectos [3, 4].
En este capı́tulo se propone una aplicación web para navegación e interacción
con entornos urbanos usando X3DOM y Ajax [5]. Se ha diseñado además una base
de datos para almacenar la información geométrica y temática de los elementos de
la escena [6]. Ası́, los usuarios pueden navegar libremente por la escena virtual y obtener información adicional sobre los edificios o el mobiliario urbano simplemente
pulsando sobre ellos.
2.
Implementación de la aplicación
A continuación se describen las principales caracterı́sticas del prototipo diseñado
para gestionar y visualizar la información urbana a travé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 información.
2.1.
Descripción
El sistema desarrollado permite tanto la visualización como la gestión y almacenamiento de datos urbanos 3D. En concreto, el método está enfocado principalmente
a la visualización realista, la reducción de la geometrı́a, la navegación peatonal libre
en la escena y la interacción con los edificios para obtener nuevos datos sobre ellos.
Sistema de visualización de entornos urbanos con WebGL y X3DOM
217
Fig. 1 Esquema general de la aplicación
El proceso se resume en la Figura 1, que muestra que la información almacenada
en la base de datos se obtiene a través de un Sistema de Información Geográfica
(SIG) 2D. La interconexión entre el SIG 2D y la base de datos se realiza mediante
un módulo java, que utiliza el patrón DAO (Data Access Object) para transmitir
la información. En cuanto a la generación de los modelos X3D de los edificios, se
realiza mediante otra función java que obtiene la informació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 serán también almacenados en la base de datos, de forma
que puedan ser reutilizados para generar el modelo final que se visualizará en la
página web. Los usuarios pueden además moverse libremente por toda la escena y
obtener nuevos datos sobre los edificios. Este proceso se describe con más detalle
en la Sección 3. Seguidamente se describen las caracterı́sticas más importantes de
la base de datos geo-espacial.
2.2.
Base de datos geo-espacial
La base de datos de la aplicación que se está describiendo debe almacenar tanto información geométrica como alfanumérica de las diferentes entidades urbanas.
Entre los opciones disponibles, se decidió utilizar MySQL puesto que es software libre y permite establecer una conexión entre PHP y otras tecnologı́as web. A
continuación se describen las tablas má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. Además de la planta,
se dispone también de la altura del edificio, por lo que la generación del modelo
2.5D asociado puede realizarse de forma inmediata. Respecto a los datos temáticos,
se dispone también de información significativa relacionada con los edificios como
una breve descripción, horarios de apertura, servicios, etc. Gracias a esta estructura,
es posible combinar en una única consulta criterios geométricos y temáticos. Por
218
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 más cercanos a
un punto o los edificios más antiguos de la ciudad.
Además de los edificios, un elemento fundamental en cualquier ciudad es el mobiliario urbano. Sin embargo, su gestió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: código único de identificación, descripción, URL del archivo X3D,
punto que indica la posición donde se ubica y dirección de la calle. El resto de información especı́fica que depende de cada categorı́a en particular se almacena en tablas
independientes. De esta forma, gracias a este diseño el sistema puede ser fácilmente
extensible, puesto que el manejo de nuevas entidades requiere únicamente la inclusión de una nueva tabla en la base de datos. Actualmente se han considerado tres
tablas: paradas de autobús, farolas y buzones. En el caso de las paradas de autobús
se han incluido datos relativos a las rutas y horarios.
2.3.
Generación de la escena X3D
Debido al tamaño de las ciudades, no es posible realizar un proceso de modelado
manual de todos los edificios. Por esta razón, en este capı́tulo se propone un método
que permite crear de forma automá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 través de
una consulta a la base de datos. En concreto, se ha implementado un módulo java
que permite crear todas las caras del modelo X3D de un edificio usando el nodo
219
IndexedFaceSet, que posteriormente se visualizará usando WebGL y X3DOM. En
general, WebGL muestra correctamente cualquier nodo de geometrı́a de X3D.
Sin embargo, la dimensión de la escena generada utilizando este procedimiento
podrı́a causar problemas durante el proceso de visualización utilizando un navegador WebGL. Por ello, es necesario un método que disminuya el tamaño y la complejidad del modelo. Para este propósito podrı́an usarse herramientas como impostores
[8] o técnicas de simplificación dependientes del punto de vista [9].
En la aplicación desarrollada se utilizan niveles de detalle, que son directamente
soportados por X3D. Este tipo de nodo permite que un modelo pueda tener múltiples
representaciones incluyendo versiones en alta resolución (cuando los usuarios están
más cerca) o baja resolución (cuando se observan a una distancia mayor). Por tanto,
este tipo de té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 más
elaborado, que será visible cuando el usuario esté situado a una distancia inferior a
500 metros. En el caso de que el usuario esté entre 500 y 1000 metros de distancia,
se visualizará el modelo de las manzanas. Finalmente, para una distancia mayor,
no se mostrará ningún modelo. Gracias a que únicamente se visualizan los edificios
má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 automática la geometrı́a urbana, a continuación se describe el proceso de interacción con los edificios
y el mobiliario urbano.
3.
Interacción con los elementos urbanos usando X3DOM
La interacción entre aplicaciones web y bases de datos geo-espaciales para permitir una interacción en tiempo real es un reto importante para los sistemas de información urbana tridimensionales. En este capı́tulo se propone un prototipo basado en una arquitectura cliente-servidor en el que el cliente visualiza e interactúa
con el mundo urbano virtual, mientras que el servidor proporciona la información
geométrica y temática. La aplicación se ha implementado utilizando software libre
como WebGL, X3DOM, MySQL y Ajax. A continuación se describe el proceso para obtener y visualizar la informació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 interacción del usuario. Ası́, cuando éste pulsa sobre ellos utilizando el
ratón, se genera una consulta a la base de datos para obtener la información asociada,
que se mostrará 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 autobús o los horarios
de apertura de una tienda.
220
Para implementar esta funcionalidad es necesario crear una función que controle
los eventos. Al contrario que con la geometrı́a, la gestión de eventos en X3DOM es
generalmente distinta a la de X3D. Por ejemplo, en X3D para controlar la pulsación
con el ratón sobre un modelo se debe usar un tipo especial de nodo denominado sensor de toque (touch sensor). Este nodo genera el evento de pulsación (clicking), que
puede ser enviado a otros nodos mediante la utilizació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 acción de pulsar con el rató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 diseñado se utiliza la tecnologı́a Ajax y PHP para conseguir este propó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 creación de interfaces dinámicas en las páginas web. En la aplicación desarrollada en este trabajo, Ajax obtiene la información adicional sobre los
edificios o el mobiliario urbano utilizando código PHP.
Finalmente, una vez finalizado todo el proceso descrito anteriormente, la aplicación visualiza la informació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 información adicional sobre algunos elementos urbanos, tal y como
se puede observar en la Figura 3. En este ejemplo, se muestra una ventana con
información sobre los horarios de apertura de un edificio, obtenida tras pulsar sobre
el modelo 3D del edificio.
En cuanto a la visualización gráfica, en las Figuras 4 y 5 se puede observar que
se ha generado una escena realista en la que se permite la navegación tanto peatonal
como en modo vuelo. Para texturizar los modelos de los edificios se han utilizado
fotografı́as reales de la ciudad de Jaén. Gracias al uso de técnicas de niveles de detalle la carga de datos se reduce significativamente, puesto que inicialmente sólo se
visualizan los modelos más sencillos y sólo se descarga el modelo real (más complejo) cuando los usuarios están cerca del edificio. Por lo tanto, se puede concluir que
este tipo de herramientas permiten mejorar el tiempo de respuesta y la interacción
con la escena.
221
Fig. 3 Información adicional sobre horarios de apertura
5.
En este capı́tulo se ha descrito un prototipo de una aplicació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 información temática y geométrica sobre los diferentes elementos urbanos. La aplicación
desarrollada es interactiva, puesto que los usuarios pueden obtener información adicional sobre las entidades de la escena simplemente pulsando sobre ellas durante el
proceso de navegación. El movimiento de los usuarios no está predeterminado, por
lo que éstos pueden moverse libremente por todo el modelo urbano.
El sistema propuesto puede ser usado en diferentes campos de aplicación como, por ejemplo, portales turı́sticos, aplicaciones de ingenierı́a y construcción, etc.
Además, es fácilmente extensible, ya que se pueden generar nuevos elementos in-
222
Fig. 4 Perspectiva aérea de la aplicación
Fig. 5 Perspectiva peatonal de la aplicación
teractivos mediante la inclusión de nuevos datos en la base de datos y la creació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 técnica, inicialmente sólo se
visualizan los edificios más cercanos. No obstante, en trabajos futuros, se pretende utilizar un método de oclusión para determinar de forma exacta el conjunto de
edificios visibles desde una posición del observador, lo que permitirı́a mejorar el
rendimiento final de la aplicación.
Agradecimientos Este trabajo ha sido parcialmente subvencionado por el Ministerio de Ciencia
e Innovación y la Unión Europea a través de los fondos FEDER bajo el proyecto de investigación
TIN2011-25259 y por la Universidad de Jaén bajo el proyecto UJA2010/13/08 subvencionado por
Caja Rural de Jaén.
Referencias
1. W3C ISO/IEC 19775:2004 - Extensible 3D, X3D (2004)
2. Marrin, C. WebGL Specification Khronos WebGL Working Group (2011)
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. & Gonzá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. & Zöllner, M. X3DOM: a DOM-based HTML5/X3D integration
model Proceedings of the 14th International Conference on 3D Web Technology, ACM, 127135 (2009)
8. Andú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 López Estrella, Marı́a Dolores Robles Ortega y Lidia Ortega Alvarado
Resumen Los SIG y la visualización tridimensional son utilizados cada vez en un
mayor número de áreas. Por otro lado, la popularización de Internet hace que la
sociedad tenga cada vez más acceso a todo tipo de datos, entre ellos, información
geográfica. La mayorı́a de empresas y profesionales autónomos está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 aplicación web interactiva
con algunas capacidades SIG que permita la obtención de información empresarial
y la navegación en 2.5D en un entorno urbano. De esta forma, a través de un navegador Web, el usuario podrá buscar los distintos comercios de la ciudad clasificados
por categorı́as, obtener información de ellos y localizarlos visualmente a distintos
niveles de detalle.
1.
Introducción
Un Sistema de Información Geográfica (SIG) se puede definir como la unión
de un conjunto de elementos, herramientas y utilidades que almacenan y manejan
información referenciada espacialmente; es decir, información que tiene asociada
una posición determinada en el espacio. Dicha posición vendrá definida por unas
coordenadas X e Y concretas, en el caso de estar utilizando una representación bidimensional.
Ana Ma López Estrella
Universidad de Jaén, Campus Las Lagunillas s/n, 23071 - Jaén e-mail: [email protected]
Ma Dolores Robles Ortega
227
228
Por lo general, los SIG ofrecen potentes capacidades de análisis y edición de
datos espaciales, lo que los hace muy útiles en diferentes ámbitos. Pero ademá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 análisis como de
visualización, mostrando los datos en mapas organizados en diferentes capas.
Sin embargo, hoy en dı́a estamos asistiendo a un importante cambio. En los últimos años, el 3D se ha ido abriendo paso en áreas como el cine, los videojuegos, la
televisión e incluso la telefonı́a móvil. Presentar un mundo virtual en tres dimensiones acerca al usuario a una representación mucho más realista de su entorno. Pero
esta inclusión de la tercera coordenada en las aplicaciones gráficas, y sobre todo
en los SIGs, no es algo trivial y, aunque está prácticamente resuelto a nivel de visualización y modelado, todavı́a encontramos muchos problemas en lo referente al
análisis espacial e interacción [2].
Otro aspecto importante en lo que respecta a las tecnologı́as de la información
es la Web. El acceso a Internet está disponible cada vez en una mayor variedad de
dispositivos y a un coste menor, por lo que su uso se extiende de manera rápida. Por
esta razón, no es de extrañar que los comercios y empresas que ofrecen servicios
públicos estén interesadas en aparecer en tantos portales web como les sea posible,
ya que de esta manera pueden darse a conocer de una manera rápida y cómoda,
llegando ası́ a clientes que jamás sabrı́an de su existencia si no fuese por ello.
La posibilidad de acceder a Internet a través de banda ancha hace que una gran
cantidad de aplicaciones cuya implementación a través de la Web era impensable
antes, ahora sea posible. Este hecho, junto con el auge que en los últimos años
está teniendo el 3D, da lugar a la aparición de la llamada Web 3D, término que se
refiere a toda aquella aplicación accesible desde un navegador que ofrece la posibilidad de visualizar y en ocasiones interactuar con gráficos en tres dimensiones para
cumplir diferentes finalidades (tiendas virtuales, museos interactivos, etc.).
Se obtienen ideas interesantes al integrar todos los términos y tecnologı́as que
acabamos de ver. Los SIG y la visualización tridimensional son utilizados cada vez
en un mayor número de áreas. Parece lógico por tanto que, aunque algunas tareas
no estén del todo resueltas, ambos aspectos traten de unirse, dando lugar a los denominados SIG 3D. Además, la popularización de Internet hace que la sociedad tenga
cada vez más acceso a todo tipo de datos, entre ellos, información geográfica. Hoy
en dı́a existe una gran cantidad de aplicaciones disponibles a través de la red que
manejan datos georreferenciados, ya sea de ciudades, comercios, etc. El ejemplo
más famoso y conocido por todos es Google Maps. Ya que la forma más sencilla y
utilizada hoy en dı́a para buscar cualquier tipo de información es recurrir al acceso
a Internet, la mayorı́a de empresas y profesionales autónomos está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 sólo beneficia a los empresarios y comerciantes, sino también a
quien busca dichos servicios. Hoy en dı́a cuando una persona necesita algo concreto
pero no sabe dónde encontrarlo, lo primero que hace es realizar una consulta en un
buscador. Sin embargo el usuario no estará sólo interesado en conocer el nombre del
lugar al que ha de ir, sino también su localización. Y si además de indicársele la di-
SIG urbanos en 3D para aplicaciones comerciales
229
rección, ésta viene acompañada con un mapa donde pueda verse de manera visual la
ubicación, entonces el usuario podrá escoger el comercio que más le convenga segú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 visualización de este entorno urbano a una distancia más
cercana y en tres dimensiones podrı́a proporcionar una mayor claridad a la hora de
interpretar el territorio que se está visualizando y de distinguir los diferentes puntos
de interés. Al ser más realista, este tipo de representación harı́a que el usuario reconociese mejor la zona a la que se está accediendo, ya que también podrı́a distinguir
los edificios que la componen, tal y como si estuviera en la ubicació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 aplicación web datos espaciales procedentes de cualquier entorno
urbano y su mundo empresarial, representando dicha información en tres dimensiones de manera que se le permita al usuario una visualización más intuitiva, realista
y atractiva de la realidad que en el caso de los entornos bidimensionales.
De esta forma se obtendrá un prototipo de un Sistema de Información Geográfica que permita la obtención de información empresarial y la navegación en 2.5D
(término que será definido más adelante) en un entorno urbano con el fin de que,
a través de un navegador web, el usuario pueda buscar los distintos comercios de
la ciudad clasificados por categorı́as, obtener información de ellos y localizarlos
visualmente a distintos niveles de detalle.
2.
Conceptos previos
El propósito que acabamos de definir se relaciona con varios conceptos (el 3D,
la Web, la representación de entornos urbanos, etc.), y los une con el fin de crear
una aplicación que trabaje como un buscador de comercios que no sólo proporcione
información de los servicios concretos que éstos prestan, sino también su localización. En el presente apartado se hará un breve repaso a la situació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 Información Geográfica cumplen un importante papel
en multitud de campos: planificación urbana y gestión territorial, medioambiente,
equipamiento social, marketing geográfico, transporte y tráfico, gestión de infraestructuras, censos, catastros e incluso se pueden aplicar a la enseñanza [4]. En ocasiones las necesidades que se pretenden cubrir con ellos requieren que éstos sean
230
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 razó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 visualización tridimensional está siendo incorporada a todo tipo de dispositivos. Para representar una
escena en 3D es necesario llevar a cabo el proceso de modelado. En ocasiones, éste
será manual, en otras, se requiere que sea automático. Mientras que los entornos
ficticios suelen ser inventados y creados a mano, la representación virtual de localizaciones reales necesita captar la geometrı́a para poder copiar la realidad de la
forma más fideligna posible. Durante años de investigación se han propuesto muchos métodos para conseguir hacer esto de la manera más automatizada posible.
Las técnicas más estudiadas hasta ahora tratan de construir la escena partiendo de
imágenes [23, 21, 3]. Sin embargo, este método impone muchas restricciones, ya
que la información que dichas imágenes proporcionan es insuficiente para construir
un entorno realmente representativo. Estudios recientes optan por utilizar escáneres
lá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
técnica se conoce como LIDAR. El uso de estos escá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 incrementándose la oferta en el mercado de la funcionalidad del 3D,
también va surgiendo la necesidad de llevar a cabo diferentes actividades teniendo
en cuenta la tercera dimensión: planificación urbana [12], actividades relacionadas con el catastro [20], monitorización medioambiental, etc. Aunque hace bastante
tiempo que la unión de los SIGs con la visualización en 3D empezó a plantearse, el
nivel de éxito que se ha alcanzado en ello es todavı́a muy débil. Las tareas que actualmente soporta un SIG 2D son: la captura, estructuración, manipulación, análisis
231
y presentación de datos [19]. Con la investigación en el campo de los Sistemas de
Información geográ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 éstos
se muestran eficientes en lo referente a la visualización, su funcionalidad en términos de estructuración, manipulación, interacción y análisis de datos 3D está todavı́a
en fase de investigación.
Fig. 1 Ejemplo de ciudad 3D generada por MapInfo
Más adelante, otro estudio parecido realizado por los mismos autores [25] muestra los beneficios que conllevarı́a la estandarización de una estructura de datos espacial. Ası́ pues, un aspecto importante a la hora de hacer progresos en estos puntos
débiles es la elección de un modelo topoló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] enfocó 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 más tarde desarrolló una
estructura propia denominada Tetrahedron Network (TEN). Otros autores proponen
modelos orientados a objetos como [15] y [1]. Cada una de estos modelos de representación propuestos tienen sus ventajas e inconvenientes; sin embargo, aún no se
ha llegado a ningún consenso en este tema.
232
2.4.
La Web 3D
Además de todo lo expuesto anteriormente, cuando lo que se quiere es integrar el
3D dentro de una aplicación web, es importante tener en cuenta no sólo la cantidad
de datos sobre la geometrı́a que se va a transmitir del cliente al servidor (problema
que no está del todo resuelto a pesar de la rapidez de las conexiones de hoy en dı́a),
sino también el tiempo que le llevará a la máquina cliente procesar la información
para poder mostrarla finalmente. Además de mantener la geometrı́a de los elementos
de la escena en estructuras de datos especiales para optimizar esta tarea, existen diversas técnicas que se pueden implementar para mejorar la interacción. Una de ellas
es mantener la información dividida en diferentes niveles de detalle (LOD, Level
Of Detail) para agilizar el proceso de visualización. De esta forma, en un entorno
3D que permita la navegación, se irá extrayendo de manera progresiva información
geométrica más detallada sólo de aquellas partes de la escena a las que el observador
o la cámara se vaya acercando, simplificando la geometrı́a de las partes que quedan
alejadas [8] [10].
Otra manera de agilizar el proceso de visualización de gráficos es la llamada
representación en 2.5D. Se trata de una simplificació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 sensación
tridimensional (Fig. 2).
Fig. 2 Extrusión de un rectángulo con Google SketchUp.
233
Fig. 3 Modelo de la Catedral de Jaén en Google Earth
2.5.
Entornos urbanos 3D: Investigación y ejemplos de
aplicaciones reales
Como se ha mencionado antes, mientras que la manipulación y el análisis de
datos geográficos se encuentran todavı́a en fase de investigación, la visualizació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, también
en la representación y modelado de entornos urbanos en concreto. Un ejemplo de
ello es City Engine, un software avanzado para la creación de ciudades en 3D.
Además de esto, la investigación sigue adelante para conseguir todas las capacidades de los SIG en tres dimensiones. Existen multitud de trabajos dedicados al
estudio de la generación de entornos urbanos; por ejemplo, Moser recoge una visión
general de las capacidades de análisis de los SIG 3D para el modelado de ciudades
virtuales en [17].
También existen estudios que orientan esta creació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 realización de consultas y la
visualización a través de la red, generando de manera semi-automática los edificios
y objetos tridimensionales. Coors [7] propone tambié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 través de Internet. Por último, Cheng et al. en [6] describe un modelo multi-escala junto con un
sistema web de consulta para la localización de edificios 3D compuesto por cuatro
niveles de detalle diferentes: modelo de bloque, modelo de textura genérica, modelo
foto-realista económico y modelo foto-realista detallado.
Como se mencionó en la introducción, una de las aplicaciones interesantes de
los SIG es la representación de entornos urbanos y la localización de servicios al
público dentro de dichos entornos. A la hora de buscar sitios web que proporcionen
234
datos geográficos de ciudades y actúen como buscadores de empresas y comercios
en ellas, podemos encontrar varios ejemplos, como MapQuest, Páginas Amarillas o,
el más conocido hoy en dı́a, Google Maps. Sin embargo, ninguna de ella por sı́ sola proporciona representaciones tridimensionales de los datos geográficos con los
que trabaja. Podemos decir que la aplicación que ha llevado más lejos la unió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 aplicación de Google intenta obtener modelos de ciudades enteras tridimensionales. También se ha añ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,
aún no existe ninguna aplicación que genere los edificios de un entorno urbano en
tres dimensiones de forma automática y localice, en su interior y por plantas, los
comercios que se encuentran en él.
3.
Metodologı́a
Tal y como se mencionó en la sección de introducción, nuestro principal objetivo
es proporcionar un método semiautomá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 aplicació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 obtención
de este prototipo. Los principales requerimientos funcionales que se van a tener en
cuenta son:
1. El prototipo debe proporcionar la visualización del entorno urbano a diferentes
niveles de detalle (LOD): plano, manzanas y edificio. La transición de un nivel
de detalle a otro se realizará en relación con una empresa que el usuario haya
seleccionado previamente. Es decir, en un principo, el SIG mostrará el entorno
urbano en su nivel de detalle más alejado (el plano). Para pasar al siguiente nivel (manzanas) el usuario deberá seleccionar una empresa o comercio concreto
obteniendo ası́ sólo su entorno más cercano de forma más detallada. Al pasar al
siguiente LOD, aparecerá únicamente el edificio al que pertenezca la empresa
seleccionada.
2. La navegación (al menos a nivel de zoom, desplazamiento y rotació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. Además de la localización, la aplicación debe proporcionar al usuario alguna
información más sobre el comercio que éste seleccione.
235
5. Parte de la información sobre los comercios que mantiene el prototipo debe poder ser modificada y actualizada por los empresarios. Para ello se crearán dos
perfiles de usuario: uno básico al que podrá acceder cualquier persona que desee
localizar comercios o servicios, y otro de empresario que le permitirá a éste, una
vez identificado en el sistema, modificar algunos de los datos sobre su empresa.
Además, se van a tener el cuenta los siguientes requerimientos no funcionales:
1. El sistema debe responder en tiempo real ante cualquier interacción del usuario,
independientemente del tipo de conexión a Internet que éste posea, siempre y
cuando se encuentre dentro de unos lı́mites razonables.
2. El sistema debe ser accesible desde cualquier máquina remota que disponga de
un navegador web sencillo y conexión a Internet, sin necesidad de ningún software adicional.
3. La interfaz debe ser intuitiva y usable de manera que ésta no suponga un problema a la hora de que un usuario utilice la aplicación por primera vez.
Señalaremos que el entorno para el que se desarrollará este prototipo será el
marco urbano de la ciudad de Jaén.
A grandes rasgos, el proceso general de desarrollo será el siguiente: el tratamiento de los datos espaciales para adaptar la información de la que se dispone a nuestras
necesidades se realizará utilizando MapInfo. Una vez hecho esto, los datos temáticos que se hayan obtenido se migrarán a una base de datos previamente diseñada (se
utilizará MySQL). A ellos se accederá desde el modelo (implementado utilizando
Java, JSP y Servlet), a través de JDBC, para obtener la información que se desee
en cada momento. Los gráficos serán implementados utilizando O3D. La geometrı́a
real en 2D de edificios y manzanas será obtenida de los ficheros .MIF y .MID que
proporciona MapInfo. A partir de ella, se obtendrá el modelo en 2.5D mediante
extrusión.
En los siguientes apartados se explica más detenidamente dicho proceso.
3.1.
Diseño de la base de datos
En esta sección se va a describir la estructura que debe tener la base de datos
que manejará la informació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 información georreferenciada y la geometrı́a
en 2D de las plantas de los edificios, manzanas y portales. Además también nos
aporta otros datos de interés tales como la altura y el número de plantas de cada
edificio o el nombre de las calles. Por otro lado, la Cámara de Comercio de Jaén nos
proporciona la base de datos empresarial, en la que cada empresa y comercio viene
indicada junto su la dirección postal.
En este caso concreto, basándonos en la descripción de funcionalidades que la
aplicación debe cumplir, y a pesar de que estamos tratando de obtener un prototipo
236
Fig. 4 Esquema conceptual de la base de datos del prototipo
que guarda una relación estrecha con los Sistemas de Información Geográfica, no se
ha considerado necesario utilizar una base de datos espacial. La razó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 dará soporte a nuestro sistema
queda como se muestra en la Figura 4.
Como refleja la estructura de nuestra base de datos, cada empresa estará ubicada en un portal (R3), cada portal está situado en un edificio (R4) y a su vez éste
pertenecerá 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, prá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 único que necesitamos es saber a qué portal pertenece cada empresa, a qué edificio pertenece cada portal y a qué manzana pertenece cada edificio, información que
237
nos viene dada en los datos de los que disponemos. Por lo tanto, no será necesario
obtenerla mediante operaciones espaciales de inclusión ni de ningún otro tipo.
Por otro lado recordemos que, al seleccionar una empresa concreta, la aplicación
debe pasar a un segundo nivel de detalle en el que se visualicen las manzanas más
cercanas a la empresa seleccionada, lo que, en un principio, supondrı́a el cálculo de
áreas de influencia o de la distancia del edificio donde se encuentra el comercio a
todas las manzanas para seleccionar las más cercanas. Sin embargo, debido al gran
volumen de datos con los que se trabajará, realizar esta tarea puede llevar demasiado
tiempo, limitando ası́ la capacidad de interacción con el usuario. Por esta razón realizaremos un preprocesamiento y almacenaremos las cinco manzanas más cercanas
a cada una de las empresas (relación R6).
Aunque en la base de datos no almacenaremos la información espacial de las
entidades, sı́ tendremos distribuidas en ficheros las coordenadas y la geometrı́a de
manzanas y edificios para su posterior visualización. Los datos espaciales de estas
entidades y de los portales están a nuestra disposición gracias a la Oficina Virtual
del Catastro. Sin embargo, en los datos que poseemos de las empresas la única información que tenemos acerca de su ubicación es su dirección. Por esta razón debemos
realizar un proceso de geocodificación (que será explicado en la siguiente secció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.
Geocodificación de las empresas
Cuando nos enfrentamos ante un problema relacionado con los Sistemas de Información Geográfica, en ocasiones, los datos de los que disponemos son simplemente
datos temáticos, y, aunque frecuentemente tenemos la dirección de las entidades,
éstas no tienen asociadas ningú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 información geográfica referente a las empresas. Los únicos datos que
tenemos sobre su situación son la dirección de cada uno de ellos. Por tanto, para obtener sus coordenadas automáticamente y poder ubicarlas el lugar correspondiente
dentro del plano de Jaén, debemos realizar un proceso previo de geocodificación.
Geocodificar una tabla de entidades en una base de datos es básicamente asignar
coordenadas X e Y a cada registro; es decir, calcular la localización de cada uno de
ellos en la superficie sobre la que se está trabajando.
Zandbergen [24] realiza un estudio comparativo de las diferentes técnicas de geocodificación. Sin embargo, únicamente menciona cómo localizar las entidades en un
entorno bidimensional. Serı́a interesante realizar este proceso de ubicación considerando las diferentes plantas de los edificios, puesto que en muchas ocasiones en los
entornos urbanos se sitúan servicios como consultas privadas de médicos o abogados que se encuentran no sólo en los locales de las plantas bajas, sino también en
238
pisos más altos. Además, existen también edificios completos dedicados únicamente
a albergar empresas.
Uno de los métodos para realizar el proceso de geocodificación utiliza las direcciones postales de las entidades a situar: calle, número, código postal, zona (paı́s,
ciudad...), etc. Las calles tienen nombres únicos dentro de zonas concretas, y las
zonas tienen nombres únicos dentro de determinadas regiones. Además, se utilizan
los códigos postales, que están ordenados jerárquicamente asignando los primeros
caracteres a zonas grandes y los siguientes a áreas más pequeñas dentro de éstas.
Atendiendo a esto, la dirección postal de una entidad es útil para poder georreferenciarla.
Una de las maneras en las que se suele realizar el proceso de geocodificación es
mediante el emparejamiento de información geográfica disponible en otras tablas
con la información que necesitamos situar en el mapa. Por esta razón, para poder
geocodificar una lista de entidades, es necesario disponer al menos de otra tabla que
tenga asociada información espacial al mismo nivel de detalle que necesitamos llegar con la geocodificación. En ocasiones, este proceso puede resultar difı́cil debido
a la amplia variedad de términos y abreviaturas diferentes con las que identificar
una dirección concreta. Otras veces, cuando no se dispone de información real para
emparejar, la geocodificación se puede realizar estimando las coordenadas X e Y
del punto concreto mediante interpolación, localizando en la capa de las calles el
punto en el lugar más aproximado a la realidad según los algoritmos utilizados.
En el caso del prototipo que se pretende desarrollar, disponemos de una serie de
comercios de los que sólo conocemos su dirección escrita, y necesitamos asignarles
unas coordenadas X e Y que nos permitan situarlos fı́sicamente sobre un mapa para
desarrollar nuestro SIG. La dirección incluye la calle, el número de portal, la planta
y la puerta. Por otra parte, como ya se indicó, la oficina del Catastro nos proporciona
información espacial referente a calles y portales. No disponemos de información
referida a la distribución interna de cada edificio, por lo que la puerta tampoco podremos utilizarla en nuestra geolocalización. Por tanto, en un principio, llegaremos
al nivel de detalle de calle y número. Ésta será la información que utilizaremos para
nuestro proceso. De esta forma, teniendo situados sobre un mapa los portales, y conociendo en qué portal está situado cada comercio, podremos geocodificar a nivel
de portal.
Aunque no es nuestro caso, en ocasiones tendremos que tener en cuenta que
puede haber información ambigua. Por ejemplo, si estuvié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 más de un par de coordenadas X e Y. En este caso, a la hora de
geocodificar se deberı́a incluir además un campo que indique la ciudad a la que se
refiere cada tabla (los comercios y la información espacial), como el có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 geocodificación, como la API de Google o de Yahoo [14]. Concretamente, para el desarrollo de este
prototipo se ha utilizado la herramienta de geocodificación de MapInfo.
3.2.1.
239
Proceso de geocodificació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, además tienen asociados una serie de datos temáticos
entre los cuales se encuentran la calle y el número. Además, tenemos la base de
datos de comercios, que nos proporciona, entre otras cosas, información acerca de
la dirección postal de cada uno de ellos. Por tanto, para realizar el proceso de geocodificación, utilizando MapInfo trataremos de emparejar los campos de dirección
de ambas tablas, asignando ası́ a cada comercio las coordenadas X e Y del portal
cuya direcció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 número de portal. Sin embargo, MapInfo tiene en cuenta
un sólo campo a la hora de realizar el proceso. Por tanto, para poder llevar a cabo la
operación será necesario que en ambas tablas exista un campo único que contenga
la dirección entera (calle y número de portal) para que podamos indicarle a MapInfo
que ejecute el proceso a partir de dicho campo.
Una vez unificados en un sólo atributo la calle y el número de portal, comenzamos el proceso de geocodificación, disponible en MapInfo en el menú Tabla.
Aparece entonces un cuadro de diálogo como el que se muestra en la Figura 5.
Fig. 5 Inicio del proceso de geocodificació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 información espacial que utilizaremos para emparejar el campo dirección y
asignar coordenadas X e Y a los comercios (Portales01), y el campo de esta última
240
tabla que se utilizará (Calle Numero). Además también se puede escoger un campo
que indique la región en la que se geocodificará (que en nuestro caso no es necesario) y la opción de geocodificar de manera interactiva en lugar de automática. Para
comenzar se intentará hacer de manera automática. Una vez rellenado el cuadro de
diálogo, al aceptar, MapInfo muestra los resultados obtenidos (ver Figura 6).
Fig. 6 Resultados en el primer intento de Geocodificació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 está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 única calle en dos tablas diferentes.
Como podemos observar, en la tabla de Comercios la dirección está expresada
con una abreviatura (CL) seguida del nombre de la calle y el número. Sin embargo,
en la tabla de portales tenemos la palabra completa “Calle” seguida del resto de la
direcció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 mayúsculas y minúsculas, sin embargo, la dirección debe
coincidir letra por letra para que se asocie un comercio a una dirección concreta. Por
241
Fig. 8 Empresas geocodificadas sobre el mapa.
defecto, MapInfo asocia algunas abreviaturas a sus correspondientes palabras; sin
embargo, estas equivalencias están definidas únicamente en inglés. Esta es la razón
por la que, en un primer intento, no ha sido posible geocodificar ningún comercio.
Para solucionar este problema, MapInfo incluye un fichero de abreviaciones llamado MAPINFOW.ABB, donde están definidas las equivalencias por defecto que
acabamos de mencionar. El fichero es editable, por tanto, simplemente añadiendo
las abreviaciones que queramos que se tengan en cuenta para nuestro proceso de
geocodificación en el formato correcto, este problema deberı́a estar solucionado.
Otra forma de dar solució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 dirección puede estar
expresada de diferentes maneras, no só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 geocodificación en
MapInfo. Si en una tabla una dirección viene indicada como “Paseo de la Estación
45”, y en la otra tabla implicada viene expresada como “Paseo Estación 45”, el proceso automático de geocodificación no emparejará dichas direcciones. Sin embargo,
existe un modo interactivo de geolocalización en MapInfo que en ocasiones soluciona este tipo de problemas. Si marcamos la casilla de “Modo Interactivo” en lugar
de “Modo automático” en el cuadro de diálogo mostrado anteriormente, MapInfo
emparejará las coincidencias exactas y, cada vez que encuentre un registro con una
dirección que no consiga localizar en la tabla que contiene la información espacial,
se detendrá, dando a elegir al usuario entre un conjunto de opciones encontradas
que MapInfo considera similares.
242
Por tanto, la manera más usual de geocodificar es ejecutar primero el proceso
de manera automática para conseguir a priori encontrar todas las coincidencias posibles y, a continuació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 localización espacial de las empresas,
convirtié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.
Geocodificació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 están situados. Sin embargo, el objetivo de este capı́tulo
es desarrollar un prototipo de SIG que los sitúe también en escenas tridimensionales.
La geocodificación en tres dimensiones actualmente no está resuelta. Existen
estudios que proponen técnicas para ello. Por ejemplo, Lee desarrolla en [13] una
técnica de geocodificació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 é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 sólo en el interior de un edificio, sino a nivel de toda una zona urbana completa. Se hará para ello una aproximación a la geocodificación en tres dimensiones. En
nuestra base de datos de comercios, como se ha comentado al principio, disponemos
de la información del número de planta en que cada negocio está 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 aplicación
en tres dimensiones a una altura determinada dependiendo del nú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 visualizarán aglomeradas en el mismo punto
como ocurre si sólo se ubican atendiendo a coordenadas bidimensionales.
3.3.
Generación del modelo 3D
Para el desarrollo de este prototipo se pretende llevar a cabo una generación automática de los modelos tridimensionales; es decir, de las manzanas y los edificios
que se representarán nuestro entorno urbano. Para ello, se partirá de los datos espaciales proporcionados por la Oficina Virtual del Catastro, en formato de MapInfo.
243
A través de este software se pueden exportar los datos a un formato de intercambio
fácilmente interpretable. El formato MIF (MapInfo Interchange Format) es un formato versátil que asocia los datos temáticos a los elementos gráficos. Se trata de un
formato editable y relativamente fácil de generar y leer.
Las tablas espaciales en este formato constan de dos archivos: los gráficos están
almacenados en un archivo .MIF y los datos de texto se incluyen en un archivo
.MID. La estructura de este último es sencilla: una lı́nea por cada registro en la que
se representan los datos temáticos separados mediante un delimitador:
‘‘0000201VG3800S’’,‘‘00002’’,2
‘‘0000206VG3800S’’,‘‘00002’’,3
‘‘0000204VG3800S’’,‘‘00002’’,2
‘‘0000310VG3800S’’,‘‘00003’’,2
...
El archivo .MIF está formado por dos partes: una cabecera que contiene información como la versión de MapInfo, el juego de caracteres utilizado o los nombres
de las columnas y el tipo de los datos temáticos, y una secció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
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 información de
dos entidades diferentes. La palabra REGION indica que se trata de objetos compuestos por uno o más polı́gonos, según indique el número que le acompañ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 continuación, en el caso de una entidad Región el
fichero señala el número de pares de coordenadas por las que está compuesta dicha
entidad y, por ú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 temáticos asociados a
la primera región definida en el fichero .MIF, la segunda lı́nea a la segunda región,
etc.
Ası́, para la generació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 búsqueda en el archivo .MID de la clave de éste
llevando un contador para almacenar la posición en la que aparece y, a continuación, se ha buscado en el archivo .MIF la entidad espacial situada en dicha posició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 vendrá determinada por el número de pisos que contenga el edificio.
Esta manera de aproximar una representación en tres dimensiones se conoce como
2.5D. Se trata de realizar un barrido o extrusió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 implementación de gráficos 3D en la Web
Una adecuada elección de las tecnologı́as a utilizar durante el desarrollo del prototipo es esencial para el funcionamiento satisfactorio de éste. A continuación se
hace un breve repaso de algunos los lenguajes de programación, de descripció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 estándar ISO de
la Web que surgió en lo referente a la visualización en tres dimensiones. Para crear
una escena con este lenguaje de descripción sólo es necesario un editor de texto simple, aunque existen algunos con caracterı́sticas más especializadas que facilitan el
245
desarrollo (como por ejemplo VRMLPad). La visualización de los resultados requiere únicamente estar en disposición de un navegador y tener instalado un plugin sobre
él que actúe como visualizador (como Cortona o BSConctact). Aunque en VRML
muchas de las funciones básicas de una aplicación interactiva están ya implementadas (movimientos de cámara, etc.), su principal problema reside en la interactividad;
un archivo de gran tamaño con un modelo muy detallado verá bastantes restringidas
sus posibilidades de interacción.
X3D(eXtensible 3D): Surgió como una nueva versión de VRML cuyas principales novedades se centran fundamentalmente en la integración de VRML 2.0. con
XML. Con ello se pretendı́a, entre otras cosas, conseguir una mejor integració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 estándar en desuso en la actualidad.
El apoyo recibido por parte de grandes compañı́as hacia este lenguaje es escaso.
Ademá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 desarrolló Google para crear aplicaciones web con grá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 visualización sobre él. Este plugin
se comunica directamente con el hardware, por lo que la velocidad de renderizado
depende en gran medida de la tarjeta gráfica. A principios de mayo de 2010, pasado
un año de su presentación y después de varios meses sin noticias sobre los avances
de su proyecto O3D, Google anunció su decisión de cambiar la dirección de su proyecto para desarrollar una API que trabaje bajo lo que pretende convertirse en un
estándar de tecnologı́as para la visualización de gráficos 3D en la Web: WebGL.
WebGL: WebGL es una especificación estándar, manejada por el consorcio de
tecnologı́a Khronos Group, que permite representar gráficos 3D acelerados por
hardware en páginas Web. Se trata también, de una librerı́a escrita bajo JavaScript;
aunque en esta ocasión el lenguaje de script sirve como enlace para utilizar la implementación nativa de OpenGL ES 2.0. Para la representación de gráficos en 3D
WebGL utiliza el elemento canvas de HTML 5, por lo que no necesita la adición
de ningún plugin en el navegador. Una clara desventaja de esta opción es que en la
actualidad Internet Explorer no tiene intención de dar soporte a esta tecnologı́a.
XML-3D: Se trata de la tecnologı́a de visualización 3D para web cuyo nacimiento ha sido má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 está diseñado para ser integrado con las tecnologı́as estándares de W3C
como HTML, DOM y CSS entre otros. En la actualidad se encuentra en una fase
muy temprana de desarrollo.
246
3.4.1.
Elección de la tecnologı́a de implementación
La elección de la tecnologı́a de implementación de gráficos en la Web por la que
nos decantamos vino marcada por el momento en que se hizo la elección.
Se descartó 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 aún,
en una fase de desarrollo muy temprana y la documentación y ejemplos disponibles
es muy escasa, por lo que fue descartado también.
En cuanto a las dos tecnologı́as restantes, WebGL y O3D, cuando se comenzó a
implementar este prototipo, fueron varios los motivos que llevaron al descarte de
WebGL: en primer lugar, además de ser una tecnologı́a muy reciente de la cual apenas se encontraba documentación, aú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 parámetros. En Google Chrome ocurre algo similar, siendo diferente la
configuración dependiendo del sistema operativo utilizado. Internet Explorer, el navegador más utilizado no da soporte a WebGL. Además de estos problemas con los
navegadores, no todas las tarjetas gráficas eran compatibles con esta tecnologı́a. Las
tarjetas de Intel, por ejemplo, muy comunes sobre todo en ordenadores portátiles
con Windows, necesitan la instalación adicional de un software de renderizado de
Firefox, con el que los gráficos serı́an procesados por el procesador del computador
y no por la tarjeta gráfica, permitiendo ası́ el funcionamiento de aplicaciones con
WebGL, pero con un rendimiento muy bajo.
Todo esto, llevó a la elección de O3D como API para la implementación del prototipo. Sin embargo, hoy en dı́a el desarrollo de WebGL ha evolucionado de manera
my rápida. Todo apunta a que WebGL se convertirá en un futuro en el estándar por
excelencia para este tipo de aplicaciones. Se trata de una tecnologı́a apoyada por
la mayorı́a de las grandes compañı́as involucradas en el desarrollo Web, incluido
Google. Además no necesita la instalación de plugin alguno en el navegador. Por
todo ello la mejor elección en la actualidad serı́a WebGL.
4.
Resultados
El proceso descrito en la sección anterior nos lleva a la obtención del prototipo
que fue planteado al comienzo del capı́tulo:
El prototipo proporciona la visualización del entorno urbano de Jaén en tres niveles de detalle diferentes.
El zoom y el desplazamiento y rotación de la escena son posibles en cualquier
parte del entorno urbano.
El prototipo proporciona la búsqueda de empresas por categorı́a en todo el entorno urbano.
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, además de la ubicación de los
comercios, información más detallada sobre ellos.
Parte de la informació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
La Figura 9 presenta el aspecto inicial del prototipo web. En él aparece, a la
izquierda, el apartado de login para el empresario; en el centro, el plano de la ciudad
de Jaén y el panel de navegación; y a la derecha, el listado de categorı́as además de
el cuadro donde aparecerá la información de la empresa seleccionada.
Al escoger una o varias categorı́as de la lista, aparecerán sobre el mapa todas
aquellas empresas que pertenezcan a dicha categorı́a. Si además se selecciona alguna, la información asociada a ella será mostrada en el cuadro de informació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 podrán visualizar las manzanas más próximas a éste (Figura 11). Por último, a nivel de detalle de edificio, la empresa escogida se verá ubicada en la planta
correspondiente (Figura 12).
Como se ha mencionado anteriormente, la aplicación web también tendrá un
espacio reservado para los empresarios, donde éstos podrán cambiar parte de la
información de las empresas a las que están asociados, como se puede ver en la
Figura 13.
5.
Conclusiones y lı́neas futuras
En este apartado se verán las conclusiones finales a las que se ha podido llegar,
ası́ como las posibles mejoras que se pueden aplicar al prototipo ya obtenido.
249
Fig. 12 Tercer LOD: edificio.
Fig. 13 Espacio para empresarios.
5.1.
Conclusiones
El 3D está cada vez más presente en las nuevas tecnologı́as como modelo de
visualización, ya que de esta forma al usuario se le permite ver escenas con un
realismo superior y la inmersión del usuario que se consigue en el entorno virtual es
mayor.
Los Sistemas de Información Geográfica (SIG) también ganan en funcionalidad cuando utilizan informació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
representación y el procesamiento de información en tres dimensiones. Ejemplos de
250
esta incorporación del 3D a los SIG son Google Earth o pequeñas funcionalidades
para la generación de 3D a partir del barrido de la planta de las entidades espaciales
añadidas a aplicaciones como MapInfo. Sin embargo, a la investigación en este tema
todavı́a le queda un largo camino por recorrer.
Por otro lado, hace ya tiempo que Internet se está convirtiendo en el medio de
acceso a la información más utilizado. Diferentes comercios, empresas y organizaciones aprovechan esta situación para darse a conocer gracias a la red. Estar localizable a través de Internet es importante para captar clientes. Además, facilita a los
usuarios la búsqueda de información.
El objetivo principal de este capı́tulo era describir la metodologı́a seguida para
desarrollar un prototipo de un Sistema de Información Geográfica que permitiese la
obtención de información empresarial y la navegación en 2.5D en entornos urbanos,
de manera que, a través de un simple navegador web, el usuario puediera buscar
las distintas empresas de la ciudad por categorı́as, obtener informació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 Sección 3, se ha conseguido
obtener un prototipo que cumple los requisitos definidos al comienzo. No obstante,
la aplicació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
continuación se comentan una serie de puntos en los que se describen las lı́neas de
trabajo futuro que se llevarán a cabo:
Situar las empresas no sólo a nivel de planta sino teniendo en cuenta también la
estructura interior del edificio: En el LOD más detallado del prototipo se sitúa
la empresa en su planta correspondiente, asignándole el centro de la geometrı́a
del edificio. Otra mejora relativa a esta geocodificación serı́a situar el comercio
no sólo en la planta a la que pertenece, sino colocarlo tambié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 también la geometrı́a interior de
cada edificio.
Aumentar la capacidad de navegación dentro del entorno urbano: En este prototipo el nivel de navegación proporcionado en las escenas es bastante limitado:
ú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 navegación, en la que el usuario pudiera moverse a nivel de peató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 información espacial de dichas
calles.
251
Migración de la aplicación a WebGL: Como se ha mencionado anteriormente,
Google abandonó su proyecto de O3D para centrarse en colaborar con WebGL,
que promete convertirse en el estándar de visualización Web al integrarse perfectamente con HTML5. Para adaptar el prototipo a la tendencia actual se deberı́a
migrar la aplicació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 opció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 localizació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 información geográ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. Köninger, A., Bartel, S.: 3d-gis for urban purposes. GeoInformatica 2, 79–103 (1998)
252
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: aplicación software para la gestión de
modelos de edificios
Bernardino Domı́nguez Martı́n, Francisco de A. Conde Rodrı́guez, Ángel Luis
Garcı́a Fernández, Francisco R. Feito Higueruela
Resumen Los Sistemas de Información Geográfica están evolucionando hacia sistemas donde los datos está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 arquitectónicos de manera sencilla.
Aquı́ tratamos los requerimientos y el diseño de la interfaz de una herramienta para
hacer más sencilla la creación, validación y refinamiento de contenidos de interiores
tomando como datos de entrada planos vectoriales de plantas de edificios.
1.
Introducción
La Informática Gráfica está cada dı́a más integrada en nuestra vida diaria. Su
influencia está 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 llevándose a cabo a miles de quilómetros de distancia y
analizarlos ası́ fácilmente.
Otros ejemplos de aplicaciones de Informática Gráfica son aquellos que ofrecen
a los usuarios la visualizació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 están almacenados en servidores remotos. También hay sitios web que permiten
navegar por el interior de museos, universidades, empresas, etcé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 aplicación,
los modelos pueden ser ú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, Á.L. Garcı́a, F.R. Feito
e-mail: {bdmartin,fconde,algarcia,ffeito}@ujaen.es
253
254
B. Domı́nguez, F. Conde, Á.L. Garcı́a y F.R. Feito
ú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 algún formato popular (normalmente DXF
o DWG), y a partir de esa información es necesario hacer un trabajo manual para
crear los modelos 3D correspondientes [2]. En todo este proceso es fundamental
tener la información CAD estructurada correctamente en capas, ya que mucha de
esa información no es relevante para crear los modelos (por ejemplo: la localización de la instalación de fontanerı́a no es relevante para una vista 3D de una sala de
un museo). Si el plano CAD está estructurado en capas, es posible seleccionar sólo
aquellas que contienen información necesaria.
Serı́a por tanto deseable disponer de una aplicación que pudiera crear automáticamente un modelo de interior a partir de un plano de planta; esto es: paredes, puertas,
ventanas, habitaciones, pasillos, etcétera. Los modelos de información de edificios 1
creados de esta manera podrı́an servir para aplicaciones de visitas virtuales, ası́ como otro tipo de aplicaciones tales como simulación de iluminación, acústica o de
incendios [9], o incluso juegos [12]. Yin y otros publicaron recientemente un estudio sobre métodos para generar este tipo de modelos [13]. Todos estos mé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 pequeña introducción para explicar algunos conceptos sobre el problema; luego se presentan los requerimientos que una aplicación para
la detección semiautomática de elementos semánticos en un plano deberı́a cumplir.
Además, también se trata el diseño de la interfaz para esta aplicación. Todo este
proceso de análisis es necesario para llevar a cabo el desarrollo de una aplicación
que pueda ser aceptada por usuarios que normalmente no serán profesionales de la
Informática, sino de Arquitectura e Ingenierı́a.
2.
Conceptos previos
Como la aplicación software que se quiere desarrollar está centrada en la carga y procesamiento de planos arquitectónicos almacenados en formato DXF, esta
sección repasa algunos conceptos básicos sobre el formato DXF y cómo tendrı́a
que procesarse teniendo en cuenta el objetivo final. En la documentación técnica de
R
Autodesk
se puede encontrar una descripción detallada del formato [1].
1
Building Information Models o BIMs a partir de ahora
MOSES: aplicación software para la gestión de modelos de edificios
2.1.
255
Estructura de un fichero DXF
Las tres unidades principales de información en un fichero DXF son las capas,
los bloques y las entidades. Otros conceptos como clases y tablas no son útiles en
este caso, ası́ que no se revisarán aquı́.
Entidades: la entidad es la unidad mı́nima de información en un plano en DXF.
Los tipos bá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 á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 continuación) colocados en una posición concreta y modificados por un
factor de escalado y un ángulo de rotació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 definició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 baño, etcétera). Cada bloque tiene un nombre único en el fichero.
Capas: son agrupaciones lógicas de entidades de un plano. Para cada capa se define un color, tipo y estilo de lı́nea, etcétera, que definen el aspecto con el que se
dibujará. Las capas se utilizan para agrupar elementos que tienen el mismo significado (paredes, columnas, aberturas, muebles, instalaciones eléctricas, equipamiento de baño, escaleras y ascensores, comunicaciones, fontanerı́a...). Cada
capa tiene un nombre ú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 información sobre las capas y entidades del plano.
2.2.
Estructura estándar de un plano
La estructura de un fichero DXF no limita de ninguna manera có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 semá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 información de conectividad.
Como tienen grosor, cada pared se dibuja con un par de lı́neas, sin ningún tipo
de información topológica asociada.
256
Las aberturas (puertas y ventanas) se definen como bloques. Cada bloque estará alineado con su sistema de coordenadas local, mientras que sus instancias
estarán trasladadas, rotadas y escaladas cuanto sea necesario. El nombre de los
bloques no es relevante.
En este trabajo se considera que las columnas están integradas en la capa de
paredes. Otras posibilidades se estudiarán en el futuro.
2.3.
Detección de elementos semánticos
Para este proceso, se introduce el concepto de punto clave como entidad semá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 nú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 tambié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.
Detección y corrección de irregularidades
Un paso previo para el resto de algoritmos es la detección y corrección de irregularidades. Los segmentos del plano se procesan automáticamente para detectar y
eliminar lı́neas duplicadas, lı́neas de longitud cero y lı́neas que está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.
Detección de paredes
En primer lugar, este proceso busca los pares de segmentos paralelos y suficientemente pró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.
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 contendrá 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 información de conectividad entre paredes es posible
detectar habitaciones cerradas.
2.3.4.
Detección de escaleras
El algoritmo para detectar escaleras se basa en la misma idea que el de detección
de paredes: basta buscar conjuntos de segmentos paralelos y equidistantes en la capa
de escaleras.
2.3.5.
Detecció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 está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 configuración geométrica, se aplica una regla
para encontrar la posició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 habitación cerrada [4].
3.
Requerimientos de la aplicación
El proceso clásico de la Ingenierı́a de Software consta de tres etapas: análisis,
diseño e implementación. El objetivo de la fase de análisis es obtener una descripción lo má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 aplicación.
En primer lugar, se enumeran las caracterı́sticas básicas que debe poseer la aplicación:
Debe ser capaz de cargar planos de plantas almacenados en un formato ampliaR
mente aceptado. El formato DXF de Autodesk
es una buena opción, puesto que
se diseñó pensando en el intercambio de información entre aplicaciones CAD, y
hoy en dı́a es muy utilizado [1].
258
Como la aplicación va a manejar dibujos arquitectónicos cuya información suele
estar dividida en capas, es necesario permitir al usuario elegir qué capas contienen información relevante sobre los elementos arquitectónicos a detectar.
El software debe permitir al usuario seleccionar los bloques que contienen información importante sobre los elementos a detectar.
Es necesario extraer de los planos información relativa a elementos arquitectónicos como paredes, habitaciones, pasillos, escaleras, puertas o ventanas, de manera que se puedan generar los elementos 3D correspondientes. Esto implica obtener el significado semántico de diferentes conjuntos de elementos geométricos
(curvas, lı́neas, puntos arcos, inserciones, ...) que se incluyen en el plano.
La información semántica obtenida tras el proceso de detección ha de almacenarse en una base de datos, para que la creación de objetos 3D pueda llevarse a
cabo fácilmente y cuantas veces sea necesaria a partir de un único análisis.
Como el objetivo de esta aplicación es muy especı́fico, sus usuarios no van a ser
de cualquier tipo, sino que será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 aplicación permitirá tratar cada planta de un edificio como un proyecto. Un
proyecto puede guardarse y cargarse posteriormente.
El usuario podrá seleccionar y/o deseleccionar capas y bloques a su antojo. La
información semántica detectada podrá visualizarse sobre el plano original para
poder comprobar su corrección.
El proceso de detección será semiautomático. Esto es: el usuario podrá personalizar la forma en que se aplican los algoritmos de detección, ası́ como seleccionar
áreas en el plano para las que se definan distintos valores de los parámetros de
detección. Además, en algunos casos será necesario recurrir a la intervención del
usuario para resolver situaciones ambiguas o inesperadas.
Todas las acciones del usuario podrán deshacerse, de tal forma que se puedan
compensar posibles errores en el uso de la aplicación.
4.
Análisis de la aplicación
La interfaz de una aplicación es fundamental para que ésta sea exitosa. Debe proporcionar al usuario medios eficientes, intuitivos y fáciles de aprender para obtener
los resultados que desea, explotando al máximo las capacidades del software.
Esta sección se centra en los requerimientos y caracterı́sticas que la interfaz de
usuario de la aplicación debe cumplir. Ası́ mismo, se plantean algunas soluciones
efectivas para cumplir con dichos requerimientos.
4.1.
259
Análisis de tareas
El proceso de diseño de la interfaz de usuario de una aplicación requiere de un
análisis detallado de las tareas que ésta va a permitir, en el cual se recogerán todas las acciones del usuario que producen cambios en el estado de la aplicación.
Teniendo en cuenta esto, y que para hacer más flexible la interacción se han separado la selección de parámetros y la ejecución de los algoritmos, se consideran las
siguientes tareas:
1. Crear un nuevo proyecto: la aplicación finaliza todos los procesos que estuvieran en marcha (permitiendo guardar o descartar los últimos cambios realizados
si procede) y prepara el entorno para introducir una nueva planta.
2. Cargar un proyecto existente: la aplicación lee los datos de un proyecto existente y almacenado previamente en un fichero, y muestra en una ventana toda la
información sobre la planta que representa.
3. Cerrar proyecto: la aplicación cierra el proyecto actual, permitiendo al usuario
guardar o descartar los últimos cambios realizados.
4. Guardar proyecto: la aplicació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 aplicación termina, permitiendo al usuario guardar o descartar los últimos cambios que no hayan sido guardados.
7. Cargar fichero DXF: la aplicació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 aplicación permite al usuario seleccionar
algunos elementos de la lista de capas. El dibujo se actualiza para mostrar sólo
las entidades contenidas en las capas seleccionadas.
9. Ver la definició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 través de esta tarea, el usuario puede ver el aspecto visual de cada bloque, y
ası́ estar seguro de su elección.
10. Cambiar el zoom: la aplicación actualiza el dibujo cuando el usuario indica un
nuevo valor de zoom.
11. Pan: la aplicación actualiza el dibujo cuando el usuario hace clic con el ratón y
arrastra el dibujo dentro de la ventana.
12. Seleccionar área: el usuario selecciona un área rectangular del dibujo. Luego, la
aplicación calcula y almacena las entidades seleccionadas. Esta selección será tenida en cuenta para la ejecución de los algoritmos.
13. Cambiar la selecció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
detección.
260
14. Cambiar la selecció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 detección.
15. Cambiar el umbral para la detecció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 detección de paredes y la extracción de puntos:
previamente a esta tarea, es necesario haber seleccionado la/s capas con la información de paredes y aberturas, los bloques que representan aberturas, y haber
fijado el umbral de detección de paredes. Opcionalmente, puede existir un área
seleccionada. En esta tarea se lanzan los algoritmos para la detección de paredes
y puntos (Secció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 (Sección 2.3.3).
19. Aplicar el umbral para la detección de escaleras: si las capas con información
de escaleras y el umbral de anchura están seleccionados, se lanza el algoritmo de
detección de escaleras (Sección 2.3.4).
20. Detección de puntos basada en reglas: se lanza el algoritmo de detección de
puntos clave utilizando reglas, siempre que todos los parámetros mencionados
anteriormente hayan sido previamente fijados (Sección 2.3.5).
21. Añadir un punto clave: la aplicación coloca un nuevo punto clave en el plano.
El usuario selecciona su tipo y ubicación haciendo clic con el ratón en un punto
del plano o introduciendo sus coordenadas.
22. Borrar un punto clave: la aplicación borra un punto clave seleccionado por el
usuario.
23. Cambiar el tipo de un punto clave: la aplicación cambia el tipo de un punto
clave seleccionado por el usuario.
24. Mover un punto clave: la aplicación mueve un punto clave cuando el usuario
hace clic con el ratón sobre él y lo arrastra o indica sus nuevas coordenadas con
el teclado.
25. Añadir habitación: la aplicación añade una nueva habitación al modelo como
un conjunto ordenado de puntos clave seleccionados por el usuario.
26. Borrar habitación: la aplicación borra una habitación seleccionada por el usuario.
27. Exportar la planta a la base de datos: la aplicación almacena la planta actual
en una base de datos, con toda la información detectada por los algoritmos. La
planta se guarda como parte de un edificio.
28. Borrar una planta de la base de datos: la aplicación borra una planta de un
edificio de la base de datos.
29. Borrar un edificio de la base de datos: la aplicación borra un edificio y todas
sus plantas de la base de datos.
4.2.
261
Estructura de las tareas
Es necesario describir el proceso completo de realización de cada tarea desde
el momento en que el usuario la inicia hasta que se termina, de manera análoga a
como se hace al describir casos de uso, incluyendo ası́ los pasos de la interacción
entre el usuario y el sistema. Normalmente, una tarea tiene la siguiente estructura:
(1) el usuario lanza la tarea interactuando con la aplicación; (2) la aplicación pide al
usuario los parámetros necesarios para ejecutar la tarea; (3) se ejecuta la tarea, y el
resultado se muestra a través de la interfaz de la aplicación. Por ejemplo, la tarea 17
se describirı́a ası́:
1. El usuario inicia la tarea al hacer clic en un botón de la interfaz.
2. La aplicación ejecuta el algoritmo de detecció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 ejecución del algoritmo.
4.3.
Arquitectura de la interacción
En esta fase se analiza cómo se combinan las tareas descritas anteriormente, de
forma que se construye una lógica de interacción consistente. Después de este análisis, se definen los caminos permitidos en el flujo de la interacción con el usuario,
evitando ası́ la posibilidad de que aparezcan algunos errores en la implementación
de la aplicación. El análisis de la arquitectura de la interacción tiene dos etapas:
Construir un árbol jerárquico con todas las tareas del sistema (distintas de las
tareas relacionadas con los usuarios y mencionadas anteriormente). La raı́z del
árbol es un nodo que representa a la aplicación completa, mientras que el siguiente nivel representa las tareas que forman parte del cauce principal de ejecució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
ejecución permitidos para cada tarea que no ocupa un nodo hoja en el árbol. La
interfaz de usuario ha de diseñarse de acuerdo con estos caminos, activando o
desactivando controles según corresponda.
Otro tema importante es determinar los estados de espera activa, provocados por
aquellas tareas que tienen un tiempo de ejecución largo durante el cual el usuario no
puede hacer nada. Estos estados deben tenerse en cuenta mientras se diseña e implementa la aplicación, porque cuando la aplicación esté en esos estados deberá proporcionar al usuario información sobre qué está pasando, ası́ como permitirle cancelar
el trabajo, manteniéndose en un estado consistente.
262
El resultado del análisis de la arquitectura de la interacción se plasma en el ası́ llamado diagrama HTA2 [3]. El diagrama HTA para esta aplicación es el siguiente:
0. Aplicación para edició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 selección de capas
Cambiar la selección de bloques representando puertas y ventanas
Cambiar los valores de umbral
Ver un bloque
Cambiar el zoom
Pan
Seleccionar un área
Detección de habitaciones
5.9.1. Cambiar la selección de capas y bloques para los algoritmos
5.9.2. Detección de irregularidades
5.9.3. Detección de paredes
5.9.4. Detección de puntos clave
5.9.5. Búsqueda de vértices
5.9.6. Agrupamiento
5.9.7. Detección de escaleras
5.10. Posprocesamiento semiautomático
5.10.1. Añ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. Añadir una habitación
5.10.6. Borrar una habitación
6. Cerrar el proyecto
7. Gestió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
263
El último paso del estudio de la arquitectura de la interacción consiste en especificar los caminos permitidos para tareas no atómicas (situadas en nodos intermedios del árbol). Estos caminos se representarán utilizando expresiones regulares, de
forma que la concatenación de tareas implica su ejecución secuencial, la barra (|)
separa alternativas, y el asterisco (*) detrás de una tarea o grupo de tareas indica que
se pueden repetir una o má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 selección inicial, la tarea Detección de habitaciones (5.9) empezará siempre por la subtarea Cambiar la selecció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 semiautomático: 5.10 → ( 5.10.1 | 5.10.2 | 5.10.3 | 5.10.4 | 5.10.5 | 5.10.6 )*
También se permiten todos los posibles caminos para la tarea Gestión de la base
de datos: 7 → ( 7.1 | 7.2 | 7.3 )*
Es más complicado representar los caminos de ejecución permitidos para la aplicación completa, ya que éstos dependen del estado de la aplicación. No es sencillo crear una expresió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 ningún proyecto abierto. En lugar de esto, se muestra un diagrama de
estado que modela los caminos permitidos.
La definición de los estados de la aplicación se basa en tres pará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 parámetros definen ocho posibles estados de la aplicación, de los cuales sólo cinco son válidos,
puesto que cuando no hay abierto un proyecto, los otros dos parámetros no tienen
sentido. A estos cinco estados se les añaden dos estados má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 aplicació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 aplicación es parte de un sistema cliente-servidor para la generación, gestión y visualización de información de interiores. Este sistema permite almacenar no
264
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 aplicació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
sólo la geometrı́a y la topologı́a de la escena, sino también otros datos que se pueden
añ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 extracción de información y generación del modelo 3D, y por tanto se hace más fácil ampliar el sistema incluyendo distintos formatos
de salida de datos sólo con cambiar el mó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 información necesaria para generar el modelo 3D. Esta información se guarda en una base de datos
que opcionalmente puede guardar datos adicionales sobre el edificio, tales como la
ubicación de negocios, despachos, etcétera.
Los clientes, por su parte, envı́an peticiones al servidor para recibir de éste una
descripción detallada de la planta correspondiente del edificio que se esté visitando,
codificada utilizando un formato de fichero 3D estándar, de tal forma que se pueda
visualizar con un visor está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
265
Fig. 1 Flujo de trabajo del
sistema propuesto
suficientes para el propósito de esta aplicación, y además se ajustan a las especificaciones del Open Geospatial Consortium (OGC) [11, 10]. En esta base de datos no
sólo se pueden almacenar datos de tipos estándar (enteros, reales, cadenas de texto,
etcétera), sino también datos de tipo geomé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 jerárquicos entre los datos almacenados, de forma que es posible
obtener información topológica mediante las consultas adecuadas.
Dos elementos de naturaleza especial son los ascensores y los tramos de escaleras, que podrı́an asociarse a más de una planta simultá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.
Diseño de la interfaz de usuario
Diseño de ventanas
En la etapa anterior del diseño se han definido las tareas a llevar a cabo por la
aplicación, ası́ como la arquitectura de la interacción. El siguiente paso es por tanto
266
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 diseño de la interfaz de usuario. Se pueden aplicar las siguientes directrices al
diseño de ventanas:
La ventana principal de la aplicación contendrá controles para lanzar todas las tareas del primer nivel del diagrama HTA. Cada ventana secundaria, diálogo emergente, marco interno o pestaña contendrá controles para lanzar subtareas.
Los caminos de ejecución prohibidos se evitarán mediante la desactivació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 aplicació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 está disponible
desde la barra principal de la aplicación, mientras que las tareas Cambiar la selección de capas, Ver un bloque y Detección de habitaciones se lanzan desde pestañas
situadas a la derecha de la ventana principal, y las tareas Cambiar el zoom, Pan y
Seleccionar un área no se lanzan mediante controles, sino utilizando un dispositivo
apuntador. La subtarea restante, Posprocesamiento semiautomático, se lleva a cabo
utilizando botones de un marco interno.
La interfaz incluye también una barra de menú estándar que organiza algunas de
las tareas antes mencionadas utilizando los menús tı́picos: Archivo, Editar, Herramientas y Vista.
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 aplicación. Los números muestran desde dónde se lanza cada tarea
del HTA
5.2.
Diseño del modelo
Como paso previo a la implementación, es necesario diseñar el sistema utilizando
una metodologı́a adecuada. Para este objetivo, se ha utilizado la metodologı́a UML
[6]. En esta sección se tratará en primer lugar la conveniencia de utilizar algunos patrones de diseño conocidos; luego se mostrará el diagrama UML para la aplicación
completa.
Para hacer este diseño, se han tenido en cuenta los siguientes principios:
Los componentes de la aplicación deben estar delimitados claramente, para evitar
ası́ el acoplamiento y hacer la implementación más sencilla.
Modificaciones futuras de la aplicación no deberı́an provocar cambios en los
componentes ya implementados, sino que bastará con añadir nuevos componentes dentro de la arquitectura existente.
5.2.1.
Patrones de diseño
Se han utilizado algunos patrones de diseño conocidos en el desarrollo de la aplicación [8, 7]. Éstos son: Modelo-Vista-Controlador, instrucción, estrategia, estado
y observador. A continuación se resume brevemente qué es cada uno de ellos, y
cómo se han utilizado en la aplicación.
268
Patrón Modelo-Vista-Controlador
La arquitectura Modelo-Vista-Controlador (MVC) se utiliza para dividir la aplicació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 informació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 cómo procesar las acciones del usuario, y si es necesario,
actualiza el modelo.
La vista só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 patrón
observador (descrito más adelante).
Patrón Estrategia
El patró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 ésta. Un objeto contexto contiene la información que
permite decidir qué implementación se utiliza en cada ocasión. En el diseño de esta
aplicación se ha utilizado este patró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 representació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
implementación del controlador, por su parte, ha de ser coherente con las del
modelo y la vista.
Algunos de los algoritmos para la detección de caracterı́sticas a partir de planos
de plantas están todavı́a en desarrollo. En esta situación, el uso del patrón estrategia es muy útil para poder probar fácilmente distintos algoritmos para el mismo
problema.
Patrón Instrucción
En los requerimientos de la aplicación se indicaba que para hacerla más flexible
era necesario que se permitiera al usuario deshacer/rehacer sus acciones, y para
hacer esto se utiliza el patrón instrucción. Hace falta identificar cada instrucción,
definiendo cómo se hace, se deshace y se rehace, y determinando qué información
hay que almacenar para cada una de estas actividades. El patrón instrucción se aplica
de la siguiente forma:
269
Hay una clase abstracta que modela el comportamiento de una instrucción genérica, y que contiene los métodos hacer y deshacer.
Cada instrucción se encapsula en una subclase de la anterior que contendrá los
parámetros necesarios para rehacer la instrucción.
Se mantiene un registro de las instrucciones ejecutadas, deshechas y rehechas en
una pila. Se permite deshacer la última instrucción ejecutada y rehacer la última
instrucción deshecha.
Patrón Observador
Para que el patró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 métodos de la vista. En esta situación se aplica el
patrón observador.
En este patró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 más que la forma de notificarles sus cambios. Cada
observador puede responder de distinta manera ante la notificació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 algún cambio, ésta
se actualiza de la manera adecuada.
Patrón Estado
Este patrón se utiliza cuando el comportamiento de un objeto depende de su
estado. Se pretende ası́ evitar acoplamiento entre clases (para decidir qué hacer, un
mé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 quién ha provocado el cambio
en su estado.
Este patrón se aplica en dos circunstancias diferentes:
Para guardar el estado de la aplicación, ya que como se comentó en la Sección
4.3, el flujo principal de la aplicación depende de si hay un proyecto abierto o no,
ası́ como de si tiene nombre de fichero asignado.
Para gestionar la interacción con el dibujo del plano. La aplicació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.
Diagrama de clases UML
Para facilitar su comprensión, el diagrama completo de clases para esta aplicación se ha dividido en varios diagramas simplificados que se muestran a continuación.
El primer diagrama (Figura 4) muestra la arquitectura MVC de la aplicación,
ası́ como los patrones observador, estado y estrategia.
<<interface>>
ViewInterface
<<interface>>
ModelInterface
<<interface>>
ModelChangedObserver
implements
<<interface>>
StackChangedObserver
implements
implements
implements
reads
registers itself
notiﬁes
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 patrón estrategia). Podrı́an añ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 sólo hay un mé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. Sólo entonces la
vista accede al modelo para actualizar la interfaz de la aplicación.
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 algún cambio
en alguno de estos estados. El controlador actualiza los estados de activación
de los controles de la interfaz y almacena el estado actual.
- StackChangedObserver se describe má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 más adelante).
El segundo diagrama (Figura 5) muestra un ejemplo de la arquitectura de clases
para el patrón instrucción, la instrucción en la que se basa el ejemplo es la de cargar
un fichero DXF (LoadDXFCommand).
UndoManager
View
<<interface>>
StackChangedObserver
-instance
registers itself
notiﬁes
+invoker
UndoStack
AbstractCommand
<<interface>>
UndoableEdit
AbstractUndoableEdit
adds itself
LoadDXFCommand
+receiver
Controller
+client
+receiver
Model
Fig. 5 Patrón instrucción
La clase principal del patrón instrucción es UndoStack. Esta clase es un singleton
(una clase con una única instancia en la aplicación) que permite añadir nuevas
instrucciones, deshacerlas y rehacerlas, ası́ como consultar si la pila está vacı́a.
Toda instrucció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
que se actualiza la interfaz de la aplicación para mostrar qué instrucciones pueden rehacerse o deshacerse.
Cada instrucción hereda de AbstractCommand, una clase abstracta que define un
método para ejecutar la instrucción.
El tercer diagrama (Figura 6) muestra la arquitectura del modelo, es decir: la
representación lógica de los datos manejados por la aplicación. En esta representació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 rectá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 bá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 creació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 detección, esto es: habitaciones formadas por puntos clave, ventanas, puertas y tramos de escaleras.
El último diagrama de esta sección (Figura 7) muestra la implementación del
patrón estado. La interfaz ApplicationState define los métodos posibles para cada acción. Ası́, la clase que representa cada estado implementa esta interfaz, y su
273
comportamiento y el siguiente estado al que pase la aplicación depende de la implementación de sus métodos. El controlador tiene en cuenta los estados anterior y
actual de la aplicación, y notifica a la vista cuando el estado cambia.
<<interface>>
AppState
AppStateQ1
AppStateQ2
AppStateQ3
AppStateQ4
AppStateQ5
Controller
Fig. 7 Estados de la aplicación
6.
Resultados y ejemplos
Se muestran ahora algunos ejemplos de uso de la aplicación, junto con los resultados obtenidos al aplicar los algoritmos implementados.
El primer ejemplo muestra el proceso de detección de paredes y habitaciones
utilizando el enfoque basado en la detección de paredes. Este proceso consta de los
siguientes pasos:
1.
2.
3.
4.
5.
6.
7.
8.
Carga del fichero DXF y selección de capas visibles (Figura 8)
Selección de capas con paredes, aberturas y escaleras (Figura 9)
Selección de bloques correspondientes a puertas y ventanas (Figura 10)
Detección de irregularidades en la capa de paredes (Figura 11)
Detección de paredes (Figura 12)
Búsqueda de vértices en las capas de paredes y aberturas (Figura 13)
Agrupamiento (Figura 14)
Detección de escaleras (Figura 15)
El segundo ejemplo muestra có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 selección de capas visibles (Figura 8)
Selección de capas con paredes, aberturas y escaleras (Figura 9)
Selección de bloques correspondientes a puertas y ventanas (Figura 10)
Detección de irregularidades en la capa de paredes (Figura 11)
Detección de puntos clave y habitaciones (Figura 16)
274
Fig. 8 Selección de capas visibles
Fig. 9 Selección de capas con paredes, aberturas y escaleras
Fig. 10 Selección de bloques correspondientes a aberturas
275
Fig. 11 Detección de irregularidades
Fig. 12 Detección de paredes
En la URL http://baeza.ujaen.es/ bdmartin/demo.zip está disponible para su descarga un vı́deo que muestra el funcionamiento de la aplicación.
276
Fig. 13 Búsqueda de vértices
Fig. 14 Agrupamiento
Fig. 15 Detección de escaleras
277
Fig. 16 Detección de puntos clave y habitaciones
7.
Se ha presentado el análisis de requerimientos, el diseño de interfaz y la implementación de una aplicación para la detección de elementos semá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 análisis de requerimientos y la interfaz de usuario,
el diseño y la implementación de la aplicación. Por último, se han mostrado algunos
ejemplos de uso de la aplicación.
El trabajo futuro consisitirá básicamente en la incorporación de nuevos algoritmos de detección a la aplicación, puesto que el diseño flexible utilizado facilita esta
tarea, sin necesidad de modificar el resto del código.
Agradecimientos Este trabajo ha sido parcialmente subvencionado por la Junta de Andalucı́a, el
Ministerio de Ciencia e Innovación y la Unión Europea (fondos FEDER) a través de los proyectos
de investigació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
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.: Detección semiautomática de paredes, habitaciones
y escaleras a partir de planos arquitectónicos CAD. In: Proceedings of XX Congreso Español
de Informática Grá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)

Visualización de medios participativos en entornos urbanos

Transcripción

Documentos relacionados

universidad de castilla-la mancha escuela superior

Manual del examinando - Escola d`Idiomes Moderns

Mapeo facial de emociones sintéticas - UPM ASLab

Extracción de Información

Ataques contra redes TCP/IP