Jump to content
  • Advertisement

Archived

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

HellRaiZer

Vertex Arrays or Vertex Programs???

This topic is 5554 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
Advertisement
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
Vertex arrays are vertex data.
Vertex programs process vertex data.

Two different things.

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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!