PDA

View Full Version : glVertexAttribFormat/glDrawArrays issue



elFarto
06-20-2013, 05:04 AM
Hi

EDIT: Ok, I've fixed the problem, turns out you can't pass 0 as the stride to BindVertexBuffer like you can to VertexAttribPointer you actually have to specify the correct stride, otherwise each element gets uses the 0th attribute in the buffer.

Can anyone tell me why this would work:

GL20.glEnableVertexAttribArray(0);
GL15.glBindBuffer(GL15.GL_ARRAY_BUFFER, buffers[0]);
GL20.glVertexAttribPointer(0, 4, GL11.GL_FLOAT, false, 0, 0);
GL11.glDrawArrays(GL11.GL_TRIANGLES, 0, 3);
But this would fail?:

GL20.glEnableVertexAttribArray(0);
GL43.glVertexAttribFormat(0, 4, GL11.GL_FLOAT, false, 0);
GL43.glVertexAttribBinding(0, 0);
GL43.glBindVertexBuffer(0, buffers[0], 0, 0); //EDIT: Stride can't be 0, it must be the correct value
GL11.glDrawArrays(GL11.GL_TRIANGLES, 0, 3);
Thanks & Regards
elFarto

tonyo_au
06-20-2013, 06:15 AM
I thought the attributes effect the currently bound buffer. In your second example the buffer is bound after the attributes are set

thokra
06-20-2013, 07:00 AM
I thought the attributes effect the currently bound buffer.

Attrib arrays aren't buffer object state but vertex array object state. The way vertices are pulled is affected - not the buffer object. Even in olden times they weren't buffer object state, becaus you could use them to specify client side vertex arrays which didn't source a buffer object's data store. Client-side vertex arrays also preceeded buffer objects.

Incidentally, GL_ARB_robustness (http://www.opengl.org/registry/specs/ARB/robustness.txt) addresses out-of-bounds buffer accesses cause by incorrect attrib array specification.


Can anyone tell me why this would work

Because you're most likely using the compat profile. It wouldn't, of course, if you were using a core context.


But this would fail

Because VertexAttribFormat/VertexAttribBinding/BindVertexBuffer are GL 4.3 functions with different error conditions right from the get go which don't adhere to compat profile premises - unlike VertexAttribPointer/(Enable|Disable)VertexAttribArray which have been adapted when client side vertex arrays were canned due to deprecation and subsequent removal.

The GL 4.3 core spec states in multiple places regarding glVertexAttribPointer/glVertexAttribFormat/(Enable|Disable)VertexAttribArray:


An INVALID_OPERATION error is generated if no vertex array object is bound.

There are also multiple missing errors about this in the official API reference not stating this, even for the GL4 refs. Therefore, please use the API ref in our Wiki (http://www.opengl.org/wiki/Category:Core_API_Reference) as it is much better maintained (and can be maintained by all of us, actually).

EDIT: BTW, glVertexAttribFormat and consorts are the right way to go if your implementation and hardware offer support for GL_ARB_vertex_attrib_binding (http://www.opengl.org/registry/specs/ARB/vertex_attrib_binding.txt) or are GL 4.3 capable.

elFarto
06-20-2013, 07:46 AM
Hi

Right, I was using the core profile before (or at least, not specifying I wanted compat, and LWJGL decided to give me core), and the first one wouldn't work until I used compat profile. And I do get an error about a VAO not being bound with the core profile.

However, I don't get any errors with that second piece of code, it's just that nothing gets drawn. It's the same using a VAO in core profile, or no VAO in compat profile.

I'm using a Geforce 570, so it does support OpenGL 4.3 and ARB_vertex_attrib_binding. I even updated the driver this morning to the latest one.

Regards
elFarto

tonyo_au
06-20-2013, 06:19 PM
EDIT: BTW, glVertexAttribFormat and consorts are the right way to go if your implementation and hardware offer support for GL_ARB_vertex_attrib_binding (http://www.opengl.org/registry/specs/ARB/vertex_attrib_binding.txt) or are GL 4.3 capable.
What is the advantage of this new format?

elFarto
06-20-2013, 11:28 PM
What is the advantage of this new format?[/COLOR]
It exactly matches what the hardware does. This means you can change the format of the vertices and which buffers the data is retrieved from independently. This is good because changing the format is slower than just changing which buffer.

Regards
elFarto

tonyo_au
06-21-2013, 05:54 AM
So does this mean it is better to have one VAO per format and swap buffer that share that format with 4.3?

thokra
06-21-2013, 06:29 AM
EDIT: Ok, I've fixed the problem, turns out you can't pass 0 as the stride to BindVertexBuffer like you can to VertexAttribPointer you actually have to specify the correct stride, otherwise each element gets uses the 0th attribute in the buffer.

Yep, the reason I gave above wasn't actually correct because it turns out that the 4.3 compat spec doesn't require a VAO to be bound. Yippie...

I have no idea why the ARB would not enforce a VAO being present when using functionality that "just" came in with the latest spec. A feature which is virtually non-existent in any real code which might rely on compatibility. Guess this would have been an opportunity to incentivise transitioning to core.