Sign in to follow this  

Managing vertex/index buffers

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

I guess this is not strictly a DirectX question, but here goes... My new engine features an asynchronous loading system that is used extensively in the map editor. For example, when you open a map in the editor, you don't have to wait until all the geometry is loaded. Instead, you can interact with the map almost instantaneously (very similar to a web page where images pop up once they are loaded). The trouble with this approach is that there's no way for me to know how big my vertex/index buffers are going to be. I'd like to have as few vertex/index buffers as possible (preferably one per vertex format), but I'm not sure how to pull that off efficiently. Right now I have one vertex/index buffer per mesh and of course that's not really ideal. Here are the options I see: - Create per-mesh vertex/index buffers and once all geometry is loaded, copy the vertices/indices to a new buffer that is big enough to hold all geometry, discarding the per-mesh buffers - Use a std::vector kind of approach (create a buffer with a reasonable size and allocate new, bigger buffers once I run out of space) - Use an ArrayList kind of approach (create relatively big buffers as needed and chain them together [obviously meshes wouldn't span across different buffers].) - Defer vertex/index buffer creation until all meshes are loaded (this is not ideal because you wouldn't see anything until the entire map is loaded) Does anybody have any experience with this? Are there other (better?) approaches? Thanks a lot in advance!

Share this post


Link to post
Share on other sites
I would suggest looking at what you described as the "AttayList" method, which is pretty common in 3D Applications. Allocate several large buffers (You'll have to experiment with what size works better for you) and load multiple meshes into it. Then, when rendering, try to sort meshes to render in order of the buffer they are stored in to prevent switching (which will improve rendering speed).

It's really the same thing as doing your own malloc/free memory management routines, if you've ever tried that.

Share this post


Link to post
Share on other sites
Can't you just include some figures in a header for the map file format indicating the number of vertices/indices the map used when it was last saved? I don't know if that'll work in your scenario, but this should allow you read this info on load and create one big static vertex/indexbuffer pair to stream everything into.

Or am I completely missing your point? [smile]

Share this post


Link to post
Share on other sites
@remigius: Yeah, that would work. The problem with that however is that you could change the mesh files (adding polys to it) and not update the map file and then you'd be back to resizing your buffers...
Good pragmatic thinking though...I like it ;-)

Share this post


Link to post
Share on other sites
Quote:
Original post by Harry Hunt
@remigius: Yeah, that would work. The problem with that however is that you could change the mesh files (adding polys to it) and not update the map file and then you'd be back to resizing your buffers...
Good pragmatic thinking though...I like it ;-)


I have no idea what your mesh format is like, but, if its easy to extract from the mesh file, you could loop through all of the meshes you are going to load and add up a tally of the number of vertices + indices you will need.

If the information on what vertex format to use is also easy to extract, you could have a per format vertex count.

Another alternative, would be to just keep the seperate vertex/index buffers per mesh when you are running in editor mode, and when running the actual game switch to using the combined buffers (since you probably don't want your maps to show in game until they are fully loaded).

Share this post


Link to post
Share on other sites
I remember something was said that it's not recommended to create buffers larger than 4MB. While this figure might have changed over the years, the idea of creating several buffers of this size sounds like a good solution.

Share this post


Link to post
Share on other sites

This topic is 3505 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.

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