I want to implement vertex arrays into my program.. Cause as of right now I am calling sin & cos every frame... a couple hundred times a frame.. so you can see that is pretty damn slow.

anyways, I have never used a vertex array before, I know that I can use glDrawArray to get the job done, but is there any other setup I need to do before making the call to glDrawArray?

also for the normals of my objects, would it be benefiicial to also store them in an array? I'd assume the time/space trade off is worth it... just a thought..

any little psuedo code examples of how you would use glDrawArrays would be awesome..

First you must enable the client state for what you want to do by calling glEnableClientState() with GL_VERTEX_ARRAY, GL_NORMAL_ARRAY, GL_COLOR_ARRAY, GL_INDEX_ARRAY, GL_TEXTURE_COORD_ARRAY, etc..

Then you pass in your arrays using the specified functions: glVertexPointer(), glNormalPointer(), glColorPointer(), etc..

And finally you draw the object.. glDrawArrays(drawMode,startIndex,numVertices)

Take a look at http://home.clara.net/paulyg/prog6.htm. It doesn't use glDrawArrays, but it shows you how to set up your app to do it.

Yes you can store normals in arrays. I have VBO's up and running and have texure, normals, vertex data all stored in VBO's!

Here is some code

HTH! And remember me on Christmas I would like a Dual G5 w/9800Pro!

glDrawElements will deliver better performance than glDrawArrays because it allows use of the card's vertex cache. You should organize your triangles into strips/fans using a library such as ACTC, but draw with GL_TRIANGLES. Don't draw with GL_TRIANGLE_STRIP because that requires multiple calls to draw a complex object and eliminates the flexibility benefit of using glDrawElements over glDrawArrays anyways. Do make sure to glLockArrays for the glDrawElements call. I'm not sure why but in my testing that gave a noticeable speed boost.

Quote:Originally posted by Muffinking
I want to implement vertex arrays into my program.. Cause as of right now I am calling sin & cos every frame... a couple hundred times a frame.. so you can see that is pretty damn slow.

I'm unclear on how these ideas are related... why do you have to call sin/cos a couple hundred times every frame?

GL_TRIANGLE_STRIP is faster than GL_TRIANGLE due to it can reduce the number of vertexes. After going with GL_TRIANGLE_STRIP I would do it over again with either GL_TRIANGLE or GL_QUADS because using GL_TRIANGLE_STRIP is a pain to setup due to the ordering of vertexes and textures coordinates.

Depending on how you store your vertices and indices, glDrawArrays with GL_TRIANGLE_STRIP can allow your geometry to pretty much fall into place with no effort.

Quote:Originally posted by Mars_999
GL_TRIANGLE_STRIP is faster than GL_TRIANGLE due to it can reduce the number of vertexes. After going with GL_TRIANGLE_STRIP I would do it over again with either GL_TRIANGLE or GL_QUADS because using GL_TRIANGLE_STRIP is a pain to setup due to the ordering of vertexes and textures coordinates.

Code is available to take a triangle mesh and produce strips. If you are drawing large primitives you can see up to three times the performance using strips and you might with meshes (if your geometry strips well and you draw in large batches). It is well worth the effort with most complex geometry. nVidia has some code that they give away for doing this.

Quote:Originally posted by Programmer
Code is available to take a triangle mesh and produce strips. If you are drawing large primitives you can see up to three times the performance using strips and you might with meshes (if your geometry strips well and you draw in large batches). It is well worth the effort with most complex geometry. nVidia has some code that they give away for doing this.

Well from what I have been told by other OpenGL programmers is the speed delta of strips isn't worth it in most cases. I am using them with my terrain engine and rendering 132k polygons each frame a 256x256 map with 5 texture units and is slow. I am also using VBO's. The 5 texture units is killing me.

Quote:Originally posted by Mars_999
Well from what I have been told by other OpenGL programmers is the speed delta of strips isn't worth it in most cases. I am using them with my terrain engine and rendering 132k polygons each frame a 256x256 map with 5 texture units and is slow. I am also using VBO's. The 5 texture units is killing me.

This will depend on how well your geometry strips and how vertex bound your system is. If you are vertex bound (due to lots of vertices or very expensive vertices, e.g. big vertex programs) then stripping is a huge win. If you are using indexed primitives then the value of stripping is reduced and you get much more value from the indexing.

Its not that hard to set up a system which runs the geometry through a stripper, and you can do other interesting things to the geometry at the same time.

Quote:Originally posted by Programmer
Code is available to take a triangle mesh and produce strips.

That would be really useful for what I am doing right now. Can you pull a link or some code out of your hat?

Quote:Originally posted by jabber
That would be really useful for what I am doing right now. Can you pull a link or some code out of your hat?

http://developer.nvidia.com/page/tools.html

Quote:Originally posted by Programmer
http://developer.nvidia.com/page/tools.html

I'd be wary about using this. There's no guarantee that this is unencumbered. ACTC has been around long enough and used in enough products without issue that it's fairly likely to be patent free.

Quote:Originally posted by inio
I'd be wary about using this. There's no guarantee that this is unencumbered. ACTC has been around long enough and used in enough products without issue that it's fairly likely to be patent free.

This is a good point -- you should always be aware of the licensing of any code that you consider using. I posted the link because it was directly requested, I'm not saying anything about the potential legal complications...

http://plunk.org/~grantham/public/actc/

Quote:Originally posted by David
(muffinking repeatedly calling sin/cos...)
I'm unclear on how these ideas are related... why do you have to call sin/cos a couple hundred times every frame?

My guess is that these are for rotation matrices. If so, then all one has to do is to calculate them once for each angle, store them, and then recall them as needed.