7
\$\begingroup\$

OpenGL VBOs (vertex buffer objects) have been developed to improve performance of OpenGL (OpenGL ES 2.0 in my case). The logic is that with the help of VBOs, the data does not need to be copied from client memory to graphics card on per frame basis.

However, as I see it, the game scene changes continuously: position of objects change, their scaling and rotating change, they get animated, they explode, they get spawn or disappear.

In such highly dynamic environment, such as computer game scene is, what is the point of using VBOs, if the VBOs would need to be constructed on per-frame basis anyway?

Can you please help me to understand how to practically take beneif of VBOs in computer games? Can there be more vertex based VBOs (say one per one object) or there must be always exactly only one VBO present for each draw cycle?

\$\endgroup\$

2 Answers 2

13
\$\begingroup\$

In such highly dynamic environment, such as computer game scene is, what is the point of using VBOs, if the VBOs would need to be constructed on per-frame basis anyway?

If you are reconstructing the vertex data for every object every frame, you're doing it wrong. Or at least, you're probably doing it inefficiently.

Moving objects in a scene can and should usually be done by changing the world transformation matrix used to render that object, not changing the vertex data directly. Skeletal animation has entirely on-GPU solutions, as well. Decomposable objects can be rendered with distinct transformation matrices, such that they appear together until they need to be decomposed, and then the matrices are adjusted to make them split apart as desired. Objects that are not visible or not spawned need not be rendered, even if their vertex data is on the card from a prior frame -- they don't need their buffers destroyed/recreated every time their visibility toggles.

Can you please help me to understand how to practically take beneif of VBOs in computer games? Can there be more vertex based VBOs (say one per one object) or there must be always exactly only one VBO present for each draw cycle?

You can have multiple vertex buffers. In generally you have one per each mesh/model, and you refer to that single mesh/model data structure with a collection of possibly-many renderable objects which contain their own unique world transformation matrix. This way if you have 50 enemies who all use the same mesh, you only need that mesh in-memory once. Then you have 50 smaller, lightweight instance structures that refer to that mesh and hold a unique world transform used when rendering each instance.

\$\endgroup\$
1
  • \$\begingroup\$ +1 for this detailed answer. I see that I will have to pay attention to scene construction and preparation, so I avoid duplicating vertices. Although this answer looks to me as Accepted Answer I will wait for a while to see, if I get more useful answers. \$\endgroup\$ Feb 16, 2011 at 17:45
3
\$\begingroup\$

You can have as many VBOs as you want. You can also have each animation frame in one VBO or whole animation in one VBO. You can also use Per vertex animation, which is done with the same data, but transformed in vertex shader (program).

If you change position, rotation or scale of object, it won't change VBO, it will only change transformation matrix.

So if you have enough memory, you can just transfer all your data to graphics memory in initialization phase.

\$\endgroup\$
2
  • \$\begingroup\$ +1 for this answer. I am studying some materials right now, but your answer pointed me to the right direction. Thanks. \$\endgroup\$ Feb 16, 2011 at 17:31
  • \$\begingroup\$ "per vertex animation" doesn't generally mean the animation logic is done in a shader, just that each vertex animates -- which is almost always the case. Were you wanting to make the distinction between vertex-based keyframe animation (where each frame of animation is a complete copy of the mesh, and you blend between them) and skeletal animation (where vertices are weighted to a simple bone hierarchy and animated)? Both can be done on either the CPU or GPU. \$\endgroup\$
    – user1430
    Feb 16, 2011 at 17:35

You must log in to answer this question.

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