   Indexed Primitives and Duplicated Vertices
  Hi everybody.I'm sorry if I ask something that could have been asked before (though I couldn't find it).Crease:The question is about different vertex attributes with respect to the face (triangle) they belong to: the very old question about "creases", e.g. discontinuity in attribute field but not in position.A tipical scenario is the cube described as follow: -- 8  positions (every cube has 8 vertices)-- 6  normals (one normal for each of the 6 faces of the cube)-- 24 UV texture coordinates (each face has its own part of a texture image)Indexed primitives with OpenGL (and, as far as I know, with DirectX) ask you the indices in the vertex array they are composed by. In the cube example, the only way to achieve the desired result is to duplicate every attribute (position and normal in this case) to create unique vertices. This lead (following the cube example) to a total of 24 vertices: 24 positions and 24 normal for 24 UVs. It is clear that if you can specify, for every indexed primitive, the index of every attribute, this would lead to a more compact vertex-data storage and a slight more expensive index sorage. In the common case, 3 floats for vertices, 3 floats for normals and 2 floats for uv represents vertex data, and one short is enough for indexing them. Thus our index storage would be multiplied in size by the number of attributes we use but we should save far more storage for vertex data.It is true that, for a large kind of geometrical models, almost every vertex has continuity in position and in every attribute field, but there are also common situations in where position is shared among different normals/UVs points (e.g. large urban environments where every building is represented by few polygons but you need to have different normals for each façade) and in which you prefere to use the typical face/vertex topology for position and face/wedge for local attributes.In conclusion, my questions are:1) Is there a particular reason for not to acheive attribute-bound indices at API level? (maybe hardware constraints?)2) Do some of you know an efficent way to acheive so? (maybe S.M. 3.0 vertex texture fetch or the new generation Primitive\Geometry Shader (DX 10, GL 2.1) could do so...)3) Should it be proposed as a new API-agnostic feature?Thanks!!! :)Marco.   
Quote:Original post by CoreMeltdown1) Is there a particular reason for not to acheive attribute-bound indices at API level? (maybe hardware constraints?)2) Do some of you know an efficent way to acheive so? (maybe S.M. 3.0 vertex texture fetch or the new generation Primitive\Geometry Shader (DX 10, GL 2.1) could do so...)3) Should it be proposed as a new API-agnostic feature?While it is not impossible to do what you want to do, there are reasons for resistance: it is hardware un-friendly and so would likely be implemented in the driver with significant performance penalties. Also, while a cube is good example of where this might be an appropriate solution, it is an extreme example. In a typical model, this might be useful for less than 10% of the vertexes.However, SM 3.0 does provide for "hardware instancing", but it doesn't do exactly what you are looking for.   