vertex arrays - static?


I’m trying to use glDrawElements with index and vertex arrays
implemented as class data members. I haven’t been able to get it to
work. Do the index and vertex arrays need to be static?

All the samples I’ve seen have the index and vertex arrays declared with
static storage (and initialized with values), but I can’t find any
reference that says it’s required.

Thanks for your comments.


No, they don’t need to be static. There may be other restrictions in your class that are preventing the rendering from working. For example, I’d be surprised if a private member array could be accessed by glVertexPointer.

Hope that helps.


I’m calling glVertexPointer from inside the Render() method of the class, so it has the required access. It all works OK if I declare the arrays static, outside the class, and initialize them with the data. The problem with that approach is that I want to be able to load the data from a file at run time.

Here’s the data and code that I’m using to test it (I’m using VC++6 and OGL1.2):

void Class::LoadFromCode()
// fVertices and iVertexIndex declared in header

fVertices = new float[12];
fVertices[0] = 1.0f;
fVertices[1] = 1.0f;
fVertices[2] = 0.0f;
fVertices[3] = 1.0f;
fVertices[4] = 0.0f;
fVertices[5] = 0.0f;
fVertices[6] = 0.0f;
fVertices[7] = 0.0f;
fVertices[8] = 0.0f;
fVertices[9] = 0.0f;
fVertices[10] = 1.0f;
fVertices[11] = 0.0f;

iVertexIndex = new unsigned int[4];
iVertexIndex[0] = 0;
iVertexIndex[1] = 1;
iVertexIndex[2] = 2;
iVertexIndex[3] = 3;

void Class::Render()
glColor3f(1.0f, 0.0f, 0.0f);

glVertexPointer(3, GL_FLOAT, 0, fVertices);

glDrawElements(GL_LINE_LOOP, 4, GL_UNSIGNED_INT, iVertexIndex);


All I get is a line from (0,0,0,) to (0,1,0).

Any help would be greatly appreciated.
(I hope I haven’t made a really stupid error : ) )

Thanks, P.

OK, I’m sure they don’t have to be static but they may have to be global, or at the least public. You also don’t have to set them up at compile-time. I’ve dug up an old app which uses VAR and has the VAR pointer and the index array global (not static) and initialises both at run-time. The problem I can see is that although your Render function is calling the OpenGL functions, the OpenGL functions themselves have no idea of C++ scope and what seems like straightforward addressing to us may not be so clear cut to the compiler - I don’t know. You may have to dig into the assembly code to see what’s being output here.

BTW, you don’t have to call glEnableClientState and glVertexPointer every frame unless the vertex data changes between calls to glDrawElements (or you’re using multiple class objects with different fVertices in each). All I can suggest is to try calling glDrawElements with GL_POINTS or GL_QUADS to see what the output is. You could also send the app to me to have a look at if you want (e-mail in profile, remove nospam). I need a break from 2 days/30 pages of Formal Methods using Z - arrgh!

Whatever happens, let us know your solution since this is something I haven’t tried before and it may be of interest to some. I am pretty sure that people have used this method before (rendering in a class function) so you may get an answer from someone else sooner or later.

Hope that helps.

As I feared, I was barking up the wrong tree, and the problem was something MUCH simpler: let’s just say everything became a lot more obvious when I increased the size of the frustum and backed away a little.

So, the code above works : )

I do need to change the data between calls, at unpredictable times; the models are eventually going to be deformable. Maybe I’ll keep a flag with each model, and only call glEnableClientState and glVertexPointer when the model is deforming.

Also, the class above is to become a base class for models in a scene. The current problem is to create a linked-list of the base class type, and traverse the list, calling the correct Render() function defined as a virtual method.

Anyway, ffish, thanks a lot for your help. It saved me lots of time, P.

Originally posted by pythagoras:
let’s just say everything became a lot more obvious when I increased the size of the frustum and backed away a little.

LOL! These things happen …