Related
I am just starting to learn OpenGL today from this tutorial: http://openglbook.com/the-book/
I got to chapter 2, where I draw a triangle, and I understand everything except VAOs (is this acronym OK?). The tutorial has this code:
glGenVertexArrays(1, &VaoId);
glBindVertexArray(VaoId);
While I understand that the code is necessary, I have no clue what it does. Although I never use VaoId past this point (except to destroy it), the code does not function without it. I am assuming this is because it is required to be bound, but I don't know why. Does this exact code just need to be part of every OpenGL program? The tutorial explains VAOs as:
A Vertex Array Object (or VAO) is an object that describes how the vertex attributes are stored in a Vertex Buffer Object (or VBO). This means that the VAO is not the actual object storing the vertex data, but the descriptor of the vertex data. Vertex attributes can be described by the glVertexAttribPointer function and its two sister functions glVertexAttribIPointer and glVertexAttribLPointer, the first of which we’ll explore below.
I don't understand how the VAO describes the vertex attributes. I have not described them in any way. Does it get the information from the glVertexAttribPointer? I guess this must be it. Is the VAO simply a destination for the information from glVertexAttribPointer?
On a side note, is the tutorial I am following acceptable? Is there anything I should watch out for or a better tutorial to follow?
"Vertex Array Object" is brought to you by the OpenGL ARB Subcommittee for Silly Names.
Think of it as a geometry object. (As an old time SGI Performer programmer, I call them geosets.) The instance variables/members of the object are your vertex pointer, normal pointer, color pointer, attrib N pointer, ...
When a VAO is first bound, you assign these members by calling
glEnableClientState(GL_VERTEX_ARRAY); glVertexPointer...;
glEnableClientState(GL_NORMAL_ARRAY); glNormalPointer...;
and so on. Which attributes are enabled and the pointers you supply are stored in the VAO.
After that when you bind the VAO again, all the those attributes and pointers also become current. So one glBindVertexArray call is equivalent to all the code previously needed to set up all the attributes. It's handy for passing geometry around between functions or methods without having to create your own structs or objects.
(One time setup, multiple use is the easiest way to use VAOs, but you can also change attributes just by binding it and doing more enable/pointer calls. VAOs are not constants.)
More info in response to Patrick's questions:
The default for a newly created VAO is that it's empty (AFAIK). No geometry at all, not even vertexes, so if you try to draw it, you'll get an OpenGL error. This is reasonably sane, as in "initialize everything to False/NULL/zero".
You only need to glEnableClientState when you set things up. The VAO remembers the enable/disable state for each pointer.
Yes the VAO will store glEnableVertexAttribArray and glVertexAttrib. The old vertex, normal, color, ... arrays are the same as attribute arrays, vertex == #0 and so on.
I always think about VAO as an array of data buffers used by OpenGL. Using modern OpenGL you will create a VAO and Vertex Buffer Objects.
//vaoB is a buffer
glGenVertexArrays(1, vaoB); //creates one VAO
glBindVertexArray(vao.get(0));
glGenBuffers(vbo.length, vbo, 0); //vbo is a buffer
glBindVertexArray(vao.get(1));
glGenBuffers(vbo1.length, vbo1, 0); //vbo1 is a buffer
glBindVertexArray(vao.get(2));
glGenBuffers(vbo2.length, vbo2, 0); //vbo2 is a buffer
The next step is to bind data to a buffer:
glBindBuffer(GL_ARRAY_BUFFER, vbo[0]);
glBufferData(GL_ARRAY_BUFFER,vertBuf.limit()*4, vertBuf, GL_STATIC_DRAW); //vertf buf is a floatbuffer of vertices
At this point OpenGL Sees:
Now we can use glVertexAttribPointer to tell OpenGL what the data in the buffer represents:
glBindBuffer(GL_ARRAY_BUFFER, 0); //bind VBO at 0
glVertexAttribPointer(0, 3, GL_FLOAT, false, 0, 0); //each vertex has 3 components of size GL_FLOAT with 0 stride (space) between them and the first component starts at 0 (start of data)
OpenGL now has the data in the buffer and knows how the data is organized into vertices. The same process can be applied to texture coordinates etc but for texture coordinates there would be two values.
glBindBuffer(GL_ARRAY_BUFFER, vbo[1]);
glBufferData(GL_ARRAY_BUFFER,coordBuf.limit()*4, coordBuf, GL_STATIC_DRAW);
glVertexAttribPointer(0, 2, GL_FLOAT, false, 0, 0);
Next you can bind texture and draw arrays, you will want to create a Vert and Frag shader, compile and attach it to a program (not included here).
glActiveTexture(textureID); //bind our texture
glBindTexture(GL_TEXTURE_2D, textureID);
glDrawArrays(GL_TRIANGLES,0,6); //in this case 6 indices are used for two triangles forming a square
Vertex Array Objects are like macros in word processing programs and the like. A good description is found here.
Macros just remember the actions you did, such as activate this attribute, bind that buffer, etc. When you call glBindVertexArray( yourVAOId ), it simply replays those attribute pointer bindings and buffer bindings.
So your next call to draw uses whatever was bound by the VAO.
VAO's don't store vertex data. No. The vertex data is stored in a vertex buffer or in an array of client memory.
VAO is an object that represents the vertex fetch stage of the OpenGL pipeline and is used to supply input to the vertex shader.
You can create vertex array object like this
GLuint vao;
glCreateVertexArrays(1, &vao);
glBindVertexArray(vao);
First let' do a simple example. Consider such an input parameter in a shader code
layout (location = 0) in vec4 offset; // input vertex attribute
To fill in this attribute we can use
glVertexAttrib4fv(0, attrib); // updates the value of input attribute 0
Although the vertex array object stores these static attribute values for
you, it can do a lot more.
After creating vertex array object we can start filling in its state. We will ask OpenGL to fill it automatically using the data stored in a buffer object that we supply. Each vertex attribute gets to fetch data from a buffer bound to one of several vertex buffer bindings. For this end we use glVertexArrayAttribBinding(GLuint vao, GLuint attribindex, GLuint bindingindex). Also we use the glVertexArrayVertexBuffer() function to bind a buffer to one of the vertex buffer bindings. We use the glVertexArrayAttribFormat() function to describe the layout and format of the data, and finally we enable automatic filling of the attribute by calling glEnableVertexAttribArray().
When a vertex attribute is enabled, OpenGL will feed data to the vertex shader based on the format and location information you’ve provided with
glVertexArrayVertexBuffer() and glVertexArrayAttribFormat(). When
the attribute is disabled, the vertex shader will be provided with the static information you provide with a call to glVertexAttrib*().
// First, bind a vertex buffer to the VAO
glVertexArrayVertexBuffer(vao, 0, buffer, 0, sizeof(vmath::vec4));
// Now, describe the data to OpenGL, tell it where it is, and turn on automatic
// vertex fetching for the specified attribute
glVertexArrayAttribFormat(vao, 0, 4, GL_FLOAT, GL_FALSE, 0);
glEnableVertexArrayAttrib(vao, 0);
And code in a shader
layout (location = 0) in vec4 position;
After all you need to call to glDeleteVertexArrays(1, &vao).
You can read OpenGL SuperBible to understand it better.
I was trying to understand this as well and now that I think I do, it would be prudent to post a code example aimed at
people less familiar with OpenGL architecture, as I found the previous examples not very illuminating and most tutorials
just tell you to copy paste the code without explaining it.
(This is in C++ but the code can be easily translated to C)
In this example, we'll be rendering a rectangle, which has 4 vertices. Each vertex has a position (vec3, xyz), texture coordinate (vec2, uv) and color attribute (vec4, rgba).
I think it's cleanest to separate each attribute into their own array:
float positions[] = {
+0.5, +0.5, 0,
+0.5, -0.5, 0,
-0.5, -0.5, 0,
-0.5, +0.5, 0
};
float colors[] = {
1, 1, 1, 1,
1, 1, 1, 1,
1, 1, 1, 1,
1, 1, 1, 1
};
float tex_coords[] = {
0, 0,
0, 1,
1, 1,
1, 0
};
Our vertex array object will describe the four vertices with these properties.
First, we need to create the vertex array:
GLuint vertex_array;
glGenVertexArrays(1, &vertex_array);
Each vertex array has a number of buffers, these can be thought of as properties of the array. Each vertex array has an
arbitrary number of "slots" for the buffers. Along with which buffer is in which slot, it saves the CPU-side pointer to
the data for the buffer, and the CPU-side datas format. We need to make OpenGL aware of both which slot to use, where the
data is, and how it is formatted.
The buffers slots are indexed, so the first buffer is index 0, the second is 1, etc.
These locations correspond to the layout defined in the vertex shader:
// vertex shader
std::string _noop_vertex_shader_source = R"(
#version 420
layout (location = 0) in vec3 _position_3d; // slot 0: xyz
layout (location = 1) in vec4 _color_rgba; // slot 1: rgba
layout (location = 2) in vec2 _tex_coord; // slot 2: uv
out vec2 _vertex_tex_coord;
out vec4 _vertex_color_rgba;
void main()
{
gl_Position = vec4(_position_3d.xy, 1, 1); // forward position to fragment shader
_vertex_color_rgba = _color_rgba; // forward color to fragment shader
_vertex_tex_coord = _tex_coord; // forward tex coord to fragment shader
}
)";
We see that the position property is at location 0, the color property at 1 and the tex coords at 2. We'll store these
for clarity:
// property locations from our shader
const auto vertex_pos_location = 0;
const auto vertex_color_location = 1;
const auto vertex_tex_coord_location = 2;
We now need to tell OpenGL the information about each buffer outlined above:
// bind the array, this makes OpenGL aware that we are modifying it with future calls
glBindVertexArray(vertex_array);
// create the position buffer
glGenBuffers(1, &position_buffer);
// bind the buffer so opengl knows we are currently operating on it
glBindBuffer(GL_ARRAY_BUFFER, position_buffer);
// tell opengl where the data pointer is
glBufferData(GL_ARRAY_BUFFER, sizeof(positions), positions, GL_STATIC_DRAW);
// tell opengl how the data is formatted
glVertexAttribPointer(vertex_pos_location, 3, GL_FLOAT, GL_FALSE, 0, (void*) 0);
// tell opengl that this slot should be used
glEnableVertexAttribArray(vertex_pos_location);
Here, we generate a buffer that will hold our position data. For glVertexAttribPointer, we choose the
correct location, 3 elements (as the positions are xyz coordinates), and no offset or stride.
Because we have a separate array for all our properties, we can leave both as 0.
Similar to the position, we generate and fill the buffers for the color and tex coord property:
// color
glGenBuffers(1, &color_buffer); // generate
glBindBuffer(GL_ARRAY_BUFFER, color_buffer); // bind
glBufferData(GL_ARRAY_BUFFER, sizeof(colors), colors, GL_STATIC_DRAW); // set pointer
glVertexAttribPointer(vertex_color_location, 4, GL_FLOAT, GL_FALSE, 0, (void*) 0); // set data format
glEnableVertexAttribArray(vertex_color_location); // enable slot
// tex coords
glGenBuffers(1, &tex_coord_buffer);
glBindBuffer(GL_ARRAY_BUFFER, tex_coord_buffer);
glBufferData(GL_ARRAY_BUFFER, sizeof(tex_coords), tex_coords, GL_STATIC_DRAW);
glVertexAttribPointer(vertex_tex_coord_location, 2, GL_FLOAT, GL_FALSE, 0, (void*) 0);
glEnableVertexAttribArray(vertex_tex_coord_location);
Where we chose 4 elements for the colors because they are in RGBA format and 2 for the tex coords for obvious reasons.
The last thing we need to render a vertex array is an element buffer. These can be thought of as a list of
indices that define which order the vertices will be rendered in. For us, we want to render the
rectangle as two tris in a triangle fan, so we choose the following element buffer:
// vertex order
static uint32_t indices[] = {
0, 1, 2, 1, 2, 3
};
glGenBuffers(1, &element_buffer); // generate
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, element_buffer); // bind
glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices, GL_STATIC_DRAW) // set pointer
We do not need to enable the element buffers slot, it is separate from the vertex array. We don't have to specify the format of the elements buffer here, that will be done during glDrawElements in the render step.
So why all this? All these functions tell OpenGL where to look for the data for the vertices. Specifying the pointers to
the correct buffer data and their layout, if we now bind the vertex array during a render step:
glUseProgram(shader.get_program_id()); // shader program with our vertex shader
glBindVertexArray(vertex_array);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, element_buffer);
glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_INT, 0);
Where 6 is the number of elements in the element buffer.
This is all that's needed to correctly update the in values in the vertex shader. OpenGL will move the data from
our CPU-side positions, colors and tex_coords into the correct locations 0, 1 and 2 of the vertex shader respectively.
We don't need to bind anything else, the vertex array remembers what we gave it and does it for us, which is why it's convenient and should be preferred in modern OpenGL.
In summary:
Each vertex array has n buffers for arbitrary properties and 1 element buffer. For each property / buffer, we need to
a) generate it (glGenBuffers)
b) bind it (glBindBuffer(GL_ARRAY_BUFFER)
c) tell OpenGL where the data is located in RAM (glBufferData)
d) tell OpenGL how the data is formatted (glVertexAttribPointer)
e) tell OpenGL to use that slot (glEnableVertexAttribArray)
for the element buffer, we only need to generate it, bind it to GL_ELEMENT_ARRAY_BUFFER, then tell opengl
where the data is.
Hopefully that helped shed some light on things. I'm almost positive there will be factual errors in this post as
I'm also mostly new to OpenGL but this was the way I conceptualized it to get my code working.
I've been working on project using OpenGL. Particles are rendered using instanced draw calls.
The issue is that sometimes glDrawElementsInstanced will not render anything. And no errors are reported. Other models and effects render fine. But no particles in
my particle system will render. The draw call looks something like
ec(glBindVertexArray(vao));
ec(glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ebo));
ec(glDrawElementsInstanced(GL_TRIANGLES, triangleElementIndices.size(), GL_UNSIGNED_INT, reinterpret_cast<void*>(0), instanceCount));
ec is a macro used to error check opengl. it effectively does this:
while (GLenum error = glGetError()){
std::cerr << "OpenGLError:" << std::hex << error << " " << functionName << " " << file << " " << line << std::endl;
}
The issue rendering particles is more prevalent in Release mode, rather than debug mode; but occurs in both modes. The issue occurs about 8/10 in release mode and 1/10 in debug mode.
Below is the rendering process for particles:
for each instanced drawcall...
bind a shared vertex buffer object(vbo)
put data into that vertex buffer object (vbo)
iterate over many vertex array objects (vao), associate the VBO with them and set up vertex attributes
render each vao
All of the objects share the same VBO, but the are rendered sequentially. The entire application is currently single threaded, so that shouldn't be an issue.
A given frame for particles A (two vaos), and B(one vao) would be like:
-buffer A's data into vertex buffer named VBO
-bind A_vao1
-set up A's instance vertex attributes
-bind A_vao2
-set up A's instance vertex attributes
-render A_vao1
-render A_vao2
-buffer B's data into vertex buffer name VBO (no glGenBuffers, this is same buffer)
-bind B_vao1
-set up B's instance vertex attributes
-render B_vao1
Is there an obvious problem with that approach?
The source below has been simplified, but I left most of the relevant parts. Unlike what I have above, it actually uses 2 shared vertex buffer objects (VBOs), one for matrix4s, and one for vector4s.
GLuint instanceMat4VBO = ... //valid created vertex buffer objects
GLuint instanceVec4VBO = ... //valid created vertex buffer objects
//iterate over all the instnaces; data is stored in class EffectInstanceData
for(EffectInstanceData& eid : instancedEffectsData)
{
if (eid.numInstancesThisFrame > 0)
{
// ---- BUFFER data ---- before binding it to all VAOs (model's may have multiple meshes, each with their own VAO)
ec(glBindBuffer(GL_ARRAY_BUFFER, instanceMac4VBO)); //BUFFER MAT4 INSTANCE DATA
ec(glBufferData(GL_ARRAY_BUFFER, sizeof(glm::mat4) * eid.mat4Data.size(), &eid.mat4Data[0], GL_STATIC_DRAW));
ec(glBindBuffer(GL_ARRAY_BUFFER, instanceVec4VBO)); //BUFFER VEC4 INSTANCE DATA
ec(glBufferData(GL_ARRAY_BUFFER, sizeof(glm::vec4) * eid.vec4Data.size(), &eid.vec4Data[0], GL_STATIC_DRAW));
//meshes may have multiple VAO's that need rendering, set up buffers with instance data for each VAO before instance rendering is done
for (GLuint effectVAO : eid.effectData->mesh->getVAOs())
{
ec(glBindVertexArray(effectVAO));
{ //set up mat4 buffer
ec(glBindBuffer(GL_ARRAY_BUFFER, instanceMat4VBO));
GLsizei numVec4AttribsInBuffer = 4 * eid.numMat4PerInstance;
size_t packagedVec4Idx_matbuffer = 0;
//pass built-in data into instanced array vertex attribute
{
//mat4 (these take 4 separate vec4s)
{
//model matrix
ec(glEnableVertexAttribArray(8));
ec(glEnableVertexAttribArray(9));
ec(glEnableVertexAttribArray(10));
ec(glEnableVertexAttribArray(11));
ec(glVertexAttribPointer(8, 4, GL_FLOAT, GL_FALSE, numVec4AttribsInBuffer * sizeof(glm::vec4), reinterpret_cast<void*>(packagedVec4Idx_matbuffer++ * sizeof(glm::vec4))));
ec(glVertexAttribPointer(9, 4, GL_FLOAT, GL_FALSE, numVec4AttribsInBuffer * sizeof(glm::vec4), reinterpret_cast<void*>(packagedVec4Idx_matbuffer++ * sizeof(glm::vec4))));
ec(glVertexAttribPointer(10, 4, GL_FLOAT, GL_FALSE, numVec4AttribsInBuffer * sizeof(glm::vec4), reinterpret_cast<void*>(packagedVec4Idx_matbuffer++ * sizeof(glm::vec4))));
ec(glVertexAttribPointer(11, 4, GL_FLOAT, GL_FALSE, numVec4AttribsInBuffer * sizeof(glm::vec4), reinterpret_cast<void*>(packagedVec4Idx_matbuffer++ * sizeof(glm::vec4))));
ec(glVertexAttribDivisor(8, 1));
ec(glVertexAttribDivisor(9, 1));
ec(glVertexAttribDivisor(10, 1));
ec(glVertexAttribDivisor(11, 1));
}
}
}
{ //set up vec4 buffer
ec(glBindBuffer(GL_ARRAY_BUFFER, instanceVec4VBO));
GLsizei numVec4AttribsInBuffer = eid.numVec4PerInstance;
size_t packagedVec4Idx_v4buffer = 0;
{
//package built-in vec4s
ec(glEnableVertexAttribArray(7));
ec(glVertexAttribPointer(7, 4, GL_FLOAT, GL_FALSE, numVec4AttribsInBuffer * sizeof(glm::vec4), reinterpret_cast<void*>(packagedVec4Idx_v4buffer++ * sizeof(glm::vec4))));
ec(glVertexAttribDivisor(7, 1));
}
}
}
//activate shader
... code setting uniforms on shaders, does not appear to be issue...
//instanced render
for (GLuint vao : eid.effectData->mesh->getVAOs()) //this actually results in function calls to a mesh class instances, but effectively is doing this loop
{
ec(glBindVertexArray(vao));
ec(glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ebo));
ec(glDrawElementsInstanced(GL_TRIANGLES, triangleElementIndices.size(), GL_UNSIGNED_INT, reinterpret_cast<void*>(0), instanceCount));
}
//clear data for next frame
eid.clearFrameData();
}
}
ec(glBindVertexArray(0));//unbind VAO's
Is any of this visibility wrong? I've debugged with RenderDoc and when the issue is not present, a draw call is present in the event browser like the image:
But when the issue does happen, the draw call does not appear at all in RenderDoc like the following image:
This seems very strange to me. I've verified with the debugger that the draw call is being executed. But it seems to silently fail.
I've tried debugging with nvidia nsight, but cannot reproduce it when launched through nvidia nsight.
I've verified
instance VBO buffer size doesn't change or grow too large, its size is stable
uniforms are be correctly finding values
vao binding appears to happen in correct orderings
System specs: windows 10; Opengl3.3, 8gb memory; i7-8700k, NVIDIA GeForce GTX TITAN X
Also observed issue on on my laptop, with roughly same reproduction rates. It has an intel graphics chip.
github link to actual source if anyone tries to compile let me know, you need to replace the hidden .suo with the copy I made to automatically fill out the linker settings. function: ParticleSystem::handlePostRender
It turns out this isn't an issue with instancing. I implemented a non-instance version and had the same issue. The real issue is with my rendering systems. Currently the swap buffer and the render particles are listening to the same delegate (event) and occasionally the swap buffers will come first when the event broadcasts. So the ordering was:
clear screen
render scene
swap buffers
render particles
clear screen
render scene
swap buffers
render particles
So, the particles were never visible because they were immediately cleared at what was supposed to be the start of the next frame.
I am trying to run Piccante image processing library on Intel GPU. The library is using OpenGL shaders to apply filters on images. The library is using OpenGL 4.0 according to its documentation, so I had to make a small modifications in order to get it to run in OpenGL 3.3 context, which is supported by Intel Mesa 10.3 driver.
I changed the following line (in buffer_op.hpp) when the shader is created:
prefix += glw::version("330"); // before glw::version("400")
After this modification the my program still works perfectly fine on nVidia GPU, even while initializing the OpenGL context as OpenGL 3.3 (Core Profile).
On the Intel GPU the program works partly. It seems to work fine as long as the images are single channel. When the images are RGB the drawing now longer works, and my images ends up black.
I have traced down the error to the following line in (quad.hpp):
void Render()
{
glBindVertexArray(vao); // (I checked that vao is not 0 here)
glDrawArrays(GL_TRIANGLE_STRIP, 0, 4); // glGetError() = 1286 (GL_INVALID_OPERATION)
glBindVertexArray(0);
}
This is the initiations of the Vertex Array Object and the Vertex Buffer Object:
float *data = new float[8];
data[0] = -halfSizeX;
data[1] = halfSizeY;
data[2] = -halfSizeX;
data[3] = -halfSizeY;
data[4] = halfSizeX;
data[5] = halfSizeY;
data[6] = halfSizeX;
data[7] = -halfSizeY;
//Init VBO
glGenBuffers(1, &vbo[0]);
glBindBuffer(GL_ARRAY_BUFFER, vbo[0]);
glBufferData(GL_ARRAY_BUFFER, 8 * sizeof(GLfloat), data, GL_STATIC_DRAW);
glBindBuffer(GL_ARRAY_BUFFER, 0);
//Init VAO
glGenVertexArrays(1, &vao);
glBindVertexArray(vao);
glBindBuffer(GL_ARRAY_BUFFER, vbo[0]);
glVertexAttribPointer(0, 2, GL_FLOAT, GL_FALSE, 0, 0);
glEnableVertexAttribArray(0);
glBindVertexArray(0);
glDisableVertexAttribArray(0);
glBindBuffer(GL_ARRAY_BUFFER, 0);
This is the generated fragment shader I am trying to run:
#version 330
uniform sampler2D u_tex_1;
uniform vec4 u_val_0;
uniform vec4 u_val_1;
in vec2 v_tex_coord;
out vec4 f_color;
void main(void) {
ivec2 coords = ivec2(gl_FragCoord.xy);
vec4 ret = u_val_0;
f_color = ret;
}
I checked that the vertex shader and fragment shader compiles and links successfully. Does this mean that the shader should be GLSL 3.3 compatible and the problem is not within the shader but somewhere else?
What could be causing the program to fail on RGB images while it works fine on single channel images?
What could cause the program to fail with Intel Mesa 10.3 driver while working fine with nVidia driver when the context is initialized on both as OpenGL 3.3?
There seems to be a lot of reasons that could cause GL_INVALID_OPERATION when rendering. What other things could I check in order to trace down the error?
Thanks a lot for any help!
I've been talking with Francesco Banterle, the author of Piccante library and he pointed out the following:
Regarding Intel Drivers, the issue is due to the fact these drivers do
not automatically align buffers, so I may have to force three colors
channel to be RGBA instead of RGB.
I changed the internal format from GL_RGB32F to GL_RGBA32F when loading the RGB textures:
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA32F, width, height, 0,
GL_RGB, GL_FLOAT, data); // before GL_RGB32F
This seemed to fix the problems on the Intel drivers.
I'm going a bit nuts on this since I don't really get what is wrong and what not. There must either be something that I've vastly misunderstood or there is some kind of bug either in the code or in the driver. I'm running this on AMD Radeon 5850 with the latest catalyst beta drivers as of last week.
OK, I began doing a OIT-rendering implementation and wanted to use a struct-array saved in a shader storage buffer object. Well, the indices in that one were reflecting/moving forward in memory way wrong and I pretty much assumed that it was a driver bug - since they just recently started supporting such thing + yeah, it's a beta driver.
Therefore I moved back a notch and used glsl-images from texture buffer objects instead, which I guess had been supported since at least a while back.
Still wasn't behaving correctly. So I created a simple test project and fumbled around a bit and now I think I've just pinched where the thing is.
OK! First I initialize the buffer and texture.
//Clearcolor and Cleardepth setup, disabling of depth test, compile and link shaderprogram etc.
...
//
GLint tbo, tex;
datasize = resolution.x * resolution.y * 4 * sizeof(GLfloat);
glGenBuffers(1, &tbo);
glBindBuffer(GL_TEXTURE_BUFFER, tbo);
glBufferData(GL_TEXTURE_BUFFER, datasize, NULL, GL_DYNAMIC_COPY);
glBindBuffer(GL_TEXTURE_BUFFER, 0);
glGenTextures(1, &tex);
glBindTexture(GL_TEXTURE_BUFFER, tex);
glTexBuffer(GL_TEXTURE_BUFFER, GL_RGBA32F, tex);
glBindTexture(GL_TEXTURE_BUFFER, 0);
glBindImageTexture(2, tex, 0, GL_TRUE, 0, GL_READ_WRITE, GL_RGBA32F);
Then the rendering loop is - update and draw, update and draw ... With a delay in between so that I have time to see what the update does.
The update is like this...
ivec2 resolution; //Using GLM
resolution.x = (GLuint)(iResolution.x + .5f);
resolution.y = (GLuint)(iResolution.y + .5f);
glBindBuffer(GL_TEXTURE_BUFFER, tbo);
void *ptr = glMapBuffer(GL_TEXTURE_BUFFER, GL_WRITE_ONLY);
color *c = (color*)ptr; //color is a simple struct containing 4 GLfloats.
for (int i = 0; i < resolution.x*resolution.y; ++i)
{
c[i].r = c[i].g = c[i].b = c[i].a = 1.0f;
}
glUnmapBuffer(GL_TEXTURE_BUFFER); c = (color*)(ptr = NULL);
glBindBuffer(GL_TEXTURE_BUFFER, 0);
And the draw is like this...
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glMemoryBarrier(GL_ALL_BARRIER_BITS);
ShaderProgram->Use(); //Simple shader program class
quad->Draw(GL_TRIANGLES); //Simple mesh class containing triangles (vertices) and colors
glFinish();
glMemoryBarrier(GL_ALL_BARRIER_BITS);
I just put some memory barriers around to be extra sure, shouldn't harm more than performance right? Well, the outcome was the same with or without the barriers anyway, so ... :)
The Shader program is a simple pass-through vertex shader and the fragment shader that's doing the testing.
Vertex shader
#version 430
in vec3 in_vertex;
void main(void)
{
gl_Position = vec4(in_vertex, 1.0);
}
Fragment shader (I guess coherent & memoryBarrier() isn't really needed here since I do them on CPU in between draw/fragment shader execution... but does it harm?)
#version 430
uniform vec2 iResolution;
layout(binding = 2, rgba32f) coherent uniform imageBuffer colorMap;
out vec4 FragColor;
void main(void)
{
ivec2 res = ivec2(int(iResolution.x + 0.5), int(iResolution.y + 0.5));
ivec2 pos = ivec2(int(gl_FragCoord.x + 0.5), int(gl_FragCoord.y + 0.5));
int pixelpos = pos.y * res.x + pos.x;
memoryBarrier();
vec4 prevPixel = imageLoad(colorMap, pixelpos);
vec4 green = vec4(0.0, 1.0, 0.0, 0.0);
imageStore(colorMap, pixelpos, green);
FragColor = prevPixel;
}
Expectation: A white screen! Since I'm writing "white" to the whole buffer between every draw even if I'm writing green to the image after load in the actual shader.
Result: The first frame is green, the rest is black. Some part of me thinks that there is a white frame thats too fast to be seen or some vsync-thing that tares it, but it this a place for logics? :P
Well, then I tried a new thing and moved the update block (where i'm writing "white" to the whole buffer) to the init instead.
Expectation: A white first frame, followed by a green screen.
Result: Oh yes its green allright! Even though the first frame is with some artifacts of white/green, sometimes only green. This might probably be due to (lack of) vsync of something, haven't checked that out. Still, I think I got the result I was looking for.
The conclusion I can draw out of this is that there is something wrong in my update.
Does it unhook the buffer from the texture reference or something? In that case, isn't it weird that the first frame is OK? It's only after the first imageStore-command (well, the first frame) that the texture goes all black - the "bind()-map()-unmap()-bind(0)" works the first time, but not afterwards.
My picture of glMapBuffer is that it copies the buffer data from GPU to CPU memory, let's you alter it and Unmap copies it back. Well, just now I thought that maybe it doesn't copy the buffer from GPU to CPU and then back, but only one way? Could it be the GL_WRITE_ONLY which should be changed to GL_READ_WRITE? Well, I've tried both. Supposedly one of them was correct, wouldn't my screen when using that one always be white in "test 1"?
ARGH, what am I doing wrong?
EDIT:
Well, I still don't know... Obviously glTexBuffer(GL_TEXTURE_BUFFER, GL_RGBA32F, tex); should be glTexBuffer(GL_TEXTURE_BUFFER, GL_RGBA32F, tbo);, but I think tbo and tex had the same value since they were generated in the same order. Therefore it worked in this implementation.
I have solved it though, in a manner I'm not very happy with since I really think that the above should work. On the other hand, the new solution is probably a bit better performance-wise.
Instead of using glMapBuffer(), I switched to keeping a copy of the tbo-memory on CPU by using glBufferSubData() and glgetBufferSubData() for sending the data between CPU/GPU. This worked, so I'll just continue with that solution.
But, yeah, the question still stands - Why doesn't glMapBuffer() work with my texture buffer objects?
glTexBuffer(GL_TEXTURE_BUFFER, GL_RGBA32F, tex);
should be
glTexBuffer(GL_TEXTURE_BUFFER, GL_RGBA32F, tbo);
perhaps there is something else wrong, but this stands out.
https://www.opengl.org/wiki/Buffer_Texture
I am just starting to learn OpenGL today from this tutorial: http://openglbook.com/the-book/
I got to chapter 2, where I draw a triangle, and I understand everything except VAOs (is this acronym OK?). The tutorial has this code:
glGenVertexArrays(1, &VaoId);
glBindVertexArray(VaoId);
While I understand that the code is necessary, I have no clue what it does. Although I never use VaoId past this point (except to destroy it), the code does not function without it. I am assuming this is because it is required to be bound, but I don't know why. Does this exact code just need to be part of every OpenGL program? The tutorial explains VAOs as:
A Vertex Array Object (or VAO) is an object that describes how the vertex attributes are stored in a Vertex Buffer Object (or VBO). This means that the VAO is not the actual object storing the vertex data, but the descriptor of the vertex data. Vertex attributes can be described by the glVertexAttribPointer function and its two sister functions glVertexAttribIPointer and glVertexAttribLPointer, the first of which we’ll explore below.
I don't understand how the VAO describes the vertex attributes. I have not described them in any way. Does it get the information from the glVertexAttribPointer? I guess this must be it. Is the VAO simply a destination for the information from glVertexAttribPointer?
On a side note, is the tutorial I am following acceptable? Is there anything I should watch out for or a better tutorial to follow?
"Vertex Array Object" is brought to you by the OpenGL ARB Subcommittee for Silly Names.
Think of it as a geometry object. (As an old time SGI Performer programmer, I call them geosets.) The instance variables/members of the object are your vertex pointer, normal pointer, color pointer, attrib N pointer, ...
When a VAO is first bound, you assign these members by calling
glEnableClientState(GL_VERTEX_ARRAY); glVertexPointer...;
glEnableClientState(GL_NORMAL_ARRAY); glNormalPointer...;
and so on. Which attributes are enabled and the pointers you supply are stored in the VAO.
After that when you bind the VAO again, all the those attributes and pointers also become current. So one glBindVertexArray call is equivalent to all the code previously needed to set up all the attributes. It's handy for passing geometry around between functions or methods without having to create your own structs or objects.
(One time setup, multiple use is the easiest way to use VAOs, but you can also change attributes just by binding it and doing more enable/pointer calls. VAOs are not constants.)
More info in response to Patrick's questions:
The default for a newly created VAO is that it's empty (AFAIK). No geometry at all, not even vertexes, so if you try to draw it, you'll get an OpenGL error. This is reasonably sane, as in "initialize everything to False/NULL/zero".
You only need to glEnableClientState when you set things up. The VAO remembers the enable/disable state for each pointer.
Yes the VAO will store glEnableVertexAttribArray and glVertexAttrib. The old vertex, normal, color, ... arrays are the same as attribute arrays, vertex == #0 and so on.
I always think about VAO as an array of data buffers used by OpenGL. Using modern OpenGL you will create a VAO and Vertex Buffer Objects.
//vaoB is a buffer
glGenVertexArrays(1, vaoB); //creates one VAO
glBindVertexArray(vao.get(0));
glGenBuffers(vbo.length, vbo, 0); //vbo is a buffer
glBindVertexArray(vao.get(1));
glGenBuffers(vbo1.length, vbo1, 0); //vbo1 is a buffer
glBindVertexArray(vao.get(2));
glGenBuffers(vbo2.length, vbo2, 0); //vbo2 is a buffer
The next step is to bind data to a buffer:
glBindBuffer(GL_ARRAY_BUFFER, vbo[0]);
glBufferData(GL_ARRAY_BUFFER,vertBuf.limit()*4, vertBuf, GL_STATIC_DRAW); //vertf buf is a floatbuffer of vertices
At this point OpenGL Sees:
Now we can use glVertexAttribPointer to tell OpenGL what the data in the buffer represents:
glBindBuffer(GL_ARRAY_BUFFER, 0); //bind VBO at 0
glVertexAttribPointer(0, 3, GL_FLOAT, false, 0, 0); //each vertex has 3 components of size GL_FLOAT with 0 stride (space) between them and the first component starts at 0 (start of data)
OpenGL now has the data in the buffer and knows how the data is organized into vertices. The same process can be applied to texture coordinates etc but for texture coordinates there would be two values.
glBindBuffer(GL_ARRAY_BUFFER, vbo[1]);
glBufferData(GL_ARRAY_BUFFER,coordBuf.limit()*4, coordBuf, GL_STATIC_DRAW);
glVertexAttribPointer(0, 2, GL_FLOAT, false, 0, 0);
Next you can bind texture and draw arrays, you will want to create a Vert and Frag shader, compile and attach it to a program (not included here).
glActiveTexture(textureID); //bind our texture
glBindTexture(GL_TEXTURE_2D, textureID);
glDrawArrays(GL_TRIANGLES,0,6); //in this case 6 indices are used for two triangles forming a square
Vertex Array Objects are like macros in word processing programs and the like. A good description is found here.
Macros just remember the actions you did, such as activate this attribute, bind that buffer, etc. When you call glBindVertexArray( yourVAOId ), it simply replays those attribute pointer bindings and buffer bindings.
So your next call to draw uses whatever was bound by the VAO.
VAO's don't store vertex data. No. The vertex data is stored in a vertex buffer or in an array of client memory.
VAO is an object that represents the vertex fetch stage of the OpenGL pipeline and is used to supply input to the vertex shader.
You can create vertex array object like this
GLuint vao;
glCreateVertexArrays(1, &vao);
glBindVertexArray(vao);
First let' do a simple example. Consider such an input parameter in a shader code
layout (location = 0) in vec4 offset; // input vertex attribute
To fill in this attribute we can use
glVertexAttrib4fv(0, attrib); // updates the value of input attribute 0
Although the vertex array object stores these static attribute values for
you, it can do a lot more.
After creating vertex array object we can start filling in its state. We will ask OpenGL to fill it automatically using the data stored in a buffer object that we supply. Each vertex attribute gets to fetch data from a buffer bound to one of several vertex buffer bindings. For this end we use glVertexArrayAttribBinding(GLuint vao, GLuint attribindex, GLuint bindingindex). Also we use the glVertexArrayVertexBuffer() function to bind a buffer to one of the vertex buffer bindings. We use the glVertexArrayAttribFormat() function to describe the layout and format of the data, and finally we enable automatic filling of the attribute by calling glEnableVertexAttribArray().
When a vertex attribute is enabled, OpenGL will feed data to the vertex shader based on the format and location information you’ve provided with
glVertexArrayVertexBuffer() and glVertexArrayAttribFormat(). When
the attribute is disabled, the vertex shader will be provided with the static information you provide with a call to glVertexAttrib*().
// First, bind a vertex buffer to the VAO
glVertexArrayVertexBuffer(vao, 0, buffer, 0, sizeof(vmath::vec4));
// Now, describe the data to OpenGL, tell it where it is, and turn on automatic
// vertex fetching for the specified attribute
glVertexArrayAttribFormat(vao, 0, 4, GL_FLOAT, GL_FALSE, 0);
glEnableVertexArrayAttrib(vao, 0);
And code in a shader
layout (location = 0) in vec4 position;
After all you need to call to glDeleteVertexArrays(1, &vao).
You can read OpenGL SuperBible to understand it better.
I was trying to understand this as well and now that I think I do, it would be prudent to post a code example aimed at
people less familiar with OpenGL architecture, as I found the previous examples not very illuminating and most tutorials
just tell you to copy paste the code without explaining it.
(This is in C++ but the code can be easily translated to C)
In this example, we'll be rendering a rectangle, which has 4 vertices. Each vertex has a position (vec3, xyz), texture coordinate (vec2, uv) and color attribute (vec4, rgba).
I think it's cleanest to separate each attribute into their own array:
float positions[] = {
+0.5, +0.5, 0,
+0.5, -0.5, 0,
-0.5, -0.5, 0,
-0.5, +0.5, 0
};
float colors[] = {
1, 1, 1, 1,
1, 1, 1, 1,
1, 1, 1, 1,
1, 1, 1, 1
};
float tex_coords[] = {
0, 0,
0, 1,
1, 1,
1, 0
};
Our vertex array object will describe the four vertices with these properties.
First, we need to create the vertex array:
GLuint vertex_array;
glGenVertexArrays(1, &vertex_array);
Each vertex array has a number of buffers, these can be thought of as properties of the array. Each vertex array has an
arbitrary number of "slots" for the buffers. Along with which buffer is in which slot, it saves the CPU-side pointer to
the data for the buffer, and the CPU-side datas format. We need to make OpenGL aware of both which slot to use, where the
data is, and how it is formatted.
The buffers slots are indexed, so the first buffer is index 0, the second is 1, etc.
These locations correspond to the layout defined in the vertex shader:
// vertex shader
std::string _noop_vertex_shader_source = R"(
#version 420
layout (location = 0) in vec3 _position_3d; // slot 0: xyz
layout (location = 1) in vec4 _color_rgba; // slot 1: rgba
layout (location = 2) in vec2 _tex_coord; // slot 2: uv
out vec2 _vertex_tex_coord;
out vec4 _vertex_color_rgba;
void main()
{
gl_Position = vec4(_position_3d.xy, 1, 1); // forward position to fragment shader
_vertex_color_rgba = _color_rgba; // forward color to fragment shader
_vertex_tex_coord = _tex_coord; // forward tex coord to fragment shader
}
)";
We see that the position property is at location 0, the color property at 1 and the tex coords at 2. We'll store these
for clarity:
// property locations from our shader
const auto vertex_pos_location = 0;
const auto vertex_color_location = 1;
const auto vertex_tex_coord_location = 2;
We now need to tell OpenGL the information about each buffer outlined above:
// bind the array, this makes OpenGL aware that we are modifying it with future calls
glBindVertexArray(vertex_array);
// create the position buffer
glGenBuffers(1, &position_buffer);
// bind the buffer so opengl knows we are currently operating on it
glBindBuffer(GL_ARRAY_BUFFER, position_buffer);
// tell opengl where the data pointer is
glBufferData(GL_ARRAY_BUFFER, sizeof(positions), positions, GL_STATIC_DRAW);
// tell opengl how the data is formatted
glVertexAttribPointer(vertex_pos_location, 3, GL_FLOAT, GL_FALSE, 0, (void*) 0);
// tell opengl that this slot should be used
glEnableVertexAttribArray(vertex_pos_location);
Here, we generate a buffer that will hold our position data. For glVertexAttribPointer, we choose the
correct location, 3 elements (as the positions are xyz coordinates), and no offset or stride.
Because we have a separate array for all our properties, we can leave both as 0.
Similar to the position, we generate and fill the buffers for the color and tex coord property:
// color
glGenBuffers(1, &color_buffer); // generate
glBindBuffer(GL_ARRAY_BUFFER, color_buffer); // bind
glBufferData(GL_ARRAY_BUFFER, sizeof(colors), colors, GL_STATIC_DRAW); // set pointer
glVertexAttribPointer(vertex_color_location, 4, GL_FLOAT, GL_FALSE, 0, (void*) 0); // set data format
glEnableVertexAttribArray(vertex_color_location); // enable slot
// tex coords
glGenBuffers(1, &tex_coord_buffer);
glBindBuffer(GL_ARRAY_BUFFER, tex_coord_buffer);
glBufferData(GL_ARRAY_BUFFER, sizeof(tex_coords), tex_coords, GL_STATIC_DRAW);
glVertexAttribPointer(vertex_tex_coord_location, 2, GL_FLOAT, GL_FALSE, 0, (void*) 0);
glEnableVertexAttribArray(vertex_tex_coord_location);
Where we chose 4 elements for the colors because they are in RGBA format and 2 for the tex coords for obvious reasons.
The last thing we need to render a vertex array is an element buffer. These can be thought of as a list of
indices that define which order the vertices will be rendered in. For us, we want to render the
rectangle as two tris in a triangle fan, so we choose the following element buffer:
// vertex order
static uint32_t indices[] = {
0, 1, 2, 1, 2, 3
};
glGenBuffers(1, &element_buffer); // generate
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, element_buffer); // bind
glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices, GL_STATIC_DRAW) // set pointer
We do not need to enable the element buffers slot, it is separate from the vertex array. We don't have to specify the format of the elements buffer here, that will be done during glDrawElements in the render step.
So why all this? All these functions tell OpenGL where to look for the data for the vertices. Specifying the pointers to
the correct buffer data and their layout, if we now bind the vertex array during a render step:
glUseProgram(shader.get_program_id()); // shader program with our vertex shader
glBindVertexArray(vertex_array);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, element_buffer);
glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_INT, 0);
Where 6 is the number of elements in the element buffer.
This is all that's needed to correctly update the in values in the vertex shader. OpenGL will move the data from
our CPU-side positions, colors and tex_coords into the correct locations 0, 1 and 2 of the vertex shader respectively.
We don't need to bind anything else, the vertex array remembers what we gave it and does it for us, which is why it's convenient and should be preferred in modern OpenGL.
In summary:
Each vertex array has n buffers for arbitrary properties and 1 element buffer. For each property / buffer, we need to
a) generate it (glGenBuffers)
b) bind it (glBindBuffer(GL_ARRAY_BUFFER)
c) tell OpenGL where the data is located in RAM (glBufferData)
d) tell OpenGL how the data is formatted (glVertexAttribPointer)
e) tell OpenGL to use that slot (glEnableVertexAttribArray)
for the element buffer, we only need to generate it, bind it to GL_ELEMENT_ARRAY_BUFFER, then tell opengl
where the data is.
Hopefully that helped shed some light on things. I'm almost positive there will be factual errors in this post as
I'm also mostly new to OpenGL but this was the way I conceptualized it to get my code working.