I’m using ofVbo to draw a line strip. The vertices can get moved around and the indices get recalculated to create a convex hull. It works for a some configuration but if you move the vertices (after initial vbo allocation) into some configurations the line isn’t correct as though the vertices are drawn in the wrong order.
Image explains it quite well.
Below is the drawing code to generate the image attached. You can see the bitmap strings draw the vertices indices correctly (0 point duplicated to create a loop). And the draw shape code always produces the correct hull it’s just the vbo that is having problems.
ofSetColor(50, 50, 50, 50);
ofBeginShape();
for (int i = 0; i < convIndices.size(); i++)
{
ofVertex(vertices[convIndices[i]]);
}
ofEndShape();
ofSetColor(100,255,100,255);
for (int i = 0; i < convIndices.size(); i++)
{
ofDrawBitmapString(ofToString(i), vertices[convIndices[i]]);
}
ofSetColor(255,255,255,255);
if(!convVbo.getIsAllocated())
{
convVbo.setVertexData(&vertices[0], vertices.size(), GL_DYNAMIC_DRAW); // also tried GL_STATIC_DRAW
convVbo.setIndexData(&convIndices[0], convIndices.size(), GL_DYNAMIC_DRAW); // also tried GL_STATIC_DRAW
}
else
{
convVbo.updateVertexData(&vertices[0], vertices.size());
convVbo.updateIndexData(&convIndices[0], convIndices.size());
}
glPushAttrib(GL_POLYGON_BIT);
glPolygonMode(GL_FRONT_AND_BACK, ofGetGLPolyMode(drawMode));
convVbo.drawElements(ofGetGLPrimitiveMode(OF_PRIMITIVE_LINE_STRIP), convIndices.size());
glPopAttrib();
Thanks for the reply. There’s a few reasons I’d like to use vbo’s directly the major reason is that I’m going to use the vertices array in a few different drawing operations and since the verts will move I’d like to just maintain one array.
Also it wouldn’t solve the problem since this is essentially the same drawing code found in ofVboMesh, unless there’s something I’m missing.
Should I post this to advanced? Surely it’s something small about dynamic vbos. I thought all you need to do when updating index data is to use GL_DYNAMIC_DRAW_ARB instead of GL_STATIC_DRAW_ARB, and then call glBufferSubDataARB() to update the indices.
i also recommend using ofVboMesh. it’s hard to debug your case because not all of the code is there, so there could be a bug in the code you posted or somewhere else. with ofVboMesh it’s been tested and we know it’s probably a bug with your code rather than with the ofVboMesh, so it will be easier to solve the problem.
you don’t have to worry about maintaining a separate vector. you only have to maintain the ofMesh vertices buffer:
I think there’s no really clean way to use ofVboMesh for what I want even just drawing the mesh and then the line loop of the hull indices, it’s very simple what I want to do.
Snippet really is all the vbo code. I’ve attached the whole program. It’s just a basic convex hull program, move the verts recalculate the hull indices and draw. Seems if you change the indice list size strange things start to happen.
when you use set*Data you are also allocating a buffer on the graphics card. when you use update*Data you are modifying that buffer. so if you setVertexData with 10 vertices, updateVertexData can never accept more than 10 vertices. i think OF should warn you about this rather than expecting you to know, so i added an issue: https://github.com/openframeworks/openFrameworks/issues/746
one fix is to allocate as much space as you could ever use (equal to the number of vertices).
alternatively, i think it’s not as bad as you think to just use ofVboMesh here. at this scale (fewer less than tens of thousands of vertices), using a vbo doesn’t make much of a difference anyway – you could just use ofMesh.
also nykwil you were right, as ofMesh was before you have one case in your code were it won’t work: when modifying the data from outside like accessing positions of the vector directly or using iterators like in ryour rotate and transpose methods.
Have added also a const version of the getters so now if you access the non const version the modified flags are set also.
Here’s a version of your code using a ofVboMesh with the latest changes