OpenGL 3: glBindVertexArray invalidates GL_ELEMENT_ARRAY_BUFFER

Go To StackoverFlow.com

6

I was certain that if you bind a buffer via glBindBuffer(), you can safely assume that it stays bound, until the target is rebound through another call to glBindBuffer(). I was therefore quite surprised when I discovered that calling glBindVertexArray() sets the buffer bound to the GL_ELEMENT_ARRAY target to 0.

Here's the minimal C++ sample code:

GLuint buff;
glGenBuffers(1, &buff);
std::cout << "Buffer is " << buff << "\n";
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, buff);
GLuint vao;
glGenVertexArrays(1, &vao);

GLint bound_buff;
glGetIntegerv(GL_ELEMENT_ARRAY_BUFFER_BINDING, &bound_buff);
std::cout << "Bound before glBindVertexArray: " << bound_buff << "\n";

glBindVertexArray(vao);    
  // ^- an implicit glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,0); ?

glGetIntegerv(GL_ELEMENT_ARRAY_BUFFER_BINDING, &bound_buff);
std::cout << "Bound after glBindVertexArray: " << bound_buff << "\n";

I run this code immediately after initializing an OpenGL 3.2 device context and get the following output:

 Buffer is 1
 Bound before glBindVertexArray: 1
 Bound after glBindVertexArray: 0

The GL_ARRAY_BUFFER on the other hand is not changed by the call. I checked the OpenGL 3.2 spec (2.10) for glBindVertexArray and found no mention of that unexpected side effect.

  1. Is this behavior compliant with the Spec?
  2. If so, what other side effects can be expected from a call to glBindVertexArray?
  3. What is the rationale behind this?

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.

2012-04-03 20:21
by ComicSansMS
I 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? :- - Robinson 2012-04-03 20:39
But why does it only change the GLELEMENTARRAYBUFFER and not the GLARRAY_BUFFER - ComicSansMS 2012-04-03 20:46
Because 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 - Robinson 2012-04-03 21:00
That makes sense. However, I still feel a little puzzled by the fact that I couldn't find any mention of this side-effect in the docs. I'd really like to see some official paper confirming this is actually the desired behavior - ComicSansMS 2012-04-03 21:08
@ComicSansMS: FYI: if you're asking a question about OpenGL, you should use the OpenGL tag. Even for OpenGL 3 questions; use both tags - Nicol Bolas 2012-04-07 16:10


14

Vertex Array Objects encapsulate all of the state* necessary to render vertex data. Therefore, they must encapsulate what buffers you associated with attributes (via glVertexAttribPointer), GL_ELEMENT_ARRAY_BUFFER (needed for glDrawElement* calls), and so forth.

However, I still feel a little puzzled by the fact that I couldn't find any mention of this side-effect in the docs.

The specification clearly explains this, though it requires understanding how the spec works to see how.

OpenGL is a collection of state, which means that all OpenGL functions (except those that actually render something) modify OpenGL state. When you call glVertexAttribPointer, this function conceptually modifies some piece of internal OpenGL state.

OpenGL objects are defined by which pieces of OpenGL state they encapsulate. Thus, if a function modifies the state encapsulated by an object, then that function modifies the object itself. Binding an object means replacing the current pieces of state that they encapsulate with the current state of that object.

The ARB_vertex_array_object specification defines VAOs based on what state they encapsulate. It basically points at one of the OpenGL state tables and says, "VAOs are all of that." The core 3.x version of this functionality actually modifies the state tables to make it a bit more clear (same behavior, slightly different explanation thereof):

OpenGL 3.3 specification, section 2.10:

The resulting vertex array object is a new state vector, comprising all the state values listed in tables 6.4 and 6.5.

I'm not going to reprint tables 6.4 and 6.5; you can look them up yourself. But they clearly include GL_ELEMENT_ARRAY_BUFFER_BINDING and the various GL_VERTEX_ATTRIB_ARRAY_BUFFER_BIDNING (which are buffer objects).

* Note: VAOs do not contain the state set by the glVertexAttrib functions. These can affect the rendering if an attribute array is not enabled.

2012-04-07 16:09
by Nicol Bolas