OpenGL defines the concept of an object as being an OpenGL construct that contains some amount of state (ie: values). OpenGL defines a fair number of object types, with many uses throughout the OpenGL API. Some object types are container objects; these objects primarily store references to other objects. Container objects cannot be shared across OpenGL Contexts.
Most OpenGL objects follow a certain set of conventions as to their APIs and use. Objects are not implemented in a C or C++ style, as pointers to some data. They are GLuint integer handles, called "names", that reference the actual data stored in the object. Functions that generate objects will be named glGen*, where * is the object name. Names can be deleted, using a function of the form glDelete*.
Generating a name does not (usually) create the object itself. To do that, it must first be bound to the context. Binding an object to the context means that the object's contained state now becomes part of the context's state. Functions that modify or query those pieces of state will set or retrieve values stored in the object. And rendering functions that rely on these pieces of state will get their data from the object.
Objects are bound with functions of the form glBind*
, where * is the object type. Most OpenGL objects can be bound to multiple locations in the context. These locations, or targets, represent different places where the object's state can be used in different ways. So how rendering works can change based on which target an object is bound to.
A Sampler Object is an object that describes how texture objects are accessed from a Shader. These parameters include how accesses to the texture are to be filtered, whether comparison mode is active, texture coordinate wrapping, and so forth. Texture objects also have these parameters, but a sampler object bound to the same texture image unit will override them.
Unlike most OpenGL objects, you can modify the state of a sampler object without binding it.
A Renderbuffer Object
is an object that represents a single image of a specific Image Format
. Such objects can only be used as render targets for Framebuffer Objects
; they cannot be read from, outside of any operation that reads from the Framebuffer
that the renderbuffer happens to be attached to. They are only useful if you need a particular image for rendering to, such as wanting to render to a texture, but needing a depth buffer for Depth Tests
A Program Pipeline Object
is a container object
that stores a series of separable program objects that contain shaders. Though program objects do not follow the standard OpenGL object model, program pipeline objects do. Program pipelines are light-weight objects that simply represent a specific sequence of shader stages
to execute in a rendering operation.
A Transform Feedback Object
is a container object that represents the state needed for a transform feedback operation. It stores the set of Buffer Objects
that are being written to. Feedback objects also store how many primitives were written in a particular feedback operation; this stored value is implicitly used in certain rendering commands
. Feedback objects can also preserve the current write position, so that feedback operations can be paused and resumed.
Some objects in OpenGL do not fit into the general object paradigm described above. These irregular objects are not considered "OpenGL Objects" in the definitive sense stated above. But they are objects (self-contained pieces of state), they are part of the OpenGL API, and they do have state which can be set and queried.
The irregular objects are described below:
A Program Object stores the executable code and uniform state for one or more Shader stages. The most common means of building them involves the creation of Shader Objects, which represent strings of text in the OpenGL Shading Language. Shader objects are compiled, and if successful, one or more shader objects is linked into a program.
In both cases, the user can query whether compilation or linking failed, and the error messages produced by any such failures.
A Sync Object
is used to detect which commands have finished executing and which have not. Fence sync objects
can be inserted into the command stream, and the user can query when they've completed. Since all OpenGL commands complete in order, if a fence object has completed, so have all operations issued before the fence.