Vertex Buffers Management / How many VBOs should I use?

Started by
3 comments, last by V-man 15 years, 1 month ago
Hello, I have some questions about vertex buffers management. Let's say we have a scene composed of: - the world (walls, terrain, etc.), which is static data; - the objects (represented by 3D models), which are dynamic data (because they are animated). When rendering the scene, I have determined a small part of world data and a subset of objects to be drawn. How to render all that stuff using Vertex Buffer Objects? More precisely: *Assuming I compute the animated vertices only for the rendering stage, i.e. I can put them in Video RAM I won't read them back* For the world (static data), I would put everything in one static VBO. For the objects (dynamic data), how many VBOs should I use? is it better to: - use one big vertex buffer? This VBO would be filled with all objects I have to draw, and then rendered in "one stage" (with respect to objects' textures and shaders). The VBO would be cleaned up after each frame, and could be reused for the next frame. It would avoid multiple memory allocations for the "final" vertex data, but I would have to prepare animated vertices of all objects before drawing (or maybe I could draw them independently -- drawing one object during vertex computations for the next one, etc., even if they are stored on the same buffer?) - use a vertex buffer for each object? Since the number of objects to be drawn on the scene is variable, I would have to create/destroy a VBO for each object for each frame. Or maybe I could keep some VBOs and reuse them for others objects during the next frame? I don't know the cost of creating/destroying a VBO. - use multiple VBOs of a "medium" size, in which I could fill multiple objects. I could render objects of a VBO when it is "full", and compute vertices+fill next VBO for the next objects. I could avoid creating/destroying a lot of VBOs. This is like a mix of the two previous solutions. Also, do you think it's better to prepare all vertex data (CPU) and then draw every thing (GPU), or prepare vertex data for an object, then render it, then prepare the next object, render it, etc.? Thanks.
Advertisement
Quote: use a vertex buffer for each object? Since the number of objects to be drawn on the scene is variable, I would have to create/destroy a VBO for each object for each frame. Or maybe I could keep some VBOs and reuse them for others objects during the next frame? I don't know the cost of creating/destroying a VBO


Never destroy and allocate a resource while the program is running.
Try to put as may objects in 1 VBO.
http://www.opengl.org/wiki/VBO_-_more
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
Thank you for your answer, and for the link!

Is the switch from one VBO to another (via glBindBuffer) costly? like switching from one texture object to another.
Beware I did some tests on this and and after a certain size there performance decreases the bigger they get. About 4mb is a good point.
Quote:Original post by V3rt3x
Thank you for your answer, and for the link!

Is the switch from one VBO to another (via glBindBuffer) costly? like switching from one texture object to another.


Not so much. Most of the cost comes from glVertexPointer, that's when most of the setup work is done in nvidia's driver.
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

This topic is closed to new replies.

Advertisement