dynamic vertex buffer size
Posted 10 February 2007 - 07:59 PM
How do i dynamically allocate a vertex buffer on the fly. Basically the issue is the number of vertices changes whenever i update the terrain and I have no way to tell ahead of time how many vertices there are going to be.
Do I set the vertex buffer to some size that would be the max limit and then have wasted space or can i resize the vertex buffer and pointer to the vertices every update?
Posted 10 February 2007 - 09:17 PM
Dynamic vertex buffers are for things that really change every frame. For your geo-mipmapping stuff I assume your geometry changes, but most of the time only a small part of the geometry changes. I hope you're aware of that.
For a performance optimization you should keep non-changing parts in a static buffer and dynamic changing stuff in a dynamic buffer. Sometimes it's worth to use a static buffer, even if the content needs to be updated every 4 or 5 frames or so. That might pay off, even if a update of a static buffer is painfully slow.
Well - i haven't answered your question yet.
The best way (imao) is to allocate a large dynamic buffer and manage it yourself. You're free to allocate (using your allocation code) as much as you like while the buffer is large enough to handle all your dynamic updates.
If your run out of space you can either draw a part of the dynamic buffer (and thus make new space for new terrain patches, because once you've used it, you're free to reuse the buffer-space) or simply allocate a new one using the graphic-api. That'll be a performance hit for sure, but that's how things are. A bit of slowdown is ok if it only happends once every while.
If you find out that your code constantly flushes your dynamic buffer or allocate new ones it's about time to either make your dynamic work buffer larger or create a second buffer. Or a third one..
You'll end up writing a dynamic memory manager for vertex/index buffers if you update your geometry each frame. That's how things are, and there is nothing you can do about it. I know it sucks, and it hurts the eyes of a programmer to do such things. If you come up with a better idea to handle such situations let us know...
I know that it looks like a bad idea to allocate a new buffer as soon as needed (e.g. during rendering), but if it happends, remember that you don't need to delete the buffer. Chances are, that you'll need the same amount of storage next frame as well, so cache the new buffer and use it. This way you'll get the performance drop due to allocation only once.
Posted 10 February 2007 - 09:28 PM
during my days as a game-dev on consoles I was really concerned to let my games run at a fixed frame rate. If the fps is stable as a rock the game looks awsome, and it's not that different on pc's these days.
However, if I had to do maintenence in my code, or load something, and I lost a frame or two noone would ever notice. I as a programmer of cause saw the glitch in framerate but testers / gamers never noticed unless it happened regulary.
Don't be afraid to do what you have to do, even if you break down the framerate for a moment.
Posted 10 February 2007 - 09:38 PM
Posted 11 February 2007 - 12:15 AM
You should try to load them into a single buffer if you can and the data fits into it. But don't be afraid to use two or more buffers if you have to. Just don't use 1000 different buffers with 100 vertices each. The time it takes to change buffers might kill you.
Back, when I did d3d coding we've also tried to doublebuffer buffers.
E.g. we've allocated twice as much storage of dynamic buffers as we needed and used the buffers in round robin fashion. E.g. if we've used a buffer in the last frame, we didn't used them in the current frame.
This gave a bit of performance increase. I think the driver detects such situations and optimizes a bit.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users