Difference between revisions of "OpenGL Object"

From OpenGL.org
Jump to: navigation, search
(Improved object deletion semantics.)
(Object zero)
Line 90: Line 90:
 
For [[Framebuffer Object]]s, 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.
 
For [[Framebuffer Object]]s, 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.
  
{{recommend|With the exception of [[Framebuffer Object]]s, you should completely ignore object 0. Even if an object type has an 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.}}
+
{{recommend|With the exception of [[Framebuffer Object]]s, you should completely ignore object 0. 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.}}
  
 
== Object Sharing ==
 
== Object Sharing ==

Revision as of 20:24, 14 February 2013

OpenGL Objects are defined in terms of the context state that they contain. 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.

State and Objects

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.

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*(location​, GLuint object​);

The * is the type of object, and object​ is the object to be bound.

The location​ is where different object types differ. Some objects can be bound to multiple locations in 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. If an object can be bound to multiple locations, then there will be some kind of parameter to define where the binding happens. glBindBuffer takes an enumeration, for example.

Different locations have separate bindings. So you can bind a buffer object as an array, and a different buffer object as an index buffer without having any crosstalk between them.

If an object is bound to a location where another object is also 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, so you are strongly encouraged to think of texture 0 as a non-existent texture, as above.

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 completely ignore object 0. 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.

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 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.

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: