Vertex Array Question

dug this up…


16.150 How can I use vertex arrays to share vertices?

Because vertex arrays let you access a set of vertices and data by index, you might believe that they’re designed to optimally share vertices. Indeed, a programmer new to vertex arrays might try to render a cube, in which each vertex is shared by three faces. The futility of this becomes obvious when you add normals for lighting and each instance of the shared vertex requires a unique normal. The only way to render a cube with normals is to include multiple copies of each vertex.

Vertex arrays weren’t designed to improve vertex sharing. They were intended to let the programmer to specify blocks of dynamic geometry data with as few function calls as possible.

You can share vertices with vertex arrays the same way you do with OpenGL immediate mode, by the type of primitive used. GL_LINE_STRIP, GL_LINE_LOOP, GL_TRIANGLE_STRIP, and GL_QUAD_STRIP share vertices between their component line segments, triangles, and quads. Other primitives do not. The type of primitive you choose to use when using vertex arrays determines whether you share vertices.

Note, however, that sharing vertices is implementation dependent. The OpenGL Specification dictates vertex array behavior, and as long as an OpenGL implementation conforms to spec, it’s free to optimize vertex sharing in vertex arrays.

Some implementations feature the EXT_compiled_vertex_array extension, which is explicitly designed to let implementations share transformed vertex array data.


compliments of the OpenGL Faq and Troubleshooting guide http://www.frii.com/~martz/oglfaq/

found this too… http://www.quake3arena.com/news/glopt.html


Quake3’s rendering architecture has been defined with the primary goal of minimizing API calls and focusing as much work as possible in a single place to make optimization more productive.

During gameplay, 99.9% of all primitives go through a single API point:

glDrawElements( GL_TRIANGLES, numIndexes, GL_UNSIGNED_INT, indexes );

GL_VERTEX_ARRAY is always enabled, and each vertex will bet four floats. The fourth float is just for padding purposes so that each vertex will exactly fill an aligned 16 byte block suitable for SIMD optimizations.

GL_TEXTURE_COORD_ARRAY is always enabled for the base texture unit, and points at pairs of floats.

If ARB_multitexture is available, GL_TEXTURE_COORD_ARRAY may or may not be enabled for the second texture unit.


Thanks for the info Mike J… yeah that all makes sense…