Jump to content
  • Advertisement
Sign in to follow this  
Hedinus

OpenGL Quicker? Submitting Geometry vs Altering Modelview Matrix

This topic is 2806 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

I am currently developing a game for the iPhone (only consider OpenGLEs 1.x at this point for the game).

I have many simple textured quads that I would like to render at one time.
The quad locations and rotation are fixed and will at most need to be dynamically skewed.

Is it faster to submit unique vertex arrays for each quad, or should I push and pop the matrix stacks, only submitting the geometry once?

Thanks for any replies.

Share this post


Link to post
Share on other sites
Advertisement
Matrix stacks work quite well. On iOS devices you should definitely submit geometry buffers only once, unless you do something special like deformable meshes, etc. The reason is because some of that stuff could get converted to fixed point math internally, depending on the GL profile, which obviously could be a significant performance hit. I suggest you to plan on how you want to represent the entire scene and how you want to render it with minimal draw calls. If you limit your draw calls as much as possible then the number of matrix stack operations will also decrease.

Share this post


Link to post
Share on other sites
After running some tests for the game, I will be making the quads more animated (having the quads' top bounce and sway).

An idea popped up while working to pass a contiguous array of vertices (each quad owning their own set) to the GP once.
Should I still just mess with the matrix stacks or just have single array of vertices?


Thank you both for the replies. You've just helped me on deciding another portion of the game.

Share this post


Link to post
Share on other sites
An idea popped up while working to pass a contiguous array of vertices (each quad owning their own set) to the GP once.
Should I still just mess with the matrix stacks or just have single array of vertices?[/quote]
Not sure what you mean by that... could you elaborate?

Basically the idea is that if you have a model of an object, say a donut, you buffer it to GL once as a VBO. To render the donut, you use the modelview matrix to scale, translate, and rotate to the appropriate position. To render many donuts in different positions, you use the same VBO, but with different modelview matrices. When dealing with many types of models (say, a sphere, a cube, a cat, a dog), you create a VBO repository of those objects (but no duplicates of the same mesh), and draw them using the method I outlined before.

Sometimes it makes more sense to combine models and a single VBO to render them in a single draw call. For instance, if you have 100 donuts spilled onto the floor (that look the same), it would be more efficient to combine them into a single vertex pool and create VBO for that group, which in turn you can use a single matrix and one draw call to render.

Share this post


Link to post
Share on other sites
[color="#1C2837"]

An idea popped up while working to pass a contiguous array of vertices (each quad owning their own set) to the GP once.
Should I still just mess with the matrix stacks or just have single array of vertices?[/quote]

[color="#1C2837"]Not sure what you mean by that... could you elaborate?
[/quote]

The idea that I had would be to submit a number of vertices to render a bunch of quads, the vertices of which were modified for animation each frame before passing the data to the GP.

In a previous game I had similar geometry for a number of objects. I would pass the geometry in once and modify the GP matrices for each object.
I didn't need to worry so much about speed in that game. This time around I want to make sure I can draw hopefully hundres of graphic elements per frame while still keeping a good frame rate.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!