Pues la verdad, todo depende de lo k kieras hacer.
Si no vas a hacer un Doom3 cualkiera de esos te sirve :-P
Yo de ahí solo he probado Irrlicht y Ogree. Ogree cuesta mucho de "poner en funcionamiento", pero luego a la larga creo k será mejor k irrlicht (estoy hablando con bastante desconocimiento). Pero ciertamente Irrlicht es una muy buena alternativa. Creo k te he liado más, pero vamos, tú decides.
Si lo k vas a hacer es realmente sencillo, dejate de historias y metete con Blitz o alguno de estos. Y sino esperate un par de meses a la salida de RET FX ;-)

Como bien decía mi colega, todo depende, depende de muchos factores.
En primer lugar ya te aviso de que no vas a poder meter más de 65.535 vertices en un VB en GPU (las tarjetas CARAS soportan más). Así k en tu caso lo mejor es, usando un octree, tirar de 8 VB, uno para cada nodo maestro del octree (se crean 8 nodos en la primera subdivisión del nodo madre). Y la otra cosa k tienes k hacer es lo k´tú ya has dixo, un array de punteros a IB en cada nodo del octree, donde el array es tan grande como número de materiales (texturas) tienes en el escenario. Luego con dos FOR's es fácil abarcar el problema:

PARA CADA material(x) HACER
      SetMaterial(x)
      SetTexture(x)
      PARA CADA nodo_visto_en_X_material(x, y) HACER
           // Donde 'y' es el nodo en cuestión y 'x' es el indexbuffer del array de buffers del nodo
           SetIndices(x)
   DrawPrimitive()
      ACABA
ACABA

De esta forma no tienes k ir modificando un IB dinámico (cosa k tardaría más k hacer muchos SetIndices() ). Nosotros lo hacemos así en RET FX y da un resultado muy bueno.
Salu2

Nada, era solo para saber si hay diferencia entre estos 2 parámetros pasados por referencia:

int MiFuncion( const cMiTipo &dato )
int MiFuncion( cMiTipo const &dato )

Es k lo he visto ya varias veces y estoy intrigado. En las ayudas oficiales no he visto el caso XD

Salud2

Bien Helius, es el cuento de nunca acabar.
Yo solo te voy a dar un par de consejos y un par de pistas:
- A DX no le mola k uses vertex buffers dinámicos
- A DX no le mola k hagas muchas DrawPrimitives()
- A DX no le mola k hagas muchas SetStreamResource()  --->para asociar un vertex buffer
- A DX no le mola k hagas muchas SetTexture()

¿joder, entonces k coño le mola a DX?

Hay algo k no le fastidia mucho a DX, y esas son las llamadas a SetIndices()

Ya para terminar, puedes alojar un index buffer en GPU o en CPU xq la diferencia de rendimiento tan solo
puede suponer unas 2-3 fps.

Bien, con esto ya te lo he dixo todo. Espero haberte iluminado :-P

En serio, no pienses cosas raras xq esas restricciones son lo único k te ayudarán en tu viaje por D3D XD

Salu2

 Sí Kriller, eso fue lo primero que pensé: tener un array de indexbuffer en cada nodo, en el k cada set del array es un indexbuffer referente a las faces de un material determinado. Pero si te fijas estoy = de jodido, ya que es muy posible que se vean más de 20 nodos a la vez, y eso significa mucho swap de material (osea, textura) =mente. Sería muy óptimo si la ramificación del quadtree fuese pekeña (una sola subdivisión por ejemplo), pero para el caso necesito algo más potente. Claro, lo que tmp puedo hacer es crear indexbuffers en tiempo de ejecución "recolectando" todas las faces de un material determinado de cada uno de los nodos, sería algo bastante costoso....
Bueno, espero más sugerencias. Gracias

 Haber como lo digo...
Tengo un escenario abierto (una ciudad) de unos 150.000 polys. Le aplico un sistema de particionado, en tal caso me decanto por el Quadtree. El factor de ramificación es de 3000 faces por nodo más o menos. Bien, antes del render me hago una colección de los nodos que veo, y finalmente pinto. Pero si os fijais, esto no es muy optimo, ya que la ciudad en cuestión alberga unos 100 materiales (100 texturas por tanto). Lo que realmente me interesa es dibujar a "cachos" según un orden de material, y porsupuesto aprovechando el quadtree. Osea, si estoy viendo 15 nodos en un momento dado, cojo los polys del material 1 de esos 15 nodos, y los pinto del tirón, luego los del material 2, y también.....y así hasta que no me keden faces visualizadas. ¿Alguién sabe como se pude hacer esto de una forma OPTIMA?

Salud!

 Simplemente GRACIAS

 Para explicarlo bien basta con poner el ejemplo del cubo. Tiene 8 vertices BASE ( k indexados son 36) y 12 trigs (36/3 efectiviwonder :-P). Yo lo quiero hallar es el número de vértices BASE.  

Pues eso, aver si alguien sabe como se puede hayar el número de vertices apartir de un número de de trigs dado. Vertices BASE, es decir, no repetidos (en cuyo caso está claro k sería tan simple como multiplicar por 3). El modo de triangulos sería un TRIANGLELIST.

Gracias de antemano...

 Pues eso, k aver si alguien sabe como demonos sacar el tamaño (en bytes) de la caché destinada al procesamiento de vertices de la t.gráfica con Diriect3D 9.
Gracias de antemano. Salu2

 Pues tenía algo por ahí escrito...aver si me acuerdo y te lo paso. Son unas 10 páginas de teoria sobre el tema
Salu2

 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!

 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

 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

mmm...creo k seria ((X - 1) * (Z - 1)) * 2