Me gustaria saber si hay alguna fórmula para saber el número de triangulos de una malla (tipo terrain mesh) apartir de un número de vertices dado. Por supuesto, el sistema es indexado de tal forma se usen los vertices justos.
El problema es k si por ejemplo tengo 9 vertices me salen 8 trigs, si tengo 12 me salen 12, y no es coherente en tanto que si tengo 25, me salen 30 y pico... :-/
No sé, alomejor soy yo k se me está yendo la pinza....XD
Salud2 y gracias

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

mmm....Haddd, no entiendo muy bien lo k refieres, más me sale una duda...
Aver...yo entre el beginScene y el endScene voy pitando objetos (al fin y al cabo listas de vertices, cada una probablemente en un VB). Para cada uno de ellos, antes de hacer un ->Render() hago su respectivo ->DoTransform() (por k puede k el objeto se hubiese movido, rotado o escalado). mmm..y la pregunta sería...¿lo estoy haciendo bien? XDD  Si primero transformara todo y luego pintara todo, lo k sucederia es k la geometria final kedaria como decidiera la última llamada a ->DoTransform() del último objeto pintado ¿no?   weno...ahí keda la duda. Es k no entendí bien a QUE tipo de calculos te referias...si puedes aclar esto mejor k mejor please... :-)

 boubou, como dice MChiz, desde el MAX5 se pueden generar lightmaps cojonudos, muy por encima de lo k pueden mostrar mapas con tecnologia quake o similar, además de poder crearlos con el tamaño k tú kieras (no estás obligado a usar 128x128 o 256x256 como sucede en muchos tipo quake).  Luego puedes exportar el archivo a X y usarlo de forma sencilla en DirectX, aunk tal y como veo, en tu caso usas oGL. Estoy deacuerdo con lo mencionado, y aparte podrías estudiar la posibilidad de implementar realtime tessellation. Consiste en tener los vertices básicos para crear planos (x ejemplo, una pared) en la k desde ahí controlas básicamente las colisiones, coordenadas de textura y poco más. Luego para teselar cada plano...pues si tienes un plano compuesto por 4 vertices (uno en cada eskina), lo más facil es dividir de forma ecuánime el plano (añadiendo nuevos vertices) e iluminandolos con respecto a la proximidad del punto de luz. Hay formas más óptimas de hacer esto, pero tmb mucho más complicadas :-P
Weno, ahí keda la cosa...

 Uno de las dudas más frecuentes en D3D sería esa ¿CUANTOS VB ES ACONSEJABLE USAR, y sobretodo, CUANTOS REFERIDOS AL MISMO OBJETO/ESCENARIO?
Algunos artículos de nVidia hablan sobre esto. Si bien es verdad apenas se puede comparar el funcionamiento de un HDD con como trabaja la memoria en la t.gráfica, tmb es verdad k hay una lógica k SIEMPRE impera, y es la de DIVIDE Y VENCERAS. Y dicho esto ¿CUANDO MERECE LA PENA USAR VARIOS VB PARA UNA MISMA PANTALLA? Sobre esto hice varias pruebas con mapas del Q3. Resulta k al hacer uso del BSP (de las LEAFS más bien) te das cuenta de que raramente dibujas de forma secuencial o lineal, sino k realmente vas pegando saltos por el VB en busca de los vertices deseados. Cuando esto es así y la pantalla tiene MUCHOS vertices (unos 30.000 por ejemplo), lo mejor es separar los LEAFS en grupos (y con ellos separamos tmb en grupos de polys), de forma k si tenemos 10.000 leafs, haciendo grupos de 500 se nos kedan en 20 grupos de 500, osea, VB's de tantos vertices como polys * numVertsInPoly haya en cada LEAF. De esta forma veremos como el rendimiento se extrema más, kiero decir, cuando iba lento ahora irá más lento XD, pero cuando iba rápido irá más rápido, o lo k es lo mismo, si salimos de la pantalla y miramos a TODO, veremos k el frame rate es más lento k usando solo un VB, pero cuando nos metemos y respetamos la estructura del PVS vemos que normalmente va más rápido, con aceleraciones/decelaraciones causadas por el salto de VB a VB (normal).
Si vamos a dibujar de forma más secuencial, con listas de triangulos o strips, lo mejor seria usar solo un VB, pero claro, tmb depende un poco del tamaño del nivel. Si usamos portal rendering con exteriores gigantescos tipo Unreal, creo k lo mejor seria usar un VB x cada GRAN celda. Aveces hay k pensar en la VideoMem como si se tratara de la FAT del disco. Realmente no tiene mucho k ver, pero si "separamos" en la medida de lo posible lo k creemos k es conveniente separar, veremos un aumento de rendimiento con un 50% de posibilidad.  Sobre vertex buffer dinámicos. Realmente no es conveniente usarlos (lo dice propiamente M$ en la FAQ), pero en juegos como BLADE, en la que la teselación se efectua en tiempo real, es preciso hacer uso de este tipo de VB. Lo que está claro es k a la larga, todo lo precompilado es más rápido...
Espero haberme expresado bien. Taleg!

 jejeje, lo sé seryu, por eso mismo ahora soy Miki Browlee.
Lo de Doom Carmak era xq lo tenia de hace un año de la otra cuenta XDD
Me la he cambiando finalmente... Weno, ya lo sabeis todos!!!