glDrawArrays

[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.

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..

[MacFiend]

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.

[Mars_999]

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

glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_NORMAL_ARRAY);
glVertexPointer(3, GL_FLOAT, nVertexStride, &terrain[0][0].vx);
glNormalPointer(GL_FLOAT, nVertexStride, &terrain[0][0].nx);

glActiveTextureARB(GL_TEXTURE0_ARB);
glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, texture[ROCK]);
glClientActiveTextureARB(GL_TEXTURE0_ARB);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glTexCoordPointer(2, GL_FLOAT, nVertexStride, &terrain[0][0].tx);

glActiveTextureARB(GL_TEXTURE1_ARB);
glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, texture[GRASS]);
glClientActiveTextureARB(GL_TEXTURE1_ARB);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glTexCoordPointer(2, GL_FLOAT, nVertexStride, &terrain[0][0].tx);

glActiveTextureARB(GL_TEXTURE2_ARB);
glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, texture[ALPHA]);
glClientActiveTextureARB(GL_TEXTURE2_ARB);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glTexCoordPointer(2, GL_FLOAT, nVertexStride, &terrain[0][0].tdx);

for(int z = 0; z < MAP_Z - 1; z++)
glDrawElements(GL_TRIANGLE_STRIP, MAP_Z * 2, GL_UNSIGNED_INT, &indexs[z * MAP_Z * 2]);

glDisable(GL_TEXTURE_2D);
glActiveTextureARB(GL_TEXTURE1_ARB);
glDisable(GL_TEXTURE_2D);
glActiveTextureARB(GL_TEXTURE0_ARB);
glDisable(GL_TEXTURE_2D);
glDisable(GL_LIGHT0);
glDisable(GL_LIGHTING);

glDisableClientState(GL_VERTEX_ARRAY);
glDisableClientState(GL_TEXTURE_COORD_ARRAY);
glDisableClientState(GL_NORMAL_ARRAY);


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

[inio]

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.

[David]

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?

[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.

[MacFiend]

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.

[Programmer]

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.

[Mars_999]

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.

[Programmer]

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.

[Josh]

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?

[Programmer]

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

[inio]

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.

[Programmer]

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/

[lpetrich]

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.

[Programmer]

Originally posted by lpetrich
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.

How many rotations do you really have? It sounds like you should have the same rotation for all the geometry, in which case you should only need to calculate one rotation matrix (which is trivial).

[deekpyro]

Originally posted by Mars_999
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!

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

woah...I thought VBO's couldn't be used in OS X until OpenGL 1.5 came out (with the proper extension).

What extension are you using then? Is it better then the one coming with 1.5?

Man...I'd pay real money (none of that monopoly shit) to setup VBOs in my game!

Thanks man,
Derek (Jesus)

[Mars_999]

Originally posted by deekpyro
woah...I thought VBO's couldn't be used in OS X until OpenGL 1.5 came out (with the proper extension).

What extension are you using then? Is it better then the one coming with 1.5?

Man...I'd pay real money (none of that monopoly shit) to setup VBOs in my game!

Thanks man,
Derek (Jesus)

Hahaha I coded my own extentsion! :wow: Nah I don't have a Mac right now sold my last one. I am on a crappy PC until I can sell it. But VBOs ROCK. If they are as good on the Mac as they are on the PC hold on.

[henryj]

Read this thread...

http://www.idevgames.com/forum/showthread.php?s=&threadid=5344&perpage=15&pagenumber=1

and then post your profile.

(ooh errr, recursive posting)

[Mars_999]

Originally posted by henryj
Read this thread...

http://www.idevgames.com/forum/showthread.php?s=&threadid=5344&perpage=15&pagenumber=1

and then post your profile.

(ooh errr, recursive posting)

Who is that for henry??

[henryj]

Muffinking and anyone else who is having performance problems.

[Mars_999]

Originally posted by henryj
Muffinking and anyone else who is having performance problems.

What about performance issues when it involves not using algorithms such as culling? I think that is a no brainer. Culling will improve performance.

[Programmer]

Originally posted by Mars_999
What about performance issues when it involves not using algorithms such as culling? I think that is a no brainer. Culling will improve performance.

It usually is, but before pursuing this as a solution you ought to be sure that more is being drawn than is appearing on screen. If everything drawn appears on screen then culling is just extra work and it doesn't save you anything.

There is often a trade-off between the cost of culling and the cost of drawing. If drawing is really cheap and culling is really expensive then it doesn't make any sense to do. In a similar vein it is important to figure out at what level to cull things -- typically culling at a low level (e.g. per triangle, as an extreme example) is far too slow.

On really fast GPU hardware it is possible that the cost of drawing everything is less than the cost of chopping the scene up into pieces in order to be able to cull it. Under OpenGL this situation is only like to be true if your drawing is not using the immediate mode draw calls.

[henryj]

What about performance issues when it involves not using algorithms such as culling? I think that is a no brainer. Culling will improve performance.

THERE IS NO SUCH THING AS A NO BRAINER. PROFILE YOUR DAMN CODE. THERE NO OTHER WAY TO TELL.


I give up.

[Mars_999]

Originally posted by henryj
THERE IS NO SUCH THING AS A NO BRAINER. PROFILE YOUR DAMN CODE. THERE NO OTHER WAY TO TELL.


I give up.

Well I have 132k polygons using VBO's and 5 texture units, I am only getting 20-30fps. That is sad. This is with a 9700Pro. I need it faster due to I haven't even put models or a particle engine in yet.