OSX GL3.2 and VAO

[Ragnemalm]

Well, c) work for me under 10.7.

That seems unlikely. Especially if you're able to use `#version 330`, or if it works with just `#version 150`.

I only tested with version 150. Seemed to work just fine.

I go for getting locations, that feels best clean to me since it doesn't require me to break in with application specific code in my shader loader, and keeps the shaders clean.

It also means that you can't share VAOs and attribute bindings among different shaders. So if you have a mesh that gets rendered with two or more shaders (very possible. Multi-pass techniques often do it. Shadow map pass and lighting pass are both two separate programs), you have to have two separate sets of attribute bindings. Even though they may use the exact same vertex inputs.

The inability to mix and match shaders with meshes is not what I would call "clean". So I would suggest either explicitly binding attribute locations to known values with `glBindAttribLocation`, or use explicit attribute locations within shaders. The latter is what I do, and ever since that extension came out, I have never wanted to do anything else again.

Good, I needed some arguments for the other two. With three totally different ways, it isn't so easy. I don't like matching arbitrary numbers between the main program and shaders, variable names are more descriptive, but I consider all options.

Do you mean that calls like glEnableVertexAttribArray or glVertexAttribPointer will require me to bind the attributes to different values? But can't I just switch shader and rebind? I havn't tried multi-pass rendering under 3.2 yet, so maybe the problems will surface when I do. (I must port my shadow mapping examples anyway.)

[Alfonse Reinheart]

Do you mean that calls like glEnableVertexAttribArray or glVertexAttribPointer will require me to bind the attributes to different values? But can't I just switch shader and rebind?

Yes, you could. But that would require work. The whole point of VAOs is that you don't have to do that work. If you have to constantly be changing what attribute indices are used, you may as well just have a single global VAO and pretend VAOs don't exist.

[reakin]

1) as mentioned, Core Profile requires you to create a VAO and all attribute pointers must be set with VBOs bound. Check the spec.

Sorry if it's blatantly obvious, but I can't find this in the specification. Do you know which section? I also have the red book (7th edition, 3.1), I've looked through both but still can't find where it mandates using vertex array objects and vertex buffer objects. I'm only now trying to upgrade my code to GL 3.2 and this is currently where I'm at.

(now getting slightly off topic)
For instance, I was doing something like:

Vec2f vertices[3] = { Vec2f( 0, 0 ), Vec2f( 0.5, 1 ), Vec2f( 1, 0 ) };
unsigned int indices[3] = { 0, 1, 2 };
 
glEnableVertexAttribArray( mAttributes.position );
glVertexAttribPointer( mAttributes.position, 2, GL_FLOAT, GL_FALSE, 0, &vertices[0] ); // if VAO is bound, creates GL_INVALID_OPERATION
glDrawElements( GL_TRIANGLES, 3, GL_UNSIGNED_INT, &indices[0] );

Will this work in GL > 3?

[Ilian Dinev]

Page 331 of GL3.2 core spec,

Client vertex and index arrays - all vertex array attribute and element array
index pointers must refer to buffer objects. The default vertex array object
(the name zero) is also deprecated. Calling VertexAttribPointer when no
buffer object or no vertex array object is bound will generate an INVALID_-OPERATION error, as will calling any array drawing command when no ver-tex array object is bound.

"E.2. DEPRECATED AND REMOVED FEATURES"

[reakin]

I see, thanks for leading me there. I suppose indicating GL_DYNAMIC_DRAW is the only way to do this now.

Cheers,
Rich