Question about vanilla vertex arrays. . .

I’ve been using ATI_vertex_array_object all this time, but have finally decided that I should also be supporting other hardware. I’m just wondering about a few points regarding standard OpenGL vertex arrays. . .

First is with regard to where the data is stored. According to the specs, the vertex data is stored in client memory (meaning the vid card). However, looking at how vertex arrays are used, it appears that each frame one must call glVertexPointer, glColorPointer, etc, or glInterleavedArray. These methods receive a pointer to arrays of data in system memory. Thus, how is it that the data is stored in video memory if the data must always be in system memory as well? Does one merely call glVertexPointer, etc, or glInterleavedArray during initialisation and then just render the vertices via glDrawElements (or whatever) each frame?

First is with regard to where the data is stored. According to the specs, the vertex data is stored in client memory (meaning the vid card).
Not necessarily true. What you are thinking of is Compiled Vertex Arrays (CVA). You do this by using an extension such as “GL_EXT_compiled_vertex_array”. Without this, your vertex data is held in system memory.

However, looking at how vertex arrays are used, it appears that each frame one must call glVertexPointer, glColorPointer, etc, or glInterleavedArray.
Not true. As you may know, OpenGL is a state machine and when you call these functions you will be altering it’s state, which only differs between Rendering Contexts (RC). Simply call your gl*Pointer() function once to tell OpenGL as to where vertex data is.

Thus, how is it that the data is stored in video memory if the data must always be in system memory as well?When using CVA the data is stored in both system memory and video memory. If you wish to change your vertex array data, then you must first unlock the data. Unlocking the data tells the video card that the data it stores locally may have been changed and requires validation (although it probably simply discards all local data). When you Lock the data, this tells the video card that the data will not be changed, so that it may be stored locally.

Does one merely call glVertexPointer, etc, or glInterleavedArray during initialisation and then just render the vertices via glDrawElements (or whatever) each frame?
That’s how I do it.

Just to clearify - the client in this case is the system, and thus the system memory, and the server is the gfx card ( if we can make such a distinction on a pc)

so vanilla vertexarrays stays in system memory and are transfered every time you use them.

Originally posted by JONSKI:
Does one merely call glVertexPointer, etc, or glInterleavedArray during initialisation and then just render the vertices via glDrawElements (or whatever) each frame?
That’s how I do it.

Then your scene must have only 65536 vertices in, if it were to run on most cards.

Hi Ostsol,

as already stated, client memory is system memory. So just point your gl*Pointer calls to your vertices (prolly an array of structs). That’s it, then you can start calling glDrawElements.

Ah, thanks! I’ll look up compiled arrays!

Originally posted by Ostsol:
Ah, thanks! I’ll look up compiled arrays!

be careful when you are using them. not all vertex format are accelerated (see nvidiasdk- performanceFAQ). usually, there is at least acceleration for the vertexformat used in quake3…

[This message has been edited by AdrianD (edited 02-20-2003).]

Hmm. . . I’m using an ATI card. . . Will the info in the NVSDK still apply?

That performance FAQ AdrianD referred to is over two years old and incredibly outdated. NVIDIA took it off their site for this very reason.

Apart from things like memory usage and data alignment, I wouldn’t worry too much about the impact of your vertex layout on performance.

– Tom

Ok, someone said it is ok to call glvertexpointer once in the initialization period and then draw each frame without doing that again. Is that ok to do with Multiple meshs, as well as meshes that move each frame? Or will that not work??