Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 5 of 5

Thread: Rendering many 2D texture quads

  1. #1
    Junior Member Newbie
    Join Date
    Jan 2013
    Posts
    3

    Rendering many 2D texture quads

    I'm creating my own graphics engine (for educational purposes), in which I'd like to render hundreds of texture quads in a 3D world. I'm new to OpenGL, but have followed multiple tutorials on the subject. I have a "decent" understanding of what I'm doing. However there is just one aspect I can't seem to grasp, correct use of VBOs.


    These are the following ways I've thought of using them:

    1. Each textured quad(game object's renderComp) has it's own VBO containing vertex data(vertices, texture coords, colors)
    -Pros: Easy to implement, adding/removing objects to render would be as simple as creating/deleting VBOs
    -Cons: The VBOs would be so small that it'd be a huge performance hit to Bind/Draw/Unbind every VBO each frame

    2. Have one(potentially more if it fills up) VBO containing ALL the textured quads vertex data interleaved
    -Pros: Only 1 Bind/Draw/Unbind call per frame, should provide much better performance
    -Cons: I have no idea how to keep track of what vertex data belongs to which game object. I could ADD to the VBO, but have no idea how I would remove (no longer render) from the VBO. (Unless I delete, recreate the whole VBO each time I remove something).


    3. Have a STATIC VBO for objects that won't be changed i.e. Map, and have an additional VBO for objects that will be created/deleted at runtime.
    -Pros: Same as #1 with a slight performance boost (less GL calls)
    -Cons: Still more calls than I would prefer


    I feel like there is something I am missing here. Could someone fill me in?

  2. #2
    Senior Member OpenGL Pro
    Join Date
    Jan 2012
    Location
    Australia
    Posts
    1,109
    You have pretty much covered it. When you have dynamic objects you will always need secondary data to link the object to the VBO. A slight variation is to have an index buffer for dynamic objects. This way you can "delete" an object by rebuilding the index buffer removing the indices associated with the object and just leave the vertices in the vertex buffer. This can be a little quicker. You can always garbage collect the vertices if you need to. Sizing you buffers is important for the space-speed trade-off. Game engines are a little easier for this since much of the data will be static. If you have a large world you will strike a secondary problem that you cannot load all you data at once.

  3. #3
    Junior Member Newbie
    Join Date
    Jan 2013
    Posts
    3
    Thank you so much! I'm glad to know I'm at least working towards the right direction. I appreciate the vertex/index buffer idea! Once I have a prototype up and running I'll have to give it a try to see the performance boost.

    I figure even if I do have a large world, I could use a number of culling methods to fix the "cannot load all the data at once" problem. Right?

  4. #4
    Senior Member OpenGL Pro
    Join Date
    Jan 2012
    Location
    Australia
    Posts
    1,109
    I figure even if I do have a large world, I could use a number of culling methods to fix the "cannot load all the data at once" problem. Right?
    The main problem is that you will have to rebuild your static object vbos. So now you will need a more intelligent way to group objects at load time - this is usually some sort of tree structure.

  5. #5
    Junior Member Newbie
    Join Date
    Jan 2013
    Posts
    3
    Ahhhh you're completely right, thanks for putting that in perspective. I don't think my world will be THAT large, but if I encounter the issue I'll know exactly what to do! Thanks for your help!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •