jcanton

Wave Engine ya está disponible

2013-02-23T19:16:17Z

Este jueves por fin lanzamos WaveEngine (waveengine.net) tras más de dos años de desarrollo. Creo que es un proyecto muy interesante para desarrolladores C# por lo que os animo a todos a probarlo y darnos feedback para continuar mejorándolo. A continuación para motivaros a probarlo os voy a contar rápidamente algunas API highlights del proyecto, las cuales desde mi punto de vista son bastantes atractivas e interesantes para desarrollados en C#. WaveEngine ha sido diseñado bajo los principios de Component...(read more)

Entrevista para la Newsletter de Visual Studio

2012-12-13T19:39:00Z

Javier Cantón lleva vinculado a Microsoft los últimos 10 años. Reconocido MVP experto en tecnologías como DirectX y XNA centradas en el desarrollo de Videojuegos y tratamiento de imágenes, ha centrado parte de su trabajo y carrera profesional en el mundo del desarrollo vinculándose con las últimas tecnologías del entretenimiento. Licenciado en Ingeniería Informática y especializado en el tratamiento y procesamiento de imágenes...(read more)

Memoria compartida entre C# struct

2012-07-15T21:59:53Z

Problemática: Imaginemos que estamos desarrollando un graphics ó physics engine en C#, el cual queremos que sea multiplataformas por lo que luego lo usaremos contra diferentes APIs como XNA, OpenTK y SharpDX. Trabajaremos con nuestras propias estructuras para Matrix4x4 ó Vector3 por ejemplo y luego las tendremos que traducir a las structs concretas de cada API. La struct para Vector3 de nuestro motor puede ser tan simple como: public struct Vector { public float X;...(read more)

WP7 Problemas de rendimiento con Struct (II / II)

2011-11-09T21:14:00Z

Realicemos un pequeño benchmark para poder evaluar cual es la pérdida de rendimiento obtenido, el cual se producirá por: CPU: Tiempo empleado en gestionar las llamadas (realizar las copias de las estructuras) Para el test vamos a crear un proyecto para Windows Phone 7.1 con Visual Studio, y luego lo analizaremos con el profiler de WP7 corriendo directamente en un dispositivo real. La demo será muy simple, colocaremos un bucle en el método Draw que es donde más...(read more)

WP7 Problemas de rendimiento con Struct (I / II)

2011-11-09T21:11:54Z

Recientemente he pasado bastantes horas optimizando código para Windows Phone 7, y una de las primeras cosas que hay que tener en mente es que el CLR(Common Language Runtime) de WP7 no es el de Windows. Incluso en la última versión (Mango) en la que han hecho grandes mejoras, como por ejemplo que ahora el GC (Garbage Collector) ofrece un rendimiento más decente con 2 generaciones, o como al aprovechamiento de las instrucciones SIMD. Otro factor a tener en cuenta para todos esos desarrolladores que...(read more)

Wave Engine

2011-09-16T18:27:00Z

Buenas, Hoy es un gran día para volver a escribir en el Blog, tras casi un año trabajando en Plain Concepts donde he conocido a gente muy grande y de la que he aprendido mucho, hoy hacemos público un vídeo en el que se puede ver Bye Bye Brain App-ocalypse corriendo sobre Wave Engine en el que hemos estado trabajando durante tantos meses, el cual permite desarrollar juegos de forma productiva para múltiples plataformas. A pesar de que aún no nos dejan desvelar...(read more)

Occlusion Culling (IV de IV)

2011-03-12T10:46:08Z

************************************************************************************************ - Back-face culling - Frustum Culling - Occlusion Culling - Optimizaciones para el Occlusion Culling ************************************************************************************************ En el post anterior explicamos los principios básicos del occlusión culling, y este último post lo dedicaremos a la implementación de dicha técnica de forma eficiente. Recordemos rápidamente en que consistía...(read more)

Occlusion Culling (III de IV)

2011-02-27T20:08:00Z

************************************************************************************************ - Back-face culling - Frustum Culling - Occlusion Culling - Optimizaciones para el Occlusion Culling ************************************************************************************************ Por fin toca escribir sobre la técnica que puso nombre a esta serie de artículos XD, Occlusión Culling también es una técnica que podemos incluir dentro de los algoritmos de visibilidad, esta técnica intenta...(read more)

Occlusion Culling (II de IV)

2011-02-13T20:31:57Z

************************************************************************************************ - Back-face culling - Frustum Culling - Occlusion Culling - Optimizaciones para el Occlusion Culling ************************************************************************************************ Frustum Culling : Es otra de las técnicas de visibilidad más usadas ya que es muy simple de implementar, consiste en no enviar a la tarjeta gráfica aquellos objetos que queden fuera del volumen de render de...(read more)

Occlusion Culling (I de IV)

2011-02-06T19:25:12Z

************************************************************************************************ - Back-face culling - Frustum Culling - Occlusion Culling - Optimizaciones para el Occlusion Culling ************************************************************************************************ Hacía tiempo que no escribía y me alegra que el regreso sea con un tema tan interesante como el Occlusion Culling. Esta técnica podríamos clasificarla dentro de las técnicas de visibilidad para mejorar el rendimiento...(read more)

Simular el acelerómetro de Windows Phone 7

2010-08-11T19:10:00Z

Con la llegada de XNA 4.0 y el soporte para los nuevos teléfonos la API nos da acceso a una parte muy usada para el desarrollo de juegos en los teléfonos, el acelerómetro, el problema es que al no tener aún los dispositivos físicos (ya que saldrán en Septiembre-Octubre) y que el emulador que se ha proporcionado para Visual Studio 2010 tampoco nos permite emularlo, muchos desarrolladores nos encontramos limitados a la hora de crear proyectos que usen el acelerómetro...(read more)

Evento XNA 4.0 & Windows Phone 7

2010-05-06T08:17:00Z

Actualmente me encuentro colaborando con personas de Microsoft como Isabel Gomez Miragaya en las presentaciones de Windows Phone 7 en España. El 28 de Mayo estaremos en Barcelona en un evento sobre Windows Phone 7 pero que lo centraremos en el desarrollo de videojuegos con XNA 4.0, dejo aquí más información: Windows Phone 7 Developer Hub: Desarrolla juegos para Windows Phone 7 con XNA 28 de Mayo, Hotel Barcelo Sants, Barcelona Durante este evento descubriréis la...(read more)

XNA Graphics Pipeline

2010-04-01T00:20:00Z

Si queremos extraerle el máximo partido gráfico a XNA usando HLSL es importante conocer el pipeline gráfico usado por este framework: Cada uno de estos “módulos” cumplen un papel especial hasta conseguir pintar un objeto en pantalla, ya sea un modelo 3D ó una imagen 2D (la cual es pintada sobre un quad “anclado” a la pantalla). Veamos que se hace en cada uno de estos “módulos”: Vertex Data: Contiene un buffer de vértices sin transformar indexado o no indexado, es posible indicar mediante VertexDeclaration...(read more)

HLSL, Un poco de historia

2010-03-11T09:30:00Z

HLSL (High Level Shader Language) es el lenguaje desarrollado por Microsoft con el que podemos programar efectos gráficos mediante DirectX para que sean ejecutados por la GPU (Graphics Processor Unit) situada en nuestras actuales tarjetas gráficas, con el se pueden aplicar efectos gráficos tan impresionantes como:

Pero como se ha llegado hasta todo esto que hoy conocemos y nos es tan común, pues todo empezó en 1995 con la salida de la primera tarjeta aceleradora gráfica 3D para consumo doméstico lanzada por la en aquellos tiempos empresa llamada 3Dfx, estoy convencido que todos recordaréis los inicios y lo que suponía arrancar un juego con y sin que apareciese este logo al arrancar:

(Por favor, visita la web para ver este medio)

La 3Dfx Voodoo Card fue la primera por aquellos tiempos uno necesitaba una tarjeta gráfica 2D y una tarjeta aceleradora de gráficos 3D, finalmente esto se fue unificando en una sola tarjeta y las llamadas tarjetas aceleradoras pasaron a ser nuestras tarjetas gráficas 2D y 3D. Estas tarjetas provocaron una revolución en el mundo de los videojuegos aunque sus posibilidades eran muy limitadas, se empezó a pensar en trasladar gran parte del cálculo especifico en los videojuegos de la CPU hacia la GPU.

El próximo salto lo dio Nvidia con el lanzamiento de la GeForce 256 la cual liberaba a la CPU del cálculo de transformación e iluminación (Transform & Lighting) y permitía por tanto tener muchísimos más objetos en pantalla iluminados al realizar esta operación por hardware:

(Por favor, visita la web para ver este medio)

Hubo una segunda generación basada en esto introducida en el mercado por Nvidia a partir de su GeForce 2 y ATI con su gama Radeon, pero en aquellos entonces todas las capacidades gráficas estaba implementadas mediante fixed-functions, lo cual significaba que solo podías aplicar a los objetos las transformaciones e iluminación que permitía el hardware de la tarjeta gráfica, esto provocó que muchos juegos de la época tuviesen un aspecto muy parecido.

Cabe destacar también como 3Dfx lanzó con su tarjeta Voodoo 2 la tecnología SLI (Scan-Line Interleave) con la que se podían conectar dos tarjetas gráficas en paralelo, lo cual además de una buena estrategia de ventas fueron los inicios de la computación gráfica en multiples procesadores, 3Dfx innovaba mucho y finalmente fue comprada por Nvidia.

Más tarde la salida de DirectX 8 intentó mejorar esto incorporando la posibilidad de poder escribir pequeños programas que serían ejecutados por la GPU para cada vértice y cada pixel, esto aportó gran flexibilidad al desarrollo de efectos gráficos. Estos pequeños programas se llamaban Shaders y al conjunto de especificaciones se le llamó Shader Model el cual podía dividirse en dos conjuntos las especificaciones para trabajar con vértices llamada Vertex Shader y las especificaciones para trabajar a nivel de pixel llamadas Pixel Shader.

Microsoft lanzaba las especificaciones de cada versión de Shader Model pero las primeras tarjetas en incorporar soporte para shaders implementaban parcialmente dichas especificaciones por ello no se hablaba casi nunca de Shader Model y se especificaba hasta que versión de Pixel Shader y Vertex Shader soportaban que no tenían porque ser la misma. Sin embargo a patir de la versión 2.0 de Shader Model los fabricantes empezaron ha hablar ya de Shader Model lo cual indicaba que las tarjetas soportaban tanto Vertex Shader 2.0 como Pixel Shader 2.0.

Por aquellos tiempos la programación de shader era muy similar a la programación en emsamblador:

Vertex Shader

vs_1_1 // version instruction

#define fogStart c9.x

#define fogEnd c9.z

def c9, 2, 2.33, 2.66, 3 // fog start values

def c10, 3, 4.5, 6, 10 // fog end values

def c11, 0, 0, 1, 1 // clamping values

def c13, 0.66, 1.51, 0, 0

dcl_position v0

dcl_texcoord v7

m4x4 r0, v0, c0  // transform vertices by world-view-projection matrix

mov oPos, r0

mov oT0, v7

m4x4 r1, v0, c4  // transform vertices by world-view matrix

// fog constants calculated in the application (6 instructions)

mov r2.x, c13.y  // 1 / (fog end - fog start)

sub r2.y, fogEnd, r1.z // (fog end - distance)

mul r2.z, r2.y, r2.x  // (fog end - distance)/(fog end - fog start)

max r2.w, c11.x, r2.z  // clamp above 0

min r2.w, c11.z, r2.z  // clamp below 1

mov oFog, r2.w  // output per-vertex fog factor in r2.x

Pixel Shader

ps_1_1 // version instruction

def c0, 0,0,0,0

def c1, 1,1,1,1

def c2, 1.0,0.5,0,0

def c3, 0,-0.5,-0.25,0

tex t0 // sample texture at stage 0,

// with texture coordinate set 0

mov r0, t0 // output texture color

// mov r0, 1 - t0 // output inverted texture color

// add r0, t0, c2 // add more reds and greens

// add r0, t0, c3 // subtract greens and blues

// mov r0, c2 // output solid pixel color

Lo cual hacía muy complicada su escritura, mantenimiento y reutilización, por esta razón se decidió crear lenguajes de alto nivel para la programación de Shader los cuales fuese compilados.

Microsoft desarrollo el lenguaje HLSL (High Level Shading Language) similar a C el cual lanzó con la versión de DirectX 9, esto provocó un impulso en en el mundo de los gráficos 3D, ahora era mucho más fácil escribir Shaders y por lo tanto el tamaño de estos pequeños programas fue aumentando al igual que su API.

También se desarrolló un lenguaje de alto nivel para trabajar bajo OpenGL llamado GLSL y posteriormente Nvidia lanzó un lenguaje más, llamado CG el cual permite compilar fácilmente un Shader a CG o HLSL.

Aquí podéis ver un ejemplo de un Shader básico que contiene su función para Vertex y Pixel Shader:

float4x4 WorldViewProjection;

float4 VertexShaderFunction(float4 Position : POSITION) : POSITION

    return mul(Position, WorldViewProjection);

float4 PixelShaderFunction() : COLOR

    return float4(1, 0, 0, 1);

technique Technique1

    pass Pass1

        VertexShader = compile vs_1_1 VertexShaderFunction();

        PixelShader = compile ps_1_1 PixelShaderFunction();

Tras programar en HLSL nunca más quieres volver a saber nada sobre lo anterior pero siempre es importante conocer algo de lo que había antes, la evolución de la API con cada versión de DirectX ha sido la siguiente:

DirectX 8.0 y 8.1 Shader Model 1.0
DirectX 9.0 Shader Model 2.0
DirectX 9.0c Shader Model 3.0
DirectX 10 y 10.1 Shader Model 4.0
DirectX 11 Shader Model 5.0

Cada una de estas versiones ha venido acompañada de mejoras, tanto en el número de instrucciones que se podían introduccir en cada shader (sin restricción alguna en las últimas versiones), como al número de intrisic functions disponibles. Cabe destar que XNA (hasta la versión actual XNA 3.1) está desarrollada sobre DirectX 9.0c por lo que desde este framework solo tenemos acceso a las especificaciones de Shader Model 3.0.

En la actualidad se ha lanzado ya la versión 11 de DirectX la cual da incluso un paso más allá con el DirectCompute del cual hablaremos otro día.

Alpha blending en XNA (IV de IV)

2010-03-04T20:23:00Z

Vayamos ahora a por el último bloque de instrucciones presentado en el primer post:

GraphicsDevice.RenderState.AlphaBlendEnable = false;

GraphicsDevice.RenderState.BlendFunction = BlendFunction.Add;

GraphicsDevice.RenderState.BlendFactor = new Color(255, 255, 255, 255);

GraphicsDevice.RenderState.SourceBlend = Blend.One;

GraphicsDevice.RenderState.DestinationBlend = Blend.Zero;

GraphicsDevice.RenderState.SeparateAlphaBlendEnabled = false;

GraphicsDevice.RenderState.AlphaBlendOperation = BlendFunction.Add;

GraphicsDevice.RenderState.AlphaSourceBlend = Blend.One;

GraphicsDevice.RenderState.AlphaDestinationBlend = Blend.Zero;

GraphicsDevice.RenderState.AlphaTestEnable = false;

GraphicsDevice.RenderState.AlphaFunction = CompareFunction.Always;

GraphicsDevice.RenderState.ReferenceAlpha = 0;

Este bloque es independiente de los dos anteriores, mientras los anteriores se referían al Alpha Blending este hace referencia al Alpha Test, lo he escrito dentro del mismo artículo ya que mucha gente los suele confundir.

GraphicsDevice.RenderState.AlphaTestEnable = false;

GraphicsDevice.RenderState.AlphaFunction = CompareFunction.Always;

GraphicsDevice.RenderState.ReferenceAlpha = 0;

Estas tres instrucciones están ligadas de forma que mientras no pongamos AlphaTestEnable = true los valores asignados a AlphaFunction y ReferenceAlpha no tendrán efecto, (por defecto AlphaTestEnable = false).

Estas instrucciones configuran un test basado en el canal alpha que es mucho más rápido que el test de Alpha Blending, su funcionamiento es el siguiente, asignamos un valor de referencia (ReferenceAlpha) con un valor entre 0 y 255 y luego seleccionamos una operación de comparación la cual descartará todos los pixeles que no la cumplan.

Las posibles funciones que podemos seleccionar son:

Always
Todos los pixeles pasan el test.

Equal
Acepta todos los pixeles que tienen en su canal alpha un valor igual que el de referencia.

Greater
Acepta todos los pixeles que tienen en su canal alpha un valor mayor que el valor de referencia.

GreaterEqual
Acepta todos los pixeles que tienen en su canal alpha un valor igual o mayor que el valor de referencia.

Less
Acepta todos los pixeles que tienen en su canal alpha un valor menor que el valor de referencia.

LessEqual
Acepta todos los pixeles que tienen un su canal alpha un valor menor o igual que el valor de referencia.

Never
Ningún pixel pasa el test.

NotEqual
Acepta todos los pixeles que tienen en su canal alpha un valor distinto del valor de referencia.

Veamos algunos ejemplos:

Canales RGB

Canal Alpha

Code 1

//Desactivado test de alpha blending

GraphicsDevice.RenderState.AlphaBlendEnable = false;

//Activamos el Alpha Test

GraphicsDevice.RenderState.AlphaTestEnable = true;

//Pasan todos los pixeles cuyo valor en el canal alpha super 200

GraphicsDevice.RenderState.AlphaFunction = CompareFunction.Greater;

//El valor de referencia será 200

GraphicsDevice.RenderState.ReferenceAlpha = 200;

Code 2

//Desactivado test de alpha blending

GraphicsDevice.RenderState.AlphaBlendEnable = false;

//Activamos el Alpha Test

GraphicsDevice.RenderState.AlphaTestEnable = true;

//Pasan todos los pixeles cuyo valor en el canal alpha sea inferior a 200

GraphicsDevice.RenderState.AlphaFunction = CompareFunction.Less;

//El valor de referencia será 200

GraphicsDevice.RenderState.ReferenceAlpha = 200;

Este test es interesante ya que es mucho más rápido que el Alpha Blending, el cual además presenta un problema bastante grande junto al ZBuffer, y es que este algoritmo no funciona muy bien con objetos transparentes ya que recordemos que en este algoritmo íbamos marcando en un buffer la profundidad de los objetos para no pintar aquellos que estuviese eclipsados, pero en este caso cuando tenemos objetos transparentes si nos interesa que se pinten todos aquellos objetos que están por detrás de estos, mucha gente decide simplemente desactivar la escritura en el Zbuffer pero esto es un error, lo correcto sería:

Realizar un render de todos los objetos opacos de la escena.
Ordenar por profundidad de atrás hacia delante los objetos transparentes de la escena.
Pintar los objetos transparentes en orden (desactivando la escritura del zbuffer).

Como se puede intuir esta solución es bastante lenta si pretendemos pintar muchos planos con transparencias pero casualmente una de las situaciones que más se presentan en los videojuegos es el pintado de vegetación usando billboards (que son planos con texturas de hierba).

Para mejorar el rendimiento de esto el equipo de SpeedTree fue el primero en combinar el Alpha Blending con el Alpha test, de forma que los billboard más cercanos se pintaban usando AlphaBlending + pre-ordenado y el resto usando Alpha Test sin ordenar pero usando un truco, modificando los canales alpha de las texturas de hierba con otras texturas de ruido para ocultar la apreciación de errores de profundidad en el dibujado.

Por último comentar que todos estos atributos relacionados con Alpha del RenderState también pueden ser configurados directamente desde el código HLSL, por ejemplo:

technique Feathering

    pass Pass0

      VertexShader = compile vs_1_1 vs11();

      PixelShader  = compile ps_1_1 ps11();

      AlphaBlendEnable = true;

      SrcBlend = SrcAlpha;

      DestBlend = InvSrcAlpha;

      ZWriteEnable = false;

    pass Pass1

      VertexShader = compile vs_1_1 vs11();

      PixelShader  = compile ps_1_1 ps11();

      AlphaTestEnable = true;

      AlphaRef = 0x00000040;

      AlphaFunc = GreaterEqual;

      ZWriteEnable = true;

************************************************************************************************

- Alpha Blending en XNA (I de IV)

- Alpha Blending en XNA (II de IV)

- Alpha Blending en XNA (III de IV)

- Alpha Blending en XNA (IV de IV)

************************************************************************************************

Alpha blending en XNA (III de IV)

2010-02-25T08:16:07Z

Recordemos que al principio del todo presentamos un gran conjunto de parámetros que están relacionados con el Alpha dentro de la API de XNA:

GraphicsDevice.RenderState.AlphaBlendEnable = false;

GraphicsDevice.RenderState.BlendFunction = BlendFunction.Add;

GraphicsDevice.RenderState.BlendFactor = new Color(255, 255, 255, 255);

GraphicsDevice.RenderState.SourceBlend = Blend.One;

GraphicsDevice.RenderState.DestinationBlend = Blend.Zero;

GraphicsDevice.RenderState.SeparateAlphaBlendEnabled = false;

GraphicsDevice.RenderState.AlphaBlendOperation = BlendFunction.Add;

GraphicsDevice.RenderState.AlphaSourceBlend = Blend.One;

GraphicsDevice.RenderState.AlphaDestinationBlend = Blend.Zero;

GraphicsDevice.RenderState.AlphaTestEnable = false;

GraphicsDevice.RenderState.AlphaFunction = CompareFunction.Always;

GraphicsDevice.RenderState.ReferenceAlpha = 0;

En esta ocasión nos centraremos en el segundo bloque, este está relacionado con el canal alpha del backbuffer y mucha gente los suele confundir con los del primer grupo. Lo más importante es que todos estos parámetros vienen desactivados por defecto, y seguirán así mientras no pongamos SeparateAlphaBlendEnable a true. En muchos sitios podemos ver como se asignan valores a AlphaSourceBlend y AlphaDestinationBlend sin haber activado SeparateAlphaBlendEnable por lo que esos cambios no tendrán ningún efecto. También hay que tener en cuenta que ciertas instrucciones de XNA modifican el Device.RenderState, como pueden ser la instrucción de SpriteBacth ó la de pass de un effect.

Pasemos a explicar cual es la finalidad de este grupo de instrucciones, cuando queremos pintar objetos translucidos en la escena y estamos realizando un render sobre el framebuffer, este a su vez es también una imagen y por lo tanto tiene sus canales R, G, B, y A. El canal Alpha del framebuffer suele usarse para guardar información extra sobre todo cuando se aplican efectos de postprocessing en los que el render final es una composición de varios renders previos.

Bien con SeparateAlphaBlendEnable = false a la hora de realizar el test de Alpha durante el render se usa la fórmula:

(Source * SourceBlend) (blendFunction) (Destination * DestinationBlend)

esta operación se realiza tanto para los canales RGB como para el canal alpha del framebuffer, sin embargo cuando configuramos SeparateAlphaBlendEnable = true podemos cambiar esto y hacer que se apliquen dos operaciones (una para los canales RGB y otra para el canal alpha).

Operación1 sobre canales RGB

(Source.RGB * SourceBlend) (blendFunction) (Destination.RGB * DestinationBlend)

Operación2 sobre el canal Alpha

(Source.A * AlphaSourceBlend) (AlphaBlendOperation) (Destination.A * AlphaDestinationBlend)

Veamos un ejemplo, utilizaremos la siguiente textura en PNG que contendrá tanto los canales RGB como el canal Alpha, aunque veámoslos por separado:

Canales RGB

Canal Alpha

Vamos a aplicar una operación a los canales RGB con BlendFactor para hacer la vidriera semitranslucida, y por otra parte vamos a usar el canal Alpha de la textura y vamos a mezclarlo con el canal alpha de FrameBuffer. Para poder apreciar la diferencia en todos los canales del FrameBuffer usaremos el siguiente procedimiento, renderizamos sobre un RenderTarget2D y posteriormente pintaremos la textura de este RenderTarget2D usando un SpriteBatch al cual le aplicaremos un Shader:

XNA Code:

//Pintamos sobre un RenderTarget2D

GraphicsDevice.SetRenderTarget(0, rt);

graphics.GraphicsDevice.Clear(ClearOptions.Target | ClearOptions.DepthBuffer,

        Color.Black, 1.0f, 0);

//Background

spritebatch.Begin(SpriteBlendMode.None, SpriteSortMode.Immediate, SaveStateMode.SaveState);

spritebatch.Draw(background, Vector2.Zero, Color.White);

spritebatch.End();

GraphicsDevice.VertexDeclaration = vertexDeclaration;

GraphicsDevice.RenderState.CullMode = CullMode.None;

//Configuración del RenderState

GraphicsDevice.RenderState.AlphaBlendEnable = true;

GraphicsDevice.RenderState.BlendFactor = new Color(127, 127, 127);

GraphicsDevice.RenderState.BlendFunction = BlendFunction.Add;

GraphicsDevice.RenderState.SourceBlend = Blend.BlendFactor;

GraphicsDevice.RenderState.DestinationBlend = Blend.InverseBlendFactor;

GraphicsDevice.RenderState.SeparateAlphaBlendEnabled = true;

GraphicsDevice.RenderState.AlphaBlendOperation = BlendFunction.Add;

GraphicsDevice.RenderState.AlphaSourceBlend = Blend.SourceAlpha;

GraphicsDevice.RenderState.AlphaDestinationBlend = Blend.Zero;

//Render

effect.Begin();

foreach (EffectPass pass in effect.CurrentTechnique.Passes)

    pass.Begin();

    effect.Parameters["World"].SetValue(Matrix.CreateRotationY(rotation));

    effect.Parameters["View"].SetValue(Matrix.CreateLookAt(new Vector3(0, 0, -4), Vector3.Zero, Vector3.Up));

    effect.Parameters["Projection"].SetValue(Matrix.CreatePerspectiveFieldOfView(MathHelper.PiOver4, aspectRatio, 1, 10000));

    effect.Parameters["DiffuseTexture"].SetValue(textures[index]);

    graphics.GraphicsDevice.DrawUserPrimitives<VertexPositionNormalTexture>(

            PrimitiveType.TriangleList, boxData, 0, 2);

    pass.End();

effect.End();

//Ahora pintamos la imágen almacenada en el RenderTarget2D sobre un SpriteBatch

GraphicsDevice.SetRenderTarget(0, null);

spritebatch.Begin(SpriteBlendMode.None, SpriteSortMode.Immediate, SaveStateMode.None);

alphaEffect.Begin();

alphaEffect.CurrentTechnique.Passes[0].Begin();

alphaEffect.Parameters["Alpha"].SetValue(alpha);

spritebatch.Draw(rt.GetTexture(), Vector2.Zero, Color.White);

alphaEffect.CurrentTechnique.Passes[0].End();

alphaEffect.End();

spritebatch.End();

Shader

sampler ColorMapSampler;

bool Alpha;

float4 PixelShaderFunctionAlpha(float2 TexCoord : TEXCOORD0) : COLOR0

    if(Alpha)

        float a = tex2D(ColorMapSampler, TexCoord).a;

        return float4(a, a, a, 1);

    else

        return tex2D(ColorMapSampler, TexCoord);

technique Technique1

    pass Pass1

        PixelShader = compile ps_2_0 PixelShaderFunctionAlpha();

Este Shader nos permitirá mediante el valor de un parámetro “Alpha”, ver los canales RGB ó el canal alpha del resultado final.

Resultado en los canales RGB del FrameBuffer:

Resultado en el canal alpha del FrameBuffer

Bueno como veis si antes teníamos muchas posibilidades, ahora con SeparateAlphaBlendEnable estas se incrementan aún más, ya que AlphaSourceBlend y AlphaDestinationBlend pueden ser configurados con cualquiera de los valores Blend vistos anteriormente para SourceBlend y DestinationBlend, de igual modo AlphaBlendOperation puede tomar cualquiera de los valores que vimos para BlendFunction.

************************************************************************************************

- Alpha Blending en XNA (I de IV)

- Alpha Blending en XNA (II de IV)

- Alpha Blending en XNA (III de IV)

- Alpha Blending en XNA (IV de IV)

************************************************************************************************

Alpha blending en XNA (II de IV)

2010-02-18T23:03:19Z

Recordemos la formula general usada para las transparecias:

(Source * SourceBlend) (blendFunction) (Destination * DestinationBlend)

En los dos ejemplos anteriores usamos como BlendFunction la operación suma que suele ser la más común, pero se pueden usar otras, la lista completa es:

Add     result = (Source * SourceBlend) + (Destination * DestinationBlend)

Max     result = max( (Source * SourceBlend), (Destination * DestinationBlend)

Min     result = min( (Source * SourceBlend), (Destination * DestinationBlend)

ReverseSubtract     result = (Destination * DestinationBlend) - (Source * SourceBlend)

Subtract     result = (Source * SourceBlend) - (Destination * DestionationBlend)

Para los parámetros SourceBlend y DestionationBlend que como vimos anteriormente nos indica el nivel de aportación a la mezcla del Source (lo que queremos pintar con transparencia) y del Destination (lo que ya está se ha pintado en el framebuffer, el fondo), y los configuramos para que usaran un valor constante de alpha para toda la textura usando el BlendFactor ó que usaran el canal alpha de la textura, pero también existen muchos otros valores, aquí os dejo la lista completa también:

Zero
Each component of the color is multiplied by (0, 0, 0, 0).

One
Each component of the color is multiplied by (1, 1, 1, 1).

SourceColor
Each component of the color is multiplied by the source color. This can be represented as (Rs, Gs, Bs, As), where R, G, B, and A respectively stand for the red, green, blue, and alpha source values.

InverseSourceColor
Each component of the color is multiplied by the inverse of the source color. This can be represented as (1 − Rs, 1 − Gs, 1 − Bs, 1 − As) where R, G, B, and A respectively stand for the red, green, blue, and alpha destination values.

SourceAlpha
Each component of the color is multiplied by the alpha value of the source. This can be represented as (As, As, As, As), where As is the alpha source value.

InverseSourceAlpha
Each component of the color is multiplied by the inverse of the alpha value of the source. This can be represented as (1 − As, 1 − As, 1 − As, 1 − As), where As is the alpha destination value.

DestinationAlpha
Each component of the color is multiplied by the alpha value of the destination. This can be represented as (Ad, Ad, Ad, Ad), where Ad is the destination alpha value.

InverseDestinationAlpha
Each component of the color is multiplied by the inverse of the alpha value of the destination. This can be represented as (1 − Ad, 1 − Ad, 1 − Ad, 1 − Ad), where Ad is the alpha destination value.

DestinationColor
Each component color is multiplied by the destination color. This can be represented as (Rd, Gd, Bd, Ad), where R, G, B, and A respectively stand for red, green, blue, and alpha destination values.

InverseDestinationColor
Each component of the color is multiplied by the inverse of the destination color. This can be represented as (1 − Rd, 1 − Gd, 1 − Bd, 1 − Ad), where Rd, Gd, Bd, and Ad respectively stand for the red, green, blue, and alpha destination values.

SourceAlphaSaturation
Each component of the color is multiplied by either the alpha of the source color, or the inverse of the alpha of the source color, whichever is greater. This can be represented as (f, f, f, 1), where f = min(A, 1 − Ad).

BothInverseSourceAlpha
(Win32 only) Each component of the source color is multiplied by the inverse of the alpha of the source color, and each component of the destination color is multiplied by the alpha of the source color. This can be represented as (1 − As, 1 − As, 1 − As, 1 − As), with a destination blend factor of (As, As, As, As); the destination blend selection is overridden. This blend mode is supported only for the SourceBlend render state.

BlendFactor
Each component of the color is multiplied by a constant set in BlendFactor.

InverseBlendFactor
Each component of the color is multiplied by the inverse of a constant set in BlendFactor. This blend mode is supported only if SupportsBlendFactor is true in the SourceBlendCapabilities or DestinationBlendCapabilities properties.

BothSourceAlpha
This mode is obsolete. The same effect can be achieved by setting the source and destination blend factors to SourceAlpha and InverseSourceAlpha in separate calls.

Ahora es cuando muchos os estaréis preguntando que para que tantos valores, pues como veis las posibles combinaciones son muchas y con todas ellas el resultado es algo diferente, que sean más o menos útiles ya es otra cosa XD.

Las combinaciones más usadas y conocidas son:

Alpha Blending     (source * Blend.SourceAlpha) + (destination * Blend.InvSourceAlpha)

Additive Blending     (source * Blend.One) + (destination * Blend.One)

Multiplicative Blending     (source * Blend.Zero) + (destination * Blend.SourceColor)

2X Multiplicative Blending     (source * Blend.DestinationColor) + (destination * Blend.SourceColor)

1. Alpha Blending, 2. Additive Blending, 3. Multiplicative Blending, 4. 2X Multiplicative Blending

También cabe destacar que existen diferentes formas de pensar en la transparencia esta que acabamos de ver podemos llamar la forma convencional en la mayoría de APIs.

Conventional Alpha Blending

Idea:

blend(source, destination) = (source.rgb * source.a) + (destination.rgb * (1 – source.a))

En XNA:

GraphicsDevice.RenderState.AlphaBlendEnable = true;

GraphicsDevice.RenderState.BlendFunction = BlendFunction.Add;

GraphicsDevice.RenderState.SourceBlend = Blend.SourceAlpha;

GraphicsDevice.RenderState.DestinationBlend = Blend.InverseSourceAlpha;

Pero como podemos observar en esta situación los valores RGB y el alpha son independientes, de manera que sería posible tener un objeto totalmente transparente con valores de color en RGB, esto a un informático no le preocupa en exceso, pero no es un comportamiento muy real. Por ello existen otras formas de pensar en la transparencia como:

Premultiplied Alpha Blending

Idea:

blend(source, destination) = source.rgb + ( destination.rgb * (1 – source.a) )

En XNA:

GraphicsDevice.RenderState.AlphaBlendEnable = true;

GraphicsDevice.RenderState.BlendFunction = BlendFunction.Add;

GraphicsDevice.RenderState.SourceBlend = Blend.One;

GraphicsDevice.RenderState.DestinationBlend = Blend.InverseSourceAlpha;

En este caso el alpha y el RGB están ligados y para que un objeto sea transparente debe tener el máximo de transparencia, y el color de RGB debe ser nulo (0,0,0). Si os fijáis la formula es la misma que la anterior solo que el source.rgb lo multiplicamos por 1, esto implica que si el objeto es translucido tendremos que realizar una conversión previa de las texturas para pasarlas a premultiplied format:

color.rgb *= color.a

Uno de los grandes motivos por el que se tiende a usar está técnica es porque se adapta mejor con DTX compression.

************************************************************************************************

- Alpha Blending en XNA (I de IV)

- Alpha Blending en XNA (II de IV)

- Alpha Blending en XNA (III de IV)

- Alpha Blending en XNA (IV de IV)

************************************************************************************************

Alpha blending en XNA (I de IV)

2010-02-14T14:37:00Z

Alpha blending es la técnica con la cual podemos trabajar con transparencias tanto en 2D como en 3D, nos centraremos en pintar un plano con una textura y veremos diferentes formas de aplicar esta técnica.

Para el primer ejemplo usaremos una textura de vidriera:

la cual nos gustaría aplicar a un plano en 3D y que se viese translucido. Si simplemente la textura el resultado sería algo como:

Aquí entran en juego todos los parámetros con los que podemos trabajar, estos los podemos dividir en 3 grupos y sus valores por defecto son:

GraphicsDevice.RenderState.AlphaBlendEnable = false;

GraphicsDevice.RenderState.BlendFunction = BlendFunction.Add;

GraphicsDevice.RenderState.BlendFactor = new Color(255, 255, 255, 255);

GraphicsDevice.RenderState.SourceBlend = Blend.One;

GraphicsDevice.RenderState.DestinationBlend = Blend.Zero;

GraphicsDevice.RenderState.SeparateAlphaBlendEnabled = false;

GraphicsDevice.RenderState.AlphaBlendOperation = BlendFunction.Add;

GraphicsDevice.RenderState.AlphaSourceBlend = Blend.One;

GraphicsDevice.RenderState.AlphaDestinationBlend = Blend.Zero;

GraphicsDevice.RenderState.AlphaTestEnable = false;

GraphicsDevice.RenderState.AlphaFunction = CompareFunction.Always;

GraphicsDevice.RenderState.ReferenceAlpha = 0;

Todos estos son muchos parámetros y mucha gente termina confundiéndolos, para empezar nos centraremos solo en el primer grupo:

AlphaBlendEnable deberemos ponerlo a true si queremos activar el test de AlphaBlending.

BlendFunction, SourceBlend y DestinationBlend serán usados para determinar el color de cada pixel en el framebuffer tras la mezcla mediante la siguiente fórmula:

(Source * SourceBlend) (blendFunction) (Destination * DestinationBlend)

En este ejemplo concreto:

- Source representará los colores almacenados en la textura de vidriera.

- SourceBlend será el valor por el que multiplicaremos Source e indicará su contribución a la mezcla.

- BlendFunction representa una operación que puede ser suma, recta….

- Destination es el color que ya está en el framebaffer en nuestro caso la imagen de fondo con los árboles.

- DestinationBlend indicará la contribución del fondo a la mezcla.

Para irnos familiarizando con todos estos parámetros seguiremos con el ejemplo de la vidriera, nosotros lo que queríamos era que se viese translucida (con el mismo valor de translucidez por toda la superficie) para ello usaremos el parámetro BlendFactor que os ayudará a aplicar un valor constante de translucidez a toda la superficie, la manera de usarlo será configurar el valor de BlendFactor y posteriormente usar este desde SourceBlend y DestinationBlend, por ejemplo:

//Activamos el AlphaBlending

GraphicsDevice.RenderState.AlphaBlendEnable = true;

//Los valores de color están entre (0-255) con 127 le estamos indicando que queremos que sea un 50% translucida

GraphicsDevice.RenderState.BlendFactor = new Color(127, 127, 127);

//Utilizamores como operador la suma para la mezcla

GraphicsDevice.RenderState.BlendFunction = BlendFunction.Add;

//Multiplica los valores RGB de la vidriera por el valor de BlendFactor

GraphicsDevice.RenderState.SourceBlend = Blend.BlendFactor;

//Multiplica los valores RGB del fondo por el valor inverso de Blend factor (1 - BlendFactor)

GraphicsDevice.RenderState.DestinationBlend = Blend.InverseBlendFactor;

El resultado:

En este caso estábamos trabajando con una textura que no traía información en el canal Alpha ó este veían vacio (todo a 1), las texturas suelen almacenar 4 canales Red, Green, Blue, Alpha (RGBA).

Probemos ahora con una textura con canal alpha para lo cual necesitaremos un formato que sea capaz de almacenarlo por ejemplo PNG:

Canales RGB

Canal Alpha

El canal alpha al ser un solo canal, si lo presentamos en una imagen esta será en blanco y negro. En este caso podemos ver como la vidriera no tiene los mismos niveles de translucidez en toda su superficie, todo lo que esté más cercano al blanco será opaco, por lo que tanto el marco como el centro serán totalmente opacos (resultado de multiplicar RGB * 1).

Ahora ya el BlendFactor no nos sirve necesitamos que tanto SourceBlend como DestinationBlend reciban información del canal alpha de la textura, esto lo haremos de la siguiente forma:

//Activamos el AlphaBlending

GraphicsDevice.RenderState.AlphaBlendEnable = true;

//Utilizamores como operador la suma para la mezcla

GraphicsDevice.RenderState.BlendFunction = BlendFunction.Add;

//Multiplica los valores RGB de la vidriera por la información almacenada en el canal alpha de la textura

GraphicsDevice.RenderState.SourceBlend = Blend.SourceAlpha;

//Multiplica los valores RGB del fondo por el inverso de los valores multiplicados en el canal alpha de la textura (1 - alpha)

GraphicsDevice.RenderState.DestinationBlend = Blend.InverseSourceAlpha;

El resultado es el siguiente:

************************************************************************************************

- Alpha Blending en XNA (I de IV)

- Alpha Blending en XNA (II de IV)

- Alpha Blending en XNA (III de IV)

- Alpha Blending en XNA (IV de IV)

************************************************************************************************

Problemas con el ZBuffer en XNA

2010-01-24T18:51:23Z

El zbuffer es el algoritmo que se utiliza a la hora de dibujar los objetos en pantalla para decidir que objetos están delante de otros, recibe este nombre ya que se realiza un test de las coordenadas z de los objetos para comparar la profundidad a la que se encuentran en el mundo 3D. Esto a muchos matemáticos o físicos les puede resultar extraño ya que están acostumbrados a que en sus sistema de referencia la z es el vector que apunta hacia arriba, en los gráficos 3D el eje z es el que “entra hacia dentro de la pantalla” para sus valores positivos. Mucha gente piensa que esto se debe a discusiones entre informáticos y matemáticos o físicos XD, pero no es cierto, simplemente se debe a que se intentan facilitar las operaciones que se tienen que realizar con la cámara para representar los modelos y por ellos la cámara en un mundo 3D siempre se pone “como mirando al suelo” perpendicular al plano XY.

Los problemas de Zbuffer pueden ser confundidos con problemas de flip de normales, suelen tener un aspecto como:

Render Correcto

Render con problema de Zbuffer

Como se puede apreciar en la segunda imagen, el algoritmo que decide que se debe pintar delante y que detrás está fallando, de todas formas para detectar este tipo de problemas también os podréis fijar en que si rotáis el modelo puede que desde algunos ángulos se vea correctamente y desde otros no.

Este es uno de los primeros problemas con los que se encuentran muchas de las personas que empiezan a trabajar con XNA, esto se debe generalmente a problemas en el código del render. XNA facilita muchas tareas y los que descubren esta tecnología después de haber trabajado con muchas otras librerías anteriores ven el “cielo abierto” y este tipo de problemas los saben detectar rápidamente y buscarle soluciones, el problema normalmente lo tienen los desarrolladores con menos experiencia que se adaptan rápidamente a la facilidad de trabajar con XNA pero cuando les surge un problema de este tipo no entienden el porque ocurre, muchos incluso piensan que el problema se debe al formato de modelos que usan ó a que no se ha exportado bien desde alguno de los programas de diseño con los que trabajan 3D Studio Max, Maya, SoftImage, blender, …

El problema suele aparecer cuando se intenta mezclar un render2D y un render3D al mismo tiempo usando para dibujar esto las clases SpriteBatch y BasicEffect que vienen por defecto con XNA, un posible ejemplo:

Matrix[] transforms = new Matrix[model.Bones.Count];

model.CopyAbsoluteBoneTransformsTo(transforms);

localWorld = Matrix.Identity

* Matrix.CreateRotationY(rotation.Y)

* Matrix.CreateRotationX(rotation.X)

* Matrix.CreateRotationZ(rotation.Z)

* Matrix.CreateTranslation(position)

* Matrix.CreateScale(scale);

foreach (ModelMesh mesh in model.Meshes)

    foreach (BasicEffect effect in mesh.Effects)

        effect.EnableDefaultLighting();

        effect.PreferPerPixelLighting = true;

        effect.World = transforms[mesh.ParentBone.Index] * localWorld * camera.World;

        effect.View = camera.View;

        effect.Projection = camera.Projection;

    mesh.Draw();

spritebatch.Begin();

spritebatch.DrawString(font, "Test", Vector2.Zero, Color.White);

spritebatch.Draw(Texture, position, Color.White);

spritebatch.End();

base.Draw(gameTime);

Este es el render básico 3D que podemos encontrar en los tutoriales de XNA, en el que pintamos un modelo 3D usando BasicEffect, y en una segunda parte pintamos un texto y una textura en 2D con spritebatch, este código probará estos errores de ZBuffer de los que hemos hablado, una posible solución sería:

Cambiar la línea del spritebatch.Begin(); por:

spritebatch.Begin(SpriteBlendMode.AlphaBlend, SpriteSortMode.Immediate, SaveStateMode.SaveState);

Con esto le estamos indicando que realice el test de alfa para la textura y el texto, que envíe los elementos 2D directamente sin ordenarlos previamente y que salve el estado del Device y lo restaura justo después de realizar el dibujado 2D. La clave está en lo último en salvar el Device y el motivo es que spritebatch modifica la configuración del Device actual (la configuración con la que hemos pintado el modelo 3D y que viene por defecto) desactivando el Zbuffer y no restaurándolo después.

Lo importante es que aunque uséis esta solución entendáis porque soluciona el problema, guardar el estado del Device y restaurarlo en cada frame es algo más lento que si configuráramos directamente el Device con una configuración completa valida para todo aquello que queremos dibujar, o si solo cambiáramos ciertos parámetros del Device y no todos, de todas formas tampoco estamos hablando de unas grandes pérdidas de tiempo, aunque para obtener resultado más profesionales esto si que sería algo a estudiar.

Además del Zbuffer ¿qué otras cosas modifica el spritebatch de la configuración del Device que puedan darme problemas?, pues aquí os dejo una lista completa de las configuraciones que realiza el spritebatch sobre el Device:

GraphicsDevice.RenderState.CullMode = CullMode.CullCounterClockwiseFace;

GraphicsDevice.RenderState.DepthBufferEnable = false;

GraphicsDevice.RenderState.AlphaBlendEnable = true;

GraphicsDevice.RenderState.AlphaBlendOperation = BlendFunction.Add;

GraphicsDevice.RenderState.SourceBlend = Blend.SourceAlpha;

GraphicsDevice.RenderState.DestinationBlend = Blend.InverseSourceAlpha;

GraphicsDevice.RenderState.SeparateAlphaBlendEnabled = false;

GraphicsDevice.RenderState.AlphaTestEnable = true;

GraphicsDevice.RenderState.AlphaFunction = CompareFunction.Greater;

GraphicsDevice.RenderState.ReferenceAlpha = 0;

GraphicsDevice.SamplerStates[0].AddressU = TextureAddressMode.Clamp;

GraphicsDevice.SamplerStates[0].AddressV = TextureAddressMode.Clamp;

GraphicsDevice.SamplerStates[0].MagFilter = TextureFilter.Linear;

GraphicsDevice.SamplerStates[0].MinFilter = TextureFilter.Linear;

GraphicsDevice.SamplerStates[0].MipFilter = TextureFilter.Linear;

GraphicsDevice.SamplerStates[0].MipMapLevelOfDetailBias = 0.0f;

GraphicsDevice.SamplerStates[0].MaxMipLevel = 0;

Además de esto también modifica los vértices, los índices, la declaración de vértices, e incluso las propiedades del Device para pixel and vertex shader.

Una solución más eficiente sería simplemente reactivar el zbuffer después del SpriteBatch.End(), de la siguiente forma:

GraphicsDevice.RenderState.DepthBufferEnable = true;

GraphicsDevice.RenderState.AlphaBlendEnable = false;

GraphicsDevice.RenderState.AlphaTestEnable = false;

Y eso fue todo XD.

Shaders en XNA

2010-01-10T19:21:00Z

Hace unas semanas Jesús Bosch me lió para dar un webcast online (si Jesús fue así ahora no lo niegues XD), y la idea principal es que iba a ser un webcast orientado a desarrolladores de XNA por lo que todos tendrían ya unos ciertos conocimientos previos sobre esta tecnología.

La charla entonces la centré en una introducción al mundo de los shaders y a como poder hacer uso de ellos dentro de XNA, los shaders para que el que no sepa de que estoy hablando son mini programas que se escriben para ser ejecutados en la GPU (Graphics Processing Unit, el procesador de las tarjetas gráficas de nuestros ordenadores).

Estas tarjetas están especializadas en cálculos en coma flotante y matriciales a diferencia de las CPU que son procesadores de propósito general, por lo que el rendimiento de nuestros juegos y aplicaciones con XNA y Shaders puede verse incrementado enormemente. Es más para el que lo desconozca en XNA todo se pinta mediante Shaders, por eso para poder ejecutar XNA en cualquier ordenador se requiere una tarjeta que soporte Pixel and Vertex Shader 1.1 al menos, esto tampoco es una restricción muy grande para los días que corren, ya cualquier chip gráfico de los que llevan varios años integrando en las placas base como las típicas de Intel 950 ya soportan esto.

Este es el principal motivo por el cual el rendimiento 3D de aplicaciones XNA está tan cercano al de aplicaciones DirectX escritas en C++. Como actualmente el cálculo intensivo se desplaza a la GPU, para la CPU quedan otro tipo de cálculos como puede ser la lógica del juego ó la IA, y es esto lo que se escribe en C#.

Para conseguir esta transparencia dentro de XNA y que los usuarios que prueban esta tecnología puedan desarrollar juegos con un alto rendimiento gráfico sin tener que preocuparse de aprender un lenguaje de Shaders como el HLSL, el equipo de desarrollo de XNA a creado dos clases básicas que se usan para pintar en 2D y en 3D.

Para 2D tenemos el spriteBatch:

Imagen:

spriteBatch.Begin();

spriteBatch.Draw(Texture, Rectangle, Color.White);

spriteBatch.End();

Texto:

spriteBatch.Begin();

spriteBatch.DrawString(font, "Hola Mundo", Position, Color.Red);

spriteBatch.End();

al cual le indicamos si queremos pintar un texto ó una imagen y el se encarga de dibujarlo en pantalla sobre un plano que coloca frente a la cámara, todo esto lo hace mediante un shader y de forma transparente para nosotros, el código de dicho shader está liberado y podéis verlo aquí.

Para pintar modelos 3D han desarrollado el objeto BasicEffect:

foreach (ModelMesh mesh in MyModel)

    foreach (BasicEffect effect in mesh.Effects)

        effect.EnableDefaultLighting();

        effect.World = world;

        effect.View = camera.view;

        effect.Projection = camera.projection;

    mesh.Draw();

el cual también usa un shader internamente y del cual también podemos bichear su código fuente aquí.

A pesar de estas facilidades si realmente queremos sacarle partido a nuestras tarjetas gráficas lo mejor es escribir nuestros propios shaders, y este webcast sobre shaders es un punto por el que empezar a conocer todo ese mundo, (aviso que son 2 horas a un buen ritmo XD).

Ahora está disponible en Channel 9 Spain gracias a Alejandro Hidalgo, espero que os sea útil.