Archived

This topic is now archived and is closed to further replies.

Vertex Arrays or Vertex Programs???

This topic is 5336 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

From the speed point of view, which is the best??? Because vertex arrays wants a lot of preproccessing before using them with the right way (sort model''s triangles, according to texture used, etc...), and the need more memory for fast processing, can vertex programs be a solution to this??? I mean, combination of speed and easy usage??? Thanks in advance... and sorry for my english!!! HellRaiZer

Share this post


Link to post
Share on other sites
How do you intend to actually pass the vertices to OpenGL if you only want to use vertex programs? Immediate mode or display lists? But neither is likely to use less memory or require less precalculations than vertex arrays to be used efficiently. A vertex program is useless if you don't pass vertices to it, and vertex arrays is a pretty good way to pass vertices.

[edited by - Brother Bob on May 5, 2003 9:36:29 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by Brother Bob
How do you intend to actually pass the vertices to OpenGL if you only want to use vertex programs? Immediate mode or display lists? But neither is likely to use less memory or require less precalculations than vertex arrays to be used efficiently. A vertex program is useless if you don''t pass vertices to it, and vertex arrays is a pretty good way to pass vertices.

[edited by - Brother Bob on May 5, 2003 9:36:29 AM]


there might be a way, but i doubt he wants a whole procedurally world thats calculated in vertex programs every single frame.. let alone finding a function that will give the right results.. you''d need very skilled mathematicians instead of level designers ,-)

Share this post


Link to post
Share on other sites
Vertex buffers or vertex arrays come before the vertex program. The buffers feed the vp with verts. You have to have both of them included in your code. The only difference between vb and va is that vb are more efficient for large batches of vertices while va are more efficient for small batches. Having lots of small vb that you create/destroy each frame incurs an overhead probably more so than sending your verts to the gpu thru va. If you don''t have static data then the best is to create one large dynamic vb and stream your verts into it each frame rather than creating/destroying vbs each frame. You should probably sort your polys by texture and stream poly verts into the vb for all dynamic brush objects. Static brushes should go into a static vb, lock once, fill and unlock then render many times. Look for arb vertex buffer object extension as this is what you want to use unless you prefer ihv specific paths.

Share this post


Link to post
Share on other sites
quote:
Original post by Trienco
there might be a way, but i doubt he wants a whole procedurally world thats calculated in vertex programs every single frame.. let alone finding a function that will give the right results.. you''d need very skilled mathematicians instead of level designers ,-)


You can''t generate vertices in a vertex program, only modify existing vertices. So at least you will have to provide dummy vertices for the vertex program to process, and how do you do that? Through vertex arrays?

Share this post


Link to post
Share on other sites
Hello again... and sorry for the confusion!!!!!

Ok lets rephrase the initial question...

I have some kind of a rendering engine, which is capable of rendering multitextured triangles. The default procedure for rendering a triangle, as you already know, is the following.

// texture binding is assumed...

Begin(TRIANGLES);

MultiTexCoord2fARB(TEXTURE0_ARB, Tex1.UV[0].u, Tex1.UV[0].v);
MultiTexCoord2fARB(TEXTURE1_ARB, Tex2.UV[0].u, Tex2.UV[0].v);
Vertex3f(Vert[0]->x,Vert[0]->y,Vert[0]->z);

MultiTexCoord2fARB(TEXTURE0_ARB, Tex1.UV[1].u, Tex1.UV[1].v);
MultiTexCoord2fARB(TEXTURE1_ARB, Tex2.UV[1].u, Tex2.UV[1].v);
Vertex3f(Vert[1]->x,Vert[1]->y,Vert[1]->z);

MultiTexCoord2fARB(TEXTURE0_ARB, Tex1.UV[2].u, Tex1.UV[2].v);
MultiTexCoord2fARB(TEXTURE1_ARB, Tex2.UV[2].u, Tex2.UV[2].v);
Vertex3f(Vert[2]->x,Vert[2]->y,Vert[2]->z);

End();

Now, there are two options to "optimize" this. As far as i know, at least!!!! I want only ONE of them!!!

Let''s look them independently.

1) Using vertex arrays (DrawArraysEXT, etc.), avoiding the above 11 function calls and doing it with maximum 3 calls. To function calls to setup triangle''s vertex and tex coord lists, and one for drawing the array. The rest of the process is the same as normal. No vertex program so far!!!
All vertex data, passed through vertex arrays, are processed by the default OpenGL pipeline.

2) Using vertex programs, bypassing parts of the default OpenGL pipeline (lighting, etc.), that aren''t used, and speeding up the process!!! Someone replied, "And how do you suppose to pass vertex info to vertex program?". The answer is, using the code above!!! I mean, using Vertex3f, etc. (I haven''t used any vertex program, and i don''t know how to do it, but i think that Vertex3f can work fine with VPs. I think that vertex arrays, aren''t required, in case to use a VP!!! If i''m wrong please correct me! I''d be glad to learn something on the mysterious VP programming!!!)

I know that combining the two procedures, can significantly improve speed, but i asked, which is the best, for using it alone!!!

I hope that made it more clear! I hope...

Thanks again.

HellRaiZer

Share this post


Link to post
Share on other sites
Lighting is enabled by caling glEnable(GL_LIGHTING); If you havn''t called that, you arn''t performing light calculations!
VP is efficient if you have GF3 up & want to perform lighnting on GPU, GF2 has vp emulated on CPU through the driver!

Use vertexarrays + tristrips for complicated geometry, that''s the fastest possible method (vbo/va) could be faster, but they remove AGP transfer mainly!

BTW, could someone tell me what was syntax for texture pointers when using multitexturing? glMultiTexCoordPointer0, glMultiTexCoordPointer1 etc.?

______________________________
Madman

Share this post


Link to post
Share on other sites
You still don't get it

1.) A vertex program will NEVER be faster than the fixed function pipeline (but can be as fast on modern hardware)
2.) OpenGL immediate calls are slow, it doesn't matter if you use vertex programs or not
3.) You NEED to use vertex arrays or better something like nVidia VAR/ATi VAO or ARB_VBO to achive good performance. There is no way around that with the use of vertex programs

[edited by - novum on May 6, 2003 9:28:53 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by Brother Bob
You can't generate vertices in a vertex program, only modify existing vertices. So at least you will have to provide dummy vertices for the vertex program to process, and how do you do that? Through vertex arrays?


quite a shame.. there would be lots of situations were one would prefer to just generate them on the fly. but as they seem to work in a quite simple way (one in, one out).. bad luck ,-)

oh. and if you really care about performance.. forget the fact that glvertex exists..

[edited by - Trienco on May 6, 2003 9:42:57 AM]

Share this post


Link to post
Share on other sites
If you care about performance even the smallest bit, completely forget about immediate mode and go for vertex arrays. Efficient use of vertex arrays completely outperforms even the most clever use of immediate mode.

As noVum said, the use of vertex program is not going to make immediate mode efficient. So if you only want one of them, you want vertex arrays. Immediate mode should never even be an option.

Share this post


Link to post
Share on other sites
the simplest vp you could get away with would just transform the incoming verticies.


!!ARBvp1.0
ATTRIB vertexPosition = vertex.position;

TEMP transformedPosition;

DP4 transformedPosition.x, state.matrix.mvp.row[0], vertexPosition;
DP4 transformedPosition.y, state.matrix.mvp.row[1], vertexPosition;
DP4 transformedPosition.z, state.matrix.mvp.row[2], vertexPosition;
DP4 transformedPosition.w, state.matrix.mvp.row[3], vertexPosition;

MOV result.position, transformedPosition;

END


I don''t know if it will be any faster than the standard pipeline stage (Which most likely just does the same thing, assuming that you have GL_LIGHTING, etc... disabled). You must supply the vertex data in one way or another since number of incoming verticices == number of out going verticies (as was stated earlier).

Share this post


Link to post
Share on other sites
Trienco:
oh. and if you really care about performance.. forget the fact that glvertex exists..


I just wanted to futher support this statement. It might be the single most important statement a newbie openGL coder could ever remember.


Share this post


Link to post
Share on other sites
quote:
Original post by _Madman_
BTW, could someone tell me what was syntax for texture pointers when using multitexturing? glMultiTexCoordPointer0, glMultiTexCoordPointer1 etc.?


glActiveTexture(GL_TEXTURE2_ARB);
glTexCoordPointer(...);
glActiveTexture(GL_TEXTURE1_ARB);
glTexCoordPointer(...);
glActiveTexture(GL_TEXTURE0_ARB);
glTexCoordPointer(...);

Share this post


Link to post
Share on other sites
Thanks for the replies!!!

I''ll try to forget everything about glVertex3f, and "convert" my rendering to vertex arrays!! I''ll leave vertex programs for now...

Thanks again!

HellRaiZer

PS. BTW does anyone know how i can use WGL_ARB_pixel_format? It is a little complicated, because you have to have a HGLRC before getting any extensions, and if you have a rc, then you already have a pixel format. I tried it, by creating a temporary window, but when i tried to get every pixel format supported, the returned value was zero!!!!! Do you have any idea???

Thanks.

HellRaiZer

Share this post


Link to post
Share on other sites