Dicen que un poco de estrés no viene mal

Pero a mí me daban dos!

Como es evidente viendo el grado de actividad del blog en las últimas semanas, mis obligaciones diarias no me dejan mucho tiempo para currar en los siempre entretenidos ejemplos que tanto me gusta hacer. :( Pero hoy aprovecho esta pequeña entrada para anunciar que se ha abierto un nuevo blog donde mi grupo de master y yo iremos posteando avances de nuestro proyecto y demás chorradas que se nos ocurran (fotos a lo 'making of', arte conceptual, lloros personales, etc).

No os perdáis The Hardcade Project!

Y después de tanto tiempo...

nuevo ejemplo subido! En realidad lo subí anteayer, pero no he tenido tiempo de comentarlo hasta ahora. El escogido ha sido el de toon shading, así que ya se puede trastear con él en el lugar habitual.

Ahora sí

Saludad a mi nuevo amigo:


He podido hacerme con la expansión del DooM 3 y así como el Lost Soul no chutaba con el cargador de Rubén, con el Forgotten no ha habido problema, así que él será el elegido para aparecer en el ejemplo de shadow mapping omnidireccional. No sé si liarme a meter algún detalle más como alguna partícula de fuego detrás de él para que realmente parezca el foco de luz ya que no quiero complicar el tema más de lo necesario, pero ya lo decidiré.

El ejemplo de toon shading no lo he tocado demasiado, pero ayer me dediqué a limpiar un poco el código y meter alguna chorrada como diferentes modos de visualización (sin siluetas animadas, sin siluetas, con iluminacion "normal", etc). Próximamente más!

Toon orgy!

Esto es un no parar. Hoy se me ha ocurrido un método para la animación de las siluetas y bueno... un video vale más que n-cientas palabras! (Es recomendable ir a YouTube y verlo en "Alta Calidad")



Lo malo es que para conseguirlo he usado VTF (Vertex Texture Fetching), así que la demo sólo funcionará en Xbox360 y PCs con gráficas nVidia a partir de la GeForce 6... Básicamente lo que hago es trasladar los vértices a través de su normal de forma "aleatoria". ¿Cómo conseguir esa aleatoriedad? Cuando se carga la aplicación, genero una textura de floats y la relleno de valores aleatorios, y luego hago un lookup de estas valores desde el vertex shader con unas coordenadas de textura que dependen de la posición del vértice y un cierto offset aleatorio que genero cada cierto tiempo (como la animación de los trazos a lápiz). Creo que ya ha llegado el momento de limpiar cosas y prepararse para subirlo... ^^

Olescul efex!

Uau, esto parecen los viejos tiempos... xD Hoy he probado un par de cosas en el ejemplo de toon shading... bueno, en realidad tres cosas pero una la he dejado para más adelante.

Por un lado he añadido la animación de los trazos a lápiz que se ve en las partes sombreadas. Esto era realmente sencillo, simplemente es modificar las coordenadas de textura de los trazos cada cierto tiempo (normalmente mayor que el que se tarda en pintar un frame) según lo que dicte un número aleatorio. La verdad es que creo que queda medianamente bien, aunque según la textura usada y la cantidad de pantalla que ocupen estas zonas sombreadas, se puede notar un poco demasiado el 'tileado'... Pero bueno, yo no estoy como para ponerme a hacer texturas perfectas.

Por otro lado he cambiado la forma de dibujar la silueta. Lo cierto es que he añadido una silueta más. :P Aparte del efecto de los trazos que vi en el Valkyria Chronicles y que me inspiró para hacer este ejemplo, quería intentar otra cosa con las siluetas para que el conjunto quedara un poco más espectacular. Y eso que quería probar es lo que se ve en Okami. En este juego (y en muchos otros antiguos como Jet Set Radio) no se usa una detección de siluetas en el pixel shader como se hace hoy en día (y como estaba hecho en la foto de ayer), sino que se usa un truco bastante curioso. Se pinta la geometría normalmente con el sombreado cel "de toda la vida", y luego se giran las normales, se escala un poco el modelo y se pinta de negro. Es decir, se cambia el tipo de culling, se pinta de negro y un poco más grande y voilà, ya se ven unas bonitas siluetas. No son tan precisas como con el método más moderno, pero antiguamente era lo más rápido y además permite hacer ciertas cosas...

Esto me lleva a lo tercero que he querido probar. En los videos de Youtube no se ve demasiado bien, pero creo recordar que en Okami aparte de un cel-shading muy sencillito, se movía la geometría de las siluetas para simular el efecto de que se estaba pintando a mano toda la escena a casi cada frame. Eso fue un detalle que sencillamente me enamoró en su día. He hecho un par de pruebas para representar el mismo efecto y no me ha gustado demasiado el resultado, así que lo he dejado para más adelante. Básicamente, el problema es mover cada vértice de manera suficientemente sutil, aleatoria e independiente de sus vecinos como para que el efecto no resulte antinatural. No se, se me ocurren un par de maneras pero ya es tarde y hay que descansar.... lo justo.

Ah! Y de regalo otro video! En este se ven las siluetas "nuevas" (aunque mantengo las antiguas para que haya más detalle) y la animación de los trazos.

Culo inquieto

Si hay alguien que sigue aunque sea un poco este blog, ya se habrá dado cuenta de que mi capacidad de mantener mi atención sobre algo durante períodos medianamente prolongados de tiempo es... limitada, por decirlo de alguna manera. Y para demostrarlo, aquí está la entrada de hoy.

Todavía no he acabo de dejar lista las sombras omnidireccionales, que ya me han entrado ganas de probar otra cosa. La idea la he sacado de un juego de PS3 llamado Valkyria Chronicles. El juego en sí no me llama un carajo, pero usa un estilo de cell-shading que me gustó mucho la primera vez que lo vi. Tiene la peculiaridad de que las zonas sombreadas tienen un efecto de esbozo a lápiz que me resultó interesante, y no sé porqué hoy me ha dado por probarlo. Todavía no está acabado ni de lejos (sólo le he podido dedicar un rato), pero he avanzado lo suficiente como para tener ganas de seguir cuanto antes! ^^

Vuelven los videos!

Primero, lo bonito (o lo que yo espero que sea bonito :P):



Y entonces, qué es lo feo? Bueno, realmente el ejemplo en teoría ya está, pero en vez de una esfera blanca cutre para representar el punto de luz, quería poner algún modelo interesante, en concreto quería usar el siguiente:


Por si no se conoce, es un Lost Soul de DooM 3. Podría añadirlo fácilmente con el importer de Rubén, y como tiene una llama de fuego por detrás queda bastante bien en la escena. Pero no se porqué sólo carga las mandíbulas y no el modelo entero, así que voy a tener que buscar una alternativa (quizás un Forgotten del Resurrection of Evil, pero ahora no lo tengo a mano).

En fin, que ya sólo queda afinarlo un poco para poderlo subir. Próximamente más!

Sacando de donde no hay

Pese al curro, el master y los asuntos personales, he conseguido encontrar algo de tiempo para esto:

Quizás no se ve demasiado bien en la tira de fotos, pero se trata de shadow mapping omnidireccional. Ahora mismo lo tengo en fase de "dejar bonito", pero lo básico ya está implementado y funcionando "perfectamente" (tiene algunos fallos propios del tipo de técnica usada, ya entraré en detalles en otro momento).

Ahora voy a tener algo de trabajo extra, pero espero tenerlo listo para el fin de semana. ^^

Ya queda menos...

Para que empiece lo bueno. Creo que el bajón de novedades y trabajo en general se ha notado (el trabajo no remunerado, por supuesto), y no estoy seguro de poder recuperar completamente el ritmo en unos días... Después de las vacaciones la carga de curro ha sido bastante espectacular, y la próxima semana ya comienza el master de videojuegos que cursaré durante el resto del año y gran parte del que viene, así que voy a estar realmente ocupado... En fin, a ver qué tal lo llevo, pero más vale que disfrute estos días "tranquilos" porque lo que se avecina va a ser durillo.

Aún así ha habido algunas novedades, como que hace unos días salió la versión beta de XNA 3.0, con interesantes novedades como un soporte mucho más currado del formato FBX (ahora acepta múltiples texturas por modelo, por ejemplo) y nuevos añadidos a las clases de tratamiento de sonido que se presentaron en la CTP. Una de las cosas más interesantes es la función GetVisualizationData, que permite obtener en tiempo real información de la frecuencia y los samples de la música que esté sonando en ese momento desde el nuevo MediaPlayer (la clase del framework, no el programa obviamente xD). Hace un par de días me puse 5 minutos y me monté una chorrada como ésta:

En realidad no es nada, simplemente he puesto de manera visual lo que devuelve esta función, pero sería muy interesante estudiar qué cosas se podrían llegar a hacer (en concreto juegos que se adapten a la música, que era algo que he querido probar desde hace mucho tiempo). Yo no entiendo mucho de sonido, pero si algun día tengo un rato (sigh) le echaré un vistazo.

Forzando la máquina

Estos han sido unos días duros y tremendamente divertidos a la vez. La semana que viene pillo vacaciones (esta vez un poco más decentes, no cuatro míseros días) y en el curro se están encargando de recordarme cada día porqué debo tener ganas de pillarlas. Y claro, después de estar toda la semana encerrado te dan ganas de liarla por ahí y olvidarte un poco de todo, así que el fin de semana pasado me fui a las fiestas de Barbastro (que por cierto son tremendas, nadie debería perdérselas) y ahora en vacaciones me iré una semanita a Suecia a pasar frío y estar bien lejos.

Pero bueno, no he estado completamente parado. He afinado un poco el tema de las nubes (intentaré subirlo antes de irme, quizás mañana o pasado) y he tocado alguna cosilla de Arles aquí y allá. Javi ha mejorado mucho el tema de la gestión de la escena y yo he añadido unas estadísticas de rendimiento para el render del editor, aparte de la posibilidad de quitar la limitación de frames por segundo típica de XNA.


Como Rubén está terminando su juego para el BDP y yo me piro por ahí, este tema estará bastante parado un tiempo, pero ya se irán haciendo cosas.

¿ A qué huelen las nubes?

A Perlin noise! Ya están medio terminadas, y este es el aspecto que lucen:



Se puede modificar la velocidad de las nubes, su densidad, la cantidad de superficie que ocupan... y próximamente la dirección.

Al principio iba a usar simplex noise (una modificación del perlin noise "clásico" que en teoría da más calidad de imagen), pero el shader era algo más lento y personalmente me gustaba menos cómo quedaba (en la imagen del post anterior se ve este tipo de función). Total, que se ha quedado el perlin de toda la vida y ya da el resultado deseado.

También había pensado calcular un normal map a partir del "heightmap" que se genera y así iluminar de forma más molona las nubes, pero por ahora lo he descartado porque no sé si valdrá la pena la pérdida de rendimiento que se sufriría.

Lo siguiente debería ser algo más volumétrico...

Presentando Arles

Alguna vez lo he comentado, pero hasta ahora no había enseñado (y en la página del proyecto en Google Code tampoco se ve nada). Éste es el aspecto que tiene actualmente el editor de terrenos en el que están trabajando los coordinadores de XNACommunity, Arles:


Por ahora todo es muy, muy básico, pero hay algunas cosas de interfaz interesantes ya implementadas (como la posibilidad de relizar 'Deshacer'/'Rehacer') y ya está prácticamente integrado del todo mi último skydome con atmospheric scattering.

Se avanza poco a poco porque lo hacemos en los ratos libres (que por ejemplo en mi caso son escasos), pero seguro que acaba siendo algo interesante. En la parte derecha del blog hay un link a la web del proyecto, donde ya se puede consultar el código y trastear con él.

Y aprovechando que se habla de Arles, he estado un par de días mirando una manera sencilla de simular otro efecto atmosférico, las nubes. La idea era usar un método sencillo y sobre todo rápido para representarlas sin entrar en soluciones mucho más costosas como nubes volumétricas y cosas por el estilo. Un primer intento ha dado este resultado:


Es una primera prueba y no he "tuneado" valores, pero aunque no se ve en la foto, en movimiento queda bastante curioso. Lo malo es que he notado bastante la diferencia de rendimiento, así que tendré que probar más a fondo si realmente vale la pena. No sé, quizás incluso monto un ejemplo de esto...

Ya queda poco...

...verano (aunque por la temperatura que ha habido estos días parece que hace tiempo que terminó), y me ha entrado una especie de ansiedad por aprovechar al máximo los días libres que tengo, y no precisamente delante del PC... En parte creo que lo necesitaba, hacía mucho tiempo que no salía y perdía algunas neuronas de forma consciente, y cuando empiece el master no creo que me pueda permitir muchas salidas.

Pero esto no significa que haya estado 100% parado, y he seguido haciendo algunas cosas. Ya he subido el nuevo componente de Skydome con atmospheric scattering. Al final creo que ha quedado bastante apañado y ya he empezado a pasarlo a Arles.

Habrá que ir pensando que será lo siguiente... por una vez estoy en blanco! o_O

Como en el campo

Ya he dejado prácticamente listo el skydome tal y como quería que quedara. Respecto a lo que había ayer, he añadido las estrellas (un porrón de ellas, quizás demasiadas ^^U) y un ligero brillo alrededor de la luna. Como ya se puede imaginar, la luna y el brillo no son más de dos quads orientados correctamente respecto a la posición del sol y las estrellas son una textura que se aplica sobre la geometría del dome, pero pese a ser tan sencillo da un aspecto bastante aceptable a la escena. La transición entre día y noche de estos elementos no ha quedado tremendamente realista, pero creo que para un juego da perfectamente el pego. No puede faltar teh video:



Como siempre, YouTube da una calidad de imagen bastante lamente y apenas se ven las estrellas, así que recomiendo verlo en "alta resolución".

Creo que poco más voy a hacerle a este ejemplo, así que es de esperar que esta semana ya lo cuelgue.

The Lone Wolves are Back!

Ya estoy de vuelta! La verdad es que incluso me da un poco de pena, porque estos días me lo he pasado muy, muy bien. Estuve unos días en Granada visitando a unos colegas, y como siempre fue una locura continua de risas, tapas y cerveza. Ahora estoy en el curro casi peor de lo que estaba antes de irme... xD Pero bueno, poco a poco voy pillando el ritmo y hoy he reanudado un rato el trabajo sobre el nuevo skydome.

Hoy pensaba dejarlo por finiquitado, pero luego he tenido la sensación de que realmente no estaba del todo satisfecho con el resultado. La representación de la luz y del scattering de la misma queda estupendamente, pero el aspecto era bastante decepcionante cuando se hacía de noche. La representación es correcta (no hay luz del sol), pero se ve todo demasiado negro y vacío, así que he decidido añadir algún detalle más. El primero es éste:


Por ahora está hecho muy a lo cutre, pero ya da un poco de alegría al cielo nocturno y es el primer paso para algo un poco más curioso.

Hoy estoy muy vago y no voy a hacer nada más, pero a ver si mañana sigo un poco. ^^

Dando los últimos coletazos

Mañana ya me largo, pero no quería irme sin dejar listas un par de cosas. Lo primero es que ya he colgado la demo de metaballs donde siempre. Y lo segundo es que ayer conseguí dejar casi listo un nuevo ejemplo de skydome con atmospheric scattering, esta vez sin texturas pre-generadas, todo se calcula en tiempo real en la GPU con un estilo muy similar al usado en Crysis. Además ahora la geometría del skydome se genera por código y no es un modelo "externo", así que podré dejar un componente bastante independiente y poco pesado. Aquí está el video que lo muestra:



La niebla no concuerda demasiado con el color de la luz, pero porque sigue siendo la que usé en la demo de skydome.

Esta será una de las posibles técnicas que estarán disponibles en Arles para el renderizado del cielo. ^^

Qué le está pasando al probe Alex...

... que hace mucho tiempo que no sale. Pues no pasa nada, simplemente estoy en la semana anterior a irme de vacaciones (por fin, joder! Hace 3 años que apenas tengo más de 2 o 3 días seguidos de descanso ^^U).

Pero eso no significa que esté especialmente vago, que también, ya que no he parado. El tema de las metaballs está un poco parado y no conseguí hacerlo funcionar bien en 360, pero el ejemplo de PC está terminado y lo colgaré como muy tarde este fin de semana. Tengo algunas ideas para intentarlo rular en la consola, pero a ver cuando saco tiempo para probarlo... Después de eso no se me verá el pelo en unos cuantos días. :)

Y por otro lado en XNACommunity hemos empezado un proyecto muy interesante (y tocho). No hay mucho que enseñar por ahora, pero ya está disponible para poder echar un vistazo. Pronto iré posteando más detalles con lo que vayamos implementando, pero en pocos días Javi ya ha puesto algunas cosas interesantes, y yo estoy trabajando en un nuevo skydome con un "verdadero" atmospheric scattering que si sale bien quedará de lujo. Quedaros con el nombre: Arles.

Problemas en las bolas

Llevo un par de días probando algo nuevo, y aunque no me lo esperaba he avanzado lo suficientemente rápido como para tener casi listo un nuevo ejemplo para PC:



Son las típicas metaballs o "blobs", pero generados mediante un efecto de post-proceso. Esto como siempre tiene su parte buena y su parte mala. La buena es que es muy rápido (ahora mismo me funciona a unos 600 fps pese a que uso un par de rendertargets de 64 bits), y la mala es que al no tener en cuenta la profundidad, a veces se pierde mucho la sensación de perspectiva y se mezclan bolas que quizás no deberían... Eso seguramente será un problema donde iba a usar este efecto, así que quizás tengo que hacer algunos cambios de concepto. ^^U

En fin, que por un lado estaba contento porque había quedado bastante bien en poco tiempo, pero por otro acabé sumamente cabreado porque no hubo manera de hacerlo funcionar bien en Xbox 360. En el ejemplo se usan point sprites para pintar las diferentes bolas, y por alguna razón que todavía no se explicar, en la consola no he conseguido modificar el tamaño de estos sprites para dar sensación de 3D. Y además en general todos los shaders usados dan algún problema, ya sea con las coordenadas de textura (si, he usado SPRITETEXCOORD en el caso de ejecutarlo en la consola) o en el paso final de post-proceso, donde no hace lo que debe hacer.

Necesito que esto funciona en ambas máquinas, así que será lo que trabaje en los próximos días.

A otra cosa, mariposa

Acabo de subir a XNACommunity el ejemplo de fluidos! Ahora toca ponerse con otro tema, que ya digo que será completamente diferente. Ya tengo una idea de qué hacer, pero hoy no voy a tener tiempo de empezar hoy, así que mañana al lío.



Por cierto, si se pausa la simulación en la demo, se puede seguir echando tinta y por tanto se sigue sumando la velocidad del fluido, así que si luego se reanuda se generan animaciones y formas bastante curiosas. ^^

Por fin se acabó

Bueno, tampoco es que haya sido una tortura, pero ya tenía ganas de terminar. Acabo de dar por finalizado el ejemplo de los fluidos 2D. He añadido un par de cosas puramente estéticas y mejorado el rendimiento (unos 15 milisegundos en ambas máquinas), además de cambiar un poco la funcionalidad (el fluido ya no va hacia arriba automáticamente, sino en la dirección del cursor) y añadir soporte total para Xbox 360. Un ejemplo del resultado final es esto:



Ahora en mi máquina va incluso un poco demasiado rápido (no hago ningún tipo de control en ese aspecto), pero creo que después de todo no ha quedado tan mal. Durante este fin de semana acabaré de pulir detalles en el código (aka limpieza de mierda) y lo colgaré, a ver si gusta. ^^

Ya grabaré el video correspondiente cuando vaya a colgar el ejemplo. ;)

Decepcionado

Y mucho, además. Hoy he usado la suscripción gratuita al Creators Club que dan al registrarte en DreamBuildPlay (es un añazo gratis!). Me hacía bastante ilusión probar mis ejemplos en la consola, y al principio todo ha ido bien... He probado un par de ejemplos antiguos y funcionaban perfectamente, pero luego ha llegado el momento de probar el que realmente quería poner a prueba.

He creado un proyecto de los fluidos para Xbox 360, he toqueteado un poco el código para que funcionase sin ratón y... F5... Deploying... Running... Zas, lento de narices. Es que no iba ni la mitad de rápido que en PC.

He cambiado alguna cosa más para tener información más precisa de cuánto estaba tardando:

- PC: Fluido de 100x100 -> ~25 ms
- Xbox360: Fluido de 64x64 -> ~65 ms

Si, eso es más del doble de tiempo con una matriz de casi un cuarto del tamaño original. La diferencia es muy grande, *enorme*, sobre todo cuando en principio había metido el thread de la simulación en su propio core... Sabía que XNA era bastante lento en la consola, pero no imaginaba que tanto.

Esto me ha trastocado un poco los planes, y me ha dejado un poco de bajón. ^^U

Pero bueno, me ha servido para ver que con el fluido de 64x64, el Gaussian Blur que puse no servía para prácticamente nada porque lo hacía sobre una imagen muy pixelada puesta sobre un backbuffer a una resolución bastante alta. Esto podría parecer un palo más, pero en realidad me ha servido para mejorar algo bastante interesante... como la Xbox (y muchas gráficas actuales) no permitía filtrar por hardware la textura de la tinta, he decidido implementar el filtro bilinear directamente en el shader, a mano. Bueno, irá como una tortuga pero por lo menos se ve bonito. Seguramente este fin de semana lo dejaré como pueda y lo subiré ya.

OMG no hay foto! o_O

Pacheando

Estos días he probado el tema de los fluidos en otros PCs para comprobar el rendimiento en máquinas bastante diferentes. Parece que aguanta bastante bien aunque al guardar el color en una textura de 128 bits, hay muy pocas gráficas que la puedan filtrar a la hora de pintar (básicamente todo lo que no lleva una DX10 lo pintará pixelado).

En vez de cambiar la manera de guardar el color (que tenía más curro de lo que parecía al principio), he tomado la decisión de aplicar un Gaussian Blur como efecto de post-proceso, de manera que se suaviza la imagen cargando casi todo el trabajo en la GPU que en este ejemplo no hace prácticamente nada. El resultado es bastante bueno y rápido, así que es muy posible que lo deje así finalmente.

Ah, también añadí la posibilidad de sacar screenshots. :P

Ya casi...

Ya está cerca, parece que por fin voy acabando cosas y no sólo las estoy empezando. He añadido otro detalle más al simulador de fluidos, y a falta de un par de cosas ya va teniendo el aspecto que quería que tuviese.



Por desgracia he añadido los colores demasiado rápido y sin pensar, y como resultado tengo que ahora mismo necesito pintar la simulacion sobre un rendertarget de 128 bits, lo cual limita mucho el rendimiento y las plataformas donde quiero que se ejecute (no cumplo uno de los puntos que requería en la última entrada sobre esta demo).

Total, que tengo que volver al punto de la optimización, pero al menos ya sé que funciona el tema de los colores. A ver si este fin de semana lo puedo finiquitar...

El chico de los recados xD

Me han vuelto a pedir que haga un pequeño shader para el Model 2 Emulator, y yo encantado de poder aportar algo más a un programa tan conocido. ^^ Esta vez se trata de imitar el aspecto de los antiguos monitores arcade con un efecto normalmente conocido como "scanlines". En muchos emuladores se permite activar un efecto similar, y hay mucha gente que lo ha pedido para éste. Esta tarde me he puesto un momento y ya tengo una versión más o menos bien afinada:


Al ser un efecto procedural y no una textura que se aplica encima de la imagen original, no hay efectos raros al cambiar de resolución y cosas por el estilo. A ver si gusta y veo otro shader mío funcionando en algo que usará mucha gente. ^^

Aunque parezca mentira también he seguido con mis cosas de XNA, y ya he empezado a adaptar el simulador de fluidos para soportar varios colores simultáneos. Lo malo es que estaba muy cansado (está siendo una semana un poco dura) y he avanzado muy lentamente. A ver si mañana le doy más ritmo y pronto puedo colgarla. ;)

Dayyytooonaaaaaa!!

Let's go away! Let's go away! Menudo temazo y menudo juegazo. ^^ Finalmente ElSemi ha añadido mi shader a su emulador de Model 2, y Daytona USA ya luce unos colores mucho más agradables y fieles a la recreativa. He grabado un video con una WIP de la nueva versión del emulador donde se muestra cómo se ve actualmente:



La calidad de imagen es lamentable, pero podeis forzar a YouTube a enseñaros algo más decente añadiendo '&fmt=6' o '&fmt=18' al final de la URL del video. Con 6 se ve a 60fps con una calidad decente y con 18 se ve mucho mejor, pero perdiendo algunos frames por segundo.

Lo dejo linkado igualmente:

VIDEO Calidad Media 60 fps
VIDEO Calidad Alta

Pecado capital

Estoy un pelín perezoso. Será el verano, el calor, que aún no he hecho vacaciones (y llevo como 3 años sin hacer) o lo que sea, pero el cansancio diario me puede y avanzo poco.

Aún así he sacado algo de fuerzas para seguir con el tema de los fluidos, y ya va teniendo una pinta más interesante. Estos días básicamente me he puesto a mejorar un poco el rendimiento, he pasado todo el cálculo de la simulación a un thread secundario (que será directamente un core distinto en 360), dejando el principal para el render (que es una chorrada y va rapidísimo). De esta manera funciona bastante más suelto aunque sigue siendo muy exigente en cuanto a CPU. A ver si mañana me monto algo para saber realmente a qué velocidad funciona (ahora mismo no tengo más información que los frames por segundo de render, que no dice gran cosa) para poder ir probando más cosas. Actualmente tiene este aspecto:



En el video también se ve que he añadido un par de funcionalidades más (echar tinta con el ratón y "empujar" el fluido), pero el cambio más importante es el rendimiento. El ejemplo final no distará mucho de esto, pero si no se me quitan las ganas quiero probar un par de cosas más:

- Echar tinta de varios colores a la vez (esto puede ser bastante costoso, así que a lo mejor lo pruebo y luego lo quito ^^U).
- Hacer el ejemplo 100% compatible con Xbox 360. Ahora mismo se llama a funciones típicas de C++ (mem_cpy y memset) y por tanto no funcionaría en consola.

Y bueno, y si al final funciona bien lo de varios colores a la vez, quizás pruebe más cosas que no formarán parte del ejemplo... :P

Ampliando horizontes

Ayer me puse un rato a hacer un pequeño trabajo que me pidió Wesker de SpekSNK. En el foro de esta web (en la que estoy desde hace varios años ^^) está incluido el foro oficial de Nebula, un conocidísimo emulador multisistema que entre otras emula la Neo·Geo. El desarrollador de Nebula, ElSemi, lleva además otro emulador muy conocido de Model 2, la genial placa de SEGA.

Se ve que el sistema que usa esta máquina para calcular el color en algunos juegos es bastante "peculiar", dando como resultado que estos juegos aún no estén emulados correctamente en este aspecto. Se han probado algunos cambios en el brillo del color para intentar acercarse al juego original, pero sin unos resultados realmente satisfactorios.

Lo que me pidieron es que hiciera un pequeño shader que permitiera manipular el color de manera que se pudiera conseguir un aspecto más cercano al arcade sin tocar nada de la emulación (si, es una manera muy cerda de hacerlo, pero por ahora no hay nada mejor).

El shader ya está listo y se pueden hacer cosas como esta (a la izquierda la imagen que da el emu, a la derecha la imagen después de aplicar el shader con una cierta configuración):


Por supuesto es completamente configurable, y precisamente se puede descargar una pequeña demo que permite ajustar diferentes constantes para que los usuarios den su opinión y así añadir al emulador el shader con los valores más "correctos". La demo se puede encontrar AQUI. Todavía no se sabe si el shader se va a incluir en el emulador o no, a ver si hay suerte y gusta.

Ah, también he subido el ejemplo del Component que pinta un texto de LEDs, está en el lugar habitual. ^^

Disperso pero activo

Una vez más me he puesto con una cosa nueva sin tener la anterior terminada. El simulador de fluidos marcha bien y ha avanzado en estos días (sobre todo en la parte de rendimiento), pero esta tarde no me apetecía seguir con él y he preparado algo rápido y sencillo que pueda subir pronto a XNACommunity.

Se trata de un GameComponent que permite pintar texto de manera que tenga el aspecto de una pantalla de LEDs como las que se ven en los marcadores deportivos. En realidad se le podría haber metido cualquier shader al texto, pero necesitaba éste en concreto. Este es el aspecto que tiene:


Como se puede deducir de la imagen, el componente permite configurar cosas como la fuente, el color o la posición, y aunque no se ve en la imagen también se pueden modificar cosas como el tamaño de los puntos, variables que controlan el gradiente de color, etc.

Ahora estoy preparando un ejemplo en el que se ve un posible uso del componente, a ver si me da tiempo de subirlo hoy mismo. ^^

Lo que no te mata...

Después de un par de días muy duros a nivel personal que me han tenido atontado y concentrado a la vez (si, eso es posible), vuelvo por fin con algo que en enseñar. Es muy preliminar y tengo que añadir/mejorar muchas cosas, pero ya empieza a tener buena pinta, y es una parte fundamental de otro pequeño proyecto que quería iniciar a medio plazo.



Antes de ponerme con esto, y después de ver el estupendo motor de raycasting de Nick Gravelyn para conseguir pseudo-3D en el Zune, se me ocurrió lo que yo creía que era una genial. Y la verdad es que era jodidamente buena, pero parece que hay gente que piensa como yo. XD La idea era hacer una pequeña demo de voxels en XNA. Es la técnica usada en juegos como Comanche, Delta Force o el enorme, enorme Outcast. Con este tipo de visualización se podrían pintar terrenos 3D bastante realistas incluso en el Zune, y era algo que aún no se había hecho en XNA. Pero Catalin Zima se me ha adelantado con un buen ejemplo (aunque se ve que va algo lento en Zune), así que tendré que plantearme hacerlo mucho mejor o sencillamente aprender de él y olvidarme. ^^U

Espero a ahora a nadie se le ocurra hacer fluidos... :P

No estaba muerto

Que no, que no estoy parado! Llevo días sin postear nada, pero por una buena razón: no tengo fotos guays que poner. Además han sido unos días movidillos de currículum para arriba y para abajo (si al final sale todo bien ya pondré el porqué de esto ;) ), y trabajo en general.

Ya avisé que me había puesto con una cosa que me llevaría más tiempo de lo habitual, y aún estoy con ello. Ni siquiera he picado una sola línea de código, por ahora me estoy estudiando el asunto porque tiene cierta matemática detrás que me trae un poco de cabeza. Además es muy posible que sea un ejemplo con una filosofía algo diferente de lo habitual, porque no cargará sobre la GPU sino que tirará básicamente de CPU aunque el resultado sea gráfico. Pero bueno, a ver si me sale bien porque mi ratio de fracasos está subiendo peligrosamente. xD

De vuelta a la realidad

Ayer me pasé el MGS4 (el cual recomiendo a todo el mundo), así que podré volver a mis tareas habituales. Hay que ver lo mucho que puede afectar un simple juego a mi vida diaria, estos días lo único que hacía era ir a trabajar y jugar. xD

En fin, que intentaré dar los últimos toques al ejemplo de deferred rendering y seguir con cosas nuevas.

Pequeño parón

Ayer por fin pude comprar el Metal Gear Solid 4, así que seguramente los próximos días voy a estar un poco más parado de lo habitual. xD Aún así me dio tiempo a colgar el ejemplo de Bubble Shader en el lugar habitual, y he empezado un nuevo tema que me llevará algo de tiempo (aunque no olvido la demo de deferred y no creo que tarde demasiado en colgarla, quizás la semana que viene si no hay nada nuevo).

No hay mucho más que comentar, así que para que el post no quede tan soso, dejo una bonita foto de la pompa de jabón. ^^

Un fin de semana menos excitante de lo esperado

Quería jugar al Metal Gear Solid 4, joder. Según Konami es por la huelga de transportistas, yo digo que es una plafinicación de distribución lamentable (lo del paro no se sabía hace sólo dos días). Hay gente que considera a esta saga el anti-juego por los muchos videos que hay y el "poco" contenido jugable, pero a mi me encantan como pocos. En fin, no pasa nada por esperar unos días más, tengo entretenimiento para rato...

Como hoy tampoco tenía mucho tiempo y he tenido una semana bastante durilla en el curro, me he vuelto a poner con algo ligero como las pompas de jabón:



Iba a poner una escena más trabajada como un cuarto de baño y varias pompas volando por ahí, pero es difícil encontrar un modelo que me guste y tal y como está ahora también queda bastante bien (además se puede ver bien el reflejo del skybox).

El efecto es rapidísimo (a mí me funciona a unos 2500 fps), así que debería tener un buen rendimiento en casi cualquier máquina.

Jugando a mi manera para despejar la mente

Hoy he dedicado mi tiempo libre a otras cosas que no son las habituales y no tenia muchas ganas de ponerme con el ejemplo de deferred, pero he podido jugar un poco con un efecto un poco tonto pero que da un resultado muy curioso:


Si, es una burbuja de jabón. ^^ En movimiento queda bastante realista, y es un efecto muy sencillo que se puede ejecutar incluso en tarjetas que sólo soporten Shader Model 1.1. Ahora me toca pensar un ejemplo donde pueda meterla(s). :P

Revisiting cosas antiguas

Hasta el momento siempre que he querido hacer motion blur he seguido la misma técnica: guardarme dos matrices ViewProjection (la actual y la del frame anterior), generar un vector de velocidad 2D en el vertex shader y pasarlo al pixel shader para sacar estas velocidades en una textura y así usarlas en un paso posterior para "blurrear" el frame.

Por norma general esto funciona de lujo y es my sencillo de implementar, pero tiene un gran fallo. Como se calculan las velocidades por vértice, puede ocurrir que algún vértice de un polígono quede fuera del frustum y otros dentro, y entonces al hacer clipping se le va completamente la olla ocurriendo cosas como esta:


Efectivamente, esto no mola un carajo. ¿Cómo solucionarlo? La idea es calcular la velocidad por píxel. Es mucho más costoso pero abordable hoy en día. En principio se puede reconstruir la posición en world space de un punto en el pixel shader sabiendo su profundidad. Basta con multiplicar el punto en cuestión en screen space con sus coordenadas de la forma (x, y, depth, 1.0) por la matriz ViewProjection inversa y dividirlo después por la componente w que le queda después de esta multiplicación. De esta manera se consigue otra vez su posición en el mundo 3D. Para conseguir el vector de velocidad buscado sólo queda multiplicar este punto reconstruido por la matriz ViewProjection del frame anterior y ver la diferencia con el actual.

Ahora es cuando debería enseñar la foto molona de cómo queda siguiendo este nuevo método, pero no la tengo. No sé porqué todavía no he conseguido que funcione, y no veo que esté haciendo nada mal. Estoy un poco cansado así que lo dejaré por hoy, pero ahora voy a estar pensando en ello hasta que pueda volver a ponerme. Qué rabia.

Las prisas son malas

El cabreo que me entro el otro día con el tema de XNA 3.0 CTP fue de lo más absurdo, ya que era una cagada mía. Pero bueno, rectificar es de sabios aunque ahora me de rabia el motivo por el cual no funcionaba. Se ve que la función que quería usar está disponible sólo si se desarrolla para Zune, y queda deshabilitada al trabajar en Windows (hay que recordar que en la CTP no se puede hacer nada en Xbox 360). Total, que me quedo sin probar lo que quería, y ya me había ilusionado... Espero que en la versión final esté solucionado.

Por otro lado ayer me puse a grabar un video del estado actual del ejemplo de Deferred Shading. Es una pena que con la calidad de imagen que da YouTube apenas se pueda ver el motion blur.

Qué rabia da!

Estos días tengo a mi sobrinilla en casa, así que después del curro tengo poco tiempo para hacer nada (¡pero no viene de eso el título del post!). Aquí la vemos en su nuevo bólido:



Qué mona ella. ^^

Lo que me da rabia es que estaba probando unas cosillas con XNA 3.0 CTP relacionado con el nuevo namespace Media (que en principio es para trabajar con el Zune, pero en Windows ofrece una manera sencilla de manejar sonidos con XNA sin tener que pasar por XACT), cuando de repente no me pilla una función de la clase Mediaplayer sin ninguna causa aparente. No aparece en la lista de métodos y si lo pongo a saco no compila, cuando hay varios ejemplos en la red usando esa función. No sé si es porque tenía en marcha también el VC#2005 y se le ha ido la olla con los frameworks, pero me he cabreado y lo he dejado. Para un rato que me pongo me toca las narices que ocurran cosas tontas como esta.

En fin, para aliviar un poco mi furia (:P) he añadido en un momento el postproceso de motion blur al ejemplo de deferred shading. Tal y como está ahora el código, en los casos de mayor coste (cuando se procesan todas las luces y éstas ocupan casi toda o toda la pantalla) me va a unos 270 fps. Puede parecer que vaya a un gran rendimiento pero tengo comprobado que manejando yo cifras similares, al probar los ejemplos en otros PCs la cosa iba bastante peor (parece que no me puedo quejar de mi gráfica ^^), así que voy a intentar afinar un poco ese aspecto.

Hay cosas que no creo que cueste demasiado mejorar (por ejemplo el número de cambios de estado en la gráfica durante el render de un frame, que son bastantes actualmente), así que espero conseguir algo en poco tiempo. También es verdad que estoy abusando un poco de la técnica, ya que con las luces que hay ahora se hacen 5 pasadas a pantalla completa de iluminación por cada frame, ya que aunque son luces puntuales, éstas afectan a casi todo el escenario y se solapan entre ellas. Podría hacer que ocupasen un área mucho menor, pero entonces la escena perdería bastante estéticamente. Igualmente, lo que hoy importa es el motion blur, que tiene un aspecto como este (estaba moviendo la cámara a una velocidad bastante elevada):


Se distingue poco, pero también he estado afinando un poco la iluminación, que era demasiado oscura. ;)

Otro ejemplo P.L.S

Es decir, Pa La Saca! Acabo de colgar la demo de God Rays, que ya tenía ganas de hacerlo desde hace días. A este paso, dentro de poco voy a tener problemas para tener nuevas ideas. xD Pero bueno, al menos eso me obligará a bajar el ritmo un poco.

Por otro lado, hoy he vuelto a avanzar bastante con el ejemplo de deferred shading, y ya tiene un aspecto tal que así:


Es increíble el cambio que puede llegar a sufrir una escena con una pequeña variación en la iluminación... Aún así todavía no estoy contento del todo con el resultado, así que los próximos días los pasaré dejándola lo mejor posible. Y además aún queda añadirle el postproceso de motion blur (aunque ya tengo todos los datos necesarios para ello), y me da miedo que haga bajar demasiado el rendimiento... Ahora mismo no funciona mal, a unos 350-450 fps según el espacio que ocupen las luces, pero creo que puedo sacarle algo más de jugo.

el g0e Weekly Update o_O

Bueeeno, ya estoy otra vez con otro ejemplo. Os presento a mi nuevo amigo:


A primera vista no parece nada fuera de lo normal: el HellKnight de Doom3 cargado con el loader de MD5 que sacaron recientemente en XNA Community y el escenario que usó Race en su ejemplo de luces volumétricas.

Pero no es ni mucho menos sólo eso. La escena se está pintando con una técnica de render conocida como Deferred Rendering o Deferred Shading. Esta técnica no es nueva, pero hasta hace poco no era posible usarla a una velocidad decente en juegos, y aún hoy en día hay muy pocos que la usen (los más conocidos son STALKER y Killzone 2).

Esta técnica tiene varias particularidades, como que sólo se iluminan aquellos puntos de la escena que realmente se están viendo o que el coste de pintar luces es proporcional al espacio que ocupan en pantalla, y no a su número. Con las tarjetas actuales se puede implementar gracias al uso de Multiple Render Targets (que ya usé en la demo de God Rays que, por cierto, colgaré mañana seguramente), este es un ejemplo:


En esta imagen se ven los cinco RTs que se usan en la visualización (color, normales, velocidad, profundidad e iluminación). Este no es el aspecto final del ejemplo ya que quiero meterle una iluminación con algo más de gracia, pero más o menos ya lo tengo encarrilado.

Traisión!

Una de las cosas que más me molestan es tener que perder el tiempo buscando y preparando modelos y escenas para los ejemplos. Te tiras un día entero para encontrar algo que no te acaba de convencer y te quedas con la sensación de no haber hecho nada. Pues bien, el otro día encontré uno que debía usar a toda costa en lo que fuera:


Si.... tiene una pinta genial, pero entonces empezaron los problemas. Se me había ocurrido una idea para un ejemplo en el que Master Chief quedaría de lujo, pero necesitaba dos cosas:

- Encontrar un escenario acorde con el personaje / ejemplo.
- Cambiarle la pose al Chief.

Al principio el primer punto fue sencillo, encontré un escenario a mi gusto en uno de los ejemplos del SDK de DirectX10. El problema es que a los de Microsoft se les ha ocurrido dejar de dar soporte a su formato de modelos .X en favor de un nuevo formato llamado sdkmesh que ellos mismos indican que es una mierda. Bravo.

Pero bueno, según ellos en el SDK han incluido una herramienta que convierte modelos entre los dos formatos. Lo probé y efectivamente funciona perfectamente al hacer la conversión .X -> .sdkmesh, pero no había manera de conseguir el paso inverso.

Después de trastear un poco con el código fuente del programa, encontré la siguiente condición en la función que carga el modelo de entrada:

if( nLength == 2 && pszExt && wcscmp( pszExt, L".x" ) == 0 )
{
CLoaderXFile loader;
hr = loader.Load( szFileName, requestedBHT );
m_pIntermediateMesh = loader.GetMesh();
}

Es decir, que sólo es capaz de pasar de .X a sdkmesh. Pues a la mierda el escenario.

El segundo punto no fue mejor. Yo no tengo ni idea de edición de modelos en programas estilo 3dStudio, Maya o XSI, pero conseguí cargar el modelo y cambiarle la pose. El problema es que los pesos están mal y a la hora de moverlo se le va la olla.

Al final me cansé de importarlo en varios programas, trastear, exportar, volver a importar, etc... Así que a la mierda el Chief (al menos hasta que contacte con un amigo que controla del tema).

Total, que me he cabreado y me voy a poner con otra cosa, porque eso de estar dos días sin parar para no conseguir nada me pone de mala leche. Lo volveré a intentar otro día...

XNA del bueno

Hoy ha sido un buen día para XNA Community. Javi y Rubén han sacado por fin su cargador de modelos MD5 para XNA (Javi a cargo de los Shaders y Rubén con el cargador en sí). Este formato es el que se usa en los juegos con el motor del Doom 3, y hay una buena cantidad de modelos en la red que lo utilizan, y muchos conversores que lo soportan.

El cargador permite usar este tipo de modelos de forma tremendamente sencilla, así como visualizar sus animaciones. Sin duda es algo que merece la pena probar.



Con esto además se ha estrenado una nueva sección de utilidades en la web, junto con los cargadores de MD3 y Collada, entre otros.

Por otro lado, yo ya tengo terminada la demo de God Rays, pero una vez más esperaré un poco a colgarla para no saturar(me). ;)

No tengo remedio

Soy impaciente de narices. Todavía no había subido la demo de animación de árboles y hardware instanting, y ya he empezado a probar un nuevo efecto. Aún queda trabajo por delante, pero hoy he conseguido los primeros resultados y la verdad es que mola. Se trata de una técnica que aparece en el GPU Gems 3 en un artículo titulado "Volumetric Light Scattering as a Post-Process", y trata de simular los llamados "god-rays" que produce la oclusión de la luz del sol con objetos opacos. Como bien dice el nombre del artículo, esta técnica se ejecuta como un postproceso en la GPU, y aún así da una sensación de volumen bastante realista.


Acabo de probarla y quedan muchos fallos por arreglar (además no se si buscaré una escena nueva) y cosas que optimizar, pero para haberle echado sólo un rato creo que por ahora va bastante bien.

Por último, ya se puede bajar la demo de animación de vegetación en el lugar habitual. Se han detectado algunos fallos en algunas tarjetas gráficas y hay quien me ha comentado que el instancing no les funcionaba bien, así que agradeceré cualquier comentario al respecto. ^^

A mí me daban dos!

Despues de la demo de POM y Custom Content Processor, una vez más voy a sacar un ejemplo doble. En el próximo, aparte de animación de vegetación como ya mostré en la entrada anterior, me di cuenta de que los cuatro hierbajos que se pintaban quedaban muy tristes y además suponían un bajón de rendimiento incomprensible para lo poca cosa que eran, así que me he mirado cómo implementar hardware instancing. Esta técnica permite pintar con una sola llamada "draw" gran cantidad de objetos iguales (varios miles sin problemas en mi PC), aumentando mucho la velocidad de renderizado. Para poder colocar cada instancia en una posición diferente, se pasa la información de la transformación de cada una con un nuevo flujo de vértices accesibles desde el shader.

Tal y como lo he implementado, el ejemplo no funcionará en Xbox 360 (aunque nunca los hago pensando en ejecutarlos en consola) ya que esta técnica se debe hacer de forma diferente en esta máquina. Dejo una imagen que da una idea del resultado:

A lo largo de esta semana la iré dejando lista y la subiré. ^^

Ah, y ya me han llegado el GPU Gems 3 y el ShaderX6, así que tengo trabajo para rato!

Mmmm... la naturaleza...

Aprovechando que ya me ha llegado el Shader X5 y que este fin de semana he tenido algo de tiempo (bueno, sólo me he podido poner hoy ^^U), me he puesto a preparar una pequeña demo sobre uno de los artículos del libro, concretamente el titulado "Animating Vegetation Using GPU Programs". Es una técnica muy sencilla para animar en la gráfica varios tipos de vegetación como árboles, arbustos o hierba. Pese a que no tiene en cuenta la forma del modelo, ni huesos ni cosas por el estilo, sino que directamente modifica los vértices según una cierta función, la animación no es 100% realista pero da perfectamente el pego para muchas aplicaciones. Además he podido prepararlo en una mañana, así que qué más se puede pedir! Ya está terminada y no creo que le añada gran cosa más, pero me esperaré un poco a colgarla, ya que Javi tiene lista otra demo y no es plan de ponerlas todas a la vez y reventar XNACommunity. xD Igualmente he grabado un video que YouTube se ha encargado convenientemente de joder hasta la saciedad, aun así creo que más o menos se puede apreciar el efecto:



Sobre aquello tan ambicioso que había empezado ya veremos... Quizás era un poco demasiado ambicioso. :(

Resacón

Bueno, ya no. El viernes fue la fiesta de la facultad, y mientras me recuperaba he colgado la nueva demo. El efecto que implementaba es el Parallax Occlusion Mapping, una especie de Relief Mapping que por ejemplo se ha usado en el Crysis. Si alguien lo prueba y le va lento es muy posible que sea por el sistema de partículas, que chupa bastante, así que se puede desactivar. Como siempre se puede descargar AQUI en XNACommunity, y a la derecha dejo el link correspondiente.

Ahora estoy esperando a que me lleguen de una puñetera vez los libros para pillar nuevas ideas, pero mientra me he puesto a trabajar en otro ejemplo mucho más ambicioso y espectacular que los anteriores... No sé si lo conseguiré, pero por intentarlo que no quede. ^^ Stay tuned!

Un pequeño adelanto

Como voy a estar un par de días sin poder hacer nada (la fiesta de la facultad y tal... :P), dejo una primera imagen de la próxima demo, que como ya comenté será más sencilla que las últimas que he hecho. Una pista sobre qué efecto implementa: el suelo. ;)

Teh Coordinator

Hace unos días por fin colgué la demo sobre nubes/humo volumétrico. Ya había puesto el link en el espacio dedicado a ello en la columna de la derecha del blog, pero no había puesto nada sobre ello. No voy a poner fotos bonitas ni vídeo porque ya está puesto en entradas anteriores, pero pongo el link AQUÍ.

Por otro lado ya estoy metido desde hace unos días en una nueva demo. En un principio tenía buena pinta, pero no me acaban de convencer los resultados así que seguramente la dejaré en algo más sencillo que lo que tenía en mente. Bueno, no todo iban a ser éxitos a la primera... Lo que seguramente se quedará como demo final es un ejemplo de customización de un Content Processor de XNA para que pueda cargar varias texturas para un mismo modelo, y así hacer efectos de iluminación más complejos como un normal mapping. Será un ejemplo de lo más sencillo, pero seguramente será útil para más de uno, y además añadiré algún shader molón para representar relieves.

Por último, comentar que desde ayer soy el nuevo coordinador de XNACommunity! Gracias a Javi (MVP DirectX) y a Rubén (de Novarama) por fijarse en mí pese a llevar tan poco tiempo colaborando en la página. ^^ Y bueno, esto hace que me entren más ganas de seguir haciendo cosas y aprendiendo cada día!

SSAO Again, nueva demo finiquitada y un chino ladrón

Hoy me he decidido a colgar el artículo sobre SSAO. Creo que aclara algunas cosillas importantes (sobre todo en el tema del cálculo de la dirección de visión), aunque quizás debería haber metido algún esquema más sobre los vectores que se calculan como me recomendaron. Lo malo es que no sabía qué esquemas hacer y cómo hacerlos (no encontré la manera de representar algo útil), así que he preferido no meter nada por si acaso lo lío más. Se puede leer AQUÍ.

Por otro lado ya he terminado la demo de nubes volumétricas. Esperaré un par de días o tres para colgarla y así dejo algo de tiempo para que se vean las cosas nuevas que se han subido. Mientras, he grabado un video de la versión casi-final (el skybox no es el definitivo, pero ya se ve cómo es el efecto).



Y por último, relacionado con este tema, hay un chino cabrón que me ha robado el video para hacer publicidad de una página guarra! Es cierto que suena de lo más bizarro, y cuando lo he visto me he quedado tal que así -> o_O Parece que por ahora no le ha servido de mucho...

Actualización: el chino ladrón ha borrado el video. Casi me apena...

Pa la saca!

Eso es lo que he dicho al pillarme el GPU Gems 3, el Shader X5 y el Shader X6, tres buenos libros sobre técnicas gráficas y otras pijerías para hacer con shaders. Son un poco caros, pero espero que sean los primeros de una buena colección. ^^ A ver si no tardan mucho en llegar y así pillo ideas para nuevas demos.

Y ahora a lo interesante. La demo sobre nubes volumétricas (resulta que hay un artículo en Shader X5 explicando esta técnica) ya casi está terminada. Hoy le he puesto una skybox para que tenga un aspecto más pulido, pero poca cosa más. Todavía no la voy a colgar porque el código está muy guarro y quiero optimizarlo un poco, pero ya queda poca cosa que hacer.


Por otro lado, ya tengo un primer borrador del artículo sobre SSAO. Supongo que mañana ya lo colgaré, espero que haya quedado suficientemente claro. Empieza así:

¿Qué es Ambient Occlusion?

Ambient Occlusion es una técnica de sombreado que simula la atenuación local de la luz debido a la propia geometría de la escena. Es decir, es una aproximación bastante bruta de los métodos de iluminación global que se pueden usar en visualizaciones que no son en tiempo real. Esta técnica se ha hecho popular gracias a que los resultados que proporciona son bastante realistas (provocando una mejor percepción de las formas 3D que se intentan representar) y el coste de cálculo la hace muy interesante para, por ejemplo, visualizar prototipos de animaciones o como un método para mejorar el aspecto del render sin tener que esperar mucho tiempo para pintar la imagen.

Aún así, el tiempo que se necesita para representar correctamente este efecto seguía siendo prohibitivo para juegos u otras aplicaciones interactivas, hasta ahora.

Que no decaiga

Esta tarde ha sido productiva, el nuevo ejemplo ya va cobrando forma y creo que ya tiene un aspecto lo suficientemente bueno como para enseñar algo:


Se trata de una técnica muy astuta y sencilla para pintar nubes (o explosiones, o humo, o similar) volumétricas con un coste muy bajo. La idea la encontré navegando por ahí en el blog de Kyle Hayward, mientras buscaba nuevos efectos a estudiar. No había ningún código de ejemplo, pero las diapositivas originales que explican el proceso son sobradamente claras para poder implementarla. Los resultados son muy buenos (pese a tener varios problemas), así que recomiendo a todo el mundo echarle un vistazo.

Como se puede observar he copiado la escena de demostración que aparece en las diapositivas, pero es que no voy sobrado de creatividad precisamente, y la escena es buena... ^^U

Screen-Space Ambient Occlusion, toma ya

Si es que no paro. Me levanto pronto, voy a trabajar, vuelvo a casa a comer en media hora, tiro pal curro otra vez, llego a casa a las 7 de la tarde, y entonces empieza mi tiempo libre... Y me pongo a programar, a hacer alguna demo porque es lo que me gusta, y el tiempo pasa rapidísimo y acaban siendo las 12 como ahora sin que realmente haya hecho demasiadas cosas... Bueno, la verdad es que sí, que he avanzado un buen trozo de una nueva cosilla que posiblemente quede bastante bien. ^^

Pero bueno, estos días han sido bastante interesantes. Publiqué una demo en XNACommunity mostrando unas de las técnicas más nuevas que se pueden ver hoy en día (sólo hay un juego comercial que lo implemente, y es el Crysis), el Screen-Space Ambient Occlusion. Resumiendo mucho, la técnica intenta simular en espacio imagen la atenuación de la luz ambiental debida a la propia geometría de la escena.

Aunque así no quede muy claro vale la pena echarle un vistazo, porque bien usada puede aumentar el realismo de la imagen de manera espectacular. Como ejemplo, AQUÍ hay un video mostrando la técnica tal y como se ha puesto en práctica en el juego de Crytek.

Y bueno, a continuación dejo un enlace a mi versión, que incluye el código fuente para que cualquiera pueda trastearlo o mejorarlo.


Aún así, como parece que para algunas personas el código no queda muy claro y al haber una ausencia casi absoluta de documentos que expliquen la técnica, estoy preparando un pequeño artículo explicando con cierto detalle los detalles de la implementación que he usado.

El siempre molón Motion Blur

Hace tiempo que sentía curiosidad por este efecto. Su definición según Wikipedia es:

Motion blur o "trazo confuso de movimiento" es el aparente movimiento a gran velocidad de objetos en una imagen quieta (fotografía) o una secuencia de imágenes como una película o animación.

Es decir, el típico difuminado que el ojo humano percibe al ver cosas que van muy rápido. Una cosa tan "tonta" puede hacer que una visualización que funciona a una tasa de 30 imágenes por segundo con motion blur tenga un aspecto mucho más realista que la misma funcionando a 60 sin este efecto.

Cuando empecé a mirarme cómo implementarlo, vi algunos métodos un poco "arcaicos" como por ejemplo guardar en una textura los frames anteriores al actual y hacer blending para ir mezclándolos entre ellos o usar el búfer de acumulación para conseguir un efecto parecido, pero los resultados eran bastante... feos.

Hoy en día, gracias a los ahora tan habituales shaders, se pueden conseguir efectos más sofisticados y con un resultado mucho más realista, sin que necesariamente eso signifique un coste de cálculo alto.

Precisamente el ejemplo que pondré más adelante aplica la técnica explicada en la presentación titulada "Stupid OpenGL Shader Tricks", de Simon Green. Este documento es bastante antiguo (2003) y creo que hoy en día hay técnicas que dan resultados mucho mejores (si no me equivoco, usando el Geometry Shader), pero el algoritmo que se explica es muy, muy sencilo y muy fácil de implementar.

Básicamente se trata de usar las matrices Model y View del frame actual y del anterior para generar un vector de velocidad en el vertex shader. Este vector se transforma al espacio imagen y se pasa al pixel shader para efectuar el blur en la dirección que marque. Sin más rollos (y además el código es bastante claro), el ejemplo lo podéis bajar haciendo click en la siguiente imagen:



En el ejemplo no se hace así, pero he comprobado que una manera de aplicar el efecto que queda bastante bien en muchas situaciones es guardar todas las velocidades de todos los objetos de la escena en una textura y hacer todo el blur como un paso de post-proceso sobre toda la pantalla (y creo que queda mejor haciendo el blur desde el pixel que se trata hacia el exterior, y no como se hace en la demo).

el g0e strikes back!

He vuelto! Hace tiempo que abrí este blog para poner las cosas que iba aprendiendo, pero lo dejé abandonado por culpa del proyecto de fin de carrera, el trabajo, y otras cosas que pertenecen a la llamada Vida Real™.

Ahora me he vuelto a poner en serio, e intentaré actualizar de forma periódica con demos y ejemplos que realizo en mi escaso tiempo libre.

Espero que sean de ayuda para alguien.