Sign in to follow this  
derek_of_bodom@hotmail.com

Frequently setting data to a vertex buffer?

Recommended Posts

I'm using Xna 3.1, and I want to use a vertex buffer that can be "cleared" when a certain event happens, then data can be put into it. I don't know what the difference between a DynamicVertexBuffer and the regular VertexBuffer would be. I'm really unsure of how I should go about using the VertexBuffer. I was thinking that I could use a static array with a fairly large size to set the vertex data, then transfer that array to the vertex buffer.
So which VertexBuffer type should I be using?

Share this post


Link to post
Share on other sites
bullfrog    481
Dynamic vertex buffer tells the graphics card to store the vertices in the best possible place in memory to be written to every frame or multiple times every frame.

Static vertex buffer tells the graphics card to store the vertices in the best possible place in memory to be rendered only and not updated regularly.

Use the static buffer if you’re not updating every frame, perfect for your event system if it doesn't trigger every frame. Otherwise use dynamic buffer.

Static buffer rendering > Dynamic buffer rendering
Dynamic buffer updating > Static buffer updating

Share this post


Link to post
Share on other sites
bullfrog    481
Graphics cards have lots of memory, so it depends on how much you need.

If you vertices are 24 bytes each (Thats x, y, z positions, texures coords and diffuse), you can store over 400,000 vertices with 10MB of video memory.

Creating a buffer big enough will save programming time and lag spikes.

But in the end, you need to make what you need to make, to make your game : )

Share this post


Link to post
Share on other sites
[quote name='bullfrog' timestamp='1333936156' post='4929435']
Graphics cards have lots of memory, so it depends on how much you need.

If you vertices are 24 bytes each (Thats x, y, z positions, texures coords and diffuse), you can store over 400,000 vertices with 10MB of video memory.

Creating a buffer big enough will save programming time and lag spikes.

But in the end, you need to make what you need to make, to make your game : )
[/quote]
I understand that bit, but I'm wondering if the buffer needs to be initialized with the predicted size, or if I could initialize it with 0 and put data into it. I don't really think that's how it would work, but it would definitely be memory efficient like that.

Share this post


Link to post
Share on other sites
bullfrog    481
.I do not know how XNA works, but if it follows the directx API, you will need to specify the size of the vertex buffer. If you post the function for creating the buffer I will be able to tell you.

Having wasted memory with vertex buffers is not uncommon. I would set the vertex buffer size to the maximum size that the buffer can reach during the game life time. But then again, that might not work with your game. Up to you!

Share this post


Link to post
Share on other sites
NEXUSKill    475
XNA is largely a wrapper for the windows api, .net framework and direct x, as far as rendering goes you can assume it will follow at the very least DirectX 9 API.
Granted since it is a wrapper certain things may be left out or wrapped in such a way that some of the real API flexibility is lost.

As for the buffer, its a balance problem, ideally you want the buffer to be tightly sized to the number of vertexes/indexes it will be handling, however, if the buffer's purpose is to host a highly changing set of primitives with unpredictable additions and removals, it would have to be constantly resizing to fit or contain the new number of elements, which is not efficient since the creation and assignation of a vertex buffer also carries some overhead.
The most frequent approach to this kind of problem is to allocate the buffer with a fixed capacity, and have the limit be retrieved from a config file or some other non compiled source. Then you run tests on your application to establish the most likely safe limit for vertexes for that particular application and set that number by the config source.
This allows you to set two different limits for two different applications without having to rewrite the functionality, and also allows you to contemplate hardware profiles, different graphics cards will have different memory capacities, and a limit that works well for one card might be too high or too low for another card, with a config driven limit you can have different configurations for each hardware profile and adapt your application to this upon execution.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this