Doom 3 y las patentes de software » Ruido blanco

Mañana 3 de Agosto por fín podremos comprar (si estuvieramos en Estados Unidos quiero decir, aquí en el estado número 52 lo tendremos a partir del 13) el esperadísimo Doom 3 de los increibles desarrolladores de id Software. A la cabeza de esos desarrolladores están Robert Duffy y Tim Willits, pero sobre todo John Carmack, el hombre al que las compañias de tarjetas gráficas adoran por permitirles vender más unidades de sus carísimos productos.

Pero la salida de Doom 3 no está siendo todo lo facil que pudiera ser (a parte de "mosquitos" segundones que, en mi opinión, han corrido a terminar el juego para Septiembre justo cuando se anunció la fecha de salida del Doom 3) debido a unos problemas con ciertas patentes de Creative (para los que puede existir "arte previo") y que han hecho que Carmack, para utilizar el algoritmo patentado, implemente en Doom 3 la tecnología EAX de Creative cuando él pretendía que todo el proceso de audio lo realizara el procesador para asi poder tener la misma experiencia auiditiva con cualquier tarjeta. La respuesta de Carmack es de lo más explicita con la situación y su posición respecto a las patentes de software.

Lo peor de todo es que la técnica que Creative pretende haber patentado se denomina en los círculos de los gráficos por ordenador Carmack's Reverse debido a este correo enviado por Carmack a uno de los ingenieros de nVidia. Parece ser que los ingenieros de Creative patentaron la técnica en 1999 (se puede ver en este artículo de la Wikipedia) aunque parece que alguien se les había adelantado unos meses aunque no rellenó la patente.

Si quereis conocer la diferencia entre la técnica usual y la técnica inversa de Carmack podeis pulsar en "Leer más" y sufrir con mi humilde explicación.

En la programación gráfica existen varios "almacenes" (buffers) donde se guardan diferentes valores que después utilizará la tarjeta (o el software) para representar correctamente la escena. Usualmente los buffers más importantes eran el color buffer (que normalmente no se le refiere de esta forma ni de ninguna otra forma y es más o menos transparente al desarrollador en la mayoría de situaciones) y el z-buffer que almacena información sobre que objetos están más próximos o más lejanos al punto de visión (en la programación gráfica la coordenada Z indica profundidad).

Desde hace un par de años (pongamos que esa famosa fecha de 1999) las tarjetas gráficas se han vuelto mucho más potentes y con más características, una de las características que le faltaba a las tarjetas de gama media-baja era el soporte para stencil buffers (almacén de plantilla, por traducirlo de algún modo), que permite asociar un valor a cada pixel de la representación y utilizarlo como mascara para representar objetos más adelante. Por decirlo de una forma simplificada donde el valor del stencil buffer sea verdadero el dibujo se verá y donde no lo sea se mantendrá lo que antes estaba en ese pixel.

¿Cómo puede esto utilizarse para representar sombras? Bueno, los programadores gráficos son unas personas muy inteligentes y utilizan las herramientas a su alrededor muy eficientemente para conseguir lo que quieren. Carmack queria que las sombras de su nuevo juego fueran totalmente realistas (bueno, dentro del realismo que se puede obtener en motores gráficos en tiempo real), si alguien pasaba por delante de una luz su silueta se debia proyectar en el suelo y las paredes de su alrededor (obviamente también en otros personajes y objetos).

La técnica que se utilizaba antes de 1999 se denomina z-pass method (ideada por Frank Crow en ¡1977!), es ella los objetos crean sombras volumétricas que sirven para rellenar el stencil buffer. Para crear estos volumenes se buscan las arístas de los objetos tridimensionales que separan la parte iluminada por la luz de la parte no iluminada y las proyectan en dirección contraria al punto de luz hasta el "infinito" (entre comillas ya que eso no es posible en los ordenadores, en su lugar se utilizan "trampas" como proyectar hasta cierta distancia fija [falla cuando la luz está muy cercana a la superfice que proyecta la sombra] o hasta un poco antes del plano de corte lejano de la escena [esto es, donde se dejan de representar objetos]), con esas caras se realiza el cálculo de cuáles pixels estarán bajo acción de la sombra y cuáles no.

El hecho de que el dibujo esté en dos dimensiones y que la superficie de representación sea unidimensional es por sencillez asi que tendreís que extrapolar un poco vosotros al mundo de las tres dimensiones y las pantallas bidimensionales.

De acuerdo, ahora que hemos calculado los poligonos que definen la sombra comenzamos el proceso para representar la escena con sombras. Lo primero que hay que hacer es representar la escena sin los polígonos que forman la sombra como hariamos normalmente. Y entonces empieza lo divertido. Normalmente los triangulos que se dibujan en pantalla tienen un sentido preferente, puede ser el sentido de las agujas del reloj o el contrario, dependiendo del orden en el que hayas definido los vertices en el código el triangulo se mostrará en la pantalla (si los vertices resultan estar en el orden preferente) o no se mostrará (si los vertices están al revés y el triangulo nos muestra la "espalda"). Eso nos permite separar las caras de los objetos en caras "de frente" y caras "del revés". Para la sombra proyectada la cara de frente es la cercana a la cámara y la cara del revés es la lejana (es necesario que las caras de la sombra miren hacia el exterior para que el proceso funcione).

Lo que hacemos ahora es representar sólamente las caras de frente (es decir el proceso normal) pero pedimos a nuestra librería gráfica que almacene los resultados en el stencil buffer pidiendo que aumente el valor del pixel almacenado en el stencil buffer si el rayo se choca antes contra uno de los triangulos de la sombra que contra uno de los objetos ya presentes en la escena.

Después de este primer paso le pediremos a nuestra librería gráfica que se vuelva un poco loca y que dibuje los triangulos del revés como si fueran de frente y viceversa, esto hace que el lado de la sombra más cercano a nosotros sea invisible, pero que sin embargo veamos el más lejano. A parte de este cambio le pediremos también que en vez de incrementar el valor del stencil buffer lo decremente si choca antes con uno de los lados de nuestra sombra en vez de con uno de los objetos de la escena.

He incluido unos rayos más para ver un par de casos más de los que se podrían dar. Además a parte de los aumentos y las disminuciones del valor del stencil buffer he puesto al final de cada rayo el valor final del stencil buffer. Vamos a analizar rayo a rayo para ver las diferencias:

• El primer rayo choca contra la sombra antes que con cualquier objeto, por lo tanto el valor del stencil buffer aumenta, en la segunda pasada choca antes contra la esfera por lo que su valor no disminuye y su valor final es 1.
• El segundo rayo entra y sale de la sombra sin chocar contra ningún objeto, su valor primero aumenta y luego disminuye, el valor final por lo tanto es 0
• El tercer rayo es muy parecido al segundo, con la diferencia que despues de salir choca contra un objeto. El valor final es 0.
• El cuarto rayo es parecido al primero, choca contra la sombra en la primera pasada (el valor aumenta) pero en la segunda choca contra el Objeto 1 antes de chocar de nuevo contra la sombra. Valor final: 1.
• El quinto rayo choca en su primera pasada contra el Objeto 2 antes de chocar contra la sombra, por lo tanto su valor no aumenta. Cuando se realiza la segunda pasada choca contra el Objeto 1 antes de salir de la sombra, de nuevo su valor no aumenta. El valor final es, por lo tanto, 0.

Con estos valores en el stencil buffer tenemos una mascara de donde debe dibujarse la sombra (valores 1) y donde no debe (valores 0). Con esta mascara normalmente se dibuja un rectangulo oscuro y semitrasparente que ocupe toda la pantalla. Las zonas en las que el stencil buffer permita dibujar quedarán tintadas de este color oscuro.

Alguien podría protestar por uno de los rayos, en él no se proyecta sombra pero debería. Es el caso del quinto rayo, en el momento de tocar al Objeto 1 está bajo la sombra de la esfera, sin embargo el valor del stencil buffer no permitirá que la sombra sea dibujada en ese pixel. En realidad ese pixel no debe estar sombreado ya que en la pantalla se vé al Objeto 2 en ese pixel que no debe estar sombreado.

Como ya hemos dicho este es el proceso z-pass o "directo", ¿qué problema habia con él para que Carmack necesitase otro método y se chocara contra la pantente de Creative? Bueno, el problema viene cuando el observador está dentro del volumen de la sombra.

Como veis las sombras se pierden, y lo que es peor, hay casos en los que las sombras se invierten. Debo decir que normalmente los stencil buffer cuando se intenta disminuir el valor mínimo se ignora la reducción y se mantienen en el mínimo, por eso las reducciones de valor no hacen que los buffers queden con valor negativo.

¿Cómo iba Carmack a permitir que porque el jugador entrara en la zona de sombra de un monstruo amenazante la sombra se perdiera? Por eso tuvo que buscar el algoritmo que permitiera a la cámara moverse libremente y seguir obteniendo sombras realistas.

Páginas: 1 2

Ver entradas relacionadas

• Rechazada la propuesta de pantentes de software en Europa
• Pues empieza bien el tratado…
• Patenta tu mundo
• iPhone: decepción antes de lanzarse
• Las leyes de Myhrvold