Advertisement Jump to content
Sign in to follow this  

Need some dynamic buffer advice

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

So I have this simple game engine that displays a 3D hex game board/map, that can support things like floating islands, river networks and cave systems. I have the map divided up geographically into cuboid chunks so that I can render only the parts that are near the camera and in the frustum. Each chunk has a series of dynamic buffers to draw the terrain, rivers, water levels etc. These buffers are often different sizes, as some map chunks have few rivers, or few water tiles, or sometimes in the case of floating islands there might be only one or two map tiles in the whole chunk, or the chunk might be completely empty space. This scheme is working great if I am just generating a map and displaying it. I draw what exists in my buffers each frame.


However, if this thing is ever going to be useful in a game, I need to be able to alter the map during the course of the game. It's time to make this thing change over time. But that means that I don't know the buffer's size needs at initialization time. I have to assume that every chunk is full of tiles, water and full of rivers, which in practice will be never the actual case. The problem is that not only will I have to waste memory (probably 5x as much) for empty fixed size buffers, but I'll also have to send a bunch of degenerate triangles for rendering, which is probably going to be some kind of performance hit.


All of a sudden my geographical partitioning makes a lot less sense. I wonder if any of you know of another way to handle resource data that changes in size in the described manner.

Share this post

Link to post
Share on other sites

ok, so you have terrain chunks, and each chunk has buffers.


options using that setup:

1. allocate all buffers possibly required for all possible terrain types in the chunk (wasteful)

2. reallocate buffers when terrain changes (slow)



an alternate way to do things:

1. buffers go in a memory pool.  (not wasteful)

2. a terrain chunk contains a list of renderables, not their buffers.  (not wasteful)

3. when a terrain chunk changes, the list of renderables changes, the buffers do not.  (fast)

4. if a change to a chunk requires a new buffer its allocated in the memory pool  

5. if the memory pool is full, buffers are discarded in a LRU manner.

6. this method eliminates the possibility of multiple copies of the same buffer in different chunks. (not wasteful)

7. you only allocate when adding a new buffer type. you only deallocate when the pool is full. you never have to reallocate. (fast)

8. changing the list of renderables in a chunk is faster than messing with buffers.  (fast)


FYI, static buffers are faster than dynamic. unless you change buffers every frame, using static buffers should be faster than using dynamic buffers. not sure if this still holds for dx11 the way it does for dx9 and dx10 - your mileage may vary.  i use static buffers to generate ground meshes for terrain chunks from heightmap data in the background, on the fly, in realtime.

Edited by Norman Barrows

Share this post

Link to post
Share on other sites

Thanks for the push in the right direction. I was foundering between option 1 and 2 in my setup, which was kinda painful and hopeless.


I'm intrigued by 'buffers go in a memory pool'. What is that exactly, a giant buffer that is maintained manually somehow? How do I put an instance buffer(misc data used by the shaders) into a memory pool and then use it in my shader?

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!