Jump to content
  • Advertisement
Sign in to follow this  
conman

about vertex buffers

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

Hi, I'd like to know, if it is reasonable to build up a vertex buffer every frame with all objects visible in the frustum. Or has the vertex buffer creation too much overhead, so each object should be stored in a vertex buffer, and the vertex buffers of the visible objects are rendered. Maybe someone knows a good article/discussion about this topic, because all vertex buffer tutorials I know build a buffer with only one triangle, but I need to know when it's reasonable to use a vertex buffer, and where it's bottelnecks are. Thanks, Constantin

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by conman
build up a vertex buffer every frame with all objects visible in the frustum.
Or has the vertex buffer creation too much overhead

Resource creation and modifying is almost always a nasty performance hit. You **dont** want to be doing this on every frame unless you absolutely have to.

There are various tricks you can use to make resource modifying less of a hit, but even then it's never going to be as fast as not changing it.

Quote:
Original post by conman
Maybe someone knows a good article/discussion about this topic, because all vertex buffer tutorials I know build a buffer with only one triangle, but I need to know when it's reasonable to use a vertex buffer, and where it's bottelnecks are.

A lot of tutorials and sample use relatively small buffers just because they're only showing a very small and specific feature(s)...

I can't think of any particularly good articles/tutorials off the top of my head.

Using vertex buffers is a good idea - especially for static geometry it's about as fast as you can get.


For your original question, I would say go with creating a single VB at load-time with all your data, then use matrix transforms (and/or a vertex shader) to manipulate it when rendering. It's important to remember that you don't have to render all of your buffer in a given draw call.

That is, if you have 10 objects in your buffer you can render the 1st, 4th and 7th objects and ignore the rest. This means that your frustum culling can just report back a list of the models that exist on screen, and you can then just draw the necessary subsets from a single buffer - without having to compose a new one with all the objects in.

hth
Jack

Share this post


Link to post
Share on other sites
creating a new vb each frame is very bad. When you load your scene put all the static geo in a vb. Try to use as little vb's as possible. This way you avoid switching vb's.

Share this post


Link to post
Share on other sites
Quote:
Original post by conman
Thanks! see, I dodn't know that, I thought I can only render the whole buffer...

You can render any subsection you want, and if you want to be clever you can use Index buffers to make a single draw call that references any vertices in the buffer - not necessarily in one continuous block or order [smile]

Jack

Share this post


Link to post
Share on other sites
Quote:
You can render any subsection you want


I guess I do this when calling

device.DrawPrimitives( this.primitiveType, index, this.numPrimitives );

in the 2nd parameter? So I have to save the begin-index of all objects in the buffer?

Or can I actually create subsets and refer to them?
I didn't find a function in the VertexBuffer class doing this.

Thanks,
Constantin

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!