10
\$\begingroup\$

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?

\$\endgroup\$
2
  • \$\begingroup\$ This is a duplicate question. Of what, I'm not too sure, but it is a dupe. \$\endgroup\$
    – DeadMG
    Commented Jul 30, 2011 at 15:11
  • \$\begingroup\$ 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). \$\endgroup\$
    – Thomas Russell
    Commented Jul 30, 2011 at 16:05

1 Answer 1

Reset to default
11
\$\begingroup\$

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.

\$\endgroup\$
4
  • \$\begingroup\$ 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? \$\endgroup\$
    – hiddensunset4
    Commented Jul 31, 2011 at 22:37
  • 1
    \$\begingroup\$ @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. :-) \$\endgroup\$
    – Wroclai
    Commented Jul 31, 2011 at 22:55
  • \$\begingroup\$ 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. \$\endgroup\$
    – Lars Viklund
    Commented Aug 1, 2011 at 7:39
  • 1
    \$\begingroup\$ I think you should also take frustum culling into account. \$\endgroup\$
    – Tara
    Commented Jan 8, 2014 at 13:37

You must log in to answer this question.

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