Diseño sistema materiales

[TrOnTxU]

He estado leyendo otra vez tu descripción de pipeline, y me parece que lo habia interpretado mal  ^_^'

Más que las "Layers" que utilizo yo parece pipelines de renderizado tipo Horde3D, algo asi:

Código [Seleccionar] Expand

<!-- Forward Shading Pipeline -->
<Pipeline>
<CommandQueue>
<Stage id="Geometry" link="pipelines/globalSettings.material.xml">
<ClearTarget depthBuf="true" colBuf0="true" />
<DrawGeometry context="AMBIENT" class="~Translucent" />
<DoForwardLightLoop class="~Translucent" />
<DrawGeometry context="TRANSLUCENT" class="Translucent" order="BACK_TO_FRONT" />
</Stage>
<Stage id="Overlays">
<DrawOverlays context="OVERLAY" />
</Stage>
</CommandQueue>
</Pipeline>

¿Es algo parecido a esto lo que te refieres con pipeline?

[XÑA]

Utilizas Forward Rendering o Deferred?

[KneDa]

Ummm, muy interesante lo de compilar a binario con posible compresión en fase de producción. En algún proyecto casero que tengo por ahí pendiente en C++ tenía en mente usar Json como formato intermedio y luego hacer algo parecido a lo que comentas, aunque no me he puesto a mirar ninguna librería C++ para tratar Json, recuerdo haber visto fugazmente alguna por google.code ... aunque no la había probado, alguna recomendación?

Con respecto a lo que comentas de 3, es lo que comentas y eso mismo hago yo en la fase de preprocesado. En cuanto a lo de la posición normalizada, simplemente fíjate en void vertexAttribPointer(GLuint indx, GLint size, GLenum type, GLboolean normalized, GLsizei stride, GLintptr offset);  :)

Lo de los uniforms, va bastante bien, te da bastante flexibilidad y crear nuevos materiales es cuestión de pocos minutos una vez tienes los shaders.

Ummm, en cuanto a los pipelines, aprovecho la flexibilidad del lenguaje Js, en donde muchas veces es casi mejor evitar abstracciones y hardcodear las cosas, ya que es muy rápido, te pongo un ejemplo.

   // 7.-SSAO (FXAA)
   this.sceneManager.addPipeline("ssao_fxaa",
      function() {
         this.quadSSAO=manager.createQuadModel(["commonSSAO"],[0.0,0.0,0.0],[1.0,1.0,1.0]);   
         this.quadFXAA=manager.createQuadModel(["commonFXAA"],[0.0,0.0,0.0],[1.0,1.0,1.0]);   
   },
      function() {
         // 1º Pass (RTT Color buffer)
         common.rtt_0.rtt(function() { manager.render(0); });
         // 2º Pass (RTT Depth buffer)
         common.rtt_1.rtt(function() { manager.render(1); });

         // 3º Pass (RTT commonSSAO Effect)
         var refObj=this;
         common.rtt_2.rtt(function() {
            refObj.quadSSAO.parts

• .materials[0].bgl_RenderedTexture="rtt_0";
              refObj.quadSSAO.parts
• .materials[0].bgl_DepthTexture="rtt_1";
              refObj.quadSSAO.parts
• .materials[0].bgl_RenderedTextureWidth=gl.viewportWidth;
              refObj.quadSSAO.parts
• .materials[0].bgl_RenderedTextureWidth=gl.viewportHeight;
              manager.renderQuad(refObj.quadSSAO,numCameraQuad);
           });            
  
           // 4º Pass (commonFXAA Effect)
           this.quadFXAA.parts
• .materials[0].uRTT="rtt_2";
           manager.renderQuad(this.quadFXAA,numCameraQuad);
     });
  
  Basicamente, tienes una función que inicializa los datos necesarios del pipeline y una función de render... En el pipeline se utiliza la funcionalidad del engine, igual no es muy muy elegante, pero en este caso va bien y se trabaja rápido. De todas formas, no descarto en un futuro crear una pequeña tool basada en nodos para agilizar el desarrollo de pipelines, pero otra tool equivale a más código a mantener... de momento esto va bien ;D
  
  Si, basicamente es parecido al formato que has puesto de Horde3D pero hardcodeado... ;)
  
  En cuanto a la fase final de optimizar todavía no me he parado mucho, pero si, es más o menos tal y como tu comentas.
  
  
  
  

[TrOnTxU]

Hola, he estado my liado con prespuestos y otras historias y no habia podido contestar desde hace dos semanas ... soy un "malqueda" :S

A la pregunta de XÑA: de momento es todo forward. Para dispositivos con fixed pipeline se utiliza solo una "configuración de renderizado", para programmable pipeline se puede utilizar single-pass o multi-pass ligthing.

La idea es que los efectos, sombras, etc. hasta ahora se ponian "a mano" en C++ en la "funcion de render", para cada proyecto en concreto. Y el sistema de "layers" te permitia seleccionar "objetos" a los que aplicar unos u otros efectos (cast/project shadows, real-time reflections, etc).

Pero visto, lo visto, esto es un peñazo insalvable, a no ser que como KneDa tengas la ventaja de tener la "funcion de render" en un lenguaje de script dinámico.


Al final estoy pasando todo a "data-drive" en ficheros de configuración LSON, con lo que para crear los RT, dibujar quads para post-screen, etc, se hace todo leyendo el archivo de configuracion.
Le voy a hacer caso a KneDa y voy a separar los pasos de los surface shaders, se renderizarán en el orden que dicte el archivo de configuración.
El deferred-shading por ejemplo, tendria que poder configurarlo desde el LSON también, así como HDR, diferentes tipos de shadows, etc.

Ya iré viendo, porque ahora hay curro, y de momento el sistema de materiales se va a quedar así, a no ser que ocurra algo de "fuerza mayor", y tenga que ponerme a "actulizarlo todo".


En cuanto a la pregunta sobre Json en c++ de KneDa: yo utilizo un "parser propio" bastante sencillito. Principalmente porque la syntaxis que utilizo para LSON no es exactamente Json. Más bien esta basado en esto: http://bitsquid.blogspot.com.es/2009/10/simplified-json-notation.html

Si que estuve buscando una vez, y encontre algo interesante: http://stackoverflow.com/questions/245973/whats-the-best-c-json-parser y un pagina con una lista de parsers, que no he podido volver a encontrar :(


Y en cuanto a lo de normalizar el atributo de la posicion del vertice lo decia porque yo marco como normalizados la normal (valga la redundancia) y los valores de color, por ejemplo, porque siempre van de 0 a 1 (o al menos deberian). En cambio la posicion del vertice puede ser cualquier numero, positivo, o negativo, y no deberia de estar normalizada. Por tanto yo en normalized para la posicvion pongo false, eso es lo que me habia extrañado.


Bueno, ya pondré como funciona esto del "data-driving pipeline" y como lo acabo de integrar con los surface shaders que tengo ahora ... cuando le pueda volver a dedicar unos dias para acabarlo.

Un saludo.