REYES

De Codepixel
Revisión a fecha de 16:05 11 jul 2011; Ruben (Discusión | contribuciones)
(dif) ← Revisión anterior | Revisión actual (dif) | Revisión siguiente → (dif)

La arquitectura REYES es un método para renderizar imágenes. Fue desarrollada por el equipo de Lucas Film que más tarde formaría Pixar, y es la tecnología usada en el motor de render Renderman.

Cada primitiva pasa una serie de etapas, entre ella, la de recortar el triángulo, formando "micropolígonos" del tamaño de un pixel. Estos micropolígonos pueden desplazarse en el espacio, permitiendo el "displacement mapping".

Cada primitiva pasa por las siguientes etapas:

  • Bound : se comprueba la bounding box de cada primitiva, para ver si es visible en pantalla
  • Split : si una primitiva es muy grande, se divide en otras más sencillas, y se vuelve a realizar el test de Bound.
  • Dice  : se refina la primitiva en un grid de micropolígonos, cadauno más o menos del tamaño de un píxel.
  • Shade : se evalua la iluminación de cada micropolígono. Al ser muy pequeño, se considera que su color es constante.
  • Bust  : se testea cada micropolígono por visibilidad.
  • Hide  : samplear los micropolígonos, para generar la imagen.

Para no tener que almacenar todo el framebuffer en memoria, lo cual, podría ser un problema con imágenes muy grandes, y sobre todo, para permitir la evaluación en paralelo, se divide la imágen en varios "buckets", o pedazos. De este modo, en la fase de split, cada primitiva se va enviando a cada bucket, antes de la fase de Dice. Cada bucket aplica su propio Dice, y los datos se descartan entre buckets. De esta forma, los buckets son independientes entre sí (aunque realizan varios cálculos de más).

El diseño está explicado en el paper The Reyes Rendering Architecture.

Contenido

[editar] Bounding & Split

Cada primitiva se testea contra la cámara, de este modo, se descarta rápidamente. Comenzamos con una pila de objetos que van a ser divididos. Se saca un objeto. Se comprueba si su bbox está dentro de la cámara. Si es así, se comprueba si se puede dividir, y si es asi, metemos las nuevas primitivas en la pila. Si no se puede dividir más, metemos la primitiva en una pila para la siguiente etapa. Cuando la pila de objetos de entrada está vacía, pasamos a la siguiente fase.

Este enlace muestra una gráfica con el test.

Es importante calcular bien hasta cuándo vamos a serguir dividiendo la primitiva. Si dividimos poco, la siguiente etapa va a generar una cantidad enorme de micropolígonos. Si dividimos mucho, tendremos una cantidad enorme de primitivas en memoria. Tendremos que adaptar la división a un tamaño acorde al bucket.

Esta parte digamos que hace de subdivisión adaptativa (ya que la etapa de Dice es división uniforme). Al refinar los splits, tendremos una división mayor en las primitivas que están cercanas a cámara, y una división menor en las partes que están más alejadas (haciendo que los consumos de memoria sean menores).

[editar] Dice

Cuando la primitiva está por debajo de un límite, donde ya no se divide más, pasa a la fase donde se crean los micropolígonos. Los micropolígonos son cuadrados, y se considera que el dato (normal, color, opacidad) es constante para todo el micropolígono, eliminando la necesidad de interpolar los valores.

De este modo, definimos una simple rejilla cuadriculada, donde cada vértice de la rejilla almacenan varios datos (posición, normal, color y opacidad). Cada cuadrado de la rejilla (micropolígono) tendrá más o menos el tamaño de 1 pixel.

Lo que hacemos es ir recorriendo sus coordenadas paramétricas u,v, e ir evaluando valores de la primitiva para intervalos regulares, y los guardamos en cada vértice de la rejilla.

Cada primitiva tendrá su propia funcion de evaluación. Así, una esfera o un triángulo tienen distintas formas de calcular su normal.

Este enlace nos muestra código de ejemplo.

A veces, podríamos tener problemas cuando las rejillas de micropolígonos no coinciden con las rejillas vecinas. Por ejemplo, puede que una rejilla tenga distinta resolución. En ese caso, aparecen pequeñas roturas. El problema se conoce como cracking, y normalmente se soluciona "cosiendo" una rejilla adicional.

[editar] Shading

Una vez que hemos generado los micropolígonos, evaluando la primitiva, recorremos cada uno de los elementos del grid, para calcular su color. Existen multitud de fórmulas para evaluar un color. Los motores normalmente usan un lenguaje de shading, que permiten programar esta etapa, según nuestras necesidades. Estos programas se llaman "shaders".

Es importante recalcar que la posición puede ser modificada por el "shader", lo que permite el "displacement shader", característica única de la arquitectura REYES.

Aquí podemos leer más sobre los problemas que incluye el shading y el displacement.

[editar] Sampleado ( Bust & Hide )

Una vez que tenemos los micropolígonos totalmente evaluados, y su color ha sido calculado. Pasamos a proyectar los triángulos en pantalla, y a samplear la imagen. Esto permite efectos de motion blur, usando una forma aleatoria de sampleado en el tiempo, conocido como "stocastic sampling".

Para generar las muestras, se usa el "sampleado estocástico", esto es, se generan muestras de forma aleatoria dentro del pixel (y también, valores aleatorios del tiempo). Existen multitud de técnicas para generar buenas muestras (sampleado estratificado, etc).

Como cada micropolígono tiene su propio valor de color y opacidad, lo único que tenemos que hacer es ver si el micropolígono es visible en esa posición. Para ello, podemos usar Half Spaces, que nos permite descartar rápidamente si un polígono es o no es visible en un pixel.

El valor de la Z se calcula por interpolación lineal de los vértices del micropolígono. Tendremos un Z buffer dónde se comprueba si la muestra es o no es visible en pantalla. Y si es visible, se actualiza el valor de la Z en el buffer.

En las siguientes versiones de Renderman, se guardan las muestras que tienen transparencia, y se combinan al final, respetando el orden de transparencia. De este modo, se puede renderizar materiales semi transparentes de forma correcta.

Más información sobre el sampleado en el wiki del motor Aqsis.

[editar] REYES en GPU's

En general, la implementación en GPU's, es, por ahora muy ineficiente. Los pipelines de las tarjetas no están preparados para esta forma de trabajar. De todos modos, las nuevas tarjetas permiten la teselación de primitivas usando aceleración por hardware. Esto abre una nueva vía de trabajo, para repensar una implementación REYES en GPU.

[editar] Ventajas y Desventajas

La gran ventaja es la flexibilidad. Renderman y los motores de tipo REYES, permiten hacer casi cualquier cosa. Por eso son los más usandos en la industria del cine (Pixar, Dreamworks, etc).

En REYES, normalmente todo se hace en pasadas, que se combinan posteriormente. Cada salida es un "mapa". Así, tenemos Shadow Maps, Deep Maps, Refraction Maps, etc. Calcular estos mapas es sencillo, y la imagen final es una combinación de muchos mapas. Tambien tenemos la posibilidad de dividir cada render según las luces, de calcular distintos efectos en separado, etc. Esta posibilidad de generar todo en etapas, permite mucho control en una producción real.

La posibilidad de programar "shaders" es una ventaja importante. Originalmente, REYES no permite "datos de entrada", simplemente se genera cada dato necesario en un "pase", y se usa esa información para la siguiente etapa, volviendo a rendear todo.

Destaca la posibilidad del "displacement", que permite tener relieve muy realista de forma flexible. El resto de técnicas tienen que usar una lista de "hacks" para poder pintar relieve (aunque muchas veces se usan en REYES, como el bump mapping, etc).

Un motor de este tipo es de "modo inmediato", esto es, cada primitiva se calcula, y se descarta. La desventaja es que efectos como reflejos o iluminación global, son muy costosos con esta arquitectura, y hay que hacer trucos (mapas de entorno, etc) para generar la imagen.

Además, el tiempo de render se incrementa con el número de primitivas. Por ejemplo, el raytracing no suele estar afectado, en cuanto a velocidad, por el número de triángulos, aunque el coste de memoria suele ser el problema que limita todo esto. Por eso, aunque de forma lenta, REYES puede renderizar cualquier número de polígonos, mientras que raytracing siempre tendrá el límite máximo de la memoria.

Una gran desventaja es que el shading se hace antes del descarte de la Z, con lo que muchas veces se evalúa el shading de algo que no se va a mostrar en pantalla después. Los rasterizadores, que se basan en interpolar valores entre los vértices de los triángulos (las GPU's), descartan antes de evaluar el shading, con lo que en general, son más rápidos, pero a costa de perder flexibilidad (no se puede hacer displacement de forma sencilla).

[editar] Referencias