Sistema De Shaders A Lo Quake 3

[Helius]

 Hay que ver qué difícil es hacer un sistema de shaders estilo Quake 3 sin la fixed pipeline, o soy yo que me estoy liando mucho... :huh:

Veamos, necesito varios stages con sus diferentes texturas y sus diferentes operaciones y los tengo definidos en ficheros de texto a lo Quake 3.

Antes asociabas las texturas que querías para cada stage y le decías a DirectX las operaciones en cada stage y a volar...

Ahora las operaciones de blending hay que hacerlas en el pixel shader por lo que si quiero sumar 2 stages tengo que hacer la suma en el PS. Bien, ¿tengo que tener un PS por cada tipo de shader que tenga? Es decir, si en un shader utilizo 2 stages para hacer por ejemplo un ADD y en otro shader utilizo 3 estages con otras operaciones (un ADD y un MODULATE), ¿tengo que tener dos PS distintos,uno que soporte 2 stages y otro que soporte 3? No veo la manera de hacerlo sólo con uno, ni la de poder elegir la operación dentro del PS :(

Luego otra cosa, si quiero hacer operaciones de tipo rotacion, scroll, escalado de cada stage necesito unas coordenadas de textura diferentes para cada stage, y por consiguiente unos Vertex Shaders que se alimenten con todas estas coordenadas de textura, uff

Bueno y si quiero mezclar todo esto con los PS que tengo de luz por pixel con normal mapping u offset mapping ya es que se me queda la cara así:  :wacko:

¿Alguien tiene alguna idea o puede aclararme un poco la mente?

[BeRSeRKeR]

 Es el problema que nos hemos encontrado nosotros con los vertex & pixel shaders y también el que me planeteé yo cuando también estuve pensando en implementar los shaders de q3 por hardware (por software también los tenía hechos).

Las posibilidades ahora mismo creo que son, o utilizar uniforms y crear tantas combinaciones como sean necesarias (en el código tendrías que utilizar ifs) o utilizar fragment linking.

El primer método me parece una barbaridad ya que el número de posibles combinaciones puede llegar a ser exagerado. El que mejor suena es el fragment linking que consiste en crear fragmentos de shader que realizan una tarea muy específica y posteriormente, en tiempo de ejecución se recolectan los fragmentos necesarios y se compilan, formando así un shader completo.

Nosotros nos habíamos decantado por el fragment linking pero debido a un posible bug en las runtime de .NET (no sé si está confirmado), tuvimos que dejarlo para más adelante, aunque el código está ahí implementado.

En cualquier caso, lo cierto es que los shaders siguen siendo poco flexibles hoy en día.

Saludos.

[Helius]

 Ufff, malas noticias  :(

¿Y cómo lo harán juegos como el Doom 3?

Aunque la verdad que no he visto mucho movimiento en sus materiales, sólo algunas capas con ADD...

[BeRSeRKeR]

Ufff, malas noticias  :(

¿Y cómo lo harán juegos como el Doom 3?

Aunque la verdad que no he visto mucho movimiento en sus materiales, sólo algunas capas con ADD...

Pues seguramente ese tipo de cosas las siguen haciendo por software porque en los shaders que yo he ojeado no he visto que se hagan los típicos efectos de quake3, aunque como bien dices, en Doom3 no hay tantos como había en Quake3.

Saludos.

[Helius]

 

Pues seguramente ese tipo de cosas las siguen haciendo por software porque en los shaders que yo he ojeado no he visto que se hagan los típicos efectos de quake3, aunque como bien dices, en Doom3 no hay tantos como había en Quake3.

Saludos.

¿Por software a qué te refieres?  :huh:

Si yo quiero renderizar un polígono con per pixel lighting y normal mapping debo usar un VS y un PS.

Como estoy usando un PS el multitexturing de DirectX se pierde ¿no? Es decir, ya no puedo hacer alphaop's ni colorop's entre stages ¿no?
Se supone que todo eso lo debería hacer el PS que uses.

No se a que te refieres a hacerlo por software. Yo no veo la manera :(

[BeRSeRKeR]

 Me refería al scroll/escalado/etc de las coordenadas de textura (operaciones per-vertex). Evidentemente lo que son las operaciones de textura deben hacerse en el pixel shader ya que la fixed pipeline ya no pinta nada.

Saludos.

[Helius]

 Ahh, bueno el scroll, escalado y rotación los puedo hacer aplicando transformaciones a las coordenadas de textura sin problemas pero el tema de blending entre varios stages usando formas de onda tipo square, saw y todo eso me va a costar bastante y tampoco lo veo muy claro, sobre todo por los tipos distintos de PS que me van a salir, y la forma de alimentarlos, buffff...

Limitaré el blending a 2 stages o algo así, pero siempre llegará mi grafista que necesitará uno más para hacer algún efecto  :lol:  

[Haddd]

 Y luego va ATI y dice que los PS 3.0 no son necesarios  :huh:  Menos mal que este año cambiará la cosa  :D


¡Vivan los shaders 4.0! Pero que vengan rapidito... B)  

[Helius]

 No tengo ni idea de qué es lo que traen nuevo los 4.0 pero si resuelven mi problema estoy contigo ;)

[Pogacha]

 Vi hace poco una implementacion de shaders de este estilo:

Código [Seleccionar] Expand

shader "MiShader"
{
 stage 0 {
    Vertex {
      Program {
       // aca ponian un vertex shader
      };
   }
   Pixel {
        Blend Modulation;
        Pixel = Color * Material.Texure_Difuse;
   }
 }

  stage 1  (per Light){
     Vertex {
       TexCoord0.Generate_S( 0, 0, 1, Light.z );
       TexCoord0.Generate_R( 0, 1, 0, Light.x );
       Color = Light.Color;
    }
    Pixel {
       Blend Add;
       Texture0 Material.Texture_Difuse;
       Texture1 Light.Cube_Projection;
       Program  {
          // aca metian un pixel shader
       };
   }
 }
};

La cuestion que este shader seria el ideal pero es un poco lento despues pues tenes que hacer un evaluador de expresiones y rellenar los campos como Texture0 con precomandos, tambien metian disintos codepaths en los programas.
A mi no me parece adecuado, yo en realidad prefiero shaders pseudo-inteligentes como el que uso yo, que te permiten una gamma de cosas para hacer y punto, no se...
Saludos

[Pogacha]

 No encontre de donde carajo saque lo de arriba, lo busque pero no lo encontre, pero el OGL2SDK tiene un sistema de shader tambien bastante bueno, pero ... es OGL ....
Saludos

[DraKKaR]

 

¡Vivan los shaders 4.0! Pero que vengan rapidito... cool.gif

¿Se sabe algo ya del Shader Model 4.0 ?

[Pogacha]

 Me parece que esperar los shaders 4.0 cuando la placas mas vendidas son las Geforce4 (por lo menos en latinoamerica) es algo medio "insano". Con los shaders 2.0 puedo hacer de todo, no entiendo cual es la desesperación por tener mas y mas tecnologia si todavia no dominamos la actual...

[BeRSeRKeR]

 La cuestión es que algo tan simple como debería ser poder tener un shader de iluminación configurable, se convierte en algo pesado. Por ejemplo nosotros queremos tener los siguientes parámetros de configuración para la iluminación:

• Affect Diffuse
  
• Affect Specular
  
• Attenuation Type
  
• Projector Enabled
  
• Cast Shadows

Hay dos posibilidades (que yo sepa) como he dicho antes. Una es utilizar uniforms lo cual te obliga a crear tantas técnicas como posibles configuraciones pueda tener el shader, y además manejar todas esas técnicas en el código. Las posibles combinaciones serían:

// Light


// Light_AffectDiffuse
// Light_AffectSpecular
// Light_AttenuationType
// Light_ProjectorEnabled
// Light_CastShadows


// Light_AffectDiffuse_AffectSpecular
// Light_AffectDiffuse_AffectSpecular_AttenuationType
// Light_AffectDiffuse_AffectSpecular_AttenuationType_ProjectorEnabled
// Light_AffectDiffuse_AffectSpecular_AttenuationType_ProjectorEnabled_CastShadows

// Light_AffectDiffuse_AttenuationType
// Light_AffectDiffuse_AttenuationType_ProjectorEnabled
// Light_AffectDiffuse_AttenuationType_ProjectorEnabled_CastShadows

// Light_AffectDiffuse_ProjectorEnabled
// Light_AffectDiffuse_ProjectorEnabled_CastShadows

// Light_AffectDiffuse_CastShadows


// Light_AffectSpecular_AttenuationType
// Light_AffectSpecular_AttenuationType_ProjectorEnabled
// Light_AffectSpecular_AttenuationType_ProjectorEnabled_CastShadows

// Light_AffectSpecular_ProjectorEnabled
// Light_AffectSpecular_ProjectorEnabled_CastShadows

// Light_AffectSpecular_CastShadows


// Light_AttenuationType_ProjectorEnabled
// Light_AttenuationType_ProjectorEnabled_CastShadows

// Light_AttenuationType_CastShadows


// Light_ProjectorEnabled_CastShadows

A mí me parece una locura tener que crear todas esas combinaciones y tener que controlarlas a través de código. Además, no podemos utilizar más condiciones en el shader porque hemos alcanzado el límite máximo de constantes, así que.... :)

Luego tenemos la opción que parecía que nos iba a salvar, el fragment linking, pero desgraciadamente parece que hay algún problema con las runtime de .NET así que habrá que esperar a la próxima revisión a ver si lo solucionan.

Por lo que tengo entendido, con el SM3.0 tenemos dynamic branching por lo que en teoría este tema quedaría solucionado. Y en cuanto al SM4.0, lo único que sé es que unificará vertex & pixel shaders y se programará todo junto, sin distinciones entre per-vertex y per-pixel.

Saludos.

[Haddd]

 Tienes razón Pochaga refiriéndote a que los shaders 4.0 ya es pedir demasiado. Y los 3 también  :)  Por eso nosotros nos hemos marcado los 2 como algo "standard" en un futuro cercano.

No creo que los 3.0 sean standard hasta dentro de 4 ó 5 años