Que Método De Renderizar Octrees Es Mejor...

[DraKKaR]

 Seré directo: tengo que renderizar un mapa (escenario) dividido opr octrees. La geometría es estática (tengo los vértices subidos a la tarjerta en un buffer estático) mientras que los índices a renderizar son los que cambian.

¿Cual de estos 2 métodos es mas eficiente?:

1º - Crear los índices como DINAMICOS y modificar este buffer para metiendo los índices a renderizar y hacerlo de una sola pasada. (Esto es lo que hago ahora)

- Ventajas: Tengo un solo buffer de indices, que voy modificando.
- Inconveniente: Los índices se declaran como dinámicos y se tienen que modificar de la tarjeta, lo que peude ser lento.



2º- Crear los índices como ESTATICOS. En este caso cada octree tiene un buffer de indices ESTATICO que nunca se va a tocar y lo que hace es usar ese buffer para renderizar.

- Ventajas: Subo todos los index buffers a la tarjeta como EStÁTICOS, con lo que nunca se van a modificar y se guardarán en una zona de memoria donde se pintarán rápidamente.
- Inconveniente: Hya muchos más index buffers y más pequeños que con el método 1, con lo que dibujaré pocos polígonos de una sola pasada y además habrán mas cambios de index buffers y más llamadas a la GPU que en el método 1.



¿Que opinais? Tengo implementado el método 1 y quiero saber si vale la pena intentar implementar el 2. ¿Que metodos usais vosotros?

[Trancos]

 Yo hice un quadtree.

No se mucho pero apuesto por ESTÁTICOS. Eso de tener las cosas en ram y amasarlas así como un panadero me da mal rollo.

Y de paso los ordenas de forma que se rendericen primero los nodos que están más cerca de la cámara. Con ésto y el ZBuffer consigues acelerar el asunto.

Otra cosa, ten todas las texturas pegadas unas con otras en un  mismo texturón de 2048x2048 y emplea las coordenadas UV, en vez de tener cada textura como un recurso separado en memoria. De ésta forma te ahorras llamadas para cambiar de textura al renderizar. No se hasta qué punto es bueno usar esos texturones, pero a mí me han recomendado trabajar con el máximo tamaño soportado por la tarjeta.

[Helius]

 Yo tengo implementado el segundo método que comentas.

Para reducir el número de llamadas subo el tamaño de cada nodo, es decir, el número de triángulos que dejo en cada nodo, aunque esto tiene el inconveniente de que hay más overdraw, pero con las GPU actuales y la memoria que traen yo creo que es mejor de esta manera.

De todas formas tener buffers muy grandes tampoco es bueno.

Discutí esto hace tiempo, alomejor te sirve:  http://www.stratos-ad.com/forums/index.php...=ST&f=14&t=2951

Saludos.

[DraKKaR]

 Jur, lo siento, no sabia que habia otro post tan parecido a lo que yo quería.

He implementado el segundo método pero no ha cambiado en nada la mejora de rendimiento :o

Debo tener el cuello de botella en otro sitio,. o es que estoy uasndo escenarios muy pequeños. Seguiré investigando.

Gracias.

[Miki]

Holaps

Drakkar, lo que planteas viene a ser el eterno problema, y es algo k ya se ha discutido largo y tendido
por estos parajes. Lo primero que debes tener en cuenta a la hora de implementar un sistema de particionamiento es:
- Voy a usar mapas muy chatos ? Entonces usaré quadtree
- Voy a tirar más de alturas ? Entonces usaré octree
Y por otra parte, debes tener en cuenta que para comparar 2 sistemas (como los que tú mismo has planteado) necesitas que el mapa sea suficientemente grande (unos 100.000 polys) y que posea un gran número de materiales (unos 100-200). Apartir de esas cotas es cuando te empiezas a dar cuenta de que ningún sistema es lo suficientemente rápido XD. No, es coña....

La primera técnica k expones (la que ya tenias implementada) es la óptima, pero necesitas además otros factores a tener en cuenta:

1) Que el vertex buffer no sea demasiado grande, para lo cual (en el caso del quadtree) es conveniente dividir el vertex buffer en 4, uno para cada rama primaria del árbol. Esto es así por lo mismo que no es óptimo usar texturas muy grandes, ya que a la larga causaremos un cuello de botella de 3 pares de cojones. Sería óptimo si en el transcurso de todo el juego/programa solo fueras a seleccionar (con SetStreamSource) un vertex buffer, pero eso es algo que normalmente no va a suceder. En un juego normalito, la media de stream changes per frame oscila entre 100 y 300 cambios, así como los de textura. Lo que planteaba Huevox de usar texturas de 2048x2048 es óptimo para un sistema 2D, como tmb para implementar animaciones de textura sobre un determinado material-superficie.
2) Precalcular TODO en cada nodo, de forma que construyas el index buffer ordenado por:
   a) Distancia de nodos con respecto a la cámara,
   b) Por materiales, de forma que se lance el menor número de DrawIndexedPrimitives.
       c) Además se ordenarán los materiales según sean ópacos o transparentes.

Dicha precomputación te costará alrededor de 20 mb de ram para un mapa de unos 60.000 vertices, 100.000 faces y 100 materiales. Esos 20 mb de ram que pierdes los agradeces después en fps XD

Ah!, ten en cuenta que en tiempo de render tendrás que ordenar los indices de las faces con materiales transparentes, de lejos a cerca.

Por último, y si quieres hilar fino, ten en cuenta que las primitivas MUY TOCHAS joden mucho a la GPU; así que por ejemplo, teniendo un mapa con pocos materiales, si vamos ha hacer 5 llamadas de 20.000 faces cada una, será muy estimulante en un Gf 6800 pero muy jodido para una 4MX. Además debes tener en cuenta el StartVertex, VertexCount, StartFace y FaceCount para que el procesamiento de vertices sea el adecuado (para no saturar el vertex caché de la GPU).

Salud2

[DraKKaR]

 Gracias por responder con una explicación tan larga y extensa. Según dices el método más óptimo es el que ya tenía implementado  :( . Al final resulta que todo depende de todo y al final es un tira y afloja donde tienes que quedarte con algo intermedio.