Skip to main content
gamedev.net
🔒 Locked

Efficient Vertex Buffer Usage

Started by Radons Jun 14, 2010 at 7:04 AM 5 replies 1.2k views
Original Post
Radons
Radons
Hello, I'm making a really simple top down game that uses boxes to make up the map. I can put the entire map into one vertex buffer object sorted by material and then render the data per material. However, this renders the entire map, so a lot of power is wasted. I'm looking for an efficient way to store the data to render only what is visible. The map consists of a grid of boxes of arbitrary heights, I can figure out my start x and start y, so I can access some array with data on what to render. But I'm kind of stuck there. Also, each face of the box can have a different texture.. Should I use some kind of tree system? (octree or something similar?) I don't know much about these yet.

Here's an example map with numbers are just heights. The stars indicate my viewport position.
11111111111111111111111122111*******1222211422211*11211*1221325551111*12231*1337432451111*11132*3112111111111*******111111111111111111111111

Anyway, thanks for reading. Hope you can help me out! :-)
Gage64
Gage64
I think the basic setup should be something like this:

find all potentially visible boxesadd them to a collection of some kind (e.g., a dynamic array)sort the collection by materialrender all boxes in collection, changing render state only when necessary


If different faces can have different textures, you'll need to treat each box as a collection of faces and not as a single object. Then in the sorting phase, you sort the faces, not the boxes.

BTW, such a collection if often called a Render Queue.
Radons
Radons
Hi, thanks for the reply. To a certain degree I understand what you're aiming at. I know how to figure out which faces are visible and how to sort them by material. But this way I don't know how to actually draw them efficiently. My data is stored in one vertex buffer object at the moment. Let's say the faces are sorted and ready to be drawn. I'd need to draw like this:

for each collection  set_material(collection->material)  for each face in collection    draw_indexed_face(face->index_start)


Is that a good way to go? It looks like a lot of draw calls to me?
Evil Steve
Evil Steve
Well, you can draw all of the faces that share the same material in one draw call if you write them into a dynamic vertex buffer every frame (Or, have one large static vertex buffer and use a dynamic index buffer). That reduces the total number of draw calls to one per material.
Radons
Radons
That's what I was aiming for. Though, doesn't that have more overhead then those extra draw calls? Or is this too difficult to tell without profiling? Thanks.
Evil Steve
Evil Steve
Quote:
Original post by Radons
That's what I was aiming for. Though, doesn't that have more overhead then those extra draw calls? Or is this too difficult to tell without profiling? Thanks.
It depends really. If you end up using 100 draw calls to render your whole map, then it may be faster to just do that. If you're going to end up with a few hundred draw calls, then you'll probably be faster to go for a dynamic VB that's filled every frame.

If in doubt, go for the simplest option and see what the performance is like, then you can always change it later.
Radons
Radons
All right, I'll give it a whirl and see where I end up. Thanks for the explanation!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.