Vertex Buffer

Started by
3 comments, last by Jason Z 10 years, 5 months ago

Hi,

I want to know if it is better to have 1 Big Vertex Buffer or many small Vertex Buffers.

I give an example:

I want to draw simple scene:

Terrain, Enemy and my Charater

It's better to divide vertices into three VS or use one?

I know that, if my objects have a few Vertices it is better to join them together, but what about objects which have many Vertices? What is many?

When I should use VS which has many objects inside?

Thanks for advice!

Advertisement

This gets the standard answer: It depends. You need to try it out both ways and see which one works better for your situation. If you are just using this for your particular laptop, then your driver, GPU, CPU, memory speed, etc... all play into the equation. You are essentially trading many buffer setting operations for many buffer data copy operations, and that may or may not help in a given system.

My advice is to design your renderer so that you can swap in and out the implementation easily - don't back yourself into a corner by hardcoding your rendering routines!

I've created only small projects(max ten objects in the scene) and result is basically the same.

I've used FPS to compare Scenes. Is better solution to compare?

My advice is to design your renderer so that you can swap in and out the implementation easily - don't back yourself into a corner by hardcoding your rendering routines!

Can you give an example, please? I can't imagine it.

In my experience, everything that is static is best in a single static buffer. No matter how big it is but my dataset is minuscule by today' standards, we're talking about 100k vertices total.

This comes with a considerable con: if you drop the buffer in PIX... it will often look like garbage.

I now do one buffer for each "compatible" set of vertex formats. Performance hasn't changed significantly and I get my clean debug output, I like it so much.

I've read a relatively recent AMD paper about GCN in which they stated the driver has an internal scratchpad buffer about 4MiB for dynamic buffer update. I don't remember if this was the suggested dynamic buffer size or the upload size.

In general, do whatever you find easier. Don't be afraid to iterate once you have better problem understanding.

Previously "Krohm"


Can you give an example, please? I can't imagine it.

What I mean is that you will probably have some object which represents each of your high level objects (Terrain, enemy, player, etc...). This objects need to have some way of providing information to your renderer about how they should be rendered. You should make this part of your design flexible, and allow it to be used by individual buffers, or alternatively in one larger dynamic buffer. To your high level objects, it should be totally transparent which system is being used - so whatever interface they use to specify their vertices should be common for both ways.

If you design it properly, you can completely generalize the rendering mechanism so that you can swap in or out various representations very easily. It isn't simple to do this, but after some effort you should be able to find a suitable solution. I strive for this design in Hieroglyph 3.

This topic is closed to new replies.

Advertisement