Cuestion Sobre Pixel Shaders

[DraKKaR]

 Estaba divagando sobre métodos de iluminación y pixel shaders,  y me preguntaba si, mediante alguna oscura arte, se podría calcular desde el pixel shader el punto en 3D que corresponde al fragmento que se está procesando. Eso sería perfecto para calcular la iluminación por pixel. ¿Alguien tiene alguna idea de esto?

[Haddd]

 Puedes pasarlo como una coordenada de textura. El problema es el rango que se permite, así que deberías inventarte algún sistema de compresión.

[BeRSeRKeR]

 Puedes utilizar un floating-point rendertarget pero la verdad, ¿para qué lo necesitas en los cálculos de la iluminación per-pixel?

Saludos.

[DraKKaR]

 Pues supongo saber el punto en 3D del pixel que se está renderizando siempre te puede servir. Por ejemplo, para calcular la distancia de ese punto hasta la luz. Aunque eso se puede hacer pasandole al vertex shader la distancia a cada vértice como un color (o como bien dice Haddd como una coordenada de textura) y dejar que el raster interpole ese color por pixel a lo largo de todo el polígono. Lo malo son las limitaciones de las que habla Haddd, como el formato que tienes que pasarle al shader: si es un color tiene que ser entre 0 y 1. Aunque si es una coordenada de textura puedes pasarle cualquier valor, pero no se interpolará a lo largo de toda la superficie como en el caso del color. Aunque si desde dentro del pixel shader se puede conocer la coordenada de textura del pixel actual, pues todo resuelto.

Perdonadsi digo chorradas, pero soy nuevo en esto de los shaders.

[Haddd]

 Los shaders 4.0 ya resuelven estas "chorradas". Todo se trata en un mismo shader y no hay que pasarse variables entre vertex shaders y pixel shaders. Pero...¿cuando llegarán? ¿2005?

[DraKKaR]

 ¿Shaders 4.0? Pero ¿los próximos shaders que van a sacar todavía son los 3.0 no? Que ganas de rallarse... yo veo bien la diferenciación entre vertex y pixel shaders, ya que se llaman en diferentes lugares de la pipeline.

[BeRSeRKeR]

 Yo tampoco es que sea un lince con los pixel shaders pero supuestamente lo que sí hace el pixel shader es interpolar cada set de coordenadas de textura a lo largo de la superficie. Así, si le pasas la normal y la posición del vértice al pixel shader, éste se encargará de interpolar.

Por lo menos en los pixel shaders 2.0 creo que es así. Sería cuestión de probarlo en otras versiones.

Saludos.

[MChiz]

 Hola!

Lo que dice Berseker es cierto; cualquier valor se interpola.
Y cuidado! No puedes interpolar la distancia a la luz. Por ejemplo:

o -> fuente de luz
v -> vertice
p -> pixels interpolados

Código [Seleccionar] Expand


                 o
v----------------------------v


En el centro del poligono esta mucho mas cerca que cualquiera de los dos vertices.

Un saludote!

[DraKKaR]

 Umm.. mchiz, yo creo que la interpolación de la distancia SÍ que daria para cada píxel el valor de la distancia correcta. El problema que comentas sucedia cuando le pasabas la dirección hacia la luz como un color por vértice, entonces al nterpolarse el color, en los puntos dentrales del polígono el vector dejaba de ser unitario. Pero en el caso de la distancia, lo que queemos exactamente es eso, que el vector no sea unitario y que se interpole linealmente entre sus vértices.

Puede que tengamos un concepto distinto de esa interpolacion.

[MChiz]

 No se si acabo de entenderte.
Lo que tu dices es de interpolar los vectores del vertice a la luz, no? En este caso si funcionaria, pero en el pixel shader tendras que calcular el modulo de este vector, que es lo costoso, asi que yo creo que es mejor utilizar la funcion 'distance' directamente desde el pixel shader. Lo unico que nos ahorramos interpolando estos vectores es una resta que, CREO, sale casi gratis y, ademas, damos opcion a que si sacan una nueva tarjeta que ejecute la funcion 'distance' de una tajada desde el pixel shader, nuestro juego pueda hacer uso de ella.
De todos modos, es una bonita idea : )

Es que me confundi, porque en tu post decias que le pasabas al pixel shader la distancia para que la interpolase y, en ese caso, no funciona.

Un saludote!

[BeRSeRKeR]

 Por cierto, para los que uséis OpenGL, ya podéis empezar a utilizar el glSlang siempre y cuando tengáis una Radeon 9500 o superior. Para los que tengan una nVidia, tendrán que esperar a que den soporte a través de los drivers.

Saludos.

[Ithaqua]

 Hmm, eso suena muy bien :)
Se sabe para cuando la dará nvidia?

[BeRSeRKeR]

 La verdad es que no tengo ni idea. Pásate por aquí si quieres echarle un vistazo al código de los shaders. Las demos de simulación de ropa y la que se ve el sistema de partículas, lo utilizan.

Realmente es muy parecido al HLSL o Cg. La ventaja que yo le veo es que parece ser que los shaders cogen los estados actuales de OpenGL. Por ejemplo, en HLSL o Cg (aunque creo que con éste ya se podía hacer) tienes que pasarle la matriz de transformación manualmente. Pues bien, con el GLSL, basta con utilizar la variable predefinida gl_ModelViewProjectionMatrix. O por ejemplo, para acceder a las coordenadas de vértice basta con escribir gl_Vertex y en el caso de las coordenadas de textura, para acceder al primer set, sería gl_MultiTexCoord0.

Vamos no lo he mirado muy detenidamente pero parece que es un aspecto a resaltar. Lo que no he mirado es cómo es el tema de implementar el sistema de carga, compilación y demás, dentro de la aplicación.

Saludos.

[DraKKaR]

 ¿Sginifica todo esto que OpenGL 2.0 ya está listo? ö

[BeRSeRKeR]

 No, significa que ATI ha dado soporte para el GLSL, pero supongo que no cumple con todas las especificaciones de OpenGL 2.0. Vamos, digo yo que OpenGL 2.0 tendrá algo más que un lenguaje de alto nivel para shaders.

Ahora falta que nVidia se digne a dar soporte en sus drivers. Pero ya se sabe, ellos son reacios ya que prefieren apoyar su Cg. Pero digo yo que antes o después tendrán que ceder. O eso, o se la juegan a costa de poder salir mal parados. Supongo que acabarán cediendo, aunque ahora se hagan los remolones :D

Saludos.