Adaptación de Algoritmos Geométricos al Uso de Hardware Gráfico Programable

Transcripción

1 Adaptación de Algoritmos Geométricos al Uso de Hardware Gráfico Programable Aplicaciones MEMORIA DE TESIS Presentada por José María NOGUERA ROZÚA Para optar al grado de doctor Universidad de Jaén, Departamento de Informática.

2

3 La Memoria titulada Adaptación de Algoritmos Geométricos al Uso de Hardware Gráfico Programable. Aplicaciones, que presenta D. José María Noguera Rozúa para optar al grado de Doctor por la Universidad de Jaén, ha sido realizada en el Departamento de Informática de la Universidad de Jaén bajo la dirección de los doctores D. Rafael Jesús Segura Sánchez y D. Carlos Javier Ogáyar Anguita. Jaén, Enero de 211. El Doctorando José María NOGUERA ROZÚA Los Directores Rafael Jesús SEGURA SÁNCHEZ Carlos Javier OGÁYAR ANGUITA

4

5 Abstract Adaptation of Geometric Algorithms to the Programmable Graphics Hardware. Applications. This thesis studies different ways to use the parallel computing capabilities of the graphics hardware to solve several problems related to Computer Graphics. The first part of this thesis introduces and discusses several parallel approaches to solve basic algorithms in Computer Graphics and Computational Geometry. The problems studied include non-coherent ray-tracing, solid voxelization and point-in-solid test. The second part, on the other hand, describes a parallel technique for interactive rendering of large terrains on mobile devices (e.g., personal digital assistants, tablets or smart phones) connected to low-bandwidth celullar networks. This technique splits the rendering workload between a mobile client and a remote server. The terrain close to the viewer is rendered in real-time by the client, whereas the distant terrain is portrayed as view-dependent impostors, rendered by the server on demand. A prototype has been built and an exhaustive set of experiments has been conducted. Results show that the approach is feasible, effective, robust and scalable. Keywords: Computer Graphics, Visualization, Graphics Hardware, Parallel Computing, Mobile Computing, Terrain Rendering. 5

6

7 Resumen Adaptación de Algoritmos Geométricos al Uso de Hardware Gráfico Programable. Aplicaciones. En esta tesis se realiza un estudio sobre la utilización de las capacidades de cómputo en paralelo del hardware para la resolución de diversos problemas en Informática Gráfica. La primera parte de la tesis se centra en la paralelización hardware de algoritmos básicos en Informática Gráfica y Geometría Computacional. Se proponen diversas soluciones paralelas y eficientes que resuelven los problemas del trazado de rayos no coherentes, la voxelización de sólidos y el test de inclusión de puntos en sólidos. La segunda parte describe una técnica paralela de visualización interactiva de grandes terrenos en dispositivos móviles (agendas electrónicas, tabletas, teléfonos móviles, etc.) conectados a redes celulares con reducido ancho de banda. La carga gráfica se reparte entre un cliente móvil y un servidor remoto. El área de terreno próxima al observador se sintetiza en tiempo real por el propio dispositivo móvil, en tanto que la parte alejada se representa mediante impostores generados por el servidor bajo demanda. Se ha desarrollado un prototipo y se ha sometido a un exhaustivo conjunto de experimentos. Los resultados muestran que la técnica es viable, efectiva, robusta y escalable. Palabras clave: Informática Gráfica, Visualización, Hardware Gráfico, Computación Paralela, Computación Móvil, Visualización de Terrenos. 7

8

9 Agradecimientos Llegados a este punto, es el momento de agradecer a todas aquellas personas que me han ayudado en la realización de este trabajo. Es un placer trabajar con vosotros, incluyendo a aquellos a los que no haya nombrado explícitamente aquí. En particular, me gustaría expresar mi más sincera gratitud a mis directores de tesis, Rafael Segura y Carlos Ogáyar, por haberme brindado la oportunidad de desarrollar este trabajo en la Universidad de Jaén, y por su guía y ayuda durante estos años. También me gustaría agradecer a Carlos Ureña por guiarme durante mis primeros pasos en el mundo de la investigación. Parte de este trabajo se realizó durante mi estancia en la Universitat Politècnica de Catalunya. Quisiera agradecer desde estas líneas a Robert Joan-Arinyo por su excelente acogida en Barcelona y por sus valiosas revisiones que tanto han ayudado a que este trabajo tenga la forma que hoy tiene. Por último, y no por ello menos importante, agradecer a mis padres, mi hermano y a Bárbara por su ánimo e infinita paciencia durante estos largos años. Parte del trabajo presentado en esta memoria ha sido financiado por la Unión Europea (fondos FEDER); la Consejería de Educación y Ciencia de la Junta de Andalucía a través del Proyecto de Excelencia P6-TIC-143; y por el Ministerio de Ciencia e Innovación del Reino de España a través del proyecto TIN C3-3. 9

10

11 Índice general 1 Introducción Introducción Motivación Objetivos Estructura de la Memoria Paralelización Hardware de Algoritmos Gráficos Introducción Taxonomía de Flynn Paralelismo Funcional y de Datos Paralelismo de Datos en CPU Paralelismo de Datos en GPU El Proceso Gráfico El Proceso Gráfico en la GPU Las Librerías Gráficas Evolución de la GPU Programable Sistemas de Computación Paralela en la GPU Paralelización de Algoritmos Gráficos en CPU Introducción El Trazado de Rayos Coherencia Espacial en Ray-Tracing Trabajos Previos El Trazado de Rayos Vectorizado Motivaciones

12 12 Índice general 3.4 Recorrido del Árbol-kd Algoritmo de Recorrido para un Rayo Algoritmo de Recorrido para Múltiples Rayos Disposición de los Rayos en Memoria Cómputo Rayo-Triángulo Rendimiento Comparación para Rayos Coherentes Comparación para Rayos No Coherentes Conclusiones Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales Introducción Sistema Generador de Objetos Gráficos Voxelización de Sólidos Soluciones para la Voxelización en GPU Comparación Empírica de Soluciones de Voxelización Inclusión de Puntos en Sólidos Soluciones desde Memoria de la CPU Soluciones desde Memoria de la GPU Comparación Empírica de Soluciones de Inclusión Conclusiones Gráficos 3D para Dispositivos Móviles Introducción Consideraciones sobre Dispositivos Móviles Tecnologías Móviles Estándares Gráficos Plataformas Móviles Redes Celulares Trabajos Previos de Visualización 3D en Dispositivos Móviles Visualización Local Visualización en el Lado del Servidor Visualización en el Lado del Cliente Visualización Híbrida Trabajos Previos en Visualización de Terrenos Triangulación de Resolución Variable mediante Árboles Triangulación por Bloques Visualización de Terrenos en Dispositivos Móviles Terrenos en Entornos Cliente-Servidor Uso del Hardware Gráfico Móvil Soluciones Específicas para Dispositivos Móviles Conclusiones

13 Índice general 13 6 El Método de Visualización Híbrido Introducción Elementos de Visión en 3D El Método Híbrido El Terreno El QuadTree Restrictivo Nuestra Estructura de Datos Base de Datos del Servidor Base de Datos del Cliente Aritmética Entera y Precisión El Panorama Actualización del Terreno Actualización del Panorama Traslación a lo Largo de los Ejes X e Y Traslación a lo Largo de la Dirección de Visión Algoritmo para Actualizar el Panorama Transición de Panoramas Visualización Dibujado Mediante Máscaras de Índices Almacenamiento de Geometría en Memoria de GPU Parametrización del Método Arquitectura Multi-Cliente para Visualización Híbrida Introducción El Marco de Trabajo Arquitectura del Servidor Principal Arquitectura del Servidor de Panoramas El Sintetizador de Panoramas El Compresor de Panoramas Arquitectura del Cliente El Módulo de Visualización Módulo Actualizador de la Base de Datos Local El Decodificador de Datos y el Generador de Peticiones Protocolo de Red Descripción del Protocolo Comunicación Asíncrona Resultados del Método de Visualización Híbrida Introducción Las Plataformas Empleadas El Terreno Empleado Evaluación del Lado del Cliente El Vuelo

14 14 Índice general La Red Empleada Los Experimentos Rendimiento Uso de la Red Estrategia Híbrida Frente a Basada en el Cliente Evaluación en el Lado del Servidor Rendimiento del Servidor Escalabilidad Conclusiones Conclusiones y Trabajos Futuros Conclusiones Trabajos Futuros A Desarrollo Software para Dispositivos Móviles 193 A.1 Introducción A.2 Evaluación de Rendimiento de Plataformas Móviles A.2.1 Los Experimentos A.2.2 Evaluación A.3 Fragmentación de los Dispositivos Móviles A.3.1 Diferencias en el Lenguaje de Programación A.3.2 Diferencias en las Librerías del Sistema Operativo A.4 Desarrollo de Software Adaptable A.4.1 Arquitectura del Software y Capas de Abstracción A.4.2 Componente Librería Común del Sistema A.4.3 Componente Librería de Gráficos 3D Común B Juego Completo de Experimentos 29 B.1 Introducción B.2 Nokia N95, Conexión UMTS (3G) B.3 Nokia N95, Conexión GPRS (2G) B.4 iphone 3GS, Conexión UMTS (3G) B.5 iphone 3GS, Conexión GPRS (2G) B.6 NVIDIA GeForce 88 GTS, Conexión UMTS (3G) B.7 NVIDIA GeForce 88 GTS, Conexión GPRS (2G) Bibliografía 229

15 1 Introducción 1.1 Introducción En este Capítulo se realiza una breve introducción al trabajo realizado que sirve para presentar las motivaciones que originaron la investigación, así como los objetivos planteados. También se expone un pequeño resumen del contenido de cada Capítulo, para proporcionar al lector un esquema de la estructura general de esta memoria de tesis doctoral. 1.2 Motivación La presente tesis se ha llevado a cabo dentro del ámbito del Proyecto de Excelencia de la Junta de Andalucía P6-TIC-143, y se ha desarrollado a lo largo de los años 27 a 21. El título de la tesis hereda directamente de la denominación de dicho proyecto, Adaptación de Algoritmos Geométricos al uso de GPU programable. Aplicaciones. De igual manera, las líneas de investigación desarrolladas en la tesis han estado motivadas por los objetivos fijados por el Proyecto de Excelencia. Durante los últimos años de la década de 199, así como la década de 2, se ha producido una rápida evolución y una profunda expansión de las arquitecturas de computación paralelas SIMD (Single Instruction Multiple Data). En la actualidad, este tipo de 15

16 16 Introducción arquitecturas son habituales en la mayoría de procesadores de propósito general, y sobre todo, en los procesadores gráficos 1 programables. La explotación de este hardware es uno de los puntales hoy en día en el campo de la Informática Gráfica, pues permiten paralelizar de forma eficiente el cómputo de elevados volúmenes de datos. Es posible afirmar que muchas de las publicaciones actuales en esta disciplina están centradas en este objetivo. Asimismo, durante la segunda mitad de la década de 2 este tipo de hardware se ha estado paulatinamente introduciendo en dispositivos móviles (ordenadores de mano, terminales de telefonía móvil, etc.). Este hecho ha aumentado la potencia de cálculo de estos dispositivos hasta cotas impensables hace escasos años. La presente tesis se apoya en dos líneas de investigación principales. La primera de ellas se centra en la paralelización hardware de algoritmos básicos en Informática Gráfica y Geometría Computacional. La segunda ha consistido en explotar el potencial gráfico de los dispositivos móviles dotados de GPU en el ámbito de la navegación interactiva sobre terrenos. El interés de los sistemas de navegación hoy en día es muy alto, siendo de aplicación en múltiples ámbitos, tanto en el sector público como en el privado. Estos sistemas se han popularizado en los últimos años gracias al abaratamiento de los costes de los receptores de GPS, así como a la disponibilidad de cartografía adecuada. Por sí mismo, este objetivo debería ser destacado como núcleo principal de la tesis, ya que las soluciones existentes hasta la fecha son completamente ineficaces o sencillamente falsas. A modo de ejemplo, la visualización 3D mostrada por los diferentes productos de navegación para automóviles no se corresponde con el terreno visualizado, y consiste en una simple proyección sobre un plano de un objeto 2D. La dificultad de la solución radica en tres aspectos: por una parte, el tamaño de los datos necesarios resulta inviable para ser procesados e incluso almacenados en el dispositivo móvil; por otra parte, las capacidades de visualización de los dispositivos son escasas, y solamente aprovechadas a pleno rendimiento por software de ocio; por último, el ancho de banda de los sistemas y protocolos utilizados para la comunicación de dichos dispositivos es pequeño, siendo necesario un uso racional y óptimo del mismo. 1.3 Objetivos Los objetivos principales de la tesis han estado centrados en el aprovechamiento de las potencialidades de la GPU desde una doble perspectiva: 1 A lo largo de esta memoria emplearemos habitualmente el acrónimo GPU, de graphics processing unit o unidad de procesamiento gráfico.

17 Introducción Realización de un estudio sobre el aprovechamiento del potencial de cómputo en paralelo del hardware para la resolución de problemas básicos en Informática Gráfica y Geometría Computacional. 2. Aplicación de algoritmos basados en GPU hacia su integración en sistemas de navegación y visualización de terrenos 3D. Diseño de un sistema que permita esta navegación de manera interactiva en dispositivos móviles. Alrededor de este último objetivo se formularon inicialmente una serie de objetivos parciales que pasamos a enumerar a continuación: Construcción de una plataforma software para el tratamiento de modelos tridimensionales en dispositivos móviles, teniendo en cuenta las restricciones de los mismos (baja potencia, escasa memoria, redes de limitado ancho de banda, etc.). Integración de algoritmos basados en el uso de la GPU en sistemas de navegación y visualización de terrenos. Problemas como el cálculo de superficies, la determinación de inclusión, el conteo de unidades, etc. son problemas básicos en este tipo de sistemas existiendo buenas soluciones, aunque algunas de ellas siguen siendo costosas en términos computacionales. El objetivo se centra pues en la búsqueda de alternativas a estas soluciones que utilicen las capacidades de la GPU para reducir el coste. La búsqueda de algoritmos y métodos enfocados a la construcción de sistemas de navegación interactivos sobre grandes terrenos en dispositivos móviles, asegurando un tiempo de respuesta apropiado. 1.4 Estructura de la Memoria Dada la dualidad de los objetivos principales del proyecto expuestos en la Sección anterior, el presente documento se divide conceptualmente en dos partes. La primera parte comprende los capítulos 2, 3 y 4. En ellos se realiza un estudio de paralelización mediante hardware de diversos algoritmos básicos en Informática Gráfica. La segunda parte comprende los Capítulos 5, 6, 7, 8 y los Apéndices. En ellos se formaliza un método de descarga y visualización 3D adaptativa de terrenos en dispositivos móviles conectados a redes inalámbricas. También se describe y valida una arquitectura cliente-servidor que hace uso de este método. Procedemos a continuación a describir el contenido de cada Capítulo:

18 18 Introducción Capítulo 2 Paralelización Hardware de Algoritmos Gráficos Este capítulo se presentan conceptos acerca de la computación paralela con objeto de enmarcar a los Capítulos 3 y 4. Dado lo amplio de esta disciplina, solo se exponen los conceptos más cercanos a la temática del trabajo, haciendo hincapié en la paralelización de datos en la CPU y en la GPU. Capítulo 3: Paralelización de Algoritmos Gráficos en CPU En este Capítulo estudiamos la aplicación de técnicas de cómputo vectorial en CPU para paralelizar algoritmos gráficos. Se presenta una solución novedosa para resolver el problema del trazado de rayos empleando las capacidades SIMD disponibles en las CPU actuales. El algoritmo propuesto permite paralelizar el cómputo de los rayos, incluso aunque éstos no presenten coherencia entre sí. Capítulo 4: Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales En este Capítulo presentamos métodos basados en recubrimientos simpliciales para aumentar el rendimiento de distintos problemas básicos de geometría computacional. Los problemas estudiados son la voxelización de sólidos y el test de inclusión de puntos en sólidos. Se proponen y contrastan diversas soluciones que resuelven los problemas haciendo uso de las características más novedosas incluidas en las GPUs recientes. Capítulo 5: Gráficos 3D para Dispositivos Móviles Este Capítulo detalla con profundidad el estado del arte en el desarrollo de gráficos 3D en dispositivos gráficos. Este Capítulo sirve para enmarcar al resto de capítulos de la tesis. Se presentan las tecnologías gráficas más importantes, las tendencias actuales en investigación y las soluciones más destacadas. También se describe el estado del arte en métodos de visualización y navegación interactiva de grandes terrenos. Capítulo 6: El Método de Visualización Híbrido Este Capítulo propone y formaliza una solución híbrida completa para realizar descarga y visualización adaptativa de grandes terrenos mediante dispositivos móviles conectados a redes inalámbricas. Capítulo 7: Arquitectura Multi-Cliente para Visualización Híbrida A continuación, este Capítulo propone una completa arquitectura multi-cliente que permite realizar visualización híbrida de centenares de dispositivos móviles empleando como servidor a un ordenador de escritorio económico dotado de GPU. Capítulo 8: Resultados del Método de Visualización Híbrida En este Capítulo presentamos un prototipo cliente-servidor que implementa las soluciones planteadas en los dos capítulos anteriores. Este prototipo ha sido sometido

19 Introducción 19 a un exhaustivo conjunto de experimentos cubriendo una amplia variedad de situaciones. Los resultados son expuestos y discutidos. Capítulo 9: Conclusiones y Trabajos Futuros Este Capítulo presenta las conclusiones generales y resume las principales aportaciones de este trabajo. También se presentan posibles mejoras que pueden realizarse en el futuro, así como varias líneas de investigación que quedan abiertas para trabajos posteriores. Apéndice A: Desarrollo Software para Dispositivos Móviles En este Apéndice se presentan algunas particularidades del desarrollo software en dispositivos móviles que es preciso conocer. También se recoge un estudio preliminar de rendimiento de diversas plataformas móviles. Este estudio fue vital a fin de orientar nuestra posterior investigación. Finalmente, se presenta una librería de abstracción o middleware que fue desarrollada a fin de posibilitar la construcción de software fácilmente transportable entre múltiples plataformas. Apéndice B: Juego Completo de Experimentos Por último, este Apéndice reúne las gráficas de todos los experimentos analizados en el Capítulo 8 y que, dada su extensión, no han podido incluirse en dicho Capítulo.

20

21 2 Paralelización Hardware de Algoritmos Gráficos 2.1 Introducción Históricamente, el software se ha compuesto de un conjunto de instrucciones diseñadas para ejecutarse secuencialmente mediante un procesador. Este tipo de procesamiento se conoce como computación en serie. De esta manera, aumentar la velocidad de ejecución solo podía conseguirse mediante: a) la adecuada optimización de los algoritmos (por ejemplo, reduciendo su orden de complejidad) o de las implementaciones de los mismos (evitando cómputos innecesarios); y b) mediante la mejora del hardware. Si bien la optimización de los algoritmos es importante, siempre existe un coste computacional irreducible inherente al problema que se quiere resolver. Por otro lado, la mejora en las prestaciones del hardware está usualmente limitada por la ley de Moore 1 [Moo98] y por las propiedades físicas del material con el que se fabrican los circuitos electrónicos. Estos problemas han motivado a investigadores y desarrolladores a elaborar técnicas de computación en paralelo. En el ámbito de la computación, el paralelismo se entiende como como la capacidad de resolver un problema mediante la realización de distintos cómputos de manera concurrente en el tiempo. Idealmente, resolver un problema de forma paralela consiste en dividir el dominio de un problema en partes menores. A continuación, estas partes se resuelven por separado de forma concurrente en el tiempo. Por último, la 1 La Ley de Moore es una conjetura basada en la observación empírica y que establece que el número de transistores de un circuito integrado se duplica cada meses. 21

22 22 Paralelización Hardware de Algoritmos Gráficos solución final se compone mediante la unión de las soluciones parciales. No obstante, no todos los problemas pueden resolverse de esta manera. El problema debe ser divisible en partes independientes, y el coste de realizar esta división y su procesamiento en paralelo debe ser menor que el coste de resolver el problema de forma secuencial Taxonomía de Flynn Flynn propuso en [Fly66] una taxonomía que divide a los computadores en cuatro clases, en función del número de secuencias o flujos de instrucciones y de datos que puedan procesarse simultáneamente en el computador. Computadores SISD: Un único flujo de instrucciones que procesa un único flujo de datos. Computadores SIMD: Un único flujo de instrucciones que procesa varios flujos de datos, ya que cada instrucción comprende realmente varias operaciones iguales, actuando cada una sobre datos distintos. Ejemplos de esta categoría son los procesadores vectoriales y las GPUs. Computadores MIMD: Se ejecutan varias secuencias o flujos distintos de instrucciones, donde cada uno de ellos opera con un flujo de datos distinto. Como ejemplos pertenecientes a esta categoría podemos citar a las CPUs multinúcleo. Computadores MISD: Se ejecutan múltiples flujos distintos de instrucciones, aunque todos ellos operan con el mismo flujo de datos Paralelismo Funcional y de Datos La taxonomía de Flynn pone en manifiesto dos tipos de paralelismo que pueden aprovecharse según la plataforma de cómputo [OAP6, DFF + 3]. El paralelismo funcional consiste en identificar tareas que pueden resolverse de forma independiente entre sí y repartirlas entre los distintos nodos de cómputo. Solo las arquitecturas MIMD y MISD de la taxonomía de Flynn pueden implementar paralelismo funcional. Por ejemplo, un procesador puede ser responsable de leer datos de memoria secundaria y descomprimirlos, mientras que un segundo procesador puede encargarse de visualizar dichos datos. El paralelismo funcional posee distintos niveles de granularidad. De menor a mayor nivel distinguimos el nivel de instrucciones, de bucle, de funciones y de programas.

23 Paralelización Hardware de Algoritmos Gráficos 23 El paralelismo de datos, por otra parte, se fundamenta en la realización de una misma tarea sobre distintos datos, correspondiéndose con el modelo SIMD de la taxonomía de Flynn. El aprovechamiento de este paralelismo se consigue mediante la subdivisión del dominio de datos y el reparto entre los distintos nodos de cómputo, sean hilos, procesos, procesadores o nodos de una red. Los Capítulos 3 y 4 de esta tesis presentan técnicas de paralelismo de datos mediante SIMD orientadas a resolver diversos algoritmos gráficos. Por otro lado, la técnica de visualización híbrida de terrenos descrita en los Capítulos 6, 7 y 8 emplea tanto paralelismo funcional como de datos. Se emplea paralelismo funcional porque las tareas a resolver se reparten entre distintos nodos de cómputo (servidor y clientes móviles) y, dentro de éstos, entre múltiples hilos de ejecución. Por último, se emplea paralelismo de datos porque la visualización tanto del servidor como de los clientes se resuelve mediante la GPU. 2.2 Paralelismo de Datos en CPU Muchas aplicaciones de cálculo científico y multimedia requieren el rápido procesamiento de grandes volúmenes de datos. Este tipo de aplicaciones se ven favorecidas por arquitecturas capaces de realizar paralelismo de datos mediante SIMD. Este hecho motivó el desarrollo de los procesadores vectoriales, los cuales deben su nombre a que disponen de una arquitectura orientada al procesamiento de vectores (sumas de vectores, productos escalares, etc.). A tal fin, disponen de un repertorio de instrucciones máquina que implementan operaciones donde operandos y resultados son vectores. El tamaño de los vectores que la arquitectura permite operar mediante una única instrucción se conoce como la anchura SIMD de la arquitectura. A día de hoy, la mayoría de procesadores de propósito general están dotados de ciertas capacidades de cómputo vectorial gracias a la inclusión de algunas instrucciones y registros propios de los procesadores vectoriales. La tecnología SSE (Streaming SIMD Extensions) [Int1] fue incorporada por Intel en sus procesadores con arquitectura IA-32 a partir del Pentium III. SSE introduce un conjunto de extensiones orientadas al cómputo vectorial SIMD con vectores de cuatro valores reales con precisión simple. Estas extensiones se añadieron para aumentar las capacidades del procesador en aplicaciones de comunicaciones, multimedia y gráficos tridimensionales. En concreto, estas extensiones consisten en: Ocho nuevos registros SIMD de punto flotante, notados XMM... XMM7.

24 24 Paralelización Hardware de Algoritmos Gráficos Un nuevo tipo de dato de 128 bits capaz de empaquetar cuatro valores en punto flotante de simple precisión (32 bits). Un nuevo conjunto de instrucciones SIMD para procesamiento de datos enteros y flotantes. Esta tecnología permite emitir dos instrucciones SSE por ciclo de ejecución, por lo que varias instrucciones se puedan ejecutar en paralelo. Para poder utilizar estas extensiones, el sistema operativo debe soportarlas, ya que que es preciso que los nuevos registros se guarden en cada cambio de contexto. Gracias a SSE, las instrucciones aritmético-lógicas entre vectores de cuatro números pueden realizarse en dos ciclos de ejecución de la CPU. La excepción es la división, que consume 22 ciclos. Por otro lado, la vectorización de algoritmos no es una tarea trivial. En la actualidad, la responsabilidad de extraer el paralelismo y de emplear las instrucciones SIMD de los procesadores es responsabilidad del programador y no del compilador. 2.3 Paralelismo de Datos en GPU Una diferencia fundamental entre una GPU y una CPU actual consiste en que los procesadores gráficos tienen una arquitectura de computación en flujo 2, distinta de la arquitectura de Von Neumann que es en serie. En el modelo de computación en flujo, véase [KRD + 3], los datos de entrada se representan mediante un vector que se define como un conjunto ordenado de datos del mismo tipo. Este vector se envía como entrada al procesador de flujo, provocando su activación. Entonces, el procesador aplica una función 3 sobre cada dato del vector de entrada, produciendo un vector de resultados como salida. La característica principal de esta forma de procesamiento es que los datos del vector de entrada se procesan de manera individual, con lo que puede paralelizarse su cómputo mediante el uso de múltiples unidades de computación. El proceso gráfico se adapta muy bien a este modelo de procesamiento vectorial. Ello se debe a que éste se divide en diversas etapas, cada una de las cuales recibe un conjunto de datos de entrada y genera otro conjunto de datos de salida. Estas etapas realizan labores muy concretas, y por tanto pueden representarse mediante funciones. En las siguiente secciones definiremos el proceso gráfico y cómo se implementa en una GPU. 2 Conocida en inglés como stream processing. 3 Conocida en inglés como kernel.

25 Paralelización Hardware de Algoritmos Gráficos El Proceso Gráfico En esta sección se presenta el núcleo o principal componente de la visualización de gráficos en tiempo real: el proceso gráfico 4. La principal función del proceso gráfico es generar una imagen bidimensional en función de una cámara virtual, objetos tridimensionales, fuentes de luz, ecuaciones de iluminación, texturas, etc. El proceso gráfico está dividido en múltiples etapas. La ventaja de esta división es que múltiples etapas pueden ejecutarse en paralelo acelerando el rendimiento general del proceso. Si bien, esto también implica que la velocidad del proceso está determinada por la etapa más lenta, sin importar lo rápidas que sean las demás. Esta velocidad suele expresarse como el número de imágenes que el proceso gráfico es capaz de generar en un segundo. Habitualmente, esta medida se denota como imágenes (o fotogramas o marcos de animación) por segundo 5. Una completa descripción del proceso gráfico escapa del ámbito de este capítulo. Existen múltiples libros publicados que ofrence una descripción detallada del proceso gráfico, véase por ejemplo [AMHH8, OSW + 5]. Realizaremos a continuación un breve repaso a las principales etapas conceptuales del proceso gráfico y su funcionalidad: La etapa de aplicación Como su nombre indica, esta etapa es gestionada por la aplicación y se implementa sobre CPUs de propósito general. Esta etapa suele gestionar la lógica de la aplicación y llevar acabo tareas como detección de colisiones, simulaciones físicas, animación, etc. La etapa de geometría Esta etapa suele implementarse en la GPU, y es responsable de la mayoría de las operaciones con polígonos y vértices. Esta etapa es responsable de aplicar las transformaciones a los vértices que componen la escena. Dichas transformaciones incluyen traslaciones, rotaciones, escalados y proyecciones. En esta etapa también se realizan cálculos de sombreado a nivel de vértice, como el cálculo de la iluminación. La etapa se subdivide en varias subetapas: creación de primitivas, aplicación de transformaciones, sombreado de vértices, proyección en perspectiva, recorte de primitivas con el volumen de visión y transformación a coordenadas de pantalla. Como resultado se genera un conjunto de vértices transformados y proyectados, junto con sus correspondientes datos de sombreado. 4 En Informática Gráfica, es habitual referirse al proceso gráfico por su denominación inglesa graphics pipeline, o simplemente pipeline. 5 También es habitual el uso del acrónimo fps, del inglés frames per second.

26 26 Paralelización Hardware de Algoritmos Gráficos La etapa de rasterización Esta etapa también se lleva a cabo en la GPU. Su objetivo convertir los vértices bidimensionales expresados en coordenadas de pantalla obtenidos de la etapa anterior en un conjunto de fragmentos. Cada primitiva geométrica (puntos, líneas y triángulos) que solape el centro de un píxel 6 genera un fragmento. Los fragmentos ocupan una posición en la imagen y contienen propiedades como color, profundidad, coordenadas de textura, etc. Estas propiedades se obtienen mediante interpolación a partir de los datos de los vértices de la primitiva que ha generado el fragmento. Operaciones raster Al contrario que la etapa anterior, las GPUs no suelen permitir programar esta etapa. El objetivo de esta etapa es dibujar una imagen con los fragmentos generados por la etapa anterior. En esta etapa también es responsable de eliminar superficies ocultas. Típicamente, esto se lleva a cabo mediante el algoritmo del test de profundidad (o Z-buffer) [Cat74]. También se lleva a cabo otro tipo de operaciones, como el Blending y el Dithering o los tests Alpha, Stencil, y Scissors 7. Véase [OSW + 5] para una descripción de los mismos. Aquellos fragmentos que superen unas ciertas condiciones (visibilidad, etc.) son finalmente transformados en píxeles dentro de una memoria de imagen que contiene a la imagen final 8. La memoria de imagen es una matriz bidimensional de colores, donde cada color tiene tres componentes: rojo, verde y azul El Proceso Gráfico en la GPU La GPU implementa las etapas de geometría, rasterización y operaciones raster del proceso gráfico definido en la Sección Estas etapas conceptuales se distribuyen entre distintas etapas hardware, algunas de las cuales pueden ser programadas. La Figura 2.1 ilustra las distintas etapas del proceso gráfico en la GPU. El procesador de vértices, el de geometría y el de fragmentos son etapas programables, puesto que el programador puede definir su funcionalidad mediante la carga de un programa. Estos programas se suelen denominar shaders. En lo sucesivo, emplearemos la denominación programa de vértices, de geometría o de fragmentos para nombrar a los shaders en función del procesador para el que estén destinados. 6 Abreviación de picture element. 7 Hemos utilizado estos tecnicismos en su lenguaje original debido que son ampliamente utilizados en Informática Gráfica y carecen de una traducción universalmente aceptada. 8 La memoria de imagen donde se almacena la imagen resultante del proceso gráfico suele conocerse como framebuffer.

27 Paralelización Hardware de Algoritmos Gráficos 27 Vector Índices Vector Vértices Textura Textura Memoria Textura Profundidad Stencil Imagen Ensamblador de Entrada Procesador de Vértices Procesador de Geometría Recorte + Proyección + Rasterización Procesador de Fragmentos Operaciones raster Figura 2.1.: Esquema general el proceso gráfico para GPUs con perfil Shader Model 4. Las etapas en rojo son programables El Procesador de Vértices La geometría enviada a la GPU se compone de un conjunto de vértices y de información sobre cómo unir estos vértices para formar primitivas (triángulos, etc.). El procesador de vértices es la primera etapa programable del proceso gráfico, y recibe como entrada un conjunto de vértices. La información sobre cómo se unen los vértices para formar primitivas no es accesible desde esta etapa. El procesador de vértices se encarga de ejecutar un programa de vértices sobre el conjunto de datos que recibe. En líneas generales, el procesador de vértices puede modificar, crear o ignorar los valores asociados con los vértices, tal y como su posición, color, normal y coordenadas de textura. El procesador de vértices no puede crear ni destruir vértices, y la información de un vértice no puede pasarse a otro vértice. El procesador de vértices se ajusta el modelo de computación vectorial explicado al comienzo de la Sección 2.3. Cada vértice se procesa de forma individual por un programa de vértices. Como no hay dependencia alguna entre vértices, se puede emplear cualquier número de procesadores de la GPU para procesar múltiples vértices en paralelo El Procesador de Geometría El procesador de geometría [BL6,Bly6] es una etapa optativa del proceso gráfico introducida en el perfil Shader Model 4, ver Sección Los programas para este procesador se conocen como programas de geometría. Estos programas se ejecutan después del procesado de vértices y toman como entrada una primitiva completa. Por ejemplo, cuando trabajamos con triángulos, los tres vértices son enviados como entrada al procesador de geometría. Éste puede emitir como salida cero o más primitivas. No necesariamente el tipo de primitiva de entrada ha de coincidir con el de salida. Conforme al modelo de computación vectorial, cada primitiva provoca una ejecución del programa de geometría, el cual la procesa de forma independiente al resto de primitivas.

28 28 Paralelización Hardware de Algoritmos Gráficos Este procesador permite la creación dinámica de geometría en la GPU. GPUs anteriores solo tenían la habilidad de manipular datos ya existentes. Pero con la llegada del procesador de geometría, la GPU es capaz de crear y destruir vértices en el procesador de geometría. Esto permite la creación de nuevas primitivas gráficas, tales como puntos, líneas y triángulos a partir de aquellas primitivas que fueron enviadas al principio del proceso gráfico. El procesador de geometría permite trabajar a nivel de primitiva, pudiendo acceder a cualquiera de los vértices de cada primitiva desde el programa de geometría. Esto permite una mayor flexibilidad comparado con el procesador de vértices, que tan solo permitía trabajar con los vértices de forma independiente El Procesador de Fragmentos El procesador de fragmentos es una etapa programable del proceso gráfico, y recibe como entrada un conjunto de fragmentos y sus datos asociados. Los programas que se ejecutan en este procesador se conocen como programas de fragmentos. La función típica de este procesador es establecer el color del fragmento. El valor de profundidad del fragmento también puede ser modificado. La aplicación de texturas, cálculo de niebla, test alpha, etc. también se realizan desde esta etapa. El procesador de fragmentos tiene la capacidad de descartar fragmentos, si bien esta operación puede ser costosa [AMHH8]. Como limitación, el procesador de fragmentos no puede alterar la posición x, y en pantalla del fragmento. Al igual que los procesadores de vértices y geometría, el de fragmentos también se ajusta el modelo de computación vectorial. Cada fragmento recibido provoca la ejecución del programa de fragmentos que lo procesa de forma individual. Los fragmentos son independientes, y no es posible acceder a la información de fragmentos vecinos La instanciación de Geometría La instanciación de geometría [Car5] se lleva a cabo en una etapa previa al procesador de vértices, concretamente en el ensamblador de entrada 9, ver Figura 2.1. La instanciación permite el procesado de múltiples instancias de un objeto mediante una única llamada a una función de dibujado. Es decir, se envía una única primitiva a la GPU, y ésta se encarga de replicarla tantas veces como se le solicite. Los nuevos vértices instanciados pueden ser modificados desde el procesador de vértices. Para trabajar con esta característica, la librería gráfica OpenGL proporciona una extensión específica llamada GL EXT draw instanced [Gol6]. Mediante dicha extensión podemos emplear una nueva función desde la CPU, DrawArraysInstancedEXT. Esta 9 En inglés, input assembler, para más información acerca de esta etapa no programable ver [Bly6].

29 Paralelización Hardware de Algoritmos Gráficos 29 función se comporta de forma análoga a la función de dibujado habitual de OpenGL, DrawArrays, con la diferencia de que admite un nuevo parámetro que indica el número de instancias a dibujar. Toda la información de los vértices está duplicada para cada primitiva instanciada, por lo que es necesario procesar individualmente cada una de las instancias para producir el efecto de repetición requerido. Para ello, a cada instancia se le proporciona una única variable identificadora de instancia (conocida como gl InstanceID) que puede ser empleada por el procesador de vértices para procesar de forma distinta cada instancia, generalmente aplicando una transformación. Esta técnica se emplea principalmente para objetos tales como árboles, hierba o edificios que pueden ser representados mediante la misma geometría sin parecer toscamente repetidos GPUs con Arquitectura Unificada Las GPUs más modernas (aquellas que soportan el Shader Model 4.) emplean un modelo de programación unificado. Esto significa que el procesador de vértices, el de geometría y el de fragmentos comparten un mismo modelo de programación y poseen un juego de instrucciones consistente. En las GPUs anteriores, el modelo de programación era distinto entre el procesador de vértices y el de fragmentos, y se carecía de procesador de geometría. Además, los recursos computacionales disponibles para los programas de vértices y fragmentos diferían entre sí. El modelo de programación unificada generalmente se implementa en el hardware de la GPU mediante una arquitectura unificada. Las GPUs que no se ajustan a esta arquitectura disponen de unidades de procesamiento distintas para ejecutar los programas de vértices y de fragmentos. Con la arquitectura unificada, la GPU dispone de múltiples unidades de procesamiento genéricas que pueden comportarse indistintamente como procesadores de vértices, geometría o de fragmentos según sea preciso. Cada unidad de procesamiento puede ejecutar cualquier tipo de programa (sea de vértices, geometría o fragmentos) y enviar su salida a cualquier otra unidad de procesamiento (incluido él mismo) [NVI6]. Una característica importante de la arquitectura unificada es que proporciona herramientas para realizar un mejor reparto de carga entre las distintas unidades de proceso de la GPU. Por ejemplo, en la visualización de un modelo geométricamente muy complejo pero con una iluminación muy simple, se puede optimizar mejor los recursos de la GPU asignando más unidades de procesamiento a ejecutar programas de vértices que de fragmentos.

30 3 Paralelización Hardware de Algoritmos Gráficos Las Librerías Gráficas Generalmente, el programador no tiene acceso directo al hardware. Es más, la mayoría de los fabricantes de hardware ocultan celosamente los detalles sobre cómo se implementa realmente las distintas etapas del proceso gráfico. En lugar de ello, existen algunas librerías gráficas bien definidas que ofrecen funciones y estructuras de datos que permiten operar con el hardware. DirectX [Mic1b] y OpenGL [OSW + 5] son las dos librerías dominantes para programar el hardware gráfico. El proceso gráfico es el concepto básico sobre el que se construyen ambas librerías. Microsoft es la propietaria de DirectX, por lo que su implementación se encuentra limitada a sistemas Windows y a videoconsolas como la XBox o la XBox 36. Por otro lado, OpenGL es un estándar abierto del que es posible encontrar implementaciones para una amplia variedad de dispositivos y sistemas operativos. DirectX es la librería más empleada en el mundo de los videojuegos, mientras que OpenGL es la opción predominante en entornos profesionales, académicos y para videojuegos en plataformas ajenas a Microsoft. Por último, existe una versión simplificada de OpenGL llamada OpenGL ES y específicamente orientada para dispositivos móviles. Esta librería se discute en la Sección La programación de los procesadores de la GPU precisa de lenguajes de programación específicamente adaptados. Antaño, esta programación se realizaba en lenguaje ensamblador. Ahora, en cambio, se emplean lenguajes de programación de alto nivel similares a C. Los más importantes son HLSL [Mic1c] (disponible para DirectX), GLSL [Ros6] (disponible para OpenGL y OpenGL ES) y Cg [NVI5,FK3] (disponible para DirectX y OpenGL) Evolución de la GPU Programable A lo largo de la década de 2, el hardware gráfico ha experimentado una sensible transformación. El cambio más decisivo ha sido la transición desde las GPUs de proceso gráfico fijo (aquellas que no pueden programarse) a las GPUs con proceso gráfico programable. En esta sección repasamos la evolución y los principales cambios producidos en las GPUs programables durante dicha década. En nuestra revisión usaremos el concepto de Shader Model para dividir a las GPUs en distintas generaciones. Microsoft acuñó el concepto de Shader Model para clasificar a las GPUs programables en función de sus características [Mic1c]. Shader Model comprende varios perfiles. Cada perfil define un conjunto mínimo de características que debe soportar una GPU que implemente dicho perfil. Cada perfil se construye sobre el anterior,

31 Paralelización Hardware de Algoritmos Gráficos 31 añadiendo más funcionalidades y eliminando restricciones. Generalmente, la llegada de cada nueva versión de la librería gráfica DirectX se acompaña con la definición de un nuevo perfil Shader Model. GPUs no programables Históricamente, la aceleración gráfica por hardware solamente se aplicaba al final del proceso gráfico, limitándose a realizar el dibujado de los triángulos. El primer procesador gráfico que incluyó procesamiento de vértices fue la NVIDIA GeForce 256, lanzada en Este procesador era capaz de realizar la transformación e iluminación de los vértices por hardware. NVIDIA inventó el término GPU para distinguir a la GeForce 256 del resto de chip anteriores. Shader Model 1.1 En 21, las GPUs NVIDIA GeForce 3 y ATI Radeon 85 fueron la primeras incluyeron procesador de vértices programable, inaugurando una nueva época en la Informática Gráfica [LKM1]. Estos modelos fueron los primeros en soportar el perfil Shader Model 1.1. Los programas para estas primeras GPUs programables se escribían en lenguaje ensamblador y el control de flujo (instrucciones condicionales) no estaba soportado, limitando considerablemente la complejidad de los programas que podían escribirse. Tampoco era posible todavía alterar la funcionalidad del procesador de fragmentos. Aún así, la programabilidad del hardware animó a la comunidad científica a usar la GPU para computación general. En 22, Mark Harris acuñó el término de GPGPU 1 para denominar al uso de la GPU en computación general. Shader Model 2 En el año 22 apareció el perfil Shader Model 2., que permitía la programación del procesador de vértices y de fragmentos. GPUs notables de esta generación incluyen la NVIDIA GeForce FX y la ATI Radeon 97. Se eliminaron muchas restricciones que padecían GPUs anteriores, como la limitación al número de accesos a textura, la ausencia de control de flujo, el escaso número de registros disponibles, etc. También se permitió la lectura de texturas en coma flotante, así como guardar el resultado de la visualización en este tipo de texturas. Todo esto permitió la creación de programas mucho más largos y complejos. Otro hecho importante fue la aparición de los lenguajes de programación de GPUs, como HLSL, Cg y GLSL. Estos lenguajes se diseñaron con gran influencia de C y del veterano lenguaje RenderMan Shading Language. Shader Model 3 El Shader Model 3. apareció en 24, y supuso otro nuevo aumento en las presta- 1 Acrónimo de General-Purpose Computing on Graphics Processing Units, o computación de propósito general en unidades gráficas programables.

32 32 Paralelización Hardware de Algoritmos Gráficos ciones del hardware. Entre otros, se añadió soporte limitado para realizar lectura de texturas desde el procesador de vértices. Las videoconsolas Xbox 36 de Microsoft y PlayStation 3 de Sony van equipadas con GPUs de este tipo. Shader Model 4 En 26 surgió el perfil Shader Model 4., presentado en [Bly6]. La primera GPU en soportar este perfil fue la serie 8 de NVIDIA [NVI6]. Los principales aportes de esta generación son la aparición de una nueva etapa programable (el procesador de geometría), la arquitectura unificada para todos los tipos de procesadores (vértices, geometría y fragmentos) y el soporte para tipos de datos enteros. Además, ya no es posible emplear lenguaje ensamblador, el desarrollo debe hacerse obligatoriamente en lenguajes de alto nivel. Esta generación también ha visto el nacimiento de librerías de programación orientadas a GPGPU. Entre las más conocidas podemos citar a CUDA [Hal8]. Estas librerías son discutidas en la Sección Shader Model 5 Finalmente, el perfil Shader Model 5 se presenta en 28 junto con la librería gráfica DirectX 11 de Microsoft. Como principal novedad se presentan los Compute Shaders. Para ampliar información puede consultarse [Boy8] Sistemas de Computación Paralela en la GPU Tradicionalmente, los procesadores gráficos han estado diseñados exclusivamente para resolver problemas de tipo gráfico mediante la programación del procesador de vértices, fragmentos y geometría, ver Sección No obstante, un área muy activa en el ámbito de la investigación es estudiar cómo la GPU puede aplicarse a resolver problemas de tipo genérico, es decir, en ámbito distinto al de la visualización. De esta forma, se pretende aprovechar la vasta capacidad de cómputo paralelo de la GPU para resolver problemas no gráficos. Esta forma de computación se conoce como GPGPU. Pese a que la GPU ha sido concebida para realizar tareas gráficas, la comunidad científica ha conseguido con éxito paralelizar en GPU gran variedad de algoritmos no gráficos. Ello se ha conseguido mediante una meticulosa programación de las distintas etapas del proceso gráfico. Pese a haberse obtenido grandes incrementos en prestaciones, este tipo de programación padece de importantes problemas [NVI9]: 1. Es preciso que el programador posea un importante conocimiento de la librería gráfica y de la arquitectura de la GPU. 2. Los problemas a resolver han de expresarse en términos que puedan ser entendidos por la GPU, por ejemplo, mediante texturas, coordenadas de vértices, colores, etc.

33 Paralelización Hardware de Algoritmos Gráficos El modelo de programación está muy limitado, pues se carece de ciertas características básicas de la programación. Por ejemplo, lecturas y escrituras en posiciones aleatorias de la memoria. 4. Hasta la aparición de Fermi se carecía del tipo de dato flotante con doble precisión. Esto vetaba el uso de la GPU en ciertas aplicaciones científicas. En la actualidad han surgido unas arquitecturas de desarrollo multiprocesador que permiten ayudar a los desarrolladores a utilizar la GPU programable de una forma completamente al margen del procesamiento gráfico convencional. La primera de estas arquitecturas fue CUDA, a la que han seguido otras. En esta Sección revisamos algunas de estas tecnologías CUDA CUDA (Compute Unified Device Architecture) es una arquitectura de procesamiento paralelo desarrollada por NVIDIA [Hal8] que permite utilizar la GPU como un coprocesador vectorial. Funciona con GPUs de NVIDIA dotadas de arquitectura unificada. CUDA constituye una capa de abstracción sobre el funcionamiento normal de la GPU, de forma que puede utilizarse para otros fines ajenos (o no) al uso típico de los procesadores gráficos (la visualización). CUDA consiste en una extensión mínima de los lenguajes C, C++ o Fortran. El programador escribe un programa secuencial que efectúa llamadas a una función 11 de CUDA. El programador también implementa esta función, cuya complejidad puede oscilar desde un simple método hasta un programa complejo. El secuencial se ejecuta en la CPU, pero las funciones de CUDA se ejecutan en paralelo en la GPU. Cada instancia de la función de CUDA se ejecuta en un hilo. Es responsabilidad del programador organizar estos hilos en bloques de hilos. Los bloques de hilos a su vez conforman parte de una jerarquía superior, la rejilla de bloques. Cada bloque de hilos se asocia con un multiprocesador, y todos los bloques se ejecutan en paralelo. No es posible la comunicación entre distintos bloques. Sí que se permite la comunicación entre hilos de un mismo bloque a través de la memoria compartida de 16 kb del multiprocesador. El número de hilos por bloque y la dimensión de la rejilla de bloques están limitados. Además, debe tenerse en cuenta que la memoria y los registros de cada multiprocesador se reparten entre los hilos del mismo bloque. Hay que tener presente que la GPU se convierte mediante el empleo de CUDA en una arquitectura multinúcleo de propósito general, aunque con ciertas particularidades, ya que no deja de ser un procesador gráfico. Por esta razón, la conversión o adaptación a 11 Conocida en inglés como kernel.

34 34 Paralelización Hardware de Algoritmos Gráficos CUDA de algoritmos secuenciales o paralelos de otros sistemas no es trivial en absoluto. Es necesario un profundo conocimiento de la arquitectura de la GPU programable para realizar una implementación óptima y eficiente. Para ampliar información sobre CUDA, puede consultarse el siguiente trabajo de Nickolls et al. [NBGS8] o la guía de programación CUDA [NVI1]. Ventajas de CUDA. Permite utilizar hardware de bajo coste como multiprocesador vectorial. También permite construir clústeres con mútiples GPUs. Un ejemplo es la arquitectura Tesla de NVIDIA [LNOM8]. Es un sistema eficiente de paralelismo de memoria compartida. Supone un gran avance sobre los métodos anteriores de programación de propósito general sobre GPUs (GPGPU) basados en programas de vértices/geometría/fragmentos. Desventajas de CUDA. No admite muchos de los recursos de programación típicos de los sistemas tradicionales, como la recursividad en las funciones o los números de doble precisión IEEE 754. Las transferencias de datos entre CPU y GPU pueden suponer un cuello de botella. Los hilos de procesamiento deben estar agrupados para un rendimiento óptimo y su tiempo de ejecución debe ser similar. Esto incrementa la dificultad de la programación bajo CUDA, ya que el programador debe invertir mucho esfuerzo en estructurar los datos de una forma adecuada para su procesamiento multi-hilo. El enfoque SIMD de CUDA también supone un serio inconveniente para resolver tareas inherentemente divergentes (por ejemplo, el recorrido de un grafo). CUDA sólo está disponible para arquitecturas NVIDIA Fermi Fermi [NVI9] es el nombre en código de la tercera versión de CUDA. Esta nueva edición pretende satisfacer las necesidades de la comunidad científica de forma que pueda utilizarse la GPU plenamente en un mayor número de problemas de cálculo científico intensivo. Supone una nueva arquitectura hardware mucho más potente que las versiones anteriores. Entre las novedades frente a CUDA caben destacar las siguientes [NVI9]:

35 Paralelización Hardware de Algoritmos Gráficos 35 Mejora del rendimiento de los cálculos en doble precisión. Se pasa del estándar aritmético de coma flotante IEEE al IEEE incorporando nuevas operaciones matemáticas de forma atómica. Soporte para verificación de errores de memoria ECC (Error Correcting Code). De esta forma se puede confiar en la validez de los datos almacenados en la GPU. Esta confianza es vital en ciertos tipos de aplicaciones, como las médicas y financieras, donde no se toleran errores de cálculo al más mínimo nivel. Jerarquía de memoria caché. Con anterioridad algunas aplicaciones no podían utilizar la memoria compartida de la GPU. Para solucionar esto, se proporciona una estructura jerárquica de la memoria caché que permite reutilizar datos y disminuir el número de transferencias desde/hacia memoria principal. Se modifica la estructura del hardware para permitir que diferentes funciones de CUDA pertenecientes a la misma aplicación puedan ejecutarse concurrentemente en la misma GPU. De esta manera es posible maximizar la utilización de los recursos de la GPU mediante la ejecución de funciones CUDA distintas de manera concurrente AMD (ATI) Stream Processor AMD Stream Processor es la alternativa de AMD para el desarrollo de una arquitectura unificada para GPU en oposición a CUDA de NVIDIA. En esta ocasión se presenta un tándem entre las CPUs de AMD y las GPUs de ATI (fabricante de GPUs propiedad de AMD). La motivación de esta implementación es la misma que la de CUDA, proporcionar un recurso para GPGPU que permita obtener un coprocesador vectorial de muy alto rendimiento basado en el uso de una GPU con arquitectura unificada. Al principio, AMD Stream empleaba como lenguaje de programación a una variante del lenguaje Brook de la universidad de Stanford. Pero tras la publicación de la especificación de OpenCL, ver Sección , AMD Stream ha sido adaptado para usar OpenCL como lenguaje de programación. Para más detalles de AMD Stream, puede consultarse la guía de programación [AMD1] o la página web de AMD Stream OpenCL OpenCL (Open Computing Language) [Mun8, Khr1a] es un estándar abierto y libre de royalties para la programación de aplicaciones de computación general en CPUs, GPUs y otros tipos de procesadores. Frente a las soluciones anteriores que limitan la 12

36 36 Paralelización Hardware de Algoritmos Gráficos aplicación a un solo tipo de hardware, OpenCL es un estándar abierto que proporciona una solución heterogénea y transportable entre distintas plataformas. OpenCL se basa en el lenguaje C, elimina ciertas funcionalidades específicas de cada plataforma y ofrece extensiones para operaciones vectoriales. En realidad es una capa de abstraccion montada sobre los sistemas actuales de paralelismo en CPU y GPU, permitiendo la utilizacion de todos los recursos computacionales de un sistema bajo un modelo unificado. Por tanto, es posible utilizar los recursos de la GPU de una forma similar a CUDA (incluso usando CUDA directamente), ademas de la utilizacion de todos los nucleos disponibles en la CPU.

37 3 Paralelización de Algoritmos Gráficos en CPU 3.1 Introducción Tal y como se afirmó en la Sección 2.2, la vasta mayoría de ordenadores de escritorio disponen de procesadores capaces de realizar cómputo vectorial SIMD. En este capítulo estudiaremos cómo aprovechar este potencial con el objetivo de paralelizar algoritmos básicos de Informática Gráfica. El algoritmo objeto de nuestro estudio es el trazado de rayos, usualmente conocido por la voz inglesa ray-tracing. El trabajo llevado a cabo en este Capítulo ha sido parcialmente publicado en [NU7, NUG9]. El capítulo se organiza de la siguiente forma. Primeramente, la Sección 3.2 repasa los trabajos previos más relacionados con nuestra propuesta. A continuación, en la Sección 3.3 mostramos una descripción general de la filosofía empleada en el algoritmo. La Sección 3.4 describe con más profundidad el funcionamiento del mismo. En la Sección 3.5 ofrecemos un estudio de rendimiento así como una comparación frente a otros métodos. Para finalizar, la Sección 3.6 ofrece algunas conclusiones sobre el trabajo llevado a cabo en este Capítulo El Trazado de Rayos Ray-tracing es la técnica dominante en el ámbito de la síntesis de imágenes realistas o de gran calidad, cuando el tiempo de cómputo es un factor secundario. 37

38 38 Paralelización de Algoritmos Gráficos en CPU Observador Rayos de visión Ventana de Visión Objeto de la escena Figura 3.1.: Lanzamiento de un rayo desde el centro de proyección a través de cada píxel de la ventana para determinar el color del primer objeto intersectado. Según [FvFH9], ray-tracing se emplea para determinar la visibilidad de superficies mediante el trazado de rayos de luz imaginarios desde la posición del observador hasta los objetos en la escena. Para ello, es necesario elegir un centro de proyección (la posición del observador) y una ventana de visión situada sobre un plano de visión arbitrario. La ventana se divide en una rejilla regular, en la que cada elemento de la misma corresponde con un píxel a la resolución deseada. Ahora, para cada píxel de la ventana se lanza uno o varios rayos. Los rayos parten desde el centro de proyección y avanzan hacia la escena a través del píxel, tal y como se muestra en la Figura 3.1. El color del píxel se establece al del color del primer objeto con el que intersecte el rayo. Este conjunto de rayos recibe habitualmente el nombre de rayos primarios. El trazado de rayos fue desarrollado por Appel [App68]. Posteriormente, Whitted [Whi8] extendió este algoritmo para soportar efectos visuales más avanzados, tal y como sombras, reflexión y refracción. Cuando un rayo impacta un objeto, se lanza un nuevo rayo desde el punto de impacto. Estos rayos pueden ser de tres tipos: de sombra, de reflexión o de refracción. Este conjunto de rayos se denomina habitualmente rayos secundarios, para distinguirlos de los rayos primarios lanzados desde la posición del observador. Los rayos de reflexión y de refracción pueden, de forma recursiva, generar nuevos rayos. Habitualmente, generar una imagen por medio de ray-tracing precisa de un elevado tiempo de procesamiento. Esto se debe al importante coste computacional requerido por el trazado de rayos, especialmente el cálculo de la intersección entre los rayos y los objetos. Para aplicaciones que interactúen en tiempo real con el usuario, es necesario disponer de algoritmos que permitan producir imágenes muy rápidamente. En estos entornos usualmente se emplean otro tipo de técnicas de dibujado, especialmente la rasterización de triángulos con z-buffer. Además, en los últimos años ha tenido un gran auge el desa-

39 Paralelización de Algoritmos Gráficos en CPU 39 rrollo de hardware gráfico específicamente optimizado que permite acelerar aún más el dibujado mediante rasterización de triángulos. No obstante, ray-tracing ofrece un gran número de características ventajosas sobre los algoritmos basados en rasterización, y sería beneficioso disponer de ellas para la visualización en tiempo real: Calidad y corrección de la imagen Los efectos visuales que se obtienen con métodos de rasterización de triángulos son muy limitados. Muchos de los efectos que se consiguen se deben a un meticuloso diseño manual de la escena. La aparición de GPUs programables ha permitido un gran avance en este aspecto, pero estos efectos siguen siendo difíciles de implementar y cuando se consiguen, se tratan simplemente de aproximaciones a la realidad. Esto contrasta con la facilidad y naturalidad con que ray-tracing permite calcular refracciones, reflexiones, sombras, iluminación indirecta y otros efectos de forma físicamente correcta. Escenas complejas Para escenas complejas, el hardware gráfico es limitado pues la rasterización presenta costo lineal frente al número de primitivas de la escena. Por ello se requieren técnicas de pre-procesamiento sofisticadas para reducir la geometría. Frente a ello, ray-tracing presenta complejidad logarítmica respecto al número de primitivas de la escena e incorpora occlusion culling. Por último, la naturaleza del algoritmo de ray-tracing permite una paralelización trivial. Múltiples ámbitos de aplicación El trazado de rayos no solo resulta útil para la visualización. Existen multitud de algoritmos, especialmente en el área de la síntesis de imágenes realistas, que basan su funcionamiento en el trazado de rayos, como por ejemplo, photon-mapping o final gathering [Jen96]. Además en estos casos se suelen trabajar con rayos no coherentes. Disponer un algoritmo de ray-tracing eficiente permitiría también obtener mejoras sustanciales en los tiempos de ejecución de estos algoritmos. Por todas estas razones, creemos interesante el desarrollo de nuevas técnicas que permitan aproximar el ray-tracing al mundo de las aplicaciones en tiempo real Coherencia Espacial en Ray-Tracing Para mejorar la eficiencia en el cómputo de las intersecciones rayo-objetos, es habitual explotar la coherencia espacial para reducir drásticamente el número de intersecciones a calcular [Wat]. La idea de la coherencia espacial es simple. El espacio ocupado

40 4 Paralelización de Algoritmos Gráficos en CPU por la escena se subdivide en regiones. Ahora, en lugar de calcular la intersección entre un rayo y todos los objetos de la escena, tan solo es necesario determinar las regiones del espacio atravesadas por el rayo y realizar la intersección con los objetos incluidos en dichas regiones, ignorando el resto. Para poder aprovechar la coherencia espacial, es necesario el uso de estructuras de datos espaciales [Sam89]. Una estructura de este tipo es aquella que organiza alguna geometría en un espacio n-dimensional, en nuestro caso 3D. La organización espacial de estas estructuras suele ser jerárquica, pues se basan en la descomposición recursiva del espacio. Esto significa que en la mayoría de las situaciones es posible representarlas mediante un árbol. En ray-tracing es muy frecuente el uso de los árboles octales (u octrees) [SW88, Wat] y de los árboles-kd [Ben75, dbcvko8]. A continuación se describe el proceso general de calcular la intersección entre los objetos de la escena y un rayo por medio de un árbol de indexación espacial. Partiendo desde el nodo raíz, se recorre la estructura en sentido descendente. Para cada nodo visitado, se calcula la intersección entre el rayo y la caja envolvente del espacio representado por el nodo. Si el rayo interseca a la caja, se procede a recorrer recursivamente los nodos hijos. Una vez se ha llegado a un nodo hoja, se realiza el cálculo de intersección entre el rayo y los objetos de la escena solapados por el espacio que representa dicho nodo hoja. Otra técnica frecuente para optimizar el algoritmo de trazado de rayos consiste en explotar la coherencia entre rayos. Rayos coherentes son aquellos rayos que tienen un punto de origen y una dirección iguales o muy parecidos, ver Figura 3.2a. Los rayos primarios de ray-tracing suponen un ejemplo típico de rayos coherentes. Es fácil ver que dos rayos que parten de la misma posición y atraviesan píxeles adyacentes, tienen una alta posibilidad de realizar el mismo recorrido a través de la escena, e intersectar con los mismos objetos. Por contraposición, rayos no coherentes son aquellos que no presentan esta propiedad entre sí, ver Figura 3.2b. 3.2 Trabajos Previos Pese a que ray-tracing es una técnica muy antigua [App68], su uso para aplicaciones interactivas es relativamente nuevo. Las GPUs están optimizadas para rasterización de triángulos, aunque ha habido diversos intentos de adaptar su uso para acelerar el ray-tracing [CHH2, PBMH2, FS5, Chr5]. Actualmente, los resultados obtenidos en GPUs apenas mejoran ligeramente los resultados que se obtienen en CPUs convencionales. Ello es debido a que si bien las GPUs son arquitecturas paralelas de cómputo muy poderosas, presentan dificultades para

41 Paralelización de Algoritmos Gráficos en CPU (a) (b) Figura 3.2.: Representación bidimensional de un conjunto de rayos que cruzan un árbol-kd a) Los rayos primarios en ray-tracing son coherentes: realizan recorridos iguales o parecidos. b) Los rayos secundarios no son tan coherentes, suelen realizar recorridos distintos aun cuando tengan orígenes similares o cercanos. aplicaciones con alto control de flujo. Si bien esto posiblemente cambiará en el futuro por el continuo desarrollo de las GPUs. Por tanto, consideramos que sigue siendo interesante desarrollar técnicas de aceleración de ray-tracing en CPUs que sean adaptables a su uso en GPUs. Wald [WBWS1,Wal4] presentó un algoritmo basado en CPU que explota la coherencia existente en los rayos primarios para aplicar paralelismo de datos. Se basa en la idea de que los rayos coherentes, con mucha posibilidad, harán el mismo recorrido a través de la estructura jerárquica de indexación espacial que contiene a la escena, ver Figura 3.2a. Su propuesta, pues, consiste en recorrer la estructura espacial y realizar las intersecciones rayo-triángulo con paquetes de cuatro rayos coherentes simultáneamente. De esta forma, es posible emplear las instrucciones SIMD de los procesadores actuales para realizar el cómputo de los cuatro rayos en paralelo. Esto consigue reducir el tiempo de cálculo sensiblemente. Además, Wald presenta un meticuloso diseño orientado a minimizar la complejidad del código y los fallos de caché. Esta idea es válida para rayos primarios pues es fácil localizar rayos que a priori tengan altas posibilidades de ser coherentes, concretamente aquellos que atraviesen el mismo píxel o píxeles consecutivos de la imagen, ver Figura 3.2a. Pero falla para rayos secundarios donde no es posible hacer esta presunción, ver Figura 3.2b. También falla para rayos generados por otras aplicaciones, como por ejemplo photon mapping o final gathering que tampoco son coherentes.

42 42 Paralelización de Algoritmos Gráficos en CPU En este Capítulo presentamos una generalización de este concepto, que permite paralelizar los cálculos de distintos rayos en cualquier situación, aún cuando éstos no sean coherentes. Más recientemente, Wald et al [WGBK7a, WGBK7b] presentó, de manera independiente al trabajo expuesto aquí, el diseño de un trazador de rayos basado en el procesamiento de paquetes de rayos y el filtrado de los mismos. Los rayos se procesan en un conjunto de paquetes, y las operaciones sobre los rayos se modelan mediante filtros. Tras realizar el filtrado, los rayos que aún deben ser procesados se empaquetan en un nuevo paquete. Los filtros pueden procesar los rayos en paralelo mediante instrucciones SIMD. Los autores han empleado un simulador para estudiar la eficiencia SIMD de este diseño para diferentes anchuras de SIMD (desde 4 hasta 16). y para diferentes tamaños del paquete de rayos (desde 2 2 hasta 64 64). Los resultados ofrecidos muestran que la eficiencia de este método decae notablemente para anchuras grandes de SIMD. Es decir, no son capaces de aprovechar toda la capacidad de paralelización ofrecida por el hardware. Aún así, y gracias al empaquetamiento de rayos, se obtiene mejor eficiencia que con propuestas anteriores. No obstante, en su trabajo los autores advierten de que no disponen de una implementación real del algoritmo, y sus resultados son simulados. El método que proponemos, además de haber sido implementado y validado en hardware real, no se ve afectado negativamente al emplear una máquina con una anchura de SIMD grande. También es capaz de aplicar la paralelización hardware incluso en el cálculo de rayos no coherentes. 3.3 El Trazado de Rayos Vectorizado La presente Sección describe el concepto general y la filosofía empleada en nuestra solución vectorizada del trazador de rayos paralelo. La Sección 3.4 describirá los detalles de implementación Motivaciones Dado un árbol de indexación espacial que contiene la escena, el algoritmo clásico de ray-tracing recorre dicho árbol de forma recursiva una vez por cada rayo. La Figura 3.3 ilustra este algoritmo para el caso de un árbol binario. Cada nodo del árbol se ha de visitar una vez por cada rayo que lo cruce. Wald en cambio, propone recorrer el árbol una vez por cada paquete de cuatro rayos, ver Figura 3.4. Más tarde, profundizó en esta idea al emplear paquetes de hasta 64 64

43 Paralelización de Algoritmos Gráficos en CPU 43 r 1 r 1 r 1 Figura 3.3.: Recorrido con un rayo rayos. En estos casos, cada nodo del árbol se visita una vez por cada paquete de rayos que lo cruce. Al tomar los rayos en paquetes, si éstos son coherentes, muy posiblemente realizarán el mismo recorrido y será posible aplicar operaciones vectoriales SIMD para paralelizar su procesamiento. No obstante, dependiendo de las propiedades del paquete, el procesamiento SIMD puede provocar una mala utilización de los recursos computacionales. Los paquetes de rayos incoherentes son penalizados puesto que los rayos pueden volverse inactivos durante el proceso. Cuando algún rayo de un paquete no interseca con un nodo hijo, pero los demás rayos sí lo hacen, se procede a descender por ese nodo hijo con el paquete completo. El rayo que no interseca con ese hijo se marca como rayo no activo, y no será tenido en cuenta en el cálculo de las intersecciones. En este caso, aunque podamos realizar cuatro operaciones en cada instrucción SIMD, solo un número menor de estas operaciones realiza trabajo real. En el peor de los casos, tendremos un paquete con un solo rayo activo, el cual requiere el mismo tiempo de proceso que un paquete con cuatro rayos activos. Así, el rendimiento en este peor caso es semejante a los algoritmos clásicos. La Figura 3.5 ilustra este hecho. Nuestra propuesta avanza en esta idea, pero propone generar un único paquete que contiene al conjunto completo de rayos disponibles, generalmente cientos de miles. Con este paquete se realiza un único recorrido de la estructura de indexación espacial. Es indudable que la posibilidad de que todos los rayos efectúen el mismo recorrido por el árbol (es decir, sean coherentes) es muy pequeña. Por tanto, en cada nuevo nivel del árbol se reorganizan todos los rayos disponibles y se genera un nuevo paquete por cada

44 44 Paralelización de Algoritmos Gráficos en CPU r 1 r 2 r 3 r 4 r 1 r 2 r 3 r 4 r 1 r 2 r 3 r 4 Figura 3.4.: Recorrido del árbol de indexación espacial con un paquete de cuatro rayos coherentes. nodo hijo disponible. Estos nuevos paquetes solo contienen los rayos que intersecan a la caja envolvente del nodo hijo correspondiente. Ahora, cada subárbol se recorre con su respectivo paquete de rayos. La Figura 3.6 ilustra este proceso para un árbol binario, si bien la idea es extrapolable a otro tipo de árboles, como los octales. Este acercamiento proporciona las siguientes ventajas: Siempre que existan dos o más rayos que necesiten atravesar el mismo nodo del árbol, éstos lo hacen a la vez. Esto se traduce en una posibilidad mucho mayor de disponer en cada nodo del árbol de varios rayos a los que procesar en paralelo. Los rayos tan solo visitan aquellos nodos a los que intersecten. Cada vez que se descienda un nivel del árbol, los rayos se clasifican y se reordenan de forma implícita. Hay una utilización máxima de los recursos computacionales. Por un lado, se trabaja con grupos de rayos mayores que la anchura SIMD. Por otro lado, los rayos se van clasificando conforme atraviesan el árbol, lo que elimina la necesidad de marcar rayos como no válidos. No existirán rayos que provoquen cómputo inútil excepto cuando el número de rayos a procesar en un nodo no sea múltiplo de la anchura SIMD. Los nodos del árbol se visitan una única vez, y no decenas de miles como en algoritmos previos. Por tanto, se reduce en gran medida en número de accesos que hay que realizar a la estructura de indexación espacial de la escena. Un menor núme-

45 Paralelización de Algoritmos Gráficos en CPU 45 r 1 r 2 r 3 r 4 r 1 r 2 r 3 r 4 r 1 r 2 r 3 r 4 r 1 r 2 r 3 r 4 r 1 r 2 r 3 r 4 r 1 r 2 r 3 r 4 Figura 3.5.: Recorrido del árbol con un paquete de cuatro rayos no coherentes. El paquete tiende a romperse. Los rayos tachados representan rayos no válidos. Se supone una anchura SIMD de cuatro. ro de accesos a memoria principal se traduce en una reducción de latencias y del número de fallos de memoria caché. El algoritmo permite su uso con una anchura SIMD arbitraria. Esta característica lo hace válido para su implementación en distintas arquitecturas. En algoritmos anteriores, la eficiencia cae drásticamente si no es posible obtener paquetes de rayos coherentes. En nuestro método, en cambio, los rayos se clasifican automáticamente al avanzar por la estructura, lo que permite mantener las citadas ventajas. Se requiere de una nueva estructura de datos que contenga los rayos a procesar. Esto no incurre en un mayor número de accesos a memoria frente a los algoritmos clásicos de ray-tracing, pues tan solo se organiza de forma agrupada la misma información que también es necesario almacenar y acceder en dichos algoritmos clásicos. Hay que tener en cuenta que usar este algoritmo para ray-tracing, o, en general, iluminación global, supone que la aplicación debe generar conjuntos grandes de rayos para calcular las intersecciones simultáneamente en todos ellos. Esto supone que el algoritmo se debe organizar según un esquema primero a lo ancho en lugar de primero en profundidad. Por ejemplo, para ray-tracing, se deben generar todos los rayos primarios, luego todos los secundarios, etc...

46 46 Paralelización de Algoritmos Gráficos en CPU r 1 r 2 r 3 r 4 r 5 r 6... r n r 2 r 3 r 5 r 6... r n2 r 1 r 4 r 5... r n3 r 2 r 6... r n4 r 3 r 6... r n5 r 1 r 4 r 5 r 4 r 5... r n6 Figura 3.6.: Recorrido del árbol de indexación espacial con un paquete de n rayos. En cada nivel, los rayos se reorganizan para formar nuevos paquetes. Los rayos tachados representan rayos no válidos. Se supone una anchura SIMD de cuatro. Si bien esto puede suponer un incremento en uso de memoria, creemos que la reducción de los tiempos de cálculo hace que merezca la pena. Otro beneficio adicional es que este esquema permite la implementación vectorizada y eficiente de otras partes del algoritmo, como puede ser la evaluación del modelo de iluminación local, o la generación de los rayos secundarios. 3.4 Recorrido del Árbol-kd Los procesadores actuales incorporan extensiones Single Instruction, Multiple Data (SIMD) que posibilitan la realización de múltiples operaciones en coma flotante (usualmente cuatro) con una sola instrucción. Correctamente usadas, estas instrucciones permiten aumentar el rendimiento de aplicaciones de cómputo intensivo. Por su gran disponibilidad, hemos decidido emplear el juego de instrucciones SSE de Intel para explotar el paralelismo de datos del trazado de paquetes de rayos. Las instrucciones SSE de Intel se describieron en la Sección 2.2. Esta Sección detalla la implementación del trazador de rayos vectorizado. En nuestra implementación empleamos un árbol-kd [Ben75,dBCvKO8]. Un árbolkd es un árbol binario de indexación espacial en el que cada vóxel 1 se divide en dos me- 1 Contracción de volumetric pixel, o más correctamente, de volumetric picture element.

47 Paralelización de Algoritmos Gráficos en CPU 47 diante planos perpendiculares a los ejes. Cada vez que se desciende un nivel del árbol, se alterna el eje utilizado para seleccionar el plano divisor. En nuestra implementación, el vóxel representado por el nodo raíz se divide en dos subvóxeles mediante un plano divisor paralelo al eje-x. Sus descendientes se dividen mediante planos paralelos al eje-y, y los nietos de la raíz mediante planos paralelos al eje-z, y así sucesivamente. Por motivo de eficiencia, en nuestra implementación añadimos la restricción adicional de que el plano que divide a un vóxel debe pasar justo por el centro. Por tanto, cada vóxel se divide en dos subvóxeles del mismo tamaño. No obstante, el algoritmo propuesto se puede modificar fácilmente para trabajar con planos de separación no situados en el centro. La principal razón de esta elección frente a otras estructuras tales como octrees o BVHs (Bounding Volume Hierarchies) es la simplicidad del algoritmo de recorrido. Para cada nodo y rayo solo hay que tomar dos decisiones: o seguir o no seguir por cada uno de los dos nodos hijos. Además este tipo de estructuras jerárquicas se adaptan bien a la complejidad de la escena. Y su paralelización con instrucciones SIMD es sencilla. No obstante, el algoritmo propuesto es extensible a otro tipo de estructuras, como el octree. Para poder paralelizar los cálculos, en cada nodo hemos de tener disponible todos los rayos que lo atraviesen. Primeramente se expondrá el funcionamiento del algoritmo para un único rayo, y posteriormente se expandirá para su uso con todos los rayos simultáneamente Algoritmo de Recorrido para un Rayo Revelles et al. propuso un algoritmo paramétrico para el recorrido de octrees muy simple y eficiente [RUL]. Para nuestro trabajo, hemos reformulado y simplificado este algoritmo conforme a nuestra representación basada en árboles-kd con planos divisores en la mitad de los vóxeles. En lo que sigue, describimos los pasos específicos de esta reformulación. Por tanto, referimos al lector a [RUL] para una completa descripción y demostración de este algoritmo. Sea r un rayo definido por sus ecuaciones paramétricas: r x = p x +td x r y = p y +td y Donde p es el vector origen, d el vector director unitario y t el parámetro real que determina un punto a lo largo del rayo. Ahora, para cada nodo del árbol-kd, definimos t x, t x1 como los valores del parámetro t del rayo para el que éste intersecta con dos planos perpendiculares al eje-x que deli-

48 48 Paralelización de Algoritmos Gráficos en CPU t y1 t x1 t xm t y tx Figura 3.7.: Nodo atravesado por el rayo, representación 2D. mitan al vóxel asociado al nodo. De forma análoga, llamamos t y,t y1 a los correspondiente valores en el eje-y, y t z, t z1 a los valores en el eje-z, ver Figura 3.7. Asumimos que t x < t x1, t y < t y1 y que t z < t z1. Este algoritmo calcula dichos valores para el nodo raíz, y a partir de ahí se recalculan de forma incremental en cada paso del recorrido del árbol. Consideremos ahora el caso de un vóxel del árbol-kd dividido en dos por un plano perpendicular al eje-x. Entonces t xm es el parámetro para el cual el rayo atraviesa el plano que divide al vóxel en dos. Puede calcularse como: t xm = (t x +t x1 )/2. Además, los valores de interseccion para el primer sub-nodo visitado son t x, t xm, y el segundo de ellos t xm, t x1. La Figura 3.7 ilustra estos valores. Los valores t ym, t zm se definen, calculan y usan de forma análoga en los casos de vóxeles divididos por planos perpendiculares al eje-y o al eje-z, respectivamente. En general, el cálculo de los valores de los nodos hijos de un nodo solo requiere sumar y dividir por dos. Puede demostrarse fácilmente [RUL] que el rayo intersecta al nodo si se cumple que: max(t x,t y,t z ) < min(t x1,t y1,t z1 ) El algoritmo funciona de forma recursiva. Para cada nodo interno, se actualizan los parámetros del rayo para su primer hijo, y se determina si lo intersecta o no. Si esto ocurre, se procede inmediatamente con dicho nodo. Posteriormente, se repite el proceso para el segundo hijo. Durante el recorrido de la estructura siempre descenderemos en primer lugar por el primer nodo situado en la dirección del rayo. De esta forma, una vez se encuentre una intersección entre un rayo y un objeto de la escena podemos terminar la recursividad. Cualquier otra intersección entre el rayo y los objetos de la escena que pudiera existir se encontrará siempre más alejada que la intersección ya localizada.

49 Paralelización de Algoritmos Gráficos en CPU 49 recorrer ( n, listarayos, eje ) { if( numrayos = ) return ; if( eshoja (n) ) intersectrg ( n, listarayos ); else foreach hijo h i of n { listarayosh i = calcnodo ( listarayos, eje ); recorrer ( h i, listarayosh i ); } } Listado 3.1: Recorrido para múltiples rayos El algoritmo de recorrido del árbol-kd para múltiples rayos funciona de forma similar al anterior. La idea consiste en procesar simultáneamente todos los rayos disponibles, y realizar un único recorrido del índice espacial para todos ellos. Su pseudocódigo puede verse en el Listado 3.1. Cada nodo n recibe una lista de rayos que lo intersectan llamada listarayos. En esta lista se almacena para cada rayo los valores de los parámetros de entrada y de salida del vóxel: t x, t y, t z, t x1, t y1 y t z1. Estos parámetros se encuentran ya debidamente ajustados para el nodo n. También se recibe una variable e je que puede valer x, y ó z en función del plano por el que toque dividir el vóxel. Si el tamaño de la lista es cero, terminamos. En caso contrario, determinamos si el nodo n es hoja o interno. En caso de ser hoja, la función intersectrg calcula si los rayos que han llegado hasta el nodo intersectan con los triángulos indexados dentro del nodo. Si estamos en un nodo interno, la función calcnodo emplea SSE para actualizar los parámetros de todos los rayos para el primer hijo h 1 y para determinar cuáles de ellos lo intersectan. Todos aquellos rayos que intersecten a dicho hijo son copiados a una nueva lista listarayosh 1. Por tanto, esta nueva lista contendrá un número de rayos comprendido entre cero y el número de rayos que atraviesan al nodo padre n. A dichas listas no se copiarán aquellos rayos para los que ya se haya encontrado una intersección. A continuación, y de forma recursiva, se recorre el primer hijo suministrándole la nueva lista de rayos calculada. Una vez se termine de recorrer ese hijo, se procede de forma análoga con el segundo hijo. El Listado 3.2 muestra el código en lenguaje C de la función calcnodo. En dicho listado, el subíndice e je puede ser x, y ó z en función del plano por el que dividamos el vóxel. Además, las variables result, t f ar, t near y t e je,m son vectores de tamaño 4. Como puede verse, el número total de operaciones requeridas para determinar si cuatro rayos intersectan un nodo son: una suma, una multiplicación, una operación de máximo, otra de mínimo y una de comparación entre el resultado de las dos anteriores, todas ellas SSE.

50 5 Paralelización de Algoritmos Gráficos en CPU calcnodo ( listarayos, eje ) { Float4 t e je, m, t f ar, t near ; Int4 result ; // Parte SIMD. Para cada rayo: // a) Calcular nuevo parámetro t m. // b) Determinar intersección rayo-vóxel, almacenar resultado en result. for ( i =; i< listarayos. tama~no ; i=i+4 ) { t e je, m =.5 * ( listarayos [i].t e je + listarayos [i].t e je1 ); MIN3 (t f ar, listarayos [i].t x1, listarayos [i].t y1, listarayos [i].t z1 ); MAX3 (t near, listarayos [i].t x, listarayos [i].t y, listarayos [i].t z ); LE( result, t near, t f ar ); // Parte no SIMD. // A~nadir los rayos que intersequen a una nueva lista. // Actualizar parámetros de cada rayo con el nuevo valor t m. } for ( int j =; j <4; j++ ) { if( result [ j] == TRUE ) listarayoshijo. a~nadirrayo ( listarayos [i+j], t e je, m ); } } return listarayoshijo ; Listado 3.2: Determinar si los rayos intersectan con el nodo usando SSE y el compilador GCC Algoritmo de Recorrido para Múltiples Rayos El Listado 3.3 muestra el código en C necesario para configurar en el compilador GCC de GNU los tipos de datos y las operaciones SSE necesarias para ejecutar el Listado 3.2. Al trabajar con múltiples rayos de manera simultánea puede ocurrir que diferentes rayos requieran recorrer el árbol de indexación espacial en distinto orden. El orden en el que un rayo ha de visitar los nodos en cada paso del algoritmo depende de los signos de las tres componentes del vector director del rayo. Por tanto, esto podría ocurrir si existen rayos con vectores directores con distinto signo, lo cual es muy probable. En estos casos no nos es posible recorrer una única vez el árbol con todos los rayos simultáneamente sin perder la deseable característica de que una vez localizada la primera intersección, ésta sea la más próxima. La solución empleada para solventar este problema consiste en que en un primer paso se clasifican todos los rayos en ocho grupos en función de los signos de las componentes de sus vectores directores. Ahora, como todos los rayos de un mismo grupo recorrerán el árbol de indexación exactamente en el mismo orden, puede aplicarse el algoritmo de recorrido sin problema para cada uno de los grupos.

51 Paralelización de Algoritmos Gráficos en CPU 51 typedef float v4sf attribute (( vector_size (16))); typedef int v4si attribute (( vector_size (16))); // 4 floats vector with 128 bits union Float4 { v4sf v ; float f [4] ; } ; // 4 ints vector with 128 bits union Int4 { v4si v ; int i [4] ; } ; // res = min(a, b, c) (res,a,b,c are Float4) # define MIN3 ( res, a,b, c ) \ ( res ).v = builtin_ia32_minps ( (a).v, (b).v ) ;\ ( res ).v = builtin_ia32_minps ( ( res ).v, (c).v ) ; // res = min(a, b, c) (res,a,b,c are Float4) # define MAX3 ( res, a,b, c ) \ ( res ).v = builtin_ia32_maxps ( (a).v, (b).v ) ;\ ( res ).v = builtin_ia32_maxps ( ( res ).v, (c).v ) ; // res = a <= b (res is Int4, a,b are Float4) # define LE( res, a, b ) \ ( res ).v = builtin_ia32_cmpleps ( (a).v, (b).v ) ; // res = a >= b (res is Int4, a,b are Float4) # define GE( res, a, b ) \ ( res ).v = builtin_ia32_cmpgeps ( (a).v, (b).v ) ; Listado 3.3: Configuración de los tipos de datos y las operaciones vectoriales para el compilador GCC. Con esta idea, tendremos que recorrer el árbol como máximo ocho veces, número que aún resulta muy inferior a las decenas de miles de veces que requieren recorrerlo los algoritmos convencionales. En la práctica, para rayos primarios nunca es necesario recorrerlo más de cuatro veces, siempre que el vector normal al plano de visión sea paralelo a uno de los ejes Disposición de los Rayos en Memoria A la hora de diseñar las estructuras de datos que almacenen los rayos, se debe elegir una disposición de los datos en memoria que permita maximizar la eficiencia y tiempo, teniendo en cuenta la implementación mediante instrucciones SIMD [Int1, Kli1].

52 52 Paralelización de Algoritmos Gráficos en CPU Se emplean dos estructuras de datos para gestionar los rayos. Una es global, puede accederse desde cualquier nodo y almacena todos los rayos y sus atributos; mientras que la otra pertenece a cada nodo en concreto y solo almacena algunos datos necesarios para el recorrido, así como punteros a la estructura global. Para cada rayo r es necesario almacenar de forma global: Su vector director d y origen p. El valor máximo del parámetro t del rayo permitido. Un marcador que indica si se ha encontrado una intersección con un triángulo. El identificador del triangulo más cercano intersectado. El valor del parámetro t del rayo para el cual lo intersecta. Las coordenadas paramétricas del triángulo en el punto de intersección. Como se explicó en la descripción del algoritmo, durante el recorrido del árbol cada nodo recibe una lista de rayos que le intersectan. Dicha lista es una estructura de datos local para cada nodo, y almacena para cada rayo los valores de los parámetros del rayo de entrada y de salida del vóxel (t x, t y, t z, t x1, t y1 y t z1 ), pues dependen del nodo en el que nos encontremos. También se almacena para cada rayo un puntero a la estructura global que almacena el resto de información del rayo. A estos datos se les aplicará operaciones SIMD, por lo que para obtener el máximo rendimiento deben de almacenarse con una organización concreta denominada estructura de vectores tal y como se aprecia en la Figura 3.8a. En esta organización, se almacenan en un vector los t x de todos los rayos, en otro vector los t y y así sucesivamente. Esta estructuración es menos natural que la clásica vector de estructuras que se muestra en la Figura 3.8b, pero es necesaria para alcanzar la máxima eficiencia con SSE. En dichas figuras, t ( j) xi representa el valor de la componente x del parámetro t para el rayo j-ésimo. i vale cero para los parámetros de entrada y uno para los de salida. Lo mismo se aplica para las componentes y,z. Un problema que presenta esta estructura es que para recuperar los distintos parámetros de un rayo, habrá que realizar accesos a posiciones distantes de memoria, especialmente si la lista de rayos es larga. Esto provoca un mal aprovechamiento de la memoria caché. Para solventar el problema, empleamos una organización de memoria mixta entre las dos anteriores [Kli1], tal y como se aprecia en la Figura 3.8c. Los rayos se almacenan en paquetes de cuatro. Cada paquete es una estructura que contiene un vector para las componentes x de los parámetros de entrada de los cuatro rayos, otro para las componentes y,

53 Paralelización de Algoritmos Gráficos en CPU 53 Estructura Parámetros entrada eje X Parámetros entrada eje Y Parámetros entrada eje Z t () x t (1) x t (2) xt (3) x t () y t (1) y t (2) yt (3) y t () z t (1) z t (2) zt (3) z... t (n) x... t (n) y... t (n) z Parámetros salida eje X Parámetros salida eje Y Parámetros salida eje Z t () x1 t (1) x1 t (2) x1t (3) x1 t () y1 t (1) y1 t (2) y1t (3) y1 t () z1 t (1) z1 t (2) z1t (3) z1 (a)... t (n) x1... t (n) y1... t (n) z1 Estructura 1 Estructura 2 t (1) x t () xt () y t () z t () x1 t () y1 t () z1 t (1) y t (1) zt (1) x1 t (1) y1 t (1) z1... t (n) z1 (b) t () xt (1) x t (2) x t (3) x t () yt (1) y t (2) y t (3) y t () xt (1) z t (2) z t (3) z t () x1t (1) x1 t (2) x1 t (3) x1... t (n) z1 (c) Figura 3.8.: Disposición de rayos en memoria. a) Estructura de Vectores. b) Vector de Estructuras. c) Mixto. etc. Si el número de rayos no es múltiplo de cuatro, el último paquete estará incompleto y se rellenará con datos que no serán tenidos en cuenta a la hora de obtener los resultados. Aparte de lo anterior, surge un nuevo problema relativo a la gestión de memoria que puede afectar negativamente a la eficiencia del método. Para cada nuevo nodo visitado es preciso generar una nueva lista de rayos. Estas listas necesitan memoria. Solicitar y liberar memoria en cada paso del algoritmo incrementa la sobrecarga del método. Para evitarlo, en nuestra implementación empleamos una pila de rayos. Al construir el árbol, se reserva memoria para una pila de tamaño suficiente. Para cada nuevo recorrido, se añaden a esa pila todos los rayos a intersectar y se envía al nodo raíz. Las listas de rayos para los sucesivos nodos visitados se añaden y retiran del tope de la pila según se avance

54 54 Paralelización de Algoritmos Gráficos en CPU r 1 r 2 r 3 r 4 r 5 r 6 r 7 r 1 r 2 r 4 r 5 r 1 r 4 r 1 r 2 r 3 r 4 r 5 r 6 r 7 r 1 r 2 r 4 r 5 r 1 r 4 Figura 3.9.: Estado de la pila de rayos en el nodo C o retroceda por la estructura de indexación. Este sencillo mecanismo elimina la necesidad de gestionar dinámicamente la memoria. La Figura 3.9 muestra el estado de la pila para el nodo etiquetado como C. Puede apreciarse como solo es necesario mantener en la pila la lista de rayos del nodo C y de los nodos situados entre éste y la raíz (A y B). Si el número de rayos en un nodo no es múltiplo de cuatro (número de operaciones que se pueden vectorizar en SSE), se completa con rayos que no serán tomados en cuenta Cómputo Rayo-Triángulo Para las intersecciones rayo-triángulo, hemos usado dos variantes: El algoritmo de Möller-Trumbore [MT97] estándar, que realiza un test de un rayo con un triángulo. Una variante optimizada del anterior, con las normales y diversos resultados intermedios pre-calculados. Además, los datos de los triángulos indexados en cada nodo se almacenan en paquetes de cuatro según una disposición mixta como la descrita en la Sección El cálculo de la intersección se realiza entre un rayo y cuatro triángulos simultáneos mediante operaciones SIMD (SSE). Se obtiene mejores resultados en cuanto a tiempo con la segunda opción. También se reduce el uso de memoria, dado que al reducir el coste de la operación rayo-triángulo,

55 Paralelización de Algoritmos Gráficos en CPU 55 Figura 3.1.: Escenas empleadas en nuestros experimentos: a) Stanford Bunny, b) Stanford Dragon, c) Happy Buddha. podemos emplear árboles menos profundos. Por tanto dicha segunda opción es la que ha sido empleada en las pruebas. 3.5 Rendimiento Para estudiar la eficiencia de este algoritmo, hemos empleado tres diferentes escenas: Stanford Bunny (69451 triángulos), Stanford Dragon (,8 millones de triángulos) y Happy Buddha (1,1 millones de triángulos). Las escenas empleadas han sido las mismas para todos los algoritmos. Las Figuras 3.1a, b y c han sido generadas empleando el algoritmo propuesto. La resolución de la visualización fue de píxeles, y se ha lanzado un rayo por cada píxel. Para comparar el algoritmo propuesto, se ha realizado una aproximación al comportamiento del algoritmo de Wald, [Wal4, WBWS1, WGBK7b]. Ésta se basa en nuestro propio algoritmo, pero se ha limitado el número máximo de rayos que pueden recorrerse juntos a paquetes de 2 2 y a rayos. De esta forma, es preciso recorrer el índice espacial repetidas veces con pequeños paquetes rayos, tal y como fue propuesto por dicho autor. También se compara el algoritmo propuesto con un algoritmo recursivo clásico que recorre la estructura una vez por cada rayo individual. Se han obtenido los resultados para una profundidad máxima permitida del árbol de indexación espacial de 16, 18, 2, 22 y 24 y se han seleccionado los mejores resultados para cada algoritmo y escena. Para la mayoría de los casos, la profundidad de 2

56 56 Paralelización de Algoritmos Gráficos en CPU ha demostrado ser la más óptima. Todas las mediciones han sido tomadas en un PC de escritorio dotado con una CPU Intel Core2 Duo a 2.6 GHz y 2 GB de RAM. Solamente se ha empleado un núcleo de procesamiento del procesador. Este procesador está dotado del juego de instrucciones SSE, que permite realizar operaciones aritméticas y lógicas en paralelo con una anchura SIMD de cuatro Comparación para Rayos Coherentes Para cada caso, se han generado una animación de cien imágenes en las que la cámara rotaba alrededor de la escena. Al tener los rayos el mismo punto de origen y atravesar píxeles consecutivos del plano de la imagen, los rayos generados presentan alta coherencia entre sí. Los diagramas de la Figura 3.11 muestran gráficamente el número medio de millones de rayos (en adelante, MegaRayos) que ha sido posible procesar por segundo para las diferentes escenas y los cuatro diferentes algoritmos. Se ofrecen los resultados para los experimentos con rayos coherentes y no coherentes. Como puede apreciarse en tales Figuras, el algoritmo clásico resulta menos eficaz en el experimento con rayos coherentes para todas las escenas estudiadas. Los otros tres algoritmos le superan ampliamente al ser capaces de paralelizar los cálculos. Entre estos tres algoritmos, la versión que recorre la estructura con paquetes de 2 2 rayos obtiene resultados ligeramente peores. Los dos restantes algoritmos obtienen los mejores tiempos, muy similares entre sí. La versión que emplea paquetes de 2 2 rayos, al ser éstos coherentes, consigue casi siempre aprovechar el ancho de SIMD proporcionado por las instrucciones SSE del procesador. Si bien, no existe garantía alguna de que los cuatro rayos efectúen el mismo recorrido a través de la estructura de indexación, y en ocasiones, el algoritmo se ve obligado a fraccionar dicho paquete. Estos paquetes más pequeños reducen el grado de paralelismo. En cambio, al trabajar con paquetes de rayos de mayor tamaño, es posible extraer mayor volumen de datos a procesar. Esto redunda en una menor posibilidad de que los paquetes se fraccionen hasta tener tamaño inferior a cuatro Comparación para Rayos No Coherentes A lo largo de este Capítulo hemos afirmado que recorrer el árbol con un único paquete que comprenda a todos los rayos disponibles permite maximizar el paralelismo en el cómputo de rayos no coherentes. Los rayos, en su recorrido por la estructura arbórea, se irían clasificando de forma natural y sin coste alguno a lo largo de las distintas ramas.

57 MRayos/s MRayos/s MRayos/s Paralelización de Algoritmos Gráficos en CPU 57 1,4 1,2 1,8,6,4,2 1 2x2 64x64 Todos Tamaño del Paquete (a) Coherentes No coherentes 1,4 1,2 1,8,6,4,2 1 2x2 64x64 Todos Tamaño del Paquete (b) Coherentes No coherentes 1,4 1,2 1,8,6,4,2 1 2x2 64x64 Todos Tamaño del Paquete (c) Coherentes No coherentes Figura 3.11.: Rendimiento medio en MegaRayos por segundo al visualizar a) Stanford Bunny, b) Stanford Dragon y c) Happy Buddha a una resolución de pantalla de píxeles.

58 58 Paralelización de Algoritmos Gráficos en CPU De esta forma, se aumenta posibilidad de que a un nodo concreto del árbol llegue un paquete con más de un rayo, y por tanto, se pueda procesar en paralelo. Para demostrar esta afirmación de forma empírica, hemos construido un generador capaz de lanzar rayos aleatorios de manera uniforme, sin que sean más densos en unas regiones que otras. Para cada rayo a generar, se toman dos puntos con probabilidad uniforme respecto al área de la esfera envolvente mínima de la escena [San76, Sbe93]. Un punto se emplea como punto origen del rayo y el otro para generar un vector director. Las gráficas en la Figura 3.11 contrastan gráficamente los resultados obtenidos en este escenario de rayos altamente incoherentes. Si comparamos entre sí los resultados obtenidos en el escenario de rayos coherentes frente al de rayos incoherentes, puede apreciarse claramente una importante caída en el rendimiento de la versión que recorre el árbol con paquetes de 2 2 rayos. De hecho, los resultados de esta versión con rayos no coherentes son muy similares a los obtenidos por el algoritmo clásico no paralelo. La razón de este degradamiento se debe a que el pequeño tamaño del paquete implica unas altas posibilidades de que éste se rompa en las partes altas del árbol. Al descender algunos niveles en la jerarquía, la mayoría de los paquetes contienen un único rayo, y por tanto, el algoritmo degenera en el algoritmo convencional no paralelo. El algoritmo que emplea paquetes de rayos consigue unos mejores resultados al ser capaz de reorganizar los rayos en cada nuevo nivel del árbol, pues elimina los no válidos y aumenta la coherencia. Pese a ello, nuestro algoritmo es capaz de ofrecer una ganancia mucho más elevada, cercana a cuatro al compararla frente al algoritmo clásico. Al trabajar simultáneamente con todo el conjunto de rayos disponible ( rayos) la reorganización de los mismos al descender por el árbol es la mejor posible. Ello redunda en un óptimo aprovechamiento del hardware al haber mayor cantidad de rayos con los que trabajar. Esta ganancia no solo se debe a un mejor aprovechamiento del hardware, sino que al reducir el número de recorridos al mínimo posible, la sobrecarga de llamada a funciones y de acceso a los nodos del árbol se reduce drásticamente. Por último, hemos estudiado el rendimiento del trazado de rayos al emplear múltiples tamaños para el paquete de rayos. Este estudio se ha realizado para el escenario de rayos coherentes y para el de rayos no coherentes. La Figura 3.12 muestra el rendimiento medio en MegaRayos por segundo para distintos tamaños del paquete de rayos. Para el caso de rayos coherentes puede apreciarse como el rendimiento asciende rápidamente aún con un tamaño pequeño para el paquete de rayos. Ello es debido a la alta posibilidad de que los rayos empaquetados juntos realicen un recorrido muy similar a lo largo de la estructura de indexación.

59 Paralelización de Algoritmos Gráficos en CPU Coherentes No coherentes MRayos/s x1 2x2 4x4 8x8 16x16 32x32 64x64 Todos Tamaño paquete de rayos Figura 3.12.: Rendimiento medio en MegaRayos por segundo para diferentes tamaños del paquete de rayos. La escena visualizada fue el dragón a resolución píxeles. En cambio, para rayos no coherentes, la gráfica muestra una tendencia ascendente mucho más suave conforme aumentamos el tamaño del paquete. Al igual que con rayos coherentes, un mayor tamaño del paquete implica mayores posibilidades de paralelizar cómputo. No obstante, estas posibilidades son muy reducidas para tamaños del paquete pequeño. Tamaños mayores del paquete de rayos incrementan esta posibilidad. De la curva deducimos que el máximo posible corresponde a nuestro algoritmo puesto que el paquete comprende todo el volumen de rayos disponible. 3.6 Conclusiones Hasta ahora, las técnicas de aceleración de ray-tracing resultaban eficaces tan solo cuando era fácil encontrar rayos coherentes a los que poder procesar en paralelo, por ejemplo, en rayos primarios. Estas técnicas precisan efectuar un recorrido descendente a través de una estructura de indexación espacial de la escena una vez por cada rayo o paquete de rayos. En este capítulo hemos mostrado un nuevo algoritmo de trazado de rayos que permite obtener un elevado paralelismo en el cómputo SIMD del trazado de rayos incluso en escenarios de rayos no coherentes. Para ello, hemos propuesto recorrer la estructura de indexación tan solo una vez, pero con todos los rayos simultáneamente (o hasta un máximo de ocho veces si los rayos presentan vectores directores de distinto signo). La técnica se ha implementado y validado en distintos escenarios y ha sido comparada con otras estrategias. Por último, se ha hecho un estudio sobre el efecto del tamaño

60 6 Paralelización de Algoritmos Gráficos en CPU del paquete de rayos en la eficiencia del ray-tracing. Se ha mostrado que esta técnica presenta los siguientes beneficios: Principalmente, permite extraer un mayor grado de paralelización en el procesamiento de los rayos. Ello ocurre aún en el caso de rayos no coherentes, pues éstos se clasifican al recorrer el árbol. Por tanto, basta con que dos o más rayos visiten un mismo nodo para que se detecte y se pueda paralelizar su cómputo. Esto se hace especialmente evidente sobre todo en los nodos más elevados del árbol, que serán visitados por una gran cantidad de rayos. Además, se visitará un nodo como máximo ocho veces, y no decenas de miles de veces como ocurre con el resto de algoritmos. De esta forma, se minimiza el número de accesos a memoria que hace falta para cargar los nodos del árbol y los triángulos que contienen. Por otro lado, este algoritmo persigue aumentar la vectorización en el procesamiento de los rayos. Se consigue extraer para cada nodo del índice espacial todo el volumen de datos que ha de procesarse, pero las operaciones deben efectuarse de cuatro en cuatro, que es lo máximo que permite vectorizar SSE. Es de esperar que con arquitecturas que sean capaces de vectorizar mayor cantidad de operaciones, la ganancia de rendimiento sea aún mayor, [BWSF6]. Las GPUs son procesadores especializados en este tipo de operaciones vectoriales, por lo que este algoritmo resulta idóneo para ser implementado en GPUs y poder aprovechar su mayor capacidad de procesamiento en paralelo.

61 4 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales 4.1 Introducción En este Capítulo profundizaremos en el uso de la GPU para optimizar y paralelizar algoritmos básicos de Informática Gráfica. Los algoritmos propuestos en este Capítulo se fundamentan en los recubrimientos simpliciales propuestos por Feito y Torres [FT97]. La Sección 4.2 resume esta base teórica. En la Sección 4.3 emplearemos la GPU para paralelizar el cálculo de la voxelización de un sólido, mientras que en la Sección 4.4 la usaremos para resolver el problema de la inclusión de puntos en sólidos. Para cada problema planteado se proponen diversas estrategias que emplean características avanzadas de las modernas GPUs programables que soportan el perfil Shader Model 4, definido en la Sección El trabajo realizado en este Capítulo ha sido parcialmente publicado en [NOJS8, NROS8]. 4.2 Sistema Generador de Objetos Gráficos En esta Sección se resumen las bases que formalizan las técnicas que serán desarrolladas a lo largo del presente Capítulo. Los conceptos aquí presentados se basan en los trabajos de Feito y Torres [FT97], los cuales fueron posteriormente extendidos por Segura et al [SFdM + 5]. 61

62 62 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales Feito desarrolló en [FT97] un sistema generador de objetos gráficos, válido para dos, tres o más dimensiones, en el que los objetos gráficos se construyen a partir del recubrimiento del volumen del objeto mediante símplices originales. Para el espacio bidimensional, los símplices utilizados son triángulos; para el espacio tridimensional son tetraedros. Teorema 4.1. Sistema generador [FT97]. Sea S un sólido con caras F 1 F 2 F 3...F m, dado en orientación consistente (los vectores normales se orientan hacia fuera del sólido). Entonces: S = m i=1 ([P i ] P i (µ,α )) donde P i (µ,α ) representa la pirámide original (símplice) obtenida mediante la unión de la cara F i con el origen de coordenadas, empleando la función constante de presencia µ y la función de aspecto α. Dichas funciones provienen de la definición de objeto gráfico dada por Torres en [Tor92, TR93]. Por otro lado, [P i ] representa el volumen signado de la pirámide P i, tal y como se describe en [O R98]. Definición 4.1. Sea un punto Q y un sólido S definido por sus caras triangulares F 1 F 2 F 3...F m. Entonces, el recubrimiento de S, denotado como C p, es el conjunto de tetraedros obtenidos mediante la unión de un punto arbitrario (por ejemplo, el centroide del sólido) con cada cara del sólido. Teorema 4.2. Sea un punto Q y un sólido S. Entonces, Q está dentro de S si: sign(q,t i ) [T i ] = 1 i donde T i C s,[t i ] es el volumen signado del símplice y la función sign(q,t i ) devuelve el volumen signado del símplice formado por un punto Q y el triángulo T i. 4.3 Voxelización de Sólidos La representación basada el vóxeles tiene una gran importancia en aplicaciones tales como visualizaciones médicas o para visualizar objetos que difícilmente se pueden representar a partir de sus fronteras, tales como humo o fuego. Además, los vóxeles son entidades tridimensionales que pueden almacenar información volumétrica, al contrario que las representaciones basadas en fronteras que tan solo describen la superficie de los objetos. La voxelización consiste en convertir un sólido desde su representación geométrica continua a un conjunto de vóxeles que lo aproximen [KCY93]. En [ORSF7] se describe

63 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales 63 un método de voxelización basado en GPU capaz de trabajar con una amplia variedad de objetos poliédricos, con o sin agujeros, con auto intersecciones y que es capaz de calcular la voxelización del interior del objeto. En esta Sección describimos cómo la adecuada aplicación de las nuevas características introducidas en las GPUs programables dotadas de Shader Model 4 permite llegar a triplicar el rendimiento del método presentado en [ORSF7]. El resto de esta Sección se estructura de la siguiente manera. La Sección describe el algoritmo básico de voxelización empleado y propone diversas soluciones en GPU basadas dicho algoritmo. Por último, en la Sección se realiza un estudio empírico de las diferentes soluciones propuestas y se comparan entre sí Soluciones para la Voxelización en GPU La base teórica del algoritmo de voxelización de sólidos poliédricos definidos por caras triangulares propuesto en [ORSF7] reside en la descomposición del sólido en símplices de Feito y Torres [FT97]. Esta base teórica ya se ha expuesto en la Sección 4.2. Referimos al lector a [ORSF7] para una completa descripción de este algoritmo. A continuación, resumimos los principales conceptos del mismo. El algoritmo consiste en construir el conjunto de tetraedros del recubrimiento simplicial del sólido y dibujarlos en un buffer de presencia. Este buffer es un vector 3D de bits con la misma dimensión que el espacio de vóxeles. Cada vóxel tiene asociado un bit, y su valor indica si el vóxel pertenece al sólido o no. Los autores proponen procesar los tetraedros en sucesivas lonchas. Primero, se elige una dirección para los cortes en lonchas (asumiremos que el corte se realiza a lo largo del eje y). Segundo, para cada loncha se dibuja en el buffer de presencia la voxelización entre la loncha y cada uno de los tetraedros. Esto se realiza mediante un escaneado de los triángulos P P 1 P 2 y P 3 P 2 P 1 mostrados en la Figura 4.1. El dibujado de los tetraedros en el buffer de presencia se realiza invirtiendo todos los bits cubiertos por el tetraedro. El Teorema 4.2 garantiza que el contenido final del buffer es la voxelización del objeto. En [ORSF7] también se propone una solución en GPU basada en este algoritmo. Esta solución se discute en la Sección A continuación, en las Secciones y presentamos dos nuevas soluciones que extienden a la anterior. La Figura 4.2 esquematiza las tres soluciones estudiadas. A continuación, la Sección propone una serie de mejoras al algoritmo básico de voxelización con el objetivo de expandir su utilidad.

64 64 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales (a) (b) (c) (d) Figura 4.1.: División de un tetraedro en lonchas Solución Previa en GPU La solución propuesta en [ORSF7] realiza la voxelización mediante el procesador de vértices de la GPU, ver Figura 4.2a. Esta implementación requiere que la CPU genere dos triángulos, P P 1 P 2 y P 3 P 2 P 1, por cada loncha y para cada tetraedro. Ver Figura 4.1. Esto provoca una ejecución del procesador de vértices por cada uno de los seis vértices. Junto a cada pareja de triángulos, también se proporciona a la GPU las coordenadas de los cuatro puntos del tetraedro ABCD a procesar y la posición de la loncha actual. Entonces, la GPU desplaza a los dos triángulos a sus posiciones correctas según la loncha y el tetraedro dados, según se ilustra en la Figura 4.1. Una vez trasladados, se aplica la operación lógica por píxel GL XOR y se dibujan los triángulos en el framebuffer de la tarjeta gráfica. De esta manera, el framebuffer asume el rol de buffer de presencia. La desventaja de esta solución es evidente. Para procesar cada loncha se necesita suministrar a la GPU dos triángulos por tetraedro. Es decir, por cada loncha hay que enviar a la GPU un número de triángulos igual al doble del número caras triangulares que conforman el sólido. Multiplíquese ahora esta cifra por el número de lonchas que son necesarias hasta conseguir la voxelización completa del sólido. En conclusión, esta solución requiere de un importante flujo de datos CPU-GPU, lo cual resulta ineficiente al trabajar con sólidos muy complejos Solución con Instanciación de Geometría Los problemas comentados en la sección anterior pueden superarse gracias a las nuevas características del Pixel Shader 4. La técnica propuesta consigue alcanzar dos fines. Primero, minimizar el tráfico CPU-GPU. Y segundo, aprovechar las nuevas características del hardware para simplificar el algoritmo. Este esquema se muestra en la Figura 4.2b. El código completo en lenguaje GLSL de esta propuesta se muestra en el Listado 4.1.

65 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales 65 # extension GL_EXT_gpu_shader4 : enable # extension GL_ARB_texture_rectangle : enable # define IN_MAIN_TRG ( vertexinfo [] < 3.) # define VERTEX_INDEX vertexinfo [] # define IN_INTERVAL (v, a, b) ( a > v && v >= b) # define INTERPOLATE (A,B,s) ( mix (A, B, (s - A [1]) / (B [1] - A [1]))) uniform float slice, texturesize ; uniform sampler2drect texture ; void main () { vec4 tetraverta ; // Coordenadas Vértice 1 (inferior) vec4 tetravertb ; // Coordenadas Vértice 2 vec4 tetravertc ; // Coordenadas Vértice 3 vec4 tetravertd ; // Coordenadas Vértice 4 (superior) } vec4 pos = vec4 (1, 1,, 1); float id = float ( gl_instanceid ); float aux = id *4.; float position = floor ( aux / texturesize ); float offset = mod ( aux, texturesize ); tetraverta = texture2drect ( texture, vec2 ( offset, position ) ); tetravertb = texture2drect ( texture, vec2 ( offset +1., position ) ); tetravertc = texture2drect ( texture, vec2 ( offset +2., position ) ); tetravertd = texture2drect ( texture, vec2 ( offset +3., position ) ); vec4 vertexinfo = gl_vertex ; if ( IN_INTERVAL ( slice, tetraverta [1], tetravertd [1])) { if( IN_MAIN_TRG IN_INTERVAL ( slice, tetravertb [1], tetravertc [1])){ if ( VERTEX_INDEX ==.) { pos. xy = INTERPOLATE ( tetraverta, tetravertd, slice ). xz; } else if ( VERTEX_INDEX == 1. VERTEX_INDEX == 5.) { pos. xy = ( slice >= tetravertb [1])? INTERPOLATE ( tetraverta, tetravertb, slice ). xz : INTERPOLATE ( tetravertb, tetravertd, slice ). xz; } else if ( VERTEX_INDEX == 2. VERTEX_INDEX == 4.) { pos. xy = ( slice >= tetravertc [1])? INTERPOLATE ( tetraverta, tetravertc, slice ). xz : INTERPOLATE ( tetravertc, tetravertd, slice ). xz; } else if ( VERTEX_INDEX == 3.) { pos. xy = INTERPOLATE ( tetravertb, tetravertc, slice ). xz; } } } gl_position = gl_modelviewprojectionmatrix * pos ; gl_frontcolor = vec4 (1, 1, 1, 1); Listado 4.1: Código GLSL del programa del procesador de vértices para la voxelización mediante instanciación

66 66 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales CPU CPU 1 Vértice 1 2 GPU Instanciación Geometría CPU GPU Instanciación Geometría Número de Tetraedros Número Tetraedros x 2 GPU Procesador Vértices Procesador Vértices Número Tetraedros x 2 Textura Procesador Vértices Procesador Geometría Textura Framebuffer Framebuffer Framebuffer (a) (b) (c) Figura 4.2.: Distintas soluciones estudiadas. a) En procesador de vértices (previa). b) En procesador de vértices con instanciación. c) En procesador de geometría con instanciación. En esta solución hacemos uso de la instanciación de geometría. Esta característica de las GPUs se describió en la Sección , y permite reducir el número de datos a mandar a la GPU a tan solo dos triángulos por loncha, P P 1 P 2 y P 3 P 2 P 1. La GPU es responsable de instanciar tantas copias de estos triángulos como sean necesarias (dos triángulos por tetraedro). De forma análoga a la versión previa del algoritmo, el procesador de vértices se encarga de trasladar a los puntos P,P 1,P 2,P 3 a su posición correcta según el tetraedro y la loncha que se esté procesando. Para que la GPU pueda distinguir correctamente a los seis puntos entre sí, es preciso adjuntar con cada punto un índice (-3 en función de si el punto es P,P 1,P 2 o P 3 ) y un identificador del triángulo al que pertenece el punto ( para P P 1 P 2 y 1 para P 3 P 2 P 1 ). Nótese que todos los triángulos instanciados son iguales. Por tanto, aunque tras la instanciación tengamos en GPU tantas parejas de triángulos como tetraedros, no es posible que cada pareja adjunte las coordenadas de un tetraedro distinto (tal y como se hacía en la solución previa). En lugar de ello, se genera una textura 2D de flotantes que almacena consecutivamente los vértices A,B,C,D de cada uno de los tetraedros del objeto a voxelizar. Dentro de cada tetraedro, los vértices se almacenan ordenados por la coordenada y.

67 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales 67 Cada texel 1 de esta textura contiene tres flotantes (RGB), lo que permite almacenar las coordenadas x, y, z del vértice de un tetraedro. Para cada tetraedro se necesitan cuatro texels. El tamaño máximo de textura permitido limita la complejidad de la geometría que podemos representar en textura. Una textura de tamaño permite trabajar con modelos de más de cuatro millones de triángulos. La textura se envía una única vez a la GPU, en donde permanece almacenada durante todo el proceso de la voxelización. De esta forma, tan solo se ha de enviar la geometría a la GPU una vez, y no sucesivas veces por cada loncha. Un programa de vértices recibe los puntos de los triángulos instanciados, así como el identificador de instancia gl InstanceID para cada uno, ver Sección Este identificador se utiliza como índice dentro de la textura, y se extraen los vértices A,B,C,D del tetraedro correspondiente. Dichos vértices se emplean para desplazar cada punto a su posición correcta. Esta versión del algoritmo consta de los siguientes pasos: 1. Crear la textura, que almacena los vértices A,B,C,D de cada tetraedro, y enviarla a la GPU. 2. Inicializar una variable y s al tamaño del espacio de vóxeles. 3. Crear un vector de vértices que almacene únicamente dos triángulos, P P 1 P 2 y P 3 P 2 P Limpiar el framebuffer y establecer la operación lógica por píxel a GL XOR. 5. Establecer como variables uniformes y s y el tamaño de la textura. Enviar el vector de vértices a la GPU con DrawArraysInstancedEXT. Se debe indicar a la función que se cree una instancia por cada tetraedro. 6. Copiar el resultado del framebuffer a memoria principal de la CPU. 7. Decrementar y s y volver al paso 4 hasta y s = Solución en Procesador de Geometría con Instanciación Cuando un tetraedro no intersecta a la loncha actual, los triángulos P P 1 P 2 y P 3 P 2 P 1 deben descartarse. Debido a que no es posible detener el proceso gráfico una vez que éste se ha iniciado, las implementaciones anteriores recurrían a trasladar ambos triángulos a posiciones alejadas para que fueran recortados en etapas posteriores. Mediante el uso conjunto de la instanciación y del procesador de geometría podemos solventar este problema. Este esquema se muestra en la Figura 4.2c. El procesador 1 Contracción de texture element, es la unidad fundamental de superficie de una textura.

68 68 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales float s = y_max ; for ( int ns= voxelspace ; ns >; ns --, s -= intervalo ){ gluniform1f ( slice, s ); gluniform1f ( texturesize, texsize ); //enviar un punto por loncha gldrawarraysinstancedext ( GL_POINTS,, 1, ntetra ); } //Transferir framebuffer a memoria Listado 4.2: Código C para configurar la ejecución del programa de geometría de geometría fue descrito en la Sección El código completo en GLSL de esta propuesta se muestra en los Listados 4.2 y 4.3. En esta implementación, en cada loncha tan solo es necesario enviar a la GPU el tamaño de la textura, la posición y s de la loncha y un único vértice. Las coordenadas del vértice son intrascendentes. Dicho vértice se envía desde CPU a GPU con la función gldrawarraysinstancedext, a la que se indica que genere una instancia por tetraedro (ver Listado 4.2). Esto provoca una ejecución del procesador de geometría por cada tetraedro. Nótese que tan solo se puede acceder a la variable gl InstanceID desde el procesador de vértices, por lo que necesitamos ejecutar un pequeño programa de vértices que copie ese valor a una de las coordenadas del vértice. El programa de geometría del Listado 4.3 toma como entrada un vértice, y genera como salida una tira de triángulos. La longitud de esta tira puede ser: Cero triángulos, si y s no está entre A y y D y, ver Figura 4.1a. Un triángulo si A y > y s B y o C y > y s D y, ver Figuras 4.1b y d. Dos triángulos, si B y > y s C y, ver Figura 4.1c. Los triángulos salen del procesador de geometría con sus vértices interpolados según la arista y loncha a la que pertenecen. La información de los tetraedros se recupera de textura, de forma análoga a la implementación de la sección anterior. Si la loncha está comprendida en el intervalo A y > y s D y, el procesador de geometría interpola los valores de los vértices P,P 1,P 2 y emite dichos vértices a la siguiente etapa del proceso gráfico. Esto genera al triángulo P P 1 P 2. A partir de los tres primeros vértices emitidos, cada nuevo vértice que se emita genera un nuevo triángulo. Por tanto,

69 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales 69 # extension GL_EXT_geometry_shader4 : enable # extension GL_EXT_gpu_shader4 : enable # extension GL_ARB_texture_rectangle : enable # define IN_INTERVAL (v, a, b) ( a > v && v >= b) # define INTERPOLATE (A,B,s) ( mix (A, B, (s - A [1]) / (B [1] - A [1]))) uniform float slice, texturesize ; uniform sampler2drect texture ; void main () { vec4 tetraverta ; // Coordenadas Vértice 1 (inferior) vec4 tetravertb ; // Coordenadas Vértice 2 vec4 tetravertc ; // Coordenadas Vértice 3 vec4 tetravertd ; // Coordenadas Vértice 4 (superior) } float aux = gl_positionin []. x * 4.; float position = floor ( aux / texturesize ); float offset = mod ( aux, texturesize ); tetraverta = texture2drect ( texture, vec2 ( offset, position ) ); tetravertd = texture2drect ( texture, vec2 ( offset +3., position ) ); gl_frontcolor = gl_frontcolorin []; vec4 p = vec4 (,,, 1); if ( IN_INTERVAL ( slice, tetraverta [1], tetravertd [1])) { tetravertb = texture2drect ( texture, vec2 ( offset +1., position ) ); tetravertc = texture2drect ( texture, vec2 ( offset +2., position ) ); } p. xy = INTERPOLATE ( tetraverta, tetravertd, slice ). xz; gl_position = gl_projectionmatrix * p; EmitVertex (); //enviar vértice p. xy = ( slice >= tetravertb [1])? INTERPOLATE ( tetraverta, tetravertb, slice ). xz : INTERPOLATE ( tetravertb, tetravertd, slice ). xz; gl_position = gl_projectionmatrix * p; EmitVertex (); //enviar vértice p. xy = ( slice >= tetravertc [1])? INTERPOLATE ( tetraverta, tetravertc, slice ). xz : INTERPOLATE ( tetravertc, tetravertd, slice ). xz; gl_position = gl_projectionmatrix * p; EmitVertex (); //enviar vértice, fin de primer triángulo if ( IN_INTERVAL ( slice, tetravertb [1], tetravertc [1])) { p. xy = INTERPOLATE ( tetravertb, tetravertc, slice ). xz; gl_position = gl_projectionmatrix * p; EmitVertex (); //enviar vértice, fin de segundo triángulo } EndPrimitive (); Listado 4.3: Código GLSL del programa del procesador de geometría para la voxelización mediante instanciación

70 7 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales si la loncha está comprendida en el intervalo B y > y s C y, se interpola el cuarto vértice P 3 y se emite. Esto da lugar al triángulo P 3 P 2 P 1. Gracias al procesador de geometría, los cálculos de interpolación que antes se hacían por vértice, ahora pueden optimizarse a nivel de primitiva. Esto permite que si el tetraedro no corta la loncha actual, puedan descartarse completamente los dos triángulos sin necesidad de enviar sus seis vértices fuera del volumen de vista. Tan solo se genera aquella geometría que es estrictamente necesaria, lo que evita cálculos innecesarios en etapas posteriores del proceso gráfico Mejoras al Método de Voxelización La instanciación de geometría puede utilizarse para realizar múltiples voxelizaciones de un mismo modelo sin necesidad de volver a transferir su geometría a la tarjeta de vídeo. Además, el algoritmo permite de forma sencilla voxelizar partes concretas del modelo a distinta resolución sin más que ajustar los parámetros de la cámara adecuadamente, ver Figura 4.3. Para restringir la voxelización a una región concreta del modelo es necesario: Fijar los planos que delimitan el volumen de visión para que las regiones que no se desean voxelizar queden fuera y sean recortadas por el hardware. Limitar el recorrido realizado por el plano de loncheado y s al intervalo deseado. Para ajustar la resolución de la voxelización, debe variarse el tamaño de la ventana de visión. Este método posibilita construir voxelizaciones multirresolución en GPU con un flujo de datos CPU-GPU mínimo: un solo vértice por loncha. Por tanto, es posible realizar una voxelización a baja resolución de un modelo, y posteriormente refinar la resolución de las regiones de interés con un mínimo coste adicional. La Figura 4.4 muestra un ejemplo de voxelización multirresolución. El modelo se ha dividido en cuatro regiones mediante tres planos perpendiculares. La resolución de la voxelización para cada región ha sido de 64 3, 128 3, y vóxeles. Los métodos de voxelización descritos en esta sección permiten el uso de un programa de fragmentos para asignar de forma eficiente una función de aspecto a cada vóxel, ver Teorema 4.1. La Figura 4.5 muestra el resultado de añadir a nuestro algoritmo un generador de ruido de Perlin 3D implementado en el procesador de fragmentos [Gre5].

71 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales 71 Figura 4.3.: Contenido del framebuffer de una de las lonchas. Para ajustar las partes del modelo a voxelizar a distinta resolución debe fijarse adecuadamente el volumen de visión y el tamaño de la ventana de visión. Figura 4.4.: Ejemplo voxelización multirresolución. Cada región del sólido se ha voxelizado a distinta resolución.

72 72 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales Figura 4.5.: Uso de un generador de ruido de Perlin para asignar un color a cada vóxel Comparación Empírica de Soluciones de Voxelización Hemos comparado las tres versiones del algoritmo (procesador de vértices, procesador de vértices con instanciación y procesador geometría con instanciación). Para una comparativa de este algoritmo con otros algoritmos de distintos autores, véase [ORSF7]. Todas las implementaciones han sido realizadas en C++ y OpenGL Shading Language (GLSL), y se ha empleado el mismo compilador y optimizaciones. Las pruebas se ejecutaron en un Intel Core2 CPU GHz con una GeForce 88GTS bajo GNU/Linux. La versión del driver de NVIDIA empleada es la En las pruebas se han utilizado varios modelos con diferentes características topológicas y distinta complejidad poligonal. La Tabla 4.1 muestra los tiempos invertidos por cada implementación en calcular la voxelización de los modelos de prueba a distintas resoluciones. La principal ventaja del uso de la instanciación de geometría es que se consigue reducir a la mínima expresión la cantidad de geometría que es preciso enviar a la GPU para procesar cada loncha. Esto consigue reducir los tiempos de voxelización para modelos complejos, en comparación con la versión previa que no utiliza instanciación. La Figura 4.6 muestra la ganancia en velocidad obtenida por las dos soluciones con instanciación de geometría en comparación con la versión previa. Esta ganancia se ha obtenido mediante la división de los tiempos requeridos por la solución previa entre los requeridos por las dos nuevas soluciones. La resolución de voxelización empleada en la gráfica es la de 256 2, si bien las curvas presentan aspecto muy similar para el resto de resoluciones. Puede apreciarse que para modelos con menos de un millón de triángulos, la ganancia de los métodos con instanciación es similar a uno (no hay ganancia). En

73 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales Modelo Triang. Previo Instan Geom Previo Instan Geom Torusknot Depot Bunny Dragon Buddha Camera Modelo Triang. Previo Instan Geom Previo Instan Geom Torusknot Depot Bunny Dragon Buddha Camera Tabla 4.1.: Tiempo de voxelización (segundos) de las tres implementaciones: en procesador de vértices (previo), con instanciación de geometría (Instan), y en procesador de geometría con instanciación (Geom). Las resoluciones de voxelización son 64 3, 128 3, y cambio, para modelos de mayor número de triángulos, la ganancia de los métodos con instanciación aumenta súbitamente. La ganancia llega a ser superior a tres para la solución en procesador de vértices con instanciación; y a dos para la solución en procesador de geometría con instanciación. Este incremento de la ganancia evidencia que la versión previa se satura a partir del millón de triángulos. La necesidad de enviar toda la geometría en cada loncha constituye un cuello de botella al trabajar con modelos complejos. En cambio, con el uso de la instanciación de geometría se elimina esta necesidad, y el algoritmo ofrece mejores resultados en modelos complejos. Nótese que la versión que emplea procesador de geometría no obtiene mejores tiempos pese a ser capaz de descartar del proceso gráfico aquellos tetraedros que no interesecten el plano de corte. Esto indica que una vez introducida una primitiva en el proceso gráfico, resulta más conveniente dejarla terminar. Es más, es reseñable el hecho de que los tiempos obtenidos por esta versión son superiores a los precisados por la solución en procesador de vértices con instanciación. Ambas versiones realizan el mismo número de cómputos, compárese los Listados 4.1 y 4.3. Este resultado nos induce a pensar que el procesador de geometría introduce una penalización de rendimiento en algún punto del cauce gráfico. Como veremos, esta observación también se reproduce en nuestra ex-

74 74 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales Factor de Ganancia Instanciacion Geometria Numero de Triangulos Figura 4.6.: Ganancia en velocidad obtenida por las soluciones con instanciación de geometría (Instanciacion) y en procesador de geometría con instanciación (Geometria) frente a la solución previa. La voxelización se realizó a resolución de perimentación con el método de inclusión de puntos, ver Sección 4.4, reafirmando esta hipótesis. Otro detalle a considerar es el consumo de memoria. La versión previa en GPU, ver Sección , requiere almacenar un vector de vértices que contenga replicada la lista completa de tetraedros. Este replicamiento es redundante pero necesario para suministrar al procesador de vértices todos los datos precisos. Además, la lista debe mantenerse en memoria principal durante todo el proceso. En cambio, las dos versiones que emplean instanciación almacenan la geometría del objeto en una textura sin necesidad de repetir datos. Una vez enviada la textura a la GPU, el espacio de ésta puede liberarse de la memoria principal. Por ejemplo, la lista de tetraedros del modelo del dragón ( triángulos) ocupa casi 4 MB (asumiendo que un flotante ocupa 4 bytes). Podemos almacenarla en una textura RGB de flotantes de 248 2, cuyo tamaño es de 48 MB. Puesto que la GeForce 88 soporta texturas no cuadradas y de tamaño no potencia de 2, podemos ajustar el tamaño de ésta para minimizar el espacio desaprovechado. 4.4 Inclusión de Puntos en Sólidos El test de inclusión de puntos en sólidos es un problema geométrico clásico que consiste en determinar si un punto se encuentra en el interior o en el exterior de un sólido. El test de inclusión es una operación básica en Informática Gráfica, y dispone de numerosas aplicaciones dentro del área de gráficos y geometría de sólidos. Los algoritmos de detección de colisiones y los de voxelización de sólidos son tan solo algunos ejem-

75 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales 75 plos. El test de inclusión es un problema clásico que ya ha sido ampliamente estudiado, véase [OSF5] para una exhaustiva revisión. En esta Sección proponemos y comparamos diversas soluciones para resolver el problema mediante el hardware gráfico, todas ellas basadas en el algoritmo descrito por Segura et al en [SFdM + 5]. Nos decantamos por este algoritmo puesto que presenta numerosas ventajas: su robustez, es simple de implementar y puede paralelizarse fácilmente. Este algoritmo a su vez se basa en la técnica de inclusión de Feito-Torres [FT97]. Como datos de entrada tomaremos un sólido poliédrico S definido por una malla de triángulos que delimita su frontera, y un punto Q del que queremos determinar su inclusión en S. Construiremos el recubrimiento simplicial del sólido C p, ver Definición 4.1. Entonces el Teorema 4.2 garantiza que la inclusión de Q en S se puede obtener mediante la sumatoria de los estados de inclusión de Q en cada uno de los símplices de C p. A partir de este algoritmo, estudiamos diferentes soluciones basadas en GPU. Estas soluciones se clasifican en dos grupos atendiendo a si la información geométrica del sólido se almacena en memoria de CPU o de la GPU. Estas soluciones se describen, respectivamente, en la Sección y en la Sección Por último, en la Sección realizamos un estudio empírico de las diferentes estrategias y analizamos sus ventajas y desventajas Soluciones desde Memoria de la CPU Usualmente, este tipo de algoritmos se denominan mediante la voz inglesa out-ofcore, debido a que los datos exceden el tamaño de la memoria del dispositivo que realiza el cómputo, en este caso la GPU. Por tanto, los datos deben residir en memoria principal de la CPU y desde allí ser enviados a la GPU según sean necesarios. Como el costo de transferencia CPU-GPU y viceversa es alto comparado con el tiempo de computación, estos algoritmos deben optimizar las transferencias de datos para ser eficientes. Comparamos dos soluciones en GPU basadas en el algoritmo de inclusión de Feito y Torres. La primera solución determina la inclusión de los puntos y los tetraedros del recubrimiento simplicial del sólido en el procesador de vértices de la GPU. Esta solución fue propuesta por Ogáyar en [Ogá6] y se discute en la Sección La segunda técnica se diferencia de la anterior en que este cómputo se efectúa en el procesador de geometría de la GPU. Esta nueva solución se describe en la Sección Si bien ambas soluciones se basan en el mismo concepto, veremos que el uso del procesador de geometría permite una solución más elegante, sencilla, intuitiva y fácil de implementar. Las dos soluciones se implementan en dos pasos. La Figura 4.7 muestra un esquema que resume ambas propuestas. El primer paso determina la inclusión del punto Q en cada

76 76 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales Datos de tetraedros T 1 T 2 T 3 T Datos inclusión Puntos Procesador de vértices/geom Intersección punto-tetraedro Estados de inclusión (framebuffer) Procesador de fragmentos Suma Resultado de inclusión (framebuffer) Figura 4.7.: Esquema general de la solución básica out-of-core para el problema de inclusión de puntos. uno de los tetraedros T i (símplices) contenidos en el recubrimiento simplicial del sólido S. El resultado de la inclusión se almacena en el framebuffer, el cual se emplea como si fuera una matriz convencional de números. El segundo paso emplea el procesador de fragmentos para realizar la suma de los resultados de inclusión de cada tetraedro almacenados en el framebuffer Solución basada en el Procesador de Vértices Al principio del primer paso, los tetraedros del recubrimiento simplicial del sólido deben ser preparados en un formato adecuado para su envío a la GPU. Recordemos que cada tetraedro está compuesto de cuatro puntos. Uno de ellos es O, y es común para todos los tetraedros. Para enviar a la GPU los restantes tres puntos de cada tetraedro, se emplea una representación compacta en la que cada tetraedro se codifica mediante un único vértice con atributos de la siguiente forma: La normal, el color y las coordenadas de textura del vértice se emplean para almacenar los tres puntos que, junto con O, determinan el tetraedro. La coordenada x del vértice incluye un número que sirve para determinar la posición de la ventana de visión donde se guardará el resultado de la inclusión entre el tetraedro y Q. Este número es único para cada tetraedro y se asigna de forma secuencial. Su uso se especifica más adelante. En la coordenada z del vértice se almacena el signo del tetraedro. Para efectuar el test de inclusión, se suministra a la GPU el punto Q a estudiar y el origen O. A continuación, se envía un vector de vértices que contiene todos los tetraedros. Esto provoca una ejecución del procesador de vértices por cada tetraedro enviado. La ejecución i-ésima determina la inclusión entre el tetraedro T i y Q. El resultado de la inclusión ( ó 1) se almacena en el color del vértice. El signo del tetraedro (positivo o negativo) se

77 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales 77 almacena en el color secundario. Entonces, el vértice se desplaza para situarse en una posición concreta de la ventana de visión, determinado por el valor de la coordenada x del vértice. De esta forma, la ventana de visión se emplea para guardar los resultados. Al final del paso anterior, el framebuffer contiene el resultado del test de inclusión para cada uno de los tetraedros. El segundo paso calcula la suma total de estos datos para obtener un único valor mediante la conocida técnica de ping-pong [BP4]. Ver [Ogá6] para una descripción de este paso Solución basada en el Procesador de Geometría Con la aparición del Shader Model 4 es posible optimizar la solución anterior mediante el uso del procesador de geometría. El procesador de vértices solo acepta un vértice como primitiva de entrada. Para salvar esta limitación, la solución anterior necesita codificar los cuatro vértices de un tetraedro en un único vértice. Para realizar esta codificación es preciso aprovechar la normal, el color y las coordenadas de textura del vértice. El procesador de geometría elimina la necesidad de esta poco intuitiva forma de codificar los datos puesto que es capaz de recibir un triángulo completo como primitiva de entrada. Es preciso configurar el procesador de geometría para que acepte triángulos como primitiva de entrada, y genere vértices como primitiva de salida. La preparación de los datos a enviar a la GPU es muy sencilla. Los triángulos que conforman el sólido se envían a la GPU de una forma similar a como lo haríamos si simplemente pretendiéramos visualizar el sólido. En esta solución, es la propia GPU la que construye los tetraedros del recubrimiento simplicial a partir de las caras del sólido. A tal fin, debemos generar un vector con todas las caras triangulares del sólido. Al igual que en la solución anterior, junto con cada triángulo es preciso adjuntar dos valores: un número que sirve para indicar a la GPU en qué lugar del framebuffer almacenar el resultado de la inclusión; y el signo del tetraedro. Estos valores se adjuntan en el color de los triángulos. Cada triángulo así enviado a la GPU provoca una ejecución del procesador de geometría. La iteración i-ésima del procesador de geometría toma la i-ésima cara triangular, y junto con el punto O construye el tetraedro T i del recubrimiento simplicial del sólido. El procesador de geometría determina entonces la inclusión entre este tetraedro y el punto Q. Como resultado, el procesador de geometría genera un vértice. El resultado de la inclusión se almacena en el color de dicho vértice. A continuación, este vértice se traslada hasta situarse en una posición concreta de la ventana de visión, de forma análoga a la solución anterior (ver Sección ). El procesador de geometría concluye mediante la emisión del vértice con el resultado de la inclusión. A la hora de emplear el procesador de geometría es requisito imprescindible programar también el procesador de vértices. Para ello se emplea un simple programa de vértices que se limita a copiar la información de los vértices de entrada a la salida.

78 78 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales El framebuffer donde se guardan los resultados está configurado para emplear números flotantes. Como cada flotante puede contener cuatro valores por texel, podemos almacenar el resultado del test de inclusión de hasta 4 puntos en cada texel (uno en cada canal de color). Esto permite modificar el algoritmo para procesar la inclusión de los puntos de cuatro en cuatro. El Listado 4.4 muestra el código en lenguaje GLSL del programa de geometría para determinar la inclusión de cuatro puntos Soluciones desde Memoria de la GPU En inglés, estos algoritmos se conocen habitualmente como algoritmos in-core ya que, al contrario de lo que ocurre con los out-of-core, todos los datos requeridos para el procesamiento se almacenan simultáneamente en la memoria de la GPU. En este segundo conjunto de soluciones almacenamos todos los tetraedros del recubrimiento simplicial del sólido en una textura. Esta textura se envía a la GPU, en cuya memoria reside durante todo el proceso. A fin de acelerar el proceso, hacemos uso de una estructura de indexación espacial para dividir el espacio ocupado por el sólido poliédrico. Esta estructura permite restringir el número de tetraedros en los que es necesario estudiar la inclusión del punto. Hemos seleccionado el tetra-tree como estructura de aceleración debido a que al utilizar tetraedros, la descomposición se adapta mejor a la forma de los sólidos (en nuestro caso, mallas de triángulos), que otras estructuras arbóreas y con un coste de pre-procesamiento mínimo [JFSO6]. Realizamos aquí una breve descripción de este tipo de estructura. Para una descripción completa véase [JFSO6,Jim6]. El tetra-tree se basa en la subdivisión recursiva del espacio mediante tetra-conos. Un tetra-cono es una región abierta del espacio delimitada por tres planos que intersecan en un punto común. El tetra-cono se puede definir mediante un tetraedro en el que uno de los vértices es el origen del tetra-cono. El primer nivel del tetra-tree está formado por ocho tetra-conos con un origen común. Estos tetra-conos cubran la totalidad del espacio sin solapamiento entre ellos. El punto común es coincidente con el punto utilizado para generar el recubrimiento simplicial del sólido. Los tetraedros de dicho recubrimiento se clasifican en cada uno de los tetra-conos. Cada tetra-cono se puede subdividir en nuevos tetra-conos de forma recursiva, normalmente hasta alcanzan una profundidad máxima prefijada o cuando el número de tetraedros clasificados en un tetra-cono es inferior a una cota dada. La información del sólido y del tetra-tree se suministra a la GPU mediante texturas. Una textura almacena los vértices de los triángulos del sólido. Otra textura almacena todos los tetra-conos hoja junto con punteros a los triángulos solapados por cada tetra-

79 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales 79 //GLSL version 1.2 # version 12 //New G8 extensions # extension GL_EXT_geometry_shader4 : enable # extension GL_EXT_gpu_shader4 : enable # define TETRA_OUTSIDE. # define TETRA_INSIDE_POS 1. # define TETRA_INSIDE_NEG -1. # define TETRA_FACE.5 # define TETRA_EDGE1.6 # define TETRA_EDGE2.7 # define TETRA_EDGE3.8 //centroide uniform vec3 O; //puntos a calcular intersección uniform vec3 p, p1, p2, p3; //tama~no del framebuffer uniform float fbsize ; void main () { float trianglenum = gl_frontcolorin []. r; gl_frontcolor = vec4 ( tetrapoint ( gl_positionin []. xyz, gl_positionin [1]. xyz, gl_positionin [2]. xyz, p ), tetrapoint ( gl_positionin []. xyz, gl_positionin [1]. xyz, gl_positionin [2]. xyz, p1 ), tetrapoint ( gl_positionin []. xyz, gl_positionin [1]. xyz, gl_positionin [2]. xyz, p2 ), tetrapoint ( gl_positionin []. xyz, gl_positionin [1]. xyz, gl_positionin [2]. xyz, p3 ) ); for ( int i =; i <4; i++ ) gl_frontsecondarycolor [ i] = ( gl_frontcolor [ i] == TETRA_INSIDE_NEG )? -1.:1.; gl_frontcolor = abs ( gl_frontcolor ); float row = mod ( trianglenum, fbsize ); float col = floor ( trianglenum / fbsize ); gl_position = gl_modelviewprojectionmatrix * vec4 ( row, col,, 1); } EmitVertex (); EndPrimitive (); Listado 4.4: Código GLSL del programa del procesador de geometría para la inclusión de puntos

80 8 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales cono (referidos a la textura anterior). La inclusión de un punto en el sólido se realiza en la GPU en dos etapas: 1. El procesador de vértices determina el tetra-cono de profundidad máxima en el que se encuentra el punto. En este cómputo se utiliza la textura de tetra-conos. 2. El procesador de fragmentos clasifica la inclusión del punto respecto a los tetraedros contenidos en el tetra-cono obtenido en la etapa anterior. Esta estructura espacial permite una consulta rápida sobre un reducido conjunto de triángulos. Al contrario que con las técnicas en memoria de la CPU, ver Sección 4.4.1, no se itera sobre los puntos a los que se desea determinar su inclusión, sino sobre los triángulos del sólido. Por tanto, una vez construida la estructura podemos determinar la inclusión de un número mayor de puntos con un mínimo coste adicional. Esto es especialmente útil en problemas de detección de colisión y en operaciones booleanas entre sólidos Comparación Empírica de Soluciones de Inclusión El objetivo ahora es realizar una comparación cualitativa y cuantitativa de todos los métodos de inclusión de puntos en sólidos explicados anteriormente. Concretamente, los métodos objeto de nuestro estudio son las soluciones desde memoria de la CPU (out-ofcore) que emplean procesador de vértices y procesador de geometría (respectivamente, Secciones y ) y la solución desde memoria de la GPU (in-core) mediante tetra-trees (Sección 4.4.2). A modo de referencia, también se incluye en nuestra experimentación una solución basada puramente en CPU, que al igual que las anteriores también hace uso del algoritmo de inclusión de Feito-Torres. La descripción de esta solución en CPU puede encontrarse en [OSF5]. Como banco de pruebas hemos empleado diversos sólidos poliédricos que constan de mallas con diferente número de polígonos así como distintas propiedades topológicas. Los experimentos se han ejecutado en un Intel Core 2 Duo con 2GB de memoria RAM. La GPU empleada es una NVIDIA GeForce 88GTS. En cada experimento se ha empleado diez conjuntos de 1 puntos aleatorios cada uno. Los puntos están incluidos en la caja envolvente mínima del sólido. La Tabla 4.2 muestra los tiempos de cómputo para cada experimento. Estos resultados son la media de los tiempos para los diez conjuntos de puntos. Para cada experimento, la Tabla 4.2 incluye el nombre del sólido poliédrico empleado, el número de caras triangulares del mismo y los tiempos en segundos requeridos, respectivamente, por la solución en CPU, la solución out-of-core mediante procesador de vértices, la solución out-of-core mediante procesador de geometría y la solución in-core mediante tetra-trees.

81 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales 81 Out-of-core In-core Procesador Procesador Triángulos CPU Vértices Geometría Tetra-Tree Torusknot Vertebra Golf Ball Bunny Escudo UJA Camera Tabla 4.2.: Tiempo en segundos requerido por cada solución en calcular la inclusión de 1 puntos en función del sólido empleado. El tamaño de las texturas empleadas en la versión in-core limita la complejidad de la escena. Por esta causa, algunos tiempos no se muestran debido a la falta de espacio para albergar la estructura de indexación. Las técnicas out-of-core no padecen esta limitación. La Tabla 4.3 muestra el tiempo invertido por la solución in-core en pre-procesamiento (generar el tetra-tree). En dicha Tabla no aparecen las soluciones out-of-core puesto que no requieren construir estructuras de indexación. Para cada sólido se muestra su número de triángulos, la profundidad máxima permitida del tetra-tree y el tiempo en segundos requerido para su construcción. Las soluciones out-of-core e in-core presentan distintas ventajas y desventajas propias de su naturaleza. Las out-of-core necesitan que la geometría del modelo sea reenviada completamente a la GPU para el procesamiento de cada conjunto de cuatro puntos. Las in-core, por el contrario, almacenan la geometría completa del modelo en memoria de la GPU y son los puntos a procesar los que deben ir fluyendo hacia la GPU. Ello provoca una mayor sobrecarga del bus PCI-Express en las soluciones out-ofcore, puesto que para procesar un conjunto amplio de puntos se debe enviar reiteradas veces la geometría del sólido a la GPU. Por el contrario, este enfoque permite trabajar con mallas arbitrariamente grandes. Esto es, es posible aplicar un procesamiento por lotes sin necesidad de interrumpir el proceso gráfico. Triángulos Profundidad Tiempo Torusknot 12 3,52264 Vertebra , Golf Ball ,73991 Bunny ,127 Tabla 4.3.: Tiempo en segundos invertidos en la construcción del tetra-tree para la malla y la profundidad máxima indicada.

82 82 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales Esta propiedad proviene del algoritmo de inclusión de Feito-Torres. El valor de inclusión de un punto se obtiene mediante la suma de los estados de inclusión en cada uno de los tetraedros del recubrimiento simplicial. En caso de trabajar con sólidos muy complejos, la malla de triángulos del sólido se puede subdividir en subconjuntos más pequeños. Estos subconjuntos se envían en sucesivos lotes a la GPU. Los valores de inclusión para los tetraedros de cada lote se suman y se agregan a un acumulador. La propiedad asociativa de la suma garantiza que no importa en qué orden se procesen los tetraedros ni cómo se configuren los subconjuntos. La solución basada en procesador de geometría presenta un reseñable beneficio frente a la basada en el procesador de vértices. Resulta más elegante e intuitiva al no necesitar compactar la información de cada tetraedro dentro de un único vértice. El procesador de geometría permite enviar la malla de triángulos del sólido a la GPU de una manera estándar y natural. Por contra, es interesante el descubrimiento de que la eficiencia de la solución en procesador de geometría es inferior al de la versión en procesador de vértices, ver Tabla 4.2. Hay que señalar que ambas realizan el mismo número de cálculos. Tan solo cambia la forma de codificar los datos y la etapa del proceso gráfico en el que se realiza el cómputo. Ello evidencia que el procesador de geometría introduce una penalización de rendimiento en algún punto del cauce gráfico. Las observaciones análogas realizadas en nuestra experimentación con el método de voxelización, ver Sección 4.3, apuntan en la misma dirección. Si bien, en el caso de la inclusión, esta pérdida de rendimiento también puede deberse a un mayor trasiego de datos CPU-GPU al tener que enviar a la GPU triángulos en lugar de vértices. Por otro lado, la Tabla 4.2 también muestra que la solución in-core ofrecen unos tiempos de cómputo mucho mejores que el resto de soluciones. Esta mejora se debe al empleo de estructuras de indexación espacial y a que la geometría solo se envía una única vez a la GPU. La mejora se hace más patente cuanto mayor sea el número de puntos a procesar. Esto hace a esta técnica muy interesante para trabajar con nubes de partículas. Como contrapartida, sufre de unos tiempos de pre-computación más elevados, tal y como muestra la Tabla 4.3. Además, las estructuras de aceleración deben recalcularse si se producen cambios en la malla. Esto lo hace poco indicado para escenas dinámicas o interactivas. La eficiencia del algoritmo Feito-Torres en CPU es inferior a las implementaciones en GPU en la mayoría de los casos. No obstante, puede verse en la Tabla 4.2 que para sólidos con geometría muy simple, tal y como el sólido Torusknot, la implementación en CPU tiene cierta ventaja. Este hecho se debe a que el procesamiento en CPU no requiere el envío de datos a través del bus de la tarjeta gráfica ni preparar las estructuras de datos pertinentes. No obstante, para mallas más complejas estos factores tienen un peso muy bajo y las versiones en GPU superan holgadamente a la versión en CPU.

83 Paralelización de Algoritmos Gráficos en GPU Mediante Recubrimientos Simpliciales 83 En conclusión, la solución in-core solo está indicada si el número de puntos a procesar es elevado y no se espera cambios en la escena. Si estas condiciones se cumplen, el rendimiento proporcionado por esta solución no tiene parangón. Por contra, si el número de puntos a procesar es pequeño o la escena es dinámica, el elevado tiempo de construcción del tetra-tree lastra el rendimiento de la técnica in-core. En este caso, resulta mucho más rentable en tiempo el empleo de una técnica out-of-core. 4.5 Conclusiones En este capítulo hemos demostrado cómo el uso de las características aún poco explotadas de las nuevas tarjetas gráficas (procesador de geometría e instanciación de geometría) pueden ser empleadas para simplificar y potenciar algoritmos gráficos. Gracias al procesador de geometría, podemos aplicar optimizaciones a nivel de primitiva. También se elimina la necesidad de emplear complejas y poco intuitivas estructuras para enviar información a la GPU (una de las principales dificultades que encuentran los programadores de GPUs). Por otro lado, la instanciación de geometría permite reducir en gran medida el flujo de datos CPU-GPU, uno de los cuellos de botella más importantes para muchas aplicaciones. Estos avances en el hardware gráfico han sido aplicados con éxito en la resolución de dos problemas básicos dentro de la informática gráfica. Concretamente, los problemas abordados han sido la voxelización de sólidos y el test de inclusión de puntos en sólidos. Para cada problema se han planteado diversas soluciones, todas ellas basadas en el concepto de recubrimiento simplicial. Estas soluciones han sido implementadas, validadas y comparadas entre sí.

84

85 5 Gráficos 3D para Dispositivos Móviles 5.1 Introducción En este capítulo presentamos los trabajos previos realizados en dos campos distintos que son del interés de nuestro trabajo: la visualización de gráficos tridimensionales en dispositivos móviles y la visualización adaptativa de terrenos en tiempo real. A continuación, y una vez conocido el estado del arte en ambos campos, analizaremos la aplicabilidad de las técnicas actuales de visualización de terrenos a los dispositivos móviles. En la Sección 5.2 ofrecemos una introducción al mundo de los dispositivos móviles y ahondamos en sus bondades y problemáticas. También proporcionamos unas consideraciones generales e identificamos los puntos en los que la computación móvil difiere de la computación habitual en ordenadores de escritorio. En la Sección 5.3 repasamos las tecnologías más habituales que es posible encontrar dentro del mundo de los dispositivos móviles. Se realiza un repaso a las plataformas existentes, sistemas operativos y estándares de desarrollo para gráficos tridimensionales. Los dispositivos móviles sufren unas severas restricciones en su potencia de cómputo y capacidad de almacenamiento. Estas restricciones han provocado que numerosos investigadores hayan desarrollado técnicas específicas para la visualización interactiva de escenas 3D en estos dispositivos. La Sección 5.4 repasa las principales propuestas para la visualización de escenas 3D genéricas en dispositivos móviles existentes en la literatura. 85

86 86 Gráficos 3D para Dispositivos Móviles En la Sección 5.5 revisamos los principales métodos existentes para la visualización interactiva de terrenos. Dado el vasto tamaño de estos modelos, no es posible realizar una visualización directa de forma interactiva del modelo original. Por tanto, es imperativo el empleo de técnicas adaptativas que permitan reducir la complejidad del modelo de acuerdo a la calidad deseada y a las restricciones de memoria o de potencia de cómputo. Por último, en la Sección 5.6 repasamos las técnicas de visualización interactiva de terrenos que fueron introducidas en la Sección 5.5 pero analizándolas desde el contexto de su aplicación a los dispositivos móviles. Finalizaremos en la Sección 5.7 con las conclusiones extraídas de este capítulo. 5.2 Consideraciones sobre Dispositivos Móviles En los últimos años, la aparición de la telefonía móvil ha supuesto un cambio social importante. Según la International Telecommunications Union, en 28 había 3.3 miles de millones de personas (la mitad de la población mundial) que empleaban dispositivos móviles [CPAM8]. Es más, podemos considerar al teléfono móvil como el dispositivo dotado de capacidades gráficas más extendido [AMS3]. Aparte de lo anecdótico de los datos, es evidente que las posibilidades que se brindan ante esta situación son numerosas. Los primeros dispositivos móviles (terminales de telefonía móvil, agendas electrónicas portátiles o PDAs, etc.) no dejaban de ser aparatos diseñados para cumplir su función específica, y sus prestaciones se limitaban a lo estrictamente necesario para cumplir dichas funciones. Sin embargo, la paulatina inclusión de nuevos servicios ha ido acompañada con un aumento espectacular en las prestaciones y funcionalidades de estos dispositivos. Incluso han surgido sistemas operativos diseñados específicamente para los mismos, donde Symbian OS, ios o Android son solo algunos ejemplos. Hoy en día puede afirmarse que los dispositivos móviles se han convertido en pequeños ordenadores personales con capacidad de procesamiento prácticamente similar a los ordenadores de hace diez años. No obstante, la forma de trabajar con los dispositivos móviles sigue difiriendo enormemente a la forma de trabajar con ordenadores personales. La computación móvil ofrece una serie de ventajas inéditas en otros entornos que han sido la razón de su éxito: 1. Ubicuidad. Puedes trasportarlos siempre contigo. 2. Conectividad. Están siempre conectados a una red de datos.

87 Gráficos 3D para Dispositivos Móviles Localización. Pueden obtener su localización geográfica, por ejemplo, a través del sistema GPS. Permiten acceder a servicios basados en la posición del usuario. 4. Interfaz multimodal. Teclados, pantallas táctiles y multitáctiles, voz, acelerómetros... Su pequeño tamaño añade nuevas formas de interacción con el usuario. Por el contrario, los dispositivos móviles presentan una serie de inconvenientes que han de tenerse presentes a la hora de desarrollar software para ellos [AMS8]. Su limitado tamaño restringe la complejidad que es posible imbuir al hardware. Y no menos importante, provoca graves limitaciones en la capacidad de disipar el calor y de obtener alimentación eléctrica. Entre otros inconvenientes de los dispositivos móviles, destacamos los siguientes: 1. Ahorro de batería. Los dispositivos móviles requieren de una batería para su funcionamiento. Las baterías son costosas y pesadas, por lo que la reducción del consumo energético es el factor que determina el diseño de los dispositivos móviles. Procesador, procesador gráfico, memoria, sistema operativo, etc. son diseñados anteponiendo la eficiencia energética al rendimiento. El software también debe diseñarse con este problema en mente. 2. Limitaciones del procesador. Debido a las razones anteriores, los procesadores existentes para dispositivos móviles suelen carecer de operaciones complejas. Así, por ejemplo, la familia de procesadores ARM9, presente aún en muchos dispositivos, carece de procesador de coma flotante (FPU). Además, las memorias cachés suelen estar muy limitadas. Todo ello hace que el rendimiento del sistema se ralentice. Con los procesadores gráficos, el problema es análogo. 3. Modelo de memoria limitado y escaso. A diferencia de los ordenadores convencionales en los que el procesador es capaz de direccionar un tamaño de memoria muy amplio (del orden de Gigabytes), en los dispositivos móviles la cantidad de memoria disponible es mucho más escasa. Además ésta debe compartirse con el resto de aplicaciones y datos del sistema. El uso de dispositivos de almacenamiento secundario (usualmente tarjetas extraíbles de memoria flash no volátil) para segmentación y paginación de memoria virtual no es útil debido a los elevados tiempos de acceso que padecen. 4. Comunicaciones limitadas. El acceso a Internet desde dispositivos móviles requiere el uso de tecnologías inalámbricas tales como 2G y 3G. El ancho de banda ofrecido por dichas conexiones es generalmente más estrecho que el ofrecido por una conexión cableada. Además, estas conexiones suelen ser costosas y tienen coberturas limitadas. Redes inalámbricas de área local, tal y como IEEE son más rápidas y económicas, pero tienen un rango de alcance aún más limitado.

88 88 Gráficos 3D para Dispositivos Móviles 5. Interfaz de usuario. Las pantallas y teclados tienen a ser muy pequeños, lo cual dificulta su uso y la cantidad de información que pueden trasmitir. 6. Fragmentación. Las tecnologías móviles cambian constantemente. Esto, unido a las constantes luchas comerciales por parte de múltiples fabricantes para hacerse con el mercado, ha dado lugar a un gran número de plataformas, tecnologías y librerías, a menudo similares pero incompatibles entre sí [PAM + 7]. A la vista de lo anterior, el desarrollo de software es especialmente complejo y, en cierto sentido, anacrónico. Algunos aspectos de la programación que habían sido superados gracias a las mejoras en el hardware son ahora rescatados del olvido. 5.3 Tecnologías Móviles Pese al auge de los dispositivos móviles y el rápido incremento de sus prestaciones, aún existía un gran inconveniente que impedía en cierto modo su eclosión como dispositivos de entretenimiento e información avanzada. La amplia difusión que la Informática Gráfica ha tenido en el campo de los ordenadores personales se ha debido en gran medida al abaratamiento e inclusión en los equipos de GPUs con gran capacidad de procesamiento. Hasta ahora esa posibilidad no estaba disponible en los dispositivos móviles. Sin embargo, los fabricantes de GPUs han sido conscientes de las amplias posibilidades que supone este mercado, diseñado hardware gráfico adaptado para su uso móvil. En [AMS8] podemos leer una revisión sobre las características de las GPUs para dispositivos móviles. Antes de la llegada este hardware gráfico de bajo consumo, no era posible visualizar gráficos 3D realistas de manera interactiva. Sus limitadas prestaciones y el uso de librerías de visualización por software solo permitían mostrar escenas triviales. Hasta hace pocos años, ni siquiera era posible visualizar un cubo con sombreado de Gouraud de forma interactiva. Aparte del hardware gráfico, otro factor determinante ha sido la importante mejora en la tecnología empleada para las pantallas. Los primeros dispositivos móviles de consumo disponían de pantallas pequeñas (48 48 píxeles) y monocromáticas. Hoy en día, los modelos más avanzados ofrecen 24 bits de color (16.7 millones de colores) y resoluciones VGA (64 48 píxeles) o WVGA (48 8 píxeles). Esta sección describe las múltiples tecnologías y librerías gráficas (APIs) que pueden emplearse en el desarrollo de aplicaciones con gráficos 3D para dispositivos móviles. Esta introducción a tan amplia variedad de tecnologías proporcionará al lector un punto

89 Gráficos 3D para Dispositivos Móviles 89 El 3 de Abril, Dr. Martin Cooper de Motorola realiza la primera llamada con un teléfono móvil celular a su rival Dr. Joel S. Engel, de Bell Labs ARP, primera red celular comercial, es creada en Finlandia. Generación G. No era posible pasar de una célula a otra sin interrumpir la llamada. Sony lanza PSP NTT, primera red celular (1G) para uso comercial es creada en Japón Motorola DynaTAC 8X, primer teléfono celular móvil comercialmente disponible. Precio: $ Sega lanza Game Gear, dotada con pantalla LCD color. 199 IBM Simon, primer teléfono móvil en incorporar funciones avanzadas: calendario, agenda, ... Precio: $ Microsoft lanza plataforma Pocket PC 2 Ericsson R38, primer teléfono inteligente y con Symbian OS, evolución de EPOC. 2 Nokia 341, primer teléfono fuera de Japón con motor gráfico 3D integrado, la librería NokiaGL. RIM lanza el primer teléfono Blackberry. 22 Nintendo lanza Nintendo DS. Nokia 663, primer teléfono con OpenGL ES y M3G. OpenGL ES M3G Apple lanza teléfono iphone y PDA itouch con iphoneos, OpenGL ES 1.1. OpenGL ES Apple lanza teléfono iphone 3GS y PDA itouch 3ª generación, con OpenGL ES Mobira Senator, primer teléfono portátil de Nokia Psion lanza Psion Organiser I, primer ordenador de bolsillo Nintendo lanza Game Boy, dotada de pantalla LCD verde. Psion lanza EPOC16, un sistema operativo multitarea para dispositivos móviles Radiolinja, primera red GSM (2G) lanzada en Finlandia Microsoft lanza Windows CE 1.. US Robotics lanza Palm-Pilot, primera PDA con Palm OS. EEUU permite el empleo del GPS para usos civiles. 21 J-Phone lanza los primeros teléfonos con motor 3D integrados. Nintendo lanza Game Boy Advance. NTT DoCoMo, primera red 3G lanzada en Japón. 23 OpenGL ES 1. M3G 1. Nokia lanza N- Gage, híbrido teléfonovideoconsola. Lanzamiento de las redes 2.5G EDGE y GPRS. 26 Primera red comercial WiMAX lanzada en Seúl por KT. Nokia N93, primer teléfono con aceleración hardware de OpenGL ES 1.1 y M3G. 28 Lanzamiento de HTC Dream, primer teléfono con Android 21 Apple lanza ipad, con OpenGL ES 2. Nintendo anuncia Nintendo 3DS, con OpenGL ES 1.1 y pantalla 3D. Figura 5.1.: 4 años de historia de gráficos en dispositivos móviles.

90 9 Gráficos 3D para Dispositivos Móviles de referencia sólido que facilitará su comprensión de los siguientes capítulos de la tesis. Para ampliar información, puede consultarse [CPAM8]. La Sección revisa las diferentes tecnologías y estándares gráficos existentes en el mercado de los dispositivos móviles. La Sección ofrece una visión general de las distintas plataformas y sistemas operativos especializados que es habitual encontrar al trabajar con dispositivos móviles. Por último, en la Figura 5.1 mostramos una línea de tiempo que refleja los mayores hitos ocurridos en la historia de los dispositivos móviles durante los últimos 4 años. Se tienen en especial consideración los hechos relacionados con la Informática Gráfica Estándares Gráficos La inclusión de hardware gráfico de alto rendimiento en los dispositivos móviles no sirve de nada si no está acompañado de un conjunto de librerías y estándares especializados que permitan el desarrollo de software específico que aproveche todo el potencial de dichos dispositivos. Las dos librerías gráficas más extendidas que permiten sacar partido al hardware gráfico de los dispositivos móviles son OpenGL ES y M3G [PAM + 7]. La primera generalmente se emplea con el lenguaje de programación C o C++, mientras que la segunda ha sido diseñada para su uso desde Java Mobile Edition (JME). OpenGL ES [Khr1b] es un subconjunto de la librería gráfica OpenGL, específicamente diseñada para dispositivos integrados. Entre éstos, se encuentran teléfonos móviles, agendas digitales personales (PDAs) y videoconsolas. Consiste en un subconjunto bien definido de OpenGL. Ofrece una interfaz flexible potente y de bajo nivel que abstrae al software del hardware gráfico subyacente. Es libre de royalties e independiente de la plataforma. OpenGL ES incluye perfiles de compilación para sistemas de punto fijo y para sistemas de punto flotante, así como la especificación EGL que permite el enlazado de sus aplicaciones en sistemas de ventanas. Actualmente se han desarrollado dos versiones de OpenGL ES. Para una comparación entre sí, véase [Cat1, Pow9]. A continuación resumimos las caraterísticas más importantes de ambas: OpenGL ES 1.x ha sido diseñado a partir de la especificación OpenGL 1.5, y ofrece operaciones aceleradas, alta calidad de imagen y elevado rendimiento, asegurando además un consumo de batería reducido. Permite su uso tanto en dispositivos que

91 Gráficos 3D para Dispositivos Móviles 91 disponen de hardware acelerador 3D, como en dispositivos que realizan la visualización enteramente por software. No permite la programación de la GPU. OpenGL ES 2.X [MGS8] ha sido diseñado específicamente para dispositivos dotados de hardware gráfico programable. La principal novedad frente a OpenGL ES 1.x reside en que OpenGL ES 2. elimina toda la funcionalidad ofrecida por el proceso gráfico fijo de la GPU. Esto fuerza al desarrollador a escribir programas de vértices y de fragmentos. Consúltese la Sección para una descripción del proceso gráfico en las GPUs. OpenGL ES es la librería para gráficos 3D oficial en Symbian OS, la plataforma Android, ios, Nintendo 3DS y PlayStation 3, entre otros. M3G (JSR-184) [Jav5], por otro lado, es una librería de alto nivel y orientada a objetos para Java Mobile Edition (JME). Ha sido diseñada para implementarse sobre OpenGL ES 1.. De esta forma, OpenGL ES proporciona a M3G toda la funcionalidad de bajo nivel (tal y como transformaciones, iluminación, rasterización, etc.), mientras que M3G ofrece características avanzadas como grafos de escena y animación. Su función es ofrecer una interfaz para Java estandarizada y de mayor nivel que OpenGL ES. Así, OpenGL ES proporciona máxima eficiencia y flexibilidad para el desarrollo de aplicaciones nativas. M3G, por otro lado, añade las características necesarias para un desarrollo eficiente sobre Java. La especificación 2. de M3G (JSR-297) [Jav9], aún en desarrollo, se construirá sobre OpenGL ES 1.1 ó 2., y permitirá opcionalmente el uso de GPU programable. También existe la posibilidad de realizar directamente llamadas a la librería OpenGL ES desde Java a través de la librería Java Bindings para OpenGL ES (JSR-239) [Jav6]. Esta especificación define un paquete opcional para JME que ofrece una interfaz estándar para Java muy similar a la librería original para C de OpenGL ES. No obstante, esta especificación no goza de mucho apoyo por parte de la industria, y la mayoría de los dispositivos móviles con hardware 3D no la incluyen Plataformas Móviles El sistema operativo es el software encargado de proporcionar a las aplicaciones servicios tales como gestión de procesos e hilos, gestión de memoria, acceso a ficheros y redes, etc. También se encarga de gestionar la interfaz de usuario. Debido a sus limitaciones, los dispositivos móviles requieren de sistemas operativos específicos y adaptados a sus posibilidades. En esta sección describimos algunos de los sistemas operativos y plataformas móviles más destacadas. La lista no es exhaustiva, pues su objetivo es ofrecer al

92 92 Gra ficos 3D para Dispositivos Mo viles (a) (d) (b) (c) (e) Figura 5.2.: Algunos ejemplos de dispositivos mo viles con capacidades gra ficas 3D. a) Agenda electro nica Dell Axim x51. b) Tele fono Samsung Galaxy. b) Tele fono iphone 4. c) Tele fono Nokia N95. d) Videoconsola Nintendo 3DS. lector una imagen general del mercado y del potencial gra fico de las distintas plataformas. Algunos de los modelos descritos se ilustran en la Figura Windows Mobile Windows Mobile [Mic1d] 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.

93 Gráficos 3D para Dispositivos Móviles 93 A día de hoy, los dispositivos basados en Windows Mobile y dotados con hardware gráfico 3D son muy escasos. Entre éstos, los modelos más populares son las PDAs Dell Axim X5v y X51v, equipadas con una GPU Intel 27G. Estos modelos han sido ampliamente utilizados en el ámbito científico, y se ilustran en la Figura 5.2a. Estos dispositivos pueden programarse mediante la librería gráfica específica de Microsoft, Direct3D Mobile, si bien los fabricantes suelen proporcionar controladores para OpenGL ES. La versión de OpenGL ES disponible para las PDAs Dell Axim es la 1.. En 21, Microsoft presentó Windows Phone 7, su nueva plataforma móvil, con el objetivo de reemplazar a Windows Mobile. Todos aquellos dispositivos móviles que quieran incluir Windows Phone deben satisfacer una serie de requisitos impuestos por Microsoft, entre los que se encuentra la aceleración gráfica por hardware [RF1]. Al contrario que la mayoría de plataformas móviles, Windows Phone 7 no soporta OpenGL ES. En su lugar, es preciso emplear una librería específica de Microsoft Android Android [Mei1] es una plataforma software y un sistema operativo para teléfonos móviles basada en el núcleo de Linux. Ha sido desarrollado por Google. La Figura 5.2b muestra un popular teléfono con Android. Solo se permite el desarrollo de software en el lenguaje Java, que se ejecuta dentro de una máquina virtual. No obstante, no soporta las librerías estándar de JME, sino que debe emplearse una librería específica desarrollada por Google. Por tanto, una aplicación para Android no podrá adaptarse a otro dispositivo con JME salvo realizando grandes cambios. En términos gráficos, Android solo soporta la antigua especificación de OpenGL ES 1. a través de una especificación propietaria similar (pero no igual) a JME Java Bindings para OpenGL ES ios ios [Neu11] es un sistema operativo diseñado por Apple Inc. y basado en una variante del núcleo Mach del sistema operativo Mac OS X. Es empleado por el teléfono móvil iphone, véase Figura 5.2c, y por los dispositivos portátiles itouch e ipad. El modelo iphone 3G incorpora una GPU modelo PowerVR MBX, y soporta la especificación 1.1 de OpenGL ES. En cambio, modelos más recientes como el iphone 3GS, el iphone 4 o el ipad incorporan GPUs de la serie PowerVR SGX, que cumplen la especificación 2. de OpenGL ES.

94 94 Gráficos 3D para Dispositivos Móviles Apple proporciona su propio entorno de desarrollo para crear aplicaciones destinadas a ios, denominado Cocoa. El lenguaje de programación habitual en esta plataforma es el Objective-C. Este lenguaje es un superconjunto de C, el cual ha sido extendido mediante ciertos elementos sintácticos y semánticos para permitir el desarrollo dirigido a objetos. Todas las llamadas a la librería nativa del sistema deben de realizarse desde el lenguaje Objective-C, propiedad de Apple, lo cual dificulta la elaboración de software fácilmente transportable a distintos dispositivos. No obstante, se permite que código escrito en ANSI C y C++ pueda entremezclarse y enlazarse libremente con código Objective-C dentro del mismo ejecutable. Por tanto, si se aíslan las partes de código que deban acceder a la librería nativa del sistema, es posible transportar código C++ con OpenGL ES existente al iphone Symbian OS S6 Symbian OS [Bab7] es un sistema operativo diseñado específicamente para teléfonos móviles y otros dispositivos con recursos limitados. Existen en el mercado algunos teléfonos con Symbian OS y dotados de aceleración 3D por hardware. Por ejemplo, los Nokia N93 y N95, que incluyen una GPU PowerVR MBX. Una fotografía de este último se muestra en la Figura 5.2d. Estos dispositivos pueden programarse tanto con M3G (desde JME) como con OpenGL ES (desde C++). La especificación de OpenGL ES soportada es la Videoconsolas Portátiles Nintendo 3DS es una videoconsola portátil fabricada por Nintendo y anunciada a finales de 21, con fecha de lanzamiento en 211. Este modelo se ilustra en la Figura 5.2e. Está equipada con una GPU DMP Pica2, y soporta la especificación de OpenGL ES 1.1. Este dispositivo demuestra que a las GPUs móviles no programables aún le quedan largos años de vida. Pese a que diversos y costosos teléfonos móviles de alta gama incluyen GPUs con proceso gráfico programable (compatibles con OpenGL ES 2.), dispositivos de ocio electrónico de bajo coste siguen implementando OpenGL ES 1.1. PSP NGP es otra videoconsola portátil fabricada por Sony y anunciada en Enero de 211. Al contrario que el dispositivo anterior, esta videoconsola incorpora una GPU PowerVR de la serie SGX compatible con OpenGL ES 2..

95 Gráficos 3D para Dispositivos Móviles Redes Celulares Las redes de telefonía móvil están basadas en una red de celdas, donde cada celda dispone de un transmisor conocido como estación base. La capa de comunicación de las redes celulares pueden emplear diversas tecnologías, tales como General Packet Radio System (GPRS), su mejora Enhanced Data rates for GSM Evolution (EDGE). La generación de tecnologías de telefonía móvil formada por GPRS y EDGE se le conoce como telefonía móvil 2G o de segunda generación. A EDGE también se le conoce como 2.5G Más recientemente ha aparecido la tecnología de red Universal Mobile Telecommunication System (UMTS) y su mejora High-Speed Downlink Packet Access (HSDPA). De forma análoga, a la generación de tecnologías que comprende a ambas se la denomina 3G o de tercera generación, y HSDPA en particular también se le denomina 3.5G. 5.4 Trabajos Previos de Visualización 3D en Dispositivos Móviles En esta sección, repasaremos el estado del arte en el campo de la visualización de escenas genéricas tridimensionales en dispositivos móviles. No nos adentraremos a discutir aplicaciones específicas, videojuegos ni herramientas de desarrollo, que escapan del ámbito de este trabajo. La navegación interactiva a través de mundos 3D complejos requiere la habilidad de poder visualizar la escena a un número de imágenes por segundo aceptable, mientras se mantiene la calidad de la escena lo más alto posible. A lo largo de los años, se han propuesto diversas técnicas para acelerar la visualización de escenas y objetos complejos en dispositivos móviles. Los métodos de visualización local expuestos en la sección asumen que el modelo a visualizar cabe completamente en la memoria del dispositivo móvil. No obstante, debido a que es habitual que los dispositivos móviles se encuentren conectados a una red, es viable el uso de técnicas de visualización en las que el modelo 3D esté almacenado en un servidor remoto. En general, podemos clasificar los métodos de visualización cliente-servidor en tres grandes categorías, en función de dónde se realiza la tarea de visualización de geometría, [Mar]: Métodos de visualización en el lado del servidor, en los que todas las tareas de visualización recaen en un servidor gráfico remoto. Serán repasados en la sección

96 96 Gráficos 3D para Dispositivos Móviles Métodos de visualización en el lado del cliente, en los que la visualización recaen en el lado del cliente. Serán repasados en la sección Métodos de visualización híbridos, en los que cliente y servidor se reparten las tareas encaminadas a la visualización de la escena. Serán repasados en la sección Visualización Local Las técnicas de visualización local almacenan toda la escena a visualizar en el propio dispositivo. No necesitan mantener conexión con ningún servidor remoto. Son más simples de implementar y la experiencia del usuario no se ve mermada por congestión o cortes de red. No obstante, el tamaño de la escena a representar queda limitado por el tamaño de la memoria del dispositivo. Este tipo de métodos son habitualmente empleados en videojuegos. En la literatura científica, la mayoría de los trabajos propuestos para dispositivos móviles tratan de buscar estrategias más eficientes de dibujar una escena que la simple visualización directa. No obstante, estas técnicas siguen limitadas por la capacidad de cómputo y de almacenamiento de los dispositivos móviles. Repasaremos a continuación las diversas estrategias propuestas en la literatura. En dispositivos móviles que carezcan de hardware acelerador 3D, la transformación y dibujado de primitivas geométricas puede suponer una gran carga de cómputo a la CPU. Esto supone un derroche importante si la mayoría de los triángulos de la escena cubren menos de un píxel de la pantalla. Algunos autores [DD4, HL7] proponen simplificar la visualización mediante el dibujado de puntos en lugar de triángulos. Estas técnicas de visualización basadas en puntos aproximan geometrías complejas mediante un conjunto de puntos situados sobre la superficie de los objetos. El número de puntos a dibujar depende de la complejidad de los objetos y del tamaño de la pantalla. Duguet y Drettakis [DD4] avanzan en esta línea, y proponen generar conjuntos estructurados de puntos mediante el uso de una jerarquía de volúmenes envolventes. Esta técnica permite ajustar el nivel de detalle en función de los requerimientos de velocidad y de la pantalla. También resultan más eficientes en memoria puesto que no se requiere tener todo el modelo simultáneamente en memoria. No obstante, con la creciente inclusión de GPUs en los dispositivos móviles de gama alta, estas técnicas basadas en visualización de puntos carecen de utilidad, puesto que el dibujado y transformación de los triángulos recae sobre la GPU. Huang et al. [HBP + 7] propone otra técnica para simplificar la visualización en dispositivos móviles basada en la visualización expresiva o no fotorrealística. Su trabajo

97 Gráficos 3D para Dispositivos Móviles 97 expone cómo superar las limitaciones del dispositivo móvil empleado (PDA Dell Axim x51v) para conseguir diversos efectos interactivos. Estos efectos son interesantes para herramientas de diseño asistido por ordenador (CAD). Entre otros, se incluyen extracción de siluetas, visualización del interior del modelo mediante cortes, inclusión de anotaciones, etc. Yang et al. [YCL9] propone otra aplicación de CAD orientada a su uso en dispositivos móviles. Su trabajo se centra en describir un algoritmo compacto de triangulación basado en la triangulación secuencial y restringida de Delaunay. Mediante este algoritmo, un dispositivo móvil es capaz de calcular la malla de triángulos que aproxima a las entidades geométricas almacenadas en un fichero STEP (STandard for Exchange of Product model data), usualmente piezas mecánicas. Una vez calculada la triangulación, se procede a su dibujado mediante OpenGL ES. La ubicuidad de los dispositivos móviles ha animado a muchos investigadores y empresas privadas a desarrollar aplicaciones de navegación tridimensional en entornos urbanos. Los primeros acercamientos, tal y como 3DCityInfo [RV1] o LAMP3D [BC5] 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 [AKO7] aplicó comercialmente esta idea con éxito en la ciudad de Tokio. En [Nur9] podemos encontrar un análisis de trabajos sobre visualización urbana en 3D para dispositivos móviles. La ubicuidad de estos dispositivos también puede aprovecharse en el interior de los edificios. Silva et al. [SR9] emplea un octree para clasificar espacialmente escenas de interiores. Así, es posible descartar partes ocultas de la escena y acelerar la visualización. Afirman obtener velocidades interactivas (3 animaciones por segundo) en un teléfono con GPU, Nokia N82, en la visualización de una escena de interior con 6191 triángulos sin texturas. Por último, la visualización de volúmenes en dispositivos móviles es un tema muy poco explorado en la literatura. En ordenadores personales suelen aplicarse dos tipos de técnicas, ambas basadas en texturas: Empleo de tres conjuntos de lonchas bidimensionales alineadas con los ejes [RSEB + ]. Empleo de una textura tridimensional [CN94]. En dispositivos móviles, el soporte de texturas tridimensionales se ofrece mediante una extensión opcional de OpenGL ES 2. [Khr7], poco implementada por los fabricantes. Para solventar esta ausencia, Moser et al. [MW8] emplea la técnica de las lonchas bidimensional en un dispositivo Dell Axim x51v, dotado de hardware acelerador 3D. Los autores afirman visualizar un modelo volumétrico de resolución 63 3 vóxeles a una velo-

98 98 Gráficos 3D para Dispositivos Móviles cidad de 1.5 imágenes por segundo en una pantalla de resolución píxeles. Para aumentar la velocidad, los autores proponen reducir el número de fragmentos a procesar por la GPU. A tal fin, reducen la resolución de la imagen a dibujar y posteriormente la escalan hasta que ocupe toda la pantalla del dispositivo. Limitando la resolución a píxeles, afirman conseguir una velocidad de 9.9 animaciones por segundo Visualización en el Lado del Servidor En los métodos en el lado del servidor, existe un servidor remoto que lleva a cabo la visualización de la escena 3D. La imagen o conjunto de imágenes resultantes son enviadas al cliente, quien solo debe mostrarlas en la pantalla. Debido a que el cliente se limita a visualizar imágenes pre-generadas, los requerimientos de computación en el lado del cliente son independientes de la complejidad de la escena. Por tanto, estos métodos resultan muy apropiados para visualizar modelos geométricamente complejos en dispositivos con muy poca capacidad de cómputo o de almacenamiento. No obstante, estas técnicas presentan una serie de problemas: 1. Interactividad. La capacidad de interactuar en tiempo real con la escena se ve reducida debido a la alta dependencia con la red. Las altas latencias inherentes de las redes inalámbricas pueden provocar fácilmente congestión de red y caída del rendimiento. 2. Escalabilidad. Se requiere de un servidor con gran capacidad de cómputo. Un incremento en el número de clientes conectados concurrentemente al servidor puede incrementar con facilidad los tiempos de respuesta del mismo. El problema de enviar imágenes a través de una red ha sido muy estudiado, y podemos encontrar numerosas propuestas en la literatura. Chang et al. y Bouatouch et al. [CG2, KBGPGT5] propusieron técnicas de visualización remota basada en imágenes. El servidor proporciona una serie de imágenes (fotogramas clave) al cliente, y éste es capaz de calcular los fotogramas intermedios. Para ello, el servidor también proporciona el mapa de profundidad 1 de cada imagen. Para calcular los fotogramas intermedios, es preciso aplicar a cada píxel de la última imagen recibida una traslación en función del desplazamiento de la cámara. El problema de estas técnicas es cómo situar la cámara para que no aparezcan agujeros en la imagen. Proporcionar una solución general a este problema es una tarea complicada. Por dicha razón, estas soluciones tienen un ámbito de aplicación muy restringido. [KBGPGT5] aplicó esta técnica para la visualización de escenas urbanas. 1 Es habitual denominar al mapa de profundidad por su nombre en inglés, z-buffer.

99 Gráficos 3D para Dispositivos Móviles 99 Tanto Aranha et al. [ADD + 7] como Jeong y Kaufman [JK7] han propuesto sistemas de visualización remotos en los que el servidor genera una secuencia de imágenes mediante trazado de rayos. Estas imágenes son comprimidas y enviadas al dispositivo cliente para su visualización. Aranha se limitó a experimentar con un PC que simulaba a un dispositivo móvil. Jeong y Kaufman, por otro lado emplearon una PDA real para visualizar escenas médicas. Afirman conseguir una velocidad de 5 imágenes por segundo a través de una conexión inalámbrica de área local IEEE 82.11b con el servidor. Lamberti et al. [LS7] presentó un sistema completo de visualización remota basado en el envío de un flujo de vídeo MPEG a través de la red. En el lado del servidor emplean un clúster de ordenadores dotados de hardware gráfico y capaces de repartirse las tareas de visualización entre sí mediante el uso de un software llamado Chromium [HHN + 2]. Los autores afirman conseguir la visualización remota en una PDA a 3 imágenes por segundo y resolución de en un clúster de 8 PCs. No obstante, los autores admiten que dicho clúster no es lo suficientemente potente como para generar simultáneamente dos flujos de vídeo distintos para dos clientes. (por ejemplo, dos clientes que navegan por distintas partes de una misma escena). Wen et al. [WWW9] propone una solución que combina el uso de una estructura multirresolución para la visualización de terrenos en un servidor, junto con su visualización remota en un cliente móvil mediante envío de vídeo por red. Por desgracia, el artículo presenta una descripción muy superficial de la técnica, y no se ofrecen resultados de rendimiento en el cliente ni de uso de la red. Boukerche [BJP9] y Pazzi [PBH8] han presentado técnicas alternativas para la visualización remota basada en imágenes. Estos autores consiguen reducir el consumo de ancho de banda mediante el uso de técnicas de predicción de movimientos y de envío parcial y progresivo de imágenes panorámicas. No obstante, estas técnicas limitan severamente los movimientos del observador, y no se comportan bien en escenas dinámicas Visualización en el Lado del Cliente En los métodos en el lado del cliente, el cliente descarga la geometría y las texturas de la escena desde un servidor remoto y realiza la visualización de forma local. Este tipo de técnicas no precisan que el servidor posea ningún tipo de capacidad gráfica, por lo que reducen la carga de trabajo del servidor. Como contrapartida, este tipo de técnicas son más exigentes con el cliente, que debe poseer la capacidad de cómputo y de almacenamiento suficientes como para poder trabajar con escenas de la calidad requerida. Los métodos de visualización en el lado del cliente son apropiados para aplicaciones en las que la interacción en tiempo real es primordial, siempre y cuando asumamos que el cliente posea la capacidad de almacenar y visualizar la escena correspondiente.

100 1 Gráficos 3D para Dispositivos Móviles El concepto de trasmisión de escenas 3D bajo demanda de acuerdo a la región de interés ha atraído un considerable interés científico. Schneider [SM99] y Teler [TL1] emplearon la idea de nivel de detalle para trasmitir datos de manera adaptativa en función de criterios tales como el ancho de banda y la capacidad de cómputo disponibles. No obstante, estos autores no trabajaron explícitamente con dispositivos móviles. En el caso de los dispositivos móviles, y comparado con la gran cantidad de literatura que versa sobre técnicas de visualización en el lado del servidor, la cantidad de trabajos publicados sobre métodos en el lado del cliente es reducida. En esta sección repasaremos los trabajos al respecto que han sido publicados que abordan específicamente este problema en dispositivos móviles. Un ejemplo típico de métodos de visualización 3D en el lado del cliente lo constituyen los sistemas de visualización y navegación sobre terrenos. Dado que los conjuntos de datos de terrenos empleados en este tipo de aplicaciones exceden con frecuencia el orden de gigabytes o terabytes, es fácil exceder el tamaño de la memoria de cualquier ordenador convencional. Este hecho ha motivado a numerosos investigadores a desarrollar técnicas cliente-servidor en las que el modelo de datos completo reside en un servidor remoto. La literatura al respecto es amplia, Debido a la especial relevancia de este tipo de trabajos en la presente tesis, dedicaremos la Sección 5.6 a discutir las técnicas de visualización interactiva de terrenos propuestas en la literatura dentro del contexto de la computación móvil. Por otro lado, Lluch et al. [LGCV5,LGEC6] presentó un sistema cliente-servidor para la visualización de modelos multirresolución en un cliente móvil. Para visualizar un modelo 3D, el cliente proporciona al servidor los parámetros de la vista. El servidor extrae una malla de triángulos que representa al modelo con el nivel de detalle deseado, y lo recorta según el volumen de visión. Esta malla simplificada se envía al cliente para su visualización. Cada vez que la vista cambia, el servidor extrae la geometría de las nuevas partes visibles y las proporciona al cliente. El problema de esta técnica es la considerable latencia experimentada cuando la vista cambia y el modelo debe actualizarse. Esto limita el método a modelos de baja complejidad geométrica y a redes inalámbricas de área local. En [Nur6, Nur7, Nur8], Nurminen describe su proyecto m-loma 3D Map. Se ofrece una solución completa cliente-servidor para la navegación virtual por entornos urbanos mediante dispositivos móviles. Un servidor aloja la geometría y texturas de los edificios, y los trasmite de forma progresiva al cliente bajo demanda a través de una red inalámbrica. Para aumentar la eficiencia, se propone el uso de algoritmos de visibilidad. En una etapa de pre-procesamiento, la escena se divide en una rejilla tridimensional de bloques cúbicos. Entonces, para cada bloque se determina el conjunto de bloques potencialmente visibles. En tiempo de ejecución se emplea esta estructura para reducir el número de edificios a descargar y visualizar.

101 Gráficos 3D para Dispositivos Móviles Visualización Híbrida Los métodos híbridos persiguen repartir el cómputo entre el servidor y el cliente con el objetivo de mejorar el rendimiento del cliente. Ante la dificultad de representar gráficos foto realistas en dispositivos móviles poco potentes, algunos autores propusieron soluciones cliente-servidor híbridas basadas en visualización expresiva o no fotorrealística. En esta línea, Hekmatzada et al. [HMK2] y Diepstraten et al. [DGE4], presentaron trabajos en los que el servidor lleva a cabo técnicas de procesamiento de imagen sobre los modelos 3D a fin de extraer en tiempo real primitivas sencillas, tal y como líneas o siluetas. El uso de estas primitivas en lugar de la geometría real permite reducir el ancho de banda necesario para su trasmisión al cliente, así como aumentar la velocidad de visualización de la escena. Quillet et al. [QTG + 6] propuso un trabajo similar orientado a la navegación por escenas urbanas. Un servidor emplea algoritmos de detección de fronteras para extraer las características principales de la textura de las fachadas. Con esta información se genera una representación vectorial de la fachada mediante líneas. El cliente descarga la geometría de los edificios y la textura vectorial desde el servidor, y visualiza una imagen no fotorrealista. Es preciso remarcar que todas estas técnicas muestran una representación monocroma y distante con la realidad, lo que dificulta la comprensión de la escena por parte del usuario. Otro tipo de técnicas híbridas dividen el modelo 3D en dos partes. Una parte es dibujada por el servidor, y la otra parte es dibujada por el cliente. Estas técnicas persiguen reducir la complejidad geométrica de la escena mediante el reemplazo partes de la misma por imágenes bidimensionales generadas por el servidor. No obstante, determinar qué parte de la escena ha de ser visualizada por el servidor o el cliente no es una tarea trivial. En esta memoria de tesis presentamos un método híbrido de visualización de terrenos que emplea esta estrategia, y que será expuesto con profundidad en los siguientes capítulos.

102 12 Gráficos 3D para Dispositivos Móviles Figura 5.3.: Mapa de alturas. 5.5 Trabajos Previos en Visualización de Terrenos La forma más común de representar información de elevación de terrenos es mediante una matriz bidimensional de valores de altitud. Esta representación suele recibir el nombre de mapa digital de elevaciones (MDE), o simplemente, mapa de alturas. Según [LKR + 96], un mapa de alturas se describe como una rejilla bidimensional y rectangular de puntos elevados sobre el plano x y, con intervalos de muestreo discretos y regulares a lo largo de los ejes x e y, ver Figura 5.3. Usualmente, la distancia de muestreo es igual en ambos ejes, y recibe el nombre de resolución del mapa de alturas. Cada muestra tiene el valor de altitud que da la cota o altura de la superficie del terreno en ese punto en relación a un plano de referencia, usualmente el nivel del mar. Los MDE suelen almacenarse en matrices bidimensionales de valores de altura. Para visualizar los mapas de alturas se emplean algoritmos de triangulación que construyen una superficie teselada en triángulos, conocida como malla de triángulos, a partir de un conjunto de puntos de elevación. Los puntos de elevación están definidos en tres dimensiones. Las componentes x, y definen la posición geográfica del punto, mientras que su componente z indica su cota de altura. Pese a que los puntos están definidos en tres dimensiones, la superficie que se obtiene uniendo estos puntos mediante triángulos suele denominarse 2.5-dimensional. Esta denominación atiende a la causa de que existe un único valor z definido por cada coordenada x, y. Por tanto, la triangulación suele hacerse habitualmente empleando las componentes x,y de los puntos, e ignorando la z. Los mapas de alturas no suelen emplearse directamente para su visualización, pues cada vez se obtienen modelos con mayor tamaño y resolución. Este aumento en su complejidad introduce dos serias limitaciones: Es imposible alojar el modelo completo en memoria principal

103 Gráficos 3D para Dispositivos Móviles 13 (a) (b) Figura 5.4.: a) Geometría inicial de un mapa de alturas. b) Geometría simplificada en función de la distancia al observador. No es posible visualizarlo en tiempo real con el hardware actual. Por tanto, la mayoría de las técnicas de visualización interactiva de terrenos proponen diversos métodos de aproximación que reducen la resolución del modelo original. Por ejemplo, tiene poco interés representar una zona distante del terreno con una resolución tal que el número de triángulos que la representa sea mayor que el número de píxeles que ocupa en pantalla. Los métodos multirresolución son capaces de adaptar en tiempo real el nivel de detalle 2 del modelo de forma adaptativa según una métrica que estime el error cometido en la simplificación según la posición del observador, ver Figura 5.4. La visualización interactiva de terrenos es un campo maduro y con una larga historia. Para un estudio más general y detallado acerca de algoritmos de visualización de terrenos multirresolución, véase [PG7]. Pajarola y Gobbetti propusieron en dicho trabajo una clasificación en distintas familias de los métodos de visualización multirresolución de terrenos. Una clasificación similar fue propuesta por Lerbour [Ler1]. En lo que sigue, repasaremos los métodos de visualización multirresolución más comunes. Basándonos en las taxonomías anteriores, los clasificaremos en dos familias: Modelos basados en triangulaciones mediante árboles. Ya sean árboles cuaternarios y binarios, serán repasados en la Sección Técnicas de triangulación por bloques. Más recientes que los anteriores, su objetivo es obtener el mayor rendimiento de la GPU. Serán revisadas en la Sección Es muy habitual el uso del acrónimo LOD, del inglés level of detail.

104 14 Gráficos 3D para Dispositivos Móviles Esta última familia la dividiremos en tres grupos de técnicas que presentan propiedades similares entre sí: Métodos basados rejillas de bloques. Revisados en la Sección Métodos en rejillas anidadas. Revisados en la Sección Métodos basados en árboles de bloques. Revisados en la Sección Triangulación de Resolución Variable mediante Árboles La principal idea de estos métodos es la construcción de una jerarquía regular multirresolución bien sea por refinamiento o por simplificación. Estos métodos generan una malla en la que todos los triángulos son rectángulos e isósceles cuando se proyectan sobre un plano x y. Métodos de refinamiento. Consisten en generar una malla de triángulos a partir de las cuatro esquinas del terreno. Posteriormente, esta malla se refina mediante la división recursiva de los triángulos que la forman. La división de un triángulo consiste en bisecar la hipotenusa del mismo, lo que genera dos triángulos rectángulos iguales pero más pequeños. Estos métodos también son conocidos como arribaabajo. Métodos de simplificación. Consisten en el proceso inverso. Primeramente, se construye una malla de triángulos regular a partir de todos los puntos del mapa de alturas de un terreno. A continuación, se procede a su simplificación recursiva mediante la fusión de pares de triángulos rectángulos adyacentes. Estos métodos también son conocidos como abajo-arriba. En este tipo de técnicas, cualquier triángulo de la malla es candidato a ser dividido o fusionado. La pequeña granularidad a la que trabajan estas técnicas provoca que pueda haber cambios muy pequeños y localizados en la geometría de la malla entre dos marcos de animación consecutivos. Este hecho es conocido como nivel de detalle continuo 3 [LKR + 96]. La estructura regular de las operaciones de refinamiento y simplificación permite que las dependencias entre sucesivas operaciones de refinamiento/simplificación se puedan representadar implícitamente mediante un árbol. Dependiendo de la regla que se emplee para seleccionar los triángulos a dividir o fusionar, podemos distinguir entre árboles cuaternarios (quad-trees) [Sam89] o árboles binarios (bin-trees). 3 Es muy habitual el uso del acrónimo CLOD, del inglés continuous level of detail.

105 Gráficos 3D para Dispositivos Móviles 15 Entre los trabajos que emplean la jerarquía de quad-tree podemos encontrar CLOD- Quadtree [LKR + 96, RHSS98], Restricted Quadtree Triangulation [Paj98], SOAR [LP1, LP2] y Quad-TIN [PAL2]. Por otro lado, entre los trabajos que optan por la jerarquía de árboles binarios podemos encontrar ROAM [DWS + 97], Right-Triangulated Irregular Networks (RTIN) [EKT1] y Right-Triangular bin-tree [Ger3] Triangulación por Bloques El objetivo de las técnicas propuestas en la Sección era calcular en la CPU el número mínimo de triángulos a visualizar en cada marco de animación, a fin de que el adaptador gráfico pudiera visualizarlos en tiempo real. No obstante, con el auge de las GPUs, el cuello de botella pasó de ser el hardware gráfico a ser la CPU. Las técnicas que se presentan en esta sección pretenden explotar la GPU de forma más eficiente mediante la agrupación de triángulos en bloques. El concepto principal de las técnicas de triangulación por bloques es que la unidad mínima sobre la que se realiza el procesamiento de niveles de detalle ya no es el vértice o el triángulo individual (como en la Sección 5.5.1), sino una porción contigua de malla. Dependiendo del autor, estas porciones de terreno suelen recibir el nombre de bloque, parche o celda. Este cambio de concepto responde a las siguientes cuestiones. Primero, las técnicas clásicas propuestas en la Sección trabajan a nivel de vértice o triángulo. Por tanto, gestionar escenas con un número elevado de triángulos implica gestionar grandes árboles de dependencias en tiempo real. Esto requiere un considerable esfuerzo por parte de la CPU y un elevado número de accesos a memoria. Segundo, las GPUs están optimizadas para visualizar conjuntos de tiras de triángulos definidas mediante índices, [Pow5]. Además, el mayor rendimiento se obtiene cuando se dibuja geometría almacenada en la memoria de la GPU. Esto supone un problema para las técnicas de nivel de detalle continuo presentadas en la Sección 5.5.1, puesto que requieren volver a enviar la geometría a la GPU cada vez que se produce un pequeño cambio en la misma. Por esta razón, muchas técnicas recientes tratan de evitar reconstruir la malla del terreno mediante la composición en tiempo real de bloques de terreno pre-construidos, los cuales pueden dejarse alojados en memoria de la GPU. De esta forma, tanto el ancho de banda GPU-CPU como el número de llamadas a la función de dibujado pueden reducirse sensiblemente.

106 16 Gráficos 3D para Dispositivos Móviles Observador (a) (b) (c) Figura 5.5.: Triangulación por bloques. a) Rejilla de bloques. b) Rejilla anidada (clipmap). b) Árbol de bloques (quad-tree) Rejillas de Bloques Este tipo de técnicas emplean estructuras de datos sencillas que tan solo permiten una adaptación limitada del nivel de detalle de la superficie. Su funcionamiento general consiste en dividir de forma regular el terreno, por lo que se obtiene una rejilla de bloques del mismo tamaño. Posteriormente, para cada bloque se genera un conjunto de niveles de detalle a distinta resolución, ver Figura 5.5a. Para visualizar la escena de forma adaptativa, primero se determinan los bloques visibles según la vista actual. Posteriormente, para cada uno de ellos se selecciona el nivel de detalle más adecuado de entre los disponibles según algún criterio, por ejemplo, la distancia del bloque al observador. Este tipo de proceder recibe el nombre de nivel de detalle discreto. Los niveles de detalle pueden pre-calcularse y almacenarse como conjuntos de triángulos, o bien pueden generarse al vuelo mediante máscaras [PM5]. Estos triángulos pueden almacenarse en memoria de la GPU para una visualización más eficiente. Como desventajas, los métodos de rejilla de bloques consiguen un nivel de adaptación inferior al que consiguen las técnicas que emplean niveles de detalles continuos. Además, el mayor reto de estas técnicas consiste unir bloques adyacentes a distinto nivel de detalle sin que aparezcan discontinuidades geométricas entre ellos. Pese a ello, estos métodos son bastante populares debido a que presentan las siguientes ventajas: facilidad de implementación, pueden emplearse con terrenos arbitrariamente grandes, permiten integrarse de forma trivial con un sistema de red o de paginación en disco, y permiten un uso eficiente de la GPU. Trabajos notables que las emplean son [PM5, SW6].

107 Gráficos 3D para Dispositivos Móviles Rejillas Anidadas El geometry clipmap, presentado en [LH4] y revisado en [AH5,CH6] emplea un conjunto de rejillas rectangulares anidadas centradas alrededor del observador. Cada rejilla representa el terreno completo pero a un nivel de detalle distinto. Los sucesivos niveles de detalle incrementan la resolución del terreno en potencia de dos. La elección del nivel de detalle se realiza según la distancia al observador, en forma de anillos concéntricos centrados en la posición del mismo, tal y como se muestra en la Figura 5.5b. Las rejillas se almacenan en memoria de la GPU para una visualización más eficiente Árboles de Bloques Las técnicas que emplean árboles de bloques dividen el terreno en una estructura jerárquica de bloques de terreno. Cada bloque de terreno almacena la geometría preprocesada correspondiente a un nivel de detalle. Recordemos que las técnicas de nivel de detalle continuo presentadas en la Sección podían refinar un triángulo dividiéndolo, o fusionar triángulos adyacentes. Las técnicas de árboles de bloques actúan de forma análoga. Un bloque de terreno puede refinarse mediante su división en un número mayor de bloques más pequeños, y puede simplificarse mediante su fusión con bloques adyacentes en un único bloque de mayor tamaño. Estas dependencias entre bloques de terreno también se representan mediante una jerarquía en árbol (quad-tree o bin-tree). Todos los bloques almacenan el mismo número de triángulos. Por tanto, al dividir un bloque se está empleando mayor número de triángulos para representar el mismo área de terreno, y por tanto, el nivel de detalle es mayor. La Figura 5.5c presenta un ejemplo con jerarquía de quad-tree. Esta estructura jerárquica puede adaptarse dinámicamente para elegir los bloques de terreno necesarios en función del nivel de detalle deseado. Comparado con las técnicas de rejillas de bloques (Sección ), las técnicas de árboles de bloques presentan una mayor capacidad de adaptar el nivel de detalle del terreno. Comparado con las técnicas de triangulación de resolución variable mediante árboles (Sección 5.5.1), las técnicas de árboles de bloques trabajan con bloques de geometría fija en lugar de con triángulos o vértices individuales. Esto reduce la capacidad de adaptar el nivel de detalle del terreno. A cambio, el tamaño del árbol jerárquico es menor, y consecuentemente se disminuye el uso de la CPU. También explotan más eficientemente la GPU, puesto que la geometría de los bloques de terreno pueden almacenarse en memoria de la GPU y no actualizarse salvo que el bloque se fusione o se divida. Trabajos notables que emplean el enfoque de árboles de bloques incluyen a BDAM [GGM + 3] y los trabajos derivados [CGG + 3, GMC + 6, BGMP7], así como a los siguientes: [Pom, Lev2, LD3, HDJ5, WZW8, LKES9, LMG9, LMG1].

108 18 Gráficos 3D para Dispositivos Móviles 5.6 Visualización de Terrenos en Dispositivos Móviles A pesar de que algunos autores ya señalaron la necesidad de desarrollar métodos de visualización de terrenos capaces de funcionar de forma interactiva en entornos con recursos limitados, [RG97], la tendencia ha sido claramente la opuesta. Los algoritmos de visualización de terrenos han crecido tanto en complejidad como en requerimientos de cómputo. Por tanto, la visualización adaptativa de grandes terrenos a través de red en dispositivos móviles es todavía un campo muy poco explorado. Hasta donde alcanza nuestro conocimiento, las soluciones de visualización de terrenos propuestas en la literatura no consideran las dos propiedades que caracterizan a los dispositivos móviles: redes inalámbricas con bajo ancho de banda, y capacidades de cómputo limitadas. En esta sección discutimos la posibilidad de emplear las técnicas de visualización de terrenos expuestas en la Sección 5.5 en dispositivos móviles. En la Sección consideraremos el uso de estas técnicas en un entorno clienteservidor. En la Sección discutiremos el aprovechamiento que dichas técnicas pueden hacer de las GPU móviles. Por último, en la Sección repasamos con mayor profundidad las técnicas propuestas en la literatura que abordan específicamente el problema de la visualización interactiva de terrenos en dispositivos móviles Terrenos en Entornos Cliente-Servidor La mayoría de los métodos de visualización de terrenos en tiempo real asumen que el conjunto de datos del terreno puede alojarse completamente en memoria principal o virtual, y no consideran explícitamente la carga de terreno de forma dinámica desde un servidor remoto [PG7]. Esta suposición es inasumible en el entorno de la computación móvil. La mayoría de los sistemas operativos para dispositivos móviles no soportan memoria virtual, o carecen directamente de memoria secundaria. Es más, la memoria principal es tan limitada que la complejidad del modelo a visualizar se restringe considerablemente. Para que un método de visualización de terrenos pueda emplearse en un entorno móvil, el conjunto de datos del terreno debe almacenarse en un servidor remoto. La mayoría de las técnicas de visualización de terrenos que contemplan su uso en entornos

109 Gráficos 3D para Dispositivos Móviles 19 cliente-servidor se ajustan a la clasificación de métodos de visualización en el lado del cliente, tal y como fue definida en la Sección Las técnicas que emplean niveles de detalle continuos (Sección 5.5.1) necesitan considerar cada vértice o triángulo del terreno para generar la malla de triángulos a visualizar. Por tanto, es requisito que toda la geometría a su mejor nivel de detalle posible este accesible simultáneamente. Esto supone un problema cuando el tamaño del modelo del terreno excede el tamaño de la memoria del dispositivo. Lindstrom et al. [LP1,LP2] presentó una técnica para la visualización de terrenos multirresolución cuyo tamaño excede el tamaño de la memoria principal. Su enfoque consiste explotar la gestión de memoria virtual que proporcionan los sistemas operativos modernos. Desgraciadamente, esta técnica no es aplicable a dispositivos móviles, puesto que éstos suelen carecer de memoria virtual y de memoria secundaria suficiente como para almacenar un DTM complejo. Pajarola [Paj98] y Pouderoux [PM5], debido a la imposibilidad de alojar el conjunto de datos completo en memoria principal, utilizan un sistema de paginación de terrenos a través de red. Su funcionamiento emplea el concepto de ventana deslizante para mantener dinámicamente en memoria un conjunto visible de bloques de terreno. Los bloques de terreno son cargados de disco o de red bajo demanda. Todas las soluciones que se basan en bloques de terreno (Sección 5.5.2) permiten que cada bloque pueda cargarse de forma independiente desde disco o a través de red, por lo que pueden emplearse de forma natural para la visualización de grandes terrenos en entornos cliente-servidor. Dentro de éstas, las soluciones basadas en árboles de bloques (Sección ) permiten la carga progresiva de niveles de detalle desde disco o red. Esto es, descargar el bloque raíz del árbol permite dibujar completamente el terreno a su nivel de detalle más bajo. Si se requiere mayor calidad, el resto de niveles del árbol pueden descargarse de forma progresiva. El BDAM, presentado por Cignoni et al. [GGM + 3] asume que todo el conjunto de datos está almacenado en una unidad de almacenamiento secundario, por tanto debemos considerarlo como una técnica de visualización local. No obstante, Gobbetti [GMC + 6] y Bettio [BGMP7] adaptaron BDAM a su uso en red, permitiendo a un servidor remoto alojar la geometría. Estas técnicas hacen uso de algoritmos de compresión con pérdida mediante la transformada óndula (wavelet) que incrementan los requerimientos de CPU del cliente. Además, ambas técnicas precisan de una GPU programable. Lerbour et al. [LMG9] describe una arquitectura en red para la descarga y visualización remota de terrenos. Primeramente, el terreno se subdivide en un árbol de bloques, donde cada bloque contiene un conjunto de niveles de detalle con resolución creciente. Cada nivel de detalle añade nuevos valores de altura que no estaban presentes en el nivel

110 11 Gráficos 3D para Dispositivos Móviles anterior. El cliente lee los bloques desde un servidor remoto de forma adaptativa y bajo demanda. Mediante operaciones de fusión o división entre los valores de altura contenidos en los niveles de detalle de cada bloque, se obtiene de forma adaptativa el mapa de alturas a la resolución deseada. Esta estructura fue ideada con el objetivo principal de evitar la descarga de datos redundantes. En [LMG1], los autores expanden su trabajo para permitir el envío de texturas y evitar discontinuidades geométricas entre bloques de terreno adyacentes a distinto nivel de detalle. No obstante, no se proponen soluciones para la paginación de terrenos en memoria Uso del Hardware Gráfico Móvil Actualmente, cada vez más dispositivos móviles de gama alta incluyen GPU. No obstante, es de esperar que esta tendencia no se extienda a dispositivos de gama media y baja, donde un precio más reducido es mejor reclamo para atraer a un segmento de mercado relativamente poco interesado en la tecnología. Además, es destacable el hecho de que dispositivos móviles tan notables como Nintendo 3DS incorporen una GPU no programable. Por tanto, cualquier técnica moderna de visualización de terrenos orientada a dispositivos móviles ha de ser capaz de explotar la potencia de cómputo de la GPU, pero también de ofrecer un rendimiento suficiente en su ausencia o si ésta no es programable. Las GPUs móviles están optimizadas para dibujar tiras de triángulos [Pow5]. Una tira de triángulos es un tipo de primitiva que almacena un conjunto de triángulos adyacentes de forma compacta. Los tres primeros vértices de la tira representan un triángulo. Cada sucesivo vértice que se añada a partir del tercero genera un nuevo triángulo. Este triángulo se dibuja empleando dicho vértice y sus dos vértices precedentes. De esta forma, pueden enviarse grandes conjuntos de triángulos a la GPU sin redundancia de vértices. La mayoría de las soluciones que trabajan con bloques de terreno emplean largas tiras de triángulos. Usualmente, para visualizar cada bloque se utiliza un pequeño número de tiras. Estas tiras pueden generarse al vuelo [LKR + 96, RHSS98, Paj98], calcularse en una etapa de procesamiento previo [GGM + 3] u obtenerse mediante máscaras de índices [PM5, LKES9, LMG1, Ler1] Otro factor a considerar es el que algunas soluciones presentes en la literatura emplean los abanicos de triángulos como primitiva geométrica, [RHSS98, SW6]. Estas soluciones suelen ser más fáciles de implementar y adaptarse bien a los quad-trees. No obstante, suelen generar un elevado número de primitivas individuales. Este tipo de técnicas deben evitarse cuando se trabaja con dispositivos móviles por dos razones: El envío de una gran cantidad de primitivas pequeñas suponen un mayor tránsito de datos CPU-GPU y un consiguiente peor desempeño.

111 Gráficos 3D para Dispositivos Móviles 111 Algunas librerías para gráficos en dispositivos móviles solo aceptan tiras de triángulos como única primitiva. Esto ocurre en M3G [Jav5]. Otra forma importante de aumentar el rendimiento de la GPU consiste en reducir el número de transferencias de geometría entre la CPU y la GPU. Para conseguir esta reducción hay que almacenar la geometría en la memoria de la GPU, y reutilizarla en tanto y en cuanto ésta no cambie. La mayoría de las técnicas basadas en bloques de terreno que fueron presentadas en la Sección 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 [Paj98] propuso una solución basada dividir el terreno en una rejilla regular de bloques, y para cada bloque construir una triangulación en forma de quad-tree restrictivo. Esta triangulación se representa mediante una única tira de triángulos, que se genera mediante un recorrido recursivo de la jerarquía del quad-tree. Esta representación no es la más apropiada para una GPU debido a que requiere la reconstrucción de la malla y su reenvío a la GPU en cada marco de animación. Para atenuar este problema, Pajarola propuso retrasar el recálculo de la malla de triángulos de cada quadtree hasta que el error cometido supere un cierto umbral. Por último, es importante señalar que la mayoría de las técnicas más recientes requieren de una GPU programable, véase [LH4, AH5, SW6, CH6, LKES9, DSW9] solo por citar algunos ejemplos. Salvo que deseemos limitar nuestras aplicaciones a dispositivos móviles de gama muy alta, este tipo de técnicas deberían evitarse Soluciones Específicas para Dispositivos Móviles Pouderoux et al. [PM5] propuso un sistema de paginación muy simple, basado en rejillas de bloques (ver Sección ), y específicamente diseñado para dispositivos móviles. El terreno a su máxima resolución es dividido en un conjunto de bloques. El cliente descarga aquellos bloques situados alrededor de la posición del observador. Cada bloque descargado contiene todos los vértices necesarios para dibujarse a su máxima resolución. Para poder dibujar el terreno de forma adaptativa, se genera un conjunto de máscaras que permite visualizar los bloques a diversas resoluciones. A la hora de mostrar el terreno, se determinan los bloques visibles, y para cada uno de ellos se aplica la máscara adecuada en función del nivel de detalle deseado. Una máscara consiste en un vector de índices que indica a la librería gráfica cómo unir los vértices del bloque para formar una tira de triángulos.

112 112 Gráficos 3D para Dispositivos Móviles Los autores afirman que consiguen visualizar una escena de 3744 triángulos a una velocidad de 7 animaciones por segundo en un dispositivo PocketPC Toshiba e8, empleando como medio de conexión una red cableada USB 2. a 48 Mbps. Esta técnica, aunque rápida en dispositivos muy poco potentes, es burda y padece ciertos inconvenientes. No se emplea una estructura jerárquica multirresolución, lo que impide la transmisión progresiva de bloques de terreno. Es decir, para visualizar un bloque de terreno (incluso a su menor nivel de detalle), han debido descargarse previamente todos sus vértices. Además, no se resuelven las discontinuidades geométricas entre bloques adyacentes a distinto nivel de detalle. Esto hace que esta técnica no sea adecuada en la mayoría de las aplicaciones. De una forma similar, Wen et al. [WZW8] también divide el mapa de alturas en una rejilla de bloques, pero cada bloque se representa mediante un quad-tree. Desgraciadamente, la vaga descripción que ofrece el artículo de la técnica, junto con la ausencia de una adecuada evaluación de rendimiento, no nos permite juzgar correctamente esta propuesta. Por último, se trata de una técnica de visualización local (ver Sección 5.4.1), puesto que no se aborda el problema del envío de terreno cliente-servidor. 5.7 Conclusiones En este Capítulo se han presentado las bases de dos áreas distintas: la visualización de gráficos 3D en dispositivos móviles y la visualización interactiva de terrenos. También se ha presentado parte de su estado actual. Pese a que se trata de dos disciplinas dispares y muy amplias, sirva este capítulo como introducción antes de tratar los temas expuestos en los siguientes capítulos. Además, las técnicas de visualización en dispositivos móviles presentadas sirven para situar a los siguientes capítulos de la tesis en su contexto, ya que mucha de las decisiones de diseño y optimizaciones que serán tomadas responden a problemas intrínsecos de los dispositivos móviles. Problemas a los que todos los autores citados en la Sección 5.4 han tratado de dar solución, con mayor o menor éxito.

113 6 El Método de Visualización Híbrido 6.1 Introducción Los dispositivos móviles, tales y como PDAs o teléfonos inteligentes son ubicuos y cada vez más potentes. En la actualidad es frecuente su uso como guías interactivas de entornos reales, y ofrecen características tales como posicionamiento global (por ejemplo, mediante GPS), acceso a bases de datos espaciales, visualización de mapas y de terrenos. La visualización de terrenos en 3D es una tecnología de gran importancia en un amplio conjunto de campos, entre los que destacamos la navegación personal y los Sistemas de Información Geográfica 1. En este Capítulo describimos una técnica para la visualización remota de terrenos en dispositivos móviles que emplea redes inalámbricas con ancho de banda reducido, tal y como GPRS o UMTS. La Figura 6.1 ilustra el marco de trabajo general de nuestra propuesta. Proponemos una técnica de visualización cliente-servidor híbrida. El cliente visualiza la geometría del terreno próxima al observador, mientras que el terreno distante es representado mediante impostores. Estos impostores son generados por el servidor y enviados al cliente a través de la red. Debido a que los impostores representan terreno alejado del observador, no necesitan ser actualizados salvo que la posición del observador dentro del entorno virtual varíe por encima de un cierto umbral prefijado. Esta técnica proporciona las herramientas necesarias para dividir la carga de visualización entre cliente y 1 Es muy habitual el uso del acrónimo GIS, del inglés Geographic Information System. 113

114 114 El Método de Visualización Híbrido Satélite GPS Localización Localización Datos Terreno Localización Datos Terreno Interacción Datos Terreno 2D & 3D Servidor Red Celular Dispositivo Móvil Cliente Usuario Figura 6.1.: Marco de trabajo general de trasmisión de terrenos en dispositivos móviles. servidor, teniendo en cuenta los recursos disponibles en el cliente y la congestión de la red. El terreno se subdivide en bloques, y cada bloque se organiza siguiente una estructura de datos jerárquica. Este acercamiento permite hacer frente a la limitada memoria principal disponible en los dispositivos móviles, y brinda la posibilidad de emplear niveles de detalle. El cliente tan solo necesita descargar desde el servidor la cantidad más pequeña posible de bloques de terreno que le permitan visualizar la escena con un nivel de detalle adecuado en función de la vista actual. Los bloques adyacentes a distinto nivel de detalle se unen entre sí sin discontinuidades geométricas mediante el uso adaptativo de tiras de triángulos pre-calculadas. Esta técnica de visualización es simple, rápida y plenamente compatible con la naturaleza distribuida de nuestra aplicación. El trabajo realizado en este Capítulo ha sido parcialmente publicado en [SNR + 8, NSOJA9a, NSOJA1c, NSOJA1f, NSOJA1e] y en el informe técnico [NSOJA1b]. Los contenidos del capítulo se organizan de la siguiente forma. La Sección 6.2 repasa los principales conceptos sobre visión 3D que serán de utilidad en las siguientes secciones. La descripción general del enfoque de visualización híbrido y sus conceptos principales se ofrecen en la Sección 6.3. Las Secciones 6.4 y 6.5 describen los principales componentes del enfoque híbrido. En la Secciones 6.6 y 6.7 formalizaremos nuestra política para gestionar la actualización de dichos componentes. La Sección 6.8 describe el algoritmo empleado para la visualización de la escena. Finalmente, la Sección 6.9 ofrece algunas consideraciones sobre la parametrización y escalabilidad de nuestro método.

115 El Método de Visualización Híbrido Elementos de Visión en 3D En Informática Gráfica es habitual trabajar con objetos tridimensionales. No obstante, para poder visualizar un objeto 3D en una pantalla bidimensional es necesario introducir previamente una proyección que transforme al objeto 3D en una proyección del mismo en un plano 2D. En esta Sección repasaremos conceptos básicos acerca de proyecciones que serán de utilidad en secciones posteriores. En [FvFH9] puede encontrarse un estudio en profundidad sobre visión 3D. Para visualizar objetos 3D es necesario definir tres conceptos: Un volumen de visión en el mundo 3D. Una proyección sobre el plano de proyección. Una ventana de visión sobre el plano de proyección. En un primer paso, la geometría de cada objeto en el mundo 3D se recorta contra el volumen de visión 3D. Aquella geometría que supera este paso se proyecta sobre el plano de visión y se transforma sobre la ventana de visión 2D para su visualización. Como nuestra intención es imitar la forma en la que los ojos humanos perciben el mundo 3D, emplearemos una proyección en perspectiva donde el centro de proyección sea coincidente con la posición del observador o cámara. El plano de proyección se sitúa de tal forma que su normal viene dada por el vector de dirección de la línea que cruza el punto de visión, la línea de visión y atraviesa el punto de referencia. Este plano de proyección también se conoce como plano de visión. El plano de visión puede situarse en cualquier lugar en relación con los objetos 3D a ser proyectados. También es necesario definir una ventana sobre el plano de visión de tal manera que su contenido sea traspasado a la pantalla. La Figura 6.2 ilustra estos conceptos. Bajo estas condiciones, el volumen de visión es una pirámide rectangular cuya cúspide se encuentra en la posición de la cámara y sus aristas atraviesan las esquinas de la ventana de visión. Las cuatro caras laterales de la pirámide definen los planos de recorte laterales. El volumen de visión se encuentra limitado a lo largo de la dirección de visión mediante el plano de recorte delantero y el plano de recorte trasero. Ambos planos son paralelos al plano de visión y se encuentran respectivamente a una distancia z f ront y zback relativa a la cámara y medida a lo largo de la línea de visión, [FvFH9]. La Figura 6.3 muestra un ejemplo de volumen de visión. Entre los elementos matemáticos de la proyección en perspectiva, estamos interesados en recordar cómo se proyecta un punto 3D. En este trabajo, asumiremos que el plano

116 116 El Método de Visualización Híbrido Figura 6.2.: Plano y ventana de proyección. de proyección se encuentra a una distancia d de la posición de la cámara. Esta distancia es conocida como distancia focal de la cámara. Es fácil ver que si P(x,y,z) es un punto 3D, entonces su proyección P p en el plano de proyección (ver Figura 6.2) vendrá dada por las ecuaciones, P px = P x d P z ; En ocasiones, estas ecuaciones se expresan como P py = P y d P z (6.1) P px = P x P z /d ; P py = P y P z /d (6.2) Nótese que la distancia d es tan solo un factor de escala para las coordenadas P x y P y. Además, la división por la coordenada P z provoca que la proyección en perspectiva de objetos distantes sea más pequeña que la proyección de objetos más próximos a la cámara. Figura 6.3.: El volumen de visión se representa en color gris.

117 El Método de Visualización Híbrido El Método Híbrido En esta sección describiremos nuestro método para realizar la descarga y visualización de terrenos en dispositivos móviles. Este método está específicamente diseñado para utilizar redes comerciales de bajo ancho de banda, por ejemplo, GPRS y UMTS. Básicamente, nuestro método consiste en una técnica de visualización híbrida que reparte las tareas de visualización entre un servidor remoto, generalmente dotado de grandes recursos tanto software como hardware, y un cliente móvil, usualmente con recursos muy limitados. Las principales tareas realizadas por el servidor son: 1. El almacenamiento del terreno. 2. Proporcionar al cliente aquellos bloques de terreno que estén cercanos a la posición del usuario y que sean necesarios para su visualización. 3. La generación y envío al cliente de imágenes bidimensionales que sirvan para reemplazar la proyección de la geometría del terreno situada lejos de la posición del observador. En Informática Gráfica, estas imágenes bidimensionales pre-generadas que se emplean en lugar de geometría 3D real reciben el nombre de impostores. Por otro lado, las principales tareas del cliente son las siguientes: 1. La visualización en tiempo real del terreno situado cerca de la posición del usuario. Esta visualización se realiza conforme al nivel de detalle requerido. 2. La visualización del impostor que reemplaza a el terreno real situado en el fondo de la escena. 3. Conforme el usuario varíe su posición, solicitar al servidor actualizaciones tanto del terreno como del impostor. La frecuencia de estas peticiones pueden ajustarse de acuerdo a la capacidad del cliente, el estado de congestión de la red y la calidad de visualización requerida. En resumen, nuestro enfoque de visualización híbrido de terrenos ofrece las siguientes ventajas:

118 118 El Método de Visualización Híbrido El área de terreno a ser dibujada por el cliente puede ser menor sin que ello repercuta en una reducción de la distancia de visualización. El servidor puede emplear cualquier tipo de técnica de visualización de terrenos para la generación de los impostores, incluidas aquellas basadas en la GPU. No es necesario la generación de impostores a alta resolución, ya que las pantallas de los dispositivos móviles son pequeñas, usualmente con resoluciones de y píxeles. Este hecho permite ahorrar ancho de banda y reducir el cómputo en el servidor. 6.4 El Terreno La descarga y visualización adaptativa de grandes superficies de terreno en dispositivos móviles requiere emplear algoritmos y estructuras de datos que hayan sido específicamente adaptados. Debido a que tanto los recursos de CPU como de memoria son muy limitados en los dispositivos móviles, nuestros algoritmos y estructuras de datos han sido diseñados persiguiendo la simplicidad, eficiencia y escalabilidad El QuadTree Restrictivo Llegados a este punto es preciso describir una serie de términos. El término árbol cuaternario o quadtree [Sam84] se emplea para describir una clase de estructuras de datos jerárquicas bien conocidas basadas en el principio de descomposición recursiva del espacio. Los quadtrees se emplean habitualmente para dividir un dominio inicial consistente en un espacio cuadrado de dos dimensiones en un conjunto de cuadrados anidados mediante su sucesiva división recursiva en cuatro cuadrantes. La estructura de datos de un quadtree consiste en un árbol en el que cada nodo tiene exactamente o cuatro nodos descendientes o ningún nodo descendiente. En el primer caso, el nodo recibe el nombre de nodo interno, y en el segundo se le conoce como nodo hoja, ver Figura 6.4. El uso del quadtree para la triangulación y visualización de superficies implica seguir los siguientes pasos: 1. Obtener una rejilla uniforme de muestras de la superficie. 2. Evaluar cada región con respecto a algún criterio de aceptación (métrica de aproximación del error).

119 El Método de Visualización Híbrido 119 Figura 6.4.: Ejemplo de estructura de datos de un quadtree. Los nodos representados en gris son nodos hoja. Los nodos en blanco son nodos internos. 3. Dividir en cuatro cuadrantes iguales las regiones inaceptables. 4. Repetir los pasos 2 y 3 hasta que se satisfaga el criterio de aceptación en toda la superficie del terreno. 5. Generar una malla de triángulos por cada región del quadtree y visualizarla. Un quadtree restrictivo [DMP96] es una descomposición jerárquica del espacio que deriva de la estructura de datos del quadtree. No obstante, se añade una restricción adicional que implica que cuadrantes adyacentes pueden diferir en como máximo un nivel en la jerarquía del quadtree, ver Figura 6.5. En este caso, decimos que el árbol está localmente equilibrado Nuestra Estructura de Datos A continuación describimos nuestra estructura de datos para representar la representación del terreno. Nuestra propuesta se organiza de acuerdo a dos niveles diferentes: 1. Primer nivel. Este nivel subdivide el conjunto completo del terreno en una rejilla de bloques del mismo tamaño. Cada bloque contiene una región cuadrada del mapa de alturas que incluye (2 n + 1) (2 n + 1) valores de altura, siendo n un número entero mayor que cero. Los bloques adyacentes comparten los valores de altura situados en las fronteras comunes. 2. Segundo nivel. Consiste en generar un conjunto de quadtrees restrictivos, [DMP96], donde cada quadtree está asociado a un bloque de terreno. Los quadtrees empleados dividen el terreno en una estructura jerárquica de bloques de terreno, y por tanto, pertenecen a la familia de métodos de visualización de terrenos mediante árboles de bloques que fue introducida en la Sección

120 12 El Método de Visualización Híbrido (a) (b) Figura 6.5.: Ejemplos de: a) Quad-tree no restrictivo. b) Quad-tree restrictivo. El nodo raíz del quadtree almacena la representación del terreno con el menor nivel de detalle, l =, incluyendo (2 n + 1) (2 n + 1) valores de altura con n n. Entonces, el bloque de terreno almacenado en el nodo raíz del quadtree se subdivide en otros cuatro bloques de terreno cuadrados y del mismo tamaño, definidos por los dos bisectores perpendiculares del bloque de terreno padre. Estos cuatro bloques conforman los cuatro nodos hijos del nodo raíz del quadtree. Cada nodo resultante de la subdivisión añade un conjunto de puntos del terreno que no estaban incluidos en el nivel anterior. En nuestra solución, cada nuevo nivel de la jerarquía del quadtree dobla el número de puntos de la rejilla en ambas dimensiones en comparación con el nivel anterior. Por tanto, el número total de puntos empleados se cuadriplica. El número específico de puntos añadidos en cada nuevo nivel es constante y depende del valor inicial de n. La Figura 6.6 ilustra esta idea para n = 2. Nótese que, tras la subdivisión, la disposición de los puntos en la rejilla se preserva, y por tanto, la misma regla de subdivisión puede emplearse en divisiones subsiguientes. Este proceso de subdivisión continúa de forma recursiva, y termina cuando el nivel de detalle alcanza la mayor precisión posible, esto es, cuando los nodos del quadtree incluyen todos los puntos del terreno. La Figura 6.7 muestra los nodos del quadtree para un ejemplo de terreno con n = 3, n = 1 y l [...2]. Las texturas asociadas con el terreno también se organizan con una estructura de quadtree definida como anteriormente. Nuestra estructura de datos ofrece las siguientes ventajas:

121 El Método de Visualización Híbrido 121 Figura 6.6.: Subdivisón del terreno. Los puntos del terreno en un nodo del quadtree a un nivel de detalle l y los puntos incluidos en un nivel de detalle l + 1. Trabajos como [GGM + 3, LMG9, DSW9] emplean un único quadtree. Nuestro trabajo, en cambio, divide el terreno en un conjunto de bloques y genera un quadtree para cada uno de ellos. Así, los quadtrees resultantes tienen menor altura y resulta posible emplear técnicas de paginación de terrenos. La estructura permite tanto la visualización como la trasmisión. Los quadtrees son estructuras multirresolución que permiten de forma natural y dinámica elegir el nivel de detalle que mejor se adecúe a las necesidades de la aplicación. El terreno se visualiza mediante largas tiras de triángulos, cuya longitud depende del valor de n. Estas tiras pueden alojarse en memoria de vídeo, lo que resulta altamente eficiente en GPUs móviles [Pow5, Sen1]. Véase la Sección 6.8. Figura 6.7.: Conjuntos de puntos visualizados. a) Al nivel de detalle l =. b) Al nivel de detalle l = 1. c) Al nivel de detalle l = 2.

122 122 El Método de Visualización Híbrido Los recursos de CPU requeridos para manejar la estructura son bajos. Además, no se requiere GPU programable. Cada nodo puede visualizarse de forma independiente. Los quadtrees pueden trasmitirse de forma progresiva, comenzando desde los nodos raíz. Una vez que una raíz ha sido recibida, toda el área de terreno cubierta por el correspondiente quadtree puede visualizarse a su menor nivel de detalle. A partir de ese momento, la calidad comienza a incrementarse conforme los sucesivos niveles de detalle se van recibiendo. Típicamente, los mapas de alturas de distintas regiones se proporcionan con diferentes resoluciones. Como nuestra estructura almacena una rejilla de quadtrees independientes, la altura de cada uno de éstos puede ajustarse de acuerdo con la resolución disponible en el área cubierta por el quadtree Base de Datos del Servidor La base de datos del servidor consiste en dos componentes. El primer componente comprende tanto el mapa de alturas del terreno como las texturas asociadas. Ambas se alojan en el disco duro del servidor, para lo cual se emplea la estructura de datos descrita previamente. El segundo componente consiste en una tabla hash indexada por los identificadores de los quadtrees. Esta tabla se emplea para determinar rápidamente el nombre del fichero que contiene un quadtree dado. Cada uno de los nodos de quadtree recibe una clave que lo identifica de forma única dentro de la estructura de datos. Esta clave está formada por dos partes bien diferenciadas. La primera de ellas consiste en un número entero que identifica el quadtree al que pertenece el nodo. Cada uno de los quadtrees que forman parte de la rejilla se enumera de forma secuencial. La segunda parte de la clave, en cambio, identifica a cada nodo individual dentro del quadtree al que pertenece. Esta parte de la clave consiste en una cadena de caracteres definida de acuerdo a la codificación Morton, [Mor66]. Cada uno de los caracteres de la cadena toma un valor dentro de {, 1, 2, 3}. Comenzando por el nodo raíz, cada carácter denota sucesivamente el cuadrante en el que se localiza el nodo en la jerarquía del árbol. Así, la longitud total de esta cadena representa la profundidad del nodo en el quadtree. Las Figuras 6.8a y 6.8b ilustran los códigos para un quadtree de tres niveles. Desde el punto de vista del servidor, el conjunto de datos no es más que una base de datos con un par de claves para identificar unívocamente a un bloque de bytes que contiene los valores de altura y la textura de un nodo de quadtree. Esto significa que es posible emplear un gestor de base de datos ordinario. No obstante, hemos implementado nuestro propio gestor de almacenamiento, optimizado para almacenar nuestra estructura.

123 El Método de Visualización Híbrido (a) (b) Cabecera (c) Figura 6.8.: a) Códigos Morton para el tercer nivel de un quadtree. b) Códigos Morton para cada nivel del quadtree. c) Organización del fichero que almacena un quadtree. Durante una etapa de pre-procesamiento, construimos la rejilla de bloques de terreno y de texturas. Para cada bloque, se construye un quadtree completo y equilibrado que contiene tanto terreno como textura. Entonces, cada uno de estos quadtrees se serializa en un fichero independiente. Cada fichero comienza con una cabecera de metadatos que describe al quadtree almacenado a continuación. Estos metadatos incluyen el identificador del quadtree, el tamaño del mapa de alturas cubierto por el quadtree, el número de valores de altura almacenados en cada nodo, las coordenadas UTM de la esquina inferior izquierda del bloque del terreno, y la distancia (en metros) entre valores de altura adyacentes. Nuestro enfoque, de manera similar a [LP2, GGM + 3, LMG9], optimiza la disposición de datos geométricos para mejorar la coherencia de memoria y el rendimiento en las operaciones de entrada/salida. Para minimizar el número de accesos a disco, los

124 124 El Método de Visualización Híbrido datos de los ficheros se almacenan de acuerdo al orden de recorrido del árbol. Esto es, los registros de los ficheros se almacenan conforme a los niveles del quadtree. El primer registro corresponde al nodo raíz. Para cada nivel, los nodos se ordenan conforme a su código Morton asociado. Véase las Figuras 6.8b y 6.8c. De esta forma, nodos hermanos siempre se almacenan consecutivamente en disco, permitiendo su recuperación conjunta mediante una única operación de lectura. Nótese además que, dentro de un quadtree dado, el tamaño de cada nodo es constante. Por tanto, esta organización en disco permite calcular en tiempo constante la posición de un nodo concreto dentro del fichero. Por último, señalar que los valores de altura se discretizan y se almacenan como valores enteros de 2 bytes Base de Datos del Cliente La base de datos del cliente, al igual que su homóloga del servidor, almacena una rejilla de quadtrees. No obstante, esta rejilla constituye solo un pequeño subconjunto del total disponible en la base de datos del servidor. Este subconjunto define un área de terreno cuadrada centrada en la posición del observador que garantiza que pueda visualizarse la escena para cualquier posible línea de visión. Dependiendo de qué datos hayan sido solicitados por el cliente, los quadtrees pueden encontrarse incompletos y sin equilibrar. Al contrario que el servidor, los datos se almacenan en la memoria principal del cliente. Pero, debido al pequeño tamaño de las memorias incluidas en los dispositivos móviles, la base de datos del cliente se actualiza de forma adaptativa conforme al algoritmo explicado en la Sección 6.6. Cada nodo de quadtree de la base de datos del cliente almacena dos conjuntos de información. El primer conjunto está constituido por la geometría del bloque de terreno y la textura asociada. La geometría se almacena como un único vector de vértices tridimensionales, lo cual resulta óptimo para su visualización. Las coordenadas de los vértices emplean como origen la esquina inferior izquierda del nodo en cuestión. Aparte, el nodo raíz del quadtree almacena un vector de coordenadas de textura y un conjunto de máscaras de índices [PM5], que son compartidos por todos los nodos de la jerarquía del quadtree. Estas máscaras se emplean para la visualización del quadtree, tal y como se explica en la Sección 6.8. El segundo conjunto consiste en la traslación y escalado que es preciso aplicar al bloque de terreno contenido en cada nodo para su correcta visualización respecto al modelo completo del terreno Aritmética Entera y Precisión La mayoría de los métodos de visualización de terrenos emplean vértices expresados mediante números reales. No obstante, muchos dispositivos móviles de reducido costo

125 El Método de Visualización Híbrido 125 no incluyen unidad de procesamiento de punto flotante. Por ejemplo, los dispositivos basados en la CPU ARM9. Por tanto, en nuestro método, las coordenadas de los puntos se representan mediante enteros cortos de dos bytes. Aparte de mejorar el rendimiento de las operaciones aritméticas, el tamaño de los vectores de vértices es claramente inferior si usamos enteros cortos, a si usamos valores flotantes de cuatro u ocho bytes. Dado que la memoria es un recurso escaso y preciado en los dispositivos móviles y que las redes inalámbricas son lentas, una reducción tan considerable del tamaño de las estructuras de datos empleadas es una mejora interesante. El principal inconveniente de esta estrategia es que las coordenadas absolutas referentes a la Tierra son sencillamente demasiado grandes como para poder ser representadas mediante enteros cortos. Como se explicó en la Sección 6.4.4, este problema se solventa mediante la segmentación del terreno en pequeños bloques de terreno, y el almacenaje de cada uno de los bloques en coordenadas locales referentes a sus respectivos orígenes. Existe otro problema de precisión que afecta a los valores de altura del terreno. Como el rango de los números enteros cortos oscila entre y 65536, los valores de altura expresados en metros deben escalarse para cubrir todo este rango numérico. De no hacerse así, la resolución vertical del terreno quedaría reducida a un metro y la imagen generada podría sufrir un visible efecto de escalonado. 6.5 El Panorama En nuestro método, un impostor consiste en una imagen sintética bidimensional que simula una vista amplia del terreno físico situado lejos del observador. Estos impostores reciben el nombre de panoramas, [BJP8]. Un panorama captura la escena visible en todas las direcciones desde un punto del espacio dado. Para visualizar un panorama, éste debe previamente proyectarse sobre una forma tridimensional. El usuario debe emplazarse en el centro de esta forma, la cual se traslada de forma solidaria con el mismo. Así, el usuario percibe la ilusión de estar rodeado por una escena situada a una distancia infinita y que cubre los 36 grados a su alrededor. Las formas tridimensionales más empleadas son las esferas, los cilindros y los cubos. Panoramas cilíndricos. En un panorama cilíndrico, la imagen se proyecta en el lado interno de la cara curva de un cilindro, véase la Figura 6.9a. Este tipo de panoramas no cubre totalmente las rotaciones verticales, esto es, el usuario tiene limitada su visión hacia arriba y hacia abajo.

126 126 El Método de Visualización Híbrido (a) (b) (c) Figura 6.9.: Las formas más usuales empleadas para visualizar panoramas: a) cilindro, b) esfera, c) cubo. Panoramas esféricos. Estos panoramas proyectan la imagen en el interior de una esfera, ver Figura 6.9b. Por tanto, cubren exactamente 36 grados en el eje horizontal y 18 grados en el vertical. Esto permite que el usuario pueda mirar hacia cualquier dirección. Como contrapartida, estos panoramas crean distorsiones en la imagen y su visualización es poco eficiente. Panoramas cúbicos. En el caso de los panoramas cúbicos, ver Figura 6.9c, la imagen se proyecta en las seis caras internas de un cubo. Al igual que los panoramas esféricos, los panoramas cúbicos cubren todas las posibles líneas de visión del observador. Pero al contrario que éstos, son altamente eficientes puesto que son geométricamente muy sencillos de visualizar. Nuestro método emplea panoramas cúbicos. Un panorama proyectado sobre un cubo suele recibir habitualmente el nombre de skybox [Sha1] o mapa de entorno [BN76]. La construcción del panorama cúbico es sencilla [BJP9]. Cada cara cubre 9 grados de visión, tanto horizontalmente como verticalmente. Para construir el panorama, el servidor coloca primero su propia cámara en las coordenadas del observador proporcionadas por el cliente. A continuación, el servidor utiliza el terreno distante para sintetizar seis imágenes ortogonales. Estas imágenes son comprimidas mediante algún algoritmo estándar de compresión de imágenes, por ejemplo JPEG, y enviadas al cliente. El cliente construye la escena final mostrada al usuario mediante composición del terreno visualizado en tiempo real y el panorama recibido del servidor, tal y como ilustra la Figura 6.1. La Figura 6.11 muestra algunos ejemplos reales de terrenos visualizados con y sin panorama. En nuestra propuesta, el servidor dibuja el terreno situado en el fondo de la escena sobre un panorama. Por otra parte, el cliente visualiza en tiempo real el terreno cercano en función de cierto nivel de detalle. No obstante, el terreno mostrado al usuario en la

127 El Método de Visualización Híbrido 127 Figura 6.1.: Síntesis del terreno cercano, visualizado por el cliente, y el panorama, visualizado por el servidor. pantalla debe carecer de discontinuidades apreciables. Por tanto, nuestra técnica divide el terreno entre terreno cercano y panorama como se explica a continuación. Considérese que el volumen de visión del cliente esté limitado por los planos de recorte delantero y traseros, situados respectivamente a una distancia z f ront c y zback c del punto de visión. Similarmente, considérese que el volumen de visión del servidor esté limitado por los planos de recorte situados a distancia z f ront s y zback s. Ahora, requerimos que zback c = z f ront s, esto es, que el plano de recorte trasero del cliente y el delantero del servidor sean coincidentes. Ver Figura La distancia focal de la cámara es la misma tanto para cliente como para servidor. Bajo estas condiciones, el cliente visualiza el terreno próximo al observador, mientras que el alejado queda fuera de su volumen de visión. Por el contrario, el servidor recorta la parte cercana de la escena, y solamente tiene en consideración la alejada cuando construye el panorama. 6.6 Actualización del Terreno El servidor efectúa el envío de datos al cliente bajo demanda. Si el servidor necesita dividir un nodo hoja del quadtree para dibujar una parte del terreno con mejor nivel de detalle, entonces procede a descargar los nodos hijos desde el servidor. Mientras se efectúa la descarga, los datos disponibles localmente se emplean para visualizar la parte del terreno afectada, aunque sea a menor calidad de la deseada. Cuando el usuario arranca la aplicación y comienza a navegar por la escena, el cliente inicializa la rejilla local mediante la descarga del nodo raíz del quadtree sobre el que se encuentra el usuario. Estos datos permiten efectuar una visualización aproximada del terreno a baja resolución. Conforme el usuario se desplaza a lo largo del entorno virtual, la base de datos local se actualiza manteniendo siempre una región de terreno

128 128 El Método de Visualización Híbrido (a) (b) (c) (d) (e) (f) (g) (h) Figura 6.11.: Escenas dibujadas por un Nokia N95. La resolución de los panoramas era de píxeles por cara del cubo. a), c), e) y g) imágenes con panorama. b), d), f) y h) imágenes sin panorama. cuadrada alrededor del observador. Se descargan todos aquellos datos que sean precisos para la visualización, y se borran aquéllos que ya no sean necesarios. Recordemos de la Sección 6.4 que nuestra representación del terreno se divide en dos niveles. De forma análoga, la operación de actualización de la base de datos local del cliente se descompone en dos pasos. Primeramente, se procede a actualizar la rejilla de quadtrees. Posteriormente, se actualiza de forma individual cada uno de los quadtrees contenidos en la rejilla. Primer paso. Debido al gran tamaño de la rejilla regular que divide el terreno en bloques, empleamos un esquema de ventana deslizante para seleccionar un subconjunto a trasferir al cliente. Este esquema funciona de forma análoga a los clásicos sistemas de paginación de terrenos, [Paj98], donde el objetivo es mantener un área cuadrada activa centrada alrededor del punto de visión. Si el punto de visión se des-

129 El Método de Visualización Híbrido 129 zback s zfront s zback c zfront c Servidor Cliente Figura 6.12.: División del volumen de visión entre cliente y servidor. plaza sobre un nuevo bloque (no necesariamente adyacente), entonces se descargan nuevos bloques del servidor y se borran aquellos bloques que queden fuera de la nueva área cuadrada. Ver Figura Segundo paso. En el segundo paso, se procede a recorrer en sentido descendente todos los quadtrees contenidos en la rejilla local. En este recorrido se selecciona un conjunto de nodos de quadtree activos para su visualización. En el segundo paso, pueden emplearse múltiples criterios para determinar el conjunto de nodos activos. Nodos activos son aquéllos que serán visualizados durante el proceso de dibujado de la escena, véase Sección 6.8. Debido a que nuestro objetivo principal es reducir la carga de la CPU, empleamos una medida simple basada en la observación de que, en general, la resolución necesaria para visualizar el terreno decrece conforme la distancia al observador incrementa. Sea e la longitud del borde del bloque de terreno cubierto por el nodo de quadtree, sea d la distancia desde el punto de vista actual al centro del bloque, y sea C un parámetro configurable que determine la calidad del terreno. Entonces, definimos la importancia de un nodo, f, como f = d e C (6.3) Para una descripción más detallada de esta expresión, puede consultarse [RHSS98]. 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 [RHSS98, LKES9]. Para cada nodo de quadtree visitado durante el recorrido, se evalúa la expresión de la Ecuación 6.3:

130 13 El Método de Visualización Híbrido Figura 6.13.: Al desplazarse el punto de visión, siempre se mantiene un área cuadrada de bloques activos. Si f < 1 y no se ha alcanzado una profundidad máxima del árbol prefijada, digamos max depth, entonces el recorrido del árbol continúa. Si el nodo actual no tiene hijos, entonces se marca como activo y se procede a la descarga de los nodos hijos del servidor. La descarga se realiza en paralelo con la visualización. Si el nodo tiene hijos, entonces no se marca como activo pero se procede con el recorrido de sus hijos. Si f 1 o se ha alcanzado la profundidad máxima del árbol prefijada max depth, entonces el nodo se marca como activo lo que implica que será visualizado en el siguiente ciclo de dibujado. Si el nodo tiene hijos, se eliminan puesto que ya no son necesarios para la visualización del terreno. La recursividad termina. Para evitar volver a descargar nodos que han sido recientemente borrados (por ejemplo, si el observador vuelve atrás sobre sus pasos), empleamos una técnica de caché para mantener en memoria algunos de los nodos de quadtree a pesar de que ya no sean necesarios para su visualización. Nuestra técnica consiste en definir un valor umbral, σ 1, tal que aquellos nodos que satisfagan σ > f > 1 en la Ecuación 6.3 no son borrados ni visualizados, pero se mantienen en memoria en previsión de un posible uso futuro. 6.7 Actualización del Panorama Según se desprende de las ecuaciones de la proyección en perspectiva dadas en la Sección 6.2, conforme la distancia de la cámara a una zona del terreno se incrementa, su proyección resulta menos significativa. Además, los cambios en la proyección de puntos alejados producidos por variaciones pequeñas de la posición del observador son práctica-

131 El Método de Visualización Híbrido 131 mente inapreciables. Por tanto, enviar un nuevo panorama al cliente por cada movimiento del observador resulta en un tráfico inútil de datos. En esta sección formalizaremos el error cometido en la escena cuando el observador se desplaza pero el panorama empleado para simular terreno distante no se actualiza. Nuestra estrategia de actualización del panorama se basa en determinar este error, y en actualizar el panorama tan solo cuando el error supere un cierto umbral prefijado. Cualquier movimiento arbitrario puede expresarse como una combinación de traslaciones y rotaciones. Debido a que los panoramas cubren 36 grados de visión alrededor del observador, cambiar la línea de visión cuando el observador rota no incrementa el error del panorama mostrado. No obstante, si el observador se traslada, el panorama debería cambiar. Una traslación general puede definirse como la combinación lineal de tres traslaciones ortogonales a lo largo de los ejes. Por tanto, consideraremos dos casos diferenciados. En un primer caso, el observador se desplaza a lo largo del eje X y/o Y. En el otro caso, el observador se traslada a lo largo de la línea de visión. En ambos casos, la distancia d del observador hasta el plano de proyección se mantiene constante Traslación a lo Largo de los Ejes X e Y Sea V s el conjunto de los puntos situados en el volumen de visión del servidor, y V c el conjunto de puntos en el volumen de visión del cliente (ver Figura 6.12). Ahora, considérese que el observador se encuentra situado en un punto O, y que P V s es un punto del terreno situado en el volumen de visión del servidor. Entonces, cuando el panorama se genera, el servidor proyecta el punto P en el punto P p situado sobre el plano de proyección (ver Figura 6.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 P p. Por tanto, si el panorama no se actualiza, el error en el punto proyectado medido en píxeles es ε x = P px P px ; ε y = P py P py (6.4) Como se esperaba, cuanto mayor sea la traslación del observador, mayor será el error. Consecuentemente, conforme el observador se aleje de la posición inicial, se volverá más

132 132 El Método de Visualización Híbrido Figura 6.14.: Traslación a lo largo del eje X. aparente una discontinuidad entre el terreno visualizado localmente en tiempo real y el panorama. Teniendo en cuenta la proyección en perspectiva definida en la Ecuación 6.1, tenemos: P px = P x d P z ; P px = (P x + OO ) d P z (6.5) donde OO es la distancia a lo largo del eje X desde O hasta O, y d es la distancia focal de la cámara. Por tanto, el error en los puntos proyectados puede expresarse como ε x = P x d P z (P x + OO ) d P z = d P z (P x P x OO ) = d P z OO Como la coordenada P z se encuentra en el denominador, el error se decrementa conforma la distancia entre los puntos del terreno y el plano de proyección se incrementa. Ignorando el signo, la traslación del observador a lo largo del eje X correspondiente a un umbral de error dado, ε x, es OO = ε x P z d El máximo error posible para cualquier punto P(x,y,z) V s se produce para aquellos puntos que estén situados a la menor distancia posible del observador. Ahora bien, ningún

133 El Método de Visualización Híbrido 133 Figura 6.15.: Traslación a lo largo del eje Z. punto proyectado sobre el panorama puede encontrarse más cerca que la distancia al plano de recorte delantero del servidor, z f ront s. Es decir, P z z f ront s P(x,y,z) V s. Por tanto, tenemos que OO ε x z f ront s d Pero, de acuerdo con nuestra defición de panorama realizada en la Sección 6.5, zback c = z f ront s. Por tanto, para preservar la continuidad en la transición terreno-panorama, deberemos actualizar el panorama cada vez que la traslación del observador satisfaga la siguiente expresión: OO zback c > ε x (6.6) d De forma análoga, y si la ventana de visión no es cuadrada, también actualizaremos el panorama cada vez que se verifique: OO > ε y zback c d (6.7) Traslación a lo Largo de la Dirección de Visión Teniendo en cuenta que en nuestro método, la distancia focal d se mantiene siempre constante, consideremos ahora una traslación del observador a lo largo del eje Z, como se ilustra en la Figura En lo que sigue, formalizaremos solamente la componente X del error en los puntos proyectados. El mismo razonamiento debe aplicarse para el componente Y.

134 134 El Método de Visualización Híbrido En las mismas condiciones asumidas en la sección anterior, las componentes del punto proyectado antes y después de que el observador haya variado su posición son: P px = P x d P z ; P px = P x d P z OO (6.8) Para mantener constante la distancia d, el plano de proyección debe trasladarse de forma solidaria junto al observador. Nótese que, en general, cuando el observador se mueve a lo largo del eje Z, los puntos proyectados se desplazan simultáneamente a lo largo de ambos ejes, X e Y, del plano de proyección. El error definido por la Ecuación 6.4 es Combinando las Ecuaciones 6.8 y 6.9, tenemos Dividiendo entre P x d, obtenemos ε x = P px P px (6.9) d ε x = P x P z OO P d x P z ε x P x d = 1 P z OO 1 P z 1 P z OO = ε x P x d + 1 P z 1 P z OO = P zε x + P x d P x P z d P z OO = OO = P z P xp z d P z ε x + P x d P xp z d P z ε x + P x d Finalmente, y dado un umbral de error ε x, la traslación permitida a lo largo del eje Z es ) OO d = P z (1 P z P x ε x + d (6.1) La expresión de la Ecuación 6.1 puede reescribirse en función de los parámetros que definen el volumen de visión. Considérese que P(x,y,z) es un punto arbitrario en V s y que w denota la mitad del ancho de la ventana de visión. Entonces, ningún punto P(x,y,z) dentro del volumen de visión del servidor puede encontrarse más allá del plano de recorte lateral que corta al plano de proyección en w, ver Figura 6.16.

135 El Método de Visualización Híbrido 135 Figura 6.16.: Los Puntos P situados sobre el plano de recorte lateral definen el ángulo de visión abarcado por el observador situado en O. En consecuencia, tenemos tan(α) = P x P z < w d Y por tanto P z P x > d w Reemplazando la Ecuación 6.11 en la Ecuación 6.1, obtenemos ( ) OO P z 1 d ( d w ε = P z 1 w ) x + d ε x + w (6.11) De acuerdo con la definición de panorama realizada en la Sección 6.5, los puntos del terreno satisfacen que P z zback c, (ver Figura 6.12). Consecuentemente, el cliente debe solicitar al servidor una actualización del panorama cada vez que se satisfaga la siguiente condición: ( OO zback c 1 w ) (6.12) ε x + w

136 136 El Método de Visualización Híbrido Algoritmo para Actualizar el Panorama En nuestro método, tanto cliente como servidor necesitan compartir los siguientes parámetros: O: La posición del observador. d: La distancia focal de la cámara. w: La mitad de la anchura de la ventana de visión sobre el plano de visión. El algoritmo para actualizar el panorama puede sintetizarse en los siguientes pasos: 1. El observador se desplaza desde su posición original O hasta una nueva posición O. 2. El cliente visualiza el terreno cercano de acuerdo con la nueva posición O. 3. El cliente decide si solicitar un nuevo panorama al servidor. Si se satisface al menos uno de los criterios dados en las Ecuaciones 6.6, 6.7, o 6.12, entonces continuar con el paso 4. En otro caso, volver al paso El cliente emite una solicitud de nuevo panorama al servidor. En respuesta, el servidor proyecta el terreno distante sobre una imagen panorámica. Este panorama se envía al cliente, quien lo emplea como impostor para simular el terreno lejano. Volver al paso Transición de Panoramas Cuando el cliente recibe un panorama, éste permanece válido durante un cierto periodo de tiempo que depende del criterio detallado en secciones previas. En el momento en el que dicho criterio se satisface, se emite una solicitud al servidor, el cual responde con un panorama actualizado. Los nuevos panoramas siempre reemplazan a los antiguos. No obstante, sustituir un panorama por otro produce una discontinuidad temporal en la escena fácilmente detectable por el usuario. En esta Sección proponemos una técnica que emplea multi-texturas para implementar una animación de transición que oculta de forma efectiva y eficiente el cambio entre panoramas. Si el dispositivo está dotado de una GPU programable, el efecto de transición puede implementarse mediante un programa de fragmentos. Si se carece de ella, puede conseguirse el mismo efecto mediante una función de combinación de texturas, [PAM + 7]. Ya

137 El Método de Visualización Híbrido 137 sea en un caso o en el otro, empleamos la siguiente estrategia para transformar progresivamente el panorama viejo en el nuevo: Las imágenes de ambos panoramas, el viejo y el nuevo, se aplican de manera simultánea sobre el cubo que empleamos habitualmente para proyectar el panorama. A tal fin, hacemos uso de las capacidades multi-textura que nos brindan las librerías gráficas tal y como OpenGL ES. Ahora, definimos una función de combinación de texturas que toma como entradas el color de ambos panoramas, c y c 1, y genera un color c interpolado de forma lineal en función del tiempo de acuerdo a la siguiente expresión: ( c(t) = 1 t t ) ( ) t t c + c 1 dur dur donde t es el instante de tiempo en el que arranca la animación, dur es la duración de la misma y t es el instante de tiempo actual, todos ellos expresados en segundos. Al principio de la animación de transición, solo es visible el color del panorama antiguo, c. Conforme la animación progresa, el color de este panorama se combina progresivamente con el del nuevo panorama de acuerdo a la expresión anterior. Al final de la animación, el panorama viejo deja de ser visible y puede descartarse. En nuestros experimentos, una duración de la transición dur =,5 segundos ofrece resultados satisfactorios. 6.8 Visualización En esta sección se explica cómo se lleva a cabo la visualización del terreno. La operación de actualización de la base de datos local del cliente, ver Sección 6.6, 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 Dibujado Mediante Máscaras de Índices La operación de dibujado se efectúa una vez por cada marco de animación. Se efectúa un recorrido en profundidad para cada quadtree alojado en la rejilla de la base de datos local. Durante dichos recorridos, aquellos nodos de quadtree que se encuentren totalmente fuera del volumen de visión del cliente son descartados, tal y como se ilustra en las Figuras 6.17 y Cuando se alcance un nodo marcado como activo, se dibuja y se detiene la recursividad.

138 138 El Método de Visualización Híbrido Figura 6.17.: Representación 2D del recorte mediante el volumen de visión. Los bloques en gris no se visualizan. Figura 6.18.: Recorte mediante el volumen de visión. Las tiras de triángulos de unión se muestran en rojo.

139 El Método de Visualización Híbrido 139 (a) (b) (c) Figura 6.19.: a) Tira de triángulo para un nodo de 9 9 (n = 3) valores de altura. b) Tiras de unión para nodos adyacentes con el mismo nivel de detalle. c) Tiras de unión para nodos adyacentes con distinto nivel de detalle. Los puntos contenidos en cada nodo de quadtree activo se enlazan para formar tiras de triángulos mediante el uso de máscaras de índices, [PM5]. Dado que el número de puntos de terreno alojados en cada nodo de un quadtree es constante (ver Sección 6.4.2), las máscaras de índices son iguales para todos los nodos de un mismo quadtree dado. Puesto que además, las máscaras no varían durante la ejecución del programa, podemos pre-calcularlas y compartirlas entre todos los nodos del mismo árbol. El bloque de terreno contenido en el nodo se visualiza como una única tira de triángulos mediante el uso de la máscara correspondiente, ver Figura 6.19a. No obstante, en la unión entre nodos adyacentes a distinto nivel de detalle pueden aparecer discontinuidades geométricas evidentes como las que se aprecian en la Figura 6.2a. Estas discontinuidades deben ser evitadas. A tal fin hacemos uso de tiras de triángulos de unión que se adaptan a la resolución de ambos nodos, tal y como se aprecia en la Figura 6.2b. Como se afirmó en la Sectión 6.6, el nivel de detalle de nodos adyacentes puede diferir como mucho en una unidad. Por tanto, el número de tiras de unión necesarias es pequeño. Las tiras empleadas en nuestra técnica se ilustran en las Figuras 6.19b y 6.19c. Para determinar las tiras de triángulos necesarias para la visualización del bloque de terreno contenido en un nodo, primero debemos identificar a los cuatro nodos adyacentes. Para ello, empleamos sus respectivos códigos Morton. Si el nivel de detalle de los cuatro nodos adyacentes es igual o menor que el del nodo actual, entonces éste se dibuja mediante una malla de triángulos cuadrangular. Para generar esta malla se utiliza una única tira de triángulos, ver Figura 6.19a. Cuando el nivel de detalle de, al menos, un nodo adyacente sea mayor que el nivel de detalle del nodo actual, entonces debemos emplear tiras de unión para evitar discontinuidades geométricas en la frontera de los bloques. En este caso, los puntos del terreno

140 14 El Método de Visualización Híbrido (a) (b) Figura 6.2.: a) Discontinuidad geométrica. b) Uso de tiras de triángulos de unión (en rojo) para evitar discontinuidades. de la zona interna del bloque se dibujan mediante una única tira que genera una región cuadrangular de terreno. Pero para dibujar los cuatro bordes del bloque de terreno, es preciso utilizar cuatro tiras de unión, una por cada lado del bloque de terreno. Para cada lado se selecciona la tira que coincida con la resolución del nodo adyacente a ese lado. Las Figuras 6.19b y 6.19c ilustran estas ideas. Las Figuras 6.21 y 6.22 muestran ejemplos de terrenos visualizados mediante esta técnica. La Figura 6.23 muestra el aspecto final de la aplicación tras añadir el panorama. Trabajos como [LMG1] también hacen uso de tiras de triángulos especiales para unir nodos de quadtree adyacentes. Si bien, permiten cualquier diferencia de nivel de detalle entre nodos adyacentes. Como consecuencia, el número de tiras de unión a precalcular es muy elevado, ya que deben contemplarse todas las posibles combinaciones. Además, las tiras necesarias para unir nodos con diferencia de nivel de detalle mayor que uno contienen triángulos desiguales, largos y estrechos. Este hecho aumenta conforme la diferencia de nivel de detalle también aumenta. Como consecuencia, las tiras de triángulo generadas son de mala calidad. En nuestra técnica, en cambio, la diferencia entre niveles de detalle solo puede ser de cero o de uno. Por tanto, el conjunto de tiras a pre-calcular es muy reducido, y todos los triángulos necesarios son rectángulos y semejantes entre sí, ver Figuras 6.19b y c Almacenamiento de Geometría en Memoria de GPU Por lo general, el movimiento del observador suele ser suave. Por tanto, podemos explotar la coherencia espacial y temporal para reutilizar los mismos datos en diversos marcos de animación. A tal fin, almacenamos los puntos del terreno en un tipo de estruc-

141 El Método de Visualización Híbrido 141 Figura 6.21.: Triangulación de la superficie. Las mallas cuadrangulares aparecen en negro, las tiras de unión en rojo. Figura 6.22.: Vista de un terreno junto a su representación en malla de alambre. Las mallas cuadrangulares aparecen en negro, las tiras de unión en rojo.

142 142 El Método de Visualización Híbrido (a) (b) Figura 6.23.: Ejemplo de escenas visualizadas en un teléfono móvil iphone. n = 1, n = 3, C = 5, max depth = 5, zback c = 75m, resolución del panorama de píxeles por cara. a) Vista de Sierra Nevada (Granada) desde el pico Mulhacén, 926 triángulos. b) Pantano del Tranco (Jaén), 8374 triángulos. tura conocida como vertex buffer object (VBO). Esta estructura se envía a la GPU del cliente, en donde queda almacena en memoria de vídeo. Desde aquí es posible proceder a su visualización en reiteradas ocasiones sin necesidad de reenviar la geometría desde memoria principal a la GPU. De esta forma, se reduce de forma drástica el trasiego de datos entre CPU y GPU. Las máscaras de índices también se almacenan como VBOs en memoria de la GPU, donde son reutilizadas para dibujar todos los nodos de la estructura. Las GPUs móviles que satisfagan las especificaciones de OpenGL ES 1.1 ó 2. incluyen soporte para VBOs. Esta es la forma más óptima de transferir vértices e índices a las GPUs móviles [Pow5, Sen1]. Para aquellas plataformas en las que no se soporten VBOs, pueden emplearse vectores de vértices estándar, si bien entonces es preciso el envío de la geometría a la GPU por cada marco de animación.

143 El Método de Visualización Híbrido Parametrización del Método Existe un gran número de propuestas en la literatura para visualización de terrenos. Pero, en general, estas propuestas han sido diseñadas para ejecutarse en ordenadores de escritorio homogéneos, dotados de una potencia similar. Por tanto, las métricas que proponen estos trabajos emplean una calidad de visualización y de nivel de detalle prefijado. Pero el mundo de los dispositivos móviles es altamente heterogéneo. Por un lado, podemos encontrar dispositivos de gama baja equipados con CPUs lentas y memoria muy escasa. Estos dispositivos suelen carecer de unidad de procesamiento de flotantes y de hardware gráfico. Por el otro lado, podemos encontrar potentes teléfonos inteligentes, dotados de procesadores multi-núcleo con soporte para cálculo flotante e incluso GPU programable. Por tanto, no podemos esperar que técnicas generales diseñadas para ordenadores de escritorio sean eficientes en este entorno tan heterogéneo. Nuestra técnica de visualización híbrida hace uso de una arquitectura cliente-servidor altamente escalable. Esta arquitectura proporciona herramientas para ajustar el reparto de carga entre cliente y servidor de forma coherente con las características específicas del dispositivo móvil. El objetivo principal es que el cliente solo reciba modelos de datos que sea capaz de procesar de manera interactiva. Así, usuarios con móviles de consumo podrán realizar una navegación fluida sobre una aproximación a baja resolución del terreno, mientras que aquellos usuarios que posean un dispositivo de gama alta podrán disfrutar de un entorno mucho más rico y detallado. Nótese que esta técnica no se limita a dispositivos móviles, sino que se puede extender de forma natural a plataformas de escritorio. Nuestro modelo híbrido está altamente parametrizado. La calidad del terreno se controla mediante los parámetros C y max depth, definidos en la Sección 6.6. El rol interpretado por el panorama y su frecuencia de actualización se controla, respectivamente, por los planos de recorte de la cámara zback c y z f ront s, definidos en la Sección 6.5; y por el máximo error permitido en la proyección, ε x, ε y definidos en la Sección 6.7. Ver ejemplo en la Figura La posibilidad de ajustar estos parámetros proporciona una alta flexibilidad a nuestra técnica. Por ejemplo, de acuerdo con las Ecuaciones 6.6, 6.7 y 6.12, los métodos de visualización en el lado del servidor (Sección 5.4.2) y en el lado del cliente (Sección 5.4.3) son casos particulares de nuestro método híbrido: Si los planos z f ront c y zback c son coincidentes entonces el servidor se encarga de realizar toda la visualización, y el panorama requiere ser actualizado en cada movi-

144 144 El Método de Visualización Híbrido zback s zfront s zfront c zback c Servidor (a) Cliente zback s zfront s zback c zfront c Servidor (b) Cliente Figura 6.24.: Desplazando solidariamente los planos de recorte delantero del cliente y el trasero del servidor, podemos: a) Incrementar la carga gráfica del servidor, reduciendo la del cliente. b) Reducir la carga gráfica del servidor, aumentando la del cliente. miento del observador. Esto es, nuestra arquitectura se comporta como un método de visualización en el lado del servidor, como se ilustra en la Figura 6.25a. Por el contrario, si el plano del cliente zback c se aleja del observador hasta cumplir que zback c = zback s, entonces el cliente se encarga de realizar toda la visualización de la escena, y no hay necesidad de actualizar el panorama nunca. Esto es, la arquitectura se comporta como un método de visualización en el lado del cliente, ver Figura 6.25b.

145 El Método de Visualización Híbrido 145 zback s zfront s zback c,zfront c Servidor (a) Cliente zback s zfront s zback c zfront c Servidor (b) Cliente Figura 6.25.: Nuestro método de visualización híbrido comportándose como: a) Método de visualización en el servidor. b) Método de visualización en el cliente.

146

147 7 Arquitectura Multi-Cliente para Visualización Híbrida 7.1 Introducción En este capítulo describimos una arquitectura software que, mediante la aplicación del paradigma cliente-servidor, permite la descarga y visualización interactiva de terrenos en dispositivos móviles. Esta arquitectura pone en práctica el método de visualización híbrido de terrenos descrito en el Capítulo 6. Gracias a dicho método podemos mejorar tanto la calidad como la interactividad en la navegación de grandes terrenos en dispositivos móviles conectados a redes inalámbricas. Como se explicó en el Capítulo 6, los clientes móviles son responsables de dibujar en tiempo real el terreno próximo al observador. En cambio, el terreno lejano se representa mediante un impostor panorámico, que es sintetizado por un servidor remoto bajo demanda. El marco de trabajo propuesto permite proporcionar una experiencia consistente entre una gran variedad de dispositivos clientes. Éstos pueden oscilar desde teléfonos móviles de consumo hasta ordenadores personales. Nuestra arquitectura permite dividir las tareas de visualización entre el cliente y el servidor en función de la capacidad de cómputo del cliente y la saturación de la red. Además, la calidad de los panoramas se adapta para ajustarse a las capacidades de visualización de cada cliente. Al contrario que los métodos de visualización en el lado del servidor, ver Sección 5.4.2, nuestra arquitectura no precisa de un hardware potente y costoso en el lado del servidor. Los métodos de visualización en el lado del servidor desprecian completamente la capacidad de cómputo gráfico del cliente, al delegar todo el trabajo en el servidor. 147

148 148 Arquitectura Multi-Cliente para Visualización Híbrida Nuestro método de visualización híbrido, en cambio, es capaz de sacar partido de los dispositivos móviles más avanzados, pues se delega en ellos parte de las tareas de visualización. Esto reduce la carga del servidor, y consecuentemente, mejora la escalabilidad del sistema. Nuestros experimentos demuestran que un PC convencional equipado con una tarjeta aceleradora gráfica es capaz de proporcionar servicio a cientos de clientes concurrentes sin penalización en el rendimiento. El trabajo realizado en este Capítulo ha sido parcialmente publicado en el informe técnico [NSOJA1d]. El resto del capítulo se organiza de la siguiente forma: La Sección 7.2 presenta una visión general de la arquitectura propuesta, mientras que las Secciones 7.3, 7.4 y 7.5 describen en profundidad sus tres componentes principales. 7.2 El Marco de Trabajo Nuestro objetivo es definir una arquitectura de visualización híbrida capaz de permitir que un número variable de clientes se conecten simultáneamente al servidor. Cuanto mayor sea el número de clientes al que podamos ofrecer servicio, mayor será la escalabilidad del sistema. La arquitectura desarrollada se ilustra en la Figura 7.1. Consiste en tres componentes software bien diferenciados: el Cliente, el Servidor Principal y el Servidor de Panoramas. El Cliente se ejecuta en el dispositivo móvil y sus funciones son gestionar la interfaz de usuario y visualizar el terreno conforme a las capacidades de cómputo del dispositivo y del estado de la red. El Servidor Principal se ejecuta en el servidor y se encarga de gestionar todas las peticiones de los clientes. Cada vez que un cliente solicita un bloque de terreno, el Servidor Principal lo recupera de una base de datos y lo suministra al cliente. Éste lo utiliza para llevar a cabo la visualización del terreno cercano. El Servidor de Panoramas proporciona impostores panorámicos comprimidos, listos para ser enviados al cliente. Dado que cada componente se ha diseñado como una aplicación independente, el sistema es capaz de funcionar incluso sin Servidor de Panoramas. En este caso, cualquier petición de panorama realizada por el cliente es simplemente descartada, y el sistema funciona como una arquitectura estándar de visualización en el lado del cliente. En las siguientes secciones describiremos en detalle cada uno de estos tres componentes.

149 Arquitectura Multi-Cliente para Visualización Híbrida 149 Figura 7.1.: Arquitectura del sistema de visualización híbrido cliente-servidor.

150 15 Arquitectura Multi-Cliente para Visualización Híbrida 7.3 Arquitectura del Servidor Principal Para el Servidor Principal proponemos una arquitectura multi-hilo, como se ilustra en la Figura 7.1. El flujo de datos se gestiona mediante un hilo maestro, que permanece a la escucha de un puerto de red determinado, y aguarda posibles intentos de conexión por parte de los clientes. Una sesión típica se describe de la siguiente manera. Cuando un cliente realiza una conexión con el servidor, el hilo maestro lanza una Instancia del Servidor. Esta instancia recibe en su creación un socket de red con la conexión al cliente establecida. El hilo maestro puede entonces desentenderse de esta nueva conexión y volver a la escucha de la red en espera de nuevos clientes. La Instancia del Servidor permanece viva hasta que la conexión se cierra o la aplicación muera. Por tanto, múltiples clientes pueden permanecer conectados simultáneamente al servidor a la vez, cada uno de ellos asociado a una Instancia del Servidor dedicada. La comunicación entre el cliente y el servidor se realiza mediante un sencillo protocolo de petición-respuesta. Las peticiones más importantes que puede generar el cliente se clasifican en dos tipos: petición de nodos de quadtree y petición de panoramas. Según el tipo de petición recibida, el servidor elabora una respuesta adecuada y la envía por red hasta el cliente. Peticiones de nodos de quadtree. Si el cliente necesita descargar un nuevo bloque de terreno, envía una petición de este tipo al servidor. En respuesta, la Instancia del Servidor recupera los valores de altura y la textura asociada de la Base de Datos del Servidor y la remite hacia el cliente. Peticiones de panoramas. Este tipo de peticiones reciben un trato ligeramente distinto. Cuando el criterio expuesto en la Sección 6.7 se satisface, el cliente genera una peticion de panorama. La Instancia del Servidor no es capaz de proporcionar respuesta por sí misma a este tipo de peticiones, y por tanto, la redirige hacia el Servidor de Panoramas. Una vez procesada, el Servidor de Panoramas proporciona el nuevo panorama a la Instancia del Servidor, quien es responsable de remitirla por red hacia el cliente. Al diseñar la Instancia del Servidor hemos seguido un paradigma multi-hilo. La comunicación y el cómputo se realizan en diferentes hilos de ejecución. La Instancia del Servidor comprende tres módulos distintos, el módulo Cola de Peticiones, el módulo Codificador de Datos y el módulo Servidor. Ver Figura 7.1. Los dos primeros módulos se encargan de la trasmisión de red, mientras que el tercero se ejecuta en su propio hilo y lleva a cabo la lógica interna del servidor. La Base de Datos del Servidor ya fue descrita en la Sección

151 Arquitectura Multi-Cliente para Visualización Híbrida 151 El módulo Cola de Peticiones es responsable de escuchar el socket y de situar todas las peticiones recibidas desde el cliente en una cola de entrada. Para insertar y extraer peticiones de la cola se aplica un esquema primero en entrar, primero en salir. El módulo Servidor es el módulo principal de la Instancia del Servidor, dado que gestiona todo el flujo de datos entre las distintas partes del sistema. Este módulo extrae peticiones de los clientes de la Cola de Peticiones, elabora las respuestas adecuadas y las proporciona al módulo Codificador de Datos. Si el módulo Servidor necesita nodos de quadtree, texturas de terreno o algún tipo de información vectorial, entonces accede a la Base de Datos del Servidor para reunir dichos datos. Las peticiones de panorama, en cambio, son remitidas al Servidor de Panoramas. El módulo Codificador de Datos recibe respuestas ya procesadas del módulo Servidor, y lleva a cabo dos tareas. Primero, empaqueta las respuestas de acuerdo a nuestro protocolo de red. Segundo, escribe estos paquetes en el socket de red para su envío al cliente. 7.4 Arquitectura del Servidor de Panoramas El Servidor de Panoramas es responsable de visualizar y comprimir todos los panoramas solicitados por las múltiples Instancias del Servidor. Las peticiones concurrentes son despachadas mediante un esquema primero en entrar, primero en salir. En resumen, el Servidor de Panoramas construye la imagen panorámica mediante la proyección del terreno distante en la memoria de imagen o framebuffer de la tarjeta de vídeo. Una vez el terreno ha sido proyectado, la imagen se copia desde la memoria de la tarjeta de vídeo hasta la memoria principal del Servidor de Panoramas. Estas imágenes ocupan un excesivo espacio en memoria, por lo que es necesario emplear algún algoritmo de compresión de imágenes que haga posible su trasmisión eficiente a dispositivos móviles. En nuestra implementación utilizamos JPEG. Finalmente, el panorama comprimido se proporciona a la Instancia del Servidor que lo solicitó, y quien es responsable de su envío al cliente. Estas tareas son llevadas a cabo por el módulo Sintetizador de Panoramas y por el módulo Compresor de Panoramas, ver Figura 7.1. Ambos módulos se describen, respectivamente, en las Secciones y

152 152 Arquitectura Multi-Cliente para Visualización Híbrida El Sintetizador de Panoramas Como se afirmó en el Capítulo 6, el método de visualización híbrido divide la tarea de visualización entre el cliente y el servidor. El Sintetizador de Panoramas es responsable de llevar a cabo la tarea de visualización del servidor. La construcción del panorama cúbico se realiza según el método explicado en la Sección 6.5. Tras la síntesis, las seis imágenes resultantes se encuentran alojadas en el framebuffer, por lo que se copian a memoria principal. Una vez efectuada la copia, las imágenes son emplazadas en una cola de espera en donde aguardan hasta que el módulo Compresor de Panoramas las recepciona y las comprime. En la práctica, solo resulta necesario generar las cuatro imágenes laterales del panorama. Puesto que estamos trabajando con modelos 2.5-dimensionales, en general nunca existe terreno sobre la posición del observador. Además, la cara inferior del cubo del panorama permanece oculta por la geometría del terreno cercano visualizada por el cliente. La mayoría de las librerías 3D, tal y como OpenGL/OpenGL ES y Direct3D 1 [MB5] no resultan seguras en un entorno multi-hilo. Esto es, el contexto gráfico permanece siempre ligado a un hilo específico. En consecuencia, resulta imposible acceder a la librería gráfica desde distintos hilos. En nuestra arquitectura, el contexto gráfico del servidor se encuentra ligado al hilo del Sintetizador de Panoramas. No obstante, si existe más de un adaptador gráfico instalado en el servidor, es posible ejecutar una instancia del Sintetizador de Panoramas por adaptador. Como cada instancia se ejecuta en un hilo separado y dispone de su propio contexto gráfico, podemos realizar la visualización de múltiples panoramas en paralelo. Las Secciones y describen algunos aspectos importantes del Sintetizador de Panoramas Adaptación de los Panoramas a los Clientes Nuestro servidor debe ser capaz de dar soporte a una amplia variedad de clientes. Los dispositivos móviles disponen de capacidades y de tamaños de pantalla de muy diversa índole. Por tanto, el módulo Sintetizador de Panoramas debe ser capaz de modificar la resolución de los panoramas generados para adecuarse a esta pluralidad. Además, dada la naturaleza multi-cliente de nuestra aplicación, hemos de esperar que peticiones de clientes con diferentes necesidades lleguen entremezcladas al servidor. Para enfrentarse a esta necesidad, el Sintetizador de Panoramas necesita poder modificar constantemente su resolución sin incurrir en costes adicionales. Este problema se soluciona de una manera sencilla pero eficiente mediante el uso de una extensión de OpenGL conocida como framebuffer object (FBO), [Khr8].

153 Arquitectura Multi-Cliente para Visualización Híbrida 153 Objeto Framebuffer Objeto Renderbuffer Objeto Renderbuffer Objeto Renderbuffer Objeto Renderbuffer Imagen 128x128 Imagen 256x256 Imagen 512x512 Imagen 124x124 Mem. Profundidad 128x128 Mem. Profundidad 256x256 Mem. Profundidad 512x512 Mem. Profundidad 124x124 Figura 7.2.: Conexión entre un framebuffer object y una colección de renderbuffers a diferente resolución. Un FBO consiste en una colección de memorias lógicas intermedias con sus estados asociados y que definen hacia dónde se redirecciona la salida del proceso gráfico de OpenGL. Los FBOs proporcionan un mecanismo para realizar visualización directamente en una memoria de imagen en lugar de en pantalla. Este mecanismo es además más eficiente que los homólogos proporcionados por los sistemas de ventanas. La memoria de imagen de un FBO se conoce como objetos renderbuffer. Estos objetos encapsulan una imagen bidimensional a una determinada resolución, tanto el mapa de colores como el de profundidad. Una característica importante de los FBOs es que permiten conectar y desconectar diferentes objetos renderbuffer de forma eficiente. Intercambiar el renderbuffer de un FBO por otro distinto es una operación sencilla y más rápida que cambiar entre diferentes FBOs. Nuestra solución para adaptar la resolución de los panoramas al cliente es la siguiente. Primero, creamos un FBO y un conjunto de renderbuffers, cada uno de ellos con una resolución diferente. Debido a que las librerías gráficas para móviles solo soportan texturas cuadradas cuyo lado pueda expresarse como potencia de dos, hemos definido una colección de renderbuffers a cuatro resoluciones diferentes: , , y píxeles. Este conjunto de resoluciones cubre un amplio espectro de clientes, desde dispositivos móviles a ordenadores personales. En tiempo de ejecución, el renderbuffer deseado es enlazado al FBO en función de las necesidades del cliente, ver Figura 7.2. Tras la visualización, el renderbuffer contiene la imagen a la resolución deseada, y puede copiarse a memoria principal. El número de renderbuffers y su resolución son parámetros de la aplicación que pueden ajustarse en función de las necesidades reales.

154 154 Arquitectura Multi-Cliente para Visualización Híbrida Visualización de Terrenos desde Múltiples Vistas La naturaleza multi-cliente de nuestra arquitectura provoca otro problema que debe ser estudiado. La mayoría de los métodos de visualización de terrenos son dependientes de la vista, esto es, generan una malla poligonal que aproxima al terreno en función de la posición del observador. Cambios en esta posición provocan la actualización y posterior reenvío de la malla a la GPU. Para reducir el coste de estas operaciones, los métodos de visualización de terrenos descritos en la Sección asumen que el observador se desplaza de forma suave y fluida. Así, se puede explotar la coherencia entre marcos de animación consecutivos para evitar complejos recálculos y reenvíos de la malla poligonal del terreno a la GPU. No obstante, en nuestra arquitectura no es posible hacer esta asunción, pues deseamos dar soporte a múltiples clientes, cada uno de ellos dotado de su propia vista. Estos clientes pueden estar navegando distintas partes del terreno a velocidades y direcciones arbitrarias, a menudo divergentes entre sí. En consecuencia, existe una elevada posibilidad de que peticiones de panoramas consecutivas hayan sido enviadas por distintos clientes situados sobre zonas alejadas del terreno. Por tanto, desde el punto de vista del servidor no existe coherencia entre fotogramas consecutivos. La solución inmediata a este problema sería emplear una representación del terreno individual por cada cliente conectado. Para ello, podría emplearse cualquiera de las técnicas de visualización de terrenos descritas en la literatura. No obstante, para que nuestro sistema sea escalable, el servidor debe ser capaz de proveer de panoramas a un elevado número de clientes concurrentes. Esto hace inviable mantener una representación de los datos individual por cada cliente. Es imperativo definir una estructura que permita una representación única de los datos sin redundancias, y que no sufra penalización en rendimiento al trasladar el punto de vista a posiciones arbitrarias entre fotograma y fotograma. Nuestra solución consiste en emplear un quadtree restrictivo implícito similar a [LKES9]. La visualización del terreno a plasmar en el panorama se realiza en tres pasos: 1. Pre-procesamiento. En una etapa previa de procesamiento, el terreno completo se divide en una rejilla regular de bloques cuadrados y del mismo tamaño. Puede emplearse el mismo particionado descrito en la Sección 6.4. Entonces, los valores de altura del área cubierta por cada bloque se codifican como una textura de dos bytes por texel. La ortofoto de dicho área también se codifica como una textura, en este caso de color RGB. Este conjunto de texturas se almacena en memoria secundaria del Servidor de Panoramas. 2. Carga dinámica de texturas en GPU. Cuando el Sintetizador de Panoramas recibe una petición para generar un nuevo panorama, selecciona el conjunto de bloques que son visibles desde el punto de vista del cliente. Si las texturas de dichos bloques

155 Arquitectura Multi-Cliente para Visualización Híbrida 155 se encuentran ya cargadas en memoria de la GPU, se reutilizan. En otro caso, se cargan de disco y se envían a memoria de la GPU. Los mapas de altura y las texturas permanecen en la GPU para uso posterior. De esta forma, pueden reutilizarse en la generación de panoramas para clientes diferentes sin provocar trasferencias de datos CPU-GPU adicionales. No obstante, como la memoria de la GPU es un recurso limitado, empleamos un algoritmo de reemplazo del menos recientemente usado (LRU) para descartar bloques de memoria innecesarios. 3. Construcción y visualización de los quadtrees implícitos. Se construye al vuelo un quadtree restrictivo por cada bloque seleccionado en el paso anterior mediante su división recursiva en cuatro bloques iguales. Los quadtrees pueden ser incompletos y sin equilibrar. El proceso de construcción se dirige mediante el criterio de división de nodos en función de la vista expresado en la Ecuación 6.3 de la Sección 6.6. Esta estructura es implícita, pues no almacena ningún tipo de información geométrica. En lugar de ello, el recurrido recursivo simplemente determina la posición y tamaño de cada nodo del quadtree con respecto a su nodo padre mediante operaciones de multiplicación de matrices de traslación y escalado. Por tanto, es muy rápido de construir y se descarta tras la generación del panorama. Cada nodo hoja se visualiza mediante una malla plana, para lo cual utilizamos tiras de triángulos pre-procesadas. La elevación de cada vértice se asigna directamente en GPU mediante un programa de vértices. Este programa emplea las coordenadas de textura de cada vértice para extraer de la textura de alturas el valor de elevación correcto. Las discontinuidades geométricas se evitan median tiras de triángulos predefinidas que unen a los nodos vecinos. Gracias al uso de Vertex Buffer Objects (VBOs), podemos alojar todas estas mallas en memoria de la GPU. Adicionalmente, y dado que los panoramas se emplean para representar terreno distante, no existe necesidad de visualizar el terreno con alta calidad geométrica y de textura. Para justificar esta afirmación, hemos de tener en cuenta que emplear una resolución de terreno o de textura tal que dos o más puntos de la escena se proyecten sobre el mismo píxel de la pantalla no mejora la calidad de la imagen visualizada. En lo que sigue, nos referiremos a la Figura 7.3. Asumamos que h es la resolución del mapa de alturas medido en coordenadas absolutas del mundo, y que p denota la distancia en coordenadas de la pantalla entre la proyección de dos puntos adyacentes del mapa de alturas, medida en píxeles. Si r es la resolución de la pantalla en píxeles y w es el ancho del volumen de visión a una distancia dist del observador, y teniendo en cuenta el primer teorema de Tales, es fácil ver que: h p = w r

156 156 Arquitectura Multi-Cliente para Visualización Híbrida Figura 7.3.: Relación entre coordenadas del mundo y coordenadas de la pantalla. Ahora, si θ denota campo de visión de la vista, tenemos tan θ 2 = w/2 dist Combinando las ecuaciones anteriores, tenemos [Coh98] h = 2 r tan θ p dist (7.1) 2 De acuerdo con nuestra definición de panorama dada en la Sección 6.5, los puntos del terreno en el panorama cumplen que dist z f ront s y θ = 9. Si ajustamos la distancia p entre valores de altura adyacentes a 1 píxel, medido en el espacio de la pantalla, tenemos que h 2 r z f ront s Para ilustrar el significado de esta relación, asumamos que el plano de recorte delantero del servidor está situado a una distancia z f ront s = 75m del observador, y que la resolución del panorama es r = 512 píxeles. Bajo estas condiciones, no hay necesidad de almacenar el mapa de alturas a una resolución mayor de metros. En el momento en el que este texto fue escrito, las tarjetas gráficas incluyen al menos 512 MB de memoria de vídeo. Por tanto, un mapa de alturas con resolución de 8 metros del tamaño de España (5 Km 2 ) y su mapa de textura asociado puede alojarse enteramente en memoria de vídeo. De acuerdo a la Ecuación 7.1, y asumiendo las mismas condiciones que antes, un mapa de alturas de resolución 8 metros provoca una distancia

157 Arquitectura Multi-Cliente para Visualización Híbrida 157 máxima en pantalla entre valores de altura adyacentes de p = 2,73 píxeles, medido en coordenadas de pantalla. Esta aproximación puede considerarse lo suficientemente buena, especialmente si consideramos el hecho de que los panoramas se emplean para simular terreno en el fondo de la escena El Compresor de Panoramas El módulo Compresor de Panoramas se alimenta con los panoramas sin comprimir generados por el módulo Sitentizador de Panoramas (descrito en la Sección anterior). Estos panoramas se comprimen en un formato útil tanto para su trasmisión por red como para una rápida descompresión por el cliente móvil. Tan pronto el panorama termina de comprimirse, es enviado al módulo Servidor de Panoramas. Hemos implementado el Compresor de Panoramas sobre una versión ad hoc de la librería de software libre Libjpeg, [Ind98]. Esta librería ha sido ligeramente modificada para permitir que las imágenes comprimidas resultantes sean almacenadas en memoria en lugar de en ficheros, como es el comportamiento habitual de la librería. El grado de compresión JPEG puede ajustarse para alcanzar un compromiso entre requerimientos de ancho de banda y calidad del panorama. El Compresor de Panoramas ha sido diseñado como un módulo independiente que se ejecuta en su hilo específico, ver Figura 7.1. De esta manera, este módulo y el Sintetizador de Panoramas pueden trabajar en cadena: mientras el módulo Compresor comprime un panorama, el módulo Sintetizador puede ir dibujando el siguiente. Desde el punto de vista computacional, la etapa de codificación de imágenes en formato JPEG representa la tarea más costosa de todo el proceso de generación de panoramas. Pero tengamos en cuenta que la mayoría de CPUs para ordenadores de escritorio están dotadas de múltiples núcleos de procesamiento. Por tanto, es posible sacar provecho de estos recursos computacionales mediante el lanzamiento de múltiples instancias del módulo Compresor de Panoramas. Estas estancias se ejecutan en paralelo, y pueden codificar múltiples imágenes de manera concurrente. En consecuencia, este paralelismo permite reducir el tiempo global de esta etapa. Este esquema resulta especialmente atractivo por dos factores. Primero es muy probable que el servidor reciba múltiples peticiones de panoramas a la vez. Y segundo, cada panorama consiste en varias imágenes independientes. Ambos factores amplían las posibilidades de paralelizar cómputos, y por tanto, de obtener una mejora del rendimiento global. El número de Compresores de Panoramas a lanzar en paralelo es un parámetro configurable de la aplicación. En nuestra implementación, utilizamos un Compresor por cada núcleo de procesamiento disponible en el servidor.

158 158 Arquitectura Multi-Cliente para Visualización Híbrida 7.5 Arquitectura del Cliente Nuestro sistema requiere que los clientes ejecuten una aplicación específica. Cualquier desarrollo software orientado a dispositivos móviles ha de tener muy presentes las severas limitaciones computacionales y de memoria que caracterizan a estas plataformas. Por tanto, el diseño y desarrollo de la aplicación cliente ha venido marcado desde el principio por dos máximas: facilitar la transportabilidad del código fuente entre diferentes plataformas (ver Apéndice A), y optimizar los recursos disponibles. Dado que C++ es el lenguaje de programación con mayor soporte en dispositivos móviles, hemos seleccionado C++ y OpenGL ES [Khr1b] como herramientas software con los que construir nuestra aplicación. Para mejorar aún más la transportabilidad, la aplicación ha sido construida sobre una capa de abstracción o middleware. Esta capa constituye una fina capa implementada directamente sobre las librerías nativas del sistema, y no añaden sobrecarga reseñable. Una mayor descripción de esta capa puede encontrarse en la Sección A.4. Gracias a este diseño, nuestra aplicación cliente se ejecuta sin cambios sobre los sistemas operativos ios (iphone, itouch, ipad), Symbian OS, Win32 y GNU/- Linux. Como ejemplo, la Figura 7.4 muestra una imagen de una sesión multi-usuario en la que participan un ordenador personal portátil, un Nokia N95 y un iphone 3GS, todos ellos conectados al mismo servidor. Al igual que la arquitectura del servidor, en el cliente también se aplica el paradigma de la programación multi-hilo, tal y como se muestra en la Figura 7.1. Hilo de Visualización. Este hilo gestiona la interfaz de usuario, dibuja la escena y actualiza la Base de Datos Local. Hilo de Red. Algunas operaciones especialmente costosas pueden bloquear la ejecución del programa, y por tanto, dar sensación de bloqueo o de pérdida de interactividad al usuario. Dichas tareas se han movido a un segundo hilo, que se ejecuta en paralelo con el de visualización. Concretamente, este hilo gestiona las operaciones de comunicación por red con el servidor. También efectúa la descompresión de las texturas y panoramas recibidos desde el servidor. La aplicación cliente también consta de diversos módulos con funciones bien diferenciadas. El resto de la Sección detalla el funcionamiento de todos los módulos del cliente que pueden verse en la Figura 7.1. Nótese que la Base de Datos Local del Cliente ya fue descrita en la Sección 6.4.4, y no se repite aquí.

159 Arquitectura Multi-Cliente para Visualización Híbrida 159 Figura 7.4.: Una sesión multi-usuario con un PC portátil, un Nokia N95 y un iphone 3GS, todos conectados al mismo servidor. Los puntos rojos muestran en tiempo real la posición de cada cliente conectado El Módulo de Visualización El módulo de Visualización emplea la información almacenada en la Base de Datos Local para dibujar la escena en función de la posición actual del observador, tal y como se explica en la Sección 6.8. La imagen final mostrada al usuario es resultado de combinar la geometría próxima al observador con el impostor panorámico proporcionado por el servidor. Este módulo también gestiona la interfaz de usuario. En la actualidad, se permite la interacción por medio de pantallas táctiles, teclados y acelerómetros. Por último, este módulo también es capaz de desplazar al observador en función de la localización real del usuario obtenida mediante GPS.

160 16 Arquitectura Multi-Cliente para Visualización Híbrida Módulo Actualizador de la Base de Datos Local El módulo Actualizador de la Base de Datos Local del cliente se encarga de actualizar la Base de Datos Local de manera dinámica de acuerdo a las necesidades actuales de la aplicación. En resúmen, este módulo tiene tres tareas: 1. Recibir del Hilo de Red toda la información proporcionada por el servidor e incorporarla en la Base de Datos Local. 2. Actualizar el terreno según se detalla en la Sección 6.6. Recordemos que esto implica a) seleccionar un conjunto de nodos de quadtree activos para su visualización; b) determinar qué nuevos datos de terreno han de ser pedidos al servidor y generar solicitudes de ser menester; y c) descartar aquellas partes del terreno que ya no sean necesarias. 3. Determinar si el panorama actual necesita ser actualizado según el criterio expuesto en la Sección 6.7. De ser así, generar la solicitud correspondiente. Todas estas solicitudes son enviadas a una cola temporal, donde aguardan su turno hasta que el Hilo de Red las transmita al servidor El Decodificador de Datos y el Generador de Peticiones Estos dos módulos se ejecutan en el Hilo de Red y gestionan la comunicación con el servidor. El módulo Decodificador de Datos recibe paquetes de red enviados por el servidor y es responsable de desempaquetarlos, decodificarlos y proporcionarlos al módulo Actualizador de la Base de Datos. Esta decodificación incluye descomprimir texturas y panoramas. El Generador de Peticiones recibe las peticiones generadas por el módulo Actualizador de la Base de Datos, las empaqueta y las escribe en una cola de salida. Desde esta cola son enviadas al servidor a través del socket de red. 7.6 Protocolo de Red La lo largo de los años se han desarrollado diversas capas software o middleware que proporcionan transparencia de comunicación y simplifican la tarea de desarrollar un protocolo de red. Algunos ejemplos incluyen a CORBA, SOAP y RMI. No obstante,

161 Arquitectura Multi-Cliente para Visualización Híbrida 161 estas soluciones consumen considerables recursos y añaden una sobrecarga significativa a la red. Por tanto, no se ajustan bien a las necesidades de los dispositivos móviles. En esta sección presentamos el protocolo de red específicamente diseñado para dar soporte a nuestra solución. También se señalan algunos problemas implícitos a las redes inalámbricas que pueden afectar a la calidad de las transmisiones Descripción del Protocolo La mayoría de protocolos de descarga de terrenos existentes en la literatura se basan en sencillos protocolos de trasferencia de ficheros, por ejemplo HTTP [PM5, BGMP7]. Muchos de los trabajos ni siquiera proporcionan ningún detalle al respecto. Dado que necesitamos que nuestro servidor sea lo suficientemente inteligente como para poder generar impostores panorámicos bajo demanda, hemos desarrollado nuestro propio protocolo de comunicación entre pares, capaz de trabajar con redes heterogéneas y de transmitir grandes cantidades de datos binarios. En esencia, se trata de un protocolo petición-respuesta. Cuando un cliente necesita descargar nuevos datos, envía un mensaje de petición al servidor, y entonces aguarda a que la petición le sea contestada. Dado que el protocolo conocido como Transmission Control Protocol (TCP) es confiable, orientado a la conexión y proporciona control sobre el flujo de datos y la congestión, hemos implementado nuestro propio protocolo directamente sobre TCP. Nuestro protocolo consiste en dos tipos de mensajes: peticiones y respuestas. Una petición puede solicitar un nuevo bloque de la rejilla de terrenos (realmente, un nodo raíz de quadtree), un nodo no raíz de quadtree o un panorama. El servidor elabora y envía el mensaje de respuesta adecuado, que proporciona los datos solicitados al cliente. Cuando un cliente necesita dividir un nodo para mejorar el nivel de detalle, emite una única petición al servidor. Entonces, el servidor lee estos cuatro nodos de disco mediante una única operación de lectura, ver Sección 6.4.3, y los envía empaquetados en un único mensaje. Este esquema minimiza el número de accesos a disco así como el número de mensajes de red. Las texturas, dado su mayor tamaño, se envían de manera independiente. Todos los mensajes constan de una cabecera. En función del tipo de mensaje, tras la cabecera puede incluirse un cuerpo que contiene datos. La cabecera proporciona información tal y como la longitud del mensaje en bytes, el identificador de quadtree y del nodo solicitado, las coordenadas de la cámara desde donde sintetizar un panorama, etc. Los mensajes más significativos de nuestro protocolo se muestran en la Figura 7.5.

162 162 Arquitectura Multi-Cliente para Visualización Híbrida Message type Reserved Padding X coordinate Y coordinate Z coordinate (a) Message type Panorama Sector X coordinate Y coordinate Z coordinate Message leght Texture data (b) Message type Reserved Message leght Quadtree Id Message type Reserved Message leght Quadtree Id Node Id Node Id Data (c) (d) Figura 7.5.: Mensajes más significativos de nuestro protocolo. a) Solicitud de un nuevo panorama. b) Respuesta. c) Solicitud de un nodo de quadtree. d) Respuesta Comunicación Asíncrona Como [FYPA5] se encarga de señalar, las redes inalámbricas suelen exhibir bajo ancho de banda y altas latencias, lo cual puede afectar al rendimiento de TCP. Este protocolo asume que la pérdida de paquetes de red se debe a la congestión. En consecuencia, TCP decrementa su ventana de congestión, lo que provoca una reducción en la velocidad de transmisión. Este método era efectivo en redes cableadas tradicionales, pero en redes inalámbricas la pérdida de paquetes puede deberse a la alta tasa de errores del medio de trasmisión o a la pérdida de señal. En estos casos, reducir la ventana de congestión provoca una reducción innecesaria del aprovechamiento de la red inalámbrica. Además, TCP emplea un algoritmo de control de congestión llamado slow start, [Pos81], que penaliza las primeras transmisiones efectuadas al establecer la conexión. Esto reduce considerablemente el rendimiento de protocolos como HTTP, en los que la conexión se cierra tras cada interacción petición-respuesta individual. Para evitar este problema, nuestro protocolo emplea una conexión persistente. Es decir, una vez establecido un canal de comunicación, se mantiene abierto en tanto y en cuanto la aplicación siga ejecutándose. La comunicación no puede ser síncrona (bloqueante) porque el bajo ancho de banda y las altas latencias de las redes inalámbricas provocarían que nuestros hilos de red (ver

163 Arquitectura Multi-Cliente para Visualización Híbrida 163 Secciones 7.3 y 7.5.3) se bloquearan largo tiempo durante las transmisiones. Por tanto, nuestro protocolo emplea comunicación asíncrona (no bloqueante). Desgraciadamente, esto incrementa el riesgo de desbordamiento en la memoria intermedia del socket TCP, gestionada por el sistema operativo. El problema se hace más patente cuanto mayor sea la lentitud de la red, [FYPA5]. Para poder sacar el máximo partido al ancho de banda de la red y a la vez evitar estos problemas de desbordamiento de la memoria del socket, gestionamos nuestras propias memorias intermedias de comunicación almacenadas en memoria del usuario. Las respuestas del servidor se añaden a una cola de salida, desde donde son enviadas de forma asíncrona vía TCP. Este envío se produce en cuanto el número de mensajes almacenados en la cola alcanza un número prefijado, o al expirar un contador de tiempo. Este método provoca una importante mejora en los tiempos de respuesta porque permite el envío de múltiples mensajes empaquetados dentro de un único paquete de TC- P/IP. De esta forma, y dado que la mayoría de los mensajes de nuestro protocolo propio son pequeños, se reduce la sobrecarga de red. Por ejemplo, si un nodo de quadtree almacena 9 9 valores de altura codificados como enteros de dos bytes, entonces un mensaje para enviar los cuatro nodos hermanos al cliente ocupa 648 bytes (sin contar cabecera). El típico tamaño de segmento máximo de TCP, [Pos83], para redes Ethernet es aproximadamente 15 bytes. En consecuencia, un único paquete TCP puede contener múltiples mensajes. La cabecera de un paquete TCP ocupa 2 bytes, por tanto, la sobrecarga de red puede minimizarse mediante el envío de paquetes grandes. Es más, la carga en las redes y enrutadores IP también se reduce. De igual manera, los mensajes que llegan al cliente también son recibidos de forma asíncrona y almacenados en una cola de entrada, donde aguardan hasta ser procesados. Esta cola reduce el riesgo de desbordamientos en el socket TCP si el cliente no es capaz de retirar y procesar los mensajes a la suficiente velocidad.

164

165 8 Resultados del Método de Visualización Híbrida 8.1 Introducción Para demostrar la validez de nuestras ideas, hemos implementado un prototipo sobre el que hemos llevado a cabo un exhaustivo juego de experimentos. Estos experimentos cubren múltiples plataformas, conexiones inalámbricas y velocidades de desplazamiento del observador: desde el caminar humano hasta la velocidad de un avión a reacción. Este prototipo lleva a cabo la descarga de datos a través de redes inalámbricas de bajo ancho de banda, tal y como GPRS (2G) y UMTS (3G). En nuestra implementación hemos utilizado las técnicas de visualización, uso de impostores, optimización de la base de datos, etc. descritas en los Capítulos 6 y 7. El prototipo es capaz de proporcionar una navegación fluida sobre grandes terrenos en dispositivos móviles. Los resultados mostrados en este capítulo demuestran que nuestra técnica es factible, efectiva y robusta. La Figura 8.1 muestra una imagen real generada por el prototipo. 8.2 Las Plataformas Empleadas De acuerdo con el estudio preliminar realizado en la Sección A.2, hemos seleccionado el teléfono móvil Nokia N95 como nuestro principal dispositivo de pruebas. Este teléfono está equipado por una CPU OMAP 242 a 332 MHz (basada en ARM11), con 165

166 166 Resultados del Método de Visualización Híbrida Figura 8.1.: Descarga y visualización del conjunto de datos Puget Sound en un Nokia N95 a 31 animaciones por segundo. SE emplean 1212 triángulos y una conexión inalámbrica UMTS. 128 MB de memoria y una GPU PowerVR MBX que soporta OpenGL ES v1.1. Nuestra implementación también ha sido probada en un teléfono móvil iphone 3GS, dotado de una CPU ARM Cortex A8 a 6 MHz, 256 MB de memoria y una GPU PowerVR SGX que soporta OpenGL ES v1.1 y v2.. Los resultados muestran que el iphone 3GS duplica aproximadamente la tasa de animaciones por segundo proporcionada por el Nokia N95. Aparte de eso, el rendimiento general, número de triángulos visualizados y uso de la red fue casi idéntico en ambos teléfonos móviles. Adicionalmente, los experimentos también se realizaron en un ordenador personal de escritorio dotado de una CPU Intel Core-2 Duo a 2.4 GHz, 4 GB de memoria y una GPU NVIDIA GeForce 88 GTS. Un equipo adicional de iguales prestaciones interpretó el rol de servidor. El tamaño de la ventana en el Nokia N95 fue de píxeles, en el iphone 3GS, y en el PC fue de píxeles.

167 Resultados del Método de Visualización Híbrida El Terreno Empleado El conjunto de datos empleado fue el terreno Puget Sound 1. Está constituido por muestras de altitud con una resolución horizontal de 1m y vertical de.1m. Cada muestra está codificada como un valor entero de dos bytes. La textura consta de píxeles, con una resolución de 1m por píxel. Durante la etapa de pre-procesamiento, el terreno se dividió en una rejilla regular de bloques con valores de altura cada uno. Entonces, cada bloque se organizó como un quad-tree de ocho niveles. Cada nodo del quad-tree almacenaba un vector de 9 9 valores de altura. Esto es, n = 1 y n = 3 según se definieron dichos parámetros en la Sección Los nodos de los primeros cinco niveles de cada quad-tree también contenían una textura de píxeles. La resolución del terreno es constante a lo largo de toda su extensión. Por tanto, y de acuerdo con la Ecuación 6.3, la parte del modelo a visualizar no influye en el proceso de visualización, en tanto y en cuanto el parámetro C y la distancia desde el terreno hasta el observador permanezca constante. Para visualizar el terreno se han empleado dos niveles diferentes de complejidad geométrica. El nivel denominado calidad estándar se caracteriza por un parámetro de calidad C = 3 en la Ecuación 6.3, y por una profundidad máxima de los quadtrees de 5. El nivel calidad alta, en cambio, emplea un parámetro de calidad C = 9 y la totalidad de los ocho niveles disponibles en los quadtrees. Dado el pequeño tamaño de la pantalla de los móviles, la calidad estándar ofrece un buen nivel de detalle para un dispositivo móvil. Véase la Figura 8.2. Para la imagen de la izquierda se emplearon 5883 triángulos, mientras que la de la derecha consta de 5339 triángulos. Pese a que el número de triángulos difiere un orden de magnitud entre ambas imágenes, las diferencias visuales en la calidad de las mismas son difíciles de señalar. Dada su elevada complejidad geométrica, el nivel de calidad alto resulta más adecuado para PCs de escritorio. No obstante, y dado que deseamos estudiar el comportamiento de los dispositivos móviles bajo condiciones de elevado estrés, también hemos ejecutado los experimentos de calidad alta en ambos teléfonos. 1 Puget Sound se ha convertido en un conjunto de datos estándar para evaluar métodos de visualización de terrenos. Fue utilizado por primera vez por Peter Lindstrom en [LP1]. A fecha de Enero de 211, el terreno se encuentra disponible para su descarga en models/ps.html.

168 168 Resultados del Método de Visualización Híbrida (a) (b) Figura 8.2.: Puget Sound visualizado en un Nokia N95. a) 5883 triángulos. b) 5339 triángulos. 8.4 Evaluación del Lado del Cliente Para evaluar y validar nuestros métodos, hemos llevado a cabo un exhaustivo conjunto de experimentos en el lado del cliente. En esta sección realizamos un detallado estudio del rendimiento del cliente, así como una comparación entre el rendimiento de nuestro método de visualización híbrido y el método de visualización en el lado del cliente El Vuelo Para cada experimento se realizó un sobrevuelo del terreno. En cada vuelo se siguió una trayectoria rectilínea a lo largo de la diagonal del modelo. Para evitar falsear los resultados, nunca se alcanzaron las fronteras del terreno. El observador siempre se desplaza hacia adelante a una velocidad constante y a una altitud constante de 1m sobre el terreno. Para permitir una descarga inicial y parcial de datos, hemos introducido una espera de 15 segundos entre que se establece la conexión y el observador comienza el vuelo. Resulta claro que incrementar la velocidad del observador también incrementará el estrés sufrido tanto por la arquitectura de descarga como por la red. Afirmamos que nuestra arquitectura es capaz de hacer frente a diferentes velocidades del observador sin pro-

169 Resultados del Método de Visualización Híbrida 169 ducir variaciones significativas en la calidad de la escena visualizada. Para demostrar esta afirmación, hemos ejecutado tres conjuntos de vuelos a tres velocidades de navegación distintas: bicicleta (25 km/h), coche (15 km/h) y jet (75 km/h) La Red Empleada Para estudiar cómo nuestra técnica se comporta con redes inalámbricas reales, hemos ejecutado todos nuestros experimentos empleando dos populares tecnologías de telecomunicaciones: UMTS (3G) y GPRS (2G). UMTS proporciona un mayor ancho de banda que GPRS. No obstante, en líneas generales la cobertura de UMTS se encuentra limitada a áreas densamente pobladas, mientras que GPRS es la única red disponible en zonas poco pobladas Los Experimentos Todos los experimentos se ejecutaron con y sin panoramas. Esto es, se ha aplicado tanto nuestra técnica de visualización híbrida como la técnica de visualización en el lado del cliente. En ambos casos, la distancia mínima de visualización fue de 3 Km. Los panoramas, en aquellos experimentos que los empleaban, se situaron a una distancia de 7.5 Km del observador. El error máximo permitido para los mismos fue del 5%, y la resolución fue de píxeles por cada cara del cubo. Durante cada experimento se tomaron una serie de mediciones a lo largo de la trayectoria. Las Tablas 8.1 y 8.2 resumen los resultados promedio obtenidos por la plataforma Nokia N95. Las Tablas 8.1 y 8.2 resumen los resultados promedio para la plataforma iphone 3GS. Finalmente, las Tablas 8.5 y 8.6 resumen los resultados promedio obtenidos por el PC con la GPU NVIDIA GeForce 88GTS. Para cada nivel de calidad, las tablas incluyen el tipo de red usada, la velocidad del observador, el número de imágenes por segundo visualizadas, el número de triángulos dibujados en cada imagen y el total de datos descargados en kb durante los 3 segundos del vuelo. Todos los resultados están promediados.

170 17 Resultados del Método de Visualización Híbrida Calidad Alta Calidad Estándar Red Velocidad Imágenes Triángulos Descargas Imágenes Triángulos Descargas Bicicleta UMTS Coche Jet Bicicleta GPRS Coche Jet Tabla 8.1.: Resultados promediados obtenidos por el Nokia N95 durante los vuelos de 3 segundos empleando nuestro método de visualización híbrido. Calidad Alta Calidad Estándar Red Velocidad Imágenes Triángulos Descargas Imágenes Triángulos Descargas Bicicleta UMTS Coche Jet Bicicleta GPRS Coche Jet Tabla 8.2.: Resultados promediados obtenidos por el Nokia N95 durante los vuelos de 3 segundos empleando un método de visualización en el lado del cliente. Calidad Alta Calidad Estándar Red Velocidad Imágenes Triángulos Descargas Imágenes Triángulos Descargas Bicicleta 21, , UMTS Coche 21, , Jet 21, , Bicicleta 28, , GPRS Coche 31, , Jet 59, , Tabla 8.3.: Resultados promediados obtenidos por el iphone 3GS durante los vuelos de 3 segundos empleando nuestro método de visualización híbrido.

171 Resultados del Método de Visualización Híbrida 171 Calidad Alta Calidad Estándar Red Velocidad Imágenes Triángulos Descargas Imágenes Triángulos Descargas Bicicleta 14, , UMTS Coche 13, , Jet 13, , Bicicleta 24, , GPRS Coche 28, , Jet 48, , Tabla 8.4.: Resultados promediados obtenidos por el iphone 3GS durante los vuelos de 3 segundos empleando un método de visualización en el lado del cliente. Calidad Alta Calidad Estándar Red Velocidad Imágenes Triángulos Descargas Imágenes Triángulos Descargas Bicicleta UMTS Coche Jet Bicicleta GPRS Coche Jet Tabla 8.5.: Resultados promediados obtenidos por el PC con GPU NVIDIA GeForce 88 GTS durante los vuelos de 3 segundos empleando nuestro método de visualización híbrido. Calidad Alta Calidad Estándar Red Velocidad Imágenes Triángulos Descargas Imágenes Triángulos Descargas Bicicleta UMTS Coche Jet Bicicleta GPRS Coche Jet Tabla 8.6.: Resultados promediados obtenidos por el PC con GPU NVIDIA GeForce 88 GTS durante los vuelos de 3 segundos empleando un método de visualización en el lado del cliente.

172 172 Resultados del Método de Visualización Híbrida FPS Hybrid FPS Client FPS Hybrid Triangles Client Triangles Triangles KiloBytes Hybrid Download Client Download Time (seconds) Figura 8.3.: Métodos de visualización híbrido vs. basado en el cliente. Conexión UMTS (3G). Calidad de terreno alta. Arriba: imágenes por segundo y número de triángulos visualizados. Abajo: datos transferidos. 5 FPS Hybrid FPS Client FPS Hybrid Triangles Client Triangles Triangles 4 4 KiloBytes Hybrid Download Client Download Time (seconds) Figura 8.4.: Métodos de visualización híbrido vs. basado en el cliente. Conexión UMTS (3G). Calidad de terreno estándar. Arriba: imágenes por segundo y número de triángulos visualizados. Abajo: datos transferidos.

173 Resultados del Método de Visualización Híbrida 173 FPS Hybrid FPS Client FPS Hybrid Triangles Client Triangles Triangles KiloBytes Hybrid Download Client Download Time (seconds) Figura 8.5.: Métodos de visualización híbrido vs. basado en el cliente. Conexión GPRS (2G). Calidad de terreno alta. Arriba: imágenes por segundo y número de triángulos visualizados. Abajo: datos transferidos. 5 FPS Hybrid FPS Client FPS Hybrid Triangles Client Triangles Triangles 4 4 KiloBytes Hybrid Download Client Download Time (seconds) Figura 8.6.: Métodos de visualización híbrido vs. basado en el cliente. Conexión GPRS (2G). Calidad de terreno estándar. Arriba: imágenes por segundo y número de triángulos visualizados. Abajo: datos transferidos.

174 174 Resultados del Método de Visualización Híbrida Las Figuras 8.3, 8.4, 8.5 y 8.6 muestran el rendimiento a lo largo del tiempo de la técnica híbrida y la basada en el cliente para los experimentos realizados en la plataforma Nokia N95 a velocidad de coche (15 km/h) y calidad alta del terreno. Las curvas de la gráfica superior muestran la evolución a lo largo del tiempo de la tasa de imágenes por segundo y el número total de triángulos visualizados en cada imagen por las dos técnicas de visualización. Las curvas de la gráfica inferior muestran la evolución a lo largo del tiempo del total de datos descargados en kilobytes. En el Apéndice B se encontra un exhaustivo conjunto de gráficas que abarca todos los experimentos incluidos en las Tablas 8.1, 8.2, 8.1, 8.2, 8.5, y Rendimiento Nuestro método, en general, consigue mantener una tasa de animaciones por segundo y un número de triángulos visualizados casi constantes durante la mayoría de los vuelos. Si consideramos por separado los valores de las Tablas vemos que, como era de esperar, la calidad de visualización alta es consistentemente más exigente que la calidad estándar. Las Tablas muestran que el iphone 3GS consigue casi duplicar la tasa de animaciones por segundo del Nokia N95. Cuando se aplica la técnica híbrida en ambos dispositivos móviles, red UMTS y calidad alta, ver Tablas 8.1 y 8.3, la media de imágenes por segundo permanece entre en el Nokia N95 y 21 en el iphone. El número de triángulos visualizados en promedio por cada marco de animación oscila entre 3 y 42 en ambos dispositivos, lo que excede ampliamente las necesidades de unas pantallas de ese tamaño. En los experimentos de calidad estándar, el método híbrido visualiza de media unos 5 triángulos a 49 imágenes por segundo en el Nokia N95 y a 6 en el iphone. Este hecho ilustra que nuestro enfoque permite que los dispositivos móviles estudiados puedan visualizar fácilmente terrenos con buena calidad en relación con el tamaño de las pantallas. Ver Figura 8.2a. En el instante en el que el cliente establece la conexión con el servidor, la escena está vacía y no contiene ningún triángulo. Definimos el tiempo de carga inicial como el espacio de tiempo requerido por el sistema desde que se inicia la conexión cliente-servidor hasta que el número de triángulos dibujados por el cliente en cada marco de animación se estabiliza en torno a un número que depende de la calidad de representación del terreno requerida.

175 Resultados del Método de Visualización Híbrida 175 Las gráficas superiores en las Figuras 8.3, 8.4, 8.5 y 8.6 muestran dos comportamientos distintos. Al comienzo de cada experimento, existe un tiempo de carga inicial en el que tanto el número de triángulos visualizados como la tasa de imágenes por segundo cambian rápidamente hasta converger. Ello se debe a que el sistema está descargando la escena inicial. A partir de ese punto, las curvas permanecen casi constantes tanto para la conexión UMTS como para la GPRS. Esta estabilidad demuestra que la calidad de la escena visualizada se mantiene estable a lo largo del recorrido sin diferencias significativas. Como se esperaba, la plataforma PC de escritorio se comporta uniformemente mejor que los dispositivos móviles. El mayor número de triángulos visualizados por el PC es una consecuencia directa del mayor tamaño de la pantalla del ordenador Uso de la Red En esta sección discutimos el efecto sobre nuestra arquitectura de la velocidad del observador y de la red empleada. A lo largo de la discusión, los datos transferidos incluyen geometría, texturas y panoramas. Los resultados empíricos mostrados en las Tablas 8.1, 8.2, 8.3, 8.4, 8.5 y 8.6 revelan que, como esperábamos, incrementar la velocidad del observador incrementa de manera consistente el tráfico de datos en la red. El escenario menos exigente es la velocidad de bicicleta. En este caso, una vez la escena inicial ha sido completamente descargada, los cambios en la escena se producen muy lentamente. En los 3 segundos que dura cada vuelo, el observador no se aleja en demasía del área inicial. Por tanto, las descargas son poco considerables y no suponen ninguna dificultad para nuestra arquitectura. En el otro extremo tenemos a la velocidad de jet, que representa el escenario más exigente debido a que es necesario mantener una tasa de descarga de terreno y panoramas muy elevada para poder mantener la escena correctamente actualizada. Analizaremos a continuación el rendimiento de nuestro sistema con las redes UMTS y GPRS por separado Red UMTS De entre todos los experimentos realizados con la red UMTS y el dispositivo Nokia N95, el escenario más exigente se produjo para la visualización de alta calidad a velocidad jet, ver Tablas 8.1 y 8.2. Durante este experimento, el método de visualización en el lado del cliente descargó 6489 kilobytes. Para el método híbrido, la descarga fue de 616 kb. Dado que cada experimento dura 3 segundos, la relación de datos descargados por unidad de tiempo fue, en promedio, de kb/s y de 2.53 kb/s respectivamente. Ambas

176 176 Resultados del Método de Visualización Híbrida cifras son inferiores a los 48 kb/s que podemos esperar de la implementación más lenta de UMTS que existe. Las curvas en las Figuras 8.3 y 8.4 muestran que el tiempo de carga inicial cuando nos desplazamos a velocidad de automóvil y empleamos la red UMTS es de unos 1-15 segundos. Durante este tiempo, las curvas de descarga de datos presentan una pendiente muy elevada. Esto sugiere que la arquitectura está aprovechando todo el ancho de banda proporcionado por la red para ajustar rápidamente la calidad al nivel deseado. Una vez la carga inicial termina, la pendiente se suaviza drásticamente. Esto indica que tan solo se precisa una pequeña fracción del ancho de banda proporcionado por UMTS para mantener una navegación fluida y estable. Estos bajos requerimientos se deben a la naturaleza progresiva del método de visualización. Tan solo una pequeña cantidad de nodos de terreno necesitan ser refinados simultáneamente Red GPRS En nuestra experimentación, determinamos empíricamente que la máxima tasa de descarga de datos proporcionada por GPRS apenas ascendía a 5.5 kb/s. Esta cifra es claramente inferior al ancho de banda necesario para conseguir una navegación fluida con calidad del terreno alta. No obstante, y pese a estas condiciones tan desfavorables, la Tabla 8.1 muestra que nuestro método híbrido fue capaz de proporcionar una escena de triángulos de media al desplazarnos a velocidad de automóvil (15 km/h). A esta velocidad, el número de triángulos también converge a un valor determinado en función de la calidad del terreno, ver Figuras 8.5 y 8.6. Se necesitan alrededor de 8-12 segundos para los experimentos con calidad alta, y unos 4-5 para los de calidad baja. Por tanto, el tiempo de carga inicial de GPRS es superior al de UMTS. Dado que a velocidad de jet es preciso descargar un mayor volumen de datos, los experimentos a esta velocidad se ven más afectados por el escaso ancho de banda y la alta latencia de GPRS. En estas condiciones, la red GPRS era incapaz de hacer frente al número de peticiones realizadas, lo que provoca que la aplicación redujera el número de triángulos visualizados para evitar congestionar la red. Es más, la mayoría de los datos recibidos eran descartados rápidamente dado que el observador los dejaba atrás. No obstante, aún bajo estas condiciones tan extremas, nuestra arquitectura consiguió mantener una escena de 25 triángulos a 58 imágenes por segundo en el Nokia N95, ver Tabla 8.1. Esta cifra es suficiente para proporcionar al usuario una aproximación decente del terreno en la pantalla del teléfono.

177 Resultados del Método de Visualización Híbrida 177 1% 9% 8% 3G High Quality 3G Standard Quality 2G High Quality 2G Standard Quality 1% 9% 8% Ratio panorama / terrain 7% 6% 5% 4% 3% 2% 1% 7% 6% 5% 4% 3% 2% 1% % % Time (seconds) Figura 8.7.: Método de visualización híbrido Relación panorama/terreno en la transferencia de datos a velocidad de coche en el Nokia N Relación Descargas Panorama/Terreno En nuestro estudio también hemos analizado el ratio panorama/terreno en la transmisión de datos. La Figura 8.7 muestra esta relación a lo largo del tiempo para los vuelos a velocidad de coche en el Nokia N95. Los datos de terreno incluyen geometría y texturas. La gráfica muestra que al principio de cada experimento se producen bruscas oscilaciones en las curvas. Pero, pasado un tiempo, las curvas se estabilizan y convergen a un determinado valor. Este valor depende de la calidad del terreno requerida (alta o estándar). La razón de este comportamiento es la siguiente. Cuando el experimento comienza, se descarga inmediatamente el primer panorama. Esto provoca un pico en el ratio panorama/terreno. La subsiguiente caída de la curva se debe a los 15 segundos de espera que hemos introducido en los experimentos antes de que el observador comience a desplazarse, ver Sección Durante este tiempo, el cliente descarga toda la geometría del terreno visible, pero no precisa descargar ningún nuevo panorama. Superado este tiempo, el observador comienza a desplazarse. Durante el desplazamiento, la descarga de datos de panorama y de terreno se produce de forma regular. Por tanto, la curva se incrementa nuevamente hasta alcanzar un valor constante, en torno al cual se estabiliza. Nótese que en los experimentos de calidad estándar, y a excepción el periodo de carga inicial, el porcentaje de datos descargados correspondientes a panoramas fue del 3%. Por tanto, el 7% restante correspondió a datos del terreno. Sin embargo, en los experimentos de calidad alta, tan solo el 1% de los datos descargados correspondieron a panoramas. Esta diferencia se debe a que el tamaño de los panoramas no depende de la complejidad geométrica con la que se represente el terreno. Por tanto, incrementar la calidad del terreno reduce la importancia relativa de la descarga de datos de panoramas, y

178 178 Resultados del Método de Visualización Híbrida viceversa. De la Figura 8.7 también se desprende la conclusión de que el ratio terreno/panorama no depende del tipo de red empleada Estrategia Híbrida Frente a Basada en el Cliente En esta sección comparamos el método de visualización híbrido frente al método estándar de visualización en lado del cliente. En ambos enfoques hemos empleado nuestra misma arquitectura de descarga y de visualización de terrenos Comparación en Rendimiento Al comparar entre sí el número de animaciones por segundo de las Figuras 8.3 y 8.4 para la red UMTS (3G), y las Figuras 8.5 y 8.6 para la red GPRS (2G), podemos ver que, como era de esperar, la visualización de alta calidad es consistentemente más exigente que la de calidad estándar. Si analizamos cada gráfica de forma independiente, e ignoramos el tiempo de carga inicial, podemos apreciar que el número de triángulos visualizados por el método híbrido es siempre inferior al requerido por el método en el lado del cliente. La reducción oscila entre el 3% y el 4%. En consecuencia, la tasa de imágenes por segundo proporcionada por el método híbrido es siempre superior, con incrementos entre el 3% y el 45%. Por tanto, nuestros experimentos avalan la hipótesis de que la navegación resulta más fluida al emplear visualización híbrida que al delegar toda la carga gráfica en el cliente. Si comparamos entre sí los valores de las Tablas 8.1 y 8.2, las Tablas 8.3 y 8.4 y en las Tablas 8.5 y 8.6, podemos ver que estas conclusiones también se extienden a las distintas velocidades de navegación y a todas las plataformas consideradas en nuestros experimentos. Cuando visualizamos escenas de alta calidad empleando la conexión GPRS, la reducción en el número de triángulos es inferior. Esto se debe a que el pequeño ancho de banda de GPRS limita el número de triángulos que pueden descargarse desde el servidor durante el vuelo Comparación en Uso de Red Las Tablas muestran que el uso de los panoramas también afecta a los requerimientos de ancho de banda. Es preciso señalar que los experimentos con GPRS no resultan ilustrativos para comparar las dos técnicas entre sí, dado que los valores de datos descargados que se muestran en las Tablas están acotados por el limitado ancho de banda. Por tanto, en nuestra discusión nos referiremos a los resultados obtenidos por la red UMTS.

179 Resultados del Método de Visualización Híbrida 179 La cantidad total de datos descargados durante los experimentos de calidad estándar por el método híbrido es superior a los descargados por el método en el lado del cliente, excepto cuando nos desplazamos a velocidad de bicicleta. La razón de este comportamiento es la siguiente. Por un lado, el ancho de banda necesario para transmitir un panorama no depende de la complejidad geométrica del terreno. Por otro lado, la densidad de triángulos del terreno lejano es pequeña. Por tanto, resulta más económico (en términos de consumo de red) descargar la geometría en lugar del panorama. En cambio, la situación se invierte para los experimentos de calidad alta. Aquí, la cantidad de datos descargados por el método híbrido es siempre menor que los descargados por el método en el lado del cliente. Es decir, si aumentamos la calidad del terreno, resulta más económico descargar impostores panorámicos que descargar la geometría real. Estos resultados evidencian que el ahorro en las descargas ofrecido por nuestra técnica híbrida escala muy bien frente a la complejidad geométrica del terreno. 8.5 Evaluación en el Lado del Servidor Una vez evaluado el rendimiento en la lado del cliente, en esta Sección nos centraremos en estudiar el rendimiento en el lado del servidor. Evaluaremos nuestra solución en base a dos requerimientos que debe de ser capaz de proporcionar cualquier arquitectura multi-cliente orientada a la navegación en entornos virtuales: rendimiento del servidor y escalabilidad. Como se afirmó en la Sección 7.1, la arquitectura propuesta no precisa hardware potente ni costoso en el lado del servidor. Para demostrarlo, hemos evaluado nuestra aplicación servidora en un PC de escritorio ordinario, que ya fue descrito en la Sección 8.2. En nuestros experimentos, el Servidor Principal y el Servidor de Panoramas se ejecutaron en el mismo ordenador. Es importante señalar que el servidor empleado en nuestros experimentos dispone de un disco duro convencional S-ATA. Idóneamente, sería preferible emplear un servidor base de datos dedicado, dado que estos equipos poseen discos duros más rápidos y con memorias intermedias más amplias Rendimiento del Servidor Para medir el rendimiento del módulo Servidor de Panoramas dentro de nuestra arquitectura (descrito en la Sección 7.4), hemos efectuado un experimento consistente en conectar un cliente al servidor y realizar un vuelo a altura constante de 1m sobre

180 18 Resultados del Método de Visualización Híbrida Resolución Calidad Tiempo Tiempo Tiempo Tamaño Panorama JPEG Síntesis (s) Copia (s) Compresión (s) Panorama (kb) Tabla 8.7.: Duración en segundos para las distintas etapas de la generación de un panorama. Se muestran valores experimentales para diferentes resoluciones del panorama y calidad de compresión JPEG. el terreno. De esta forma se generaron 1 panoramas desde diferentes posiciones. Para evitar falsear los resultados, el cliente nunca se aproximó a las fronteras del terreno. La Tabla 8.7 muestra los resultados promediados obtenidos por el Servidor de Panoramas. De izquierda a derecha, la Tabla muestra la resolución del panorama (definida como la resolución de cada una de las caras del cubo), el factor de compresión JPEG, el tiempo empleado para sintetizar todas las imágenes del panorama, el tiempo empleado en copiar las imágenes resultantes desde memoria de la GPU a memoria de la CPU, el tiempo empleado en comprimir un panorama completo en formato JPEG, y finalmente, el tamaño en kb del panorama ya comprimido. El análisis de los valores en la Tabla 8.7 nos permite identificar los puntos fuertes del Servidor de Panoramas, así como los potenciales cuellos de botella. Como se esperaba, al incrementar la resolución del panorama se incrementa la duración temporal de todas las etapas del proceso de generación de panoramas. En cambio, el factor de compresión JPEG no parece influir en el tiempo de procesamiento, tan solo afecta al tamaño del panorama resultante. El Tiempo de Compresión es siempre significativamente mayor que los Tiempos de Visualización y Copia. Esto sugiere que la fase de compresión es la tarea más costosa del proceso de generación de panoramas. Las diferencias de agrandan al aumentar la resolución del panorama. Por contra, la etapa de visualización es la que requiere menor tiempo de cómputo. Estos resultados avalan la estrategia de equipar a nuestra arquitectura con múltiples módulos Compresores de Panoramas ejecutándose en paralelo. En nuestros experimentos, los Tiempos de Compresión están comprendidos entre.996s para el escenario de resolución y factor de compresión JPEG 6, y los.11528s segundos necesitados en el escenario de resolución con factor JPEG 8. Por tanto, el primer escenario permitiría una tasa de generación de panoramas de 1.4

181 Resultados del Método de Visualización Híbrida 181 panoramas por segundo, mientras que el segundo escenario permitiría generar 8.67 panoramas por segundo. Estos números nos permiten aproximar el tope máximo de clientes por segundo a los que podemos servir panoramas si el sistema solo incluye una instancia del módulo Compresor de Panoramas. Para mejorar el rendimiento de la etapa de compresión JPEG de los panoramas necesitaríamos incrementar la capacidad de cómputo de la máquina donde se ejecuta el Servidor de Panoramas. Esto podría lograrse mediante la adición de más núcleos de procesamiento o mediante el uso de algún tipo de implementación hardware para la compresión JPEG. Actualmente usamos la librería Libjpeg, que realiza la compresion JPEG por software Escalabilidad Para estudiar la escalabilidad de nuestro sistema, hemos sometido a nuestro servidor a una prueba de carga consistente en repetir el mismo experimento con un número de clientes concurrentes cada vez mayor. En cada experimento, los clientes establecían una conexión con el servidor y descargaban la escena inicial. Terminada esta descarga, todos los clientes comenzaban simultáneamente un vuelo que consistía en seguir una trayectoria rectilínea a velocidad y altitud constante. La altitud era de 2m sobre el terreno. Los clientes se inicializaban en posiciones aleatorias distribuidas sobre todo el terreno. La dirección y velocidad de navegación también eran valores aleatorios e independientes para cada cliente. La velocidad estaba comprendida entre 1 y 15km/h. La duración de cada experimento fue de 3 segundos. Ningún cliente alcanzó nunca las fronteras del terreno. En todos los experimentos, la distancia mínima de visión era de 3km. Los panoramas se situaron a 7.5km del observador. Hemos empleado el criterio de actualización de panoramas descrito en la Sección 6.7 con un error máximo del 5%. La calidad del compresión JPEG de los panoramas fue de 6. Para simular una elevada cantidad de clientes móviles hemos empleado un clúster de hasta 32 PCs, en donde cada ordenador ejecutaba 8 instancias de la aplicación cliente. La Figura 8.8 muestra algunas imágenes del clúster empleado durante nuestra experimentación. Cada instancia del cliente visualizaba de forma local aproximadamente 1 triángulos por marco de animación. Nótese que, desde el punto de vista del servidor, no hay ninguna diferencia práctica entre un cliente móvil real y uno simulado en un PC. Para cada experimento, hemos tomado un conjunto de medidas tanto en el servidor como en los clientes. Las siguientes secciones discuten los resultados obtenidos.

182 182 Resultados del Me todo de Visualizacio n Hı brida (a) (b) Figura 8.8.: Clu ster de ordenadores empleado durante nuestro estudio de escalabilidad. a) Imagen general de los 32 ordenadores que componen el clu ster. b) Detalle de algunos ordenadores ejecutando un experimento. Cada uno simulaba 8 clientes mo viles.