Jump to content
  • Advertisement
Sign in to follow this  
SeeMe

Static Buffer and Dynamic Buffer

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

Hello, I'm trying to implement static and dynamic buffer managment in my Render Engine. I would like to make the render engine as flexible as possible. I'm facing some "problem", and I would like to have advices and tips to go in the right path from scratch. 1) Big static buffer approach and Culling The aim is to keep inside a Big static vertex buffer all the objects that will not move and that have the same device state/shader. The problem with this is : How are you doing your Frustum culling on that buffer ? Let's say that I have all the trees (all differents) in a big static buffer, but depending on the camera location, most of the time only 30% of them are visible at the same time. Do you still render all the static buffer within one single draw call (Even if 70% of the tree inside the buffer won't be visible) ? 2) How would you manage your buffer in a "seamless" land while moving (No "zone") ? If you move quite quickly, is it worth to store the terrain into static buffer ? Tx you !!!

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by SeeMe
Hello,

I'm trying to implement static and dynamic buffer managment in my Render Engine.
I would like to make the render engine as flexible as possible.

I'm facing some "problem", and I would like to have advices and tips to go in the right path from scratch.

1) Big static buffer approach and Culling
The aim is to keep inside a Big static vertex buffer all the objects that will not move and that have the same device state/shader.
The problem with this is : How are you doing your Frustum culling on that buffer ?
Let's say that I have all the trees (all differents) in a big static buffer, but depending on the camera location, most of the time only 30% of them are visible at the same time.
Do you still render all the static buffer within one single draw call (Even if 70% of the tree inside the buffer won't be visible) ?

This is typically done using a spatial subdivision scheme (octrees, ABT-trees).

Quote:
Original post by SeeMe
2) How would you manage your buffer in a "seamless" land while moving (No "zone") ?
If you move quite quickly, is it worth to store the terrain into static buffer ?

Tx you !!!


You can use a LOD system to handle your terrain. There are multiple resources on the web that deal with terrain rendering, the most complete being (IMHO) vterrain.org.

Regards,

Share this post


Link to post
Share on other sites
Hello Emmanuel,
Tx you for you answer.

Concerning the Octree, I agree with you for the method.
But, how are you managing you buffer with it ?

Just an exemple out of my crazy brain :

Let's have one hundred static objects around the camera.
The octree that surround the camera is filled in with all the objects.
Following the camera LookAt vector I'm able to retrieve the collection of objects that needs to be rendered quite easily.

As the objects are "Static", I could build my Static buffer with the visible object only.
But what's going on with my static buffer if the camera begin the rotate around the Y axis ?
It means that the objects collections that are visible are changing a lot ! (Even if thoses objects are not moving at all !)
Should I use dynamic buffer instead of static buffer ?


Share this post


Link to post
Share on other sites
You seem to be confusing static vs. dynamic buffers versus what draw calls you issue on them - the important point is that you don't have to draw the entire contents of static buffers each time you call DrawIndexedPrimitive().

For most circumstances, you would either have a) one static vertex buffer and one static index buffer (both which would be shared between multiple objects), and then issue different DrawIndexedPrimitive() calls to draw your objects, or b) one static vb & ib per object, with each DIP() call using the entirety of each of those smaller buffers.

If you're concerned about frustum culling on static buffers for something like terrain, you could have multiple static index buffers, and one static vertex buffer. Then, after you do your rough frustum vs. (say, perhaps) quad-tree determination, you use that to select which of the static index buffers you submit to DIP(), thereby selecting which parts of the static geometry you're going to render.

So, no, for what you've described, you don't need dynamic buffers - they'd probably slow you down.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!