Problem with creating more VBO Buffers

Hello

I have the following Problem.
I stop my 3D animated Renderer with that sequence of code:

/* FPSAnimator anim = new com.jogamp.opengl.util.FPSAnimator( glDrawable, 80 );*/
anim.pause();
Renderer3D renderer3D = Renderer3D.getInstance();
glDrawable.removeGLEventListener(renderer3D);
Renderer2D renderer2D = Renderer2D.getInstance();
glDrawable.addGLEventListener(renderer2D);
renderer2D.init(glDrawable);

I the got a Problem in the init method, if i create the buffers:

final GL4 gl = glDrawable.getGL().getGL4();
private int vbobuffer[] = new int[2];
private int vaobuffer[] = new int[1];
......
1) gl.glGenVertexArrays( 1, vaobuffer, 0);
2) gl.glBindVertexArray(vaobuffer[0]);
3) gl.glGenBuffers( vbobuffer.length, vbobuffer, 0 );
4) gl.glBindBuffer( GL4.GL_ARRAY_BUFFER, vbobuffer[0] );
5) gl.glBufferData( GL4.GL_ARRAY_BUFFER, vertexBuffer.capacity()<<2, vertexBuffer, GL4.GL_STATIC_DRAW );
6) gl.glVertexAttribPointer(ShaderConstants.VERTEX_BUF, 2, GL4.GL_FLOAT, false, 0, 0);
7) gl.glEnableVertexAttribArray(ShaderConstants.VERTEX_BUF);
8) if ( tex_coordBuffer!=null )
9) {
10) gl.glBindBuffer( GL4.GL_ARRAY_BUFFER, vbobuffer[1] );
11) gl.glBufferData( GL4.GL_ARRAY_BUFFER, tex_coordBuffer.capacity()<<2, tex_coordBuffer, GL4.GL_STATIC_DRAW );
12) gl.glVertexAttribPointer(ShaderConstants.TEXTURE_BUF0, 2, GL4.GL_FLOAT, false, 0, 0);
13) gl.glEnableVertexAttribArray(ShaderConstants.TEXTURE_BUF0);
14) }
.........

Now in line 5 it crashes with the following exception:

Exception in thread "main-Display-.windows_nil-1-EDT-1" com.jogamp.opengl.GLException: GL_INVALID_OPERATION: Buffer for target 0x8892 not bound
        at jogamp.opengl.GLBufferObjectTracker.createBufferStorage(GLBufferObjectTracker.java:164)
        at jogamp.opengl.gl4.GL4bcImpl.glBufferData(GL4bcImpl.java:40258)  

Are the names/id's in the vbo- or vao-buffers in the application not global?
Ich have seen that in line 3),

gl.glGenBuffers( vbobuffer.length, vbobuffer, 0 );

the names/id's are always 0. How can it be?
That describes the exception.  

Then is my next question,
musst all buffer-ids (with glDeleteBuffers)  are deleted, before i can use
new buffers with (glGenBuffers) ?
It seems there is a conflict.

Sorry,
the Animator must be set to
anim.resume(),
after a
anim.pause();
so that the new GLEventListener-objects are also
under a gl context and the init method is correct called.

I then  habe testet that the animator must not be stopped
for a change with GLEventListener's.
Good work from jogl Team:-)

Hi Adi,

a couple of hints:

- prefer Animator to FPSAnimator

- prefer IntBuffer s to int arrays

- in glBufferData vertexBuffer.capacity()<<2 doesn't look right, do vertexBuffer.capacity() * Float.BYTES for floatBuffers

- there is no global/local for vbo and vao names, but I think what you mean it's context related, in that case some else may answer that

- if you call glBufferData on an existing vbo name, it's fine, the driver will clean the allocated memory and will allocate a new one. But if you call glGenBuffers, you should delete your previous names with glDeleteBuffers

Hi elect

Thanks for your Hints.
Multiplikation are slower than shifts.
And what is it with ((maxPoints<<1)+maxPoints)<<2 ) or maxPoints*3 :-)
The other problems was not the glGenBuffers, they are working correct.
I was not in a correct state.
Using glGenBuffers not in an opengl context doesn't work good:-)
 
       

adi wrote

Multiplikation are slower than shifts.
And what is it with ((maxPoints<<1)+maxPoints)<<2 ) or maxPoints*3 :-)

Ah, nice trick

elect wrote

adi wrote

Multiplikation are slower than shifts.
And what is it with ((maxPoints<<1)+maxPoints)<<2 ) or maxPoints*3 :-)

Ah, nice trick

Well that was true for some CPUs a long time ago. Both the javac compiler, the runtime and even the CPU will recognize what *2 or /2 means and use the most efficient way. Use the one that is more readable for humans and the compiler will handle it.

http://softwareengineering.stackexchange.com/questions/250635/when-i-test-out-the-difference-in-time-between-shifting-and-multiplying-in-c-th

Interesting, nice to know, thanks

Most compilers can do peephole-optimizing, besides gnuc++ compiler:-)