2010-11-27 13 views
7

Oye. Soy nuevo en OpenGL ES pero tengo mi experiencia compartida con OpenGL normal. Me han dicho que el uso de matrices entrelazadas para los búferes de vértices es mucho más rápido debido a la optimización para evitar errores de caché.
he desarrollado un formato de vértice que voy a utilizar con este aspectoAlcance del atributo de Opengl Vertex

 
struct SVertex 
{ 
    float x,y,z; 
    float nx,ny,nz; 
    float tx,ty,tz; 
    float bx,by,bz; 
    float tu1,tv1; 
    float tu2,tv2; 
}; 

Luego utiliza "glVertexAttribPointer (índice, 3, GL_FLOAT, GL_FALSE, zancada, v);" para apuntar a la matriz de vértices. El índice es uno de los atributos que quiero usar y todo lo demás está bien, excepto la zancada. Funcionó antes de que decidiera agregar esto a la ecuación. Pasé la zancada como sizeof (SVertex) y como 13 * 4, pero ninguno de ellos parece funcionar.
Si tiene alguna importancia, dibujo las primitivas como esta

glDrawElements(GL_TRIANGLES,surface->GetIndexCount()/3,GL_UNSIGNED_INT,surface->IndPtr());
En las especificaciones de OpenGL está escrito que la zancada debe ser del tamaño en bytes desde el final del atributo (en este caso z) hasta el siguiente atributo del mismo tipo (en este caso x). Entonces, según mis cálculos, esto debería ser 13 (nx, ny, nz, tx, ty .... tuv2, tv2) multiplicado por 4 (el tamaño de un flotador).
Ah y una cosa más es que la pantalla está vacía.
¿Alguien podría ayudarme con esto?
Muchas gracias.

+1

Dije 13 valores pensando que tengo que restar los primeros 3 (si solo tienes x, y, z entonces la zancada es 0); – Sanctus2099

Respuesta

6

Si tiene una estructura como esta, entonces stride es solo sizeof SVertex y es lo mismo para cada atributo. No hay nada complicado aquí.

Si esto no funcionó, busque su error en otro lugar.

Por ejemplo aquí:

surface->GetIndexCount()/3

Este parámetro debe ser el número de vértices , no primitivos que se enviará - por lo tanto, yo diría que esta división por tres es incorrecto. Dejarlo como:

surface->GetIndexCount()

+1

Gracias. Fue el recuento de índice. Aunque si observa las especificaciones de Ogl " recuento: especifica el número de elementos que se procesarán". – Sanctus2099

+0

Creo que la especificación significa que un "elemento" es lo mismo que "vértice" en este contexto. Líneas, triángulos, quads, polígonos, etc. se denominan en conjunto "primitivos". – Kos

+0

en realidad, el segundo argumento es el número de ** índices, no vértices **. Acerca de las especificaciones "elemento" significa que más primitivas se compilan con índices según un modo de topología *. Pero al final del día es simplemente que los índices cuentan. – Stringer

2

Luego utiliza "glVertexAttribPointer (índice, 3, GL_FLOAT, GL_FALSE, zancada, v);" para apuntar a la matriz de vértices. El índice es la de que el atributo quiero usar y todo lo demás está bien , excepto el paso

Esto no funciona para TexCoord (usted tiene 2x 2 flotadores o boyas 1x 4).

Sobre la zancada, como dijo Kos, creo que debe pasar un paso de 16 * sizeof(float) (el tamaño de su SVertex).

También otra cosa que vale la pena mencionar. Usted dice que quiere optimizar el rendimiento. ¿Por qué no comprime su vértice al máximo y suprime los valores redundantes? Esto ahorraría mucho ancho de banda.

x, y, z están bien, pero nx y ny son autosuficientes si sus normales están normalizadas (que puede ser el caso). Puede extraer en el sombreador de vértices nz (suponiendo que tiene capacidades de sombreado).Lo mismo aplica para tx y ty. No necesita bx, by, bz, ya que sabe que es el producto cruzado de normal y tangent.

struct SPackedVertex 
{ 
    float x,y,z,w;  //pack all on vector4 
    float nx,ny,tx,ty; 
    float tu1,tv1;tu2,tv2; 
}; 
+1

Algunos buenos comentarios aquí acerca de la redundancia, pero ¿este resultado normal de empaque en un rendimiento realmente mejorado? Suena probable (la latencia de la memoria gpu es probablemente un cuello de botella más ajustado que el poder de procesamiento de vértices en la mayoría de los casos), pero, ¿los puntos de referencia realmente lo confirman? – Kos

+2

No lo sé, solo estoy adivinando aquí. Como siempre, punto de referencia, punto de referencia, punto de referencia! :) Si OP está utilizando OGL ES, probablemente su código se ejecute en dispositivos portátiles que están lejos en términos de ancho de banda de memoria de las GPU de escritorio (creo), por lo que puede valer la pena intentarlo ... – Stringer

+2

Además, no sé si esto puede aplique aquí, pero el tamaño del vértice también parece importar para el caché pre-VS (tal vez 32 o 64 bytes es mejor que 48 ...) En ese caso, trataría de comprimir aún más, a 32 bytes. Esto podría hacerse utilizando medio flotador (GL_OES_vertex_half_float) para normales, tangentes y texcoords: http://developer.amd.com/gpu_assets/GDC06-ATI_Session-Zarge-PerfTools.pdf – Stringer

Cuestiones relacionadas