Jump to content
  • Advertisement
Sign in to follow this  
Juksosah

VertexBuffer 'correct' usage

This topic is 4163 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 created a quad class which consist of creating a vertexBuffer with 4 vertex in it and setting a texture. If in my scene i have 20 textured quads (each one with a different texture), created with my quad class, I will have 20 vertexBuffer. I'm locking/unlocking once at initialisation. I think it's wrong but it's so simple to do it that way. Any ideas if it will hurt a lot my performance ?? If so is there any workaround ? Remember I'm a begginer so KISS (keep it simple, stupid) [Edited by - Juksosah on April 22, 2007 12:15:10 PM]

Share this post


Link to post
Share on other sites
Advertisement
If your scene consists of only 20 quads, any optimisation would really be overkill ...however [smile]

Assuming all your quads share the same vertex format, you could use a single vertex buffer. Then when drawing a quad you can just use an offset into the vertex buffer instead of a unique buffer per quad.

As you have a unique texture for each quad, you are looking at 20 draw calls anyway. However, you could maybe pack those textures together into one larger texture and modify the quad's texture coordinates to reflect where the packed texture is. This would allow you to reduce your draw calls as you would have fewer texture changes.

Regards,
ViLiO

Share this post


Link to post
Share on other sites
Quote:
Original post by ViLiO
If your scene consists of only 20 quads, any optimisation would really be overkill ...however [smile]

Assuming all your quads share the same vertex format, you could use a single vertex buffer. Then when drawing a quad you can just use an offset into the vertex buffer instead of a unique buffer per quad.

As you have a unique texture for each quad, you are looking at 20 draw calls anyway. However, you could maybe pack those textures together into one larger texture and modify the quad's texture coordinates to reflect where the packed texture is. This would allow you to reduce your draw calls as you would have fewer texture changes.

Regards,
ViLiO


Wouldnt yuou have the same number of draw calls, but fewer texture changes?

Edit: btw, I didnt mean to sound corrective- I really want to know bnecause I've been doing that and calling multiple draw calls but only one texture set

Share this post


Link to post
Share on other sites
Quote:
Original post by Crazyfool
Wouldnt yuou have the same number of draw calls, but fewer texture changes?
I probably didn't explain it very well [wink]

So, let's say you have 20 textures, all 256x256 and you pack those into 5 textures which are all 512x512. You also modify the texture coordinates on the quads as they will no longer be going from 0.0->1.0, but 0.0->0.5, 0.5->1.0 etc. depending on where the texture they used was packed into the larger textures.

Then, with your quads sorted by texture (there are only 5 textures now), you can bind one of those 5 textures and draw the 4 quads that use it with a single draw call.

All the best,
ViLiO

Share this post


Link to post
Share on other sites
I understand very well thanks.

Less draw calls = more performance.

But I wonder about the complexity of managing a single vertex buffer. 'Sorting' the quads, what to do if one of the quad in the buffer stops being rendered ? You'll have a waste of vertex coordinates in your buffer ?

Damn it looks complicated...
Any article or good reference on this subject ?

Maybe the time used for managing the buffer >= the time for a draw call...

Share this post


Link to post
Share on other sites
Something like that. There are several solutions to the problem you're facing next, when using a single vertex buffer (VB). Remember though, that using a single VB is still advised to short-circuit vertex traffic between CPU and GPU). Here's a possible answer:

Simply determine which quads you would like to draw, memorize their offsets into the vertex buffer and draw them using multiple draw calls. There are some possible optimizations too. You could for example use a single draw call when offsets nicely line up. For example:

you have a VB filled with four quads, each quad aligned to a n-byte boundary. So the first quad is found at offset 0, the second at offset n, and so on. If you now decide to draw the first and last two quads, you could do this using three draw calls, each with an offset, drawing one quad. Or, you could do this using two draw calls:

draw 1 primitive, starting at offset 0
draw 2 primitives, starting at offset 2.n

You could group primitives that need not be sorted, use index buffers, etc.

Also, note that although we're talking about just one VB, it doesn't have to be this simple. However, static geometry should be packed in static VBs. And then there's (vertex) shaders.

Plus, you are not wasting memory when some primitives don't get rendered one particular frame. The cost of updating a VB each frame could outweigh the memory footprint easily.

Share this post


Link to post
Share on other sites
Thanks todo for your clear and simple post.

I just need an example of 'static geometry' : Is a HUD or game menu static geometry ?

Share this post


Link to post
Share on other sites
Depends what part of the HUD or menu you are referring to and how you want to present it (animated or not). I was thinking more along the lines of the actual static (as in non-movable, perhaps non-interactive) level geometry. For example, a simple 6 sided room, with 8 vertexes.

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!