Guaycochea PDF

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
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.
I
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)
III
Í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
V
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
VI
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.
Introducción 1
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
2 Introducción
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.
Introducción 3
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
Modelado de Terrenos 5
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.
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.
Modelado de Terrenos 7
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.
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.
El Pipeline Gráfico 9
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.
Coordenadas del Objeto Coordenadas en el mundo
z  m11 m12 m13 m14  instancia 1 instancia 2

m del cubo
m22 m23 m24  del cubo
MatrizMundoi =  21
m31 m32 m33 m34  z
 
m41 m42 m43 m44 
( 0 , 0 , 0 )obj
( -3 , 10 , 5 )mundo y x
instancia 3
del cubo
modelo del cubo
v11 v12 v13 v14 
y x v v 22 v23 v24 
MatrizVist a = 
21
v31 v32 v33 v34  cámara

 
Coordenadas
v 41 v 42 v43 v44 
canónicas
 p11 p12 p13 p14 
volumen canónico p p 22 p 23 p 24  Coordenadas relativas
( -1, -1, -1)
Matriz Pr oyección = 
21
a la cámara
 p31 p32 p33 p34 
 
 p 41 p 42 p 43 p 44 
(1,1,1)
( 1 , 10 , -2 )vista
volumen de y z
visualización
x
plano de
proyección
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.
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.
Renderizado de Terrenos 15
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.
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.
Renderizado de Terrenos 17
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.
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.
Terrenos con Nivel de Detalle 19

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: n x n , n x n , etc. (Figura 5.2). A partir de la
2 2 4 4
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.

w
f
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 wscreen y alto
hscreen (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.
s x world s
= ⇒ x world = n (1)
d n d
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 wworld y alto hworld (2).
wworld
tg (γ ) = 2 w = 2n tan(γ )
2  world 2
n ⇒ wworld (2)
aspect =
wscreen  hworld =
hscren  aspect

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 x screen en píxeles.
Se calculan, entonces, dos casos, xscreenh asumiendo que el segmento se
encuentra horizontal, y x screenv asumiendo que el segmento se encuentra
vertical (3).
x world s
x screenh = wscreen ⇒ x screenh = wscreen
wworld 2d tan(γ )
2
(3)
x world s.aspect
x screenv = hscreen ⇒ x screenv = hscreen
hworld γ
2d tan( )
2
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.
Π
x s
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.

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
Primeros Trabajos en Nivel de Detalle 29

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 x res e y res . Se utilizan bloques cuadrados de tamaño fijo de 2 n + 1
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 2 m + n x res x 2 m + n y res , 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:
B+C
ε = abs ( D − ) . Si la proyección del error de modelado ε no excede el
2
valor umbral seleccionado, entonces la simplificación puede concretarse.
B
D
ε
A C
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.

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.
Evolución del Hardware Gráfico: El Pipeline Gráfico Programable 37

• 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
38 Evolución del Hardware Gráfico: El Pipeline Gráfico Programable

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.
Primera Generación de GPUs Segunda Generación de GPUs Tercera Generación de GPUs Cuarta Generación de GPUs
Vértices de los Vértices de los Vértices de los Vértices de los

Modelos de Modelos de Modelos de Modelos de
Objetos Objetos Objetos Objetos
CPU CPU CPU

Transformaciones
de Vértices
AGP AGP AGP / PCIe
GPU GPU GPU
Ensamblado de
Primitivas Transformaciones Transformaciones Transformaciones
de Vértices de Vértices de Vértices
CPU
PCI Ensamblado de Vertex Shader

Vertex Shader
Primitivas limitados
GPU
Ensamblado de Ensamblado de
Rasterización Rasterización
Primitivas Primitivas
Operaciones de Operaciones de
Rasterización Rasterización
Rasterizado Rasterizado
Operaciones de
Frame Buffer Frame Buffer Fragment Shader
Rasterizado
Operaciones de
Frame Buffer
Rasterizado
Frame Buffer
(a) (b) (c) (d)
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.

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.
Programación de GPUs: Shader Model 4.0 45

• 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 Input Assembler
Vertex Shader Vertex Shader
Geometry Shader
Geometry Shader
Stream Output Stream Output
Rasterizer Rasterizer
Pixel Shader Pixel Shader
Output Merger Output Merger
Input Assembler Input Assembler
Vertex Shader Vertex Shader
Geometry Shader Geometry Shader
Stream Output Stream Output
Rasterizer Rasterizer
Pixel Shader Pixel Shader
Output Merger 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 // Vertex Shader
//--------------------------- //----------------------------
Texture2D ColorTexture; PS_INPUT VS( VS_INPUT input )
{
//--------------------------- PS_INPUT output = (PS_INPUT)0;
// Buffer de Variables output.Pos = mul( input.Pos,
// Constantes World );
//--------------------------- output.Pos = mul( output.Pos,
cbuffer cb0 View );
{ output.Pos = mul( output.Pos,
matrix World; Projection );
matrix View; output.Color = input.Color;
matrix Projection;
} return output;
}
//---------------------------
// Estructuras de datos a //----------------------------
// utilizar // Pixel Shader
//--------------------------- //----------------------------
struct VS_INPUT float4 PS( PS_INPUT input) :
{ SV_Target
float4 Pos : POSITION; {
float2 TextCoord : TEXCOORD0; return ColorTexture.Sample(
}; TextureSampler,
struct PS_INPUT input.TextCoord);
{ }
float4 Pos : SV_POSITION;
float2 TextCoord : TEXCOORD0; //-----------------------------
}; // Configuraciones del pipeline
//-----------------------------
//--------------------------- technique10 Render
// Samplers de Texturas {
//--------------------------- pass P0
SamplerState TextureSampler {
{ SetRasterizerState( rsSolid );
Filter = MIN_MAG_MIP_LINEAR; SetVertexShader(
AddressU = Wrap; CompileShader(vs_4_0, VS())
AddressV = Wrap; );
};
SetGeometryShader( NULL );
//-----------------------------
// Configuración del Rasterizer SetPixelShader(
//----------------------------- CompileShader(ps_4_0, PS())
RasterizerState rsSolid );
{ }
FillMode = Solid; }
CullMode = Back;
};
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.

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
Soluciones Modernas al Renderizado de Terrenos 53

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 2 k + 1 vértices de lado, donde
k ∈ [1, →) . Entonces, el terreno es divido en bloques cuadrados de 2 n + 1
vértices de lado, donde n ∈ [1, →) , 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 2 n + 1 vértices de lado; luego, el lado del nivel m consiste en
2 n−m + 1 vértices, con m < n . 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 2 n − 1 vértices de lado (con n = 1,2,3... ) 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].

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
Diseño de la Solución Propuesta 61

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 n = 2 + 1 (con k = 1, 2, 3…), ya que es necesario para poder dividir
k
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
m = 2 j + 1 (con j = 1, 2, 3…). La solución necesita que cada parche sea divido
en, al menos, 8 x 8 bloques. Esto significa que k − j ≥ 3 . 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 2i(m − 1) 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 (r + 1) * (m − 1) + 1 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.

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
Implementación de la Solución 73
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 Instancias de objetos de las clases que contiene.
destacables
Métodos - Init: Inicializa el framework. Crea e inicializa las
principales 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.
Atributos - extention_x: Longitud en el eje x de la superficie del
destacables 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.
Métodos Los métodos permiten consultar tanto los atributos
principales como obtener referencias a los objetos que lo
componen.
Clase HeightMap
Responsabilidades Administra las consultas al mapa de alturas utilizado
para modelar el terreno.
Atributos - height_resolution: Resolución vertical para escalar los
destacables valores discretos contenidos en el mapa de alturas.
- height_offset: Valor para desplazar todos los valores
de alturas presentes en el mapa de alturas.
Métodos - getHeightsAtRegion: Permite obtener los valores de
principales 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.
Atributos -
destacables
Métodos -
principales
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.
Atributos - position: Posición del observador en el espacio del
destacables 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.
Métodos - getViewMatrix: Método para consultar la matriz de
principales 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.
Atributos - foward_vel: Velocidad de avance. Utilizado para
destacables 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.
Métodos - move: Método que a partir del valor de las
principales 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.
Atributos Instancias necesarias para realizar el renderizado de
destacables cada cuadro.
Métodos - Render: Esta función inicializa el pipeline gráfico y
principales 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
Métodos -
principales
Clase TerrainRenderingTechnique
Responsabilidades Clase abstracta que modela las tareas y datos comunes
para renderizar un terreno.
Atributos - fx_file: Path del archivo de texto que define el efecto
destacables 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.
Métodos - TerrainRenderingTechnique: Constructor. Recibe el
principales 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.
Atributos -
destacables
Métodos - Init: Inicializa la administración del joystick.
principales - 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.
Atributos -
destacables
Métodos - getWidth, getHeight: Métodos para obtener el alto y
principales 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.
Atributos -
destacables
Métodos -
principales
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 cada 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 transformació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 con 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 pollera 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 para almacenar
/// en cada capa la información de elevación para cada parche
Texture2DArray <float> HeightMapTexture;
/// RefinedTilesTextureArray: Array de texturas utilizado para

/// almacenar en cada capa la información de elevació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 atributos de entrada
/// a los Vertex Shaders
/// > u_offset: offset respecto al vértice de referencia del parche.
/// > v_offset: offset respecto al vértice de referencia 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: coordenada del vértice de
/// referencia para el muestreo
/// de la altura.
/// > patch_texture_reference_position_v: coordenada del vértice de
/// referencia para el muestreo
/// de la altura.
/// > world_reference_position_x: posicion en el mundo del vértice
/// de referencia.
/// > world_reference_position_y: posicion en el mundo 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_REFERENCE_POS_U;
uint patch_texture_reference_position_v:PATCH_TEXT_REFERENCE_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 que define los
/// atributos de entrada a los Vertex Shaders
/// > u_sample: coordenada para obtener el valor de elevacion del
/// vértice de la textura correspondiente.
/// > v_sample: coordenada para obtener el valor de 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 mundo del vértice
/// de referencia.
/// > world_reference_position_y: posicion en el mundo 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 array de texturas
/// con datos de los bloques refinados.
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 atributos de salida
/// de los Vertex Shaders.
/// > Pos: posicion transformada del vértice en coordenadas
/// homogéneas.
/// > TextCoord: coordenadas de textura para obtener el color de
/// sombreado de la superficie para ese 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 altura 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értice

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

* float(input.v_offset) * SurfaceResolution;
// tomo la altura del mapa de elevacion del layer que

// 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 altura

float z = z0 - input.is_skirt * skirt_height;
// escalo la altura del vértice con la resolución vertical

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 obtener 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értice

float pos_x = input.world_reference_position_x
* float(input.u_sample) * SurfaceResolution;
float pos_y = input.world_reference_position_y

* float(input.v_sample) * SurfaceResolution;
// tomo la altura del mapa de elevacion del layer que

// corresponde al bloque refinado al que pertenece el vertice
uint z0 = RefinedTilesTextureArray.Load( int4(
input.u_sample,
input.v_sample,
input.texture_layer,
0
)
);
// si es un vértice de la pollera modifico la altura

float z = z0 - input.is_skirt * skirt_height;
// escalo la altura del vértice con la resolución vertical

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 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.TextCoord);
}
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 terrenos. Configuración
// del pipeline gráfico
//-------------------------------------------------------------------
technique10 RenderTerrain
{
/// P0: Pasada utilizada para renderizar los Bloques NO
Refinados
pass P0
{
SetRasterizerState( rsSolidframe );
SetDepthStencilState( depthState, 0 );
SetVertexShader( vs );
SetPixelShader( ps );
}
/// P1: Pasada utilizada para renderizar los Bloques Refinados

pass P1
{
SetRasterizerState( rsSolidframe );
SetDepthStencilState( depthState, 0 );
SetVertexShader( vs_refined_tiles );
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.
(V( 4, 0 ) − V( 0, 0) ) × (V( 0, 4) − V( 0, 0) ) = N
r
N • V( i , j ) + N • V( 0, 0 ) = 0
r r
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).
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.
Resultados Obtenidos 93
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

178 5470 2718 1108 970 259 85 140 31 1
1652 6830 2318 2047 1355 873 318 139 13 0
38 5038 4234 2448 724 620 346 113 3 0
30 5419 3567 2687 756 359 233 63 4 0
30 6219 3661 2121 365 171 7 1 0 0
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
94 Resultados Obtenidos
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.
Resultados Obtenidos 95
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
Conclusiones 97
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.
98 Conclusiones
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.
Referencias 99
[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.
100 Referencias
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.
Publicaciones 101

Guaycochea PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guaycochea PDF

Cargado por

Copyright:

Formatos disponibles

Visualización de Terrenos

con Tarjetas de Video

TESIS DE GRADO EN INGENIERÍA EN

UNIVERSIDAD DE BUENOS AIRES

TESISTA: Lucas Enrique Guaycochea

DIRECTOR: Ing. Horacio Antonio Abbate

A Mónica y Enrique, mis padres, por brindarme todo lo que he

A Emilia, que ha estado a mi lado los últimos 7 años, siempre dando su

A Horacio, director de esta tesis, por sus consejos, dedicación y

A mis compañeros y amigos de la facultad, por su compañía, amistad y

A mis amigos, familiares y compañeros de trabajo, por su apoyo

A todos ellos, muchas gracias!

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

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

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

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

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

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

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

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

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

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

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

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

1.1 Visualización de Terrenos

Un tema particularmente importante en computación gráfica es el

1.2 Objetivo de esta Tesis

Finalmente, el objetivo de esta tesis, tras haber presentado y

Figura 2.1 – Malla de puntos en un espacio tridimensional.

Los ejes de referencia a utilizar en el espacio son elegidos

2.1 Uso de Mallas Regulares o Irregulares

Los puntos que conforman la superficie del terreno pueden

2.2 Formato de Archivos de Modelos de Terreno

La descripción de los puntos, que conforman el modelo de la superficie

El conjunto de operaciones que se realiza para, a partir del modelado

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

A continuación, se expondrá una breve explicación de las operaciones

3.1 Vértices y Primitivas

Los objetos de la escena son modelados mediante una malla de

Las posiciones de los vértices que modelan cada objeto se referencian

z  m11 m12 m13 m14  instancia 1 instancia 2

v31 v32 v33 v34  cámara

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

Figura 3.4 – Operación de recorte.

Luego, las primitivas son mapeadas a coordenadas de pantalla a partir

El objetivo de esta etapa es determinar el conjunto de píxeles que

El problema de brindar visualizaciones ricas en detalle de mayores

Figura 4.2 – La técnica de frustum-culling permite no introducir en el pipeline gráfico la

Este hecho, surgido de la visualización en perspectiva, también es

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

5 Terrenos con Nivel de Detalle

A continuación, en este capítulo, se explicarán los distintos aspectos

5.1 Criterios para la Elección del Nivel de Detalle

Dentro de la vasta bibliografía en el tema, los trabajos publicados

Terrenos con Nivel de Detalle 19

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

20 Terrenos con Nivel de Detalle

El error geométrico o de modelado puede calcularse de manera

Error percibido o proyectado

Terrenos con Nivel de Detalle 21

Figura 5.4 – Volumen de Visualización.