I don’t know how much the CPU must be used with such amount a triangles. It may be due to the vbo dynamic usage that involves many transferts from system to video memory…

However, I don’t see any problem in what you are doing.


I have one last question on this topic.

If I use Index Buffer Object. and say that I know out of roughly 50,000 indices I want to change 5,000 of these indices attributes per frame. I know what indices(vertices) that they would be prior to ever rendering. I just have no idea how to dynamically only update those particular attributes. I want to avoid updating all of the attributes.

If you can provide some insight I would appreciate. I searched updating buffers and can’t find how to sub small batches since they aren’t sequential necessarily.


If indices are constinuously packed in the vbo simply call glBufferSubData to update a little chunk of the vbo.

In the other case, map the buffer with glMapBuffer. With this function you get a pointer with an address where you can directly write new data as if it was regular system memory.

Do not forget to unmap the buffer then.

Mapping a vbo is very powerful, but as i said in other posts, or thread of you, it may stall the program as long as the vbo is used by hardware. To prevent this problem, the best solution is to use two vbo, one for drawing and one for data update then switch their roles (ping-pong).
This way you are sure that the vbo used for update is not in-use.

There is also, glMapbufferRange which provides the ability to map a particular portion of a vbo. With this function you can map a vbo whose one portion is used for drawing and another for update without causing any stall. But I am sure it would be usable in your case since you seem to use the entire vbo each render call.

Mapping the vbo sounds like it might be the only way to proceed. Since the indices could be randomly scattered between the entire amount of vertices, glMapBuffer would allow to store which memory address’s should change? So I could loop through only the necessary elements to change or ? I’m a bit lost on this. Trying to learn openGL in a month’s time has presented many challenges!

Just cast the pointer returned by glMapBuffer and loop through the buffer the same way you would modify the array you used to fill the vbo with glBufferData the 1st time. It is transparent! :slight_smile:

! It makes sense. I am attempting to finish implementing the IBO’s. How do I go about indexing the normals and the positions? I have a different total amount of vertices and normals, and can’t figure out how to drawElements() for both?

OpenGL uses the same index for all bound vbo. Data must be arranged to comply with this constraint. So you do not have one index for vertex position, one for normals, etc… Vertex position normals and all remaining attributes are indexed with the same index.

That requires to preprocess a bit your data before rendering.


you are the OpenGL saint for me! I’m off to try these changes, I can’t foresee why it wouldn’t work. Got a bit of processing to do in order to get the indices cooresponding.

hopefully, I won’t have to post anymore!

lol, good luck! :wink:


I’m getting caught at the glMapBuffer idea. I ran into a few other problems that don’t relate to the openGL, importing my data, but I am unsure on the glMapBuffer. If I cast the pointer, I would have to use a loop to go through all the Buffer items per frame? There is no way to only change 4,000 of the attributes using the AttributeArray? I can’t determine how I would only change some attributes. Help would be greatly appreciated!

Suppose that you have a VBO full of float attributes and you want to write the 42th element you simply do:

GLfloat* pData = ( GLfloat* )glMapbuffer( GL_ARRAY_BUFFER, GL_WRITE_ONLY );
pData[ 41 ] = 12.f; // some random float value


Where is the problem?

With the mapping method you are able to update values that are not necessary continuously packed in a buffer. Otherwise glBufferSubData is enough.


do you think this will be a performance hit if I’m rendering say 150,000 triangles per frame?

Thanks for the sample code! that made it crystal clear.

With the ping/pong method I talked about earlier, that should not affect performances too much but double memory consumption for this vbo.
Try and you will see! :wink:

That sounds promising! I’m still attempting to get this program implemented since this matlab interaction is causing tons of problems when rendering the model.

When I try to use index buffer, it performs as if it were not there. Does this code seem correct for using an IBO?

glGenBuffers (1, &IndexVBOID);
glBufferData (GL_ELEMENT_ARRAY_BUFFER, IndexTotal * sizeof(unsigned int), IndexVBO, GL_STATIC_DRAW);


No it is not correct because you made the mistake that almost everyone do the 1st time they use vbo :wink:

glIndexPointer is for color indices. I must admit that the name of this function is ambiguous indeed. Simply forget this function, it is pretty useless.

Before the drawing call (glDrawElements) you just need to bind the index buffer object and that’s it! No gl*Pointer call is required for ibo unlike GL_ARRAY_BUFFER bindings since all is done in glDrawElements or glDrawRangeElements.

Perhaps you already did it but do not forget to enable vertex array client side capabilites with glEnableClientState for all bound vertex buffers.


A working example:


Yeah, I found out that the IndexPointer is indeed a trick! I posted a new thread under openGL beginners because it doesn’t really pertain to GLSL.

The IBO and VBO are still causing me create trouble. The MATLAB program I’m using, has a .mat file with all vertices and the index for these.

I merely import this into my openGL program, calculating normals before hand in MATLAB, and try to render with VBO and IBO. Doesn’t work. Check out the other thread, your help is always welcomed and needed.



That post link