Agregando Soporte Para Shaders En Un Engine.

[Pablo Zurita]

 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.

[Haddd]

 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....

[Pablo Zurita]

 

Muy 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.

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....

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.

[Javi SJ Cervera]

 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.

[Pablo Zurita]

 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.

[[Vil]]

 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.

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

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

[fiero]

 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

[Ruben]

"] 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.

[Jikan]

 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:

[Pogacha]

 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.

[Jikan]

 

el 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.

   

[Pogacha]

 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.

[Javi SJ Cervera]

 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.

[zupervaca]

 

No 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.

[Jikan]

 

Los 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  :) .