Mathematical Topics from 3D Graphics - 3D Math Primer for Graphics and Game Development - page 385

The vertices must be listed in clockwise order around a face, but it
doesn't matter which one is considered the “first” vertex; they can be cycled
without changing the logical structure of the mesh. For example, the quad
forming the cube top could equivalently have been given as {1,2,3,0},

{2,3,0,1}, or {3,0,1,2}.
As indicated by the comments in Listing 10.5, additional data are almost
always stored per vertex, such as texture coordinates, surface normals, basis
vectors, colors, skinning data, and so on. Each of these is discussed in
later sections in the context of the techniques that make use of the data.
Additional data can also be stored at the triangle level, such as an index that
tells which material to use for that face, or the plane equation (part of which
is the surface normal—see Section 9.5) for the face. This is highly useful
for editing purposes or in other tools that perform mesh manipulations in
software. For real-time rendering, however, we seldom store data at the
triangle level beyond the three vertex indices. In fact, the most common
method is to not have a struct Triangle at all, and to represent the entire
list of triangles simply as an array (e.g. unsigned short triList[] ),
where the length of the array is the number of triangles times 3. Triangles
with identical properties are grouped into batches so that an entire batch
can be fed to the GPU in this optimal format. After we review many of
the concepts that give rise to the need to store additional data per vertex,
Section 10.10.2 looks at several more specific examples of how we might feed
that data to the graphics API. By the way, as a general rule, things are a lot
easier if you do not try to use the same mesh class for both rendering and
editing. The requirements are very different, and a bulkier data structure
with more flexibility is best for use in tools, importers, and the like.
Note that in an indexed triangle mesh, the edges are not stored explic-
itly, but rather the adjacency information contained in an indexed triangle
list is stored implicitly: to locate shared edges between triangles, we must
search the triangle list. Our original trivial “array of triangles” format in
Listing 10.4 did not have any logical connectivity information (although
we could have attempted to detect whether the vertices on an edge were
identical by comparing the vertex positions or other properties). What's
surprising is that the “extra” connectivity information contained in the in-
dexed representation actually results in a reduction of memory usage in
most cases, compared to the flat method. The reason for this is that the
information stored at the vertex level, which is duplicated in the trivial
flat format, is relatively large compared to a single integer index. (At a
minimum, we must store a 3D vector position.) In meshes that arise in
practice, a typical vertex has a valence of around 3-6, which means that
the flat format duplicates quite a lot of data.
The simple indexed triangle mesh scheme is appropriate for many ap-
plications, including the very important one of rendering. However, some