Performance

[jean91]

Hi
Actually we have a bunch of drawing functions with or without indices for sending batches of vertices. It was expected that sharing vertices would speed up thing. However, when you look at some objects to draw, like a cube for instance, each vertex is shared by 3 faces but on each face, the texture coordinates are different, as well as the normal vectors. To my knowledge, there is no way to have separate indices on each active array. So, in fact, we must dupplicate the metric coordinates.
My suggestion is to provide drawing primitives with separate indices to arrays. In the cube example, we would have to dupplicate only the indices to the metric coordinates.
Thanks
Jean

[aqnuep]

You can already perform that using programmable vertex pulling, i.e. getting your vertex attributes manually using the built-in gl_VertexID and texture buffer objects.

[menzel]

aqnuep is right about the possibility of custom pulling of vertex data. However, I see an advantage of multiple indices from a programmers point of view as this would be simpler to use.
But: I'm not sure how much of an advantage this would be, the cube example is kind of a worst case scenario, normally you will only have to dublicate vertices at texture seams so the saved amount of memory is small (but you add additional index arrays which in turn could make the total memory consumption even higher!). The biggest advantage in indexed rendering might be the use of the post-transformation buffer which now can use the index as a 'key' to prevent the vertex shader to get called a second time if that vertex was already processed. With multiple indices a set of indices will be the unique 'key' and the number of unique vertices will not be smaller so you will not save anything here (only make it more complicated for the hardware). Depending on the vertexshader complexity and the vertex locality (the post-transformation buffer has a limited space) most of your index-rendering performance boost comes from this and not the reduced memory footprint so multiple indices might not help but even slow down the rendering.

[mhagain]

Depending on the vertexshader complexity and the vertex locality (the post-transformation buffer has a limited space) most of your index-rendering performance boost comes from this and not the reduced memory footprint so multiple indices might not help but even slow down the rendering.

This, basically.

There is a culture of "using less storage is always better" and it is so often so wrong. If multiple index buffers were a genuine performance advantage they would have been available a long long time ago; the fact that they're not should tell us something.