I realized that glDrawElements will use vertex index to lookup texture/normal from their respective arrays, unfortunately most uv sets will contain multiple uvs mapped to a single vert(per face mapped), this will not work. And since I can’t provide alternative uv indices(can I?), indexed drawing will be useless right?
Similar question to this 10 year old thread,
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=138451
Any modern solution?
The fourth post down in that thread answers the question:
Unfortunately, this is the nature of vertex arrays. Your index is an index into each of your separate arrays, so if you need a vertex that has a certain position, but two sets of UVs, you will need to have that position in two places in your vertex array.
This is completely normal and used in virtually every 3D game and most other 3D applications. You should do this unless you have a specific need not to.
Ahh… do you mean using uv set as key data source with verts/norms mapped to it? I’ve been centering at the poly verts all this time…
Ahh… do you mean using uv set as key data source with verts/norms mapped to it?
No. It means that if one attribute (position, normal, UV, etc) is used with two or more other values, then that attribute must be replicated.
“Useless” is a pretty strong word. Indexed arrays will still provide quite a performance boost in most normal use cases.
I guess what you really mean is that “it’s a shame that OpenGL doesn’t have something like GL_ARB_separate_indexes where you can specify a separate index for each vertex attribute”. Yes, I agree that it’s a shame, but the API does ultimately have to follow what the hardware can support, and all the more so in recent versions, and right now hardware just does not support this.
But “useless” is still a damn strong word. I find it hard to accept “useless” when I’ve personally used this technique to reduce vertex submission by a significant percentage, and when so have thousands of others.
Using uv set as a reference will produce the same result does it?(will try it out…)
No offense. I should have use “not use” instead. 
None taken. 
All the same, loads of people have definitely used it to great benefit, so I guess you’ve just got a use-case for which it’s advantages don’t apply. So yeah, useless for what you want to do right now perhaps, but it should still be your first option in other cases.
Not really… I’m actually working my way down from the data I have, drawing/learning them with opengl until I hit this problem of missing/incompatible indices. I’m just gathering info on how things are done, and what’s available or depreciated.
If you have an environment with a lot of hard edges, I guess the memory and lookup of the indices is more expensive than it’s worth. As only on smooth, rounded shapes can they share data… I guess there’s also a computational advantage because the vertex shader runs once for every indice rather than 3 per triangle (if not stripped)