Agregando Soporte Para Shaders En Un Engine.

[fiero]

 Ni blanco ni negro, la vida es gris.

Pablo no te espantes que aqui somos muy burros y nos gusta mucho discutir sobre las discusiones discutidas  :rolleyes: ...

[Pablo Zurita]

 Bueno, creo que Pogacha dejo todo mas o menos claro, no voy a seguir el tema porque no tengo interés en discutir algo que personalmente me parece tan obvio. Solo voy a responder a preguntas y comentarios sobre las notas que escribí.

[Pablo Zurita]

Ni blanco ni negro, la vida es gris.

Pablo no te espantes que aqui somos muy burros y nos gusta mucho discutir sobre las discusiones discutidas  :rolleyes: ...

No me espanto, solo trato de usar mi tiempo lo mejor posible :)

[Pogacha]

 Espanto = asustarse ;), en argentino es huir.

[tiutiu]

 Hombre, no esta mal el articulo, aunque tocas temas que ya existian con la FFP. La ordenacion por material siempre se ha tenido en cuenta (o al menos ha estado ahi).
Al final lo que te queda, mas que un shader, es un material abstracto con sus parametros y su guion de ejecucion (el shader en si). Necesitas una interfaz para cambiar dichos parametros, un metodo de ordenacion, etc... Vamos, como en la FFP (sin entrar en temas de programacion, ¿eh?) :)

Sobre el apartado de Los shaders y la geometria, hay cosas que me gustaria comentar.
El caso ese de la esfera - que por cierto, dices que el culling rechaza la esfera, el shader la agranda y entonces se sale del frustum; no tiene mucho sentido, ¿no? - seria algo especial, puesto que si aplicas displacement mapping o algun efecto con geometry shaders (habra que empezar a tenerlos en cuenta :S ) tendrias que usar un hull o algo parecido para marcar el posible volumen de efecto del shader, igual que se hace cuando calculas los shadow casters para cada luz. De ese modo podriamos estar seguros de que si rechazamos un renderable no va a afectar al resultado final del frame.
Sobre lo del tone mapping, tendriamos que distinguir entre shaders de materiales y shaders de post-produccion. Ni se aplican igual ni en la misma fase de renderizado. Tambien habriamos de mirar el soporte para deferred shading, que es otro tema a tener en cuenta.
Cuando comentas lo del volumen de impacto en la luz omni, eso no tiene que ver con la integracion de shaders. Es mas de culling que de otra cosa, y nos podemos referir a lo mismo que he dicho sobre el caso de la esfera.

Concluyendo:
- Abstraer el concepto de material desde la FFP y los shaders, ya que comparten muchas caracteristicas (parametros, cambios de estado, ordenacion).
- Contemplar que la geometria que procesamos en la CPU puede ser diferente que la de la GPU (displacement mapping, geom. shaders).
- Diferenciar entre tipos de efectos, si son para renderizables (materiales) o post-produccion (¿donde iria el deferred shading?).


PD: si me permites un consejo, escribe mas en la seccion de conclusiones.

[Pablo Zurita]

Hombre, no esta mal el articulo, aunque tocas temas que ya existian con la FFP. La ordenacion por material siempre se ha tenido en cuenta (o al menos ha estado ahi).
Al final lo que te queda, mas que un shader, es un material abstracto con sus parametros y su guion de ejecucion (el shader en si). Necesitas una interfaz para cambiar dichos parametros, un metodo de ordenacion, etc... Vamos, como en la FFP (sin entrar en temas de programacion, ¿eh?) :)

Sobre el apartado de Los shaders y la geometria, hay cosas que me gustaria comentar.
El caso ese de la esfera - que por cierto, dices que el culling rechaza la esfera, el shader la agranda y entonces se sale del frustum; no tiene mucho sentido, ¿no? - seria algo especial, puesto que si aplicas displacement mapping o algun efecto con geometry shaders (habra que empezar a tenerlos en cuenta :S ) tendrias que usar un hull o algo parecido para marcar el posible volumen de efecto del shader, igual que se hace cuando calculas los shadow casters para cada luz. De ese modo podriamos estar seguros de que si rechazamos un renderable no va a afectar al resultado final del frame.
Sobre lo del tone mapping, tendriamos que distinguir entre shaders de materiales y shaders de post-produccion. Ni se aplican igual ni en la misma fase de renderizado. Tambien habriamos de mirar el soporte para deferred shading, que es otro tema a tener en cuenta.
Cuando comentas lo del volumen de impacto en la luz omni, eso no tiene que ver con la integracion de shaders. Es mas de culling que de otra cosa, y nos podemos referir a lo mismo que he dicho sobre el caso de la esfera.

Concluyendo:
- Abstraer el concepto de material desde la FFP y los shaders, ya que comparten muchas caracteristicas (parametros, cambios de estado, ordenacion).
- Contemplar que la geometria que procesamos en la CPU puede ser diferente que la de la GPU (displacement mapping, geom. shaders).
- Diferenciar entre tipos de efectos, si son para renderizables (materiales) o post-produccion (¿donde iria el deferred shading?).


PD: si me permites un consejo, escribe mas en la seccion de conclusiones.

Bueno, por fin la universidad me da un poco de tiempo para responder.

Hombre, no esta mal el articulo, aunque tocas temas que ya existian con la FFP.

Claro, la idea de lo que escribí no es exponer una idea innovadora, es simplemente dar a saber que hay ciertos factores a tener en cuenta al momento de implementar el soporte para shaders.

La ordenacion por material siempre se ha tenido en cuenta (o al menos ha estado ahi).

Bueno, uno puede argumentar que la idea de ordenar por materiales tampoco era innovadora en su momento porque la idea de mantener los cambios de estados a la menor cantidad es una optimización básica.

Al final lo que te queda, mas que un shader, es un material abstracto con sus parametros y su guion de ejecucion (el shader en si). Necesitas una interfaz para cambiar dichos parametros, un metodo de ordenacion, etc... Vamos, como en la FFP (sin entrar en temas de programacion, ¿eh?) :)

La definición de un material depende de lo que definís para un material. En mi caso un material puede tener varios shaders, entonces ordenar por material no me sirve porque termino con mas cambios de estados. La idea es tener la menor cantidad de cambios de estados, como logras eso depende de cómo tenes estructurado tu engine.

Sobre el apartado de Los shaders y la geometria, hay cosas que me gustaria comentar.
El caso ese de la esfera - que por cierto, dices que el culling rechaza la esfera, el shader la agranda y entonces se sale del frustum; no tiene mucho sentido, ¿no? - seria algo especial, puesto que si aplicas displacement mapping o algun efecto con geometry shaders (habra que empezar a tenerlos en cuenta :S ) tendrias que usar un hull o algo parecido para marcar el posible volumen de efecto del shader, igual que se hace cuando calculas los shadow casters para cada luz. De ese modo podriamos estar seguros de que si rechazamos un renderable no va a afectar al resultado final del frame.

A eso me refiero con este problema en particular. Existe un convex hull que contiene a esa esfera, al momento de dibujar testeas el frustum contra el convex hull y ves que esta afuera entonces decidís no dibujar. Pero si esa esfera original es modificada con un shader que causa que la esfera se expanda fuera del convex hull entonces vas a hacer el culling de manera equivocada. El problema en base es que si no podes actualizar el convex hull después del shader entonces no vas a poder hacer el culling correctamente. Ahí esta el sentido de usar el ejemplo, pero si lo queres pensar en un ejemplo mas artístico podes tomar un plano y subdividirlo varias veces. Piensa el convex hull de ese plano desde el CPU y como cambiaria si un vertex shader transforma ese plano en un terreno de gran extensión en los tres ejes. Desde el CPU tenes un convex hull que es mucho mas chico mientras que si tenes en cuenta los cambios a los vértices hecho en el GPU el convex hull seria diferente.

Sobre lo del tone mapping, tendriamos que distinguir entre shaders de materiales y shaders de post-produccion. Ni se aplican igual ni en la misma fase de renderizado.

El artículo habla sobre notas al momento de implementar los shaders en la manera más básica. De igual forma no hace falta diferenciar los shaders de ninguna manera. En mi caso un mismo shader se puede aplicar a la geometría definida por el artista, o la geometría definida por el engine en si (como seria un cuadrado que ocupa la pantalla para los efectos post-processing). Se aplican de la misma manera porque la idea es siempre tener los parámetros correctos y activar el shader. Con respecto a cuando se renderiza, eso depende de cada engine y de la escena en si, no es la idea del articulo decir cuando se tiene que renderizar cada cosa, por eso el articulo habla sobre shaders y no sobre materiales.

Tambien habriamos de mirar el soporte para deferred shading, que es otro tema a tener en cuenta.

El tema sigue siendo el mismo, tener en cuenta como hacer el culling basado en el shader (ya sea con un convex hull y/o stencil rectangles), y ejecutar los shaders apropiados correctamente, nada especial en este caso. El artículo no te va a decir como implementar deferred shading pero si te dice cosas básicas sobre los shaders que vas a tener que tener en cuenta incluso cuando implementes deferred shading.

Cuando comentas lo del volumen de impacto en la luz omni, eso no tiene que ver con la integracion de shaders. Es mas de culling que de otra cosa, y nos podemos referir a lo mismo que he dicho sobre el caso de la esfera.

Es un ejemplo de porque se definen los shaders volumétricos. Por una parte esta el culling en si, pero por otra parte esta la parte de tener en cuenta que aplicar shaders a todo en casa pasada no es lo más conveniente y por lo tanto es necesario tener estos shaders volumétricos.

Concluyendo:
- Abstraer el concepto de material desde la FFP y los shaders, ya que comparten muchas caracteristicas (parametros, cambios de estado, ordenacion).

No, lo que abstraes son los shaders que comparten el mismo shader compilado. Si varios materiales usan un mismo shader entonces vas a cambiar de material según sea conveniente para evitar el cambio del shader. Y si tienen parámetros diferentes y el mismo shader compilado entonces cambias los parámetros y renderizas.

- Contemplar que la geometria que procesamos en la CPU puede ser diferente que la de la GPU (displacement mapping, geom. shaders).

Exacto, esa era la idea.

- Diferenciar entre tipos de efectos, si son para renderizables (materiales) o post-produccion (¿donde iria el deferred shading?).

No porque no estas aplicando cosas diferentes. Son simplemente shaders como cualquier otro pero con parámetros diferentes, nada más. Eso a nivel shaders, si haces otras abstracciones pueden ser distintos pero a nivel shaders son iguales y teniendo en cuenta que tenes que mantener los cambios de shaders al mínimo entonces no tendría que haber una distinción entre un efecto en lo que vos llamas un material en la geometría renderizable, y un efecto de post-processing.

PD: si me permites un consejo, escribe mas en la seccion de conclusiones.

Tengo tantas cosas por mejorar al momento de escribir :( ... Pero bueno lo voy a tener en cuenta para el próximo.

[Xam]

 Sobre lo de copiar y pegar el código de un algoritmo o desarrollarlo por uno mismo, yo también comparto la opinión de Pablo Zurita y de Pogacha. Además, creo que ya se ha explicado bastante bien la diferencia así que no voy a añadir nada más.

Sobre el artículo. Creo que Pablo Zurita simplemente intenta explicar, desde su experiencia al dar soporte para shaders en su motor, que más importante que los shaders en sí es la manera de gestionarlos. Y que esta gestión no es para nada trivial. Sobretodo si se quiere conseguir unos resultados lo más eficientes posibles. Y no creo que para explicar esto haga falta poner código.

Muchas veces la gente no comprende toda la magnitud de lo que se dice en un artículo o paper y busca código fuente o alguna demostración visual que apoye los razonamientos y las conclusiones del mismo. Y al no encontrarlos se puede sentir decepcionada. Sin tener en cuenta que a lo mejor la finalidad de ese artículo o paper no era la de implementar nada.

Creo que esto es lo que ha pasado con el artículo de Pablo Zurita. Hay que entender que para algunas personas es suficiente con lo que se dice en un artículo o paper para sacar provecho del mismo.