Los gráficos en 3D a tiempo real tienen dos pipelines diferenciadas:

  • El World Space Pipeline
  • El Screen Space Pipeline

Si miramos la definición de rasterizacion lo que obtenemos es que es el nombre completo de todo el proceso.

La rasterización es el proceso por el cual una imagen descrita en un formato gráfico vectorial se convierte en un conjunto de píxeles o puntos para ser desplegados en un medio de salida digital, como una pantalla de computadora, una impresora electrónica o una Imagen de mapa de bits (bitmap).

Pero en realidad el nombre de lo debe a una de las etapas del pipeline en conjunto, la que se situa entre el World Space Pipeline y el Screen Space Pipeline.

Pe… pero Urian… Esto son palabros nuevos.

El World Space Pipeline no es más que la etapa de geometría donde por cada objeto se sigue un proceso conjunto pero no se hace teniendo a la pantalla como referencia, esta parte del pipeline es independiente a la resolución de pantalla y consiste en los siguientes pasos:

ogl_vertex_life

En la primera etapa la GPU desplaza o rota los objetos de la escena de una manera determinada según le marque la lista de comandos de la CPU. En la segunda etapa lo que hace es recolocar uno por uno todos los polígonos de la escena según el nuevo punto de referencia que es la posición de la cámara y en la tercera etapa lo que tenemos basicamente es esto:

raytracing-raster2

Esta es la étapa a la que llamamos rasterización, en este punto los polígonos se proyectan sobre la pantalla y la información de profundidad de cada polígono se almacena en el z-buffer o buffer de profundidad. Pero en realidad la GPU no esta realizando una conversión de 3D a 2D solamente:

jwcl8

Es decir, teniendo como entrada las coordenadas (x,y) de las tres aristas del ahora el triangulo 3D acabamos sabiendo que pixeles ocupan los vertices de cada polígono antes d dividir en fragmentos de 2×2 y enviarlos directamente al Screen Space Pipeline para que sean texturizados y/o simplemente se les de color. También es posible (en sistemas muy antiguos) que los vertices ya tengan un color asignado y de ahí se cree un búfer de imagen y se envie a la pantalla.

El método de rasterizado más utilizado es el del OpenGL, en dicho proceso las primitivas gráficas son procesadas sin más orden que el de la geometría y los polígonos se procesaba uno por uno hasta hace relativamente poco con la llegada de DirectX 11 donde desde entonces se ha permitido que se puedan enviar 2 y hasta 4 poligonos por ciclo de reloj. En realidad dicho proceso en su día recibió el nombre de Triangle Setup y cuando las tarjetas 3D sin el World Space Pipeline (geometría) no calculaban polígonos de ningún tipo a lo que se referían con polígonos es precisamente a la cantidad de geometría que el rasterizador podía rasterizar y enviar al Screen Space Pipeline que es la parte rastante del pipeline 3D.

El caso es que para la rasterización tenemos dos formas distintas clásicas que son el rasterizado por scanlines y el rasterizado baricentrico. Al primero se le llama así porque no tiene en cuenta la pantalla sino solo la linea de escaneo actual pero tiene la desventaja de que no se puede utilizar filtrado de texturas desde el momento en que los polígonos son enviados pixel por pixel al Screen Space Pipeline en vez de 2×2. ¿La ventaja de este método? Permite renderizar a la velocidad de la pantalla, pero dado que hoy en día se hacen decenas de cálculos por pantalla no es recomendable, pero hay un sistema que si que utilizo en su día este tipo de rasterizado, este fue la NintendoDS.

super-mario-64-ds-20041120091123141

El Baricentrico es el clásico, si que tiene en cuenta el espacio de pantalla y se puede utilizar filtrado de texturas con el mismo. Este al contrario que el rasterizado por scanlines es independiente a la velocidad de refresco del monitor por lo que permite incrementar la complejidad gráfica de la escena sacrificando velocidad pero si la GPU es lo suficientemente rápida no es problema alguno. Dado que este proceso es llevado en una parte no programable del pipelne y de función fija no es algo por lo que los desarrolladores se tengan que preocupar, en realidad una buena parte del pipeline 3D esta automatizada.

La primera consola en utilizar el sistema baricentrico fue la PlayStation de Sony pero con un problema, con tal de ahorrar tiempo y potencia lo que decidió Sony fue cargarse por completo la generacion del Z-Buffer, eliminando por completo en el proceso la corrección de perspectiva y transformando la escena en un enorme flan en la gran mayoría de casos (a no ser que los desarrolladores hicieran una corrección de perspectiva por software). Saturn en cambio al no trabajar con triangulos no tenía un rasterizador de triangulos por lo que esta fuera y N64 fue la primera consola en utilizar el sistema baricentrico con un búfer de profundidad aunque por temas de rendimiento se desactivaba en algunos juegos.

Como curiosidad, el mundo del PC a medidados de los 90 tenía problemas enormes con los gráficos en 3D a tiempo real por esta etapa de rasterizado que le quitaba un rendimiento brutal a los juegos comparados con la PlayStation de Sony. Incluso los primeros Pentium iban ahogados de mala manera ya que toda esa etapa se tenía que hacer por software. ¿El primer hardware con un Triangle Setup primitivo? Fueron dos, uno se llevo la palma que fue la Voodoo Graphics, el otro salió unos meses antes y fue el innovador.

v1000e

El Rendition Verite V1000, el que se encontraba en las primeras 3D Blaster que aparecieron en el mercado, algo innovador que solo fue superado por algo mucho más bestia.

1

La todopoderosa Voodoo Graphics más conocida como Voodoo 1 fue revolucionaria en el mercado por implementar gráficos con filtrado de texturas entre otras cosas a una resolucíón de 640×480 y sin los problemas de texturas de mala calidad de N64.

glcomp

La enorme popularidad de la Voodoo Graphics hizo que se hiciera una sucesora, a la cual se la llamo Voodoo 2, la gran novedad de la sucesora fue un Triangle Setup/Rasterizador ampliamente mejorado, capaz de realizar el Rasterizar hasta unos 3 millones de poligonos por segundo y a partir de ahí la cosa fue en ascenso.

¿El Rasterizador más impresionente de la historia? El del Graphics Synthetizer de PS2, donde Sony acabo sacrificando buena parte de los elementos que tenían otros procesadores gráficos contemporaneos a cambio de tener un rasterizador lo suficientemente rápido como para que no fuera un problema, capaz de rasterizar unos 75 millones de poligonos por segundo, es decir, 1 poligono cada 2 ciclos de reloj. Algo que ni el PC podía alcanzar en esos momentos. Como dato histórico, los famosos 3 millones de Dreamcast son la potencia de su Triangle Setup/Rasterizador, esto es para que veáis el enorme salto y lo impresionante que fue.

 

La GameCube de Nintendo tuvo un Rasterizador más bien pobre y lento en comparación al resto, necesitan unos 16 ciclos de reloj de la GPU para rasterizar un triangulo, aunque las cifras en las que se movían los juegos en cuanto a geometría no lo convertían en un cuello de botella a efectos prácticos la verdad es que este era muy lento en comparación con lo que había disponible en la época. Cierto es que el de de PS2 era una bestia parda con sobrepotencia pero el de las primeras GeForce podía hacerlo en 8 ciclos, pero con la GeForce 3 y la GeForce 4 hubo un cambio bestia y la cosa se quedo en 2 ciclos para las GPUs de Nvidia hasta la llegada de la G80 alias 8800, por lo que esto significa que PS3 llevando un derivado de la 7900 (G71) tiene una GPU que rasteriza un poligono cada dos ciclos o lo que es lo mismo: 275 millones de poligonos. Y ahora sabéis de donde sale la cifra.

Xbox 360 tenía un mejor rasterizador, capaz de rasterizar un poligono por ciclo, llegando a los 500 millones. Esta norma de 1 poligono por ciclo se mantuvo como el limite durante años hasta la llegada de DX11 que empezamos a ver GPUs capaces de rasterizar dos poligonos simultaneos y hoy en día tenemos bestia en el mercado que pueden hacerlo con 4 polígonos y quien sabe si pronto lo veremos con 8. Aunque la verdad es que ahora algo que en su día era un problema es una parte muy banal del pipeline y de la potencia total que se necesita para renderizar una escena.