Jump to content

  • Log In with Google      Sign In   
  • Create Account

Why glVertexPointer is slower than glVertex??


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 Civilian_E   Members   -  Reputation: 122

Like
Likes
Like

Posted 07 January 2002 - 06:55 PM

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?

Sponsor:

#2 Lev Povalahev   Members   -  Reputation: 122

Like
Likes
Like

Posted 07 January 2002 - 11:43 PM

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

-Lev

#3 Dredge-Master   Members   -  Reputation: 175

Like
Likes
Like

Posted 08 January 2002 - 01:37 AM

it is probably because you are loosing time when you pass your values into the array which is slowing it down.


#4 Civilian_E   Members   -  Reputation: 122

Like
Likes
Like

Posted 08 January 2002 - 02:02 AM

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

#5 Civilian_E   Members   -  Reputation: 122

Like
Likes
Like

Posted 08 January 2002 - 02:27 AM

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);

}



#6 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 08 January 2002 - 03:40 AM

> 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

#7 zedzeek   Members   -  Reputation: 528

Like
Likes
Like

Posted 08 January 2002 - 07:39 AM

if your triangles are changing around a lot eg ROAM
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)

http://uk.geocities.com/sloppyturds/gotterdammerung.html

#8 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 08 January 2002 - 09:40 AM

> 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




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS