I can connect a VBO data with the shader's attribute using the followings functions:
GLint attribVertexPosition = glGetAttribLocation(progId, "vertexPosition");
glEnableVertexAttribArray(attribVertexPosition);
glVertexAttribPointer(attribVertexPosition, 3, GL_FLOAT, false, 0, 0);
I analyze a legacy OpenGL code where a VBO is used with the following functions:
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, 0);
How that legacy code makes a connnection between a VBO data and the shader's attribute:
attribute vec3 vertexPosition;
?
For these fixed-function functions, the binding between the buffer and the vertex attribute is fixed. You don't tell glVertexArray which attribute it feeds; it always feeds the attribute gl_Vertex, which is defined for you in the shader. It cannot feed any user-defined attribute.
User-defined attributes are a separate set of attributes from the fixed-functioned ones.
Note that NVIDIA hardware is known to violate this rule. It aliases certain attribute locations with certain built-in vertex arrays, which allows user-defined attributes to receive data from fixed-function arrays. Perhaps you are looking at code that relies on this non-standard behavior that is only available on NVIDIA's implementation.
Related
I am writing a particle simulation which uses OpenGL >= 4.3 and came upon a "problem" (or rather the lack of one), which confuses me.
For the compute shader part, I use various GL_SHADER_STORAGE_BUFFERs which are bound to binding points via glBindBufferBase().
One of these GL_SHADER_STORAGE_BUFFERs is also used in the vertex shader to supply normals needed for rendering.
The binding in both the compute and vertex shader GLSL (these are called shaders 1 below) looks like this:
OpenGL part:
glBindBufferBase(GL_SHADER_STORAGE_BUFFER, 1, normals_ssbo);
GLSL part:
...
layout(std430, binding = 1) buffer normals_ssbo
{
vec4 normals[];
};
...
The interesting part is that in a seperate shader program with a different vertex shader (below called shader 2), the binding point 1 is (re-)used like this:
GLSL:
layout(location = 1) in vec4 Normal;
but in this case, the normals come from a different buffer object and the binding is done using a VAO, like this:
OpenGL:
glVertexAttribPointer(1, 4, GL_FLOAT, GL_FALSE, 0, 0);
As you can see, the binding point and the layout of the data (both are vec4) are the same, but the actual buffer objects differ.
Now to my questions:
Why does the VAO of shader 2, which is created and used after setting up shaders 1 (which use glBindBufferBase for binding), seamingly overwrite (?) the binding point, but shaders 1 still remember the SSBO binding and work fine without calling glBindBufferBase again before using them?
How does OpenGL know which of those two buffer objects the binding point (which in both cases is 1) should use? Are binding points created via VAO and glBindBufferBase simply completely seperate things? If that's the case, why does something like this NOT work:
layout(std430, binding = 1) buffer normals_ssbo
{
vec4 normals[];
};
layout(location = 1) in vec4 Normal;
Are binding points created via VAO and glBindBufferBase simply completely seperate things?
Yes, they are. That's why they're set by two different functions.
If that's the case, why does something like this NOT work:
Two possibilities present themselves. You implemented it incorrectly on the rendering side, or your driver has a bug. Which is which cannot be determined without seeing your actual code.
I want to know if its possible to draw in opengl 3.1+ core profile using vertex arrays ( client side rendering not immediate mode) without using the VBO. I know in opengl 3.1+ core profile use of VAO is essential. I want to know if its possible to draw without using VBO by using vertex arrays (client side vertex array not immediate mode).
PS I am talking about client side vertex array not immediate mode. I want to know if I can create a VAO without VBO
I read this somewhere in opengl spec Immediate-mode vertex attribute specification, client-side vertex arrays is depricated. Vertex Attributes must be stored in one or more Buffer Objects, or be specified explicitly using glVertexAttrib*(). Since OpenGL 3.2 using Vertex Array Objects is mandatory. So does this means I can specify vertex array data using the glVertexAttriPointer like this
glBindVertexArray(m_vaoHandle);
glEnableVertexAttribArray(m_attributes[POSITION_HANDLE]);
glVertexAttribPointer(m_attributes[POSITION_HANDLE], 3, GL_FLOAT, false, 0,vertexArray);
glEnableVertexAttribArray(m_attributes[TEXCOORDINATE_HANDLE]);
glVertexAttribPointer(m_attributes[TEXCOORDINATE_HANDLE], 2, GL_FLOAT, false, 0, textureArray);
glBindVertexArray(0);
Here vertexArray and textureArray are two arrays on CPU not VBO. Then while drawing them
glUseProgram(m_Program);
// Explicitly unbind buffer so attrib pointer knows to slurp in array.
glBindBuffer(GL_ARRAY_BUFFER, 0);
//bind vertex array object
glBindVertexArray(m_vaoHandle);
glDrawArrays(mode, 0, numVertices);
glBindVertexArray(0);
If its possible in OpenGL 3.1+, I would also like to know if its possible in OpenGLES 3.0
The core profile of OpenGL 3.2+ removed the ability to use client-side vertex arrays.
OpenGL ES 2.0 does allow the use of client-side vertex arrays, as do all higher versions of ES. However, the vertex shader input variable gl_VertexID (added in GLSL ES 3.00) is undefined when using client-side arrays. Oh, and client-side vertex arrays in ES 3.0 are mentioned in appendix F.1: Legacy Features. About them, it says:
The following features are present to maintain backward compatibility with OpenGL ES 2.0, but their use in not recommended as it is likely for these features to be removed in a future version.
While I wouldn't expect them to ever go away, clearly you are being advised not to use them.
As to the question of whether VAOs can work with client-side pointers at all, yes (when client-side pointers are supported at all, of course). VAOs always store vertex array state, no matter where those arrays come from. Calling glVertexAttribPointer with a client-side pointer will store the pointer inside the current VAO, just like it would store the buffer object+offset inside the VAO.
As an appendix to the accepted answer, you can 'kind of' emulate client arrays with UBO/SSBO.
On the other hand, it should not be too hard to implement your own 'client pointer' implementation via a hidden VBO and glBufferData.
I buffer normal data to a VBO, then point to it using glVertexAttribPointer:
glVertexAttribPointer(<INDEX?>, 3, GL_FLOAT, GL_FALSE, 0, NULL);
However, what value should I use for the first parameter, the index, if I wish the data to be bound to the gl_Normal attribute in the shaders?
I am using an NVidia card, and I read here https://www.opengl.org/sdk/docs/tutorials/ClockworkCoders/attributes.php that gl_Normal is always at index 2 for these types of cards. But how do I know that gl_Normal is at this index for other cards?
Additionally, using an index of 2 doesn't seem to be working, and the gl_Normal data in the shader is all (0,0,0).
I am aware of glGetAttribLocation and glBindAttribLocation, however the documentation specifically says the function will throw an error if attempted with one of the built in vertex attributes that begin with 'gl_'.
EDIT:
Using OpenGL 3.0 with GLSL 130.
You don't. When using the core profile and VAOs, none of the fixed-function vertex attributes exist.
Define your own vertex attribute for normals in your shader:
in vec3 myVertexNormal;
Get the attribute location (or bind it to a location of your choice):
normalsLocation = glGetAttribLocation(program, "myVertexNormal");
Then use glVertexAttribPointer with the location:
glVertexAttribPointer(normalsLocation, 3, GL_FLOAT, GL_FALSE, 0, NULL);
In the core profile, you must also do this for positions, texture coordinates, etc. as well. OpenGL doesn't actually care what the data is, as long as your vertex shader assigns something to gl_Position and your fragment shader assigns something to its output(s).
If you insist on using the deprecated fixed-function attributes and gl_Normal, use glNormalPointer instead.
I am want to know if the uniform and vertex attribute variable values remain if the shader program is unbound and then rebound
Basically I want to ask this question Do uniform values remain in GLSL shader if unbound?. But I want to know if this applies to both uniforms and attribure variables?
If I do this
glUseProgram(shader1);
// Now set uniforms.
glUniform4fv(m_uniforms[COLOR_HANDLE], 1, color.AsFloat());
glUniformMatrix4fv(m_uniforms[MVP_HANDLE], 1, false, matrix);
glBindBuffer(GL_ARRAY_BUFFER, bufferIndex);
glEnableVertexAttribArray(m_attributes[POSITION_HANDLE1]);
glEnableVertexAttribArray(m_attributes[POSITION_HANDLE2]);
glVertexAttribPointer(m_attributes[POSITION_HANDLE], 3, GL_FLOAT, false, 3 * sizeof(GLfloat), 0);
Now save the current program, vao, vbo binded.
Then use second program
glUseProgram(shader2);
//bind some new vao, vbo, set some uniform, vertex attribute variable.
element.draw();
Then again use the first shader program. Rebind the vbo, vao
glUseProgram(shader1); //Here, do the uniforms and attributes set in first shader program remain?
element.draw();
Does this mean that complete state is restored and draw calls will work. I think this should work if the uniforms and attribute values are retained. So when I restore the client program with glUseProgram, all uniforms and attributes set by client will be restored.
If not, then how can I save complete state. Onething is client has to set them again. but if that is not an option, what is other way around. How can I save the full state and restore it later. Is it even possible ?
PS: I need to do it for opengl 2.0, opengl 3.2+, opengl es 2.0, opengles 3.0
Uniforms
Uniforms are part of the shader program object. Thus they keep saved even when the program object is unbound. The OpenGL 4.5 Specification says to this:
7.6 Uniform Variables
Uniforms in the default uniform block, except for subroutine uniforms, are
program object-specific state. They retain their values once loaded, and their values
are restored whenever a program object is used, as long as the program object has
not been re-linked.
Attributes
Attribute bindings are part of the VAO state. When no VAO is bound then the default VAO is used (which is btw. not allowed in Core Profile). When using VAOs, restoring attribute bindings is quite simple since it is sufficient to rebind the VAO. In the other case, I would have a look at the "Associated Gets" section here.
I'm switching from HLSL to GLSL
When defining vertex attributes in of a vertexbuffer, one has to call
glVertexAttribPointer( GLuint index,
GLint size,
GLenum type,
GLboolean normalized,
GLsizei stride,
const GLvoid * pointer);
and pass an index. But how do I specify which index maps to which semantic in the shader?
for example gl_Normal. How can I specify that when using gl_Normal in a vertex shader, I want this to be the generic vertex attribute with index 1?
There is no such thing as a "semantic" in GLSL. There are just attribute indices and vertex shader inputs.
There are two kinds of vertex shader inputs. The kind that were removed in 3.1 (the ones that start with "gl_") and the user-defined kind. The removed kind cannot be set with glVertexAttribPointer; each of these variables had its own special function. gl_Normal had glNormalPointer, gl_Color had glColorPointer, etc. But those functions aren't around in core OpenGL anymore.
User-defined vertex shader inputs are associated with an attribute index. Each named input is assigned an index in one of the following ways, in order from most overriding to the default:
Through the use of the GLSL 3.30 or ARB_explicit_attrib_location extension syntax layout(location = #), where # is the attribute index. So if I have an input called position, I would give it index 3 like this:
layout(location = 3) in vec4 position;
This is my preferred method of handling this. Explicit_attrib_location is available on pretty much any hardware that is still being supported (that isn't Intel).
Explicit association via glBindAttribLocation. You call this function before linking the program. To do the above, we would do this:
GLuint program = glCreateProgram();
glAttachShader(program, some_shader);
glBindVertexAttrib(program, 3, "position");
glLinkProgram(program);
You can set multiple attributes. Indeed, you can set multiple attribute names to the same index. The idea with that is to be able to just set a bunch of mappings automatically and let OpenGL figure out which one works with the actual shader code. So you could have "position" and "axis" map to index 3, and as long as you don't put a shader into this system that has both of those inputs, you'll be fine.
Let OpenGL assign it. If you don't assign an attribute index to an attribute in one of the other ways, the GLSL linker will assign it for you. You can fetch the attribute post-linking with glGetAttribLocation.
I really don't advise this, because OpenGL will assign the indices arbitrarily. So every shader that uses an attribute named position may have the position in a different index. I don't think it's a good idea. So if you can't explicitly set it in the shader, then at least explicitly set it in your OpenGL code before linking. That way, you can have a convention about what attribute index 0 means, what index 1 means, etc.