Para muchas aplicaciones y para el uso moderno de un ordenador, el multithreading se está volviendo indispensable y muy bien aprovechado. Además, los precios están bajando bastante y es un vicio bastante asequible, y muy recomendable.

 AMD prometia mucho con sus phenom. Nos lo ponían como la revolución del futuro con su gestor de memoria, pero tras retrasos, lo úncio que tuvimos era un quadcore normalito, y que además tenía un bug bastante serio en su traductor de direcciones .

 AMD ha sacado su nuevo micro con la solución a su bug en el TLB, pero todavía de 65nm, y en extremetech han realizado una comparativa de este nuevo micro, el phenom X4 9850,  con el quadcore más económico de 45nm,  el Q9300 ,  y el de 2 cores  más potente  de 45nm, el  E8500. Todos andan por un precio similar de $300, aunque el de amd es el más económico de  todos (sobre los $235)

 Ambos quadcores tienen la misma velocidad de micro, unos 2,5Ghz, y el de amd tiene el controlador de memoria integrado. Eso debería de darle una ventaja frente a los de intel. Pero la realidad es que el Q9300 es muchas veces superior (sólo en algunos casos mejora el de amd). Si merece la pena esos $60 extras, es ya una cuestión de cada uno.

Lo que sí sorprende es que el dual core, valiendo p´racticamente lo mismo, aun corriendo a 3Ghz, no consiga competir en muchos test con el quadcore.

Asi que yo creo que la decisión está clara, si vais a mirar un micro seriamente para estos dias...

Cada vez tengo más ganas de montar el foro, es cierto, pero soy un poco reticente. Por ahora, creo que el nivel de comentarios que aparecen en las noticias esta siendo constante, y creo que si seguimos así, se puede crear una comunidad de usuarios suficiente para que un foro tenga un mínimo de trafico. Pero todavía falta un poco...

Así que pensado sobre el tema, me he decidido a crear una lista de correo para que todos podamos opinar sobre codepixel, dar ideas, preguntar, y todas esas cosas. La dirección del grupo es codepixel en googlegroups.com , y cualquiera puede inscribirse y postear.  Creo que codepixel es un buen sitio para que los profesionales y entusiastas de la programación gráfica podamos juntarnos y aprender todos juntos, así que os animo a participar primero en la lista, y si la cosa marcha mejor, en el foro de la web.

 Esta es la tercera y última parte de la serie de artículos "Diseño de un motor de render moderno". En este último artículo pasamos a la parte que más flexibilidad va a aportar a nuestro motor: el scenegraph. Se nombra una lista de tareas que iremos realizando a medida que visitamos los nodos declarados, como calcular su posición en la escena, preparar los datos de iluminación, ordenar para que el posterior pintado sea óptimo, etc. 

Aqui teneis el enlace .

 Intel ha publicado las especificaciones de las nuevas instrucciones que estarán disponubles en el futuro. Atención, porque esto es algo que nos va a afectar a todos en el futuro.

 Lo más importante es que tendremos  256 bits para nuestros datos (8 floats) y una nueva sintaxis que permitirá 3 y 4 operadores por instruccion. Además, van a bajar las grandes restricciones que existian hoy en día de memoria alienada, etc. Será compatible con SSE4 y todo eso. O sea, mas potencia de cálculo paralelizable, más potencia de multiplicación de matrices, más vectorización, etc.

Aqui podeis leer toda la información , y quizás podáis explicarme porqué tiene que salir la foto de un flipao en plan mago de los programas de jose luis moreno.

 Ya podeis leer la segunda parte de esta serie de tutoriales sobre el diseño de un motor de render para tarjeta. En esta ocasión hablaremos de qué tareas hay que desarrollar para pintar geometría a bajo nivel de una forma óptima, y que partes del API gráfica deberíamos de abstraer.

 Este es el enlace al artículo .

Nos hemos juntado Iñigo Quilez, Jesús de Santos  y Javier Loureiro para crear una serie de 3 artículos sobre la creación de un motor de render moderno. En estos artículos trataremos el tema de qué partes se tienen que implementar, cuales son los objetivos que tiene cada componente, y sobre todo, tener una visión general de la arquitectura. Los artículos intentan mostrar cómo aprovechar al máximo las capacidades de la tarjeta gráfica actual.

La primera parte es una introducción general sobre el diseño, donde se explican las funciones más importantes y las partes del motor.

Aquí teneis el enlace.

 No os podeis perder esta demo de PS3 , Linger in Shadows, del grupo demoscener Plastic. Estos días está dando mucho que hablar en el mundillo.

 El aspecto gráfico es realmente impresionante. Pero lo que a mí más me impresiona es que el trabajo requiere de un entorno profesional.  Tiene un amplio trabajo de modelado, de texturizado, de matte painting, de sonido, etc. A parte del trabajo de desarrollar un motor gráfico con características como ambient occlusion (algo raro para mi ojo, pero que tiene un trabajo), la parte de físicas (por poco que metas, ya requiere un esfuerzo de desarrollo), y muchas cosas que hacen esta demo un trabajo de bastante gente. Incluso me parece dificil hacer la demo sin un software de gestión de proyecto como una productora normal. Desde luego, es un trabajo parecido a que se requiere para hacer una demo de un videojuego que vayamos a presentar a una distribuidora potente. Hay muchas empresas de 3D que no tienen los recursos para hacer una demo de este estilo,, y este grupo se ha sacado una demo asi de elaborada.

 Da que pensar...

 Ya habíamos hablado aqui de las nuevas características de DIrectX 10.1, pero es bueno echarle un ojo a esta presentacion de ati sobre qué podremos hacer realmente con esta tecnología (cuando esté ampliamente extendida, vamos).

 El tema principal de la extensión DX10.1 son las muestras de antialias y la posibilidad de programarlas. En la presenctación podemos ver mejor su uso real. Imaginad una partícula renderizada en un billboard orientado a cámara. El driver ve 2 triangulos, y hace filtrado en los triangulos, pero realmente tenemos una bola con alpha. DirectX 10.1 nos permite programar cómo se va a calcular el antialias en el triangulo para que el filtrado sea correcto en los bordes de la partícula, mejorando bastante la calidad de las partículas.

Otro tema es el deferred shading, esto es, componer capas para sacar un frame. Hoy en día hay problemas con la precisión, ya que si usamos buffers, podemos perder precisión, precisamente en los bordes. Con directx 10.1 podremos controlar un poco más la escritura de datos, y hacer los bordes más correctos. Esto indica que renderizar por pases, como en animación, se está convirtiendo un estandard en la industria.

El otro punto interesante de DirectX 10.1 es todo lo que tiene que ver con los cube maps. LAs nuevas extensiones permiten cuardar más información sobre el entorno. Eso combinado con un shader, nos permite almacenar información precalculada de iluminación, y hacer cálculos de "iluminación global" o de la información de entorno para un correcto render. La idea es que podemos interpolar entre varios cube maps. Esto es algo que puede explotar bastante bien  para tener un fotograma mucho más realista. 

  DirectX 10.1 tiene, a mi modo de ver, 2 problemas principales. Obliga a tener el antialias siempre activado, cosa que me parece algo excesivo, y está sólamente disponible en windows vista, tema que tiene pinta de no acabar muy bien.

 Vaya, hacia unos días que no comentaba cosas nuevas por aquí (es lo que tiene la semana santa)

 Hoy voy a hablar de una charla de ATI en el gdc sobre displacement . El titulo de la charla hace referencia a teselar en tiempo real (esto es, generar triangulos a partir de un proceso matematico). Pero hay cosas que merecen la pena destacar.

 Lo interesante es que hace una comparacion del mundo de la animación y de los videojugos. Los mapas de desplazamiento, y el rigging,  son partes fundamentales en una producción real. Las escenas pueden llevar facilmente más de 30 millones de poligonos enviados a render, y los personajes pueden llevar literalmente cientos de controles de animacion/pesos de vertices, etc

La tendencia imparable es la de equiparar soluciones que ya están muy probadas en un pipeline de animación, a un pipeline de videojuegos. Y de eso va esta presentacion. Veremos cómo se aplicar el modelado basado en subdivision a un videojuego.

A la hora de aplicar subdivisión, hay que mirar algunas cosas en el pipe del juego. La animación suele ser aplicada a la malla de baja poligonización, y eso puede crear problemas cuando, tras aplicar la animación, generamos la subdivisión. Eso pasa en la animación normalmente, y por supuesto, ocurre en los videojuegos que comienzan a usar este tipo de algoritmos.

El otro problema es el de las coordenadas UV de la malla teselada. No es sólo generar una nueva geometría, también debemos de preservar las uv´s y toda la información necesaria. Aqui se va mucho trabajo en que los cálculos sean correctos, y no tengamos cortes bruscos. Hay una parte matemática seria en cuanto a las bases de espacio parametrico, de espacio baricentrico, etc. Si vais a programar algo de subdivisión, debeis de tener todo esto muy claro.

 El pipe que propone es el de pasar de la malla en baja resolución, a una malla teselada segun nuestros parámetros (cercania a la cámara, tipo de render, etc), y despues aplicar el vertex shader para desplazar los vértices. Esto, comparado al algoritmo de renderman, tiene un coste grande: tenemos que teselar toda la malla, con el gasto de memoria asociado. Pero al menos funciona.

 Otra cosa que propone es teselar despues de la animación, aplicando algoritmos de espacio de pantalla. Esto es, teleselar solo lo que mire a pantalla y cosas similares. Este tema es obio porque si sabemos qué es lo que se va a ver, pues podemos reducir la resolución del triangulo más pequeño. Por ejemplo, si tenemos una textura para darle relieve a los labios, lo normal es que tengamos que teselar muchísimo los labios para conseguir ese detalle. Si los labios están lejos, o simplemente no se vana  ver, podemos aprovechar eso para no teselar esa zona tanto, acelerando la generación de la malla. En general, podemos dividir la geometria en zonas de teselado, pero hay que trabajar con el artista para que esa información sea util. Si no, tendremos qeu teselar todo el personaje a la resolución del detalle más pequeño (esto es, lo suficiente para ver los detalles de los labios) lo que nos puede generar una cantidad infinita de triangulos.

Un tema importante es que debemos de soportar la misma teselación que el programa 3D, porque si no, los artistas estarán dando palos de ciego. La subdivisión cambia bastante con el algoritmo y los parámetros que configuremos... y los modeladores no tienen ganas de perder el tiempo ajustando algo que ndespues no se va a a ver.

 Despues viene el tema de la iluminación. Tema peliagudo porque el desplazamiento nos mete una nuevas normales, y un nuevo entorno de autosombreado (vease parallax mapping y demás técnicas). En este tema la presentación tampoco nos dice mucho, simplemente nos muestra algunos shaders para su estudio.

 La gran ventaja del displacement es que por debajo las mallas suelen ser de baja poligonización. Ahorramos mucho trabajo de animación si trabajamos con la malla sin teselar. Además, los buenos artistas se manejan muy bien con programas como zbrush para sacar detalle, y eso siempre nos va a dar un extra de realismo en el personaje final.

Estos días se ha publicado esta tesis que para los que quieran aprender un poco más sobre montecarlo, metropolis sampling, etc, es muy interesante.

La tesis en sí habla de varias técnicas para acelerar la integración de montecarlo usando la tarjeta. Comienza con una siempre util revisión de laatemática de un path tracer, para pasar a describir qué problemas podemos acelerar con una GPU.

 La tesis nos desarrola el concepto de path (fundamental para bidireccional y metropolis) y su aplicación la instant radiosity. Hay que entrar bastante para explicar la matemática que hay detrás, pero digamos que tenemos rayos que parten de la luz, y despues podremos aprovecharlos para iluminar.

 La técnica para  que describe es la de "interleaved sample patterns", donde en el g-buffer vamos guardando la información necesaria de sampleo. Despue se hacen determinados cálculos guardando en una textura distintos pasos de la iluminación.

Para mi, todo esto de renderizar GI por tarjeta me parece una "ñapa" bastante gorda, sobre todo porque hay muchas cosas que se hacen en espacio de pantalla, con filtros y cosas por el estilo, que creo que es retorcer el algoritmo, ya de por sí complicado.

 De todos modos, de estas tesis siempre se puede aprovechar, al menos, la introducción matemática. Por ejemplo, aqui dedican una parte interesante a explicar el path tracer bidireccional y las "mutaciones" de metropolis.

 Eso sí, las velocidades que sacan son bastante interactivas (3 fps para algun tipo de escenas), pero queria verlo yo con materiales complejos, con capas de distintos bsdf´s y cosas por el estilo.

 La parte final me pareció más interesante. Da metodos nuevos para aprovechar mejor la coherencia de los rayos en metropolis sampling, usando paquetes de rayos (util para aprovechar el SSE y poder hacer varias intersecciones de golpe). La idea es que las mutaciones tengan en cuenta que se envían 4 rayo, por lo que reaprovecha resultaods de test anteriores en los nuevos rayos.

 Esta charla es del año pasado , pero me haparecido muy interesante por la cantidad de imágenes que incluye. Es sobre el killzone 2: Deferred Rendering in Killzone 2. 

 La charla nos explica el pipeline ideal para renderizar usando el geometry buffer (g-buffer), donde se almacenan atributos de la geometria en espacio de imagen. Es una técnica muy usada en animación, para dejar despues que el postproceso genere el fotograma adecuado (además, es la técnica que más dominan los iluminadores y artistas).

El g-buffer no es mñas que renderizar atributos de la malla en un fotograma: la normal, coordenadas de textura, profundidad, altura, id del objeto, vectores de movimiento, etc. Para despues tener un shader que los combine y consiga el resultado final. El "problema" está en que tenemos que renderizar muchas veces la escena, pero la mayoria de las veces rederizamos toda la escena con un simple shader, porlo que será un fotogrmaa muy rápido. En este pdf podemos leer sobre el g-buffer, y una aplicación para render no fotorealista.

 En la charla de guerrilla podemos ver los distintos pases: normal en espacio de vista, pase despecular, pase de profundidad, etc. Y despues usaremos esta información para combinarla en un fotograma final.

 Las tarjetas nuevas tienen buffers en float muy potentes, así que la precisión mejora considerablemente para usar esta técnica. En el momento de sacar el killzone2 no tenían tanta precisión, por eso indican que esto es un problema. Pero en las tarjetas modernas, se reduce la precisión. Pensad que si hacemos 1 normal por pixel, todo el pixel tendrá la misma normal.

 Una cosa que me pareción interesante es que no tienen porque renderizar todo el buffer contnuamente. Por ejemplo, los balazos pueden pintarse por encima. Además, ciertos buffers nos permiten condicionar posteriores renders. Por ejemplo, si el color difuso es negro, podemos no calcular la luz en ese pixel, ya que la multiplicaríamos por negro posteriormente... y cosas parecidas.

 También es interesante ver cuánto se deja a manos del artista, sobre todo en iluminación. El artista tiene mucho control sobre sombras y puede hacer mucho manualmente para ajustar calidad/precio. 

 Interesante charla para conocer un pipeline de render moderno.

 En una entrevista , el CEO de Epic Games nos dice que DirectX puede ser la última API gráfica relevante. Esto es así por algo que parece imparable: la fusión de CPU con otros coprocesadores gráficos superpotentes. En el pasado tuvimos un problema que pudimos acelerar por hardware: el pintar triángulos. Pero hoy en día los probemas son de muchos tipos: inteligencia artificial, colisiones y físicas, etc. Las máquinas del futuro cercano tendrán varios mounstruos de procesado, y hay que pensar cómo aprovecharlas.

 Asi que el entrevistado piensa que eso de pintar por tarjeta al modo tradicional se va a acabar. Que volveremos a la época donde nos escribimos nuestro motor de render, aprovechando los distintos hardwares de cálculo que existen en la máquina: distintos cores, y distintos procesadores adicionales.

 Hay desde luego, un espacio para el que quiera escribir un nuevo motor de render. En el futuro, podremos mezclar cálculos de rasterizado con raytracing, y aprovechar de la mejor forma posible la combinacion de ambos. Podremos tener un motor "hardware" acelerado de forma más optima que la competencia, y no dejar que toda esa parte la realize el driver, como hasta ahora.

 Toda esta postura no me parece para nada descabellada. Es probable que las API´s tipo CUDA permitan en el futuro escribir un motor de render propio, y mezclando distintas tecnologías, podremos combinar distintas posibilidades  para sacar un frame con más detalle. Desde luego, con 16 cores y 4 cores de GPU, hay espacio para dividir tareas, pasadas de render, generación de texturas y sombras, etc.

 ...A veces pienso que las ganas que tiene un programador, en hacer un motor de render, no conoce límites.

Seguimos con charlas del GDC, que me parecen interesantes de comentar, y creo que todos aprendemos mucho con ellas.

La de hoy es una de intel sobre cómo optimizar un motor 3D usando multithreading. Un tema muy interesante (está orientado a DirectX, pero muchas cosas son aplicables en general).

 Lo primero es reconocer el coste del driver gráfico. Aunque nosotros hagamos profile de nuestro juego, el driver también gasta ciclos, y es normal que gaste muchos ciclos. Aunque nosotros no podemos optimizar el driver, si que podemos medir el impacto de nuestras llamadas. Por eso, debemos de tener casos de prueba con contenidos principales y representativos, para conocer el rendimiento general del motor en varias situaciones.

 El futuro es el multicore (incluso en las tarjetas), así que optimizar para varios threads nos dará mucho recorrido en el futuro. Pero los threads tienen un coste. Sobre todo, tenemos que testear que es lo que pasa cuando escalamos en número de cores. 

 Hay que mirar las diferencias entre modelos de driver de windows xp y vista. Vista comienza aofrecer posibilidades para multithread en el driver (aunque no está muy bien soportado todavía), pero el camino apunta a ir por ahí. En concreto, podemos leer un resumen de las capacidades de vista y su WDDM.

 Cuando comenzamos a optimizar el juego, hay que intentar librar al motor de bloqueos. Por eso es muy aconsejable el uso de listas de comandos. En vez de bloquear y mandar una operacion para actualizar la escena, metemos los comandos en una lista, y el motor los procesa cuando puede, librandose así de bloqueos innecesarios usando un patron de productor/consumidor   (obiamente, hay un sistema de flags para que todo esto pueda saltarse si un update es urgente, etc).

 En la presentacion hay varios ejemplos de threads y qué responsabilidad aplicar a cada uno.  Los gráficos son bastante ilustrativos, y es muy interesante echarles un vistazo.

 Tenemos el ejemplo del motor de namco para que veamos ejemplos de qué cosas estudiar de un motor,  cómo detectar lo que parece pérdidas de tiempo, y un resumen de las tareas de los distintos threads (incluyendo físicas, sonido, etc). Me ha gustado especialmente el gráfico de los mensajes que se envian a los threads.

 En definitiva, una charla muy buena si quereis desarrollar un motor de render, aunque sea básico, pero que escale bien con muchos cores, que será lo que ocurra en el futuro.

 Otra charla del GDC, y con esta creo que es la última.

 Esta está muy chula, sobre todo para alguien que trabaje en un departamento de efectos, o quiera currarse una demo espectacular. Trata de cómo renderizar hierba y vegetación aprovechando tecnología multicpu.

 Normalmente, la vegetación se diseña usando mapas de densidad, que representan zonas de vegetación. Estos mapas suelen ser de distintos tipos, indicando diferentes vegetaciones. El sistema debe de poder aprovechar esos mapas, renderizar con distitnos niveles de detalle (y por tanto, distintos algoritmos), y debe de ser rápido descartando geometría. 

  Los niveles de detalle cambian la forma de pintar la geometría, usando billboards alienados a cámara cuando es preciso, o ni siquiera eso si están muy lejos.

 La charla explica un algoritmo en varios pasos, descartando rápidamente cuadrados con densidad 0 antes de determinar detalles de vegetaciñon, y gestionando solo los rectángulos visibles con densidad. Cuando tenemos las listas, mandarlas a un proceso que las procese en multithreading, para generar la vegetación.

 La charla comenta que se han dado cuenta que es mejor mandar muchísimos trabajos a la cola que no tener grandes gestores por CPU. Esto es compatible con mi propia experiencia, ya que los multicore tienen problemas al acceder al bus de datos simultaneamente. De todos modos, tendríamos que ver cómo funciona eso cuando el número de cores aumenta.

Cada trabajo recibe unos trabajos para generar la vegetación, como la semilla de "randomización", o los tamaños necesarios. Los trabajos deben de estar libre de dependencias, para evitar las esperas. El gestor de trabajos debería de dar poca prioridad a este tipo de trabajos (frente a tareas del juego o de físicas).

 Una vez terminado esto (aqui hay esperan  a que los trabajos terminen) , renderizamos la vegetación. Cada nivel de detalle va en listas separadas, ordenadas de tal manera que aprovechemos el test de alpha y el test de profundidad para renderizar menos píxeles.

Seguimos con las charlas del GDC08

Esta vez le toca a un tema complejo de entender al principio, los esféricos harmónicos y la iluminación global por tarjeta.

Esta técnica sirve basicamente para generalizar un mapa de entorno. Hay una matemática algo compleja, que permite transformar un mapa HDR en una serie de coeficientes, reduciendo seriamente las necesidades de almacenamiento de un shader y aumentando mucho la velocidad de render.

Perdemos mucha definicion en el mapa. Sería omo tener una textura hdr y hacerle un grandísimo blur para quedarnos sólo con las partes más iluminadas, pero en realidad, eso no se va a notar en la escena (nos da igual si el mapa HDR tiene mucho o poco detalle, lo que queremos es que ilumine de forma realista). Los SH (spherical harmonics) reducen la textura a una serie de coeficientes, que sirven de mapa de entorno.

 En la charla habla de distintas formas de iluminación tipo "GI", nos habla de ambient occlusion, que hace un efecto chulo, nos habla de la técnica de radiosity normal maps desarrollada en valve para el HL2 (que se basa en guardar 3 lightmaps con informaciñón de la luz).

 El shader de tarjeta usa PRecumputed Radiance Transfer, que es retomar el antiguo algoritmo de radiosity, pero almacenando sólo ciertos datos de cuanta luz se transfiere en un polígono. El tema es que necesita conocer visibilidades, pero esto se puede precalcular. Hay mucha documentaciñon sobre esta técnica, y si estais interesados en el GI por tarjeta, desde luego es lo que necesitáis mirar, ya que todos los papers van por aquí.

 La presentación nos hace un resumen del shader, que es bastante complejo matemáticamente. Hay que calcular los factores de spherical harmonics, calcular los factores de PRT, comprimirlo para que no ocupe demasiado (la presentaciñon nos da algunos datos para reducir el número de bits de los factores), y realizar la integral (que es una suma de todos los factores) usando los coeficientes de esfericos harmónicos para pintar.

En resumen, que es una técnica que lleva mucho tiempo para programar (os puede llevar meses tener esto funcionando), pero que permite sacar unos resultados muy rápidos en tarjeta. Lo que os he escrito aquí es un resumen muy muy vago, cada paso es un desarrollo complejo en sí mismo.