Do I need to assume that all vertices share all attributes - i.e., coordinates, normals, textures, etc, as far a copying data to the VBO with, say, glBufferSubData?[/quote]

Yes.
Stride, in glXXXPointer is used to specify the byte offset between consecutive vertices, yes, but a vertex in glXXXPointer's case is the trio: position, color, and normal. Correct usage is as such, assuming you have a vertex struct in the style of:


typedef struct vertex_t
{
float x, y, z;
float nx, ny, nz;
unsigned char r, g, b, a;
} Vertex;


You can specify the byte offset for each attribute of the vertex by using glXXXPointer as such (28 = sizeof(Vertex)):

// glVertexPointer is doing exactly this: read the next 3 floats at pos (ptr),
// then move to the next position data, 28 bytes ahead
glVertexPointer(3, GL_FLOAT, 28, ptr);
// glNormalPointer forces normal vectors to hold 3 numbers,
// does the exact same as glVertexPointer
// however, the first 12 bytes in the array hold the position data,
// so you tell OpenGL to look 12 bytes ahead in the array
// to mark the location of the normal data in the array, then move on
// 28 bytes to the next normal vector
glNormalPointer(GL_FLOAT, 28, ptr+12);
// same as before, read the next 4 bytes as color data,
// and skip now 12 bytes for the position and 12 bytes
// for the normal data, then move on 28 bytes ahead
glColorPointer(4, GL_UNSIGNED_BYTE, 28, ptr+24);


In the case for VBO's, you can replace "ptr+##" with "((char*)NULL + (##))" as a macro.

To draw, simply enable what you want to be drawn on the client side before you issue your drawing command.
So, in your triangle example:


glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_COLOR_ARRAY);

// draw first triangle

glEnableClientState(GL_NORMAL_ARRAY);

// draw second triangle

glDisableClientState(GL_NORMAL_ARRAY);
glDisableClientState(GL_COLOR_ARRAY);
glDisableClientState(GL_VERTEX_ARRAY);


EDIT: Missed your 3rd question.

I'm just not clear whether I have to make a worst-case scenario assumption that all vertices always have all attributes.[/quote]

If you were drawing objects without color, or normals, or etc, just disable them on the client side before you draw. The empty data will be skipped over, and never looked at. If you have, say, two different structs for vertices you use, like ColorPoint and BlankPoint, just specify different byte offsets and positions when calling glXXXPointer. It helps when you're worried about data consumption, no reason to allocate a ton of space if you aren't going to use any of it, otherwise, just skip it.

You can specify the byte offset for each attribute of the vertex by using glXXXPointer as such (28 = sizeof(Vertex)):[/quote]

You can specify the byte offset for each attribute of the vertex by using glXXXPointer as such (28 = sizeof(Vertex)):

[/quote]
So why not put it in your sample code and keep everything unambiguous then? The OP has already expressed some confusion about the usage here - providing sample code containing hard-coded vertex sizes (and creating a risk that the mistake will be propagated via copy/paste) is not wise in the circumstances.

glVertexPointer (3, GL_FLOAT, 28, ptr);

Don't do this.

Do this instead:

glVertexPointer (3, GL_FLOAT, sizeof (Vertex), ptr);

Safe, portable, clean, robust, has been used in OpenGL code all over the world for 16+ years.

1) I actually have multiple calls - possibly thousands or even millions! - to store the data in the vbos. Then, during the rendering, I need to traverse this data. The model is usually the same, but the view may change. I had thought of creating just a single struct that could potentially hold everything like you described. My problem is that during the storage phase the data is not packed: I have coordinates in one array, normals in another, texture coordinates in another, etc. So if I'm going to store the data in a uniform way then I need to use CPU time to move the data around into my struct format. I have found that sometimes my machines end up CPU-bound - NOT GPU bound! - so this moving actually consumes a lot of time.

2) Another "related" question: I'm using both a Windows and a Linux machine. Both have NVIDIA cards that, according to NVIDIA, support OpenGL 4 or higher. My question: the "default" location for the header files and the libraries are such that, on both machines, I only see OpenGL version 1.1. Is there a way to get header files and libraries I can use that would automatically support the version of OpenGL claimed by the NVIDIA card? I would assume that once the card is installed these libaries would be made available, but I haven't been able to find them anywhere. If anybody has a clue to this problem I would appreciate any help. I'm currently stuck on Windows and I have to use hacks and OpenGL extensions on Linux to test all this. There has to be a better, cleaner way.
[/quote]
This is the way OpenGL works. Newer versions in the API are not defined in the standard headers. I also have a project running in both Windows and Linux, and I use the glfw library to help me set-up an OpenGL context (works for both Linux and Windows). To get access to later versions of OpenGL, I would recommend to use glew. You include that instead of gl.h. This package is also available for both Linux and OpenGL.

See more information at http://www.opengl.org/wiki/Getting_Started