I render my tris using glDrawElements(), passing an index-array and a pointer to the actual vertices. Each triangle in my structure stores it’s own indices to the verts. When I add a tri to the renderbuffer it’s _indices is copied. That means that I don’t need to store more verts than necessary. Everything worked fine until when I wanted to add texcoords.
I really wish there were a gl command that used both vertexindices and texcoordindices.
Well, if you actually understood what I meant, what would you do?
I could use vertexarrays with nine values for each tri, and no shared vertices. Is that a good or bad idea? What should I do?
When I add a tri to the renderbuffer it’s _indices is copied. That means that I don’t need to store more verts than necessary.
Sure about that? Store where? In vid card memory, I suppose? How many times average do you reference a single vertex? Five+ times on average? What kind of geometry are you using then?
Even if your vertices are stored in fast memory, they’re still not free. They still eat space. Even worse, if you were able to upload lots of vertices that are mostly unused and only referenced once in a blue moon, you’d be fragmenting memory and wasting bandwith.
Just accept that there are no vertex array formats for your purposes. That’s not necessarily a bad thing.
Use glTexCoordPointer just as you would glVertexPointer (but mind the different parameters when you call it) and make up an appropriate array of texture coordinates, most likely parallel or mixed in with your vertex coordinates. Then glDrawElements will match them up when it goes.
OpenGL, and other hardware APIs, do NOT allow you to use indexed primitives with separate texture and vertex indices. This is question #1 asked by anyone who comes out of a procedural/software/modeling background.
It turns out that while you lose some memory by splitting out vertex/texture data into unique v/t combinations, you gain a lot of memory by only using one index array, so the potential memory savings aren’t that great. For many meshes, this is actually a net win! Thus, you might as well go with what the hardware can understand natively.
If you’re saying that having separate position, normal and texture coordinate lists will need less position transforms and/or normal transforms, then this could potentially be true. On the other hand, it would require more data to transfer (three indices instead of one!) and would complicate implementation a lot, for very little practical gain.
The key take-home point here is that for meshes with any reasonable complexity (which is where this matters) the number of “split verts” is really fairly low.