ARB_vertex_buffer_object and Vertex Arrays

[Markus_Persson]

http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt

BindBufferARB changes the behavior of the various Vertex Array pointer methods to take an offset inside the current buffer instead of a memory pointer to a buffer as the last argument.
Unfortunately, jogl defines glVertexPointer as glVertexPointer(int, int, int, Buffer), so it's kinda hard for me to send an int there.

Is this a "bug" (or lacking feature, rather) in jogl, or am I doing something wrong?

[Markus_Persson]

I tried to send in an bytebuffer containing only an 0, by the way, but it still seemed to use the memory address of the buffer as the offset inside the buffer.

[DavidYazel]

One thing you can try is to use slice() to create a new buffer which is really pointing into the other buffer.  I have not done it, but I think it would work.

Games published by our own members! Check 'em out!

[Markus_Persson]

Oh. No, that's not what I need.
*tries to be clearer*

When using vertex arrays like normal, that would probably work, but enabling ARB_vertex_buffer_object changes the behavior of the vertex array methods.
Instead of passing a pointer, you pass an offset.
So usually, you'd want to pass 0 to start from the beginning of the buffer.
That offset is used to offset the data of the vertex buffer, which resides on the video card memory.
(not to be confused with a java.nio.Buffer)

See the example way down at the bottom of the specification of ARB_vertex_buffer_object to see what I'm talking about.

[DavidYazel]

Got it... yep sounds like the API needs to be expanded a bit to cover that call.

[Ken Russell]

We haven't thought through the ARB_vertex_buffer_object support yet and it will almost certainly not work in its current form. The primary issue is that the allocation of the vertex buffer object is separated from the fetching of its base pointer (unlike NVidia's wgl/glXAllocateMemoryNV call), so in order to figure out the capacity of the returned buffer from glMapBufferARB we need the result from another, earlier API call. This means that some handwritten bookkeeping will be needed. It's definitely on the list of things to do (which I should solidify and put up in HTML form in a shared location) but if you or anyone else wants to work on this please feel free; I'm more than happy to assist.