Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 8 of 8

Thread: glVertexAttribFormat/glDrawArrays issue

  1. #1
    Junior Member Regular Contributor
    Join Date
    Aug 2006
    Posts
    218

    glVertexAttribFormat/glDrawArrays issue

    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:
    Code :
    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?:
    Code :
    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
    Last edited by elFarto; 06-21-2013 at 03:46 AM.

  2. #2
    Senior Member OpenGL Pro
    Join Date
    Jan 2012
    Location
    Australia
    Posts
    1,106
    I thought the attributes effect the currently bound buffer. In your second example the buffer is bound after the attributes are set

  3. #3
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,099
    Quote Originally Posted by tonyo
    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 addresses out-of-bounds buffer accesses cause by incorrect attrib array specification.

    Quote Originally Posted by elFarto
    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.

    Quote Originally Posted by elFarto
    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:

    Quote Originally Posted by The GL Spec
    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 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 or are GL 4.3 capable.
    Last edited by thokra; 06-20-2013 at 07:08 AM.

  4. #4
    Junior Member Regular Contributor
    Join Date
    Aug 2006
    Posts
    218
    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

  5. #5
    Senior Member OpenGL Pro
    Join Date
    Jan 2012
    Location
    Australia
    Posts
    1,106
    EDIT: BTW, glVertexAttribFormat and consorts are the right way to go if your implementation and hardware offer support for GL_ARB_vertex_attrib_binding or are GL 4.3 capable.

    What is the advantage of this new format?

  6. #6
    Junior Member Regular Contributor
    Join Date
    Aug 2006
    Posts
    218
    Quote Originally Posted by tonyo_au View Post
    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

  7. #7
    Senior Member OpenGL Pro
    Join Date
    Jan 2012
    Location
    Australia
    Posts
    1,106
    So does this mean it is better to have one VAO per format and swap buffer that share that format with 4.3?

  8. #8
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,099
    Quote Originally Posted by elFarto
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •