The concept of Index buffers is that certain vertices are shared across faces, hence can be reused to save space of duplicated verticies. A vertex is usually more than 12 bytes (depending on the number of attributes, ie. 3* 32-bit floats), while an index could be stored in as little as 1 to 4 bytes (depending on max number of vertices).
Example: A cube consisting of 6 quad-faces without using an index buffer would require
6 * 4 * 12 = 288 bytesBut as it only has 8 unique vertices, it could be stored using an index buffer with 4 * 6 indices =
8 * 12 + 4 * 6 = 120 bytes
However for non-shared vertices the space used by the Index Buffer is effectively wasted - because these vertices could've been drawn without an index buffer (if correct ordering in the vertex buffer is given). Considering only the vertex position as attribute, this trade-off would make sense for most meshes - but meshes in the real-world tend to have also other attributes like normals, texture-coordinates etc. Even if a vertex position is shared across faces, it is rare that all other attributes are also shared - hence the vertex needs to be duplicated in the vertex buffer.
Example: A cube with normals has 8 unique vertices, but each of its 6 faces having a different normal vector. So 48 unique vertices are required, if one vertex is 24 bytes this results in =
8 * 6 * 24 = 1152 bytesUsing an index buffer the same size is needed plus at least 48 bytes to store the indices =
Not only would a vertex buffer without index buffer need less memory, it would probably be more cache-friendly as well (as the memory accessed is continous memory).
I try to find out in which scenarios I should use an index buffer instead of a plain vertex buffer, but I failed to find any real-world examples where it would make sense to use an index buffer at all.
My question is: Are there any cases in modern graphics-programming where using an index buffer will actually bring a benefit (ie. is there any advantage which I overlooked)?