The modern way to go is to use vertex buffer objects (VBOs) when it comes to rendering. Therein you have vertices and faces, the latter given either implicitely as vertex sequences or (a bot more explicit) as sequence of indices of vertices. Indexed vertices are most efficient if vertices can be shared between faces. Using any other representation means the necessity to convert.

The above works well for rendering. Animation, or even more interactive editing of meshes may make more topological information senseful to know.

In other words, the solution depends a bit on the situation.

I'm a little torn between vertex arrays and display lists atm (though I'll end up back with VBOs in the long run).

So I'll just pick up on your vertex normal comment; you can easily calculate one by taking an average of all connecting surface normals (this will vary depending on tessellation and any boundaries).

A vertex always describes all (needed) features of a surface at a given point. So it is a composite of the position itself, the normal and tangent and bi-normal vectors at that position, the color(s) at that position, and the texture co-ordinates at that position; just to name the most common ones. If you are using VBOs and only a single bit of all these values differs, you need to store a second vertex. The immediate mode allows you to assemble the vertex at runtime on CPU costs, but that way is slow and will be no longer part of core OpenGL with version 3 (however, it will presumbly be available in a utility library).

The mesh representation as vertices and sequences of polygon corners (either as index lists or not) still has topological information of vertices, edges, faces, and partly of shells. So you can of course find shared vertices in a VBO like representation, although it is obviously very inefficient since some dependencies are given indirectly only, and hence require the algorithm to do many searches. On the other hand, as already stated in my previous post, how often do you encounter situations in which yiu still need to access the topology that way?

The project I'm currently working on deals with both interactive editing and, of course, display of large amounts of meshes. Due to the interactive editing purposes, the project knows of a mesh structure named EditMesh. This kind of mesh has an explicit knowledge of vertices, edges, loops, faces (n-gons), holes, shells, regions, and voids as first class topological (and partly also geometrical) elements, and edge shares as well as face shares as helper elements.

During editing a mesh, the relations between the elements is explicitely given in both top down as well as bottom up order. When not being edited, roughly half of the relations are not available; when starting editing, the half is reconstructed, and when ending editing, it is dropped. Reconstruction is fast enough as long as not dealing with meshes of a million vertices. The advantage is that, although many meshes are loaded simultanuosly, the total memory consumption is relatively small since only one (or at most a few) meshes are edited at a time. Actually, the EditMesh is not VBO friendly, since it is a kind of multi-indexed array set.

Hence the above mesh representation is not suitable for fast rendering. For this purpose a totally other kind of meshes exists, namely the RenderMesh class. Whenever needed, the faces of the EditMesh are processed (i.e. triangulated), and a RenderMesh is computed from them. The RenderMesh, you assume it already, is very VBO friendly.

The computation of the RenderMesh is backed by the EditMesh, and hence has all geometrical and topological information at hand, also those used to decide how normals are to be computed (i.e. which faces contribute to what vertex normal). Although often only "the mesh is smoothed or not" may be used, the EditMesh allows a finer granularity. However, after the RenderMesh is computed, in many cases there is no more need to have the EditMesh at hand up until the next editing. So, in the "compiled" level, EditMeshes are very rare, but RenderMeshes are found at every corner.


Well, many words to show just "use whatever is suitable in a given situation".

_What_ is stored is principally: The vertex data (whatever is needed from the position, normal, ...), zero or more index arrays, and the kind of primitive for each (index) array, e.g. TRIANGLES or LINES. These informations are used to fill-up a GfxRenderingJob, actually just a vehicle to be able to sort rendering due to shader and material settings; I'm sure you already have read about this way.

If you're interested in _how_ it is stored: The nitty-gritty details are numerous...

Since the shaders may need various data, it cannot always be forecasted what compositions of vertex data need to be passed to the API. Even if it were possible, then the number of combinations may be too great. Hence, the vertex data is actually stored in "unstructured" octet arrays, overlayed by (more or less) primitive types as and when needed. The description how the overlays are to be done is stored in some metadata. E.g. the byte offset, primitive data type, and semantics is stored this way. (For performance reasons, I don't deal with one such array for each mesh but with several and bigger arrays, but you don't necessarily need care about that ATM.) However, all those stuff is later used when the renderer actually performs a GfxRenderingJob, for parametrizing the various glXxxPointer and related routines.

Since situations exists where a mesh is so-called "static", presumbly a copy will be made in VRAM or so (see the various GL_STATIC_DRAW, GL_DYNAMIC_DRAW, GL_STREAM_DRAW,... modes). The renderer needs to know whether such a copy exists, or whether it is required to refresh the copy from the main memory. It furthur needs to know which VBOs are associated with a mesh. These informations are also available from the RenderMesh class (although not necessarily directly).