Texture coordinates in faces

[chronologicaldot]

Just musing here...
Wouldn't it be more convenient in some cases to put the texture coordinates in the indices themselves? That way we wouldn't have to duplicate vertices (and keep track of them) when assigning different parts of the texture on each face. Also, we wouldn't have to keep track of duplicated vertices when smoothing meshes (where it would otherwise be a real problem) or when assigning vertices to bone joints (where we've doubled the number of vertices we need to move).
Not that it doesn't have its disadvantages...

[Mel]

It is because of the redundancy of having multiple texture coordinates (or other info) repeated across the mesh. A triangle inside a mesh, with texture mapping on, shares the texture coordinates among the neighbours.

Think of this, a square, 2 ajacent faces: It uses 4 vertices and 6 indices
In the current approach they'd have 4 texture coordinates, one per vertex
With yout approach they'd have 6 texture coordinates, one per index, two of them repeated.

Now think of a large patch of adjacent squares, say 4x4 squares, with a single texture map (a terrain, for example). It uses:
25 vertices and 216 indices, using a primitive list.
Current approach: 25 texture coordinates to transfer to the video card
Your approach: 216 texture coordinates, most of them repeated.

And you're just storing one set of texture coordinates, if you store two, the information duplicates. If you store aditional data, the same.

Storing the data on the vertices is advantageous because it reduces the amount of information to the minimum necessary. To create meshes which aparently have separate texture coordinates it is necesary to duplicate the vertices, indeed, but that redundancy is just local to the places where the texture coordinates split, overall, there would be still less data involved than having the information stored per index.

[chronologicaldot]

I see.
Thanks for the reply!
I was musing because I'm trying to do a bit of editing work where, in some cases, I do end up making multiple vertices because of some little texture coordinate difference. I imagine, though, even in these situations, given what you've said, it's still probably far less troublesome to have the vertices contain the texture coords. hm...
Anyways... Thanks again

[Mel]

It has its disadvantages also, of course, when you add multiple information to the vertices, and they split between faces groups, it increases the amount of vertices because you have to have a group of vertices for each combination of the information you're storing, this is more noticeable when splitting smoothing groups and texture coordinates, for instance, or colors. The amount of combinations increases to the square of the amount of data sets to be stored.

In practice the processing isn't performed on meshes that are meant to be transferred to the video card, but on custom meshes which store the necessary information, like the adjacency data, and can be handled more efficiently, before that mesh is translated into a mesh of vertices and indices.

For instance, Blender's smoothing groups don't exist per se, they are indeed created separating faces and duplicating the vertices on the borders. The advantage is that it is very fast to translate such mesh to the video card, although probably it also contains internally another mesh with aditional information that can be passed, or not to the videocard when needed. The inconvenient is more conceptual than anything else, you expect a vertex to remain a single vertex, while in practice, they're two.