Escribí de nuevo en mi blog. Esta vez son unas pequeñas notas al momento de agregar soporte para shaders en un engine. Espero que a alguien le sirva.
Soporte para shaders en un engine.
Muy interesante, pero no explicas nada, falta toda la parte de implementación :huh:
Nosotros creamos los shaders en tiempo de ejecución, así resolvemos el hecho de que tengamos una luz spot, o direccional o un tipo de iluminación diferente....
¿como resuelves tu ese problema? ¿fragment linker? Nosotros lo probamos y el rendimiento era pésimo....
CitarMuy interesante, pero no explicas nada, falta toda la parte de implementación :huh:
Esto es un acto deliberado mío. Personalmente me molesta los casos como
http://www.stratos-ad.com/forums/index.php...=ST&f=14&t=6414 donde el interés no esta en aprender en si sino que conseguir el código para hacer tal cosa. De esa manera no aprendes, solo supones que aprendiste como es el tema. Por otra parte estas son solo unas notas, cosas que como desarrollador uno tiene que tener en cuenta al momento de implementar el soporte para shaders.
CitarNosotros creamos los shaders en tiempo de ejecución, así resolvemos el hecho de que tengamos una luz spot, o direccional o un tipo de iluminación diferente....
¿como resuelves tu ese problema? ¿fragment linker? Nosotros lo probamos y el rendimiento era pésimo....
En mi engine es simplemente un efecto con impacto volumétrico. Para un pointlight hay una esfera de impacto y lo que determina que sea una luz en si es el hecho de que genera sombras y que el shader en si "ilumina" la escena, pero no hay distinciones especiales. El culling y el scissoring se hacen para todos los efectos volumétricos (a no ser que se le aplique un tag específico para que no se haga). Eso es a nivel engine, pero obviamente existen los tipos de luces en 3dsmax (que es desde donde traigo toda la geometría y demás) para que aparezcan en la escena. Esos shaders ya están escritos y no necesito hacer nada especial.
Realmente no se cual es el problema que tenes, son shaders diferentes, si queres hacer algo mas general podes tener funciones dentro del shader para la atenuación y demás que sean genéricas para todos los tipos de luces, pero igual sigo sin saber a que te referís.
Vaya, pues lo siento mucho si te molestó mi post, pero deberias tratar de no hacer comentarios ofensivos con el resto de miembros de la comunidad :P
Una cosa es mirarte un código que muestra como utilizar shaders .fx (el código q me miré al final tiene menos de 400 lineas, y si miramos solo la parte que me interesa de los shaders, en unas 50 lo soluciona), y otra ponerte luego a implementarlo en un engine.
Yo lo he integrado en IrrLicht, y creo que sí he aprendido un par de cosas nuevas, tanto acerca de los shaders, como del propio IrrLicht.
Primero que nada mi post no fue un ataque contra tu persona sino contra una actitud general. Simplemente use tu post como ejemplo. Y no, no trato de ofender a la comunidad, en todo caso trato que vean sus errores incluso si a alguno lo ofende (aunque obviamente seria mucho mejor que no se ofenda nadie).
La conclusión es la misma, en ninguno de los dos casos sabes realmente que estas haciendo. Una persona que realmente sabe del tema puede agarrar la especificación de una API y trabajar con eso, y esa la manera mas efectiva de aprender. Viendo código, cortando y pegando, adaptando para que ande no sirve. Lo que te pasa eventualmente si haces eso es que un día vas a estar sin conexión a Internet o vas a querer hacer algo sobre lo que no hay código y te vas a dar cuenta que no sabias tanto como pensabas.
Copiando y pegando codigo se aprende muchisimo... he copiado y pegado algunos algoritmos como el A*, y entre adaptarlo a mi propio codigo y leer cuatro cosas he aprendido como funciona y lo he modificado a gusto.
Cuando te pones a ver código, generalmente un copia y pega solo consigue errores de compilacion, pero leer ese codigo muchas veces hace que digas "anda joder, asi que si hago esto asi tal tal tal" y te pueda orientar para seguir tu trabajo.
CitarLo que te pasa eventualmente si haces eso es que un día vas a estar sin conexión a Internet o vas a querer hacer algo sobre lo que no hay código y te vas a dar cuenta que no sabias tanto como pensabas
Visto asi, entonces debieramos de estar preparados para reinventar todos los algoritmos y conocerlo todo a la hora programar... por mucho que conozcas como se implementa un shader y como funciona toda esa parafernalia, habra mil efectos o implementaciones que no se te ocurran ni por asomo... y viendo trabajo ya hecho de los demas se pueden hacer cosas muy interesantes.
De hecho no siempre es totalmente necesario comprender todo el codigo que usas, puedes reutilizar el código de alguien en un aspecto tedioso o poco interesante.
Y bueno, es la opinion de un ""programador"" amateur (y le pongo dos comillas...) que lo que ha aprendido, en muy gran parte ha sido leyendo otros códigos
Si eres capaz de cortar y pegar código y conseguir que funcione, significa que tienes capacidad de sobra para haberlo hecho por ti mismo. A mí siempre me ha parecido muchísimo más facil hacer algo desde cero que intentar comprender código ajeno, y creo que hay mucha gente así. Para ser un "copipasteador" de código necesitas ser un crack...
un saludo
Cita de: "[Vil"] Visto asi, entonces debieramos de estar preparados para reinventar todos los algoritmos y conocerlo todo a la hora programar... por mucho que conozcas como se implementa un shader y como funciona toda esa parafernalia, habra mil efectos o implementaciones que no se te ocurran ni por asomo... y viendo trabajo ya hecho de los demas se pueden hacer cosas muy interesantes.
Totalmente de acuerdo.
Yo creo que si necesitas saber cómo van los .fx lo mejor es mirarse el ejemplo de DirectX y ya está. ¿Para qué perder el tiempo mirandose los mil detalles? Esto lo hace todo el mundo, y he visto incluso un video sobre una empresa donde los programadores decían que usaban ejemplos del SDK de Windows, de MSDN, de revistas y de internet.
Es normal que alguna vez hayamos usado código que no sabíamos muy bien cómo funcionaba. No veo dónde está el problema. Si quiero hacer un engine de física, voy a usar un engine 3D hecho por otros programadores, e incluso puede que llegue a usar algun algoritmo matemático necesario para mi simulación física ya implementado. Hacerlo todo desde cero es inviable hoy en día.
Y es verdad, usar el código de otros requiere saber mucho. No hay más que intentar añadirle cosas al Quake 3 para darse cuenta de ello :lol:
A riezgo de parecer chupamedia :P ... lamentablemente pienso que Pablo tiene razón, es la diferencia entre un guitarrista y un guitarrero.
En todos lados que estudié algoritmica con gente que sabía jamas se hablaba de codigo ni de implementaciones (eso ya es materia pasada), se hablaba de como dar optima solución a cada tipo de problema y cada particularidad que pueda ser aprovechada, dandote control total de la situación.
El copiar y pegar muchas veces ayuda cuando no tienes idea, pero es el camino rapido (si si, el mismo que te lleva al infierno (twist) ) es muy facil tentarse de que si ya anda lo abandones y no sepas lo que pasa adentro de eso.
En definitiva, la implementación es una capacidad aparte del conocimiento algoritmico. El conocimiento algoritmico te da completo control de una situación, no importa el sistema o particularidades donde te encuentres, tendras total dominio, la implementación es un uso de ese conocimiento para resolver un determinado problema en particular.
Caso puntual, veo 3000 implementaciones de atenuación y solo he visto 2 o 3 que utilizan exponenciales con coeficientes negativos ( siendo por lejos el mejor metodo a mi entender ), la razón, no hay una implementación dando vueltas por internet. O sea ... el tope de tu creatividad esta dada por lo que otros liberen?
Yo desarrolle toda la teoria de todos los shaders que utilizé por cuenta propia para poder sacar conclusiones ciertas a la hora de implementar y de esta manera logre lo que yo queria.
... tampoco es blanco o negro, todos cutopastamos de 3ros de vez en cuando, a lo que voy es que a esta altura SI tendrías que ser capas de poder implementar cualquier algoritmo que entiendas y poder sacar provecho de las particularidades en su implementación. La forma de aprender es entender la problematica del algoritmo para poder hacer tus implementaciones tomando el máximo provecho.
Saludos.
Citarel tope de tu creatividad esta dada por lo que otros liberen?
Tampoco hay que exagerar, yo hablaba de casos puntuales.
De todas formas, otros "liberan" algoritmos, técnicas (aunque sin implementación) en papers (por ejemplo SIGGRAPH) y tesis doctorales. Esta es la base. No creo que nadie haga todo desde cero.
Los que hacen los PAPERS de donde sacan los codigos? :P
Por supuesto que es muy dificil hacer todo desde cero, pero de donde mas arriva te pares mas propio es tu trabajo y en nuestro caso mas sabras tu ... de nuevo no es blanco ni negro, es solo una tendencia ... que puede orientarse a un o a otro lado.
Saludos.
Estoy de acuerdo con lo que dices Pogacha, pero de ahí a que Pablo me diga que "en ninguno de los dos casos sabes realmente que estas haciendo" por pedir un ejemplo sobre cómo se implementa un shader .fx, hay un trecho. Simplemente pienso que no es una actitud muy positiva que una persona que no lleva ni un mes registrada venga diciendo a otros que llevamos años en esta comunidad cuánto le molesta un post que puse sin que supusiera una ofensa para nadie.
No es tan sencillo como copiar y pastear código. Gracias al ejemplo, ya conozco las funciones empleadas para cargar un shader .fx, y el método para renderizar geometría usando el shader. Pero copypasteando definitivamente no hubiera sido capaz de implementarlo en IrrLicht. Por ejemplo, IrrLicht renderiza sus materiales en un solo paso. En cambio, muchos shaders .fx requieren de varias pasadas para renderizarse, así que tocó reescribir parte del renderer para soportar lás múltiples pasadas necesarias.
Así que haciendo las cosas así también se aprende.
CitarNo creo que nadie haga todo desde cero.
La libreria multiplataforma y multirender que sigo montando esta toda desde cero y no necesita ningun tipo de libreria externa a no ser que sean las nativas del sistema operativo, todo el codigo es mio, basicamente me lo puedo permitir por que es algo que estoy haciendo para pasar el rato :lol:
Creo que este hilo no aportada nada y solo es otra caza de brujas mas en stratos, pero tambien hay que reconocer que el articulo que pones no explica nada, iba a ponerlo el otro dia, pero se me adelanto haddd con su primera linea de su primer mensaje, ultimamente me he parado a leer muchos blogs en internet y no entiendo como la gente pierde tiempo escribiendo algo que te parece interesante pero que lo dejan todo en el tintero quedandote como estas o aun peor teniendo teorias nuevas totalmente equivocadas por que tiene una mente calenturienta el tio que escribio el articulo, ademas esto creo que nos perjudica a todos a la hora de buscar documentacion desde un buscador de internet ya que te encuentras con mil paginas webs que hablan de lo que te interesa, pero realmente no dicen nada, estoy seguro que esto ultimo lo estais observando desde hace tiempo muchos de vosotros.
CitarLos que hacen los PAPERS de donde sacan los codigos?
NB: Cuando digo desde cero, digo desde el cero absoluto. Igual te inventas tú solo todos los algoritmos para renderizar :P .
Se suelen basar en técnicas anteriores. Si miras la última sección de los papers incluye las referencias. Además un paper sin referencias es rechazado sin más. Además los papers no suelen incluir código, bien porque lo consideran trivial, bien porque no les interesa.
Pero bueno, que te entiendo perfectamente. De hecho yo pienso lo mismo, cuanto más aprendas y hagas cosas intentando crear técnicas nuevas mejor y más interesante. Pero para una pruebecilla rápida, pues eso ;). Efectivamente, es una tendencia, y la nuestra es investigar e intentar en la medida de lo posible llegar a una cierta originalidad :) .
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: ...
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í.
Cita de: "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: ...
No me espanto, solo trato de usar mi tiempo lo mejor posible :)
Espanto = asustarse ;), en argentino es huir.
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.
Cita de: "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.
Bueno, por fin la universidad me da un poco de tiempo para responder.
CitarHombre, 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.
CitarLa 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.
CitarAl 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.
CitarSobre 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.
CitarSobre 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.
CitarTambien 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.
CitarCuando 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.
CitarConcluyendo:
- 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.
Citar- 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.
Citar- 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.
CitarPD: 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.
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.