Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am using assimp to load 3d model data. I have noticed that each loaded model is made up of different meshes. I was wondering should each mesh have it's own vertex/index buffer or should there just be one for the whole model? From looking through the index data that is loaded it seems to suggest that I will need a vertex buffer per mesh but I'm not 100% sure. I am using C++ and DirectX9

Thank you,


share|improve this question

migrated from Jun 25 '11 at 10:51

This question came from our site for professional and enthusiast programmers.

up vote 3 down vote accepted

Most games nowadays use a vertex buffer for each mesh. It's true that having a single vertex buffer for the whole model reduces the number of draw calls, which is more efficient, but it tends to make your design more complex. Here's a discussion about this

By the way, you might get better answers at (about this kind of stuff, that is)

share|improve this answer

Having all your data in the same vertex buffer lets you batch all those objects in a single draw call, as long as they have the same render states.

The game would have to be draw call bound for that technique to give you any performance gain and this won't happen before having thousands of calls per seconds on modern hardware.

Batching introduces a lot of complexity to your engine and will force you to defer most rendering, which will introduce some performance penalities.

Conclusion, don't mess with that until strictly necessary, that is, you profiled your game and it is clearly draw call bound.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.