DISCLAIMER: I am well aware that the godly TnL units on most video cards make this unneeded. But it's an interesting thing to consider. Also, this isn't a question, it's a discussion. Frequently, some sort of mesh will have many vertices with exactly the same position, but different material/tex coord information. Currently, the only way to use these vertices is to create multiple duplicate vertices, all with the same position but having different tex coords. This results in vertices with the exact same position information being transformed multiple times, when really they don't need to be. So, my question is, how can one avoid multiple transformations of what is essentially the same vertex? Let's take an exaggerated example. Suppose we have some arbitrary vertex pool, in an indexed tri list, that averages 9 duplicates per vertex position (that is, 10 identical verts total), all with different texture coordinates. Let's suppose that most of these vertices are, on average, fairly close to each other in order of use (so they are all close together in the index buffer). Is it possible to somehow redesign this thing to effectively and efficiently recycle transformation information? (You can consider this either from an application or driver perspective.)

Let's stick to fixed function pipeline, for this discussion. Again, I'm aware that this is really not relevant to reality.

[Edited by - Promit on October 6, 2004 12:58:40 PM]

I don't think this is that big a deal in reality. The main situations where you get these kind of duplicated vertices are where there are texture seams and where you have a hard edge requiring two different normals. As a proportion of the total vertices in the mesh such vertices are not all that common in most real models. Your exaggerated example is hugely exagerrated I think - it's rare for a single vertex to be at the junction of more than two boundaries so it's rare for there to be more than 2 duplicates of a vertex. Vertices that need duplicates are a small proportion of the total so the average number of duplicates for the entire mesh is much lower than 2. I would expect there to be fewer duplicates in a typical mesh than there are degenerate verts in a typical stripped mesh.

Whilst there is hardware that can maintain separate index lists for separate streams I don't think the minor benefits are worth the additional complexity. The cost of all those extra index buffers is also not insignificant. It's one of those cases where the 'solution' is worse than the problem.