OpenGL: Vertex Arrays, Vertex Buffers e indices

[tamat]

Estoy  intentando optimizar mi render de meshes así que he decidido usar algun tipo de buffer con todo indexado.

Ahora mismo mi clase mesh tiene un array con todos los vertices, otro con todas las normales y luego uno que dice cada cara qué vertices tiene y qué normales.

He probado usando Vertex Arrays pero he descubierto que los vertex arrays obligan a que haya el mismo numero de vertices que de normales (corregidme si me equivoco), lo que significa que tengo que replicar datos, lo que para mi es una chapuza.

A mi me gustaría pasarle a opengl el array de vertices, de normales y despues uno en el que estan los indices para que los vaya sacando de los arrays. Es eso posible?

He estado mirando los VBOs pero por lo que veo la unica diferencia es que en lugar de enviar los arrays en cada iteración se suben y se dejan en memoria, con lo cual te ahorras esa transferencia cada vez. Tienen alguna mejora adicional?

¿Hay más alternativas que esten suficientemente extendidas?

Gracias.

[ethernet]

Puedes renderizar geometría indexada con una VBO. Hay 3 tipos de VBO, los estáticos (subes una vez y renderizas ), dinámicos (subes vaias veces y por cada subida rendeizas varias veces) y stream (subes cada vez lo que renderizas, lo mismo que los vertexarray de siempre).

creo que no hay alternativas, salvo las disply list de toda la vida que imagino que internamente generarán un vbo estático.


Hay bastantes papers y tutos del uso de vbo, por ejemplo:

http://developer.nvidia.com/attach/6427

[ethernet]

De cualquier forma por lo que veo ultimamente en la lista de gamedev es que la optimización de mallas va por el camino de evitar fallos de caché, esto es, ordenar los vértices para que estén seguidos.

[tamat]

pero mi problema de tener que replicar las normales o las coordenadas de textura no tiene solucion entonces, no? estoy obligado a tener indexados el mismo numero de cada cosa

[MA]Mestre]

He probado usando Vertex Arrays pero he descubierto que los vertex arrays obligan a que haya el mismo numero de vertices que de normales

Una normal siempre se se define por vértice, no por polígono. Bien lo hagas tu, te lo haga el driver, o el espiritu santo.

[Marci]

Yo me encontre con el mismo problema. Por ejemplo para un cubo formado por 12 triangulos tengo 8 vertices, 4 vertices de textura y 6 normales. Lo ideal seria subir estos tres arrays a la tarjeta y trabajar con ellos mediante los indices (sería muuuuuy comodo). Al final no encontre la forma y lo que hago es crear un array combinando los vertices, textura y normales y eliminar los repetidos de esta forma ya puedo trabajar con el vertex buffer y los indices. Para el caso del cubo se me queda en un array de 24 vertices.

[tamat]

MaMestre, el problema es que si tengo 100 vertices y 2 normales yo no quiero tener que usar un normalArray de 100 normales, mi idea es especificar para cada vertice el indice de la normal.

Marci, ¿puedes explicar mejor tu solución? segun entiendo lo que haces es crear los 100 vertices con las 100 normales asociadas y despues mirar si se repiten para recortar los repetidos. No es mala idea, no ahorro tanto espacio pero ya es algo.

Es que me cuesta aceptar que no exista una solución OGL para esto, me parece algo muy elemental, se pueden indexar mil cosas pero ahora resulta que los indices tienen que ser simultaneos para todos, no me parece nada optimo.

[ethernet]

EL tema de los vértices duplicados está ya bastante trillado. Te toca duplicar vértices...

[MA]Mestre]

Es que me cuesta aceptar que no exista una solución OGL para esto, me parece algo muy elemental, se pueden indexar mil cosas pero ahora resulta que los indices tienen que ser simultaneos para todos, no me parece nada optimo.

Existe esa solución en DX ?

El 'vértice' de un poligono lleva con sigo 'todo un pack', no puedes indexar sus elementos individualmente. Además lo encuentro lógico.

Siguiendo tu ejemplo, tenemos 100 vértices y solo 2 normales. Resulta que en algún stage de pipeline, ( o un simple Shader ), modifica alguna de las 100 normales mapeadas en 2.  Óptimo ?

[tamat]

pues habría pensado que trabaja con replicas en memoria cuando cruza la pipeline.

En fin, me tocará tirar algo de memoria.

[Marci]

Marci, ¿puedes explicar mejor tu solución? segun entiendo lo que haces es crear los 100 vertices con las 100 normales asociadas y despues mirar si se repiten para recortar los repetidos. No es mala idea, no ahorro tanto espacio pero ya es algo.

Si, basicamente es montar los vertices y despues indexarlos de forma que el vertex buffer pueda trabajar con ellos (eliminas todos los vertices que comparten la normal). Como tu dices no ahorras mucho pero no se me ocurrió otra cosa. Lo bueno es que si cargas la malla desde un archivo con todo indexado para las comparaciones puedes trabajar con enteros (los indices). Lo malo es que el tiempo de carga de un archivo se te alarga demasiado.

Mestre"]El 'vértice' de un poligono lleva con sigo 'todo un pack', no puedes indexar sus elementos individualmente.

De acuerdo en que habrá casos en que no se pueda indexar por separado, pero creo que para representar una malla estatica en la que no se va a modificar ningun vertice si se podria hacer

[tamat]

es que fijaos en mi caso, tengo un modelo de 10.000 vertices de un edificio. No hace falta ser muy listo para darse cuenta de que normales no hay más de 100 (todo son planos ortogonales), y eso porque hay algunos arcos, sino en realidad solo necesitaría unas 12. Me duele tener que reservar 10.000 * 3 floats * 4bytes =  120KBs para algo que ocuparia 1KB.

Pero entiendo que puede ser problema de la arquitectura de las tarjetas gráficas y la gestión que hacen de los datos.

[ethernet]

No te preocupes, nosotros tiramos con casas de 400 mil vértices y ni se inmuta la tarjeta :P

[tamat]

es bueno saberlo

[marcode]

Me duele tener que reservar 10.000 * 3 floats * 4bytes =  120KBs para algo que ocuparia 1KB..

Si no necesitas mucha precisión podrías usar bytes en lugar de dwords para describir las normales, aunque no sé si bajará el rendimiento.