OpenGL Object

From OpenGL.org
Jump to: navigation, search

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. The object will only contain its default state when it is first bound to the context.

The functions to generate the object's name 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, and 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.

Deletion unbinding

When an object is deleted, if 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.

Note: This says "binding", not "attachment". Binding goes to the context; attachment is what you do when one object references another. Attachments are not severed due to this call.

Some objects can be associated with the context in unusual ways. These ways include, but are not limited to:

In such cases, these binds are not undone when the object is deleted. The only bindings that are undone are bindings that can be undone by calling the basic glBind*​ function for the object type.

So if you call 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.

Deletion orphaning

Calling glDelete*​ on an object does not guarantee its immediate deletion. Because OpenGL is allowed to execute rendering commands well after you issue them (for maximum parallelism and performance), it is entirely possible for an object to remain with the OpenGL server for some time before it actually deletes it.

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 current context. Though remember the caveat above about non-standard binding points.
  • It is attached to a container object.

So if a Texture is attached to a Framebuffer Object, 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.

Note: Some implementations don't implement that last part correctly. So really don't use this.

Object Usage

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.

Object zero

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 Framebuffer Objects, object 0 represents the Default Framebuffer. While it has most of the same interfaces as user-created FBOs, it uses a very different set of images.

Recommendation: With the exception of Framebuffer Objects, you should treat object 0 as a non-functional object. Even if an object type has a valid object 0, you should treat it as if it did not. Treat it as you would the NULL pointer in C/C++; you can store it in a pointer, but you can't use that pointer until you put a real pointer there.

Multibind

Object Multibind
Core in version 4.4
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:

Object Sharing

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.

Object types

Objects can be separated into two different categories: regular objects and container objects. Here is the list of regular objects.

Container objects

Non-standard objects

The following are "objects", but they do not follow the standard conventions laid out on this page for OpenGL objects: