Databases
StackOverflow2013
Postsdbo
POOpenGL 3: glBindVertexArray invalidates GL_ELEMENT_ARRAY_BUFFER
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POOpenGL 3: glBindVertexArray invalidates GL_ELEMENT_ARRAY_BUFFER
    primarykey
    data
    text
    <p>I was certain that if you bind a buffer via <code>glBindBuffer()</code>, you can safely assume that it stays bound, until the target is rebound through another call to <code>glBindBuffer()</code>. I was therefore quite surprised when I discovered that calling <code>glBindVertexArray()</code> sets the buffer bound to the GL_ELEMENT_ARRAY target to 0.</p> <p>Here's the minimal C++ sample code:</p> <pre><code>GLuint buff; glGenBuffers(1, &amp;buff); std::cout &lt;&lt; "Buffer is " &lt;&lt; buff &lt;&lt; "\n"; glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, buff); GLuint vao; glGenVertexArrays(1, &amp;vao); GLint bound_buff; glGetIntegerv(GL_ELEMENT_ARRAY_BUFFER_BINDING, &amp;bound_buff); std::cout &lt;&lt; "Bound before glBindVertexArray: " &lt;&lt; bound_buff &lt;&lt; "\n"; glBindVertexArray(vao); // ^- an implicit glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,0); ? glGetIntegerv(GL_ELEMENT_ARRAY_BUFFER_BINDING, &amp;bound_buff); std::cout &lt;&lt; "Bound after glBindVertexArray: " &lt;&lt; bound_buff &lt;&lt; "\n"; </code></pre> <p>I run this code immediately after initializing an OpenGL 3.2 device context and get the following output:</p> <pre><code> Buffer is 1 Bound before glBindVertexArray: 1 Bound after glBindVertexArray: 0 </code></pre> <p>The GL_ARRAY_BUFFER on the other hand is <em>not</em> changed by the call. I checked the OpenGL 3.2 spec (2.10) for <code>glBindVertexArray</code> and found no mention of that unexpected side effect.</p> <ol> <li>Is this behavior compliant with the Spec?</li> <li>If so, what other side effects can be expected from a call to <code>glBindVertexArray</code>?</li> <li>What is the rationale behind this?</li> </ol> <p>I tested this on an nvidia card on a Win XPx64 machine with the 296.10 WHQL driver. A quick test on OS X Lion with an nvidia GT330M gave the same results.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USNicol Bolas
    1. USComicSansMS
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POOpenGL 3: glBindVertexArray invalidates GL_ELEMENT_ARRAY_BUFFER
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POOpenGL 3: glBindVertexArray invalidates GL_ELEMENT_ARRAY_BUFFER
      1. USrotoglup
      1. VTFavorite
    3. VO
      singulars
      1. POOpenGL 3: glBindVertexArray invalidates GL_ELEMENT_ARRAY_BUFFER
      1. USComicSansMS
      1. VTBountyStart
    1. COI think binding a VAO is implicitly binding the element and vertex array buffers. That's what VAO's are for. If you bind a VAO and then bind an index and vertex buffer, those buffers are then implicitly bound whenever you bind the VAO later. So binding the VAO above has presumably implicitly set the element and vertex arrays to zero as these have not been included by you in the VAO object. Did that make sense? :-)
      singulars
      1. POOpenGL 3: glBindVertexArray invalidates GL_ELEMENT_ARRAY_BUFFER
      1. USRobinson
    2. COBut why does it only change the GL_ELEMENT_ARRAY_BUFFER and not the GL_ARRAY_BUFFER?
      singulars
      1. POOpenGL 3: glBindVertexArray invalidates GL_ELEMENT_ARRAY_BUFFER
      1. USComicSansMS
    3. COBecause the array buffer is the vertex buffer (at least the various glEnableVertexAttribArray and glVertexAttribPointer calls your make with it), and it includes an element buffer as part of that state.
      singulars
      1. POOpenGL 3: glBindVertexArray invalidates GL_ELEMENT_ARRAY_BUFFER
      1. USRobinson
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload