Archived

This topic is now archived and is closed to further replies.

vertex buffer sizes

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

why do you have to give the vertex buffer a size when you create it? how are you gonna know how many vertices you need to draw something when you have a dynamic world with all kinds of stuff loading/unloading etc. etc.??

Share this post


Link to post
Share on other sites
If you have a really dynamic world, then just keep resizing the VB when you need new space.

For example (very roughly):

You created a VB (m_vb) with "num_total_vertices" vertices.
At the moment it has "num_active_vertices" in it.
You wish to add "num_add_vertices".

if (num_active_vertices + num_add_vertices > num_totalvertices)
{
num_total_vertices *= 2; // increasing by factor of 2 is good
m_vb = new VertexBuffer(num_total_vertices);
dest = m_vb.Lock()
my_local_copy_of_vertices.CopyTo(dest);
m_vb.Unlock()
}

// Fill vertices as you normally would, starting at num_active_vertices

You would need a local copy of all the vertices in your buffer, which will take system memory. I think you also shouldn''t resize back down, unless you REALLY need the space on the graphics card for something else.

On the other hand, you could just create a very large VB (larger than you think you will ever need), and just use it.

Share this post


Link to post
Share on other sites
If you know approximately how many vertices you''ll need at maximum, then you should rather create a VB large enough to contain ''em all, so you dont have to release and recreate it each time, that''s useful when you need to save CPU time. However, be careful!!!!! Your app will very easily crash if the VB is too small!

Prog, Hex & Rock''n''Roll :
I don''t like the Prog but the Prog likes me.
Some nice poetry to sweeten your spirit and relax a bit before programming

Share this post


Link to post
Share on other sites
i got a question regarding these vertex buffers, what im trying to do is add 6 new vertices to the buffer each time, so like
it starts at 0 then there are 6 temp ones, then when you click it stores those 6 in the buffer, then it goes on. my problem is, everytime i recreate the buffer, i loose the past vertices. how could i keep increasing the size while keeping the past vertices. like appending to the buffer, or would i have to create a new buffer which is like hidden, then load the vertices, then add them back to the other buffer?

Share this post


Link to post
Share on other sites
bleh! there must be some kind of technique, cuz i dont see how to proficiently code in direct3d with this limitation...

i know i sound really new by saying this, because there are TONS of games in Direct3d, so there has to be some way to deal with this type of thing...

Share this post


Link to post
Share on other sites
hehes thats what i was saying, how can they limit it and make it harder on a user when they coulda made a simple call just to increase the buffer without loosing anything.

Share this post


Link to post
Share on other sites
Well, if you think of the VB as a block of memory, then it makes sense that you can''t just make a call to resize it. If I malloc() (or new) something, I just can''t make a call to say,

"Oh, you know how I allocating exactly 4 things, here, well now I want 6... yeah, yeah, ... Look, I don''t care if you allocated 2 other different things in memory right after mine! Just give me the friggin'' space you shmuck!"

You can''t do that in system memory, and you can''t do that in video memory either. The only solution (just like in system memory), is to allocate the new space, copy the old data over, and then use the newly allocated memory. You could write a wrapper object to do this for you, if you see yourself doing this alot. I in fact have a VertexMemory object which handles my VB and IB''s, automatically resizing them and giving me new ones when I run out of space in others. It has worked quite well so far.

Share this post


Link to post
Share on other sites