vertex array questions

[weston]

After running -Xprof on my game and finding that 79% of my time is spent in org.lwjgl.opengl.Win32Display.swapbuffers, I decided to optimize my opengl code a bit. Optimization of choice: vertex arrays.

What I'm wondering is how to use vertex arrays with lots of sprites (and particles eventually).

Can I put all the vertices from my sprites into a single FloatBuffer and then just use glDrawArrays for each sprite, giving an offset however many vertices have already been used? Or should each sprite keep its own FloatBuffer of points (and tex coords etc.) and then I use glVertexPointer for each sprite?

I'm primarily concerned with just making it work at this point, but I'd certainly be interested in hearing about which way would be better for whatever reasons.


Also, am I going to see much of a performance difference by using vertex arrays? I created a test app that renders 810,000 points and I get exactly 14 fps with and without vertex arrays... is that expected or am I doing something wrong?

[tom]

Use a single vertex array and draw ALL your sprites using ONE call to glDrawArrays. That means all sprites need to be in the same "space". So you need to transform the sprites manually and store the world coordinates in the vertex array.

[weston]

hmm, does this mean I need to rotate the vertices and texture coordinates manually as well? I'm not even sure I know how to rotate the texture manually... So assuming I can just rotate the texture coordinates the same way I do the vertices, is trig going to be too slow for this? I don't know any matrix math yet, but is that how this would generally be accomplished?

Games published by our own members! Check 'em out!

[tom]

Yes you have to rotate the vertices yourself. You only need to change the texture coordinates if you are using the texture matrix. They texture will stick to the goemetry when you move the vertices.

What math you need to use depends on what your rendering. Do you do 2d sprites, 3d geometry, billboards (sprites that always facing camera). They all use different math.

Java trig is known to be slow but it will be faster than drawing each sprite one by one.

[weston]

ok, I've got this mostly working (after spending much time reading a 3d math book :-/ ). However, I see a problem with just using one call to glDrawArrays(). I use a per vertex lighting system that effects my sprites so some of them have been tesselated, this means that I have to use GL_TRIANGLE_STRIP instead of GL_QUADS. Because of this, opengl won't know when one sprite's geometry ends and another starts. Does this mean I am going to have to use a call to glDrawArrays for each sprite? If theres another solution for this kind of problem, I'd love to hear about it

[weston]

I have another question that may be a little bit off this topic... Using vertex arrays I can draw 800 texture mapped quads at about 75 frames per second, the program does nothing else. If I were to write a particle system it would probably use this same approach, vertex arrays with texture mapped quads. Now a particle system that that draws can only draw 800 particles while mainting a decent framerate seems pretty bad to me. So I tried decreasing the size of the quads to about 10 unit squares, this actually gave me a large boost in framerate. With quads this size I can draw about 2500 while maintaining 75fps. What I'm wondering is why having larger geometry makes such a big difference on the framerate and what sort of optimization I would need to use in order to speed that up. Also, being able to draw 2500 quads is certainly better, but still seems a bit low to me. What other sorts of optimizations can I make to speed this up?

edit: ok, I should have checked my profiler but I just assumed the bottleneck would be the same thing with a different number of quads (oops). Turns out that the bottleneck is Matrix4f.load()... followed by my transformVertices() method. If anyone has an example class that uses matrices for transforms I'd like to see it I'm not really sure how this should be done, I just learned how to do the math and other than that I have no experience with the subject.

[Orangy Tang]

Some notes:

- Your initial 'bottleneck' of 79% in swapBuffers was probably not a bottleneck, but actually your app waiting for the next vsync.

- Graphics cards like nice big chunks of geometry at a time. Stuff like immediate mode (glBegin etc.) and small vertex buffers (less than 100 verts) are all far to small to be efficient. So you've basically got to batch things up into as big a group as possible - which usually means making compromises like sticking to one texture or geometry type.

- Ideally your CPU wouldn't even touch individual vertices, but for a particle system thats pretty much unavoidable.

- State changes (like binding textures, matrix stack stuff) can be costly as well, so try and avoid them where possible.

- Larger particles mean more pixels touched, which basically means a greater fillrate required. Theres no easy way around this, but if you add alpha testing to low-alpha values that can help some.

[tom]

ok, I've got this mostly working (after spending much time reading a 3d math book :-/ ). However, I see a problem with just using one call to glDrawArrays(). I use a per vertex lighting system that effects my sprites so some of them have been tesselated, this means that I have to use GL_TRIANGLE_STRIP instead of GL_QUADS. Because of this, opengl won't know when one sprite's geometry ends and another starts. Does this mean I am going to have to use a call to glDrawArrays for each sprite? If theres another solution for this kind of problem, I'd love to hear about it

You can use GL_TRIANGLES instead. You will have to dublicate a lot of vertices and that will increase the amount of data transfered to the card. It might slow you down, but is better that making a call to glDrawArrays for each sprite.

Or you can use indexed arrays. Then you can draw with GL_TRIANGLES without dublicating the vertex data. It's the indexes that is dublicated instead and they are only 4 (possibly 2?) bytes per vertex.

[weston]

about spending 79% of the time on swap buffers, I didn't have vsync enabled although I still was pausing (for a very small amount of time) in my game loop, I used something like sync2(1000).

There is still one more thing that I'm confused about. Is it really going to be slower using something like glTranslate() than transforming the vertices myself? How I had it set up initially was that every sprite just translated itself (using glTranslatef()) before rendering instead of actually changing the vertices. If I were to do this then I would have a very small number of unique vertices and either way every sprite needs to be transformed. How is it more efficient for me to multiply every vertex by the transform matrix myself instead of letting opengl do it? I know that I can load the matrix into opengl using glMultMatrix, but I thought I was supposed to give the 'world space' coordinates to opengl when using glDrawArrays(), is that true?.

Also, lookes like I'll be switching to indexed arrays with GL_TRIANGLES, don't know why I didn't think of just using triangles instead of a triangle strip...

[tom]

There is still one more thing that I'm confused about. Is it really going to be slower using something like glTranslate() than transforming the vertices myself? How I had it set up initially was that every sprite just translated itself (using glTranslatef()) before rendering instead of actually changing the vertices. If I were to do this then I would have a very small number of unique vertices and either way every sprite needs to be transformed. How is it more efficient for me to multiply every vertex by the transform matrix myself instead of letting opengl do it? I know that I can load the matrix into opengl using glMultMatrix, but I thought I was supposed to give the 'world space' coordinates to opengl when using glDrawArrays(), is that true?.

It is not faster to transform the vertices yourself. But when all the vertices are in the same space they can be drawn using one call to glDrawArrays(). Instead of one call for every sprite. Doing the transformation yourself is a compromise you do to get the speed increase of batching up geometry.

The vertices don't have to be world space. But they do have to be in the same space since they are all rendered with the same matrix.

To sum up, assuming you are geometry limited and not filrate limited (you spend more time transfering vertices to the card than actually rendering):
few calls to drawArrays - good
many calls to drawArrays - bad

Games published by our own members! Check 'em out!

[weston]

ok thanks for the help, I think I have a much better understanding of the situation now