Yes it's possible to modify a VBO but before that, see the VBO drawing hints. There are constants for drawing which also give some hints to the opengl rendering engine.

1 2 3

GL_STATIC_DRAW// The VBO will be created once and drawn many timesGL_STREAM_DRAW// The VBO will be updated every frameGL_DYNAMIC_DRAW// The VBO will be updated n times and is drawn n times

Then create the VBO as you normally would and you can update the contents with the

glBufferSubData()

function. It's syntax is

1 2 3 4 5 6 7 8 9 10 11 12 13 14

/** * Updates a subset of a buffer object's data store. It redefines some or * all of the data store for the buffer object currently bound to target. Data * starting at byte offset offset and extending for size bytes is copied to the * data store from the memory pointed to by data. * * @param target Specifies the target buffer object.

So when the first buffer is created it is bound with GL_STREAM_DRAW. And i created the second buffer wit hthe data i want to be updated. But it seems like glBufferSubData is not changing the data out. Nothing changes.

It's tricky to work out what the problem is without seeing the 'loop' where these methods are being invoked or understanding what you're trying to achieve.

Is renderInitStart only invoked once? If so, why is the glBufferSubData call there? If it is called on every frame then you will need to move the glBufferSubData call after you've bound the VBO (I think calling methods on the default VBO is undefined but don't quote me on that).

well... i dont know about glMapBuffer. But the glBufferSubData: create the VBO normally except in the gl glBufferData you but GL_STREAM_DRAW instead of GL_STATIC_DRAW. and then when you have the now content ready for the buffer you just. glBindBuffer(GL_ARRAY_BUFFER, BufferID);glBufferSubData(GL_ARRAY_BUFFER, offset, buffer with new content);glBindBuffer(GL_ARRAY_BUFFER, 0);

But if values change, i.e. you've directly modified the values in vertices, textures, and colors, you can intentionally do an upload. Here's an example of me uploading the colors also during the draw/render phase:

At some point in time you need to free the VBOs but that is only when you're done with them and not necessarily every frame.

1 2 3 4 5 6 7

valib: IntBuffer = BufferUtils.createIntBuffer(3)

ib.put(0, vHandle)ib.put(1, tHandle)ib.put(2, cHandle)

glDeleteBuffers(ib)

On my system, I can render a frame in about 1.5 msec with pure static VBOs. If I need to upload the colors on 160000 quads, the render jumps up to around 2.0 msec. Yes technically, I am not modifying the VBO purely in video memory and instead I'm uploading an entire data set. However, the performance hit appears negligible and note that depending on how I manage things, I may not need to upload data every frame.

will delete the previous data, allocate new memory and then copy the data. With

glBufferSubData

there is some increase in performance since the same memory will be reused.

This is not entirely true. glBufferData() doesn't immediately delete the previous data since the GPU might still be using it. However, you're right that it reallocates the memory on each call. This is called orphaning and it has some useful characteristics. Let's say you have a small VBO which you update multiple times per frame. In this case, glBufferSubData() and glMapBuffer() will have terrible performance since each time you update the buffer you basically stall the entire OpenGL pipeline since the GPU has to finish using the old data before it's overwritten. If you instead use glBufferData(), the driver is smart enough to not immediately delete the old buffer and the driver may keep multiple internal buffers for each call to glBufferData(). In this case, there is no stall since the driver isn't forced to overwrite the old data of the buffer and can just keep the old buffers in memory and deallocate them when they no longer have a use. In the case of a buffer being updated only once per frame, the overhead of glBufferData() is a bad thing and glBufferSubData() or (even better) glMapBuffer() is preferred to glBufferData() like you said.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org