VBO's -> data parameter

Hi,
I want to use vertex buffer objects in my program, but i’m a little confused about the parameter data of glBufferData.
On the nehe example: http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=45
In that code, they use a class, with three variables(x, y and z), and they give an array of that classes to the function glBufferData.
But on the man page of glBufferData, it says nothing about classes or whatever, and the way I would think data has to be stored is an array of floats, where the size of the array equals to the number of vertices to render times three.
Can somebody clear this up a bit?
Thanx in advance,
Hylke

The best way to understand VBO is to read carefully the specs. You don’t need any classes. Why would you need them since GL is written in C but not C++ ? Classes are made to make things easier, generally :slight_smile:

For BufferData, it is simple: give the size in bytes, a pointer that points to the start of the array to copy, and the usage. The size is like any other allocating command, like malloc. You can’t give the number of vertices3 just because you can not only put float in VBO but any other types which do not have the same sizes. So you’ll give vertices3*sizeof (GLfloat) for example.

Thank you for your reply,
But I still have a question:
How can OpenGL fetch the data from a class/struct?

This question relies from how your programming language stores the data in memory not from GL. So I guess a good book or a good documentation about your programming language will definately help you increase your understandings.

Anyway, generally in C and C++ when you write something like this:

struct S{
   float a;
   float b;
   float c;
};

all a,b and c will be memory aligned (I said generally because I could never ensured it anywhere). In this case, simply put the adress of a when you fetch.
What’s an obligation from the standards is that all struct S will have the same size (here 3*sizeof (float)).

Hope that could help.

I already figured it would be something like that.
Well, thanks.
Hylke