I hv an animated mesh in which the vertex positions are required to be modified from time to time. Initially i tried to call glVertex for hundreds times per frame, but now i try to modify a vertex array''s content and then re-sumbit it to be rendered by glDrawArrays. To my surprise, i get a 20% framerate loss for this! Can anyone tell me what i hv done wrongly?

hmm, some code might help - can you post your rendering loop? (if its not 100k)

-Lev

So it means that glVertexPointer should not be used for non-static vertex data?

This is a simplified version of my rendering function:

Mesh::Draw(){
// To build up a new transformation matrix
animate();

int tcount=0, ncount=0, vcount=0;

//some code to bind texture
...

//glBegin(GL_TRIANGLES)

for (int i=0; i< numVertices; i++ ){

newNormal.set( currentNormal );
FinalMatrix.transform( newNormal);
newNormal.normalize();
newVertex.set( currentVertex );
FinalMatrix.transform( newVertex);

//glTexCoord2f(s, t);
//glNormal3fv( newNormal.get() );
//glVertex3fv( newVertex.get() );

Tex[tcount++] = s;
Tex[tcount++] = t;

Nor[ncount++] = newNormal[0]; // overloaded operator[]
Nor[ncount++] = newNormal[1];
Nor[ncount++] = newNormal[2];

Ver[vcount++] = newVertex[0];
Ver[vcount++] = newVertex[1];
Ver[vcount++] = newVertex[2];

}
// glEnd();

glTexCoordPointer(2, GL_FLOAT, 0, Tex);
glNormalPointer (GL_FLOAT, 0, Nor);
glVertexPointer (3, GL_FLOAT, 0, Ver);

glDrawArrays( GL_TRIANGLES, 0, numVertices);

}

> So it means that glVertexPointer should not be used for non-static vertex data

Depends, on how you update your vertex array data. Your VA populating code is rather slow, so you will loose performance here. Generally, VAs are faster than individual glVertex() calls, if you cache your VAs (don''t rebuild them each frame, or update *only* the modified parts).

If you have an nVidia based 3D chipset, you should definitely check out the VAR/fence transfer modes for dynamic geometry, you can''t get faster than those (even CVAs are slower). They are a bit tricky to handle, though.

- AH

> begin + end might be the quickest way even faster than VAR (though i havent tested this but I have word from other developers that this is so)

No.

Internally, the same transfer mechanisms are used, but: begin+end use system RAM, VAR use AGP DMA memory (if you ask for it), and you got the additional function call overhead for begin & end. Other than that, they transfer the same data types over the AGP bus. Not to forget, that VARs (being a form of VA) will pass through the vertex cache of the GPU, reusing shared vertices. Begin + end does not.

VAR''s will *always* be faster than begin + end, no exceptions. One can discuss the speed differences on static geometry compared to CVAs in video memory (although nVidia says, VARs beat CVAs), but definitely not begin & end.

Developers that experienced something else did something wrong while using VARs. As I said, it''s rather tricky to use them correctly: AGP mem (not system, nor video RAM), asynchroneous fencing, interleaved arrays, good caching behaviour of your index data, etc.

But you''ll never beat the speed of a well coded VAR.

- AH