Visualización de Terrenos con Tarjetas de Video ...materias.fi.uba.ar/7500/Guaycochea.pdf · tarjetas de video o GPU que responden ... En las últimas dos décadas las aplicaciones

Visualización de Terrenos con Tarjetas de Video

Programables GPU

TESIS DE GRADO EN INGENIERÍA EN INFORMÁTICA

FACULTAD DE INGENIERÍA

UNIVERSIDAD DE BUENOS AIRES

TESISTA: Lucas Enrique Guaycochea DIRECTOR: Ing. Horacio Antonio Abbate

OCTUBRE 2011

UNIVERSIDAD DE BUENOS AIRES Visualización de Terrenos FACULTAD DE INGENIERÍA Tesis de Grado con Tarjetas de Video INGENIERÍA EN INFORMÁTICA Programables GPU

I

Resumen

La visualización de terrenos es un tema importante y popular en el área de la computación gráfica. El problema que se presenta es lograr una visualización en tiempo real de terrenos extensos aptos para aplicaciones interactivas como simuladores de vuelo. El interés reside en administrar eficientemente la gran cantidad de datos utilizados para modelar la superficie de un terreno extenso y detallado.

Este trabajo presenta una solución que parte de representar el terreno utilizando distintas resoluciones para diferentes regiones del mismo. La resolución o nivel de detalle a utilizar en cada región se administra de manera dinámica en tiempo de ejecución.

Es motivo de interés del trabajo estudiar las propiedades y características de los hardware gráficos actuales. Se evalúan las novedades introducidas por las tarjetas de video o GPU que responden al modelo Shader Model 4.0. El análisis de este hardware gráfico es necesario ya que la implementación de parte de la solución en las unidades programables de las tarjetas permite obtener mejores resultados.

La solución presentada consiste en el diseño y la implementación de una técnica simple, que obtiene como resultado una visualización precisa con un buen rendimiento. La técnica propuesta está basada en la técnica Geometry Clipmaps que pertenece al estado del arte del tema. Además, la misma brinda una visualización donde el error de aproximación, producto de utilizar resoluciones menores a la máxima disponible, que es percibido por el usuario se encuentra acotado a un valor umbral que se considera despreciable.

Por último, la implementación aprovecha el poder de procesamiento de las GPU modernas utilizando la librería gráfica Direct3D 10. Los resultados obtenidos permiten la navegación en tiempo real de grandes extensiones de terreno, consumiendo poco procesamiento de CPU.

Abstract

Terrain visualization is an important and popular aspect in the computer graphics area. The problem involved consists in achieving a real-time visualization of large terrains in order to develop interactive applications such as flight simulators. The key point is to efficiently manage the great amount of data that is used to model large and detailed terrain surfaces.

This work presents a solution where the terrain is represented using several resolutions in different regions of its surface. The resolution or level of detail used to represent each region is dynamically managed in runtime.

This thesis is also focused on the study of current graphics hardware properties and capabilities. The novel characteristics introduced in the GPUs that support Shader Model 4.0 are analyzed. This analysis is necessary in order to implement part of the solution using the graphics processing units available in the GPUs so as to obtain better results.

The solution that is presented consists in the design and implementation of a simple terrain rendering technique that achieves a precise visualization with a good performance. The technique introduced is based on Geometry Clipmaps that belongs to the state-of-the-art. Moreover, our technique achieves an error-bounded visualization. That means that the perception of the approximation error, introduced by the use of different levels of detail, is bounded.

Finally, the implementation takes advantage of modern GPU processing power using Direct3D 10 graphics library. The results obtained allow a real-time

navigation over large terrain extensions, consuming little CPU processing time.


III

Agradecimientos

Este trabajo marca la culminación de mi carrera de grado, permitiéndome recibir el título de ingeniero en informática. Deseo agradecer a muchas personas por el apoyo recibido en este trabajo, durante la carrera y en la vida misma.

A Mónica y Enrique, mis padres, por brindarme todo lo que he necesitado en la vida y hacer posible mi educación como persona, incluida mi formación profesional.

A Emilia, que ha estado a mi lado los últimos 7 años, siempre dando su apoyo, amor y compañía.

A Horacio, director de esta tesis, por sus consejos, dedicación y presencia durante el desarrollo de este trabajo. Además, por posibilitarme un lugar de trabajo en un gran grupo dedicado a un área apasionante como la computación gráfica.

A mis compañeros y amigos de la facultad, por su compañía, amistad y cooperación durante cada asignatura cursada. Asimismo, a los profesores de la facultad por su dedicación por la enseñanza.

A mis amigos, familiares y compañeros de trabajo, por su apoyo brindado en los distintos aspectos de la vida, y por brindarme su confianza y aliento para terminar este trabajo.

A todos ellos, muchas gracias!

Lucas. (Octubre 2011)


V

Índice

Resumen.............................................................................................I

Abstract ..............................................................................................I

Agradecimientos ............................................................................... III

Índice ................................................................................................V

1 Introducción................................................................................. 1

1.1 Visualización de Terrenos......................................................... 1

1.2 Objetivo de esta Tesis ............................................................. 3

2 Modelado de Terrenos ................................................................... 5

2.1 Uso de Mallas Regulares o Irregulares ....................................... 6

2.2 Formato de Archivos de Modelos de Terreno............................... 7

3 El Pipeline Gráfico ......................................................................... 9

3.1 Vértices y Primitivas .............................................................. 10

3.2 Transformaciones.................................................................. 11

3.3 Ensamblado, Recorte y Mapeo a Pantalla ................................. 12

3.4 Rasterización........................................................................ 13

4 Renderizado de Terrenos.............................................................. 15

5 Terrenos con Nivel de Detalle ....................................................... 19

5.1 Criterios para la Elección del Nivel de Detalle............................ 19

5.2 Simplificación vs. Refinamiento............................................... 23

5.3 Consecuencias del Uso de Nivel de Detalle ............................... 25

6 Primeros Trabajos en Nivel de Detalle............................................ 29

6.1 Real-Time, Continuous Level of Detail Rendering of Height Fields 29

6.2 ROAMing Terrain: Real-Time Optimally Adapting Meshes............ 31

6.3 Smooth View-Dependent Level-of-Detail Control and its Application to Terrain Rendering....................................................................... 33

7 Evolución del Hardware Gráfico: El Pipeline Gráfico Programable....... 37

7.1 Historia del Hardware Gráfico ................................................. 37

7.2 Interfaces de Programación 3D............................................... 41

7.3 Cambio en el Paradigma de Programación de Aplicaciones de Gráficos 3D. .................................................................................. 42

8 Programación de GPUs: Shader Model 4.0...................................... 45


VI

8.1 Nueva Versión del Pipeline Gráfico........................................... 45

8.2 Recursos y su Utilización ........................................................ 46

8.3 Configuración del Pipeline: Efectos .......................................... 48

8.4 Análisis de las Nuevas Características Introducidas.................... 48

9 Soluciones Modernas al Renderizado de Terrenos ............................ 53

9.1 Geometrical MipMapping ........................................................ 53

9.2 Geometry Clipmaps ............................................................... 56

9.3 Geometry Clipmaps en la GPU ................................................ 59

9.4 Trabajos Posteriores .............................................................. 60

10 Diseño de la Solución Propuesta................................................. 61

10.1 Motivaciones y Decisiones de Diseño .................................... 61

10.2 Representación del Terreno ................................................. 63

10.3 Análisis del Error Proyectado ............................................... 65

10.4 Algoritmo de Renderizado ................................................... 67

10.5 Resolución de Artefactos ..................................................... 69

10.6 Conclusiones ..................................................................... 71

11 Implementación de la Solución .................................................. 73

11.1 Análisis del Shader Model 4.0 y Direct3D 10 .......................... 73

11.2 Estructuras de Datos y Recursos Utilizados............................ 75

11.3 Implementación del Framework ........................................... 77 11.3.1 Descripción General del Framework............................................................77 11.3.2 Implementación de la Técnica de Renderizado de Terrenos TiledClipmaps.......83 11.3.3 El Efecto Utilizado ....................................................................................85 11.3.4 Algoritmos Auxiliares a la Solución.............................................................90

12 Resultados Obtenidos ............................................................... 93

13 Conclusiones ........................................................................... 97

13.1 Trabajos Futuros................................................................ 98

Referencias ...................................................................................... 99

Publicaciones .................................................................................. 101


Introducción 1

1 Introducción

En las últimas dos décadas las aplicaciones gráficas para la plataforma PC han tenido un crecimiento exponencial, impulsadas principalmente por la industria de videos juegos. Actualmente se han alcanzado resultados visuales que son casi indistinguibles de la realidad, como, por ejemplo, se puede observar en las últimas películas animadas. Sin embargo, los resultados logrados no implican que el crecimiento del área se haya detenido, sino que se sigue trabajando en mejorar distintos detalles para obtener aún más realismo. La rama de las ciencias de la computación que se centra en el estudio y la evolución de las aplicaciones gráficas es llamada computación gráfica. Esta área estudia la manera de generar imágenes o gráficos por computadora, siendo uno de sus principales objetivos la generación de imágenes o animaciones (sucesiones de imágenes) que se asemejen a fotos y videos de la vida real.

Dentro del área de la computación gráfica podemos diferenciar dos grandes ramas que se caracterizan por el tiempo disponible para generar las imágenes o animaciones. Por un lado, se encuentran aquellas aplicaciones donde el tiempo no es un limitante y, por ende, se puede invertir el tiempo necesario de procesamiento para generar las imágenes con el realismo deseado, como por ejemplo en la confección de películas animadas. Por otro lado, existen aquellas donde la visualización se debe realizar en tiempo real, como ocurre en videos juegos, en simuladores de entrenamiento y en aplicaciones interactivas con representación visual de escenarios virtuales o sintéticos. Estas aplicaciones requieren que cada cuadro este listo para mostrarse con la suficiente rapidez como para no afectar la ilusión de continuidad de movimiento en la animación, proveyendo así una adecuada experiencia de usuario interactiva.

El crecimiento de la calidad de las aplicaciones, mencionado en el comienzo, fue viabilizado por el avance de la tecnología. El progreso permitió un incremento en forma sostenida de las capacidades tanto de almacenamiento como de procesamiento.

En un principio, los sistemas capaces de generar buenas visualizaciones implicaban hardware especial y una gran inversión de dinero. Al igual que las computadoras, con el tiempo, estos sistemas con gran potencia gráfica se hicieron accesibles y, hoy en día, esas capacidades fueron introducidas en placas gráficas o tarjetas de video.

En la actualidad, las tarjetas de video permiten programar distintas partes de su procesamiento. Esta cualidad permite utilizarlas con distintos fines, implementando algoritmos que serán ejecutados por las unidades de procesamiento gráficas (GPUs) propias de la tarjeta.

1.1 Visualización de Terrenos

Un tema particularmente importante en computación gráfica es el relacionado con el modelado y la visualización de terrenos. Existen importantes campos de aplicación donde es necesario representar escenarios basados en terrenos, como ser: video juegos, cine de animación, simuladores de entrenamiento y sistemas de información geográfica, entre otros. Para visualizar terrenos muy amplios, con imágenes de alta calidad y en tiempo real es necesario enfrentar varios problemas característicos.


2 Introducción

Actualmente, para la representación de terrenos reales se dispone de la información de la altura de distintos puntos de la superficie terrestre con una granularidad que llega a un espaciamiento de decenas de metros entre puntos consecutivos. Un terreno puede entonces representarse como una malla de puntos ubicados en una escena tridimensional. Esto implica un enorme volumen de datos para un terreno de algunos cientos de kilómetros de lado, tamaño que es como mínimo necesario para aplicaciones como un simulador de vuelo. Esta gran cantidad de datos es aún un inconveniente para las capacidades de procesamiento de las tarjetas gráficas actuales si se desean resultados interactivos. La manera de modelar un terreno mediante un conjunto de puntos es abordado en el Capítulo 2.

El desafío en la visualización de terrenos consiste en representar fielmente los detalles del terreno, manteniendo la fluidez de generación de imágenes necesaria para brindar animaciones con continuidad visual. Esto implica encontrar un punto de compromiso entre la granularidad (cantidad de puntos y polígonos) con la que se va a modelar un terreno y la velocidad con la que puede procesarse esa cantidad de datos para generar imágenes con la fluidez deseada. En el Capítulo 3 se introduce el pipeline gráfico, la secuencia de tareas, comunes en computación gráfica, que se realizan para la generación de las imágenes a visualizar a partir de modelos tridimensionales.

Además del desafío mencionado en el párrafo anterior, la visualización o renderizado de terrenos presenta otros aspectos característicos que son analizados en el Capítulo 4. Luego, las soluciones que se han propuesto para resolver el desafío siguen una misma línea de trabajo. Esta consiste en representar el terreno utilizando distintos niveles de detalle en diferentes regiones del mismo, con el fin de disminuir la cantidad de datos (o geometría) a dibujar. Estas soluciones son conocidas como algoritmos o técnicas de nivel de detalle o, en inglés, level-of-detail (LOD). Las características comunes a estas soluciones son presentadas en el Capítulo 5.

En los últimos 15 años, se han publicado varios trabajos que proponen distintas soluciones. Durante la década del ’90, y hacia finales de la misma, se han publicado trabajos significativos en el tema que sentaron las bases de los trabajos posteriores y actuales. El Capítulo 6 se concentra en la descripción de los tres trabajos más importantes que introdujeron estrategias y técnicas que son utilizadas aún hoy en día.

Luego, con el comienzo de una nueva década, en el 2000, surge una revolución en el hardware gráfico, es decir, en las tarjetas de video. Sus capacidades de procesamiento comienzan a aumentar en forma exponencial y, además, incorporan la posibilidad de ejecutar programas específicos de una forma muy eficiente. En el Capítulo 7 se resume la evolución de este hardware que dio lugar a distintas generaciones de GPU, tarjetas gráficas o tarjetas de video. Luego en el Capítulo 8, se presentan en mayor detalle las características de la última generación de GPU, ya que en este trabajo se propone una solución que hace uso de las novedades introducidas para lograr una técnica de visualización de terrenos eficiente.

Dada la evolución experimentada por las GPU, las soluciones debieron modernizarse para aprovechar las capacidades que fueron incorporadas, ya que algunos de los esfuerzos realizados por las soluciones anteriores dejaron de ser necesarios. En el Capítulo 9 se presentan dos soluciones modernas que pertenecen al estado del arte en el área de visualización de


Introducción 3

terrenos. Las soluciones descriptas son populares dado a su eficiencia y relativa simpleza de implementación.

1.2 Objetivo de esta Tesis

Finalmente, el objetivo de esta tesis, tras haber presentado y analizado el tema de interés, es presentar una técnica que resuelva el problema de la visualización de grandes extensiones de terreno. El propósito es realizar el diseño de una técnica que provea buenos resultados visuales de calidad y sea eficiente en cuanto al procesamiento requerido. Además, el diseño busca tener en cuenta las capacidades de las GPUs actuales, para lograr una implementación eficiente.

La solución propuesta esta enmarcada en aplicaciones de simulación o video juegos, típicamente un simulador de vuelo. En este tipo de aplicaciones (simuladores) la calidad gráfica lograda en dirección a proveer representaciones fluidas y realistas es un factor fundamental.

En el Capítulo 10 se presenta el diseño de la técnica propuesta. La misma está basada, y toma aspectos, de las soluciones analizadas anteriormente. Luego, en el Capítulo 11 se muestran los detalles de la implementación de la técnica en un módulo de software, o framework, utilizado para mostrar la visualización de un terreno al desplazarse sobre el mismo.

Por último, el Capítulo 12 expone los resultados obtenidos y el Capítulo 13 consiste en las conclusiones del presente trabajo y las líneas de trabajo futuras.


Modelado de Terrenos 5

2 Modelado de Terrenos

La representación gráfica de ambientes tridimensionales comenzó a ser utilizada en los videojuegos. El objetivo era mostrar a los usuarios escenarios que parecieran reales para lograr la inmersión de los mismos en las situaciones representadas. En los comienzos, los escenarios representados eran interiores de edificaciones o callejones en ciudades, común en videojuegos del tipo first person shooter (FPS). Este tipo de escenarios, conocidos como indoors, no contaba con representaciones de terrenos. A lo sumo, podía visualizarse el exterior a través de una ventana del edificio que se recorre, y para ello se utilizaba una fotografía.

Limitaciones del hardware gráfico y de procesamiento, dificultaban el modelado tridimensional de un terreno. Algunas aplicaciones que utilizaban la representación de un ambiente en exteriores (ó outdoors), modelaban una pequeña porción de terreno, limitando el movimiento de los personajes a esa área y utilizando también fotografías para la representación de zonas alejadas y el horizonte.

El advenimiento de mayores capacidades en el hardware gráfico y de procesamiento en las computadoras, dio lugar a la búsqueda de soluciones para el modelado de grandes extensiones de terreno. Aplicaciones basadas en la navegación y visualización interactiva de terrenos se pudieron comenzar a desarrollar. Los simuladores de vuelo de entrenamiento fueron las primeras aplicaciones que impulsaron la generación de mecanismos para la visualización de terrenos extensos. Hoy en día, estos mecanismos han sido incorporados a un amplio espectro de aplicaciones que aprovechan esta capacidad, como por ejemplo, los sistemas de información geográfica.

Una porción de terreno puede modelarse en un espacio tridimensional como una malla de puntos. En otras palabras, puntos interconectados por segmentos de rectas pueden representar la superficie de un terreno natural. Cada punto posee una posición tridimensional en el espacio y esta conectado a dos o más puntos, de manera de formar un mallado cerrado.

Figura 2.1 – Malla de puntos en un espacio tridimensional.

Los ejes de referencia a utilizar en el espacio son elegidos arbitrariamente. En esta tesis, se tomarán ejes cartesianos de referencia



donde los ejes X e Y representan el plano horizontal del terreno, y la coordenada Z de cada punto, la altura del mismo respecto a una altura de referencia, por ejemplo, el nivel del mar. Además, se utilizará una terna de mano izquierda (Figura 2.1).

Luego, la superficie formada por la malla de puntos es texturada artificialmente o con imágenes satelitales de la región natural representada.

2.1 Uso de Mallas Regulares o Irregulares

Los puntos que conforman la superficie del terreno pueden considerarse como el muestreo de la altura del terreno en una posición de un plano horizontal. La posición tridimensional del punto, entonces, está formada por su ubicación en el plano horizontal, más la información de la altura del terreno en ese lugar.

De esta forma, la representación de un terreno puede verse también como una función inyectiva de dos variables, f(x,y) = z. Dadas las coordenadas (x,y) de un punto proyectado en el plano horizontal, se obtiene la altura z de ese punto para definir la superficie del terreno.

El problema de la representación de un terreno a través de una estructura de puntos ha sido abordado de dos maneras diferentes según la disposición geométrica de los puntos donde se muestrea la altura del terreno.

Una manera de modelar la superficie de un terreno es mediante la utilización de mallas irregulares, que en la bibliografía son conocidas con el nombre de “redes de triángulos irregulares” (o triangulated irregular Networks, TINs). El uso de estas mallas no impone restricciones en la conectividad de los puntos, ni en los lugares donde debe hacerse el muestreo de la altura del terreno.

La otra posibilidad es el uso de mallas regulares. Los puntos se encuentran regularmente esparcidos sobre la superficie del terreno. Esta regularidad permite que la conectividad entre los puntos quede implícita, en contraste al uso de TINs que requiere especificar la conectividad de los puntos de la malla. Esta característica implica que las coordenadas X e Y de cada punto pueden inferirse a partir de su ubicación en el conjunto de datos, por lo que esta alternativa reduce la cantidad de datos necesarios para el modelado de un terreno.

Figura 2.2 – A la izquierda un ejemplo de una malla irregular o TINs. A la derecha puede verse una malla regular.


Modelado de Terrenos 7

A partir de las diferencias estructurales de estas dos formas de representación de un terreno pueden inferirse otras comparaciones entre las mismas. Larsen y Christensen, en [Larsen03], enumeran algunas de las propiedades del uso de un mallado regular o, como también es conocido, campo de alturas (del inglés height field). Las tres propiedades que destacan los autores son consideras como ventajas sobre el uso de TINs y se enumeran a continuación:

• La estructura regular permite ordenar y disponer de las elevaciones en una estructura de datos simple como una matriz de dos dimensiones o, incluso, una imagen.

• La consulta sobre la elevación de un punto cualquiera en la superficie puede resolverse mediante un acceso directo a la estructura de datos. Computacionalmente, una consulta de primer orden u O(1). Dado este tipo de acceso, esta estructura de datos es conocida también como mapa de alturas (del inglés height map).

• Pueden discriminarse fácilmente regiones de terrenos contenidas en un volumen de interés en el espacio.

Por otro lado, el uso de mallas irregulares permite representar una superficie de un mismo terreno, usando menor cantidad de puntos y polígonos que un mallado regular. Zonas planas de terreno son representadas con menor densidad de puntos, mientras que aquellas regiones con mayores detalles, como montañas, ríos y costas, concentrarán mayor cantidad de muestras y pueden modelarse con mayor precisión.

Estas diferencias brevemente introducidas, entre otras, motivan la elección de una alternativa sobre la otra dependiendo de la disponibilidad de recursos y el enfoque de cada solución. Más adelante en este trabajo, en el Capítulo 6, se ejemplifican las motivaciones presentes en distintos trabajos, que los llevaron a adoptar una disposición geométrica y sus consecuentes características.

2.2 Formato de Archivos de Modelos de Terreno

La descripción de los puntos, que conforman el modelo de la superficie de un determinado terreno, puede encontrarse dispuesta en diferentes estructuras de datos. Para ser utilizados en aplicaciones de software, los datos son almacenados en archivos. Los modelos de los terrenos pueden corresponder a modelos artificiales o representar regiones reales de la superficie terrestre. Archivos que representan superficies reales, que son utilizados también para otro tipo de aplicaciones, son comúnmente distribuidos en la forma de grillas regulares.

Existen distintos formatos de archivos, binarios o de texto, que describen el modelo de una región de terreno. Los modelos que usan mallados irregulares requieren formatos de archivos más complejos. Como fue dicho, los mallados irregulares deben contener no sólo la posición 3D de cada punto, sino también la manera de conectarlos. De esta manera, para describirlos suelen utilizarse los mismos archivos que se utilizan para la descripción de cualquier objeto tridimensional. Son ejemplo de esto, los archivos de extensión “.x” que definen el mallado de objetos y son utilizados en distintas versiones de la librería gráfica Direct3D.



Los modelos basados en grillas regulares son los más compactos y usualmente utilizados y distribuidos, ya que sólo se necesita almacenar el valor de elevación o altura de cada punto. Los términos mayormente utilizado para nombrar estos archivos son “modelos digitales de elevación” (DEM, Digital Elevation Model) y “modelos digitales de terrenos” (DTM, Digital Terrain Model). DTM es un término más genérico ya que DEM es también utilizado para referirse a un formato particular de archivo.

Una de las maneras más sencilla de disponer los datos de elevación de un modelo regular, es almacenarlos en un archivo de imagen. Imágenes y modelos de elevación regulares coinciden en contener datos discretos organizados en una estructura 2D, como por ejemplo, en filas y columnas de una tabla o matriz. Las unidades discretas de las imágenes son los píxeles, y en los modelos de elevación de interés son los valores de altura de cada punto. Cabe destacar que los formatos de archivos de imágenes tienen un propósito distinto, permitiendo esquemas de compresión y resoluciones que pueden resultar insuficientes e inapropiados para los modelos de elevación. Sin embargo, dada la variedad de formatos de imágenes disponibles, hay algunos que pueden utilizarse adecuadamente para almacenar los modelos de elevación, complementados con parámetros que son distribuidos paralelamente. Los formatos de archivos más utilizados son PNG, JPEG y TIFF; todos ellos excluyendo el uso de compresión con pérdida.

Por otro lado, han surgido formatos de archivos específicos para almacenar modelos de elevación. Los mismos contienen un encabezado para definir parámetros necesarios en estos modelos, como la resolución del muestreo, el sistema de coordenadas de los datos o valores de referencia, y la resolución vertical, entre otros datos georeferenciales.

Los modelos de elevación pueden conseguirse de manera libre o con cargo en distintos sitios disponibles en la Web. En el sitio del Servicio Geológico de Estados Unidos (United States Geologic Survey, USGS) pueden conseguirse archivos en formato DEM o STDS (estándar de transferencia de datos espaciales, spatial data transfer standard) con resoluciones de hasta 10 o 30 metros entre los puntos muestreados de la superficie terrestre. El Departamento de Defensa de los Estados Unidos reporta tener archivos DTED (datos digitales de elevación de terrenos, digital terrain elevation data) con resoluciones de 30, 10, 3, y 1 metro entre los puntos; pero los mismos no se encuentran disponibles para usos civiles. Finalmente otros formatos de archivos que son utilizados para la descripción de modelos de terrenos son GeoTIFF, imágenes georeferenciales basadas en el formato de archivo de imágenes etiquetado (TIFF, tagged image file format); y BT (Binary Terrain), formato de archivo binario para la descripción de terrenos.


El Pipeline Gráfico 9

3 El Pipeline Gráfico

Para llevar a cabo una representación virtual de un ambiente tridimensional, se realiza un modelado del escenario. Dicho modelo incluye la representación geométrica de los objetos presentes, las condiciones de iluminación de la escena y el lugar dentro de la misma desde dónde es apreciada. Cada objeto es representado a través de combinaciones, más o menos complejas, de figuras geométricas, el color o las texturas de sus superficies, y su posición y orientación en la escena. Luego se configuran las condiciones de iluminación, es decir posición, color, tipo y demás atributos de cada fuente de luz presente en la escena. Por último, se determina la posición y dirección del punto de vista o de la cámara a través de la cual se visualiza el ambiente.

La visualización del ambiente en un dispositivo, como la pantalla de un monitor, es posible gracias a software y hardware especializado. Dicha especialización permite dibujar eficientemente sobre una pantalla bidimensional la proyección, comúnmente en perspectiva, de una escena tridimensional (Figura 3.1).

Figura 3.1 – A partir del modelado de una escena tridimensional (a) se obtiene una imagen o cuadro (b). En (a) se ve el modelado de la escena utilizando objetos y posicionando una cámara. Además, puede verse el volumen de visualización de la cámara. En (b) se muestra lo visualizado por la cámara: la escena proyectada (en perspectiva).

El conjunto de operaciones que se realiza para, a partir del modelado del escenario, lograr una imagen para dibujar en la pantalla es llamado pipeline gráfico. En computación gráfica, al proceso de generar una imagen bidimensional, para mostrarla en un dispositivo, se lo conoce como renderizar1 [Akenine-Möller et al. 2008].

La denominación pipeline hace referencia a que las operaciones se encuentran secuenciadas y que el conjunto de ellas puede verse como una línea de producción de una fábrica. Cada operación corresponde a una estación de trabajo. Cada estación, o etapa del pipeline, toma como entradas las salidas de la estación anterior, y produce salidas que sirven de entradas para la subsiguiente. Esta relación entre las operaciones permite cierto grado de paralelismo. Las estaciones pueden estar todas trabajando simultáneamente si el pipeline es correctamente alimentado; claro esta, cada etapa sobre un conjunto de datos diferente.

1 Renderizar es una castellanización del verbo en ingles “to render”, cuya traducción literal es traducir o interpretar. Puede considerarse que la acción consiste en traducir un modelo tridimensional a una imagen bidimensional.



La navegación interactiva de ambientes virtuales implica la necesidad de generar en el dispositivo de salida una secuencia de imágenes (también llamadas cuadros) que brinden una sensación de continuidad en el desplazamiento o movimiento. El pipeline gráfico debe renderizar cuadros con una velocidad de al menos 15 cuadros por segundo para que el ojo humano no note discontinuidades en la animación [Akenine-Möller et al. 2008].

El rendimiento del pipeline gráfico, o de aquellas aplicaciones que lo utilizan para la visualización de ambientes virtuales, es medido comúnmente a partir de la velocidad con la que se renderizan los cuadros. La medida con la que el rendimiento es expresado es la cantidad de cuadros por segundo o, en inglés, frames per second (fps). Las tarjetas gráficas que implementan las funcionalidades del pipeline gráfico junto con el software que las acompaña (los controladores o drivers) son fabricadas de manera genérica. De esta manera, las distintas etapas son optimizadas por los fabricantes por igual. Por lo tanto, el rendimiento es determinado por la manera en que la aplicación utiliza el pipeline gráfico. Finalmente, como el pipeline gráfico consiste en una secuencia de etapas que trabajan paralelamente, el rendimiento resultante está limitado por la etapa que requiere mayor tiempo de procesamiento, la cual es denominada “cuello de botella”.

En computación gráfica, para introducir los datos al pipeline gráfico se utilizan librerías gráficas que hacen uso de los distintos hardware gráficos y brindan una abstracción común del mismo. Las librerías gráficas más populares son DirectX y OpenGL, en sus diferentes versiones.

El pipeline gráfico puede modelarse de manera genérica en tres etapas (Figura 3.2). El pipeline recibe datos geométricos de los objetos de una escena y otros datos de configuración de la aplicación, y genera como salida una imagen que es mostrada en un dispositivo, como ser, un monitor.

Figura 3.2- El modelo genérico del pipeline gráfico.

A continuación, se expondrá una breve explicación de las operaciones que ocurren en un pipeline gráfico genérico y los datos que son ingresados y utilizados en cada etapa.

3.1 Vértices y Primitivas

Los objetos de la escena son modelados mediante una malla de triángulos. Las librerías gráficas permiten especificar para cada objeto los vértices de dichos triángulos y las conexiones entre ellos.

La información incluida en cada vértice puede variar dependiendo de la aplicación, pero comúnmente contiene:

• Su posición: las coordenadas tridimensionales de la ubicación de dicho vértice según un eje de referencia determinado en el modelo del propio objeto.



• La normal: la dirección del vector normal al mallado al que pertenece el vértice en esa posición. Es usada para calcular la incidencia de las distintas fuentes de luz y para determinar la cara frontal de los triángulos que define.

• El color: puede contener la información del color del vértice.

• Las coordenadas de textura: alternativamente al color, si el mismo debe ser tomado de una textura, las coordenadas para realizar el muestreo dentro de la textura correspondiente.

Además del conjunto de vértices que representarán un objeto, debe introducirse la información de cómo deben usarse los mismos para armar los triángulos u otras primitivas (puntos y líneas). Esta información es simplemente una secuencia de los índices de los vértices descriptos anteriormente.

3.2 Transformaciones

Las posiciones de los vértices que modelan cada objeto se referencian respecto a un sistema de coordenadas propio de cada objeto. Esto permite que el mismo modelo sirva para representar distintas instancias del objeto dentro de una escena.

Una primera etapa del pipeline consiste en transformar las coordenadas de los vértices en coordenadas normalizadas del dispositivo. Para esto a cada vértice se le aplica una secuencia de transformaciones utilizando matrices de dimensión 4x4 y coordenadas homogéneas (véase una buena explicación en el Apéndice G en [OpenGL 1997]). Las posiciones de los vértices son afectadas entonces por 3 transformaciones:

• Mundo: A partir de la posición, orientación y escala de la instancia del objeto en la escena, se arma una matriz que lleva las coordenadas de los vértices del sistema de referencia propio del objeto al sistema de referencia de la escena, común a todos los objetos.

• Vista: Para mostrar lo que es percibido desde un punto de vista, se aplica una matriz que hace coincidir la posición de la cámara con el origen de coordenadas. Además, se hace coincidir la dirección de la cámara con el eje Z positivo, quedando el eje Y hacia arriba y el eje X hacia la derecha. Así las posiciones de los vértices de los objetos quedan relativas a la ubicación y orientación de la cámara.

• Proyección: El espacio que es visualizado de la escena es definido por un volumen de visualización. Los objetos dentro de ese volumen son proyectados en la cara delantera de dicho volumen para obtener la imagen a mostrar. Utilizando una proyección perspectiva, el volumen de visualización tiene la forma de la parte inferior de una pirámide de base rectangular truncada, en inglés, frustum. Finalmente, la transformación de proyección convierte ese volumen de visualización en un volumen de visualización canónico, un cubo con sus vértices extremos en (-1, -1, -1) y (1, 1, 1).



En forma resumida, la Figura 3.3 muestra la secuencia de transformaciones aplicadas al modelo geométrico de un cubo. En un principio el cubo es modelado en coordenadas propias del objeto. Luego, aplicando distintas matrices de mundo, se ubican tres instancias del cubo dentro de una misma escena. Cada matriz del mundo aplica un conjunto distinto de operaciones de traslación, rotación y escalado. De esta manera se ubican los vértices del cubo en coordenadas del mundo. A continuación, a todos los objetos de la escena se les aplica la transformación de vista, para que las posiciones de sus vértices queden relativas a la ubicación de la cámara. El siguiente paso consta de aplicar a los objetos la matriz de proyección. La matriz de proyección es utilizada para definir el volumen de visualización o frustum, y como resultado se transforman los vértices a coordenadas canónicas. Finalmente, se visualizan aquellos objetos que quedan dentro del cubo canónico.

xy

z

xy

z

( 0 , 0 , 0 )obj( -3 , 10 , 5 )mundo

=

44434241

34333231

24232221

14131211

mmmm

mmmm

mmmm

mmmm

oMatrizMund i

cámara

=

44434241

34333231

24232221

14131211

vvvv

vvvv

vvvv

vvvv

aMatrizVist

x

zy

( 1 , 10 , -2 )vista

Coordenadas del Objeto Coordenadas en el mundo

Coordenadas relativas

a la cámara

volumen de

visualización

plano de

proyección

Coordenadas

canónicas

=

44434241

34333231

24232221

14131211

Pr

pppp

pppp

pppp

pppp

oyecciónMatrizvolumen canónico

( -1, -1, -1)

(1,1,1)

modelo del cubo

instancia 1

del cuboinstancia 2

del cubo

instancia 3

del cubo

Figura 3.3- Transformaciones que son aplicadas al modelo genérico de un cubo.

3.3 Ensamblado, Recorte y Mapeo a Pantalla

A continuación, los vértices transformados son ensamblados para formar las primitivas (puntos, líneas o triángulos) descriptas a partir de la



secuencia de índices. En esta etapa, las primitivas que quedan fuera del volumen canónico de visualización son descartadas del pipeline. Aquellas que se encuentran parcialmente dentro, son recortadas reemplazando los vértices que quedan fuera por vértices en las intersecciones de la primitiva con el cubo canónico (Figura 3.4).

Figura 3.4 – Operación de recorte.

Luego, las primitivas son mapeadas a coordenadas de pantalla a partir de la posición y dimensión de la ventana en la cual se visualizará la escena. El mapeo consiste de un escalado seguido de una traslación, afectando a las coordenadas X e Y (no afecta a la coordenada Z).

Las coordenadas de pantalla X e Y junto con las coordenada Z (valor de profundidad) son pasadas a la siguiente etapa de rasterización.

3.4 Rasterización

El objetivo de esta etapa es determinar el conjunto de píxeles que formarán parte de la imagen final a visualizar. Esta etapa usa un buffer bidimensional para la generación progresiva de la imagen o cuadro final, que es llamado frame-buffer. La primera operación consiste en determinar los pixeles necesarios para la representación de cada una de las primitivas a visualizar (Figura 3.5). El proceso, también conocido como escaneo de conversión (en inglés, scan conversion), genera una estructura transitoria llamada fragmento. Cada fragmento contiene los atributos ingresados con los vértices junto a la posición. El valor de los atributos es obtenido mediante una interpolación lineal de los valores presentes en cada vértice de la primitiva, utilizando como pesos la posición del fragmento relativa a los vértices.

Figura 3.5- Etapa de rasterización. Se obtienen los píxeles necesarios para representar las primitivas que quedan dentro del volumen canónico de visualización.



Dos o más primitivas pueden generar fragmentos en la misma posición. El fragmento que debe dibujarse es aquel que se encuentra más cercano al observador, es decir, aquel que no se encuentra tapado por otro. El valor de la coordenada Z, o valor de profundidad, es utilizado para dirimir el fragmento que se convertirá en píxel. Para esto se utiliza una estructura de datos llamada Z-buffer o buffer de profundidad (en inglés, depth buffer) que almacena el valor de profundidad del último fragmento dibujado en el frame-buffer. Un fragmento es descartado si su valor de profundidad es mayor al que se encuentra en el Z-buffer para la misma posición.

El color del fragmento candidato a convertirse en un píxel de la imagen final es decidido en esta etapa. El color puede obtenerse del atributo que acompaña a cada vértice o puede muestrearse de una textura en particular, a partir de las coordenadas de textura para ese fragmento. Más aún, operaciones de iluminación y transparencia pueden contribuir en el color final de un píxel.

Finalmente, los fragmentos dibujados en el frame-buffer son mostrados en la pantalla del dispositivo.


Renderizado de Terrenos 15

4 Renderizado de Terrenos

Como fue introducido anteriormente, aplicaciones que requieren la visualización y navegación de ambientes tridimensionales han ido evolucionando y demandando cada vez mayor realismo en los resultados gráficos producidos. La meta por alcanzar es la producción de visualizaciones de escenarios virtuales que sean difícilmente diferenciables de filmaciones del mundo real. Particularmente, el foco de interés de esta tesis reside en visualizaciones de escenarios naturales, donde el terreno es el objeto principal de los mismos.

Ulrich [Ulrich 2002] explica de manera simple las características de un renderizado ideal de un escenario virtual en un dispositivo. La aplicación debe producir resultados visualmente ricos e interesantes. Por ejemplo, debe permitir posicionar un observador libremente en el escenario y, desde ese punto de vista, apreciar los alrededores en perfecto detalle, desde aquellos árboles en las laderas de montañas lejanas en el horizonte, hasta las pequeñas rocas que se encuentran a los pies del observador. Además, debe permitir el control interactivo de dicho observador sin limitaciones a su movimiento en el escenario, manteniendo la percepción de los detalles tanto de sus alrededores inmediatos como de las vistas lejanas. Por último, no debe introducir artefactos (distorsiones o ruido localizado, que producen un efecto visual con un aspecto característico) que degraden la inmersión del usuario en ese mundo virtualmente representado, el usuario debe percibir en todo momento como si estuviera en el mundo real.

Como fue explicado en el capítulo anterior, se desarrollan aplicaciones que utilizan el pipeline gráfico para renderizar una escena. La escena esta compuesta por objetos que son modelados mediante mallas de vértices y otros atributos. El terreno también es representado utilizando una malla de vértices que modelan su superficie. Una primera aproximación al renderizado de escenas, y particularmente terrenos, es ingresar de manera completa la representación disponible del terreno en el pipeline, como si fuera cualquier otro objeto. Esta técnica para renderizar terrenos, al no realizar ningún procesamiento particular sobre el mismo, es conocida como fuerza bruta.

Las primeras tarjetas gráficas especializadas o GPUs (ver Capítulo 7) ofrecían la capacidad de renderizar miles de vértices manteniendo un rendimiento aceptable para aplicaciones interactivas, pero el modelado detallado de terrenos excedía esa capacidad. Utilizar una técnica de fuerza bruta limita el tamaño y los detalles de los modelos de terrenos soportados. De esta manera, cuando el punto de vista se encuentra próximo al terreno, la segmentación de las ondulaciones del modelo se hace evidente y, cuando se encuentra elevado, se perciben los límites del modelo (Figura 4.1).

Las aplicaciones que utilizaban fuerza bruta como técnica para el renderizado de terrenos, debían encontrar soluciones para mantener el realismo. Por ejemplo, podían restringir el movimiento de la cámara u observador en la escena y de esta manera modelar el terreno estratégicamente de manera tal de aumentar el detalle en las zonas cercanas. Otra solución utilizada consistía en representar efectos para ocultar las regiones lejanas del terreno, por ejemplo utilizando niebla. En consecuencia, este enfoque restringe las aplicaciones que podían desarrollarse, dejando afuera por ejemplo a simuladores de vuelo.



Figura 4.1 – Un terreno de 16km x 16km modelado con un mallado regular de 1024 x 1024 vértices. (a) Imagen donde el observador se encuentra cercano al terreno; pueden observarse las aristas de los polígonos. (b) Imagen donde el observador se encuentra elevado sobre la superficie; pueden verse los límites del modelo del terreno.

El problema de brindar visualizaciones ricas en detalle de mayores extensiones de terreno seguía vigente. Dado las capacidades de procesamiento del hardware y el realismo idealmente deseado para las representaciones, las soluciones deben buscar el punto de compromiso que conjuguen una performance y una calidad visual adecuada.

Una técnica usualmente utilizada en computación gráfica consiste en no introducir dentro del pipeline gráfico geometría de objetos de la escena que no contribuyan a la imagen final. Aquellos objetos que no se encuentren incluidos en lo que es visualizado por la cámara consumen tiempo de procesamiento para sus vértices que resultarán descartados dentro del pipeline en el proceso de recorte. Por lo tanto, en tiempo de ejecución, es útil que el programa realice un testeo para descartar de manera temprana a aquellos objetos que con certeza1 no contribuyen a la imagen final. Este testeo que se realiza utilizando el volumen de visualización o frustum, buscando seleccionar aquellos objetos para descartar, es llamado frustum-culling2 (Figura 4.2).

La técnica de frustum-culling por ende permite optimizar la utilización de los recursos disponibles. Un terreno raramente se encontrará fuera del volumen visualizado por completo. Sin embargo, el terreno puede dividirse en porciones que son testeadas individualmente para decidir si serán introducidas dentro del pipeline.

Por otro lado, también puede aprovecharse, para incrementar la performance, la manera en que la percepción de detalles varía según la distancia de los objetos, a partir de la visualización en perspectiva. Dada la naturaleza de la visión humana, la misma cubre un amplio rango de detalle geométrico [Ulrich 2002]. La vista puede resolver detalles de tamaño pequeño en objetos cercanos, mientras que apenas puede distinguir un pico de varios metros en una montaña dentro de una cordillera lejana.

1 El testeo no necesariamente implica cálculos rigurosos para decidir si el objeto se encuentra dentro del volumen visualizado. Contrariamente, suele constituir un cálculo rápido y burdo, significando poco procesamiento. 2 Frustum en inglés se refiere a la pirámide truncada que refiere a la forma del volumen de lo visualizado por una cámara utilizando una proyección en perspectiva. Cull en inglés significa seleccionar o sacrificar de manera selectiva.


Renderizado de Terrenos 17

Figura 4.2 – La técnica de frustum-culling permite no introducir en el pipeline gráfico la geometría de la tetera, el cono y el cubo.

Este hecho, surgido de la visualización en perspectiva, también es utilizado en computación gráfica, en ambientes donde los objetos pueden encontrarse en un amplio rango de distancias, para evitar introducir en el pipeline gráfico geometría que modela detalles que no contribuirán a la imagen final. De esta manera, una estrategia común es tener un mismo objeto modelado en distintos niveles de detalle a ser utilizados según la distancia que se encuentre de la cámara (Figura 4.3). En tiempo de ejecución, calculada la distancia del objeto a la cámara, se elige el modelo con el cual se representará el objeto. Sin embargo, esta estrategia no es válida para los terrenos.

Figura 4.3 – La clásica “tetera” o teapot usada en computación gráfica modelada en distintos niveles de detalle.



Dada la naturaleza de los terrenos, una superficie de gran extensión, la cámara se encontrará cercana a ciertas regiones y lejana a otras. Por ende, es necesario encontrar técnicas que permitan modelar distintas regiones de terreno con distinto detalle. De esta manera, se podrá mejorar el rendimiento de las aplicaciones, sin perder calidad visual y aumentando la superficie de terreno que puede modelarse y visualizarse. Estas técnicas son conocidas en la bibliografía como técnicas de nivel de detalle. La utilización de las técnicas de nivel de detalle aplicadas a la visualización de terrenos es motivo de análisis del siguiente capítulo.


Terrenos con Nivel de Detalle 19

5 Terrenos con Nivel de Detalle

La incorporación de la visualización de mayores extensiones de terreno de mayor calidad en distintas aplicaciones, es posible a partir del ajuste de la resolución en distintas regiones del modelo del terreno. La estrategia consiste en representar zonas con mayor o menor resolución a partir de la percepción posible de sus detalles. Recapitulando las propiedades de la visión en perspectiva, zonas cercanas al observador requerirán mayor resolución que aquellas zonas más alejadas. Asimismo, regiones con accidentes geográficos más pronunciados serán representados con mayor resolución respecto de regiones de la superficie del terreno llanas o de leves ondulaciones.

La idea o estrategia presentada, entonces, da lugar a las técnicas de nivel de detalle (en inglés level-of-detail, abrevieándose LOD). Para el caso de la visualización de terrenos, se desarrollaron técnicas para manejar el nivel de detalle o resolución con el cual se representarán las distintas regiones del modelo de la superficie. Esta elección de los niveles de detalle a utilizar debe realizarse de manera dinámica en tiempo de ejecución, es decir, cuadro por cuadro. La resolución elegida varía a partir de, por ejemplo, la posición del observador o cámara, entre otros criterios (Figura 5.1).

Figura 5.1 – Un mismo terreno representado con mallas con diferente nivel de detalle. El nivel de detalle de distintas regiones varía según la posición del observador.

A continuación, en este capítulo, se explicarán los distintos aspectos involucrados en las técnicas de nivel de detalle. Los aspectos referidos son los criterios para elegir el nivel de detalle adecuado, la estrategia de los algoritmos y los inconvenientes a resolver cuando se utilizan estas técnicas.

5.1 Criterios para la Elección del Nivel de Detalle

Dentro de la vasta bibliografía en el tema, los trabajos publicados muestran que la elección del nivel de detalle a utilizar puede depender de distintos parámetros. El criterio utilizado puede involucrar cálculos sencillos y de baja precisión, como también algoritmos más precisos y complejos. Los criterios más precisos utilizan como entrada mayor cantidad de parámetros. Asimismo, dentro de la bibliografía también puede encontrarse cómo los distintos criterios pueden combinarse. A continuación se desarrollarán tres de los criterios más utilizados.



� Distancia al observador:

La manera más sencilla de elegir el nivel de detalle es utilizando la distancia al observador. Por ejemplo, si un terreno es dividido en regiones cuadradas de n x n vértices, la misma podrá ser representada con menor

cantidad de vértices: 2n x 2

n , 4n x 4

n , etc. (Figura 5.2). A partir de la

distancia del observador al centro de cada región, usualmente proyectada al plano XY, se elige el nivel de detalle con el cual debe ser representada. En otras palabras, a partir de la distancia al observador se elige la cantidad de puntos con la que la superficie de cada región del terreno es modelada.

Figura 5.2 – Una misma región de terreno representada en distintas resoluciones.

� Error de modelado:

Un criterio más preciso considera la rugosidad del terreno. El criterio anterior, utilizando sólo la distancia al observador, concibe representaciones de los terrenos ignorando las características particulares del mismo. Ese criterio no considera si cada región representa una superficie llana, con pocos detalles o de baja frecuencia, o si, por el contrario, modela una porción de terreno con accidentes geográficos más pronunciados, con mayores detalles o detalles de alta frecuencia. Por lo tanto, este criterio más preciso tiene en cuenta, no sólo la distancia al observador, sino también, las características de la superficie de cada región.

Si un mismo terreno, o región del mismo, es modelado con distinta cantidad de puntos, existe una diferencia entre las superficies resultantes. Si una de las superficies es tomada de referencia, se dice que las diferencias encontradas por una representación alternativa constituyen un error geométrico o de modelado. Este error geométrico o de modelado puede encontrarse en coordenadas del objeto, o tras su correspondiente transformación del mundo, en coordenadas del mundo.

Particularmente, analizamos el caso donde una porción de terreno es representada con menor resolución a partir de un sub-muestreo de los vértices utilizados en una representación de mayor resolución o mayor densidad de vértices. La altura de un punto de la superficie coincidente con un vértice omitido en una representación de menor detalle, cambiará y será resultado de una combinación o interpolación de las alturas de los vértices presentes. La diferencia de alturas (valor de la coordenada z) para el mismo punto en los modelados de distinto detalle constituye el error de modelado para ese punto (Figura 5.3).



Figura 5.3 – Error geométrico o de modelado. Vista desde el costado del error en la altura producido al omitir el vértice blanco en un bloque de menor detalle, su posición imaginaria quedará en el segmento que une los vértices negros. El cambio en la altura y error de modelado es h.

El error geométrico o de modelado puede calcularse de manera relativa, entre representaciones de niveles de detalle sucesivos, o de manera absoluta, tomando siempre como referencia el modelado de mayor resolución que contiene todos los vértices disponibles.

Por ejemplo, un criterio que tiene en cuenta el error de modelado presentado junto con la distancia al observador, posee valores máximos para los errores de modelado aceptables según distintos rangos de distancias. Los errores máximos admisibles aumentan con la distancia. Finalmente, el nivel de detalle seleccionado para cada región involucrará un error de representación por debajo del valor umbral establecido para la distancia al observador en la que se encuentre.

� Error percibido o proyectado

Hasta el momento, los criterios enumerados no tienen en cuenta el mecanismo de la visión humana. La manera de obtener modelos de terrenos simples y de la mayor calidad visual posible es utilizar un criterio que aproveche las características de la transformación de proyección perspectiva.

Los triángulos que representan la superficie del terreno en un modelo tridimensional, tras ser procesadas en el pipeline gráfico, son proyectados en la pantalla. El proceso de rasterizado definirá el conjunto de píxeles para dibujar en la pantalla cada triángulo. De esta manera se puede analizar si los detalles de un modelo son perceptibles por el usuario.

El criterio, entonces, consiste en evaluar el tamaño en píxeles de la proyección del error geométrico o de modelado introducido anteriormente. El modelado de una zona del terreno con un determinado nivel de detalle u otro, tiene por consecuencia errores geométricos. Por lo tanto, el criterio de elección pasa por evaluar la proyección del error de modelado, medida en unidades del espacio de pantalla, y decidir si el mismo es aceptable o no.

Por defecto, si el tamaño del error proyectado en pantalla es menor a un píxel, el mismo no será apreciable y el nivel de detalle en cuestión es aceptable. Sin embargo, es común que las aplicaciones o soluciones de visualizaciones y renderizado de terrenos permitan elegir un valor máximo de píxeles para que un error se considere despreciable. Al establecer un valor máximo o umbral, si la proyección del error de modelado no excede dicho valor, entonces el nivel de detalle que se quiere utilizar es aceptable.

Este criterio es el más preciso de los vistos, e involucra a los anteriores. Utiliza el error de modelado y necesita la distancia de dicho error a la posición del observador, para realizar el cálculo de la proyección y mapeo a la pantalla.



Π

f

γ

h

w

Figura 5.4 – Volumen de Visualización.

Finalmente, el cálculo de la proyección es explicado a continuación. El volumen de visualización o view-frustum, utilizando una proyección en perspectiva, es definido a partir de: (i) el campo de visión horizontal γ (en grados), que refiere a la amplitud visual del observador o del lente de la cámara; (ii) el tamaño de la ventana de visualización, ancho screenw y alto

screenh (en píxeles); (iii) la distancia n al centro del plano de proyección Π

(en unidades del mundo); y (iv) la mayor distancia de lo visualizado o distancia f al plano trasero del volumen de visualización (en unidades del mundo)(Figura 5.4). Entonces, a partir de los parámetros de visualización, se quiere calcular la proyección x en el plano Π de un segmento de longitud s que se encuentra en el mundo a una distancia d del observador. De manera conservadora, se asume que el segmento a proyectar tiene una orientación ortogonal a la dirección de observación. Por semejanza de triángulos (Figura 5.5), se obtiene (1). Por ende, el resultado obtenido de x se encuentra en unidades del mundo.

d

snx

n

x

d

sworld

world =⇒= (1)

Si se quiere obtener la cantidad de píxeles que representarán la proyección x del segmento s, debemos calcular el tamaño de la ventana de visualización en coordenadas del mundo, ancho worldw y alto worldh (2).

=

=⇒

=

=

aspect

wh

nw

h

waspect

n

w

tgworld

world

world

scren

screen

world

)2tan(22)2(γγ

(2)



Asumiendo que la proyección x se encuentra en el centro del plano Π , se calcula el tamaño relativo de dicha proyección en la ventana de visualización y luego se transforma en pixeles, obteniendo screenx en píxeles.

Se calculan, entonces, dos casos, screenhx asumiendo que el segmento se

encuentra horizontal, y screenvx asumiendo que el segmento se encuentra

vertical (3).

screenscreenhscreenworld

worldscreenh w

d

sxw

w

xx

)2tan(2 γ=⇒=

screenscreenvscreenworld

worldscreenv h

d

aspectsxh

h

xx

)2tan(2

.γ=⇒=

(3)

Por último, el error de modelado es proyectado en la pantalla, de manera conservadora, utilizando el procedimiento y las ecuaciones explicadas. El método conservador asume que el error de modelado se representa con un segmento ortogonal a la dirección de observación y en posición vertical en el centro de la ventana de visualización.

Π

sx

Figura 5.5 – Semejanza de triángulos para el cálculo de la proyección de un segmento sobre el plano de visualización.

5.2 Simplificación vs. Refinamiento

La representación de un terreno con nivel de detalle implica reducir la complejidad del modelo sin perder calidad visual. El objetivo es obtener una representación más simple manteniendo la misma apreciación del terreno. En el procedimiento de obtener un mallado más simple, la motivación puede estar dada por: (i) mantener cantidad de primitivas o vértices a utilizar por debajo de un valor establecido; (ii) mantener el error de representación menor a un valor umbral que se considere aceptable; y por último, (iii) una combinación de las anteriores. Independientemente de la motivación utilizada, las soluciones pueden utilizar estrategias diferentes. Las técnicas de nivel de detalle pueden estar concebidas a partir de dos estrategias diametralmente opuestas.

Una primera estrategia consiste en comenzar por un modelo simplificado del terreno, un modelo burdo o de baja resolución, y luego aplicar operaciones de refinamiento hasta alcanzar una representación del terreno con un nivel de detalle aceptable, según la motivación y el criterio de elección utilizado. Esta estrategia, que parte de un modelo de poca



resolución llegar a una representación de mayor detalle, es llamada de refinamiento o, en inglés, top-down.

Refinamiento o top-down

Simplificación o bottom-up

Figura 5.6 – Simplificación vs. Refinamiento. Una misma región de terreno es representada con mayor o menor detalle.

Por el contrario, otra estrategia utilizada es aquella que comienza por la representación del terreno en su máxima resolución y, tras ejecutar varias operaciones de simplificación, obtiene un mallado del terreno más simple, con el nivel de detalle suficiente que satisface la motivación y el criterio de elección usado. Esta estrategia es llamada de simplificación o, en inglés, bottom-up (ver Figura 5.6).

Las nociones de arriba y abajo (top and bottom) surgen de imaginar un terreno y sus regiones en una estructura de árbol, donde la raíz de la estructura contiene un modelo simplificado del terreno. El terreno modelado en la raíz es dividido en n regiones representadas en un mayor detalle en n nodos hijos de la raíz. Sucesivamente, se subdivide cada región en regiones más pequeñas y de mayor detalle, hasta alcanzar una profundidad donde el conjunto de los nodos hoja del árbol constituyen el modelo del terreno en su máxima resolución (ver Figura 5.7). Si se imagina el árbol con el nodo raíz en la parte superior y las ramificaciones hacia abajo, las estrategias toman su nombre a partir de la manera en que los nodos del árbol son recorridos. En la simplificación, se parte desde abajo, desde los nodos hojas y se procede simplificando y subiendo en la jerarquía de nodos (bottom-up). En cambio, en el proceso de refinamiento, se parte desde la raíz, desde arriba, y se refina el mallado bajando por los nodos del árbol (top-down).

Los algoritmos o técnicas de nivel de detalle, aplican estas estrategias cuadro por cuadro para decidir la resolución con la cual será representado el terreno, según los criterios utilizados. Generalmente, la estrategia de refinamiento produce resultados más precisos, logrando la mínima cantidad de vértices para la calidad deseada. Sin embargo, esta estrategia suele demandar mayor disponibilidad de recursos, tanto de procesamiento como de memoria. Por otro lado, la estrategia de simplificación es más simple y sencilla de implementar, demandando menor cantidad de recursos, aunque produzca mallados con mayor cantidad de vértices que el mínimo posible.

Finalmente, también existen técnicas que usan estrategias híbridas, que mantienen un nivel detalle para el terreno y, cuadro por cuadro, de manera incremental, proceden con operaciones de refinamiento y/o simplificación según sea necesario en diferentes regiones del terreno.



Figura 5.7 – Estructura de árbol utilizada para manejar el nivel de detalle en la representación de terrenos. La raíz contiene el modelo completo del terreno en una baja resolución. Los nodos hoja contienen regiones del terreno con la máxima resolución disponible. Utilizando todos los nodos hojas se obtiene el terreno con la máxima resolución.

5.3 Consecuencias del Uso de Nivel de Detalle

El uso de estas técnicas de nivel de detalle introduce efectos no deseados o artefactos apreciables en la visualización de los terrenos. Los terrenos representados con estas técnicas pueden presentar en ocasiones discontinuidades espaciales y temporales. La representación de regiones adyacentes con distintos niveles de detalle puede dar lugar a la aparición de cracks (o grietas) en la superficie de terreno (Figura 5.8). Por otro lado, la elección dinámica del nivel de detalle a utilizar, por ejemplo en una misma región, puede ocasionar que los cambios de geometría sean perceptibles por el usuario.

La discontinuidad espacial ocurre cuando triángulos adyacentes pertenecen a distintos niveles de detalle. Las grietas aparecen en los bordes de las regiones representadas con distinto nivel de detalle, ocasionados por aquellos vértices que se encuentran presentes en el nivel de detalle mayor, y ausentes en el otro (Figura 5.9). Estos vértices son llamados vértice-T, ya que el mismo se encuentra interconectado con una conexión en T (T-junction). Generalmente, la aparición de un crack es ocasionada porque la altura del vértice-T no coincide con la altura con el cual es representada esa posición en el nivel de menor detalle, producto de la interpolación de los vértices presentes en este último.



Figura 5.8 – Grietas que aparecen en el terreno al utilizar distintos niveles de detalle.

Figura 5.9 - Conexión en T sobre el vértice en negro (marcada en rojo), que está en el borde de dos bloques vecinos con niveles de de detalle diferentes. A la izquierda se observa una vista superior 2D del mallado. A la derecha se observa el agujero que se produce en la superficie por la falta de conexión del vértice T en el bloque de menor resolución.

Por otro lado, otro artefacto, que produce un efecto similar a cracks en el terreno, es también originado por los vértices-T. En el caso en el que la altura interpolada coincida con la altura original del vértice, también pueden observarse pequeños agujeros o cracks en la superficie del terreno. Estos agujeros son originados por diferencias de redondeo de punto flotante producidos entre las operaciones del pipeline gráfico. En la bibliografía, el efecto es llamado bleeding tears (lágrimas de sangre) [Luebke et al. 2003].

Temporalmente, también pueden apreciarse discontinuidades. El artefacto es llamado “popping” (del verbo inglés to pop, saltar). El mismo se refiere a la percepción de saltos ó pops en la superficie del terreno, es decir, un cambio brusco y repentino en la geometría del terreno. Esto ocurre



cuando hay un cambio en el nivel de detalle utilizado para la representación de una misma zona de terreno a medida que el observador se desplaza cuadro por cuadro.

Finalmente, el cambio de nivel de detalle de una región de un cuadro a otro, también puede producir efectos apreciables en el sombreado del terreno, dado que con la geometría también cambian las normales de las primitivas que son usadas en los cálculos de iluminación convencionales.


Primeros Trabajos en Nivel de Detalle 29

6 Primeros Trabajos en Nivel de Detalle

Ya se han descripto, en primer lugar, la problemática de la visualización de terrenos y, luego, las características representativas de las soluciones basadas en nivel de detalle. Este capítulo, entonces, estará dedicado a tres trabajos publicados en el tema, que son considerados fundacionales.

Entre mediados y fines de los ’90, han surgido varias publicaciones acerca del renderizado de terrenos. Las capacidades de las tarjetas gráficas permitían ya renderizar algunos millones de triángulos por segundo. Entonces, fue viable desarrollar soluciones para resolver el renderizado de terrenos en tiempo real utilizando técnicas de nivel de detalle. En este período, las soluciones se caracterizan por tener como objetivo común minimizar la cantidad de vértices a utilizar en cada cuadro, y a la vez obtener una alta calidad en las imágenes producidas.

Dentro de las varias publicaciones, se destacan: Lindstrom et al. [Lindstrom et al. 1996], Duchaineau et al. [Duchaineau et al. 1997] y Hoppe [Hoppe 1998]. Las soluciones y estrategias descriptas en estos trabajos han servido de fuente y base para muchos otros. Además, dado los resultados obtenidos, esos trabajos dieron lugar a implementaciones presentes en varios sistemas reales y motores de juegos [Luebke et al. 2003]. A continuación, se exponen las características principales de los tres trabajos, en el orden cronológico en el que fueron publicados.

6.1 Real-Time, Continuous Level of Detail Rendering of Height Fields

En 1996, Lindstrom et al. publicaron el trabajo titulado “Real-Time, Continuous Level of Detail Rendering of Height Fields” [Lindstrom et al. 1996]. Los autores presentan una solución representando el terreno a través de una malla regular y utilizando, como criterio de elección del nivel de detalle a utilizar, un valor umbral para la proyección del error en pantalla, definido por el usuario. La estrategia es bottom-up y consiste en dos pasos: un primer paso de simplificación a nivel de bloques y, luego, una mayor simplificación vértice por vértice. Por último, provee un nivel de detalle sin discontinuidades espaciales y, según sus autores, un mallado cercano al óptimo.

El trabajo utiliza un mallado regular para el modelado del terreno. Los autores fundamentan que si bien el uso de mallas irregulares o TINs minimiza la cantidad de vértices, el cálculo de distintos niveles de detalle es computacionalmente muy costoso y, por ende, su uso dinámico, prohibitivo. Más aún, consultas comunes en aplicaciones como los juegos, son de difícil resolución. La falta de organización espacial dificulta consultas como la detección de colisiones con el terreno, o la definición de una trayectoria para un objeto que se desplaza sobre la superficie. Por otro lado, como fue introducido en el Capitulo 2, las mallas regulares permiten una representación más compacta, eficiente y, también, facilita la obtención de distintos niveles de detalle a partir de un simple submuestreo de los vértices.

Una de las principales contribuciones del trabajo, es la utilización de un valor para acotar el error de aproximación tolerable. La elección por parte



del usuario de un valor umbral para el tamaño máximo de un error proyectado, permite mostrar una clara relación directa entre un parámetro de entrada del método y la calidad de las imágenes obtenidas. Anteriores trabajos que presentan algoritmos de nivel de detalle, no reconocen la necesidad de proveer una solución que tenga un error acotado en la imagen renderizada. Más aún, no se asociaba la selección de las resoluciones a utilizar con el error perceptible en la pantalla.

Recapitulando el uso de mallas regulares, los autores representan el terreno mediante una grilla regular de vértices con intervalos de muestreo discretos resx e resy . Se utilizan bloques cuadrados de tamaño fijo de 12 +n

vértices de lado. Sin embargo, la extensión espacial de los bloques varía, ya que están compuestos por vértices muestreados en múltiples resoluciones que son potencia de dos. De esta manera, el área que cubre un bloque será de res

nm x+2 x resnm y+2 , donde m es un entero no negativo.

La estrategia de simplificación consiste en la combinación de triángulos de manera recursiva. Inicialmente todo el terreno se encuentra en su máxima resolución. En ciertas condiciones un par triángulo/cotriángulo son reducidos a un sólo triángulo, y el triángulo resultante, junto con su cotriángulo son considerados para fusionarse recursivamente. Por ejemplo, dado el par de triángulos ABD y BCD, que comparten el lado BD, ambos pueden combinarse en un solo triángulo ABC (Figura 6.1). La diferencia entre las dos representaciones, es la diferencia de la altura del vértice D y el valor resultante de la interpolación de las alturas de B y C:

)2

(CB

Dabs+−=ε . Si la proyección del error de modelado ε no excede el

valor umbral seleccionado, entonces la simplificación puede concretarse.

A C

D

B

ε

Figura 6.1 – Triángulos ABD y BCD se combinan formando ABC. El error de modelado ε surge de la omisión del vértice D.

Este procedimiento realizado para todos los vértices puede resultar computacionalmente muy costoso. Por lo tanto, los autores deciden realizar la simplificación en dos pasos: el primero basado en los bloques, y el segundo basado individualmente en cada vértice.

El primer procedimiento de simplificación consiste de una estimación conservadora que se realiza sobre el conjunto de vértices presentes en un bloque. Se obtiene el máximo error de modelado para la representación del bloque en un determinado nivel de detalle. Entonces, sólo ese valor máximo se proyecta en el plano de visualización y se compara con el valor umbral. De esta manera se selecciona eficazmente un nivel de detalle mínimo para el bloque.

Luego, se decide la triangulación óptima para cada bloque haciendo un análisis vértice por vértice. Se analiza la omisión de los vértices que permiten la combinación de dos triángulos adyacentes. Entonces, como fue explicado, si el error de representación, al proyectarse, no excede el umbral



fijado, el vértice puede omitirse, los triángulos fusionarse, y el proceso se repite recursivamente mientras el error no exceda el umbral.

Por último, la fusión de un par de triángulos puede ocasionar vértices T, que ocurre en el par de triángulos que comparte el vértice omitido en el primero. La aparición de vértices T da lugar a grietas en la superficie del terreno, para evitarlo los autores administran dependencias entre pares de triángulos y vértices. Para ello utilizan un grafo acíclico que codifica las dependencias presentes entre los vértices, de manera tal que al decidir la omisión o presencia de un vértice, la misma se propaga con el fin de evitar las grietas.

6.2 ROAMing Terrain: Real-Time Optimally Adapting Meshes

Duchaineau et al. [Duchaineau et al 1997] publicaron en 1997, una técnica de nivel de detalle muy popular que fue bautizada como ROAM. El algoritmo que es presentado en el trabajo utiliza un árbol binario de triángulos para la representación del terreno. Utiliza un par de colas con prioridad para manejar operaciones de división o split y de combinación o merge de triángulos. El algoritmo aprovecha la coherencia entre cuadro y cuadro, de manera tal que sólo deben realizarse operaciones sobre el mallado obtenido en el cuadro anterior. Por último, brinda una visualización con errores proyectados acotados a partir de un preprocesamiento donde calcula el error de modelado absoluto.

Figura 6.2 – Árbol binario de triángulos. Los niveles son formados a partir de una bisección de triángulos recursiva.

El trabajo explota la coherencia cuadro a cuadro, por lo que el tiempo de ejecución es proporcional al número de triángulos que cambian en cada cuadro. El tiempo de procesamiento es entonces independiente del tamaño total del terreno (resolución y extensión). En el caso de contar con una



limitación estricta del tiempo de procesamiento de cada cuadro, el algoritmo puede adaptarse limitando la cantidad de operaciones de split y merge que se realizan. Por otro lado, los pocos cambios que se producen por cuadro reducen los artefactos temporales, como los saltos o pops. Sin embargo, el algoritmo deja lugar para incorporar fácilmente un mecanismo de mutación de vértices o vertex morphing, que suaviza el cambio de geometría en el tiempo.

La representación dinámica del terreno es realizada mediante una estructura de árbol binario de triángulos. La estructura comienza en el menor detalle (l=0), en la raíz, con un triángulo rectángulo e isósceles. El siguiente nivel se logra con la división o bisección del lado más largo o hipotenusa (longest-edge bisection) para refinar la raíz en dos nuevos triángulos rectángulos e isósceles, que conforman el nivel 1 (l=1). La bisección se realiza desde el vértice que presenta el ángulo recto, a la mitad de la hipotenusa, surgiendo allí un nuevo vértice. Los siguientes niveles son logrados siguiendo este procedimiento de bisección de triángulos recursivamente (Figura 6.2).

Los autores se refieren a un par de triángulos que comparten la hipotenusa como un diamante. Las operaciones de split y merge ocurren en ambos triángulos del diamante, asegurando una malla continua, libre de vértices T (Figura 6.3).

El mecanismo de refinamiento o simplificación es realizado utilizando dos colas con prioridad, una para las operaciones de split y otra para las operaciones de merge. Los autores desarrollan un mecanismo de prioridades monótonas, donde la prioridad de un triángulo hijo es siempre menor que la de su triángulo padre. De esta manera, como las operaciones son desencoladas en orden de prioridad, siempre se producen mallas continuas y no es necesario realizar esfuerzos especiales para evitar los vértices T.

Figura 6.3 – Operaciones de split y merge sobre ambos triángulos de un diamante. Cuando el triángulo AED es refinado surgiendo el vértice H, también se refina el triángulo AFD. De manera equivalente, cuando los triángulos AHE y EHD se combinan, también deben combinarse los triángulos AHF y FHD.

En el mecanismo de prioridades es involucrado el error de modelado. El error de modelado para cada triángulo en el árbol binario es calculado en un procesamiento previo (antes del tiempo de ejecución). El error de modelado es calculado bottom-up de manera absoluta contra la máxima resolución disponible y, además, se asegura que sea estrictamente



monótono no decreciente, ya que el error de modelado de un triángulo padre siempre es mayor o igual que el de los hijos.

Por otro lado, el error de modelado es independiente de los parámetros de la visualización, y su cálculo previo ayuda al cálculo en tiempo de ejecución del error proyectado o perceptible. Como el error de modelado es calculado de manera absoluta y además es saturado para asegurar que sea monótono, definiendo un valor umbral para el error proyectado, el mecanismo asegura una visualización con el error perceptible acotado. Lindstrom et al. [Lindstrom et al. 1996], por el contrario, al calcular el error de manera relativa, finalmente, no pueden asegurar una visualización con el error perceptible acotado.

Finalmente, los autores de ROAM, al comparar su trabajo con el de Lindstrom et al. [Lindstrom et al. 1996] destacan que utilizan la misma estrategia de representación y división y combinación de triángulos, aunque estos últimos no hayan reconocido la estructura de árbol binario de triángulos subyacente. Además, mencionan que deben mantener una estructura especial para asegurar la continuidad en la malla, algo implícito en la estrategia presentada en ROAM. Más aún, en Lindstrom et al., la coherencia cuadro a cuadro no es aprovechada ya que siempre la simplificación por vértice dentro de cada bloque es realizada bottom-up. Por último, destacan que ROAM se diferencia del trabajo de Lindstrom et al., ya que este último, además de no poder asegurar una visualización con error acotado, presenta una técnica que no es adaptable a una restricción en la cantidad de triángulos en el mallado a producir, ni tampoco soporta la inclusión de vertex morphing para el ocultamiento de los pops.

6.3 Smooth View-Dependent Level-of-Detail Control and its Application to Terrain Rendering

Este trabajo presentado en 1998 por Hugues Hoppe [Hoppe 1998] extiende el uso de su VDPM (View-Dependent Progressive Mesh) framework [Hoppe 1997] sobre aplicaciones de renderizado de terrenos. El framework consta de una representación de un modelo en mallas de detalle progresivo y dependiente de parámetros de la visualización. Aplicado al renderizado de terrenos, permite representar la superficie de un terreno utilizando una malla arbitraria de triángulos a partir de una estructura jerárquica de transformaciones geométricas de refinamiento progresivo. Esta estructura permite obtener eficientemente aproximaciones de la malla original en distintos niveles de detalle. Además, el trabajo introduce el uso de geomorphs para eliminar el artefacto de popping, e introduce un cálculo exacto del error de aproximación en las representaciones utilizadas realizado previo al tiempo de ejecución.

A partir de un terreno originalmente modelado por una malla arbitraria (puede ser regular o no), produce representaciones de la superficie usando una malla irregular o TIN con el objetivo de minimizar la cantidad de vértices, ya que el procesamiento de la geometría es el cuello de botella dentro del pipeline gráfico en las aplicaciones que involucran el renderizado de terrenos.

El terreno es entonces representado por lo que Hoppe llama una malla progresiva o progressive mesh (PM) [Hoppe 1996]. Esta malla progresiva describe una malla arbitraria de triángulos Mn, compuesta por todos los



vértices en los que está relevado el terreno. Tras un procesamiento realizado previo al tiempo de ejecución, Mn es representada a partir de una malla más simple M0 junto con una secuencia de n transformaciones de refinamiento llamadas vertex splits o vsplits. Esta representación se obtiene bottom-up a partir de tener la malla en su máximo detalle Mn y aplicarle n operaciones inversas a los vsplits llamadas edge collapse o ecol (Figura 6.4). De esta manera se define una jerarquía de vértices con una forma de árbol binaria sin una única raíz, donde los nodos raíces son los vértices presentes en la malla M0 y las hojas contienen los vértices de la malla Mn. Finalmente, de la estructura descripta pueden obtenerse mallas M del nivel de refinamiento deseado sin necesidad de que pertenezcan a la secuencia M0 … Mn (Figura 6.5). Usualmente, la cantidad de vértices en la malla M es mucho menor a la cantidad original de vértices.

El algoritmo se basa en 2 aspectos principales para decidir si se realiza una operación de simplificación o refinamiento en cada vértice: (i) si se encuentra dentro del espacio que es visualizado; (ii) si excede o no una tolerancia, especificada por el usuario, de t pixeles de la desviación proyectada en pantalla.

Figura 6.4 - Las operaciones vertex split y edge collapse.

Figura 6.5 - Árbol binario que representa la jerarquía de los vértices.

Por otro lado, los efectos de salto son totalmente eliminados si se toma la tolerancia t igual a 1, pero lo mismo puede llevar a tener muchos polígonos renderizados afectando el frame-rate. En contraposición, Hoppe introduce el concepto geomorphs. El uso de geomorphs significa que el cambio de geometría, tras una operación de vsplit o ecol, sea realizado de manera progresiva a través del avance de algunos cuadros. Por ende, el uso de geomorphs en tiempo de ejecución, permite un valor más alto en la tolerancia, logrando que el cambio en la malla sea progresivo, en lugar de instantáneo. Puntualmente consiste en ir interpolando la posición del vértice a lo largo de x cuadros (parámetro dado por el usuario). Cabe destacar que estos geomorphs son utilizados sólo cuando los vértices involucrados son



visibles; en cambio, cuando los mismos son dejados atrás por la porción visible por la cámara, son instantáneamente simplificados.

Hoppe introduce el concepto de geomorphing utilizado en muchos trabajos posteriores. Larsen and Christensen [Larsen and Christensen 2003] proponen que el geomorphing es equivalente a una animación, y por ende enumeran tres métodos posibles para controlar la duración y el progreso de la animación. Las opciones son controlar la animación a partir de: (i) el tiempo, se define una cantidad de milisegundos para la duración; (ii) los cuadros, la animación durará una cantidad de cuadros o frames especificados; y (iii) la velocidad del observador, la velocidad de la animación es función del movimiento del observador o cámara. Hoppe en su trabajo menciona que opta por que el geomorph dure un segundo, pero el valor definido es una cantidad de frames (que coincide en valor con los frames por segundo logrados por su método). En cambio, Larsen y Christensen prefieren que la animación sea controlada por el movimiento del observador. Las ventajas son que el terreno no sufre modificaciones cuando el observador no se mueve, y a mayor velocidad del observador, la percepción de detalles disminuye, por lo que los geomorph pueden ocurrir más rápido.

Retomando el trabajo de Hoppe, el mismo propone un cálculo exacto del error de aproximación. Indica que no alcanza con que el cálculo se realice en todos los puntos de máxima resolución presentes en una grilla regular inicial, ya que no es suficiente y puede llevar a cambios importantes en el mallado provocando saltos perceptiblemente grandes. El cálculo se realiza entonces en todos los puntos de la grilla de máxima resolución y, además, en las intersecciones de los lados de los triángulos a los que pertenece el vértice colapsado, con las aristas de los triángulos en la grilla original (Figura 6.6). Por último, como fue introducido, el cálculo de estos errores de modelados se realiza como preproceso para usarlo como criterio para las operaciones en tiempo de ejecución.

Figura 6.6 – Puntos donde se calcula el error de modelado.

Finalmente, teniendo en cuenta que la información del terreno puede ser muy grande, el trabajo parte el modelo en bloques que son recursivamente simplificados y combinados, a su vez, en bloques. De esta manera, intenta brindar escalabilidad para el manejo de grandes extensiones de terreno, administrando el uso de memoria principal en tiempo de ejecución. Se genera entonces para cada bloque una representación jerárquica comenzando por el nivel de mayor detalle, y



luego se van aplicando transformaciones ecol (dejando intactos los vértices de los bordes para prevenir vértices T) mientras se respete una tolerancia al error de modelado que es dada por parámetro para cada nivel. Estas transformaciones van siendo guardadas en orden en disco. A continuación, se juntan los bloques en 2 x 2, y se repite el proceso. Al terminar, la malla M0 contará con dos triángulos e invirtiendo los ecol se forma la secuencia de vsplit. Por último, en tiempo de ejecución la estructura jerárquica es recorrida top-down armando el mallado a utilizar incluyendo vértices hasta que los errores de modelado codificados en cada vértice no excedan, al proyectarse, el valor umbral especificado por el usuario.


Evolución del Hardware Gráfico: El Pipeline Gráfico Programable 37

7 Evolución del Hardware Gráfico: El Pipeline Gráfico Programable

Como se ha desarrollado en el Capítulo 3, la secuencia de operaciones que se llevan a cabo para mostrar en un dispositivo una imagen, producto de la visualización de una escena tridimensional, es llamada pipeline gráfico. Esta denominación permite la abstracción y el modelado genérico de las tareas comunes que son necesarias para la visualización de escenarios sintéticos. La abstracción del modelo descrito, tiene como objetivo el desarrollo de aplicaciones gráficas independientes de la implementación concreta del pipeline. A lo largo del tiempo, el pipeline gráfico es implementado tanto en productos de software, como de hardware, y la combinación de estos.

Por último, se desarrollan algunas las consideraciones que deben tenerse en cuenta para maximizar el rendimiento de las aplicaciones que utilizan el pipeline gráfico de las nuevas generaciónes de GPUs. Estos conceptos dan lugar a un cambio de paradigma en el desarrollo de soluciones para las aplicaciones gráficas.

7.1 Historia del Hardware Gráfico

La evolución del hardware gráfico en los últimos 15 años ha sobrepasado el crecimiento de cualquier otro hardware, modelado por la Ley de Moore. La razón reside en que, además del progreso en la reducción del tamaño de los transistores y la integración de los mismos, el paralelismo innato de las operaciones del pipeline permite incrementar aún más el rendimiento.

Por otro lado, la evolución puede explicarse como consecuencia de la presión de la industria. Aplicaciones militares y médicas requerían soluciones para la generación de gráficos en tiempo real. Además, la industria de entretenimiento, como los videojuegos, aportó una gran demanda para el desarrollo de mejores soluciones.

En el artículo de Luebke y Humphreys, “How GPUs work” [Luebke and Humphreys 2007], se explica muy bien la motivación existente para la generación de hardware específico que implemente las funcionalidades del pipeline gráfico. La generación de gráficos en tiempo real, para aplicaciones interactivas, requiere producir reiterativamente imágenes para mostrar en un dispositivo, al menos, 15 cuadros por segundo. Por lo tanto, las operaciones de cada etapa del pipeline gráfico, que se ejecutan por cada objeto de la escena y en cada cuadro, deberán ejecutarse eficientemente numerosas veces. En consecuencia, surge la necesidad de desarrollar hardware específico que contemple la realización de las operaciones repetitivas en forma eficiente. Del artículo mencionado pueden extraerse principalmente las siguientes:

• La etapa de transformaciones se caracteriza por aplicar transformaciones lineales a atributos de los vértices, aplicando operaciones matriciales a vectores. Por ende, se necesita hardware gráfico que realice eficientemente operaciones aritméticas con vectores con valores de punto flotante.



• La etapa de rasterización produce los píxeles necesarios para la representación de una primitiva en pantalla. Los cálculos para decidir el color de cada píxel son independientes de los demás pixeles. Por lo tanto, el hardware puede explotar esta característica realizando los cómputos de cada píxel en forma paralela.

• Dentro de los cálculos para la decisión del color de cada píxel, una estrategia común es tomarlo de una imagen precargada que es llamada textura. Entonces, es necesario que el hardware permita la carga de texturas en memoria de rápido acceso o consulta.

Previo a la era de las computadoras personales o PC, las soluciones consistían en hardware dedicado y costoso. Con la aparición de las PC disponibles al público en general, IBM lanzó en 1987 las conocidas tarjetas de video VGA, adaptadores de gráficos de video, que funcionaban como un frame-buffer y lo administraban. En ese entonces, el conjunto de operaciones del pipeline era implementado por la CPU, responsable además de acceder y actualizar el frame buffer. Luego, a finales de los 90, cuando las tarjetas comenzaron a implementar las funcionalidades del pipeline, NVIDIA introdujo el término GPU, unidades de procesamiento gráfico, para identificar al hardware gráfico.

La historia de las GPUs se divide en distintas generaciones. En su comienzo, el pipeline gráfico fue implementado como una secuencia de operaciones fijas, donde las mismas eran configurables utilizando parámetros de entrada. Luego, a partir de la tercera generación de GPU, se incluye la posibilidad de programar las operaciones de algunas etapas del pipeline, manteniendo otras fijas. El conjunto de instrucciones o programas, que se ejecutan en la GPU, son llamados shaders, y, por este motivo, las generaciones de GPUs programables se corresponden a distintos modelos de programación o Shader Models.

A continuación, se explican brevemente las características de cada una de las etapas de la historia de las GPUs. La nomenclatura utilizada se basa en la utilizada en el capítulo introductorio de [Fernando and Kilgard 2003].

� Pre – GPUs

David Evans e Ivan Sutherland fueron los pioneros de la computación gráfica tras fundar su compañía Evans & Sutherland en 1968. Proveyeron soluciones para proyectos militares de simulación y entrenamiento, entre otros. Luego, en 1981, Sillicon Graphics (SGI) fue fundada por alumnos de Ivan Sutherland. Estas compañías fueron las que diseñaron y desarrollaron costosos sistemas de hardware específicos, que sentaron las bases de varios conceptos de la computación gráfica actual, como las transformaciones de vértices y el uso de texturas. Hoy en día, las GPU accesibles han sobrepasado largamente las capacidades de aquellos sistemas exclusivos.

� Primera Generación de GPUs

En 1998, aparecieron las primeras tarjetas gráficas accesibles al público que implementaron parte del procesamiento del pipeline en su hardware. La implementación consistió en el grupo de tareas incluidas en la etapa de rasterización. Por ende, como entrada requería las primitivas ya



transformadas en espacio de coordenadas de pantalla, y, entonces, las operaciones de transformación y ensamblado eran realizadas por la CPU (Figura 7.1a). Tras la rasterización, tenían la capacidad de aplicar una o dos texturas para el cálculo del color de cada fragmento. Las marcas comerciales que surgieron con esta tecnología son la NVIDIA TNT2, ATI Rage y 3dfx Voodoo3. El bus de comunicaciones utilizado por estas tarjetas era PCI, compartido con el resto de los periféricos instalados en la misma PC.

� Segunda Generación de GPUs

Hacia finales de 1999 y principios del 2000, una nueva generación de GPUs fueron liberadas al mercado, conocidas como T&L GPUs. Su denominación se debe a que implementaban en su hardware las operaciones de transformación e iluminación (en ingles, transform and lighting) para los vértices 3D introducidos en el pipeline (Figura 7.1b). Además, esta generación permitía más opciones en las operaciones realizadas por el pipeline, por ende, ofrecían más alternativas de configuraciones. Las principales tarjetas o placas comerciales que implementaron el pipeline completo en su hardware fueron las NVIDIA GeForce 256 y GeForce2, ATI Radeon 7500 y S3 Savage3D. Por último, estas placas utilizaban un bus exclusivo de comunicaciones, AGP.

� Tercera Generación de GPUs

En lugar de ofrecer más alternativas de configuración para la etapa de procesamiento de vértices, se introdujo la posibilidad de especificar una secuencia de instrucciones para los cómputos de cada vértice (Figura 7.1c). Sin embargo, para el cálculo realizado sobre cada fragmento sólo se ofrecieron mayores posibilidades de configuración. En Lindholm et al. [Lindholm et al. 2001] se describen las decisiones de diseño de los programas de vértices, más tarde llamados vertex shaders, y su implementación en la GPU NVIDIA GeForce3. Los programas ofrecían un conjunto limitado de instrucciones para operar con un conjunto, también limitado, de registros (Shader Model 1.1). Además, no se incluyeron instrucciones de control de flujo para mantener el hardware simple.

Las marcas de esta generación, del año 2001 y comienzos del 2002, que pueden nombrarse son la NVIDIA GeForce3 y GeForce4, y la ATI Radeon 8500. Finalmente, aunque limitadamente, esta generación introdujo los primeros vestigios de permitir la programación de operaciones en las GPU.

� Cuarta Generación de GPUs

La cuarta generación es considerada la primera generación de GPU completamente programables. Se extendieron las posibilidades de programación para los programas de vértices, y se introdujeron los programas de fragmentos (Figura 7.1d). Las primeras tarjetas gráficas representativas de esta generación, hacia fines de 2002, son la serie GeForce FX de NVIDIA y las ATI Radeon 9700 y 9800, conformes al modelo de programación Shader Model 2.x.

El diseño e implementación de estas tarjetas permitieron la programación en un nivel de abstracción mayor utilizando lenguajes de programación especiales. Los programas de vértices y fragmentos, al ser de



naturaleza diferentes, poseían operaciones particulares para cada uno (aparte del conjunto de operaciones básicas). De este modo, en las tarjetas existían unidades de procesamiento específicas tanto para los vertex shaders como para los fragment ó pixel shaders.

Luego, en 2004, la serie GeForce 6 de NVIDIA salió al mercado implementando un nuevo modelo de programación, el Shader Model 3.0 [Kilgariff and Fernando 2005]. Esta serie introdujo el uso de un nuevo bus de comunicaciones dedicado de mayor velocidad, el PCIe. Por otro lado, este modelo puso en común la mayoría de las operaciones de los dos shaders, como por ejemplo, permitiendo la consulta de valores de texturas en los programas de vértices [Gerasimov et al. 2004]; sin embargo, se mantuvo la diferenciación de las unidades de procesamiento.

Rasterización

Operaciones de

Rasterizado

Frame Buffer

Ensamblado de

Primitivas

Transformaciones

de Vértices

PCI

Rasterización

Operaciones de

Rasterizado

Frame Buffer

Ensamblado de

Primitivas

Transformaciones

de Vértices

AGP

Rasterización

Operaciones de

Rasterizado

Frame Buffer

Ensamblado de

Primitivas

Transformaciones

de Vértices

AGP

Vertex Shader

limitados

Rasterización

Operaciones de

Rasterizado

Frame Buffer

Ensamblado de

Primitivas

Transformaciones

de Vértices

AGP / PCIe

Vertex Shader

Fragment Shader

Vértices de los

Modelos de

Objetos

Vértices de los

Modelos de

Objetos

Vértices de los

Modelos de

Objetos

Vértices de los

Modelos de

Objetos

CPU

GPU

CPU CPU CPU

GPU GPU GPU

(a) (b) (c) (d)

Primera Generación de GPUs Segunda Generación de GPUs Tercera Generación de GPUs Cuarta Generación de GPUs

Figura 7.1 – Implementación del pipeline gráfico en las primeras cuatro generaciones de GPUs. (a) Primer Generación: Sólo se implementa en GPU las etapas de pasterización. (b) Segunda Generación: Se incorpora la transformación y ensamblado de vértices dentro de las GPUs. (c) Tercer Generación: surge la primera etapa programable, el vertex shader. (d) Cuarta Generación: se aumenta la posibilidad de programación dentro de las GPU, en etapas de vertex shader y fragment shader.

� Quinta Generación de GPUs

Luego de 3 años, en 2007, una nueva generación de GPU fue introducida en el mercado. El cambio fundamental fue la unificación de las unidades de procesamiento. Esta característica permite ahora balancear la carga de procesamiento utilizando las unidades de procesamiento necesarias para cada etapa de manera dinámica. Por el contrario, el modelo anterior daba lugar a ocasiones donde las unidades de procesamiento de



fragmentos podían encontrarse saturadas mientras que las de vértices se encontraban libres, y viceversa. Además, el modelo unificado de unidades de procesamiento permite definitivamente la misma implementación para todas las operaciones de los distintos shaders. Por último, el poder de cálculo y paralelismo de este hardware, da lugar al uso de las GPU para procesamientos de propósitos generales, distintos a la renderización de escenas. Este tema, GPGPU (General-Purpose Computing on GPU), presenta una rama de estudio muy interesante respecto al uso de las GPU, pero excede el alcance de este trabajo.

Ejemplos de GPU de esta generación son las NVIDIA GeForce 8800 y posteriores, y la AMD Radeon HD2900. Estas placas se corresponden al cuarto modelo de programación Shader Model 4.0, que introduce una nueva etapa en el pipeline gráfico. Esta nueva etapa, llamada de geometría (Geometry Shader), permite el procesamiento particular de cada primitiva, pudiendo modificarla, descartarla o incluso generar nuevas. Este modelo de programación es motivo de desarrollo del siguiente capítulo.

Finalmente, en la actualidad, se encuentran disponibles nuevas GPU

que implementan un nuevo modelo de programación Shader Model 5.0, introducido en distintas conferencias en el área hacia fines de 2008 y en 2009. El modelo introduce nuevas etapas programables en el pipeline gráfico y aún más optimizaciones de rendimiento. Las GPU comerciales que lo implementan son la NVIDIA Geforce GTX 480 (2010) y la serie AMD Radeon HD5800 (2009). Sin embargo, al momento de escribir el presente trabajo, no se encuentra documentación suficiente sobre este nuevo modelo.

7.2 Interfaces de Programación 3D

En los principios de la década del 1990, con la aparición de las computadoras personales, surgieron bibliotecas de programación que facilitaron el desarrollo de aplicaciones 3D en el área de la computación gráfica, como ser, juegos, simuladores, etc. Previamente, las aplicaciones eran desarrolladas de manera particular para cada plataforma o hardware en la que se ejecutaría. Para que una misma aplicación pudiera ejecutarse sobre otro hardware, debía re-invertirse mucho esfuerzo. Entonces, el objetivo de estas bibliotecas fue permitir desarrollar aplicaciones 3D abstrayéndose del hardware sobre el cual se ejecutarían.

Estas bibliotecas proveyeron una interfaz de programación común para aplicaciones 3D, concentrando el manejo particular de cada implementación de hardware. Además, estas bibliotecas abstraen e implementan el pipeline gráfico. Ofrecen una visualización genérica del pipeline, como fue introducido en el Capítulo 3, brindando las funcionalidades necesarias para su uso y configuración. De esta manera, abstraen la implementación del pipeline, tanto de la implementación de software, como de la implementación de hardware presente en las distintas generaciones de GPU vistas anteriormente. Estas bibliotecas o interfaces de programación han ido evolucionando, proveyendo mayores funcionalidades, de la mano de la evolución de las GPU y las implementaciones de algoritmos gráficos. Las dos interfaces de programación más populares son OpenGL y DirectX.

En primer lugar surge OpenGL como un estándar de una interfaz de programación para escribir aplicaciones 3D. Provee funcionalidades



independientes de la plataforma. Se encuentran disponibles implementaciones para computadoras que usan Windows, Linux y Macintosh. OpenGL fue inicialmente desarrollado por Silicon Graphics Inc. (SGI) en 1992. Luego, fue y es mantenido por una junta de revisión (OpenGL Architecture Review Board), que libera actualizaciones y nuevas versiones del estándar.

Por otro lado, unos años más tarde, Microsoft lanza un paquete de interfaces de programación multimedia para el desarrollo de aplicaciones sobre sus sistemas operativos. Este paquete de APIs fue llamado Microsoft DirectX, y la interfaz de programación que maneja el renderizado de escenas 3D es Direct3D. A medida en que fueron evolucionando las capacidades gráficas, nuevas versiones de DirectX fueron liberadas.

Al surgir las tarjetas gráficas programables, estas bibliotecas ofrecieron lenguajes de programación para los programas de vértices y fragmentos. Estos lenguajes, que permitían una programación de alto nivel basados en C, son HLSL (High-Level Shading Language) ofrecido en DirectX y GLSL (OpenGL Shading Language) por parte del OpenGL.

Por razones comerciales y de mercado, la mayoría de los juegos y aplicaciones de gráficos 3D comerciales son desarrollados sobre la plataforma Windows. La evolución del software y del hardware gráfico, impulsado por la industria de entretenimientos, entre otros motivos, también es liderada por las nuevas versiones de estas interfaces gráficas que pretenden brindar mayores y mejores funcionalidades para el desarrollo de nuevas aplicaciones.

Por los motivos explicados en el párrafo anterior, el software desarrollado como resultado del trabajo de esta tesis, es implementado utilizando la API Direct3D, parte del paquete DirectX, en su versión 10.0, sobre plataforma Windows 7.

7.3 Cambio en el Paradigma de Programación de Aplicaciones de Gráficos 3D.

El surgimiento de las nuevas generaciones de GPU programables modificó los criterios de maximización del rendimiento de las aplicaciones interactivas de gráficos 3D. Previo al 2000, el esfuerzo estaba concentrado en la reducción de triángulos, como puede apreciarse en las técnicas de renderizado de terrenos con nivel de detalle explicadas en el Capítulo 6. La fuerza de procesamiento residía solo en la CPU, siendo la única unidad de procesamiento. Por lo tanto, el objetivo consistía en reducir la cantidad de procesamiento requerido para el renderizado de escenas 3D, para permitir resultados interactivos, y dando lugar a otros procesamientos que deben ser realizados por la CPU dentro de las aplicaciones.

Las generaciones de GPU programables introdujeron nuevas unidades de procesamiento que pueden concentrar el esfuerzo dedicado al renderizado de escenas, quitando trabajo a la CPU. Además, en la actualidad, el poder de procesamiento de las GPU supera en gran medida a las CPU, y la proyección es que la brecha seguirá aumentando. Como las GPU han incrementado su fuerza de cómputo para el renderizado de cada vez más triángulos por segundo, mejores rendimientos serán obtenidos si el tiempo de CPU también es optimizado.



Las GPU modernas poseen varias unidades de procesamiento propias e independientes. Entonces, una de las claves para optimizar el rendimiento es aprovechar el paralelismo entre estas unidades y, además, el trabajo en paralelo de la CPU y las GPUs. De esta manera, se deben minimizar los puntos de contacto o comunicación entre la CPU y la GPU. Esto es, minimizar los puntos de sincronismo y aprovechar al máximo el ancho de banda del bus de comunicación cuando las comunicaciones son necesarias.

El esquema del trabajo en paralelo entre la CPU y GPU, consiste en que mientras la CPU se encuentra procesando y preparando los datos para la generación de un cuadro i, la GPU está procesando los vértices y fragmentos para el cuadro anterior i–1, y en el dispositivo se está visualizando el cuadro previo i–2 (Figura 7.2).

Figura 7.2- Esquema del procesamiento paralelo de CPU y GPU.

Por otro lado, dado que la capacidad del bus de comunicaciones se ha incrementado, tanto como el poder de procesamiento de las GPU, una de las claves a tener en cuenta es que la CPU pueda alimentar adecuadamente a la GPU. El criterio consta en poder enviar pocas unidades de trabajo grandes por cuadro, en lugar de enviar muchas unidades de trabajo pequeñas. Este criterio ayuda a disminuir también el overhead producido por los cambios de estados o configuraciones del pipeline.

Por ultimo, tanto la modificación en tiempo de ejecución de los datos de un recurso, como la lectura por parte de la CPU de los mismos, suponen puntos de sincronismo en el trabajo en paralelo que deben tratar de minimizarse o evitarse.

Finalmente, la evolución de las GPU permite obtener mejoras en el rendimiento de las aplicaciones interactivas y, a la vez, ofrecer visualizaciones más ricas. Estas características se traducen en un cambio de paradigma para los algoritmos de renderizado, ya que los criterios de optimización del rendimiento han sido modificados. Por ejemplo, ya no es necesario el trabajo exhaustivo de la CPU para lograr la minimización de triángulos y vértices. En consecuencia, nuevas técnicas de renderizado surgen para aprovechar las nuevas características de las GPU.


Programación de GPUs: Shader Model 4.0 45

8 Programación de GPUs: Shader Model 4.0

En el artículo de Blythe [Blythe 2006] se introduce el modelo de programación de GPUs Shader Model 4.0 junto con Direct3D 10. La implementación del mecanismo de renderizado de terrenos de esta tesis se realizó utilizando este modelo a través de la interfaz de programación Direct3D. Este capítulo consta de una breve explicación del modelo de pipeline gráfico ofrecido en esta versión, sus nuevas funcionalidades y la manera de utilizarlo para la renderización de escenas 3D. Por último, se desarrollarán algunas funcionalidades que pueden tenerse en cuenta para maximizar el rendimiento de las aplicaciones de renderizado de terrenos que utilizan el pipeline gráfico de esta generación de GPUs.

8.1 Nueva Versión del Pipeline Gráfico

Este modelo de programación de GPUs introducido en [Blythe 2006] presenta novedades respecto de las generaciones anteriores. El nuevo modelo incluye una nueva etapa programable que procesa las primitivas y es capaz de generar nuevas primitivas y enviarlas a un buffer de memoria de video. Por otro lado, se extienden las características de programación y se generalizan los recursos disponibles para todas las etapas.

El nuevo modelo mantiene la estructura original y agrega dos nuevas etapas (Figura 8.1). A continuación se describen brevemente cada una de las etapas.

• Input Assembler: Esta primera etapa es la responsable de preparar los datos de cada vértice y transferirlos desde la memoria de video al vertex shader. Para lograr esa tarea, junta la información de los distintos buffers presentes en memoria, y genera los datos de entrada de cada vértice para ser utilizados en la siguiente etapa. Además, permite replicar los vértices de un objeto dando lugar a la creación de varias instancias (esta técnica es llamada instancing y será desarrollada más adelante). Por último, genera parámetros automáticos que permiten identificar de manera única cada vértice, y la primitiva e instancia a la que pertenecen. Estos parámetros pueden ser utilizados en los programas que se encuentran a continuación.

• Vertex Shader: Los programas de vértices permiten realizar operaciones para sobre los datos de cada uno de los vértices de entrada. Su principal función es transformar vértices del espacio del objeto al volumen canónico de visualización. Además, al ser programable permite realizar las operaciones que el programador desee sobre cada vértice, como por ejemplo cálculos de iluminación y muestreo de texturas.

• Geometry Shader: Estos programas de geometría o primitivas, permiten operar sobre los vértices de una primitiva. Esta etapa puede descartar o agregar atributos a los vértices, como así también descartar la primitiva o generar nuevas. Por último, esta etapa puede encontrarse activada o desactivada según lo desee el programador. El programador debe decidir dónde realizar las operaciones de transformación, aquí o en el vertex shader.



• Stream Output: Esta etapa permite copiar la salida de los programas de geometría en buffers de memoria de video. Luego, estos buffers pueden usarse como buffers de entrada para la etapa de Input Assembler. Esta etapa sólo puede estar activa si los geometry shaders lo están.

• Rasterizer: Esta etapa de procesamiento fijo, recibe como entradas los vértices de cada primitiva y genera los píxeles o fragmentos correspondientes. Realiza la última transformación del volumen canónico de visualización a coordenadas de pantalla, el proceso de recorte, e interpola los atributos de cada vértice para generar los atributos de cada fragmento.

• Pixel Shader: Los programas de fragmentos procesan cada fragmento generado en la etapa anterior. La función de estos programas es generar el color final para ese fragmento, a partir de los atributos del mismo.

• Output Merger: Esta etapa realiza las últimas operaciones del pipeline, varias pruebas para descartar o combinar el fragmento con otros, y luego escribe en el frame-buffer.

Finalmente, a partir de este nuevo modelo de pipeline gráfico con sus nuevas etapas, el programador obtiene mayor flexibilidad en su uso, pudiéndolo utilizar de 4 maneras diferentes [Engel et al. 2008] (Figura 8.2).

8.2 Recursos y su Utilización

El pipeline gráfico trabaja sobre un espacio de memoria donde vuelca sus resultados y de donde obtiene datos para operar. Las interfaces de programación brindan la posibilidad de utilizar el espacio de memoria de video a partir del uso de recursos. Un recurso representa un bloque de memoria que contiene un tipo de dato específico y será utilizado con un objetivo en particular.

Direct3D 10 permite utilizar recursos con datos de distintos formatos, e indicar distintos tipos de uso y etapas donde es utilizado [Engel et al. 2008]. El formato de los datos de un recurso puede ser real de punto flotante o entero con o sin signo, entre otros. El tipo de uso permite indicar la manera de uso del recurso durante la ejecución de la aplicación. Por ejemplo, un recurso puede establecerse como inmutable, indicando que no será modificado tras su creación, o puede indicarse como dynamic, si requerirá actualizaciones en tiempo de ejecución. Por último, la interfaz de programación permite indicar a qué etapa del pipeline un recurso es asociado.

De manera genérica, Direct3D 10 permite crear dos tipos de recursos: buffers y texturas. Un buffer representa el tipo de recursos más simple, consistiendo en un bloque plano de memoria de tamaño fijo definido en bytes. En cambio, las texturas representan una organización espacial implícita entre los datos. Las texturas que pueden crearse son de 1, 2 y 3 dimensiones. Las texturas son creadas indicando el número de elementos en cada dimensión de la misma junto con el formato de cada elemento.



Input Assembler

Vertex Shader

Geometry Shader

Stream Output

Rasterizer

Pixel Shader

Output Merger

Figura 8.1- Etapas del nuevo pipeline gráfico introducido en el Shader Model 4.0. Las etapas programables se encuentran sombreadas en amarillo.

Los buffers son generalmente utilizados de tres maneras: como buffers de vértices o vertex buffers, como buffers de índices o index buffers, y como buffers de constantes o constant buffers. Los buffers de vértices se utilizan para almacenar los datos de cada vértice de un objeto. Los datos de cada vértice son definidos por el programador; a modo de ejemplo, para cada vértice puede almacenarse su posición y sus coordenadas de textura. Por otro lado, los buffers de índices indican los vértices (del buffer de vértices que se utilice) que son utilizados para armar las primitivas que definen las superficies del objeto. Los buffers de índices constan de una secuencia de números enteros que indican el índice de los vértices dentro de un vertex buffer. Luego, la secuencia de índices de vértices es interpretada en la etapa de input assembler para formar las primitivas; por ejemplo, los índices pueden definir una lista de triángulos. Y por último, los buffers de constantes se utilizan para almacenar un conjunto de datos para ser utilizados como constantes en los programas de vértices y fragmentos. Los datos de estos buffers pueden actualizarse en tiempo de ejecución. Se recomienda agrupar los datos en distintos buffers de constantes según su frecuencia de actualización.



Las texturas, por su lado, son usualmente utilizadas para definir el color de los píxeles de las superficies de los objetos. Sin embargo, también pueden ser utilizadas de manera genérica para almacenar distintos tipos de datos. Por ejemplo, pueden almacenar mapas de alturas, mapas de normales y mapas de iluminación, entre otros usos posibles.

Por último, una novedad del modelo de programación en cuestión es la introducción de arreglos de texturas. De esta manera, un recurso puede consistir en un arreglo de texturas 1D o 2D. Esta característica permite cargar varias texturas de igual tamaño en las distintas capas de un arreglo de texturas y, por ende, un shader podrá seleccionar en tiempo de ejecución la capa de donde obtener valores.

8.3 Configuración del Pipeline: Efectos

DirectX proveyó en sus últimas versiones un lenguaje de alto nivel, HLSL, para facilitar la programación de los programas de vértices y fragmentos que en un comienzo era realizado con un mecanismo de programación del estilo de Assembler. En Direct3D 10, los programas de vértices, fragmentos y ahora geometría, son codificados en un archivo de texto que es llamado “efecto” con extensión “*.fx”. Además, de las instrucciones para cada programa, el efecto permite describir la configuración completa del pipeline. Un efecto será utilizado para el renderizado de un objeto o un conjunto de ellos.

Un efecto describe los buffers de constantes y las texturas que se utilizan en los programas, junto con la secuencia de instrucciones de los mismos. Además define los parámetros de configuración de las etapas fijas del pipeline.

Un efecto permite la definición de más de un programa de vértices, fragmentos y geometría. Para el renderizado, el efecto define técnicas, que agrupa una secuencia de pasadas. Cada pasada define un programa de vértices, un programa de geometría (opcional) y un programa de fragmentos a utilizar, junto con las configuraciones del resto del pipeline. La Tabla 8.1 muestra un ejemplo de un archivo fx que define los programas de GPU y la configuración del pipeline para renderizar un objeto particular.

Por último, Direct3D 10 ofrece un conjunto de funciones en su interfaz para la compilación y carga de los efectos, y para su utilización por parte del programador de la aplicación para el renderizado de los objetos.

8.4 Análisis de las Nuevas Características Introducidas

En Patidar et al. [Patidar et al. 2006] se presenta un análisis sobre las nuevas funcionalidades o características introducidas en Direct3D10/Shader Model 4.0. El trabajo también expone resultados de experimentos realizados utilizando las nuevas funcionalidades. En esta sección, nos interesa revisar las características que pueden ser utilizadas en técnicas o algoritmos de renderizado de terreno.

La unificación de las unidades de procesamiento, permite que el muestreo de texturas sea eficiente para cualquiera de las etapas. En modelos anteriores, las unidades de procesamiento dedicadas a fragmentos estaban optimizadas para el acceso a las texturas. Si bien el Shader Model 3.0 incorporó el acceso a texturas en las unidades de procesamiento de



vértices, su uso solía ser penalizante en performance. Esta característica puede ser explotada por los algoritmos de renderizado de terrenos, ya que las alturas de los vértices de una malla regular pueden cargarse en una textura 2D y ser consultados por los programas de vértices.

Input Assembler

Vertex Shader

Geometry Shader

Stream Output

Rasterizer

Pixel Shader

Output Merger

Input Assembler

Vertex Shader

Geometry Shader

Stream Output

Rasterizer

Pixel Shader

Output Merger

Input Assembler

Vertex Shader

Geometry Shader

Stream Output

Rasterizer

Pixel Shader

Output Merger

Input Assembler

Vertex Shader

Geometry Shader

Stream Output

Rasterizer

Pixel Shader

Output Merger

Figura 8.2 – Cuatro maneras diferentes de utilizar el pipeline gráfico del SM4.0.

En un principio, la etapa de geometría puede aprovecharse también para dos tareas distintas. En primer lugar, da lugar a la implementación de un segundo nivel más preciso de frustum-culling a nivel de triángulo, directamente en estas unidades de procesamiento. La CPU seguiría encargada de un primer nivel de frustum culling a nivel de bloques, y la GPU realizaría un testeo de mayor precisión descartando aquellos triángulos que se encuentren completamente fuera del volumen de visualización, ahorrando trabajo a la tarea de recorte. En segundo lugar, la habilidad de generar geometría, permitiría el refinamiento de un triángulo en 2 o más triángulos para obtener mayor detalle. Esto permite disminuir el ancho de banda necesario en la comunicación de datos para los vértices entre la CPU y GPU, ya que podrían disminuirse la cantidad de vértices de entrada.



La posibilidad de refinar triángulos en el Geometry Shader puede combinarse con la posibilidad de escribir el resultado en memoria de video usando la etapa de Stream Output. De esta manera, puede pensarse una técnica que consista en una determinada cantidad de pasadas que refinen una malla de poco detalle, junto con una pasada final que renderize. Este algoritmo que refina una malla de pocos puntos y obtiene una malla con primitivas o triángulos más pequeños de mayor detalle es llamado tessellation.

//--------------------------- // Texturas a utilizar //--------------------------- Texture2D ColorTexture; //--------------------------- // Buffer de Variables // Constantes //--------------------------- cbuffer cb0 { matrix World; matrix View; matrix Projection; } //--------------------------- // Estructuras de datos a // utilizar //--------------------------- struct VS_INPUT { float4 Pos : POSITION; float2 TextCoord : TEXCOORD0; }; struct PS_INPUT { float4 Pos : SV_POSITION; float2 TextCoord : TEXCOORD0; }; //--------------------------- // Samplers de Texturas //--------------------------- SamplerState TextureSampler { Filter = MIN_MAG_MIP_LINEAR; AddressU = Wrap; AddressV = Wrap; }; //----------------------------- // Configuración del Rasterizer //----------------------------- RasterizerState rsSolid { FillMode = Solid; CullMode = Back; };

//---------------------------- // Vertex Shader //---------------------------- PS_INPUT VS( VS_INPUT input ) { PS_INPUT output = ( PS_INPUT)0; output.Pos = mul ( input.Pos, World ); output.Pos = mul ( output.Pos, View ); output.Pos = mul ( output.Pos, Projection ); output.Color = input.Color; return output; } //---------------------------- // Pixel Shader //---------------------------- float4 PS( PS_INPUT input) : SV_Target { return ColorTexture.Sample( TextureSampler, input.TextCoord); } //----------------------------- // Configuraciones del pipeline //----------------------------- technique10 Render { pass P0 { SetRasterizerState( rsSolid ); SetVertexShader( CompileShader( vs_4_0 , VS()) ); SetGeometryShader( NULL ); SetPixelShader( CompileShader( ps_4_0 , PS()) ); } }

Tabla 8.1- Archivo fx o efecto que define la configuración del pipeline para el renderizado de objetos.



Lamentablemente, toda la potencialidad de aprovechamiento de esta nueva etapa de geometría se ve perjudicada por las limitaciones en rendimiento que ofrecen las implementaciones de este shader. Los resultados obtenidos cuando este shader es utilizado, disminuyen en performance comparado con algoritmos que no los utilizan. La performance no es buena ya que termina introduciendo un overhead importante en el pipeline. En el mismo reporte técnico de NVidia [NVidia 2008] se menciona que los programas de geometría no deben ser utilizados para realizar tareas costosas de tessellation. Más aún, se menciona también que las penalizaciones en rendimiento hacen que esta etapa sea una característica del SM4.0 que no es utilizada.

Por último, la incorporación de arreglos de texturas permite mejoras en la técnica de instanciación o instancing. Esta técnica implica la réplica de un mismo objeto (descripto por un conjunto de vértices) utilizando una sola función de la API para dibujar varias instancias del objeto en una escena. Por lo tanto, la instanciación permite enviar gran cantidad de trabajo a la GPU utilizando una sola llamada o función.

Considerando las técnicas de renderizado de terrenos, varios bloques del terreno podrían mandarse a dibujar con una única función, utilizando un programa de vértices que obtenga la altura de una capa particular de un arreglo de texturas 2D.


Soluciones Modernas al Renderizado de Terrenos 53

9 Soluciones Modernas al Renderizado de Terrenos

Nuevas técnicas surgieron tras el cambio de paradigma en el diseño de soluciones de aplicaciones gráficas interactivas, producido por la evolución de las GPU (Capítulo 7). Las técnicas debían aprovechar el paralelismo introducido por las unidades de procesamiento disponibles en las GPU programables.

Las soluciones para el renderizado de terrenos desarrolladas hasta el momento, como las presentadas en el Capítulo 6, ya no se correspondían con los nuevos criterios surgidos para maximizar el rendimiento y la calidad. Si bien la disminución de la cantidad de triángulos sigue siendo necesaria, ya no es útil la minimización de los mismos llevado a cabo por un gran esfuerzo de cómputo de la CPU. Las técnicas de fuerza bruta siguen siendo inaceptables si se desean incorporar mayores extensiones de terreno y mejor detalle. Además, el desperdicio de recursos que implica el renderizado utilizando fuerza bruta ya fue explicado, y por ende esta técnica es descartada. Las técnicas de nivel de detalle, presentadas en los finales de los 90, seguían siendo válidas, aunque necesitaban una revisión y actualización dado los nuevos criterios.

Varios trabajos sobre el renderizado de terrenos mencionan el cambio de criterio y la necesidad de adaptar las soluciones al nuevo paradigma de programación de aplicaciones gráficas [Ulrich 2002, Wagner 2004, de Boer 2000]. De Boer menciona que ya no es necesario enviar el conjunto perfecto de datos al pipeline, sino que se debe enviar al pipeline tanta geometría como pueda ser soportada por el procesamiento del hardware y minimizar el procesamiento en la CPU. Wagner menciona que las GPUs de 2003 ya son capaces de manejar 200000 triángulos por cuadro manteniendo un buen rendimiento, como en el juego “Unreal 2”. Por lo tanto, ya no es importante que el mallado producido para la visualización de terrenos este formado por 10000 o 20000 triángulos. La importancia reside en que el mallado se produzca con el mínimo de procesamiento de CPU. La CPU, además del armado de la escena, también debe ocuparse de otras tareas: la física de los objetos, la inteligencia artificial de los personajes, las comunicaciones en juegos distribuidos, etc.

En este capítulo se abordarán dos técnicas de nivel de detalle, que encuentran sus bases en las técnicas que ya han sido desarrolladas y se adaptan al cambio de paradigma establecido por las GPUs programables. Estas técnicas llevan el nombre de Geometrical MipMapping [de Boer 2000] y Geometry Clipmaps [Lossaso and Hoppe 2004]. Estas soluciones han sentado la base de muchos otros trabajos presentados a lo largo de la última década y, por ende, son considerados como soluciones referentes manteniéndose como estado del arte del área de interés.

9.1 Geometrical MipMapping

El trabajo de de Boer [de Boer 2000] es, cronológicamente, el primer trabajo que aborda el renderizado de terrenos teniendo en cuenta las capacidades de las nuevas GPUs. El autor propone dividir el terreno en bloques y luego decidir el nivel de detalle con el que será representado cada bloque en cada instante. Contrariamente a las técnicas ROAM [Duchanieu et al. 1997] y VDPM aplicado a terrenos [Hoppe 1998] que deciden el nivel de



detalle en base a un análisis realizado a nivel de los triángulos, y de manera similar a la primera parte de la técnica presentada por Lindstrom et al. [Lindstrom et al. 1996], el algoritmo presentado decide la resolución de distintas regiones del terreno en un análisis más burdo, a nivel de bloques. Como los trabajos precedentes, para la decisión del nivel de detalle, utiliza un valor umbral para el máximo valor admisible del error proyectado. El algoritmo es bautizado como GeoMipMaps, en analogía a la técnica de mipmapping utilizada con texturas que es bien conocida en el área de la computación gráfica.

Mipmapping [Williams 1983] es una técnica de nivel de detalle de texturas. A partir de una textura, se arma una estructura que consiste en una cadena de texturas donde cada una posee la mitad de resolución de la que la precede. La primera textura de la cadena es la textura original, y se posee tantas texturas como se desee. Luego, en el momento de muestrear una textura para decidir el color de un fragmento, se utiliza una de las texturas de la cadena según la distancia del fragmento a la cámara. Por lo tanto, la analogía presentada por de Boer consiste en la posibilidad de representar cada bloque con distintos niveles de detalle precalculados, cada uno conteniendo la mitad de la resolución del anterior. La elección del nivel de detalle en cada bloque se realiza utilizando la distancia a la cámara (como uno de los parámetros para el cálculo del error proyectado).

La solución propuesta parte de poseer una representación del terreno que consista de una grilla regular cuadrada de 12 +k vértices de lado, donde

),1[ →∈k . Entonces, el terreno es divido en bloques cuadrados de 12 +n vértices de lado, donde ),1[ →∈n , que comparten los vértices del borde con sus vecinos. La simplificación de la grilla del terreno se logra a partir de tener diferentes niveles de detalles para “dibujar” cada bloque. El nivel 0 cuenta con los 12 +n vértices de lado; luego, el lado del nivel m consiste en

12 +−mn vértices, con nm< . Claro está, a mayor nivel m, se tienen triángulos más grandes, es decir, menor resolución (Figura 9.1).

Figura 9.1- Distintos niveles de GeoMipMaps a partir de un bloque original de 5x5 vértices.

Dada la representación del terreno utilizada, el algoritmo de renderizado, en primer lugar, procede a omitir aquellos bloques que no entran en el espacio visualizado por la cámara, aplicando la técnica de frustrum culling (ver Capítulo 4). Para ello utiliza una estructura de datos armada en tiempo de carga, conocida como quadtree ó árbol-cuaternario, equivalente a la estructura de árbol ejemplificada en la Sección 5.2. Cada



nodo del árbol se subdivide en 4 nodos hijos (excepto las hojas). La raíz (que representa todo el terreno) tiene como hijos cuatro grandes bloques cuadrados e iguales en los que es dividida la grilla inicial, estos a su vez son divididos en cuatro bloques cuadrados, y así hasta que los bloques resultantes son aquellos en los que fue dividida originalmente la grilla, siendo estos bloques las hojas del árbol. De esta manera, teniendo la porción del espacio que es visualizada por la cámara, el árbol es recorrido top-down para aplicar eficientemente el testeo de frustum culling. Cada nodo del árbol tiene guardada la información de las coordenadas límites que definen un volumen que contiene su geometría. Comenzando por la raíz, se accede a cada nodo del árbol y si el volumen que lo contiene interseca con el volumen de visualización, se ingresa recursivamente a los nodos hijos hasta llegar a las hojas (si no hay intersección espacial, la recursividad termina para esa rama del árbol). De este modo, de los nodos hoja alcanzados, se obtienen los bloques que deben visualizarse, los cuales son marcados como visibles.

Luego, el algoritmo decide el nivel de detalle de cada bloque visible asegurando que el tamaño de la proyección del error no exceda el valor umbral definido. Para realizar esto, en vez de proyectar cuadro a cuadro el máximo error de modelado de un bloque y compararlo con el valor umbral, utiliza una técnica más eficiente. La idea consiste en precalcular la mínima distancia a la cual un nivel m puede ser utilizado para cada bloque, utilizando los parámetros de la visualización y el máximo error de modelado en cada nivel. Esto es realizado previo al tiempo de ejecución, optimizando luego el procesamiento de CPU cuadro a cuadro, comparando solamente distancias.

Figura 9.2- Reconexión de los vértices (en rojo) en el bloque de mayor detalle ante un vecino de menor detalle, omitiendo la conexión del vértice que no esta presente en el último. A la izquierda un GeoMipMap de nivel 1 y a la derecha de nivel 0.

Por otro lado, la técnica propuesta produce grietas entre dos bloques vecinos cuando son representados con distintos niveles de detalle. Para resolver este artefacto, propone realizar una reconexión de los vértices del bloque de mayor detalle que lindan con el bloque de menor detalle, omitiendo la conexión de aquellos vértices ausentes en el segundo (Figura 9.2). Sin embargo es importante recalcar que esta reconexión no es



consistente cuando se tiene más de un vecino de menor nivel de detalle. En un trabajo posterior [Larsen and Christensen 2003], esto es resuelto a partir de una conexión inicial distinta de los vértices del bloque, que posibilita dicha consistencia en la reconexión (Figura 9.3).

Figura 9.3- Distinta conexión inicial para cada bloque propuesta en [Larsen and Christensen 2003] y reconexión consistente ante vecinos de distintos niveles.

Por último, de Boer propone que pueden ser implementadas dos mejoras a su algoritmo. La primera consiste en realizar un cambio gradual del nivel de detalle para contribuir a la eliminación del efecto de salto (popping). Esta mejora es comparada con la técnica de “filtrado trilineal” utilizado junto a mipmapping. La segunda pretende solucionar el problema que aparece cuando la información del terreno no entra en memoria principal por completo. Entonces, propone el prearmado del quadtree de todo el terreno, calculando las mínimas distancias a las cuales pueden usarse los diferentes niveles de GeoMipMaps para cada bloque del terreno y almacenarlo en memoria principal. Luego, en tiempo de ejecución, si el bloque es visible, los datos de las alturas de los vértices del bloque deben ser cargados desde el disco para la creación efectiva del GeoMipMap correspondiente.

9.2 Geometry Clipmaps

Lossaso y Hoppe presentan un trabajo donde minimizan el trabajo de procesamiento en la CPU. Los autores bautizan esta técnica como Geometry Clipmaps [Lossaso and Hoppe 2004], ya que también recurren a una analogía a la técnica de mipmapping de texturas. La técnica consiste en una representación del terreno mediante un conjunto de grillas anidadas y centradas alrededor del observador. Cada grilla es representada con un nivel de detalle diferente, disminuyendo la resolución en las grillas externas. La información del terreno que es cubierto por las grillas es almacenada en memoria de video. La información de las grillas es actualizada de manera incremental cuando el observador se desplaza. De esta manera, sólo se renueva una parte de los datos, utilizando y aprovechando la coherencia cuadro a cuadro.

El nivel de detalle o resolución de cada una de las grillas del conjunto se mantiene constante. De este modo, el nivel de detalle de las distintas regiones del terreno sólo se basa en la distancia 2D al observador. Por ende, el algoritmo es independiente de las características particulares del



terreno a representar; es decir, no se analizan errores de modelado ni sus proyecciones en pantalla.

Figura 9.4 – (a) Las superficies cubiertas por las grillas de diferente resolución pueden verse como una pirámide. (b) Anidamiento de las grillas que representan el terreno en distintos niveles de detalle.

Una característica principal del trabajo es que la independencia del algoritmo respecto a las particularidades de los terrenos, permite un rendimiento constante. Esto es consecuencia de que la carga de procesamiento realizada por la CPU no varía significativamente durante el tiempo de ejecución.

La analogía que es planteada respecto de la técnica de mipmapping, reside en que al usar texturas con mipmaps, el nivel de detalle de la textura a utilizar se decide sólo en base a parámetros de la vista y la distancia a la cámara, ignorando el contenido propio de la imagen.

Una estrategia interesante que utiliza es la predicción de la superficie de una zona de mayor detalle a partir de la región de menor detalle que la contiene. La predicción consta simplemente de un sobremuestreo a partir de la interpolación de aquellos vértices disponibles en la región de menor detalle [Kobbelt 1996]. Luego, la altura real de cada vértice se obtiene tras sumar un residuo que es obtenido en tiempo de ejecución. El residuo consiste en la diferencia de la altura real del vértice en el conjunto de datos disponible, con la altura calculada por el algoritmo de predicción. El cálculo de los residuos consta de un procesamiento previo a la ejecución.

El uso de la estrategia anterior, permite, por un lado, cargar por completo el terreno en memoria de video con una resolución baja. Por otro lado, el trabajo utiliza un mecanismo de compresión para los residuos. El mecanismo de compresión permite compresiones en el orden de 60-100 veces, y la descompresión puede realizarse sobre regiones de interés [Malvar 2000]. En consecuencia, la compresión de los residuos permite cargarlos en memoria principal, dando lugar a que la CPU realice la descompresión sin la necesidad de lecturas a disco.

Respecto a la representación del terreno, el trabajo parte de la disponibilidad de un terreno modelado utilizando un mallado regular. Las grillas cuadradas de 12 −n vértices de lado (con ...3,2,1=n ) que se utilizan, representan regiones del terreno muestreadas en sucesivas resoluciones equivalentes a potencias de dos. El conjunto de grillas, dada las superficies que abarcan, pueden verse como una pirámide, de manera tal que tras



proyectar los distintos niveles de la pirámide al plano inferior se obtienen las grillas anidadas (Figura 9.4). A la hora de renderizar, sólo la grilla de mayor detalle es dibujada por completo, los otros niveles se dibujan omitiendo la parte central que ya es cubierta por los niveles de mayor detalle.

Figura 9.5 – Estrategia de actualización de la geometría utilizando acceso toroidal. La figura muestra como la estructura 2D con los datos de la geometría es actualizada en dos cuadros consecutivos dado el desplazamiento del observador.

El trabajo propone pensar la estructura de datos que contiene la geometría de cada grilla como una estructura de dos dimensiones. El desplazamiento del observador implica actualizar la grilla para que la misma se mantenga centrada respecto del observador. Como el desplazamiento del observador entre cuadro y cuadro es coherente1, la actualización requiere sólo una porción nueva de geometría. En vez de modificar la estructura de datos por completo, desplazando los datos ya presentes que siguen perteneciendo a la grilla, se propone un direccionamiento circular o acceso toroidal sobre la estructura de datos. Esto consiste en desplazar el centro lógico de la estructura de manera equivalente al desplazamiento del observador respecto del cuadro anterior. De esta manera, sólo se requiere actualizar unas franjas horizontales y/o verticales de la estructura 2D, manteniendo intactos los datos presentes aún válidos (Figura 9.5). Como puede verse, esta estrategia optimiza el procesamiento de actualización de las grillas.

Por otro lado, el uso de grillas de distinto nivel de detalle puede introducir discontinuidades espaciales y temporales. Para evitar la aparición

1 Al decir, “un desplazamiento […] coherente” se refiere a que el desplazamiento es progresivo, siendo las posiciones del observador en cuadros sucesivos cercanas entre si, donde la diferencia es pequeña.



de grietas en los vértices T de los bordes de las grillas, los autores optan por incorporar geometría a cada grilla en sus bordes. La idea consta de formar triángulos cada tres vértices de los bordes. Estos triángulos son denominados de área cero (zero-area triangles), porque si los tres vértices son colineales, el triángulo será de área nula y son descartados en la etapa de rasterizado. En el caso en el que los vértices no sean colineales, resulta un triángulo vertical que oculta la grieta (Figura 9.6). Con respecto a los artefactos de saltos, el trabajo define una zona de transición dentro de cada grilla donde aplica geomorphing.

Finalmente, puede apreciarse que Geometry Clipmaps propone una técnica de renderizado de terrenos innovadora, optimizando el procesamiento y el uso de recursos mediante distintas estrategias. Sin embargo, la ganancia en rendimiento es obtenida junto con una limitación. Los mismos autores mencionan que se asume la representación de un terreno con detalles de baja frecuencia. En el caso de poseer detalles de alta frecuencia, es probable que los mismos aparezcan de manera repentina y tarde en la visualización. Esta limitación es consecuencia de la independencia del algoritmo respecto de las particularidades de los terrenos, ya que nunca tiene en cuenta la rugosidad de las superficies representadas.

Figura 9.6- Triángulos utilizados para evitar las grietas en los bordes de grillas vecinas de distinto nivel de detalle. El triángulo ABC termina siendo de área nula, mientras que el triángulo CDE tiene una superficie que cubre la grieta.

9.3 Geometry Clipmaps en la GPU

Un año después de la publicación del trabajo que introduce los Geometry Clipmaps, Assirvatham y Hoppe escriben un artículo donde exponen la implementación de la mayoría de las operaciones en la GPU [Asirvathan and Hoppe 2005]. La implementación es realizada utilizando GPUs de la cuarta generación descripta en el Capítulo 7. Con mayor precisión, utilizan las GPUs de la segunda mitad de esta generación que responden al Shader Model 3.0. La incorporación de la posibilidad de muestrear valores de una textura en el vertex shader, permite un mejor rendimiento.

En [Lossaso and Hoppe 2004] cada grilla es representada utilizando un vertex buffer, requiriendo que la CPU administre su actualización. Además, la CPU debe generar un nuevo index buffer distinto para cada nivel cuadro a cuadro. La creación y modificación en tiempo de ejecución de los buffers de vértices e índices son operaciones costosas en los hardware gráficos.



En el nuevo trabajo, utilizando el SM 3.0, se almacena la información de alturas de los vértices de cada grilla en distintas texturas 2D que son muestreadas en los programas de vértices. En consecuencia, esto permite utilizar vertex buffers constantes que contienen sólo las coordenadas (x, y) de los vértices, ya que la coordenada z se obtiene de las texturas. Los index buffer que se utilizan son también constantes. Más aún, el uso de texturas facilita la actualización incremental usando la técnica toroidal, ya que la actualización afectará a sólo a unas pocas filas y/o columnas de la textura.

Además, almacenar la información de altura en texturas permite que el resto de las operaciones de la técnica sean realizadas completamente en la GPU, como por ejemplo, el cálculo de predicción de las alturas en las grillas de mayor detalle. La CPU sólo se encarga de descomprimir los residuos y cargarlos en una textura de residuos, para que puedan ser sumados a las predicciones y así obtener el valor de altura original de cada vértice.

Por otro lado, las operaciones de geomorphing son realizadas completamente en el vertex shader.

Finalmente, en resumen, el artículo expone una implementación de Geometry Clipmaps basada en el uso de la GPU obteniendo una mejor performance.

9.4 Trabajos Posteriores

Como se ha mencionado anteriormente, Geometrical MipMaps y Geometry Clipmaps, son los trabajos que marcaron el estado del arte de las técnicas de renderizado de terrenos de la última década. Estos trabajos sentaron las bases para los algoritmos que han sido adaptados para el aprovechamiento del poder de procesamiento de las GPUs programables. En consecuencia, estos trabajos han sido utilizados como fuentes de numerosos trabajos posteriores.

Dentro de las trabajos basados en la idea presentada en Geometrical MipMaps, que consiste en dividir el terreno en bloques y decidir el nivel de detalle para cada uno de ellos, han surgido numerosas variaciones y permutaciones [Snook 2001] [Ulrich 2002] [Larsen and Christensen 2003] [Wagner 2004]. Estos trabajos, a modo de ejemplo, han agregado aportes sobre: la implementación de algunas características en las GPUs programables, nuevas interconexiones de los vértices de los bloques para evitar grietas entre vecinos de distinto nivel de detalle, etc.

Lindstrom junto a colegas han actualizado y extendido el trabajo presentado en 1996 [Lindstrom et al. 1996] al publicar dos nuevos trabajos con el objetivo de proponer una técnica sencilla que soporte mayores extensiones de terrenos [Lindstrom and Pascucci 2001] [Lindstrom and Pascucci 2002].

Por otro lado, Geometry Clipmaps ha sido extendido para representar superficies planetarias utilizando coordenadas esféricas [Clasen and Hege 2006].

Finalmente, una buena guía y resumen que concentra las técnicas sobre renderizado de terrenos a partir de mallados regulares puede consultarse en [Pajarola and Gobbetti 2007].


Diseño de la Solución Propuesta 61

10 Diseño de la Solución Propuesta

En los capítulos anteriores se han explicado los aspectos que conciernen al desafío de la visualización de terrenos en aplicaciones interactivas y se han desarrollado los comienzos, evolución y el estado del arte de las técnicas y trabajos existentes que abordan el tema. Entonces, tras la introducción de los conceptos anteriores, este capítulo estará dedicado a los detalles tenidos en cuenta para el diseño de una nueva solución que consiste en el foco de interés de la presente tesis.

La solución desarrollada busca proponer una alternativa de interés para abordar el tema de visualización de terrenos. En primer lugar, se exponen las razones que motivan el diseño de esta nueva solución o técnica. Luego, se explican en detalle los aspectos centrales de la técnica. Los aspectos desarrollados consisten en la descripción de la representación del terreno utilizada, el criterio de selección del nivel de detalle, la estrategia de resolución de los artefactos conocidos, y la descripción del algoritmo utilizado en tiempo de ejecución para renderizar cada cuadro.

Este capítulo no ahondará en los detalles de la implementación, que son dejados para su desarrollo en el capítulo siguiente.

10.1 Motivaciones y Decisiones de Diseño

Como ya fue explicado, el objetivo de este trabajo es introducir una técnica propia que resuelva el problema de renderizado de terrenos. Se busca desarrollar una técnica que pueda ser incorporada en el desarrollo de aplicaciones reales interactivas. Por ende, la simplicidad de la idea y el algoritmo presentados es tan importante como el rendimiento alcanzado. Además, el rendimiento de la técnica desarrollada no puede encontrarse en el límite de lo aceptable, ya que la misma formará parte de una aplicación concreta más compleja, que usará la CPU para el procesamiento particular que necesite. Por último, para el diseño de la técnica se han analizado las funcionalidades que brindan software y hardware actuales para maximizar el rendimiento.

Dentro de la amplia variedad de aplicaciones interactivas de renderizado de terrenos, el foco residirá sobre los simuladores de vuelo utilizados para entrenamiento de pilotos. Los simuladores de vuelo no sólo tienen los requerimientos comunes de tiempo real, sino también, demandan mayor calidad visual que los juegos comerciales. La simulación debe brindar un ambiente inmersivo al piloto y permitirle volar sobre escenarios reales de la superficie terrestre fielmente representados. Estas características implican que el usuario no debe percibir distracciones que interfieran con su inmersión en la simulación; por ende, no pueden percibirse artefactos ni errores en la representación. Por otro lado, la representación de escenarios reales no permite la generación automática en tiempo de ejecución del terreno, característica conocida como síntesis de terrenos. Las descripciones de los terrenos estarán disponibles en archivos que indiquen la elevación real de distintos puntos de la superficie.

Además, como fue dicho, la técnica resolverá sólo una parte de las tareas concernientes a un simulador de vuelo o cualquier otra aplicación interactiva. Usualmente, motores gráficos o de juegos brindan una mayor abstracción para la administración de las tareas gráficas, respecto de las



interfaces de programación 3D o bibliotecas gráficas presentadas en la Sección 7.2. Estos motores permiten el manejo y visualización de escenas virtuales en un mayor nivel de abstracción. Los motores brindan servicios a las aplicaciones para: representar e instalar objetos, configurar las luces y las cámaras, administrar movimientos o trayectorias de los objetos, etc. Más aún, una aplicación de simulación de vuelo debe ejecutar la evolución de un modelo matemático que describe la dinámica de vuelo del avión, mostrar y administrar los paneles de instrumentos de la aeronave, etc. Finalmente, la técnica presentada deberá ser integrada y formará parte de un motor gráfico, que a su vez será utilizado por una aplicación de simulación de vuelo. Por ende, la eficiencia de la técnica desarrollada en cuanto al uso de procesamiento de la CPU es fundamental.

Por otro lado, las características de las funcionalidades ofrecidas por hardware y software actuales no sólo son de interés para la implementación, sino que también deben tenerse en cuenta en el diseño. El aprovechamiento de las capacidades de las GPU, funcionalidades y poder de cómputo, es fundamental para las expectativas de rendimiento descriptas. La decisión tomada para este trabajo es explotar las capacidades de las GPUs actuales que se corresponden al modelo de programación Shader Model 4.0. Entre las novedades de este modelo sobresale la nueva etapa Geometry Shader para la generación o eliminación de primitivas dentro del mismo pipeline gráfico implementado enteramente en la GPU. Por ende, es necesario un análisis de esta etapa y de su rendimiento. La decisión de incluir o no el uso de esta etapa afecta el diseño del algoritmo a utilizar en tiempo de ejecución. Los detalles que respectan a la implementación de la técnica en cuanto a la programación del algoritmo y programas en la GPU serán descriptos en el siguiente capítulo.

Dadas las motivaciones presentadas, pueden resumirse las dos principales características que debe presentar la solución: alto rendimiento y precisión en la visualización de terrenos. Tras el estudio de los trabajos en el área, se destaca la técnica de Geometry Clipmaps [Lossaso and Hoppe 2004] [Asirvathan and Hoppe 2005] dado el alto rendimiento que se obtiene con su implementación. Sin embargo, como fue visto, esta técnica presenta una limitación que incide en la fidelidad de la representación de las superficies. Geometry Clipmaps carece del análisis de errores para la decisión del nivel de detalle con el cual representar el terreno. La precisión de la superficie visualizada es un aspecto central. Para cumplir con esta característica la técnica debe asegurar que los errores introducidos por el uso de nivel de detalle no sean perceptibles por el usuario. Por ende, debe analizarse el error que se percibe, y al menos, asegurar una cota superior al mismo. Esta característica introducida en [Lindstrom et al. 1996] es incorporada a la técnica desarrollada. Dado que el análisis del error a nivel de vértices no es eficiente, el análisis se realizará a nivel de bloques como en GeoMipMaps [de Boer 2000].

Claro esta, el análisis del error se traduce en que, comparando con Geometry Clipmaps, se necesita mayor procesamiento de CPU para el cálculo del error proyectado y, si es necesario el refinamiento de algunas regiones, la transferencia de alturas desde la CPU a la GPU y mayor cantidad de geometría para dibujar. A pesar de que esto significa claramente un rendimiento menor al de Geometry Clipmaps, los resultados obtenidos tras la implementación en CPUs y GPUs modernas son más que aceptables (ver Capítulo 12).



Finalmente, siguiendo la categorización común de las técnicas de nivel de detalle de terrenos, también descripta en [Pajarola and Gobbetti 2007], la técnica desarrollada puede encuadrarse entre dos categorías diferentes. El diseño combina aspectos, por un lado, de aquellas técnicas que proponen grillas anidadas y concéntricas (en inglés, nested-grids) alrededor del observador y, por el otro, de aquellas técnicas que dividen al terreno en celdas o bloques (en inglés, tiled-blocks).

10.2 Representación del Terreno

La solución presentada está basada en Geometry Clipmaps y pretende agregarle la habilidad de analizar el error introducido por el uso de niveles de detalle. Esto es realizado subdividiendo cada grilla anidada en bloques o tiles (en español, baldosas). Luego, se decide si alguno de los bloques necesita ser refinado para garantizar una representación del terreno con error acotado (en inglés, error-bounded).

Figura 10.1 – Tamaños utilizados para los parches, bloques y márgenes. Pueden apreciarse además la relación entre esas estructuras. Se usa para la figura n = 17 y m = 3.

A partir de Geometry Clipmaps, el terreno es representado usando un conjunto de grillas o patches (en español, parches) centrados alrededor de la posición del observador. Cada parche representa una región del terreno con distinta resolución o nivel de detalle. El nivel más detallado es el nivel cero (L = 0), donde el espacio entre los puntos de elevación de la superficie



se encuentran en la máxima resolución. La superficie cubierta por cada nivel es cuatro veces mayor que el nivel que lo precede, es decir que el intervalo de muestreo del primero duplica el del segundo. El intervalo de muestreo de un parche es 2L veces el intervalo de muestreo de la máxima resolución disponible, para L = 0, 1, 2….

En consecuencia, todos los parches o grillas tienen la misma cantidad de puntos o vértices, n x n. A diferencia de Geometry Clipmaps, se elige

tomar 12 += kn (con k = 1, 2, 3…), ya que es necesario para poder dividir cada parche en bloques. La elección de ese valor para n requiere manejar nueve casos posibles para las posiciones relativas entre parches de niveles de detalles consecutivos (Figura 10.2). La posición del centro de un parche, es decir, el vértice que se encuentra en el centro de cada parche, debe coincidir con un vértice presente en el parche de menor resolución inmediato anterior. De esta manera, los bordes del parche de mayor resolución coinciden con la retícula del parche de menor resolución. Si esto no se cumpliese, aparecerían franjas sin geometría en la superficie renderizada, generando discontinuidades en el terreno.

Figura 10.2 – Los 9 casos de posiciones relativas entre parches de sucesivos niveles de detalle. Se usa para la figura n = 9.



En lo que respecta a los recursos a utilizar, los datos de elevación de los vértices de cada parche serán cargados en una textura y muestreados en los programas de vértices. Considerando mejorar el rendimiento, además de los vértices utilizados para renderizar el parche de n x n, se cargan en las texturas datos de elevación alrededor de esta región, formando un margen que es utilizado como caché. El tamaño de este margen es una cantidad de vértices igual a una potencia de dos en cada dirección (hacia arriba, abajo, izquierda y derecha). De esta manera, la actualización de los datos de cada parche recién ocurrirá cuando el caché no contenga los datos necesarios para el renderizado. Cuando esto ocurra, se actualizará una franja completa igual al tamaño del margen, optimizando el uso del ancho de banda de comunicación entre CPU y GPU. Además, esto aumenta la coherencia cuadro a cuadro, ya que evita la actualización frecuente de columnas o filas individuales en las texturas. Por último, la utilización de este margen, y su actualización completa, puede ser aprovechada si los datos de elevación se encuentran comprimidos por esquemas de compresión en bloques.

Como es realizado en Geometry Clipmaps, la actualización de las texturas se realiza de manera incremental utilizando la estrategia de acceso y direccionamiento toroidal.

Hasta este punto, se describió la representación básica del terreno similar a lo utilizado en Geometry Clipmaps. Sin embargo, esta representación no es suficiente, ya que no permite analizar la percepción de los errores de modelado para asegurar una representación con error acotado. Entonces, para agregar esta propiedad a la técnica presentada, se decide dividir cada parche en bloques. Estos bloques permiten analizar las características locales del terreno dentro de cada parche, decidiendo si el nivel de detalle del parche es suficiente o no. El análisis realizado será descripto en la sección siguiente.

En consecuencia, se utilizan bloques cuadrados de tamaño m x m, donde 12 += jm (con j = 1, 2, 3…). La solución necesita que cada parche sea divido

en, al menos, 8 x 8 bloques. Esto significa que 3≥− jk . La necesidad surge de ubicar la posición relativa del centro de cada parche, que ahora deberá coincidir con la esquina de algún bloque propio. Por otro lado, las texturas que contienen las elevaciones de cada parche, deben almacenar datos de una cantidad entera de bloques, por ende el tamaño del margen utilizado como caché, en cada sentido, debe ser de )1(2 −mi vértices de ancho (con i =

1, 2, 3…). Finalmente, en la Figura 10.1 pueden apreciarse las relaciones entre

los tamaños de las distintas grillas utilizadas para los parches, los bloques, los márgenes y las texturas.

10.3 Análisis del Error Proyectado

La técnica presentada propone dividir cada parche original de Geometry Clipmaps en bloques y, entonces, decidir si el nivel de detalle del parche es apropiado para cada bloque. La meta es que la decisión del nivel de detalle a utilizar pueda asegurar visualizaciones del terreno donde los errores introducidos no sean apreciables.

Recapitulando lo introducido en el Capítulo 5, Sección 5.1, cuando la superficie de un terreno es representada con una malla de menor resolución



que la disponible, se introducen algunos errores de aproximación o de modelado. El error de modelado se define como la distancia vertical que surge de la diferencia de altura de un vértice presente en la malla de máxima resolución respecto de la posición virtual que toma cuando es removido en un nivel de detalle de menor resolución. Este error generalmente es medido directamente en coordenadas del mundo, y por esto es conocido en la bibliografía como world-space error.

El error de modelado puede ser medido en términos relativos o absolutos. En algunos trabajos, como por ejemplo [Lindstrom et. al 1996] y [de Boer 2000], el error es medido en términos relativos entre niveles de detalles sucesivos. Esta forma de medición no permite asegurar representaciones con errores acotados. Si la técnica de nivel de detalle desea brindar una solución con error acotado, la medición de errores relativos debe ser correctamente saturada [Pajarola and Gobbeti 2007]. La saturación de errores asegura que, en un mismo bloque, el máximo error de modelado presente en una representación de menor detalle nunca es menor que al usar un nivel de mayor detalle. Sin embargo, es más preciso calcular el error de modelado de manera absoluta respecto de la máxima resolución disponible, como es realizado en ROAM [Duchanieu et al 1997].

Hugues Hoppe presenta una manera de calcular el error de modelado de manera absoluta y exacta [Hoppe 1998]. Propone el cálculo del error no sólo en los vértices de la máxima resolución que hayan sido omitidos, sino también en las intersecciones de los lados de los triángulos de menor detalle con las aristas de los triángulos presentes en la máxima resolución. La técnica presentada pretende este cálculo exacto del error. Sin embargo, al utilizar bloques que son simplificados en resoluciones sucesivas de potencias de dos, los lados de los triángulos de menor detalle coinciden con las aristas presentes en la máxima resolución. Por lo tanto, solo basta con medir el error de modelado en los vértices presentes en la máxima resolución que fueron omitidos (detalles en la Subsección 11.3.3).

Respecto al cálculo del error de modelado, la solución requiere que sea realizado anteriormente al tiempo de ejecución. La técnica desarrollada lo realiza como un preprocesamiento realizado offline, y guarda los resultados en un pequeño archivo en disco. Luego, en tiempo de carga el archivo es cargado del disco y dispuesto en memoria de CPU para evitar las latencias de lectura de disco en tiempo de ejecución. El cálculo es realizado a partir de dividir el terreno en bloques de m x m, realizando sucesivas pasadas con los bloques en sucesivas resoluciones. Se calcula el máximo error de modelado absoluto y exacto de cada bloque y se almacena en un archivo en disco. Luego, en tiempo de ejecución, a medida que el observador se desplaza y los parches son actualizados incrementalmente, se consultan los errores precalculados (ya dispuestos en la memoria principal) de los bloques necesarios.

Por otro lado, el máximo error de modelado de cada bloque, en un nivel de detalle particular, es una entrada necesaria para analizar si los errores de aproximación son perceptibles por el usuario. Entonces, en tiempo de ejecución, tras calcular la menor distancia del observador al bloque y utilizando los parámetros de la visualización, se calcula el tamaño del error proyectado en píxeles (ver cálculo en Sección 5.1).

Finalmente, la aplicación es configurada definiendo la máxima cantidad de pixeles tolerables para el error proyectado (como se encuentra en coordenadas de la pantalla, en la bibliografía es llamado screen-space



error). Este valor constituye un valor umbral con el cual se puede comparar. Si la proyección del máximo error de modelado de un bloque en pantalla excede el valor umbral, entonces esa región de terreno necesita ser representada con una resolución mayor (Figura 10.3)

Figura 10.3 – Los errores de modelado 1ε y 2ε , originados por representaciones utilizando dos niveles de detalle diferentes, son proyectados en el plano de visualización Π .

(a) Nivel 2 (L=2): la proyección 1ρ del máximo error de modelado excede el valor umbral τ .

(b) Nivel 1 (L=1): la proyección 2ρ del máximo error de modelado es menor que el valor umbral τ .

10.4 Algoritmo de Renderizado

Esta sección describe la estrategia de renderizado abordada por la técnica desarrollada. Se explica el algoritmo utilizado para generar cada cuadro en tiempo de ejecución en un alto nivel (Pseudo-Código 1). Detalles de la implementación utilizados para optimizar el rendimiento son tema del próximo capítulo.

En primer lugar, dada la posición del observador, se calcula la posición central de cada parche y se actualiza la información de elevación en cada textura si es necesario. La posición central de cada parche debe coincidir con la posición de un vértice presente en una representación del terreno utilizando el mismo nivel de detalle del parche. Además deben tenerse en cuenta las posiciones relativas entre los parches como fue explicado en la segunda sección de este capítulo. Por ende, se comienza por calcular la posición central desde el parche de menor nivel de detalle utilizado. Luego, si existe desplazamiento en la posición central en cada parche respecto del cuadro anterior, y las elevaciones necesarias no se encuentran en la textura cargada en la GPU, se procede a actualizar las texturas necesarias.

En segundo lugar, se toman los bloques de cada parche (excluyendo aquellos bloques presentes en los márgenes) para ser testeados contra el volumen de visualización (frustum-culling). Como fue explicado, es al menos necesario este testeo, ya que reduce en un cuarto la carga del



pipeline gráfico para el renderizado de geometría (calculado sobre un campo de visualización horizontal de 90 grados). El testeo se realiza utilizando una caja para definir el volumen ocupado por cada bloque. La caja se obtiene a partir de las coordenadas límites presentes en un bloque en los 3 ejes cartesianos. Esta caja, que se obtiene con el valor máximo y mínimo de las coordenadas x, y, y z de los vértices de un bloque, se llama en computación gráfica axis-aligned bounding box (AABB).

Pseudo-Código 1. Descripción en pseudo-código en alto nivel del algoritmo de renderizado que se utiliza para generar la representación del terreno en cada cuadro.

Vector tiles_to_refine; Vector unrefined_tiles; UpdatePatches(patches); foreach Patch p in patches Vector tiles = getTilesFromPatch(p); foreach Tile t in tiles if ( !culledByFrustum(t) ) if ( getScreenSpaceError(t) < threshold ) unrefined_tiles.add(t); else tiles_to_refine.add(t); end if; end if; end foreach; end foreach; render( unrefined_tiles ); refineAndRender( tiles_to_refine );

En tercer lugar, el análisis del error proyectado se realiza sobre

aquellos bloques que no fueron descartados en el paso anterior. Como fue explicado, se toma el máximo error de aproximación de cada bloque y se lo proyecta en pantalla para ser comparado con el valor umbral definido. Si el error proyectado excede el valor umbral, ese bloque necesita ser representado con una mayor resolución. El bloque debe ser representado con un nivel de detalle cuyo máximo error de aproximación, al proyectarse, no exceda el valor umbral. Este bloque, que será llamado bloque refinado, es renderizado utilizando una resolución dos, cuatro, ocho, etc. veces mayor según sea necesario (experimentalmente, raramente es necesario más de dos niveles de refinamiento). En consecuencia, los bloques refinados tendrán 1)1(*)1( +−+ mr vértices de lado, donde r es el nivel de refinamiento (r = 1, 2, 3…).

Este último paso también incluye cargar en memoria de GPU (utilizando texturas) las elevaciones necesarias para el renderizado de los bloques refinados. La técnica propone utilizar una cantidad fija de texturas para cada nivel de refinamiento, y administrar su utilización utilizando la menos usada recientemente. Esta política de administración de memoria es llamada least-recently used o LRU.



(a)

(b) Figura 10.4 – Dos cuadros distintos renderizados por la técnica propuesta (usando n = 129, m = 17). (a) Parches anidados alrededor del usuario y diferentes posiciones relativas entre niveles sucesivos. (b) Los parches que necesitaron refinamiento son marcados en rojo y dibujados en verde.

Por último, el algoritmo dibuja los bloques utilizando la técnica de instancing (detalles en el siguiente capítulo). Por ende, dibuja primero los bloques que no necesitan refinamiento, y luego los bloques refinados agrupados por nivel de refinamiento. La Figura 10.4 muestra dos cuadros renderizados por la técnica propuesta: en (a) pueden verse los distintos parches anidados y divididos en bloques; mientras que en (b) se muestran los bloques refinados marcados en rojo.

10.5 Resolución de Artefactos

Como fue introducido a lo largo del presente trabajo, al representar los terrenos con nivel de detalle pueden provocarse artefactos que degradan la continuidad espacial y temporal en las representaciones de los terrenos.



Por un lado, la discontinuidad espacial se manifiesta en grietas en la superficie del terreno y pueden ocurrir en los bordes de dos regiones representadas con niveles de detalle diferente. Este problema surge en las representaciones de nivel de detalle que no presentan un mallado continuo, como la descripta en esta tesis, al originar vértices T. Soluciones que proponen niveles de detalle continuos como [Duchanieu et al 1997] y [Lindstrom et al. 1996] no presentan este inconveniente.

Figura 10.5 – (a) Las grietas que pueden aparecer entre bloques de distinto nivel de detalle. (b) Polleras o skirts usadas alrededor de los bloques para ocultar la aparición de grietas.

Tanto las técnicas de nivel de detalle basadas en el uso de bloques, como las que utilizan grillas anidadas, tienen que resolver este problema. Las grietas pueden aparecer en bloques adyacentes de distinta resolución, ya que no comparten la misma cantidad de vértices en sus bordes (Figura 10.5 (a)). Varios trabajos en la bibliografía del tema, al presentar variaciones en los métodos basados en el uso de bloques, han propuesto distintas alternativas para evitar la aparición de grietas entre bloques vecinos. Algunos trabajos [de Boer 2000] [Snook 2001] [Wagner 2003] resuelven el problema modificando la conexión de los vértices de uno de los bloques (generalmente en el bloque de mayor resolución), evitando la presencia de vértices T. En este trabajo se decide no utilizar estas estrategias ya que requieren conocer para cada bloque el nivel de detalle de sus vecinos, agregando complejidad al algoritmo y la necesidad de manejar varios casos. Por otro lado, Ulrich [Ulrich 2002] describe en su trabajo algunas técnicas para resolver el problema agregando geometría para cubrir las posibles grietas. Las opciones que enumera son agregar alrededor de cada bloque vértices para formar: (i) “pestañas” hacia abajo con un cierto ángulo y longitud, que da a llamar flanges; (ii) “cintas verticales” de una determinada altura, que llama vertical ribbons; y (iii) “polleras” verticales, también de una determinada altura, en inglés, skirts. Mayor detalle de estas opciones pueden verse en el trabajo citado. Geometry Clipmaps, como fue explicado, cubre el perímetro de cada parche utilizando triángulos de área nula. Sin embargo, esta técnica sólo es válida cuando los bloques difieren en solo un nivel de detalle. Finalmente, en la técnica presentada se opta por utilizar “polleras” verticales alrededor de cada bloque. Estas polleras coinciden en su borde superior con el borde del bloque y tienen una extensión vertical definida por parámetro (Figura 10.5 (b)). Además, como las grietas introducidas se mantienen por debajo del valor umbral establecido, esta estrategia elegida es eficiente.

Por otro lado, las técnicas de nivel de detalle deben evitar que ocurra el artefacto de popping. Para prevenir este efecto, las soluciones suelen



interpolar gradualmente la geometría de una región cuando ocurre un cambio en el nivel de detalle. Como fue visto, Hoppe en [Hoppe 1998] bautizó esta estrategia como geomorphing. Como la técnica presentada asegura un error acotado para la representación, los cambios de geometría se mantendrán por debajo del valor umbral definido y, por definición, imperceptibles. Dada esta razón, la técnica no aplica ninguna estrategia específica para evitar los saltos o pops.

10.6 Conclusiones

Como puede apreciarse, la técnica presentada en este trabajo presenta una solución tomando distintos aspectos de trabajos anteriores. Se combinan aspectos de Geometry Clipmpas con técnicas basadas en la división del terreno en bloques, como GeoMipMaps.

En comparación con Geometry Clipmaps, se toma la misma representación inicial del terreno, la estructura de datos utilizada y la estrategia de actualización incremental de los datos de elevación. Esta decisión es impulsada por la optimización del uso de recursos y los altos rendimientos alcanzados por las implementaciones de Geometry Clipmaps. Sin embargo, la solución presentada en este trabajo agrega la capacidad de brindar visualizaciones con la percepción de errores acotados. En consecuencia, el análisis realizado para incorporar la propiedad anterior y el posible refinamiento de bloques necesario, se ve reflejado en un rendimiento algo menor a Geometry Clipmaps, sin poder asegurar trabajo de CPU prácticamente constante. A pesar de esto, como podrá verse en los resultados, las fluctuaciones ocasionales en la carga de procesamiento de la CPU no degradan la performance ni la calidad visual de la solución.

Por otro lado, comparando con las técnicas de división del terreno en bloques, la técnica presenta varias ventajas. Como fue visto, la utilización de bloques es motivada para asegurar la cota en los errores proyectados. Generalmente, las técnicas que utilizan bloques requieren la carga completa del terreno en memoria principal o de video, viéndose limitados por el tamaño del terreno. En cambio, utilizando la estrategia de Geometry Clipmaps el uso del ancho de banda CPU-GPU está optimizado, permitiendo la carga de las regiones de terreno necesarias y de manera incremental.

Finalmente, en resumen, la principal contribución de este trabajo es una técnica que agrega a Geometry Clipmaps la posibilidad de representar terrenos con error acotado. La técnica parte de una representación del terreno con grillas anidadas, utilizando como criterio para el nivel de detalle sólo la distancia al observador. Luego, las características particulares del terreno son consideradas cuando cada grilla es subdividida en bloques, para aplicar si es necesario un refinamiento (estrategia top-down) a cada bloque utilizando como criterio el error proyectado. De esta manera, se asegura una visualización sin artefactos acotando la percepción de errores a un nivel que se consideren despreciables.


Implementación de la Solución 73

11 Implementación de la Solución

Parte del trabajo de la presente tesis consiste en una implementación de una técnica de renderizado de terrenos que verifique ser eficiente. Para ello, se decide realizar la implementación usando software y hardware actuales que permitan maximizar el rendimiento. El presente estado del arte encuentra establecidas las GPUs que responden al Shader Model 4.0 y la biblioteca gráfica Direct3D en su décima versión (ver Capítulo 7). Además, la elección de las herramientas debe considerarse para el diseño de la solución. En el capítulo anterior, se mencionan cómo algunas decisiones de diseño fueron tomadas teniendo en cuenta las capacidades de las herramientas, particularmente las GPUs.

En una primera sección de este capítulo, se realizará un breve análisis de las capacidades y propiedades del Shader Model 4.0 y, utilizando Direct3D 10, las funcionalidades provistas que son aplicables y aprovechables en técnicas de renderizado de terrenos. Luego, más adelante en este capítulo, se exponen las estructuras de datos utilizadas y los detalles de la implementación de un módulo de software o framework que resuelve el problema de renderizado de terrenos. Dicha implementación sigue el diseño descripto en el capítulo anterior y, con la misma, se obtienen los resultados que serán mostrados en el capítulo siguiente.

11.1 Análisis del Shader Model 4.0 y Direct3D 10

Esta sección pretende repasar y explayar lo escrito en la última sección del Capítulo 8. Como fue dicho, para este tipo de aplicaciones o productos, analizar las propiedades y funcionalidades de las herramientas es un trabajo fundamental a realizar previo, o paralelo, a la etapa de diseño dado que se quieren lograr resultados eficientes en tiempo real. El diseño de software con tales requerimientos implica analizar y conocer el hardware sobre el cual se ejecutará. En otras palabras, el diseño de la técnica puede optimizarse al tener en cuenta el hardware a utilizar.

En [Blythe 2006] se presenta el modelo de GPUs Shader Model 4.0 junto con la librería de programación Direct3D 10 que debe usarse para acceder a sus funcionalidades. Tras seleccionar esta plataforma, sobre la cual se implementa el resultado de esta tesis, se realizaron algunas pruebas para analizar el rendimiento que se obtiene al utilizar hardware y software involucrados. A continuación se explicarán brevemente las conclusiones obtenidas de las diferentes pruebas. Las conclusiones que se obtienen son similares a las presentadas en [Patidar et al. 2006].

Tras realizar pruebas, implementando algunas de las técnicas de la bibliografía del tema y utilizando las capacidades de las GPUs para realizar el renderizado, se llega a distintas conclusiones. Algunas operaciones o funcionalidades requieren un procesamiento que resulta costoso y por ende es necesario minimizarlas o buscar soluciones que no las utilicen. Las operaciones analizadas son aquellas que pueden ser utilizadas en las técnicas de renderizado de terrenos.

Tras la novedad de estas últimas GPUs, es esperable que las técnicas aprovechen la posibilidad de implementar programas de geometría que sean ejecutados en la etapa de Geometry Shader. Esta etapa puede ser utilizada en las técnicas de renderizado de terrenos para refinar parches o



bloques completamente en la GPU, sin intervención de la CPU y minimizando la comunicación entre las unidades de procesamiento. De esta manera, podría almacenarse en la GPU una versión burda del terreno que sea refinada en tiempo de ejecución completamente utilizando procesamiento dentro de la GPU. Además, el Geometry Shader, con la habilidad de eliminar primitivas, podría ser utilizado para realizar el mecanismo de frustum culling enteramente en la GPU con mayor precisión a nivel de triángulos. Sin embargo, como fue mencionado en la sección 8.3, los resultados obtenidos al utilizar esta etapa muestran que su utilización degrada el rendimiento de las soluciones. Tras buscar algunas alternativas y distintas estrategias, se decide descartar su utilización por los resultados obtenidos.

Otra característica que incorpora las nuevas GPUs es la unificación de unidades de procesamiento de shaders. De esta manera, es esperable que el costo de realizar una operación en un vertex shader sea el mismo que realizarla en un pixel shader. Dentro de las técnicas de renderizado de terrenos, esta característica favorece al uso de mapa de alturas, es decir, almacenar la información de elevaciones de mallados regulares en texturas a ser muestreadas en los programas de vértices. Tras realizar las pruebas, la performance de los programas de vértices disminuye con el número de muestreo de texturas que se realicen. Esta realidad no hace prohibitivo el muestreo de texturas en los programas de vértices, pero sugiere mantenerlas acotadas en cantidad. Típicamente, con una lectura es suficiente para obtener la elevación del vértice. Por ejemplo, lo que no se recomienda es realizar más muestreos de texturas por vértice para promediar elevaciones e implementar de esta manera las técnicas de geomorphing.

Claramente, la principal limitación de las técnicas de renderizado de terrenos es la cantidad de vértices que describen las superficies comúnmente extensas. Aún utilizando técnicas de nivel de detalle, el cuello de botella reside en la cantidad de vértices que se desean renderizar. La opción de realizar el frustum culling en el Geometry Shader no es útil ya que esta etapa se encuentra luego de haber realizado el procesamiento de cada uno de los vértices ingresados al pipeline gráfico. Por ende, es indispensable realizar al menos algún procesamiento burdo de frustum culling en la CPU, para descartar aquellas porciones de terreno que se encuentren fuera del volumen de visualización. Esta operación es fundamental para obtener un rendimiento alto en las técnicas implementadas, permitiendo mayores extensiones de terreno con mayor calidad.

Por otro lado, como ya fue mencionado anteriormente, la clave actual para optimizar el rendimiento al implementar una técnica es minimizar el procesamiento de la CPU y las comunicaciones entre la CPU y la GPU. Los puntos de sincronismo entre las unidades de procesamiento deben evitarse, de manera de explotar al máximo el trabajo en paralelo. En esta dirección es que la implementación debe utilizar la funcionalidad de instancing junto con el uso de arreglos de texturas. Con esta funcionalidad, se minimiza el overhead producto del uso de las bibliotecas, que se traducen en comunicación entre CPU y GPU informando cambio de estados y configuraciones del pipeline. Utilizando vertex buffers para describir la organización regular de bloques en el plano XY y la posibilidad de tomar la elevación Z en los programas de vértices de alguna de las capas de un



arreglo de texturas, el terreno visualizado puede renderizarse por completo utilizando unas pocas llamadas al método Draw, método de Direct3D 10 utilizado para renderizar.

Por último, las decisiones de diseño que involucran tanto utilizar un margen alrededor de la información de elevación de cada parche, como administrar las elevaciones necesarias para los bloques refinados con una política LRU, buscan minimizar las comunicaciones entre CPU y GPU para la actualización de los datos de las texturas. De esta manera, los puntos de sincronismo son menos frecuentes, permitiendo explotar el paralelismo del hardware disponible.

11.2 Estructuras de Datos y Recursos Utilizados

Tras decidir el diseño de la estrategia del mecanismo de renderizado desarrollado, se definen las estructuras de datos que serán utilizados en la implementación. Los datos deben ser cargados en memoria de GPU para que la misma pueda procesar con ellos los programas de vértices y pixeles. Para esto, los datos son organizados en estructuras que son llamadas recursos, como fue explicado en la Sección 8.2. Estos recursos pueden ser buffers o texturas.

Como fue diseñado en la técnica teniendo en cuenta su implementación, las alturas de los vértices de los parches o bloques son muestreadas de mapas de alturas almacenados en texturas. Esta característica permite definir los recursos para describir un bloque genérico y utilizarlo como la unidad de renderizado.

} } }}

Figura 11.1 – Vertex e Index Buffers utilizados para la descripción de un bloque genérico. El vértice V0 es el usado como referencia.

Los recursos utilizados para la descripción de un bloque genérico consisten en un vertex buffer más un index buffer inmutables. El vertex buffer contiene la información 2D para cada vértice de un bloque, es decir, su posición relativa dentro del bloque en el plano XY. Por ende, el vertex buffer cuenta, por cada vértice, con dos valores enteros no signados indicando el offset del vértice respecto del valor de referencia del bloque, tanto en X como en Y. El valor de referencia del bloque coincide con su vértice superior izquierdo (Figura 11.1), por ende los valores pertenecen al intervalo [0; m-1]. Además, con el fin de implementar la pollera alrededor de los bloques para cubrir las posibles grietas, el bloque además de los m x m vértices, es formado por 2 x 4 x m vértices extras para describir los triángulos que conforman la pollera. Tanto a los vértices que pertenecen al borde superior de la pollera, como a aquellos que pertenecen al borde



inferior, les corresponde el mismo valor de XY. Para diferenciarlos, todos los vértices son descriptos por un valor de punto flotante más, de valor 0.0f o 1.0f que indica si pertenece o no al borde inferior de la pollera. Luego, para describir la conexión de los vértices se utiliza un index buffer para describir una lista de triángulos1 que definen la superficie del bloque (Figura 11.1).

El uso de recursos que definen un bloque genérico es posible gracias a la técnica de instanciación. Para la creación de instancias concretas de bloques que cubran las superficies de los parches de distintos niveles de detalle, se utiliza un vertex buffer dinámico que es completado en la generación de cada cuadro con datos que definen cada instancia. Cada instancia es definida a través de 3 valores enteros no signados junto con 2 valores de punto flotante. Los primeros 2 valores enteros no signados definen las coordenadas de muestreo del vértice de referencia del bloque concreto para obtener la coordenada Z de una textura. Los 2 valores de punto flotante definen la coordenada XY del vértice de referencia en el mundo. Por último, el valor entero no signado restante define el parche al que pertenece el bloque. Este valor es utilizado para muestrear la capa adecuada dentro del arreglo de texturas de los parches y, además, para definir la posición final en el mundo de cada vértice tras calcular el intervalo entre vértices propio del nivel de detalle del parche.

Las alturas o coordenada z de cada vértice será muestreada de una textura en los programas de vértices. Para ello, los datos de elevación serán cargados en un arreglo de texturas de tantas capas como parches de distinto nivel de detalle se utilicen. El tipo de dato de cada valor de la textura se elegirá de acuerdo a la resolución disponible de los datos de elevación del terreno a representar. Generalmente, se utilizan valores enteros no signados que luego en los programas de vértices son escalados y trasladados según un valor de escala y offset definidos, cargados en un buffer de datos constantes.

Luego, se procede de la misma manera para cargar la información necesaria para el renderizado de los bloques refinados. Para cada nivel de refinamiento, se utiliza un vertex buffer y un index buffer inmutables para la descripción 2D genérica del bloque. Asimismo, se dispone de un arreglo de texturas, de una cantidad de capas parametrizable, donde se disponen las alturas especialmente cargadas para los bloques de un nivel de refinamiento dado. Como fue dicho, las capas se administran utilizando una política LRU. Por último, de manera idéntica, se utiliza un vertex buffer dinámico para almacenar los datos necesarios para instanciar, cuadro a cuadro, los bloques refinados. Cabe aclarar, finalmente, que este esquema se repite para cada nivel de refinamiento posible.

1 En implementaciones anteriores del pipeline gráfico en hardware o software era recomendado utilizar strips de triángulos en lugar de lista de triángulos. Sin embargo, la implementación actual de GPUs pertenecientes al SM4.0, aseguran tener un caché para los vértices resultados de la etapa de vertex shader, tal que si se encuentra el resultado en caché, el vertex shader no se ejecuta dos veces para el mismo vértice de entrada. Esto indica que actualmente no hay diferencias de performance por utilizar strips de triángulos, por lo que en la implementación de este trabajo se utilizan listas de triángulos. Finalmente, experimentalmente esto fue comprobado y no se han notado diferencias de performance.



11.3 Implementación del Framework

Esta sección esta destinada a la descripción del desarrollo de un módulo de software o framework que implementa la técnica de renderizado de terrenos descripta en este trabajo. La implementación es realizada utilizando el paradigma de programación orientado a objetos, específicamente en el lenguaje C++.

En un primer lugar se mostrarán las clases utilizadas en el desarrollo del framework, y se explicarán brevemente sus funciones y responsabilidades. Luego, la descripción se centrará en aquellas clases que resuelven el renderizado del terreno utilizando la técnica presentada en esta tesis. Por último, se describirán algunos algoritmos auxiliares pero importantes que forman parte del módulo en cuestión.

11.3.1 Descripción General del Framework

La Figura 11.2 muestra el diseño UML de las clases que conforman el módulo desarrollado. El conjunto de funcionalidades anexas, requeridas para la implementación de la técnica presentada para el renderizado de terrenos, son abordadas por las clases presentes en la figura mencionada. La clase central de estas actividades y que mantiene las relaciones entre todas las clases del framework es llamada TerrainFramework.

De manera breve pueden mencionarse las motivaciones que dan lugar a la utilización de cada clase. La clase Terrain representa el conjunto de datos de un modelo de terreno a renderizar, compuesto por un objeto de la clase HeightMap, que representa los datos de elevación, y otro objeto de la clase SurfaceTexture, que contiene los datos para el texturado de la superficie del terreno. La clase TerrainViewer modela al observador del terreno, su ubicación (posición en el espacio y actitud) y los parámetros de visualización (datos para la proyección en perspectiva, por ejemplo, el campo visual). La interacción con el usuario de la aplicación, que consta principalmente en el desplazamiento y evolución del estado del observador, es resuelto por las clases JoystickListener (que toma las entradas del joystick utilizado por el usuario) y ViewerMotion que, en este caso, modela un movimiento con 4 grados de libertad para el observador. Luego, la clase que se encarga del renderizado general de la escena es la clase Renderer que contiene un SkyboxRenderer, encargado de renderizar el cielo o skybox, y una TerrainRenderingTechnique, que se encarga de renderizar el terreno aplicando una técnica de renderizado dada. Finalmente, la clase TerrainFramework, además de mantener la relación con las clases ya mencionadas, implementa la función que es iterada para el renderizado cuadro a cuadro de la escena presentada.



Figura 11.2 – Diagrama UML de las clases implementadas en el módulo de software desarrollado



Por último, cabe destacar que la clase abstracta TerrainRenderingTechnique pretende abstraer y modelizar las actividades, asociaciones y responsabilidades comunes de cualquier técnica de renderizado de terreno. La misma debe ser especializada para la implementación de una técnica concreta. A modo de ejemplo y estudio durante el período de trabajo que concluye con la presentación de esta tesis, se han implementado diferentes técnicas de renderizado: fuerza bruta en la clase BruteForceTRT, Geometrical MipMaps en la clase GeoMipMapsTRT, Geometrical Clipmaps en la clase GeometryClipmapsTRT. Finalmente, la técnica propuesta como resultado de este trabajo fue implementada en la clase TiledClipmapsTRT y es motivo de detalle de la siguiente subsección.

A continuación se describirán las responsabilidades de cada clase implementada junto con una descripción de los atributos y métodos destacables de cada una. Como en cualquier diseño en el paradigma de orientación a objetos, los atributos representan los datos que almacenan los objetos de la clase que son necesarios para brindar las funcionalidades ofrecidas a través de su interfaz de métodos.

Clase TerrainFramework

Responsabilidades - Mantiene la relación con el resto de las clases del framework, las crea, inicializa y asocia. - Ejecuta el hilo principal y la función que itera ciclo a ciclo para realizar tanto la actualización del estado del observador como el renderizado de la escena cuadro a cuadro.

Atributos destacables

Instancias de objetos de las clases que contiene.

Métodos principales

- Init: Inicializa el framework. Crea e inicializa las instancias que corresponden y las asocia. Recibe la ventana donde se mostrará el renderizado de la escena. - Release: Finaliza la ejecución y libera los recursos inicializados por el framework. - Run: Comienza la ejecución de la tarea principal del framework, ejecutando iterativamente la función cycle_func. - cycle_func: Esta función iterativa mide el tiempo transcurrido entre llamadas sucesivas. En primer lugar actualiza el estado del joystick que incide en el movimiento del observador. Luego hace evolucionar el movimiento del observador dando el intervalo de tiempo transcurrido, lo que actualiza la posición y actitud del observador. Por último, pide a la instancia del Renderer que renderize la escena.

Clase Terrain

Responsabilidades Representa el conjunto de datos que componen el modelo del terreno a representar. Está compuesto por un mapa de alturas y una textura para su superficie.




- extention_x: Longitud en el eje x de la superficie del terreno modelado (en metros) - extention_y: Longitud en el eje y de la superficie del terreno modelado (en metros) - Con estos valores y la cantidad de muestras del mapa de altura se obtiene la resolución máxima que define la distancia entre los puntos de la malla a utilizar.


Los métodos permiten consultar tanto los atributos como obtener referencias a los objetos que lo componen.

Clase HeightMap

Responsabilidades Administra las consultas al mapa de alturas utilizado para modelar el terreno.


- height_resolution: Resolución vertical para escalar los valores discretos contenidos en el mapa de alturas. - height_offset: Valor para desplazar todos los valores de alturas presentes en el mapa de alturas.


- getHeightsAtRegion: Permite obtener los valores de altura o elevación para una región del terreno dada. - getMapWidth, getMapWidth: Permite obtener la cantidad de muestras de cada lado del mapa de alturas.

Clase SurfaceTexture

Responsabilidades Contiene la información respecto a la textura utilizada para colorear la superficie del terreno.


-


-

Clase TerrainViewer

Responsabilidades Representa el conjunto de datos respecto de las características del observador que interesan para realizar el renderizado del terreno y de la escena.


- position: Posición del observador en el espacio del mundo. - at: Punto en el espacio que define la dirección de observación del observador. - up: Dirección que termina definiendo unívocamente la actitud del observador. - fov, aspect, near, far: valores que definen la proyección perspectiva que define el volumen de visualización percibido por el observador. Todos estos atributos permiten además definir las matrices de transformación (matriz de vista y proyección) necesarias para el renderizado de la escena.




- getViewMatrix: Método para consultar la matriz de vista. - getProjectionMatrix: Método para consultar la matriz de proyección. - getViewFrustum: Método para obtener los planos que definen el volumen de vista. Además posee los métodos necesarios para cambiar los valores de los atributos, que permiten evolucionar su ubicación (son utilizados por la clase ViewerMotion).

Clase ViewerMotion

Responsabilidades Modela la trayectoria de movimiento del observador. A partir de los valores de velocidad que permite 4 grados de libertad, modifica la ubicación del observador representado por la clase TerrainViewer.


- foward_vel: Velocidad de avance. Utilizado para avanzar la posición del observador según la dirección de observación. - yaw_vel, pitch_vel, roll_vel: Velocidades de rotación en los 3 grados de libertad de la actitud del observador.


- move: Método que a partir del valor de las velocidades y el intervalo de tiempo recibido calcula los valores diferenciales para evolucionar la ubicación del observador. - setFowardVel, setYawVel, setPitchVel, setRollVel: Modifican los valores de los atributos. Utilizados por el controlador que toma las entradas del usuario, en este caso, una instancia del JoystickListener.

Clase Renderer

Responsabilidades Se encarga del renderizado de la escena. Configura los valores iniciales del pipeline gráfico para la generación de cada cuadro.


Instancias necesarias para realizar el renderizado de cada cuadro.


- Render: Esta función inicializa el pipeline gráfico y renderiza la escena utilizando el renderizador del skybox y del terreno. - setSkyboxRenderer: Indica el renderizador del skybox o cielo a utilizar. - setTerrainRenderingTechnique: Indica la técnica a utilizar para renderizar el terreno.

Clase SkyboxRenderer

Responsabilidades Renderiza el skybox o cielo de la escena. Atributos

destacables -


-



Clase TerrainRenderingTechnique

Responsabilidades Clase abstracta que modela las tareas y datos comunes para renderizar un terreno.


- fx_file: Path del archivo de texto que define el efecto a utilizar para el renderizado. - effect: Instancia del efecto de Direct3D 10 cargado que define los datos y funciones que serán utilizados para configurar el pipeline gráfico para el renderizado del terreno. - technique: Instancia de la técnica de Direct3D 10 que define la configuración del pipeline a utilizar para el renderizado.


- TerrainRenderingTechnique: Constructor. Recibe el terreno, el observador y el archivo de efectos a utilizar. - Init: Realiza la inicialización de la técnica. Inicializa los parámetros comunes y genéricos, como la carga del archivo de efectos, y llama al método protegido _Init que es definido por las clases hijas para realizar la inicialización particular. - _Init: Método virtual puro que debe ser definido para realizar la inicialización particular de cada técnica concreta. - Release: Libera los recursos utilizados. - RenderTerrain: Realiza el renderizado del terreno. En esta clase, se implementan las configuraciones generales del pipeline como la técnica a utilizar y las matrices de transformación obtenidas de la instancia de TerrainViewer. Luego se llama al método protegido _RenderTerrain para las configuraciones particulares y ejecutar el renderizado concreto del terreno según la técnica adecuada. - _RenderTerrain: Método virtual puro que debe ser definido para realizar el renderizado del terreno.

Clase JoystickListener

Responsabilidades Controlador que administra la interacción del usuario con el joystick para interactuar con el sistema.


-


- Init: Inicializa la administración del joystick. - Release: Libera los recursos inicializados. - Update: Toma los eventos realizados por el usuario en el joystick y el estado de los controles analógicos para interactuar con las clases del sistema. Principalmente modifica las propiedades del movimiento del observador modeladas en la clase ViewerMotion.

Clase IWinWindow

Responsabilidades Modela una ventana de la interfaz gráfica del sistema operativo Windows.




-


- getWidth, getHeight: Métodos para obtener el alto y ancho en píxeles de la ventana utilizada para mostrar el renderizado del terreno. - close: Método utilizado para cerrar la ventana y terminar la aplicación.

Clase DXDevice

Responsabilidades Contiene el dispositivo y demás datos utilizados en Direct3D 10 para la interacción con el pipeline gráfico.


-


-

11.3.2 Implementación de la Técnica de Renderizado de Terrenos TiledClipmaps

A la hora de implementar la técnica presentada en el Capítulo 10, la clase principal que lo hace es llamada TiledClipmaps, dando así un nombre a la técnica introducida. Esta clase concentra la lógica de la técnica, aunque delega algunas responsabilidades a las clases que representan los parches y los bloques, TerrainPatch y TerrainTile respectivamente. Además, la administración de la memoria de video utilizada para el renderizado de bloques refinados concierne a la clase RefinedTilesElevationData-Manager. La Figura 11.3 detalla en UML las clases utilizadas para la implementación concreta de esta parte del framework. A continuación se describirán las principales responsabilidades de las clases mencionadas, detallando la distribución de las tareas entre ellas.

La clase TerrainPatch modela el parche que representa una región de terreno alrededor de la posición del observador con un nivel de detalle particular. Existen tantas instancias de esta clase como niveles de detalle se utilicen para representar el terreno. Cada instancia de esta clase administra las actualizaciones de las elevaciones del mapa de alturas en la capa del arreglo de texturas que le corresponde. Para esto, tiene en cuenta la posición del observador y las dimensiones del parche, los bloques y el margen utilizado como caché. En otras palabras, implementa la actualización incremental de la información de alturas utilizando la estrategia de direccionamiento toroidal. Además, se encarga de crear y liberar las instancias necesarias de los bloques que lo componen (modelados con la clase TerrainTile) a medida que el observador se desplaza.

Por su parte, la clase TerrainTile modela cada bloque y concentra la responsabilidad de analizar el error de aproximación que se percibe al utilizar el nivel de detalle del parche al que pertenece. En la creación o construcción de una instancia de esta clase, se consulta los errores de modelado inherentes a los niveles de detalle con los que el bloque puede ser representado. La clase LODErrorQueryManager en la etapa de carga del sistema almacena el archivo de errores en memoria principal y luego resuelve las consultas referentes al error de modelado de los bloques.



Además, en la creación, dada la superficie 2D del bloque, se consulta el valor máximo y mínimo de altura en ese bloque para definir el AABB del bloque para ser luego contrastado con el volumen de visualización al aplicar frustum culling. De manera idéntica a los errores de modelado, un preproceso calcula las alturas máximas y mínimas de cada bloque y los almacena en un archivo. Luego, en tiempo de carga del sistema, la clase MinMaxZQueryManager dispone los datos en memoria principal para resolver las consultas pertinentes. Por otro lado, cada instancia, dada la posición del observador, los parámetros de la visualización y el valor umbral definido, decide si el nivel de detalle es suficiente o es necesario refinar la malla del bloque. Para esto calcula la mínima distancia del observador al AABB, y realiza los cálculos descriptos en la Sección 5.1. Entonces, si es necesario representar el bloque con mayor detalle, pide a la instancia de RefinedTilesElevationDataManager la carga de los datos de elevación pertinentes a memoria de video (quien los carga si no se encuentran ya cargados), para que se encuentren disponibles para cuando, a continuación, se renderice este bloque refinado.

Figura 11.3 – Clases diseñadas para implementar la técnica desarrollada.

Por último, la clase principal de este grupo, la clase TiledClipmapsTRT, implementa el algoritmo de renderizado descrito en alto nivel en la Sección 10.4. Se excluye la actualización de cada parche que es delegado a cada instancia de TerrainPatch tras calcular la posición central de cada uno a partir de la posición del observador y el centro de cada parche de menor detalle, administrando las posiciones relativas entre los parches sucesivos.



Recapitulando, tras tomar los bloques que corresponden al área de renderizado de cada parche, se verifica si se encuentran dentro del volumen visualizado. Luego, se le pasa a la instancia de cada bloque que pasa el testeo anterior la información necesaria para que decida si debe ser refinado o no. A continuación se disponen los bloques según si deben ser refinados o no, y si son refinados separados por nivel de refinamiento necesario. Finalmente, se completan los vertex buffer dinámicos con la información de cada instancia a renderizar, y se renderiza (mediante la técnica de instancing) el terreno utilizando una llamada a Draw para todos aquellos bloques que no necesitan refinamiento, y luego una llamada a Draw para cada nivel de refinamiento que agrupa los bloques refinados necesarios. Experimentalmente, en general no se utilizan más de dos niveles de refinamiento, por ende se renderiza el terreno completamente utilizando 3 llamadas al método Draw.

11.3.3 El Efecto Utilizado

Los programas de vértices y píxeles utilizados, junto con las configuraciones del pipeline, se encuentran descriptos en un archivo de efecto, “tiledclipmapstrt.fx”, que es cargado por la aplicación.

//------------------------------------------------- ------------------ // Buffers de Constantes //------------------------------------------------- ------------------ /// cb0: Buffer de constantes que es actualizado ca da cuadro. /// > World: Matriz que define la transformació n del mundo a /// aplicar a los vértices. /// > View: Matriz que define la transformación de vista a /// aplicar a los vértices. /// > Projection: Matriz que define la transfor mación de /// proyección a aplicar a los vértices. cbuffer cb0 { matrix World; matrix View; matrix Projection; } /// cb1: Buffer de constantes que es inicializado c on información /// necesaria para el renderizado. /// No necesita actualizaciones /// > SurfaceResolution: intervalo de muestreo de los puntos de /// la superficie del terreno. /// > WorldWidth: Extensión del terreno en X. /// > WorldHeight: Extensión del terreno en Y. /// > FullPatchSize: Tamaño del parche. /// > height_resolution: Resolución vertical. /// > skirt_height: Altura vertical de la polle ra de los bloques. cbuffer cb1 { float SurfaceResolution; float WorldWidth; float WorldHeight; uint FullPatchSize; float height_resolution; float skirt_height; } Tabla 11.1- Archivo de efecto: Buffers de constantes utilizados.



//------------------------------------------------- ------------------ // Texturas cargadas //------------------------------------------------- ------------------ /// HeightMapTexture: Array de texturas utilizado p ara almacenar /// en cada capa la información de elevación para c ada parche Texture2DArray < float > HeightMapTexture; /// RefinedTilesTextureArray: Array de texturas uti lizado para /// almacenar en cada capa la información de elevac ión de bloques /// de un nivel dado de refinamiento. Texture2DArray < float > RefinedTilesTextureArray; /// SurfaceTexture: Textura utilizada para colorear la superficie /// del terreno. Texture2D SurfaceTexture;

Tabla 11.2- Archivo de efecto: Texturas referenciadas.

En su comienzo el archivo describe las texturas y los buffers de constantes que va a utilizar. El efecto utiliza tres puntos de referencia a texturas que necesitará (Tabla 11.2). Asimismo se agrupan las constantes a utilizar en el efecto en dos grupos. Por un lado, aquellas que se cargan inicialmente y no se modifican en tiempo de ejecución y, por el otro, las matrices de transformaciones que son actualizadas cuadro a cuadro (Tabla 11.1).

//------------------------------------------------- ------------------ // Estructuras de datos utilizadas en los shaders //------------------------------------------------- ------------------ ///------------------------------------------------ ------------------ /// VS_INPUT: Estructura de datos que define los at ributos de entrada /// a los Vertex Shaders /// > u_offset: offset respecto al vértice de refe rencia del parche. /// > v_offset: offset respecto al vértice de refe rencia del parche. /// > is_skirt: indica si el vértice corresponde a la parte inferior /// de la pollera de un bloque /// > patch_texture_reference_position_u: coordena da del vértice de /// referencia para el muestreo /// de la altura. /// > patch_texture_reference_position_v: coordena da del vértice de /// referencia para el muestreo /// de la altura. /// > world_reference_position_x: posicion en el m undo del vértice /// de referencia. /// > world_reference_position_y: posicion en el m undo del vértice /// de referencia. /// > patch_level: nivel de detalle del parche al que pertenece el /// vértice. struct VS_INPUT { int u_offset : OFFSET_U; int v_offset : OFFSET_V; float is_skirt : IS_SKIRT_VERTEX; uint patch_texture_reference_position_u:PATCH_TEXT_REFE RENCE_POS_U; uint patch_texture_reference_position_v:PATCH_TEXT_REFE RENCE_POS_V; float world_reference_position_x : WORLD_REFERENCE_POS_X ; float world_reference_position_y : WORLD_REFERENCE_POS_Y ; uint patch_level : PATCH_LEVEL; };



///------------------------------------------------ ------------------ /// VS_INPUT_REFINED_VERTEX: Estructura de datos qu e define los /// atributos de entrada a los Vertex S haders /// > u_sample: coordenada para obtener el valor d e elevacion del /// vértice de la textura correspondient e. /// > v_sample: coordenada para obtener el valor d e elevacion del /// vértice de la textura correspondiente. /// > is_skirt: indica si el vértice corresponde a la parte inferior /// de la pollera de un bloque /// > world_reference_position_x: posicion en el m undo del vértice /// de referencia. /// > world_reference_position_y: posicion en el m undo del vértice /// de referencia. /// > patch_level: nivel de detalle del bloque al que pertenece el /// vértice. /// > texture_layer: layer para muestrear en el ar ray de texturas /// con datos de los bloques refi nados. struct VS_INPUT_REFINED_VERTEX { int u_sample : SAMPLE_U, int v_sample : SAMPLE_V, float is_skirt : IS_SKIRT_VERTEX, float world_reference_position_x : WORLD_REFERENCE_POS_X , float world_reference_position_y : WORLD_REFERENCE_POS_Y , uint patch_level : PATCH_LEVEL, uint texture_layer : TEXTURE_ARRAY_LAYER }; ///------------------------------------------------ ------------------ /// VS_OUTPUT: Estructura de datos que define los a tributos de salida /// de los Vertex Shaders. /// > Pos: posicion transformada del vértice en co ordenadas /// homogéneas. /// > TextCoord: coordenadas de textura para obten er el color de /// sombreado de la superficie para e se vértice. struct VS_OUTPUT { float4 Pos : SV_POSITION; float2 TextCoord : TEXCOORD0; };

Tabla 11.3- Archivo de efecto: Estructuras de datos utilizadas por los shaders.

Luego, en el archivo se describen las estructuras de datos que agrupan la información utilizadas como entradas a los programas de vértices, y la estructura de datos que se origina como resultado del procesamiento de cada vértice (Tabla 11.3).

A continuación, el archivo contiene el código a ejecutar por los programas de vértices y de fragmentos que se utilizan. En la Tabla 11.4, la Tabla 11.5 y la Tabla 11.6, se muestran respectivamente el programa de vértice para los vértices de bloques no refinados, el vertex shader para los vértices de los bloques refinados, y el programa de fragmentos utilizado en todos los casos para aplicar la textura a la superficie del terreno.

Al final, el archivo posee directivas de compilación de los programas utilizados y descriptos anteriormente (Tabla 11.7). La compilación de estos programas se realiza cuando se carga el archivo y el correspondiente efecto. Y por último, se describe en el archivo la técnica de renderizado con sus correspondientes pasadas (Tabla 11.8). Como fue introducido, la



técnica, a través de las pasadas, describe la configuración del pipeline que debe aplicarse en el momento de dibujar la geometría que se ingrese. Se describen dos pasadas, que se diferencian en el programa de vértices utilizado.

//------------------------------------------------- ------------------ // Vertex Shader //------------------------------------------------- ------------------ VS_OUTPUT VS( VS_INPUT input ) { VS_OUTPUT output = ( VS_OUTPUT)0; // se obtienen las coordenadas para obtener la altu ra del // parche correspondiente uint u_sample = ( int (input.patch_texture_reference_position_u) + input.u_offset + int (FullPatchSize) ) % FullPatchSize; uint v_sample = ( int (input.patch_texture_reference_position_v) + input.v_offset + int (FullPatchSize) ) % FullPatchSize ; // se calcula la posicion XY en el mundo del vértic e float pos_x = input.world_reference_position_x + pow(2.0f, float (input.patch_level)) * float (input.u_offset) * SurfaceResolution; float pos_y = input.world_reference_position_y + pow(2.0f, float (input.patch_level)) * float (input.v_offset) * SurfaceResolution; // tomo la altura del mapa de elevacion del layer q ue // corresponde al nivel de detalle uint z0 = HeightMapTexture.Load( int4( u_sample, v_sample, input.patch_level, 0 ) ); // si es un vértice de la pollera modifico la a ltura float z = z0 - input.is_skirt * skirt_height; // escalo la altura del vértice con la resolución v ertical float vertex_height = height_resolution * z; // aplico las transformaciones al vértice output.Pos = mul ( float4 (pos_x,pos_y,vertex_height,1.0f) , World); output.Pos = mul ( output.Pos, View ); output.Pos = mul ( output.Pos, Projection ); // calculo las coordenadas de texturas para luego o btener el // color del vértice output.TextCoord = float2 (pos_x /WorldWidth, pos_y /WorldHeight); return output; }

Tabla 11.4- Archivo de efecto: programa para los vértices de bloques no refinados.



//------------------------------------------------- ------------------ // Vertex Shader para Refined Tiles //------------------------------------------------- ------------------ VS_OUTPUT RefinedTileVS( VS_INPUT_REFINED_VERTEX input ) { VS_OUTPUT output = ( VS_OUTPUT)0; // se calcula la posicion XY en el mundo del vértic e float pos_x = input.world_reference_position_x + pow(2.0f, float (input.patch_level)) * float (input.u_sample) * SurfaceResolution; float pos_y = input.world_reference_position_y + pow(2.0f, float (input.patch_level)) * float (input.v_sample) * SurfaceResolution; // tomo la altura del mapa de elevacion del lay er que // corresponde al bloque refinado al que pertenece el vertice uint z0 = RefinedTilesTextureArray.Load( int4( in put.u_sample, input.v_sample, input.texture_layer, 0 ) ); // si es un vértice de la pollera modifico la a ltura float z = z0 - input.is_skirt * skirt_height; // escalo la altura del vértice con la resolución v ertical float vertex_height = height_resolution * z; // aplico las transformaciones al vértice output.Pos = mul ( float4 (pos_x,pos_y,vertex_height,1.0f) , World); output.Pos = mul ( output.Pos, View ); output.Pos = mul ( output.Pos, Projection ); // calculo las coordenadas de texturas para lue go obtener el // color del vértice output.TextCoord = float2 (pos_x /WorldWidth, pos_y /WorldHeight); return output; }

Tabla 11.5- Archivo de efecto: programa para los vértices de bloques refinados.

//------------------------------------------------- ------------------ // Pixel Shader //------------------------------------------------- ------------------ float4 PS( VS_OUTPUT input ) : SV_Target { // se obtiene el color del fragmento muestreando la textura de la // superficie del terreno. return SurfaceTexture.Sample(TextureSampler,input.TextCoo rd); }

Tabla 11.6- Archivo de efecto: programa para los colorear los fragmentos.



//------------------------------------------------- ------------------ // Directivas de compilación de los programas de vé rtices y // fragmentos utilizados //------------------------------------------------- ------------------ VertexShader vs = CompileShader( vs_4_0 , VS() ); VertexShader vs_refined_tiles= CompileShader( vs_4_0 ,RefinedTileVS()); PixelShader ps = CompileShader( ps_4_0 , PS() );

Tabla 11.7- Archivo de efecto: directivas para compilar los shaders.

//------------------------------------------------- ------------------ // Técnica utilizada para el renderizado de terreno s. Configuración // del pipeline gráfico //------------------------------------------------- ------------------ technique10 RenderTerrain { /// P0: Pasada utilizada para renderizar los Bloque s NO Refinados pass P0 { SetRasterizerState( rsSolidframe ); SetDepthStencilState( depthState, 0 ); SetVertexShader( vs ); SetGeometryShader( NULL ); SetPixelShader( ps ); } /// P1: Pasada utilizada para renderizar los Bloque s Refinados pass P1 { SetRasterizerState( rsSolidframe ); SetDepthStencilState( depthState, 0 ); SetVertexShader( vs_refined_tiles ); SetGeometryShader( NULL ); SetPixelShader( ps ); } }

Tabla 11.8- Archivo de efecto: descripción de la técnica y pasadas que se utilizan.

11.3.4 Algoritmos Auxiliares a la Solución

Por último, cabe describir los procedimientos auxiliares que se utilizan offline, previo a la carga y ejecución del sistema descripto. Los algoritmos se ejecutan para que, dado un terreno, se calculen y dispongan en un archivo los datos auxiliares que se necesitan precalculados en tiempo de ejecución del framework. Uno de estos procedimientos es aquel que calcula el error de aproximación o modelado al utilizar bloques de resoluciones menores a la máxima disponible. El otro, es el que calcula el valor de altura máximo y mínimo de cada bloque, utilizado para armar el AABB de cada bloque sin tener que inspeccionar todas las alturas involucradas en cada uno en tiempo de ejecución. Los algoritmos constan de algunas iteraciones sobre el mapa de alturas completo calculando las cuestiones de interés descriptas dividiendo el conjunto de datos en los bloques y resoluciones a utilizar en la ejecución.



De los dos algoritmos, es de interés describir el que calcula el error de modelado para cada bloque en cada nivel de detalle. El error de modelado se calcula de manera absoluta y exacta utilizando los valores discretos que contiene el mapa de alturas, como es propuesto en [Hoppe 1998]. Recapitulando lo presentado en la Sección 10.3, el cálculo del error de un nivel de detalle debe hacerse sobre todos aquellos vértices presentes en la máxima resolución que son omitidos en el nivel de detalle en cuestión.

El algoritmo que calcula el error de modelado, recorre el mapa de alturas tomando bloques de m x m, para cada nivel de detalle a utilizar. Luego, para cada bloque, toma cada uno de los triángulos que definen su superficie y se calcula la diferencia de altura en los vértices omitidos. Siguiendo el ejemplo mostrado en la Figura 11.4, se toma el triángulo de nivel 2, con intervalo de muestreo de 4 vértices, definido por los vértices V(0,0), V(4,0) y V(0,4). Dado el triángulo, se calcula la ecuación del plano a partir de los vértices mencionados. Luego, para cada vértice omitido, V(i,j), se ingresan los valores (i, j) en la ecuación del plano y se obtiene el valor de altura con el que se aproxima. Finalmente, se calcula la diferencia con su altura original y se almacena la mayor diferencia para cada bloque.

NVVVVr

=−×− )()( )0,0()4,0()0,0()0,4(

0)0,0(),( =•+• VNVN ji

rr

Figura 11.4 – Cálculo del error de modelado. Utilizando los vértices presentes en un determinado niveles de detalle (en blanco), se calcula el error de aproximación sobre los vértices omitidos (en gris). En primer lugar se obtiene la ecuación del plano que define la superficie del triángulo, calculando la normal al plano (Ecuación a). Luego, dada las coordenadas 2D (relativas al triángulo en cuestión), (i,j), de los vértices omitidos, se obtiene la altura con la que son aproximados (Ecuación b).


Resultados Obtenidos 93

12 Resultados Obtenidos

Figura 12.1 – Resultado del renderizado del terreno en un vuelo sobre el terreno “Puget Sound”.

La implementación de la técnica presentada fue probada mediante algunos experimentos y los resultados obtenidos se exponen en este capítulo.

La mayoría de los trabajos en el tema utilizan un terreno de referencia para mostrar y comparar sus resultados. Este conjunto de datos bien conocido es llamado “Puget Sound area”. El mismo esta compuesto por una grilla regular de 16.385 x 16.385 puntos con un intervalo de muestreo de 10 metros, cubriendo por lo tanto una superficie de 163,85 Km. x 163,85 Km. El tamaño de la superficie es adecuado para aplicaciones como simuladores de vuelo. Los valores de altura de cada punto son codificados utilizando 16 bits (65536 valores discretos posibles) con una resolución vertical de 0,1 metro. Este conjunto de datos se dispone en un archivo de imagen PNG de un canal de 16 bits.

La ejecución de la implementación fue realizada en una PC, sobre sistema operativo Windows 7, con 2.8 GHz Intel® Core™2 Quad, 4 GB de memoria principal y una tarjeta de video Nvidia GeForce GTX 280 con 2GB de memoria de video.

El framework fue configurado para correr en una ventana fullscreen con una resolución de 1920 x 1080 píxeles. El campo de vista horizontal del observador utilizado es de 90 grados. La elección del valor umbral para los errores proyectados fue de 5 píxeles (0,5% de la resolución vertical). De esta manera, se obtuvo una perfomance promedio de 120 cuadros por segundo, lo que implica un promedio de 8 milisegundos para la generación de cada cuadro. Por otro lado, cuando el observador vuela cercano a zonas de detalles de alta frecuencia, el rendimiento promedio cae a unos 50 cuadros por segundo. Debido a la carga de datos necesaria para representar bloques refinados, algunos cuadros pueden llegar a requerir unos 40 milisegundos para su generación. La Figura 12.1 muestra una captura de pantalla mostrando la visualización obtenida sobre el terreno mencionado.


94 Resultados Obtenidos

La Tabla 12.1 y Figura 12.2 resumen los resultados obtenidos tras ejecutar cinco corridas en las condiciones especificadas. Los cinco experimentos consistieron en un vuelo sobre el terreno a una velocidad de 340 metros por segundo, típicamente desde el centro del terreno hacia la zona de la montaña bien detallada. Se midió el tiempo insumido en la generación de cada cuadro durante un vuelo de entre dos y tres minutos. Como puede verse en la Figura 12.2 el 70% de los tiempos medidos se encuentran en el intervalo entre 5 y 15 milisegundos (44,35% en el intervalo 5–10 ms., y 25.44% en el intervalo 10–15 ms.). Por último, el tiempo máximo registrado fue de 49,5 ms.

Run 1 Run 2 Run 3 Run 4 Run 5

Tiempo de Vuelo 132 seg. 189 seg. 180 seg. 166 seg. 140 seg. Cuadros Totales 10960 15545 13564 13118 12575 Max. Frame Time 49.5 ms. 44.1 ms. 40.7 ms. 41.5 ms. 36.0 ms. Frame Time in 5-10 ms 49.91% 43.94% 37.14% 41.31% 49.46% Frame Time in 10-15 ms 24.80% 14.91% 31.21% 27.19% 29.11%

Tabla 12.1- Resultados de las cinco corridas ejecutadas.

Frame Time Distribution

15470178 2718 1108 970 259 85 140 31068301652 2318 2047 1355 873 318 139 130503838 4234 2448 724 620 346 113 30541930 3567 2687 756 359 233 63 400621930 3661 2121 365 171 7 1

0 - 5 5 -10 10 -15 15 - 20 20 - 25 25 - 30 30 - 35 35 - 40 40 - 45 45 - 50

Intervals [ms]

Run1 Run2 Run3 Run4 Run5

Figura 12.2- Distribución de las mediciones de los tiempos de generación de cada cuadro en las cinco corridas ejecutadas.

Finalmente, puede notarse que el tiempo promedio de generación de un cuadro, que requiere esta técnica de renderizado de terrenos, permite que la misma sea incorporada en un motor gráfico. Como era uno de los


Resultados Obtenidos 95

objetivos, el tiempo insumido en la generación del renderizado del terreno, da lugar a las demás actividades que debe realizar el motor gráfico y la aplicación que lo utilice. La tarea de renderizado del terreno deja tiempo libre para ser utilizado por otras tareas de renderizado y procesamiento necesarias para la generación de cada cuadro. Por último, el consumo de procesamiento de CPU permite que las aplicaciones que utilicen la técnica propuesta mantengan rendimientos adecuados a sus requerimientos interactivos.


Conclusiones 97

13 Conclusiones

Como resultado de este trabajo se ha propuesto una solución que resuelve el problema de visualización de grandes extensiones de terrenos, un tema importante y popular en el área de la computación gráfica. En la primera parte de este trabajo se han expuesto los conceptos generales del tema de interés. A continuación, fueron citados y explicados los trabajos más relevantes en el área que, en primer lugar, sentaron las bases de las soluciones relacionadas y, luego, corresponden al estado del arte.

El trabajo desarrollado no deja de lado las características actuales del hardware donde se ejecuta la implementación resultante. Es por eso que se realiza una breve exposición de la evolución del hardware gráfico, y luego se hace hincapié en las características de las tarjetas gráficas o GPUs programables de la actualidad.

Las GPUs actuales responden al modelo llamado Shader Model 4.0. Dentro de las nuevas características introducidas se destaca una nueva etapa llamada Geometry Shader. Tras estudiar la funcionalidad brindada por esta etapa, y analizar el rendimiento obtenido al utilizarla, se concluye que la misma no es útil para el renderizado de terrenos. El uso de esta etapa degrada el rendimiento general de una técnica. Sin embargo, sí se encontraron útiles otras características, como la unificación de las unidades de procesamiento y la posibilidad de utilizar arreglos de texturas en combinación con la técnica de instanciación.

Por otro lado, la solución desarrollada brinda una técnica de renderizado de terrenos apta para aplicaciones interactivas o tiempo real, como ser videojuegos o simuladores de vuelo. Con mayor precisión, la técnica apunta a ser utilizada en simuladores de vuelo, donde los requerimientos son más estrictos. La visualización producida debe representar fielmente terrenos del mundo real logrando una inmersión total del usuario dentro del simulador. Por ende, la técnica propuesta no muestra distorsiones ni artefactos, brindando una representación visualmente exacta del terreno.

La principal contribución de esta tesis es la presentación de una técnica que combina aspectos de las técnicas que pertenecen al estado del arte para brindar una solución sencilla y con un buen rendimiento. La técnica presentada está basada en Geometry Clipmaps, que expone ideas y algoritmos que optimizan el procesamiento requerido obteniendo una alta performance. Más aún, la técnica presentada resuelve la limitación que presenta Geometry Clipmaps para representar superficies con detalles de alta frecuencia sin introducir cambios en la superficie que sean notorios al usuario. Para esto, se opta por incorporar el análisis de la proyección del error de aproximación propio de las representaciones que utilizan nivel de detalle. La estrategia consiste en mantener acotado el error percibido por debajo de un valor que pueda considerarse despreciable. Para lograrlo, el análisis del error es realizado tras dividir las regiones del terreno en bloques, lo que es propuesto en las técnicas basadas en bloques, como Geometrical MipMaps.

Finalmente, la técnica es implementada utilizando software y hardware actuales, aprovechando las novedades útiles para optimizar la performance. Los resultados de los experimentos muestran un buen rendimiento de la técnica presentada. El poco tiempo de procesamiento de CPU y GPU que


98 Conclusiones

consume, permite que la técnica sea incorporada en un motor gráfico a ser utilizado para el desarrollo de aplicaciones interactivas.

13.1 Trabajos Futuros

La técnica presentada sólo aborda el trabajo sobre el modelado del terreno para lograr un renderizado que obtenga un buen rendimiento. La superficie del terreno es coloreada simplemente usando una textura disponible.

Esta técnica puede ser complementada de manera de producir visualizaciones más ricas y permitir la representación de mayores extensiones de terrenos, virtualmente sin límites de tamaño. Temas generalmente ortogonales a la solución dada al modelado del terreno que pueden ser abordados en un futuro son:

• Texturado de la Superficie. Puede trabajarse sobre una técnica para aplicar nivel de detalle a la textura utilizada para colorear la superficie. Como primera aproximación, podría utilizarse la misma estrategia utilizada con el mapa de alturas.

• Iluminación. El coloreado de la superficie puede ser enriquecido incorporando luces en el ambiente representado. Para lograr esto podría incorporarse el manejo de un mapa de iluminación para mejorar el coloreado de la superficie. Otra posibilidad es utilizar un mapa de normales que ayude al cálculo del color permitiendo el movimiento dinámico de las luces del ambiente.

• Terrenos más extensos. Para contribuir a la representación de mayores cantidades de datos pueden analizarse dos aspectos. Por un lado, si la cantidad de datos excede la capacidad de la memoria principal del sistema, desarrollar una política de carga de datos del disco a memoria principal, de manera que se encuentren disponibles para cargarlos en memoria de video. Algunos trabajos proponen aprovechar las funcionalidades del sistema operativo, utilizando la posibilidad de mapear un archivo en memoria principal [Lindstrom and Pascucci 2001] [Lindstrom and Pascucci 2002]. Por otro lado, los datos pueden ser comprimidos. Con mecanismos de compresión que permitan el acceso a regiones de interés, pueden obtenerse del archivo en disco los datos necesarios para ser luego cargados en memoria de video [Lossaso and Hoppe 2004]. Más aún, puede desarrollarse una técnica donde la descompresión de los datos ocurra en la misma GPU.


Referencias 99

Referencias

[Akenine-Möller et al. 2008] Akenine-Möller, T., Haines, E., and Hoffman, N.: “Real-time rendering”. 3rd edition, A.K.Peters Ltd., 1045p, 2008.

[Asirvatham and Hoppe 2005] Asirvatham, A., and Hoppe, H.: “Terrain Rendering Using GPU-based Geometry Clipmaps”, GPU Gems 2, pp. 27–46, 2005.

[Blythe 2006] Blythe, D.: “The Direct3D 10 system”. ACM SIGGRAPH 2006, Papers on SIGGRAPH ’06, ACM Press, 2006.

[Clasen and Hege 2006] Clasen, M., and Hege, H.: “Terrain Rendering Using Spherical Clipmaps”. Eurographics - EuroVis, 2006.

[de Boer 2000] De Boer, W.H.: “Fast Terrain Rendering Using Geometrical Mipmapping”. Unpublished Paper, Available at http://www.flipcode.com/ articles/article_geomipmaps.pdf, 2000.

[Duchaineau et al. 1997] Duchaineau, M., Wolinsky, M., Sigeti, D.E., Miller, M.C., Aldrich, C., and Mineev-Weinstein, M.B.: “ROAMing terrain: Real- time optimally adapting meshes”. Proceedings IEEE Visualization, pp. 81–88, 1997.

[Engel et al. 2008] Engel, W., Hoxley, J., Kornmann, R., Suni, N., and Zink, J.: “Programing Vertex, Geometry, and Pixel Shaders”. Charles River Media, 2nd edition, 2008.

[Gerasimov et al. 2004] Gerasimov, P., Fernando, R., and Green, S.: “Shader Model 3.0: Using Vertex Textures”. NVIDIA Corporation – Whitepaper, 2004.

[Fernando and Kilgard 2003] Fernando, R., and Kilgard, M.: “The Cg Tutorial: The Definitive Guide To Programmable Real-Time Graphics”. Addison-Wesley, 2003.

[Hoppe 1996] Hoppe, H.: “Progressive Meshes”. Computer Graphics, SIGGRAPH ’96 proceedings, pp. 99-108, 1996.

[Hoppe 1997] Hoppe, H.: “View-dependent refinement of progressive meshes”. Computer Graphics, SIGGRAPH ’97 proceedings, pp. 189-198, 1997.

[Hoppe 1998] Hoppe, H.: “Smooth view-dependent level-of-detail control and its application to terrain rendering”. Proceedings IEEE Visualization, Computer Society Press, pp. 35–42, 1998.

[Kilgariff and Fernando 2005] Kilgariff, E., and Fernando, R.: “The GeForce 6 series GPU architecture”. ACM SIGGRAPH 2005 Courses on - SIGGRAPH ’05, 2005.

[Kobbelt 1996] Kobbelt, L.: “Interpolatory subdivision on open quadrilateral nets with arbitrary topology”. Eurographics 1996, 409-420, 1996.

[Larsen and Christensen 2003] Larsen, BD, and Christensen, NJ: “Real-time terrain rendering using smooth hardware optimized level of detail”. Journal of WSCG. 2003;11(2):282–9.


100 Referencias

[Luebke et al. 2003] Luebke, D., Reddy, M., Cohen, J.D., Varshney, A., Watson, B., and Huebner, R.: “Level of Detail for 3D Graphics”. Morgan Kaufmann Publishers, 2003.

[Luebke and Humphreys 2007] Luebke, D., and Humphreys, G.: “How GPUs Work”. Computer. 2007;40(2):96-100.

[Lindholm et al. 2001] Lindholm, E., Kligard, M., and Moreton, H.: “A user-programmable vertex engine.” Proceedings of the 28th annual conference on Computer graphics and interactive techniques - SIGGRAPH ’01 (2001): 149-158.

[Lindstrom et al. 1996] Lindstrom, P., Koller, D., Ribarsky, W., Hodges, L.F., Faust, N., and Turner, G.A.: “Real-time, continuous level of detail rendering of height fields”. Proceedings ACM SIGGRAPH, ACM SIGGRAPH 1996, pp. 109–118, 1996.

[Lindstrom and Pascucci 2001] Lindstrom, P., and Pascucci, V.: “Visualization of Large Terrains Made Easy”. IEEE Visualization 2001 Proceedings, 363-370, 2001.

[Lindstrom and Pascucci 2002] Lindstrom, P., and Pascucci, V.: “Terrain Simplification Simplified : A General Framework for Out-of-Core Visualization”. IEEE Transactions on Visualization and Computer Graphics, 8, 239-254, 2002.

[Lossaso and Hoppe 2004] Losasso, F., and Hoppe, H.: “Geometry Clipmaps: Terrain Rendering Using Nested Regular Grids”. ACM SIGGRAPH 2004 Papers, pp. 769–776, 2004.

[Malvar 2000] Malvar, H.: “Fast Progressive Image Coding without Wavelets”. Data Compression Conference (DCC '00), 243-252, 2000.

[NVidia 2008] NVidia: “GPU Programming Guide GeForce 8 and 9 Series”. 2008.

[OpenGL 1997] OpenGL Architecture Review Board, Woo, M., Neider, J., and Davis, T.: “OpenGL Programming Guide: The Official Guide to Learning Opengl, Version 1.1”, 2nd Edition, Addison-Wesley Pub, 650p, 1997.

[Patidar et al. 2006] Patidar, S., Bhattacharjee, S., Singh, J.M., and Narayanan, P.: “Exploiting the shader model 4.0 architecture”. Technical Report, Center for Visual Information Technology, IIIT Hyderabad, 2006.

[Pajarola and Gobbetti 2007] Pajarola, R., and Gobbetti, E.: “Survey of Semi-regular Multiresolution Models for Interactive Terrain Rendering”. The Visual Computer nº23, 583-605, 2007.

[Snook 2001] Snook, G: “Simplified Terrain using Interlocking Tiles”. Game Programming Gems 2, Charles River Media, Inc., 377-383, 2001.

[Ulrich 2002] Ulrich, T.: “Rendering Massive Terrains Using Chunked Level of Detail Control”, SIGGRAPH ‘02 Course Notes, 2002.

[Wagner 2004] Wagner, D.: “Terrain Geomorphing in the Vertex Shader”, ShaderX2, Shader Programming Tips and Tricks with DirectX 9, Wordware Publishing, 2004.

[Williams 1983] Williams, L.: “Pyramidal Parametrics”, SIGGRAPH 83, pp. 1-11, 1983.


Publicaciones 101

Publicaciones

Guaycochea, L., and Abbate, H.: “Error-Bounded Terrain Rendering Approach based on Geometry Clipmaps”, CACIC 2011, XVII Congreso Argentino de Ciencias de la Computación, 2011.

Documents

Visualización de Terrenos con Tarjetas de Video ...materias.fi.uba.ar/7500/Guaycochea.pdf · tarjetas de video o GPU que responden ... En las últimas dos décadas las aplicaciones