Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Currently I am working on a project in which I generate geometry based on the players movement. A glorified very long trail, composed of quads.

I am doing this by storing a STD::Vector, and removing the oldest verticies once enough exist, and then calling glDrawArrays.

I am interested in switching to a shader based model, usually examples I see the VBO is generated at start and then that's basically it. What is the best route to go about creating geometry in real time, using shader / VBO approach

share|improve this question
add comment

2 Answers

up vote 5 down vote accepted

Even though this can be application bound and depends on how much you generate geometry and how dynamic your application is, there are general rules you can follow when using VBOs.

-Specify how your VBOs will be used.

  • "Static" means the data in VBO will not be changed (specified once and used many times),
  • "Dynamic" means the data will be changed frequently (specified and used repeatedly)

  • "Stream" means the data will be changed every frame (specified once and used once). "Draw"

so in your case they should be dynamic.

  • Update (reuse) your existing VBOs using glBufferSubData, glMapBuffer(), glUnMapBuffer(), instead of creating and allocating new VBOs.

About using std::vector I think this can hurt performance if you add and remove a lot of objects, try to specify a vector with predefined size to minimize memory copy.

As for shaders, I don't think this makes any difference as long as you track transformation matrices (player position, rotation).

for more on VBOs refer to http://www.songho.ca/opengl/gl_vbo.html

share|improve this answer
    
if you have geometry data that change every frame, what are differences/advantages using VBO with stream flag vs sending them using glDrawElements()/glDrawArrays() + pointer ? –  tigrou Apr 8 '13 at 13:57
    
@tigrou as far as I know this will tell the graphics driver to optimize where is it supposed to store the data in memory; for example data could be cached or not, stored in system memory or graphics memory. –  concept3d Apr 8 '13 at 21:55
add comment

I agree with Concept3d, you don't really want to be using a vector to store this data. If I was going to be setting this up with VBOs I would just allocate off a large static chunk of memory. This allows you to setup the VBO once, then just update the data as you add verts.

I would keep track of the how many verts were in the buffer using an outside variable. Then you could easily memcpy new verts on to the end of the buffer and use shift operators to removes old verts form the front of the buffer.

As Concept said you will want to use a Dynamic VBO which will need to be uploaded into RAM every time it changes. Just make sure you pass the correct number of verts to you Draw call and not the size of the VBO, as it could be partially full.

share|improve this answer
add comment

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.