Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

OpenGL 3: glBindVertexArray invalidates GL_ELEMENT_ARRAY_BUFFER

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.

like image 891
ComicSansMS Avatar asked Apr 03 '12 20:04

ComicSansMS


1 Answers

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.

like image 137
Nicol Bolas Avatar answered Oct 19 '22 13:10

Nicol Bolas