Problemas Con Mapas Q3 En D3d

[Miki]

Por favor, si alguien intentó (con éxito) pasar los triangle fans de los mapas del Q3 a triangle strips (y usando indexación) a D3D, k diga algo...
Gracias de antemano

[Grugnorr]

 OGRE

[BeRSeRKeR]

 Yo nunca he visto triangle fans en los mapas de quake3. Son todo primitivas indexadas. Otra cosa es que después para temas de optimización se creen triangle fans/strips pero la geometría de los BSP de quake3 está especificada como primitivas indexadas.

Saludos.

PD: con "primitivas indexadas" me refiero a lista de triángulos con indexación.

[vicho]

 yo con la weba que e tenido problemas aunque en OGL es con los lightmaps, desde windows no me los esta cargando bien, nose porque

[Astharoth]

 Esto... eso de que un .bsp de Q3 no lleva triangle fans....

De planetISO (el primer tuto que he pillado a mano con lo de los mapas,etc,etc)

struct tBSPPoli
{
   int texturaID;           // El indice en el array de texturas
   int efecto;              // El indice para los efectos (-1 significa desactivado)
   int tipo;                // 1=poligono, 2=superficie curva, 3=malla, 4=billboard
   int startVertIndex;      // El primer inidice para el primer vertice del poligono
   int numDeVerts;          // Numero de vertices del poli
   int meshVertIndex;       // El inidice en el primer vertice de malla
   int numMeshVerts;        // El numero de vertices en la malla
   int lightmapID;          // El indice de textura para el lightmap
   int lMapCorner[2];       // La esquina del lightmap en la imagen
   int lMapSize[2];         // El tamaño de la sección del lightmap
   VECTOR3BSP lMapPos;      // El punto de origen 3D del lightmap.
   VECTOR3BSP lMapVecs[2];  // Coordenadas de los vectores unitarios s y t
   VECTOR3BSP vNormal;      // La normal del polígono
   int size[2];             // Los tamaños de la superficie curva
};  
Esta estructura almacena todos los datos del polígono en cuestión. Lo más importante son los índices a los vértices que usa y la textura. Pero ya veremos cómo usar esto para renderizar. Sólo queda aclarar que si el tipo es igual a '1' se tratará de un polígono normal y se podrá renderizar como un triangle fan. El resto de tipos son:
'2': Indica que es una superficie Bezier.
'3': Indica que es una malla (funciona como el '1').
'4': Indica que es un billboard.

Tutorial completo Aqui

Si, lleva triangle fans.. de hecho si no los cargas y representas te pierdes "parte" de la geometria.

Un Saludo, Astharoth.

[BeRSeRKeR]

 Es extraño porque a mi los mapas de quake3 se me visualizan correctamente utilizando siempre lista de triángulos indexada, y eso que he probado muchísimos.

Tal vez te de dos opciones. Una, renderizar con triangle fans (sin indexar) y otra, utilizar los índices de ese polígono y renderizar con lista de triángulos indexada.

Saludos.

[Astharoth]

 Hola Berseker.

Yo pensaba lo mismo.

Resulta que la que tu nombras como "indexadas" contiene la geometria general del nivel (muros, suelos,etc,etc).
La de "patches", pues todo lo redondillo.. (columnas, algunos muros,etc)
Y la de "triangle fans" contiene objetos añadidos al mapa (el calavero que esta tirado en un sitio, la estatua tal,etc,etc).
Si mal no recuerdo, que de esto hace ya un tiempo.

Vamos, Por eso a priori ves el nivel "bien" :) .. aunque falten cosas :)

Un Saludo, Astharoth.

[BeRSeRKeR]

 Hola Astharoth.

En las especificaciones en las que yo me basé para crear el visualizador de niveles de quake3 (la primera versión que hice fue hace unos 3 años) no se hablaba de triangle fans (la verdad, ahora me entero que se pueden utilizar triangle fans :D).

Estos son los tipos de primitivas que yo tenía:

Código [Seleccionar] Expand

#define FACE_PLANAR   1
#define FACE_PATCH   2
#define FACE_TRIMESH  3
#define FACE_BILLBOARD 4

Precisamente el tipo FACE_TRIMESH es el que representa a los objetos que añaden detalles al nivel. Como tú dices son las calaveras, estatuas, teletransportadores, etc.

Pero como ya he dicho, toda esta geometría yo la trato como lista de triángulos indexada y se visualiza perfectamente, sin ningún problema. Vamos que el nivel en mi visualizador se ve exactamente igual que en quake3...

Así que, si realmente esos polígonos están definidos como triangle fans, deben ser sin indexar, es decir, los índices de ese polígono no se utilizan (esto es tan sólo una suposición). Pero si quieres seguir utilizando lista de triangulos indexada, sólo tienes que pillar los índices del polígono y tratarla como el otro tipo de polígonos (el que yo definí como FACE_PLANAR) que es justamente lo que yo hacía.

Saludos.

[Miki]

 Bien, llegado a este punto habria k saber diferenciar entre un triangle normal, triangle strip y triangle fan...
Los 2 primeros son =, la diferencia es k en los strips lo k se hace es dibujar el 2º trig a raiz del primero, el 3º a aprovechando el 2º, el 4º aprocechando el 3º y así sucesivamente; de ahí k usar strips sea más óptimo k usar listas de triangulos normales (xq en tal caso, no se "concatenan"). Ahora bien, lo k dice berserker es totalmente cierto, yo tmb he conseguido usar triangle list indexado, y lo cierto es k conseguí un rendimiento peor cuando dubujaba muchas faces, para lo cual era más óptimo usar fans, tal y como se detalla en el tuto de planet iso. La draw primitive para un poly fan seria algomo como:
m_pDevice->DrawPrimitive( D3DPT_TRIANGLEFAN, m_pPolygon.uiStartVertexInPoly,  m_pPolygon.uiNumVerticesInPoly-2 );
Eso te dibuja tantas faces como número de vertices en el polígono - 2. Realmente todo esto viene apartir de unas pruebas k hize en oGL, con un tuto de GameTutorials. Me sorprendió enormemente que oGL dibujaba los fans y las listas de triangulos normales mucho más rápido k DX9, tal vez un 100% más rápido. Por poner un ejemplo, en un mapa del q3 bastante tocho, visualizando TODO en oGL rulaba a 34 fps, en mi engine a 9 fps, y ahí no hay ni trampa ni cartón, xq en ambos casos se dibujaban todos los polys. Luego me dí cuenta que realmente los strips merece la pena usarlos, ya que ahora estoy usando un terrain mesh generator de 130.000 faces con 3 texturas, y me rula a una media de 50 fps a 1024x768x16 en un P3 600, 256 ram y gforce2mx (osea, k la diferencia de rendimiento es BRUTAL). Tmb es verdad que para los mapas del q3 habria k tener en cuenta el tema de dibujar los polys por grupos de textura y tal y tal, pero en cualkier caso, el rendimiento que he podido obtener es PENOSO (y sí, estoy usando el PVS). Es k da pena que con dibujar 1.000 polys x frame ya vaya lento :__( cuando en oGL empieza a ir lento apartir de los 20.000 (al menos en mi mákina, la citada anteriormente). No sé, haber si alguien sabe algo más del tema. Por lo k pude ver en un demo k me pasó berserker hará cosa de un año, el rendimiento que sacaba era muy parecido al mio :-P, osea, un merdé. La verdad es k a uno le entran ganas de pasarse a oGL. Por cierto "jonathan", no sé si te acordarás de mi, estube haciendo un trabajillo para Illusion3D y de vez en cuando entraba en el canal del IRC para darte la paliza con preguntitas sobre DX8. Te sorprenderia saber lo k he llegado a aprender un 1 año XDD

[BeRSeRKeR]

 Miki, ten en cuenta que los drivers de nVidia/ATI/etc están superoptimizados para quake3. Dudo que nuestros programas puedan alcanzar ese nivel sin que nVidia/ATI/etc meta mano en sus drivers para realizar optimizaciones específicas para nuestras cosillas :D

Saludos.

[Miki]

 Pues sí Berserker, ahí te doy toda la razón. Supongo que ID da y recibe mucho soporte por parte de las empresas que desarrollan hard 3D. De todas formas, ese tutorial de TutorialGames usa un oGL standard, nisikiera hace uso de vertex buffers, tira los polys a pelo. Así k oGL rulez XD Otra de las cosas que se me olvidó comentar (x si alguien está implementando el sistema) es k además de dibujar los polys por grupos de textura, es conveniente ordenar los LEAFS vistos por orden de distancia, de tal forma se dibuje de front to back. Esto puede suponer una ganancia en fps del 50%
Weno, gracias a todos por contestar =mente
Salud2

[BeRSeRKeR]

 Hay un detalle muy importante que se te ha pasado por alto. El tutorial de gametutorials NO utiliza los shaders de quake3. La demo que yo te pasé realizaba un uso intensivo de ellos (te diría que excepto la niebla volumétrica y el skybox, los demás efectos estaban implementados) y eso hace descender los FPS bastante. La razón principal es que en esa época no existían los vertex shaders y tuve que hacerlo con la fixed pipeline y una de las consecuencias es tener que bloquear el vertex buffer en cada frame con el consecuente descenso de rendimiento. Además, los shaders requieren bastantes cálculos para todos los vértices de la geometría por lo que el descenso de rendimiento es aún mayor.

¡Con esto no estoy diciendo que el motor que hicimos ProD y yo no pudiera optimizarse más (por supuesto que se podía optimizar más)!. Sólamente digo que las cosas hay que compararlas al mismo nivel y en este caso nuestro motor sale mal parado ya que las caracterísiticas (y por lo tanto el consumo de CPU/GPU) de nuestro motor son muy superiores a las del visor de gametutorials que por otro lado es bastante simple.

De todas formas es un tema este de los BSP que ya no me interesa demasiado ya que estoy metido en otros asuntos. La verdad, estoy cansado de utilizar los formatos de otros :D. Por eso estoy metido en el desarrollo de herramientas propias y el desarrollo de un motor orientado 100% al uso de vertex & pixel shaders.

Saludos.

[Miki]

 OK Berserker, capto el mensaje. La verdad es que yo tmp kiero usar el formato de mapas del q3 XD. Lo k pasa k para hacer pruebas de indoors es xungo hacer las pantallas con el MAX, era por eso k me intersaba lo del q3, por akello del qRadiant. Yo por el contrario, todabia no he implementado nada  de shaders en mi engine (pero ya lo estoy orientando).  Lo dejaré para dentro de 2 o 3 meses, sobretodo xq con mi 2mx no puedo hacer gran cosa XDDDD
Salud2!