- Buffer Objects
- Vertex Array Objects
- Asynchronous query objects
- Framebuffer Objects
- Unconventional objects:
An OpenGL Object is an OpenGL construct that contains some state. When they are bound to the context, the state that they contain is mapped into the context's state. Thus, changes to context state will be stored in this object, and functions that act on this context state will use the state stored in the object.
OpenGL is defined as a "state machine". The various API calls change the OpenGL state, query some part of that state, or cause OpenGL to use its current state to render something.
Objects are always containers for state. Each particular kind of object is defined by the particular state that it contains. An OpenGL object is a way to encapsulate a particular group of state and change all of it in one function call.
Remember: this is just how OpenGL is defined by its specification. How these objects are actually implemented in drivers is another matter. But that is nothing you need to worry about; what matters is how objects and state interact as defined by the specification.
Object Creation and Destruction
To create an object, you generate the object's name (an integer). This creates a reference to the object. However, this does not necessarily create the object's state data. For most object types, the object will only contain its default state when it is first bound to the context; until it is bound, attempting to use it will fail. The objects which do not behave this way are Program Pipeline Objects and Sampler Objects.
The functions to generate object names are of the form glGen*, where * is the object's type in plural form. All functions of this type have the same signature:
void glGen*(GLsizei n, GLuint *objects);
This function generates n objects of the given type, storing them in the array given by the objects parameter. This allows you to create multiple objects with one call.
An object name is always a GLuint. These names are not pointers, nor should you assume that they are. They are references, numbers that identify an object. They can be any 32-bit unsigned integer except 0. The object number 0 is reserved for special use cases; see below for details.
- Legacy Note: In OpenGL versions before 3.0, the user was allowed to ignore the generation step entirely. The user could just decide that "3" is a valid object name, bind it to the context to create its default state, and then start using it like an object. The implementation would then have to accept that and create the object behind the scenes when you first start using it. In GL 3.0, this behavior was deprecated. In core GL 3.1 and above, this is no longer allowed. Regardless of the version of OpenGL, it is always good practice to use glGen* rather than making up your own object names.
Once you are finished with an object, you should delete it. The functions for this are of the form glDelete*, using the same object type as before. These functions have this signature:
void glDelete*(GLsizei n, const GLuint *objects);
This works like the glGen* functions, only it deletes the objects instead of creating them. Any values that are not valid objects or are object 0 will be silently ignored.
When OpenGL objects are deleted, their names are no longer considered valid. Following this call, a subsequent glGen* call may or may not reuse a previously-deleted name; you should not make assumptions either way.
When an object is deleted, if the object is bound to the current context (and note this only applies to the current context), then the object will be unbound from all binding to the context.
Furthermore, if the object is attached to any container object, and that object is itself bound to the current context, the object will be unattached from the container object. If it is attached to an object that is not bound to the current context, then the attachment is not broken.
Some objects can be bound to the context in unusual ways. These ways include, but are not limited to:
- Buffer Objects bound to indexed targets via glBindBufferRange or its equivalents.
- Textures bound as images.
In OpenGL 4.4 and below, ehse binds were not undone when the object is deleted. The only bindings that were undone in those versions were bindings that could be undone by calling the basic glBind* function for the object type.
So if you called glBindBufferRange(GL_UNIFORM_BUFFER, ...) and then delete that buffer, it will be as if glBindBuffer(GL_UNIFORM_BUFFER, 0) was called. This does not unbind it from the indexed target.
OpenGL 4.5 and above will unbind even from these unusual binding methods. These "bindings" are reset to their default state. Again, recall that this only takes place for the current OpenGL context.
Calling glDelete* on an object does not guarantee the immediate destruction of that object's contents. Furthermore, it does not even guarantee the immediate destruction of the object's name, since the object name can still be in use after deletion. If an object is still "in use" after it is deleted, then the object will remain alive within the OpenGL implementation.
An object is "in use" if:
- It is bound to a context. This is not necessarily the current one, since deleting it will automatically unbind it from the context that caused the deletion. Though remember the caveat above about non-standard binding points for GL 4.4 and before.
- It is attached to a container object.
So if a Texture is attached to a Framebuffer Object that is not bound to the context, the FBO will still be functional after deleting the texture. Only when the FBO is either deleted or a new texture attachment replaces the old will the texture finally be fully deleted.
Note that the name is still detectable via the OpenGL API. You can call glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER_ATTACHMENT_OBJECT_NAME) to fetch the object's name. However, the name is still considered unused, so don't use it for anything.
Because objects in OpenGL are defined as a collections of state, to modify objects, you must first bind them to the OpenGL context. Binding objects to the context causes the state in them to be set to be the current context's state. This means that any functions that change the state governed by that object will simply change the state within the object, thus preserving that state.
Binding a newly generated object name will create new state for that object. In some cases, the target to which it is first bound (see below) will affect properties of the newly created state for the object.
Different objects have different binding functions. They do share a naming convention and general parameters:
void glBind*(GLenum target, GLuint object);
The * is the type of object, and object is the object to be bound.
The target is where different object types differ. Some objects can be bound to multiple targetsin the context, while others can only be bound to a single specific place. For example, a buffer object can be bound as an array buffer, index buffer, pixel buffer, transform buffer, or various other possibilities.
Different targets have separate bindings. So you can bind a buffer object as an vertex attribute array, and a different buffer object as an index buffer.
If an object is bound to a location where another object is already bound, the previously bound object will be unbound.
The GLuint value 0 is treated specially by OpenGL objects. However, some objects treat it in different ways. 0 will never be returned by a glGen* function.
For most object types, object 0 is much like the NULL pointer: it is not an object. If 0 is bound for such object types, then attempts to use that object for rendering purposes will fail.
For some objects, object 0 represents a kind of "default object". Textures have this concept, though it is very complex, and object 0 cannot be deleted. Such default texture objects cannot be used in many of the ways that real texture objects can (you can't put them in FBOs, for example), so you are strongly encouraged to think of texture 0 as a non-existent texture.
For Framebuffers, object 0 represents the Default Framebuffer. It has similar state to a proper Framebuffer Object, but it has a very different set of images. Also, these images cannot be attached/detatched; this means that many of the FBO-specific interfaces don't work on object 0. Even so, image property query functions do work on object 0, as do general framebuffer interface functions.
|Core in version||4.5|
|Core since version||4.4|
|Core ARB extension||ARB_multi_bind|
A number of object types can be bound to specific, numbered targets. It is therefore useful to be able to bind a group of objects, all at once to a series of targets.
It is important to note that many of these multi-binding forms can only be bound for using the object, not bound for modifying them.
One major difference between these functions and the single-bind functions is this. These functions all take arrays of objects to bind. If one of the objects in that array cannot be bound, if binding it with the single call would cause an OpenGL Error of some kind, then the binding of that object will fail with GL_INVALID_OPERATION.
The difference is that pretty much every other OpenGL function that fails with an error will have no effect all all. These functions still have an effect.. If one particular object cannot be bound for any reason, the rest of the objects that can be bound will still be bound. Only the binding to that particular numbered binding point will fail. The function will still emit the appropriate error if even one of the objects cannot be bound.
Note that this only applies to errors due to a failure to bind a particular buffer or incorrect parameters for a specific buffer. Errors due to an invalid buffer binding range and so forth will change none of the bindings.
The array of objects to bind that these functions take can be NULL. If so, then it will bind 0 to all of the numbered targets in the range. This makes unbinding everything in a range easy.
The objects which can be multi-bound, and their specific uses that allow multi-binding, are as follows. The links below will provide detailed information on these multi-bind functions:
- Buffer objects being bound to one of the indexed buffer binding targets.
- Buffer objects being bound for separate attribute buffers in vertex data.
- Textures and sampler objects being bound for use by GLSL samplers.
- Textures being bound for use by image load/store operations.
You can create multiple OpenGL contexts. This is useful, as the current GL context is thread-specific. Normally, each context is entirely separate from the others; nothing done in one can affect the others.
At context creation time however, you are able to create a context that shares objects with another existing context. This means you can use objects created in one context in another context.
Not all object types can be shared across contexts. Objects that contain references to other objects cannot be shared. All other object types can be shared. This includes GLSL Objects and Sync Objects, which do not follow the OpenGL Object model.
Note that state changes to objects made in one context are not necessarily immediately visible in another. There are specific rules that govern the visibility of object state data. If you are using threading, you need to do some synchronization on your own to ensure that changes made in one context have been made, before trying to use those changes in another context.
Objects can be separated into two different categories: regular objects and container objects. Here is the list of regular objects.
|Core in version||4.5|
|Core since version||4.3|
|Core ARB extension||KHR_debug|
OpenGL Objects, as well as the non-standard objects like Program Objects and Sync Objects, are very useful. However, their names are non-intuitive; they are just numbers (or pointers in the case of sync objects). Furthermore, those numbers are defined by the system, rather than by the user. This makes debugging with objects difficult.
However, OpenGL has a mechanism to associate an arbitrary string name with any object. This also permits system-generated messages to be able to talk about an object by its string name. The functions to set the name for an object are:
void glObjectLabel(GLenum identifier, GLuint name, GLsizei length, const char * label);void glObjectPtrLabel(void * ptr, GLsizei length, const char * label);
The first function is used to set all objects that use GLuints for their object types. This means all OpenGL Objects, as well as all Program Object types. The second function sets the name for Sync Objects.
|GL_VERTEX_ARRAY||Vertex Array Object|
|GL_PROGRAM_PIPELINE||Program Pipeline Object|
|GL_TRANSFORM_FEEDBACK||Transform Feedback Object|
For GLuint-based objects, the object name alone is not enough to identify the object, since two objects of different object types may have the same GLuint name. Therefore, the type is specified by the identifier parameter, which must be one of the enumerators on the left.
The length specifies the length of the string label, which must be less than GL_MAX_LABEL_LENGTH (which will be no less than 256).
To retrieve the name of an object, you use these functions:
void glGetObjectLabel(GLenum identifier, GLuint name, GLsizei bufSize, GLsizei * length, char * label);void glGetObjectPtrLabel(void * ptr, GLsizei bufSize, GLsizei * length, char * label);
The bufSize is the total number of bytes in label; the function will not copy more than this many bytes (including a null-terminator) into label. If length is not NULL, then the function will store the number of characters written into the buffer (including the NULL pointer). If label is NULL, then the total length of the string will be copied into length. If both are NULL, an error results.
The following are "objects", but they do not follow the standard conventions laid out on this page for OpenGL objects:
- Sync Objects
- Shader and Program Objects
- Except for program pipeline objects, which do follow the OpenGL Object conventions.