Tell me more ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 7 down vote favorite
1

I'm making a 3D first person game. Should I give each character its own VBO or should I batch all characters into a single VBO? What are the pros/cons?

share|improve this question
This is a duplicate question. Of what, I'm not too sure, but it is a dupe. – DeadMG Jul 30 '11 at 15:11
It's similar to this, but I don't believe that it's a duplicate per-se, for a start, this is Open-GL (I'm not sure if there are any specific differences), whereas the other question is about deformables in DirectX11 (thus presumably using tessellation, which changes things). – Shaktal Jul 30 '11 at 16:05

1 Answer

up vote 9 down vote accepted

This is really a choice between performance and flexibility, but I'll list my opinions about it.

One single VBO

The positive sides are:

  • Just one draw call to draw your scene. This increases performance. Although your application may require multiple draw calls, you can still have a single VBO and let the count and offset decide your drawing.
  • Not requiring state changes between your objects. This increases performance.

and the negative sides are:

  • Hard to manage, although this depends on how you write your code, if it's properly designed etc.
  • By saying hard to manage I mean stuff like update the VBO, set correct offset for every object etc.

Individual VBO:s

The positive sides are:

  • Easy to implement.
  • Easier to manage from the beginning.

and the negative sides are:

  • Lots of state changes. This decreases performance.
  • Lots of draw calls. It will decrease the performance.

Summary

I'd recommend you to profile your application; get your real bottleneck in data you can see. Premature optimization can be shown (in this case) as unnecessary. However, that being said, if you'd discover a real performance loss in your application, given the individual VBO:s scenario, you can start implementing a single VBO.

However, as long as it's not needed (the number of objects are low, not many state changes overall, etc) I'd recommend to go with individual VBO:s unless you see that's not gonna work.

Edit

I forgot to mention that it'd be alright with multiple draw calls. The most important thing in performance critical times is to keep the state changes at a minimum. You can simply set the number of indices to process and an offset for every draw call, and this is fine. But however, keep state changes as low as possible and make as few draw calls as possible, that's the big hello of this answer, or at least what I tried to say.

share|improve this answer
If your only doing 1 draw call, that screws you over for per mesh (not per vertex) state changes (uniforms etc). Also forces an all or none for drawing everything. Sure you can break it down so theres only 1 VBO multiple draw calls, but what if you want to add a new mesh? – Daniel Jul 31 '11 at 22:37
1  
@Daniel: A new mesh should simply be updated/added into the VBO. I forgot to mention that it'd be alright with multiple draw calls. The most important thing in performance critical times is to keep the state changes at a minimum. You can simply set the number of indices to process and an offset for every draw call, and this is fine. But however, keep state changes as low as possible and make as few draw calls as possible, that's the big hello of this answer, or at least what I tried to say. :-) – Shelly Jul 31 '11 at 22:55
Batch, batch, batch in 2005 came to the conclusion that you can afford between 10k and 25k batches on a 1 GHz CPU before you're completely CPU-bound by processing the draw calls alone. As that translates into a few hundred batches per 60Hz frame, shoehorning everything into a single VB isn't essential, but it sure helps if you bundle geometry that has similar characteristics (lifetime, update rate, attributes) into the same VB. – Lars Viklund Aug 1 '11 at 7:39

Your Answer

 
discard

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.