Render Lists.

[Oanime]

                                Buenas gente,

desde hace ya algunos meses (desde q empece mi motor), he estado usando esta forma para renderizar mis modelos.

HRESULT CModel::Render()
{
       Codigo quitado...
       .
       .
       .

       m_pMesh->DrawSubset(0);      

   return S_OK;
}

como se puede ver, cada modelo se encarga de renderizarse y de mandar los triangulos a la tarjeta grafica atraves de un D3DXMESH.

Ahora que he empezado a rediseñar ciertos aspectos del motor, he creado unas clases q encapsulan carasteristicas de los objetos del engine, ya sea un ejemplo la CRenderable de la que heredan todos los objetos que puedan ser renderizados. Los problemas han llegado al empezar a incluir un manager de fonts y soporte de modelos md2 al motor, ya que este tipo de objetos estan basados en lista de triangulos, (bueno para los fonts podrian usarse strips sin problemas), asi que estuve pensando en hacer varias subclases q heredaran de CRenderable llamadas CMesh (que incluye un D3DXMESH q renderiza mallas indexadas), un CTriangleList, que renderiza listas de triangulos, etc... pero es un palo ya que necesitaria crear nuevas subclases para cada tipo de de dibujado de triangulo (strips, etc...). Asi, he decidio basar todo el motor en listas de triangulos y añadir un renderer y un puntero a una lista de triangulos a este, asi, los objetos al llamar a su render no mandarian triangulos a la tarjeta, sino que los mandarian a la lista de triangulos del renderer y luego la escena se crearia desde aqui. De esta forma se podria optimizar (o eso creo yo) el dibujado de la escena ya que los triangulos se podrian ordenar por textura, estados de render, etc.... Bueno que os parece? se suele hacer asi?. Algun tutorial sobre esto?

Gracias.
HexDump.

Nota: vaya tocho mensaje :sonriendo:.                                

[BeRSeRKeR]

                                Sin duda, si lo haces así (recolectar todas las faces, ordenarlas por shader o lo que sea y entonces ir renderizandolas), te ahorrarías unos cuantos vertex & index buffers y los consiguientes bloqueos/desbloqueos y además el tener que cambiar más de la cuenta los render y texture stage states necesarios.

Lo que pasa es que no sólo tendrías que separar las faces por shader sino también por transformaciones ya que dentro de un mismo grupo de faces que compartan el mismo shader pueden haber unas que tengan una transformación y otras otra transformación distinta...ejemplo: dos cubos idénticos (con el mismo shader) pero uno tiene una rotación en X y el otro en Z y encima una matriz de escalado (por poner un simple ejemplo) :sonriendo:

Saludos

_________________
Visita:
La web de http://www.planetquake.com/digitalys">DiGiTALYS
La web del motor http://run.to/illusion3d">Illusion3D

[ Este Mensaje fue editado por: BeRSeRKeR el 2002-08-28 23:56 ]                                

[Oanime]

                                ummm, Berseker, no me pegues, pero q coño es un shader, al menos en la acepcion q tu lo usas, te refieres a textura?.

Otra cosa, seguramente sera por mi ignorancia, pero no entiendo bien la parte del final cuanto te refieres a ordenar por transformaciones, si yo tengo 2 cubos pues tiro a la lista los triangulos de los 2 y ya esta no?, no entiendo el problema, ya que yo ya mando alli los triangulso transformados. NO ME PEGUES EH? Q SEGURO Q HE DICHO ALGUNA BARBARIDAD :sonriendo:.

Gracias por contestar.
HexDump.


Nota: como te dije, tus tuts roooolllz :sonriendo:.


                               

[BeRSeRKeR]

                                Con shader me refiero a un vertex shader, a un shader tipo quake3 o a una simple textura. En el caso de los shaders de quake3 se trata de un script en el que se especifican tanto la/las texturas (pueden haber varias capas) como los render & texture stage states y muchas cosas más.

Con respecto a las transformaciones...imagina los dos cubos. Uno está en una posición, y el otro en otra y además las rotaciones son diferentes. Ahora resulta que tu renderer va recolectando las faces de los objetos visibles entre ellos los dos cubos. Entonces al ordenar por shader por ejemplo, tienes que, al tener los dos cubos el mismo shader, pues te va a quedar un grupo de faces entre las cuales están las de los dos cubos. Ahora resulta que renderizas esas faces (Draw?Primitive)...¿qué matriz de mundo pones a la hora de renderizar esas faces?...¿la matriz de mundo del cubo uno, la del dos?...evidentemente tendrás que poner a cada grupo de faces su matriz de mundo. A eso es a lo que me refería con "ordenar" por transformación.
                               

[Oanime]

                                Berseker unas cositas mas.

Hablando en el IRC y discutiendo unas cosas hemos llegado a unas conclusiones. Mira ,tengo pensado hacer el renderer asi: Cada modelo mantendra una lista de vertices en memoria convencional (no VBs) y una lista de indices tambien en memoria convencional (no IBs). El caso es que cuando se tenga se llame al render de cada objeto se pase el puntero del objeto a la cola del renderer. En el objeto tambien se tiene el sistema q usa para renderizar los triangulos (strips, etc...) y los states. De esta forma el renderer cuando tenga q crear la escena, tomara los datos necesrios de cada modelo que hay en la lista, como numero de vertices, etc... y renderizara. Me mosquea que haya oido por ahi que mucha gente tiene un lista de triangulos en el renderer y no, referencias a los objetos, ya que de la forma que yo digo te ahorras copiar datos a la cola y necesitas menos memoria.

Nota: Para renderizar los distintos tipos desde memoria que tal DrawPrimitiveUP?.

No me contestes mu tecnicamente que soy palurdin :riendo:.

Gracias.
HexDump.                                

[BeRSeRKeR]

                                Pues está bien. De esa forma no te complicas con el tema de las transformaciones ya que mandas al renderer el objeto y éste activará su matriz de transformación, los render & texture stage states necesarios y renderizará, ¿no?

Seguramente es una buena forma para empezar. Después ya se te irán ocurriendo posibles mejoras.

Saludos.

PD: con respecto al DrawIndexedPrimitiveUP...pues resulta que internamente te va a crear un vertex & index buffer así que supongo que mejor hacerlo tú mismo y pintas con DrawIndexedPrimitive...

_________________
Visita:
La web de http://www.planetquake.com/digitalys">DiGiTALYS
La web del motor http://run.to/illusion3d">Illusion3D

[ Este Mensaje fue editado por: BeRSeRKeR el 2002-08-29 23:16 ]                                

[Oanime]

                                Las ostia tio, que rapido contestas :sonriendo:, sorry por darte tanto la paliza. Por cierto, lo del drawprimitiveUp, ya me pensaba yo algo de eso. Lo mejor que sera crearse un vertex buffer fijo de un tamaño optimo para hacer batching y vas copiando los vertices e indices de cada grupo, colocas states y texturas y renderizas no?.


Again, gracias.
HexDump.                                

[BeRSeRKeR]

                                Exacto :sonriendo:

Sin duda esa sería lo solución ideal creo yo...

Saludos
                               

[Drácula]

                                Yo creo que lo mejor es ordenar los objetos por texturas y RenderStates y lanzarlos a la tarjeta con sus respectivos VB e IB creados.                                

[BeRSeRKeR]

                                Si, el problema que comentabamos es que un objeto puede contener más de un shader...por ejemplo un personaje con un visor que tiene un shader con envmap y el resto con un shader normal (una simple textura)...De todas formas es muy raro que el shader de un objeto coincida con el de algún otro por lo que en ese caso concreto no tendría demasiado beneficio lo de mandar al renderer los triángulos de todo objeto visible y ordenar por shader...

Saludos
                               

[Oanime]

                                Yo berseker creo q no es tan raro. Varios objetos distintos pueden usar la misma textura y los mismos render states, por ejemplo para simular cualquier tipo de material sobre ellos (metal de espadas, etc...). Una cosa que no me queda del todo claro son los render states, vosotros que pasa que ya exportais junto con el objeto la informacion de los render states que va a usar cada subset? (es decir cada parte que tiene una textura distinta, etc...?) o lo teneis "hard coded" en el objeto?.

Saludos.
HexDump.                                

[BeRSeRKeR]

                                Con respecto a los render & texture stage states, te recomiendo que le eches un vistazo a los ftp://ftp.idsoftware.com/idstuff/quake3/tools/Q3Ashader_manual.doc">shaders de quake3. La verdad es, una vez ves como funcionan, se convierten en algo imprescindible. Dan muchas posibilidades a la hora de crear muchos efectos.

La verdad, yo no puedo hablar más que maravillas del sistema de shaders de quake3... y como digo ofrecen muchas posibilidades por lo que no te costará nada encontrarle más utilidades...por ejemplo asignar un sonido a la superfice que tenga asociada un shader determinado... :sonriendo:

Saludos
                               

[Degiik]

                                "shader normal", "vertex shader", "textura normal", excepto el ultimo, los demas no los entiendo. Alguien puede explicarme, en que consisten brevemente.

Gracias y perdonar si la pregunta es muy simple pero estoy empezando.                                

[BeRSeRKeR]

                                Con los shaders que he mencionado arriba me refiero a los de quake3 que son scripts que definen las carácterísticas de una superfice (textura que se le aplicará, cuantas pasadas se darán, render & texture stage states necesarios para el render, etc)

Después tenemos los vertex & pixel shader (o vertex & fragment programs en la terminología de OpenGL) que son pequeños programas que se desarrollan en la GPU (si se soporta).

Con los vertex shaders controlas la transformación de los vértices. Con ellos puedes hacer cualquier cosa con los vértices (cambiar su posicón, cambiar el color, calcular la iluminación, especificar y/o modificar las coordenadas de textura, etc)

Con los pixel shaders controlas la fase de rasterización (aunque el blending por ejemplo no se lleva a cabo en ellos). Digamos que con ellos defines la apariencia final de la imagen a nivel de pixel. Con los pixel shaders puedes realizar efectos como per-pixel lighting & bump mapping. Decir que al pixel shader se le pasan algunos datos desde el vertex shader como por ejemplo, la dirección de la luz, el half-angle vector, etc. Esto creo que se eliminará en la version 2.0 de los vertex & pixel shaders y todo el tema de la configuración de la iluminación y el cálculo se realizarán integramente en el pixel shader pero es algo que no puedo confirmar.

A ver si te he aclarado algo las cosas :sonriendo:

Saludos.