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

+

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.

−

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

−

+

−

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.

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.

Line 12:

Line 10:

== Object Creation and Destruction ==

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

+

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 Object]]s and [[Sampler Object]]s.

−

The functions to generate the object's name are of the form {{code|glGen*}}, where * is the object's type in plural form. All functions of this type have the same signature:

+

The functions to generate object names are of the form {{code|glGen*}}, where * is the object's type in plural form. All functions of this type have the same signature:

void glGen*(GLsizei {{param|n}}, GLuint *{{param|objects}});

void glGen*(GLsizei {{param|n}}, GLuint *{{param|objects}});

Line 22:

Line 20:

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.

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 {{code|glGen*}} rather than making up your own object names.

+

: '''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 {{code|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 {{code|glDelete*}}, using the same object type as before. These functions have this signature:

Once you are finished with an object, you should delete it. The functions for this are of the form {{code|glDelete*}}, using the same object type as before. These functions have this signature:

Line 28:

Line 26:

void glDelete*(GLsizei {{param|n}}, const GLuint *{{param|objects}});

void glDelete*(GLsizei {{param|n}}, const GLuint *{{param|objects}});

−

This works like the {{code|glGen*}} functions, only it deletes the objects instead of creating them.

+

This works like the {{code|glGen*}} functions, only it deletes the objects instead of creating them. Any values that are not valid objects or are [[#Object zero|object 0]] will be silently ignored.

When OpenGL objects are deleted, their names are no longer considered valid. Following this call, a subsequent {{code|glGen*}} call may or may not reuse a previously-deleted name; you should not make assumptions either way.

When OpenGL objects are deleted, their names are no longer considered valid. Following this call, a subsequent {{code|glGen*}} call may or may not reuse a previously-deleted name; you should not make assumptions either way.

Line 34:

Line 32:

=== Deletion unbinding ===

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

+

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.

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

{{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:

+

Furthermore, if the object is attached to any [[#Container objects|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 [[#Deletion orphaning|''not'' broken]].

+

+

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

* [[Texture]]s bound as [[Image Load Store#Images in the context|images]].

+

* [[Texture]]s bound as [[Use Image With Shader|images]].

−

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 {{code|glBind*}} function for the object type.

+

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 {{code|glBind*}} function for the object type.

−

So if you call {{apifunc|glBindBufferRange|(GL_UNIFORM_BUFFER, ...)}} and then delete that buffer, it will be as if {{apifunc|glBindBuffer|(GL_UNIFORM_BUFFER, 0)}} was called. This does not unbind it from the indexed target.

+

So if you called {{apifunc|glBindBufferRange|(GL_UNIFORM_BUFFER, ...)}} and then delete that buffer, it will be as if {{apifunc|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.

=== Deletion orphaning ===

=== Deletion orphaning ===

−

Calling {{code|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.

+

Calling {{code|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.

−

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:

+

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 bound to a context. This is not necessarily the current one, since deleting it will [[#Deletion unbinding|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 objects|container object]].

* It is attached to a [[#Container objects|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.

+

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 {{apifunc|glGetFramebufferAttachmentParameter|iv(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 that the name is still detectable via the OpenGL API. You can call {{apifunc|glGetFramebufferAttachmentParameter|iv(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.

Line 70:

Line 72:

Different objects have different binding functions. They do share a naming convention and general parameters:

Different objects have different binding functions. They do share a naming convention and general parameters:

−

void '''glBind*'''({{param|location}}, GLuint {{param|object}});

+

void '''glBind*'''(GLenum {{param|target}}, GLuint {{param|object}});

The * is the type of object, and {{param|object}} is the object to be bound.

The * is the type of object, and {{param|object}} is the object to be bound.

−

The {{param|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. {{apifunc|glBindBuffer}} takes an enumeration, for example.

+

The {{param|target}} is where different object types differ. Some objects can be bound to multiple targets 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.

−

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.

+

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 also bound, the previously bound object will be unbound.

+

If an object is bound to a location where another object is already bound, the previously bound object will be unbound.

=== Object zero ===

=== Object zero ===

Line 84:

Line 86:

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 {{code|glGen*}} function.

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 {{code|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 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 bound object for rendering purposes will fail.

−

For some objects, object 0 represents a kind of "default object". [[Texture]]s 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 some objects, object 0 represents a kind of "default object". [[Texture]]s have a default texture. However, the default texture is very complex to use; texture object 0 technically represents ''multiple'' default textures. Furthermore, default textures cannot be used in many ways that regular texture objects can. For example, you cannot attach images of them to [[Framebuffer Object|FBOs]]. Therefore, you are ''strongly'' encouraged to think of texture 0 as a non-existent texture.

−

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]]s, object 0 represents the [[Default Framebuffer]]. It has similar state compared to a proper [[Framebuffer Object]], but it has a very different set of images with its own image names. Also, these images cannot be attached/detatched; this means that many of the [[Framebuffer Object|FBO-specific interfaces]] don't work on object 0. Even so, [[GLAPI/glGetFramebufferAttachmentParameter|image property query functions]] do work on object 0, as do [[Framebuffer|general framebuffer interface functions.]]

−

{{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 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 value there.}}

+

+

== Multibind ==

+

{{infobox feature

+

| name = Object Multibind

+

| core = 4.4

+

| core_extension = {{extref|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 {{enum|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 Multibind|Buffer objects being bound to one of the indexed buffer binding targets]].

* [[Texture Multibind|Textures and sampler objects being bound for use by GLSL samplers]].

+

* [[Image Multibind|Textures being bound for use by image load/store operations]].

== Object Sharing ==

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

+

You can create multiple [[OpenGL Context|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.

+

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. [[#Container objects|Objects that contain references to other objects]] cannot be shared. All other object types can be shared. This includes [[GLSL Object]]s and [[Sync Object]]s, which do not follow the OpenGL Object model.

Not all object types can be shared across contexts. [[#Container objects|Objects that contain references to other objects]] cannot be shared. All other object types can be shared. This includes [[GLSL Object]]s and [[Sync Object]]s, 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 [[Multithread Object Visibility|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 ==

== Object types ==

Line 116:

Line 146:

* [[Transform Feedback]] Objects

* [[Transform Feedback]] Objects

* [[Vertex Array Object]]s

* [[Vertex Array Object]]s

+

+

== Object names ==

+

{{infobox feature

+

| core = 4.3

+

| core_extension = {{extref|debug|KHR}}

+

}}

+

+

{{snippet|:OpenGL Object/Object Name}}

== Non-standard objects ==

== Non-standard objects ==

Line 122:

Line 160:

* [[Sync Object]]s

* [[Sync Object]]s

−

* [[GLSL Object|GLSL Shader and Program Objects]]

+

* [[GLSL Object|Shader and Program Objects]]

** Except for program pipeline objects, which ''do'' follow the OpenGL Object conventions.

** Except for program pipeline objects, which ''do'' follow the OpenGL Object conventions.

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.

Contents

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.

Deletion unbinding

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.

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.

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:

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.

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.

Deletion orphaning

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.

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

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 bound object for rendering purposes will fail.

For some objects, object 0 represents a kind of "default object". Textures have a default texture. However, the default texture is very complex to use; texture object 0 technically represents multiple default textures. Furthermore, default textures cannot be used in many ways that regular texture objects can. For example, you cannot attach images of them to FBOs. Therefore, you are strongly encouraged to think of texture 0 as a non-existent texture.

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

Multibind

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.

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

Object names

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:

The first function is used to set all objects that use GLuint​s 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.

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

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.

Non-standard objects

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