I'm currently working on a personal project where I'm trying to load the levels and all of the geometry from the game "Medal of Honor Allied Assault" into my own C# code-base based on SharpDX.

I managed to do all that, but now that I'm trying to cleanup the code I came across a few questions on which Google and other sites don't give me a clear answer to, hence I'm turning myself to StackExchange once more!

Currently, I'm rendering the whole scene using the following equation: 1 VBO (BSP) + 1 VBO (Terrain) + (1 VBO (Model) * NumberOfModels)

For each VBO, I'm keeping track when and where I have to start a new DrawIndexedPrimitive-call (eg. Texture-swap).

Is my current setup sufficient, or should I put everything into as less VBO's as possible? Or is there a better approach. How about culling which I'm not bothered with just yet, would one massive VBO work better for that than lots of smaller ones?

To give a little more information: some models require 3-4 Texture-swaps, are relatively small (128 vertices to 4k vertices) and I'm currently not even animating them yet.

If I'd go with my feeling, I would give everything its own VBO, arranging vertices in such a way I can batch textures and use instancing techniques, but I'm unsure this the way to go.

Feel free to ask for more information!


2 Answers 2


At this stage it doesn't really matter too much. I'd say just go with having everything in separate buffers for now, then measure your performance and see how things are.

Buffer swapping is a relatively cheap operation on modern hardware - not free for sure, but still not a huge overhead - so you may well find that you run with acceptable performance. On the other hand, putting everything into a single buffer entails some added complexity (prescanning your models at load time to figure how big a buffer you need to allocate, for example) and compromises your ability to be flexible with e.g. on-demand loading, so it may not be worth the tradeoff.


There is no general way of doing this correctly, each game has its own rendering ways due to its own characteristics.

But, typically, FPS games go with high frustum culling, batched geometry, and sorted texture swaps. Ideally, you could instance every same geometry and just pass on some parameters defining what texture to use and so on.

And it's really hard to say what causes a bottleneck in your case. The draw call or the binding of the data to the GPU. You really have to test this and make a profiling chart over what's causing bottlenecks. From there, move on to improve your rendering.

There are some really good papers on how different games have gone with their rendering. This one is from DICE's Battlefield 3. You might get good ideas from that.


It is a 5 part video.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .