Don’t you mean 6 sides?
Ah, ok.
Here’s the basic idea behind the triangle indices. As you know, modern hardware generally renders geometry in terms of individual triangles. Now, you could just describe each triangle in terms of three vertices, e.g.:
[0, 1, 2], [4, 5, 2], [2, 4, 2]
And graphics APIs such as OpenGL and Direct3D will in fact let you do that.
However, consider a cube. A cube has 8 unique vertices (not worrying about normals and texture coordinates for the moment), and 12 triangles. If we submit three vertices for each triangle, that’s 36 vertices total. On modern hardware however, sending data across the bus is one of the costlier things you can do, so it’s generally best to minimize the amount of data that needs to be transfered where possible. In this case, we’re obviously sending each vertex multiple times, so there’s some redundancy there that can be eliminated.
One way to eliminate the redundancy is only to send 8 vertices, and then send a set of integer indices, where each set of three indices describes a triangle. The indices themselves index into the vertex array; for the cube (for example), that means all the indices will be in the range [0, 7].
Here’s an even simpler example: a quad. The vertices and indices for a simple quad might be:
vertices: [0, 0], [0, 1], [1, 1], [1, 0]
indices: 0, 1, 2, 0, 2, 3
If you draw this out on paper, you should see how the indices describe the two triangles that make up the quad (assuming I didn’t mess anything up).
In actuality, a cube mesh will likely have at least 24 vertices anyway, since it’s likely that normals and texture coordinates will not be shared at the corners. But, for more complex meshes with many triangles, using triangle indices can drastically reduce the amount of data (since the vertices don’t need to be duplicated for each triangle).
Sorry if that explanation is overly elementary and I’m telling you stuff you already know, but it seemed like the easiest way to explain it. (Post back if that still doesn’t answer your questions though.)