glBlendFunc

Official

Opaque
Transparent

Name

glBlendFunc
  specify pixel arithmetic..

C Specification

void
glBlendFunc(
  GLenum sfactor
  , GLenum dfactor
);

  sfactor \specifies how the red-green-blue-alpha- source blending factors..

  dfactor \specifies how the red-green-blue-alpha- destination blending factors are computed.

Description

Pixels can be drawn using a function that blends the incoming (source) RGBA values with the RGBA values that are already in the frame buffer (the destination values). Blending is initially disabled. Use glEnable and glDisable with argument GL_BLEND to enable and disable blending.

glBlendFunc defines the operation of blending for all draw buffers when it is enabled. glBlendFunci defines the operation of blending for a single draw buffer specified by buf when enabled for that draw buffer. sfactor specifies which method is used to scale the source color components. dfactor specifies which method is used to scale the destination color components. 

Another Description

glBlendFunc

void glBlendFunc(GLenum sfactor, GLenum dfactor)

Specifies how the incoming values (what you’re going to draw) are going to affect the existing values (what is already drawn).

In other words:

• Incoming values == Source
• Existing values == Destination

So what we are setting with glBlendFunc is the multiplying factors for both source and destination. The source factor will multiply the incoming values, and the destination factor will multiply the existing values, and then both will be added together to form the final result. This is a vectorial sum: the red, green, blue and alpha components of each pixel are taken into account separately.

Mathematically (and succintly) expressed:

Result = SourceFactor * SourceValues + DestinationFactor * DestinationValues

And since we’re talking vectorially here:

Blending factors

There are many blending factors, although we usually only end up using a handful of them. Most of them use the alpha value of the incoming pixels to decide whether they are shown or not, or how much of them is shown (tipically in order to achieve translucency).

The equivalent to having blending disabled is to use (GL_ONE, GL_ZERO) –or in other words, multiply the source by 1 (i.e. don’t change its value) and multiply the destination by zero (i.e. ignore its value), then add it together. Which effectively replaces everything already in the framebuffer with the incoming, new values.

,,,,,,,

??glBlendFunc()

If you’re doing 3D graphics on the iPhone, you’re mostly dealing with OpenGL. And if you’re doing OpenGL, you’re using glBlendFunc(GLenum source_factor, GLenum destination_factor) to indicate how polygons draw on top of each other. The way it works is it multiplies a source image (what you’re putting on top) by something, multiplies the destination image (the background) by something, and adds the two results together. The glBlendFunc() specifies what those two somethings are.
Here are a few examples from my own code:

 

The source image is just a circle that's half black and half white. The destination is a background image that comes with the iPhone simulator.

glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);

This is the standard operation, which is used 99% of the time. It specifies that you multiply the source image by one, which leaves is alone, and multiply the background by (1 - source_alpha), which cuts a hole for the source image to fit in. I've also seen examples which replace the first GL_ONE with GL_SRC_ALPHA but in my experience, images with transparency tend to be pre-multiplied so GL_ONE is more correct.

glBlendFunc(GL_ZERO, GL_ONE_MINUS_SRC_ALPHA);

This is pretty much like the last example, except that we multiply the source image by zero so that all we're left with is a hole in the shape of the source image.

glBlendFunc(GL_DST_COLOR, GL_ONE_MINUS_SRC_ALPHA);

I've used this combination to blend or tint the background. For example, I used this on Mach Dice to burn shadows on backgrounds. It works by multiplying the source and destination images together and plopping it on top of the hole cut out of the background.

glBlendFunc(GL_DST_COLOR, GL_ONE);

This is pretty much just like the previous example except that a hole isn't cut out of the background. The result? The tinted image is added on top of the background making it lighter. I've used this to create highlights on backgrounds.

glDrawArrays

Official

Name

glDrawArrays
  render primitives from array data.

C Specification

void
glDrawArrays(
  GLenum mode
  , GLint first
  , GLsizei count
);

  mode \specifies what kind of primitives to render

  first \specifies the starting index in the enabled arrays.

  count \specifies the number of indices to be rendered.

Description

glDrawArrays specifies multiple geometric primitives with very few subroutine calls. Instead of calling a GL procedure to pass each individual vertex, normal, texture coordinate, edge flag, or color, you can prespecify separate arrays of vertices, normals, and colors and use them to construct a sequence of primitives with a single call to glDrawArrays.

When glDrawArrays is called, it uses count sequential elements from each enabled array to construct a sequence of geometric primitives, beginning with element first. modespecifies what kind of primitives are constructed and how the array elements construct those primitives.

Vertex attributes that are modified by glDrawArrays have an unspecified value after glDrawArrays returns. Attributes that aren't modified remain well defined.

How :-)

The call to glBindBuffer tells OpenGL to use vertexBufferObject whenever it needs the GL_ARRAY_BUFFER.

glEnableVertexAttribArray means that you want OpenGL to use vertex attribute arrays; without this call the data you supplied will be ignored.

glVertexAttribPointer, as you said, tells OpenGL what to do with the supplied array data, since OpenGL doesn't inherently know what format that data will be in.

glDrawArrays uses all of the above data to draw points.

Remember that OpenGL is a big state machine. Most calls to OpenGL functions modify a global state that you can't directly access. That's why the code ends with glDisableVertexAttribArray and glBindBuffer(..., 0): you have to put that global state back when you're done using it.

--By Steve Howard

@handuel: It uses all enabled vertex attributes. What each attribute means exactly defined through the programming of the vertex shader.

@handuel: Actually the vertex shader gets into action after glDrawArrays gets called. glDrawArrays simply passes the data for each active vertex attribute enabled using glEnableVertexAttribArray into the drawing queue. In the vertex shader there's a binding for each vertex attribute array, and the shader determines what becomes screen position, what color and so on. 

@handuel: When glVertexAttribPointer(attrib_index, …) is called the buffer bound byglBindBuffer(GL_ARRAY_BUFFER, …) gets bound to the vertex attribute specified by the first parameter of glVertexAttribPointer. To bind another buffer to another attribute you do anotherglBindBuffer(GL_ARRAY_BUFFER, …); glVertexAttribPointer(…);. –– The call ofglEnableVertexAttribArray is not required to make the binding between buffer and attribute. But enabling a vertex attribute array makes the glDraw… calls use the enabled attributes. 

--– datenwolf

DrawArrays takes data from ARRAY_BUFFER.

Data are 'mapped' according to your setup in glVertexAttribPointer which tells what is the definition of your vertex.

In your example you have one vertex attrib (glEnableVertexAttribArray) at position 0 (you can normally have 16 vertex attribs, each 4 floats). Then you tell that each attrib will be obtained by reading 3 GL_FLOATS from the buffer starting from position 0.

--By fen

glEnableVertexAttribArray

Official

Name

glEnableVertexAttribArray
  enable or disable a generic vertex attribute array.

C Specification

void glEnableVertexAttribArray(
  GLuint index
);

  index \specifies the index of the generic vertex attribute to be enabled or disabled.

Description

glEnableVertexAttribArray and glEnableVertexArrayAttrib enable the generic vertex attribute array specified by index. glEnableVertexAttribArray uses currently bound vertex array object for the operation, whereas glEnableVertexArrayAttrib updates state of the vertex array object with ID vaobj.

glDisableVertexAttribArray and glDisableVertexArrayAttrib disable the generic vertex attribute array specified by index. glDisableVertexAttribArray uses currently bound vertex array object for the operation, whereas glDisableVertexArrayAttrib updates state of the vertex array object with ID vaobj.

By default, all client-side capabilities are disabled, including all generic vertex attribute arrays. If enabled, the values in the generic vertex attribute array will be accessed and used for rendering when calls are made to vertex array commands such as glDrawArrays, glDrawElements, glDrawRangeElements, glMultiDrawElements, or glMultiDrawArrays.

SO How it is like :-)

'glEnableVertexAttribArray(0) enables the attribute index for the position attribute' - doesn't explain anything. Why we need to enable it and when? We call glVertexAttribPointer - to indicate where ogl should take vertices or other data for shader input, why then we need to call this additional function? Should i call this method every time active shader program changed, if vertex shader? 

--By Zakus .a good reply

It's similar to a vertex array but stores additional extra values for each point rather than it's coordinates. You might want to store a temperature, density, signal strength at each point in a modelling app for example, or perhaps a damage value for a game

--By Martin Beckett

glVertexAttribPointer

Official

Name

glVertexAttribPointer
    define an array of generic vertex attribute data.

C Specification

void glVertexAttribPointer(
  GLuint index
  , GLint size
  , GLenum type
  , GLboolean normalized
  , GLsizei stride
  , const GLvoid * pointer
);

  index \specifies the index of the generic vertex attribute to be modified.

  size \specifies the number of components per generic vertex attribute.must be 1, 2, 3, 4.

  type \specifies the data type of each component in the array.the symbolic constants gl_byte, gl_unsigned_byte, gl_short, gl_unsigned_short, gl_int, gl_unsigned_int are accepted.

  normalized \specifies whether fixed-point data values should be normalized or converted directly as fixed-point value when they are accessed.

  stride \specifies the byte offset between consecutive generic vertex attrbutes. if stride is 0, the generic vertex attribtues are understood to be tightly packed in the array. the initial value is 0..

  pointer \specifies an offset of the first component of the first generic vertex attribute in the array in the data store of the buffer currently bound to the GL_ARRAY_BUFFER target. the initial value is 0...

Description

glVertexAttribPointer, glVertexAttribIPointer and glVertexAttribLPointer specify the location and data format of the array of generic vertex attributes at index index to use when rendering. >>> size specifies the number of components per attribute and must be 1, 2, 3, 4, or GL_BGRA. type specifies the data type of each component, and >>> stride specifies the byte stride from one attribute to the next, allowing vertices and attributes to be packed into a single array or stored in separate arrays.

For glVertexAttribPointer, if normalized is set to GL_TRUE, it indicates that values stored in an integer format are to be mapped to the range [-1,1] (for signed values) or [0,1] (for unsigned values) when they are accessed and converted to floating point. Otherwise, values will be converted to floats directly without normalization.

For glVertexAttribIPointer, only the integer types GL_BYTE, GL_UNSIGNED_BYTE, GL_SHORT, GL_UNSIGNED_SHORT, GL_INT, GL_UNSIGNED_INT are accepted. Values are always left as integer values.

glVertexAttribLPointer specifies state for a generic vertex attribute array associated with a shader attribute variable declared with 64-bit double precision components. type must be GL_DOUBLE. index, size, and stride behave as described for glVertexAttribPointer and glVertexAttribIPointer.

If pointer is not NULL, a non-zero named buffer object must be bound to the GL_ARRAY_BUFFER target (see glBindBuffer), otherwise an error is generated. pointer is treated as a byte offset into the buffer object's data store. The buffer object binding (GL_ARRAY_BUFFER_BINDING) is saved as generic vertex attribute array state (GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING) for index index.

When a generic vertex attribute array is specified, size, type, normalized, stride, and pointer are saved as vertex array state, in addition to the current vertex array buffer object binding.

To enable and disable a generic vertex attribute array, call glEnableVertexAttribArray and glDisableVertexAttribArray with index. If enabled, the generic vertex attribute array is used when glDrawArrays, glMultiDrawArrays, glDrawElements, glMultiDrawElements, or glDrawRangeElements is called.

Notes

Each generic vertex attribute array is initially disabled and isn't accessed when glDrawElements, glDrawRangeElements, glDrawArrays, glMultiDrawArrays, or glMultiDrawElementsis called.

GL_UNSIGNED_INT_10F_11F_11F_REV is accepted for type only if the GL version is 4.4 or higher.              

So it looks like this :-)

You can safely unbind a VBO after making the calls to gl…Pointer, the association with the VBO bound at the time of the call of the gl…Pointer function is not lost.

--By datenwolf

@datenwolf already covered the key aspect in a comment above. To elaborate some more:

You do not have to bind GL_ARRAY_BUFFER again before the glDrawElements() call. What matters is that the buffer you want to source a given attribute from is bound when you make the glVertexAttribPointer() call for that attribute.

The best way to picture this is that when you make this call:

glVertexAttribPointer(0, 3, GL_FLOAT, false, Vertex.SIZE * 4, 0);

you're specifying all the state needed to tell OpenGL where to get the data for attribute 0 (first argument) from, and how to read it. Most of that state is given directly by the arguments:

• it has 3 components
• the components are float values
• vertices are read with a stride of 20 bytes...
• ... and starting at byte 0 of the buffer

But there's an additional implied piece of state that is also stored away for attribute 0 when you make the call:

• the data is read from the buffer currently bound to GL_ARRAY_BUFFER

In other words, the state associated with each attribute includes the id of the buffer the attribute data is sourced from. This can be the same buffer for multiple/all attributes, or it can be a different buffer for each attribute.

Note that the same is not true for GL_ELEMENT_ARRAY_BUFFER. That one needs to be bound at the time of the glDrawElements() call. While it seems somewhat inconsistent, this is necessary because there's no equivalent to glVertexAttribPointer() for the index array. The API could have been defined to have this kind of call, but... it was not. The reason is most likely that it was simply not necessary, since only one index array can be used for a draw call, while multiple vertex buffers can be used.

--By Reto Koradi

Demo Code

Examples[0]
Render an indexed vertex array (not loaded into OpenGL) using texture UV and normal vertex attribtues.

//attribute indexes were received from calls to glGetAttribLocation,//or passed into glBindAttribLocationglEnableVertexAttribArray(texcoord_attrib_index);glEnableVertexAttribArray(normal_attrib_index);glEnableVertexAttribArray(position_attrib_index); 

//texcoords_data is a float* [2-per-vertex] representing UV coordinates.//normal_data is a float* [3-per-vertex] representing normal vectors.//vertex_data is a float* [3-per-vertex] representing the poition of each vertex.glVertexAttribPointer(texcoord_attrib_index, 2, GL_FLOAT, false, 0, texcoords_data);glVertexAttribPointer(normal_attrib_index, 3, GL_FLOAT, false, 0, normals_data);glVertexAttribPointer(position_attrib_index, 3, GL_FLOAT, false, 0, vertex_data); 

//num_vertices is the number of verts in your vertex_data.//index_data is an array of unsigned int offsets in bytes into vertex_data.glDrawElements(GL_TRIANGLES, num_vertices, GL_UNSIGNED_INT, index_data);
glDisableVertexAttribArray(position_attrib_index);glDisableVertexAttribArray(texcoord_attrib_index);glDisableVertexAttribArray(normal_attrib_index);

Examples[1]
Render an indexed buffer object using texture UV and normal vertex attributes.

//vertex_buffer is retrieved from glGenBuffers//index_buffer is retrieved from glGenBuffers//attribute indexes were received from calls to glGetAttribLocationglEnableVertexAttribArray(texcoord_attrib_index);glEnableVertexAttribArray(normal_attrib_index);glEnableVertexAttribArray(position_attrib_index); 

//vertex_stride is the size of bytes of each vertex in the buffer object..//vertex_position_offset and kin are the offset in bytes of the position data..//in each vertex, E.g. if your vertex structure is//[positionF3,texcoordF2,normalF3]//then position vertex_position_offset will have offset 0..//and  vertex_texcoord_offset have offset 12//(I.e. position is 3*sizeof(float) bytes large, and texcoord comes just after)//and  vertex_normal_offset is 20 (3*sizeof(float)+2*sizeof(float))GLintptr vertex_texcoord_offset = (3*sizeof(float));GLintptr vertex_normal_offset = (5*sizeof(float);GLintptr vertex_position_offset = (0*sizeof(float)); 

glVertexAttribPointer(texcoord_attrib_index, 2, GL_FLOAT, false, vertex_stride, (GLvoid*)vertex_texcoord_offset);glVertexAttribPointer(normal_attrib_index, 3, GL_FLOAT, false, vertex_stride, (GLvoid*)vertex_normal_offset);glVertexAttribPointer(position_attrib_index, 3, GL_FLOAT, false, vertex_stride, (GLvoid*)vertex_position_offset); 

//num_vertices is the number of verts in your vertex_data..//index_data is an array of unsigned int offsets into vertex_data..glDrawElements(GL_TRIANGLES, num_vertices, GL_UNSIGNED_INT, NULL);
glDisableVertexAttribArray(position_attrib_index);glDisableVertexAttribArray(texcoord_attrib_index);glDisableVertexAttribArray(normal_attrib_index);

________
Done :-)
End.
________

glBufferData

Official

Name

glBufferData
  creates and initializes a buffer object's data store.

C Specification

void
glBufferData(
    GLenum target
    , Glsizeiptr size
    , const GLvoid * data
    , GLenum usage
);
,,,
  target specifies the target to which the bufer object is bound for glBufferdata.

  size specifies the size in bytes of the buffer object's new data store.

  data specifies the pointer to data that will be copied into the data store for initialization or null if no data is to be copied.

  usage specifies the expected usage pattern of the data store.

Description

glBufferData and glNamedBufferData create a new data store for a buffer object. In case of glBufferData, the buffer object currently bound to target is used. For glNamedBufferData, a buffer object associated with ID specified by the caller in buffer will be used instead.

While creating the new storage, any pre-existing data store is deleted. The new data store is created with the specified size in bytes and usage. If data is not NULL, the data store is initialized with data from this pointer. In its initial state, the new data store is not mapped, it has a NULL mapped pointer, and its mapped access is GL_READ_WRITE.

usage is a hint to the GL implementation as to how a buffer object's data store will be accessed. This enables the GL implementation to make more intelligent decisions that may significantly impact buffer object performance. It does not, however, constrain the actual usage of the data store. usage can be broken down into two parts: first, the frequency of access (modification and usage), and second, the nature of that access. 

What it is

To update your entire buffer, you should call glBufferData() once again:

glBufferData(GL_ARRAY_BUFFER, vertex_size * sizeof(VertexData), vertices, GL_DYNAMIC_DRAW);

Furthermore, it is possible to update only part of the data using the glBufferSubData() call:

glBufferSubData(GLenum target, GLintptr offset, GLsizeiptr size, const GLvoid* data);

The glBufferSubData() is faster since it will not reallocate the underlying buffer .

...By  Sergey K.

glBindBuffer

official

Name
glBindBuffer -bind a named buffer object.

C Specification
void
glBindBuffer(
    GLenum target
    , GLuint buffer
);

Description

glBindBuffer binds a buffer object to the specified buffer binding point. Calling glBindBuffer with target set to one of the accepted symbolic constants and buffer set to the name of a buffer object binds that buffer object name to the target. If no buffer object with name buffer exists, one is created with that name. When a buffer object is bound to a target, the previous binding for that target is automatically broken.

What it is

    By Dietrich Epp

From a low-level perspective, you can think of an array as having two parts to it:

• Information about the size, shape, and type of the array (e.g., 32-bit floating point numbers, containing rows of vectors with four elements each).
• The array data, which is little more than a big blob of bytes.

Even though the low-level concept has mostly stayed the same, the way you specify arrays has changed several times over the years.

OpenGL 3.0 / ARB_vertex_array_object

This is the way you probably should be doing things today. It is very rare to find people who can't run OpenGL 3.x and yet still have money to spend on your software.

A buffer object in OpenGL is a big blob of bits. Think of the "active" buffer as just a global variable, and there are a bunch of functions which use the active buffer instead of using a parameter. These global state variables are the ugly side of OpenGL (prior to direct state access, which is covered below).

GLuint buffer;
// Create a buffer
glGenBuffers(1, &buffer);
// Make the buffer the active array buffer
// i.e. opengl->array_buffer = buffer
glBindBuffer(GL_ARRAY_BUFFER, buffer);
// Upload a bunch of data into the active array buffer
// i.e. opengl->array_buffer = new buffer(sizeof(points), points, STATIC_DRAW)
glBufferData(GL_ARRAY_BUFFER, sizeof(points), points, GL_STATIC_DRAW);

Now, your typical vertex shader takes vertexes as input, not a big blob of bits. So you need to specify how the blob of bits (the buffer) is decoded into vertexes. That is the job of the array. Likewise, there is an "active" array which you can think of as just a global variable:

GLuint array;
// Create an array
glGenVertexArrays(1, &array);
// Make the array the active array
// i.e., opengl->vertex_array = array
glBindVertexArray(array);

// Make the buffer the active array buffer
// i.e., opengl->array_buffer = buffer
glBindBuffer(GL_ARRAY_BUFFER, buffer);
// Attach the active buffer to the active array,
// as an array of vectors with 4 floats each.
// i.e. opengl->vertex_array.attributes[attr] = {
//          type = GL_FLOAT,
//          size = 4,
//          data = opengl->array_buffer
//      }
glVertexAttribPointer(attr, 4, GL_FLOAT, GL_FALSE, 0, 0);
// Enable the vertex attribute
glEnableVertexAttribArray(attr);

OpenGL 2.0 (the old way)

In OpenGL 2.x, there weren't vertex arrays and the data was just global. You still had to call glVertexAttribPointer() and glEnableVertexAttribArray(), but you had to call them every timethat you used a buffer. In OpenGL 3.x, you just set up the array once.

Going back to OpenGL 1.5, you could actually use buffers, but you used a separate function to bind each kind of data. For example, glVertexPointer() was for vertex data, and glNormalPointer()was for normal data. Prior to OpenGL 1.5, there weren't buffers, but you could use pointers into your application memory.

OpenGL 4.3 / ARB_vertex_attrib_binding

In 4.3, or if you have the ARB_vertex_attrib_binding extension, you can specify the attribute format and the attribute data separately. This is nice because it lets you easily switch one vertex array between different buffers.

// Create and bind the array.
GLuint array;
glGenVertexArrays(1, &array);
glBindVertexArray(array);

// Enable my attributes
glEnableVertexAttribArray(loc_attrib);
glEnableVertexAttribArray(normal_attrib);
glEnableVertexAttribArray(texcoord_attrib);
// Set up the formats for my attributes
glVertexAttribFormat(loc_attrib,      3, GL_FLOAT, GL_FALSE, 0);
glVertexAttribFormat(normal_attrib,   3, GL_FLOAT, GL_FALSE, 12);
glVertexAttribFormat(texcoord_attrib, 2, GL_FLOAT, GL_FALSE, 24);
// Make my attributes all use binding 0
glVertexAttribBinding(loc_attrib,      0);
glVertexAttribBinding(normal_attrib,   0);
glVertexAttribBinding(texcoord_attrib, 0);

// Quickly bind all attributes to use "buffer"
// This replaces several calls to glVertexAttribPointer()
// Note: you don't need to bind the buffer first!  Nice!
glBindVertexBuffer(0, buffer, 0, 32);

// Quickly bind all attributes to use "buffer2"
glBindVertexBuffer(0, buffer2, 0, 32);

OpenGL 4.5 / ARB_direct_state_access

In OpenGL 4.5, or if you have the ARB_direct_state_access extension, you no longer need to call glBindBuffer() or glBindVertexArray() just to set things up... you specify the arrays and buffers directly. You only need to bind the array at the end to draw it.

// Create the array, don't bind it.
// Instead of binding it, we pass it to the functions below.
GLuint array;
glGenVertexArrays(1, &array);

// Enable my attributes
glEnableVertexArrayAttrib(array, loc_attrib);
glEnableVertexArrayAttrib(array, normal_attrib);
glEnableVertexArrayAttrib(array, texcoord_attrib);
// Set up the formats for my attributes
glVertexArrayAttribFormat(array, loc_attrib,      3, GL_FLOAT, GL_FALSE, 0);
glVertexArrayAttribFormat(array, normal_attrib,   3, GL_FLOAT, GL_FALSE, 12);
glVertexArrayAttribFormat(array, texcoord_attrib, 2, GL_FLOAT, GL_FALSE, 24);
// Make my attributes all use binding 0
glVertexArrayAttribBinding(array, loc_attrib,      0);
glVertexArrayAttribBinding(array, normal_attrib,   0);
glVertexArrayAttribBinding(array, texcoord_attrib, 0);

// Quickly bind all attributes to use "buffer"
glVertexArrayVertexBuffer(array, 0, buffer, 0, 32);

// Quickly bind all attributes to use "buffer2"
glVertexArrayVertexBuffer(array, 0, buffer2, 0, 32);

// You still have to bind the array to draw.
glBindVertexArray(array);
glDrawArrays(...);

Maybe ARB_direct_state_access is the way of the future, or maybe it's just a temporary stop on the way to something better (Mantle will almost certainly influence the next OpenGL standard). Either way, the ugly global variables are gone.