| Name |
| |
| ARB_vertex_shader |
| |
| Name Strings |
| |
| GL_ARB_vertex_shader |
| |
| Contributors |
| |
| Kurt Akeley |
| Allen Akin |
| Dave Baldwin |
| Pat Brown |
| Matt Craighead |
| Cass Everitt |
| Evan Hart |
| Phil Huxley |
| Dale Kirkland |
| John Kessenich |
| Steve Koren |
| Jon Leech |
| Bill Licea-Kane |
| Benjamin Lipchak |
| Barthold Lichtenbelt |
| Kent Lin |
| Jeremy Morris |
| Teri Morrison |
| Glenn Ortner |
| Randi Rost |
| Jeremy Sandmel |
| Folker Schamel |
| Eskil Steenberg |
| |
| The ARB_vertex_program working group members. Several concepts and |
| chunks of text are copied from the ARB_vertex_program specification. |
| |
| Contact |
| |
| Barthold Lichtenbelt, 3Dlabs, Inc. (barthold 'at' 3dlabs.com) |
| Randi Rost, 3Dlabs, Inc. (rost 'at' 3dlabs.com) |
| |
| Notice |
| |
| Copyright (c) 2003-2013 The Khronos Group Inc. Copyright terms at |
| http://www.khronos.org/registry/speccopyright.html |
| |
| Specification Update Policy |
| |
| Khronos-approved extension specifications are updated in response to |
| issues and bugs prioritized by the Khronos OpenGL Working Group. For |
| extensions which have been promoted to a core Specification, fixes will |
| first appear in the latest version of that core Specification, and will |
| eventually be backported to the extension document. This policy is |
| described in more detail at |
| https://www.khronos.org/registry/OpenGL/docs/update_policy.php |
| |
| IP Status |
| |
| As described in the Contributor License, which can be found at |
| http://developer.3dlabs.com/openGL2/specs/3dlabs_contributor.pdf . |
| |
| Status |
| |
| Complete. Approved by the ARB on June 11, 2003. |
| Updated revision 0.81 approved by the ARB on June 17, 2004. |
| |
| Version |
| |
| Last Modified Date: December 14, 2009 |
| Author Revision: 0.83 |
| |
| Number |
| |
| ARB Extension #31 |
| |
| Dependencies |
| |
| OpenGL 1.0 is required. |
| |
| This extension is written against version 1.10 of the OpenGL Shading |
| Language Specification. |
| |
| The extension is written against the OpenGL 1.4 Specification. |
| |
| The ARB_shader_objects extension is required. |
| |
| Overview |
| |
| This extension adds programmable vertex level processing to OpenGL. The |
| application can write vertex shaders in a high level language as defined |
| in the OpenGL Shading Language specification. The language itself is not |
| discussed here. A vertex shader replaces the transformation, texture |
| coordinate generation and lighting parts of OpenGL, and it also adds |
| texture access at the vertex level. Furthermore, management of vertex |
| shader objects and loading generic attributes are discussed. A vertex |
| shader object, attached to a program object, can be compiled and linked |
| to produce an executable that runs on the vertex processor in OpenGL. |
| This extension also defines how such an executable interacts with the |
| fixed functionality vertex processing of OpenGL 1.4. |
| |
| Issues |
| |
| 1) What does need to be said about invariance (Appendix A of the OpenGL |
| 1.4 spec)? |
| |
| DISCUSSION: Numerous rules and proposals have been discussed. In the |
| end, simplicity is an important goal. It is always possible to later add |
| more invariance rules, if it turns out to be desirable. |
| |
| RESOLUTION: The same shader will produce the same result when run |
| multiple times with the same input. The wording 'the same shader' means |
| a program object that is populated with the same source strings, which |
| are compiled and then linked, possibly multiple times. This program |
| object is executed using the same GL state vector. |
| |
| Position invariance between a vertex shader and the fixed functionality |
| pipeline is important for certain applications. Therefore there must be |
| a way to guarantee that a vertex shader produces the exact same position |
| for a vertex as the fixed function pipeline does. This is achieved by |
| using the built-in function ftransform in a vertex shader, and assign it |
| to the output variable gl_Position. The shader does this instead of |
| computing the product of the ModelViewProjection matrix with the vertex |
| position. See section 2.15.6 for more. |
| |
| 2) Should we take the API commands to load generic vertex attributes |
| from ARB_vertex_program? |
| |
| DISCUSSION: At first glance these commands, for example |
| VertexAttrib3fvARB, look like exactly what this extension needs. |
| However, if we re-use these commands here, how does the GL |
| implementation decide where attributes go when using shaders written |
| using ARB_vertex_program or this extension? What happens to the |
| attribute value when switching between an ARB_vertex_program and an |
| ARB_vertex_shader shader? How does this resolve with respect to |
| undefined aliasing defined in ARB_vertex_program and the no aliasing |
| defined in this extension? |
| |
| RESOLUTION: Resolved, we will re-use these entry points. It is very |
| convenient for an ISV to be able to re-use the entry points to load |
| data, and only have to switch shaders when it wants to go from an |
| ARB_vertex_program shader to an ARB_vertex_shader shader. This extension |
| allows for no aliasing among generic attributes and standard vertex |
| attributes, whereas ARB_vertex_program has the concept of undefined |
| aliasing. In order to resolve this the interactions section extends |
| ARB_vertex_program to expose this no aliasing approach. Note that we do |
| not lift the restriction in the grammar on invalid attribute binding |
| pairs, see Table X.2.1 in the ARB_vertex_program specification. |
| |
| 3) Should we take the API commands to load generic vertex arrays from |
| ARB_vertex_program? |
| |
| DISCUSSION: See issue 2. |
| |
| RESOLUTION: Resolved, yes we will re-use these entry points. See also |
| the previous issue resolution. |
| |
| 4) Should we take the API commands to query the values of generic |
| attributes from ARB_vertex_program? |
| |
| DISCUSSION: This goes hand in hand with issue 2. |
| |
| RESOLUTION: Yes we will. |
| |
| 5) Do we need to specify how Evaluators and AUTO_NORMAL generation |
| interacts? |
| |
| DISCUSSION: ARB_vertex_program specifies that for evaluated normals the |
| normal is no longer automatically normalized when a vertex shader is |
| active. This is discussed in detail in issue 92 in the |
| ARB_vertex_program specification. |
| |
| RESOLUTION: We will follow ARB_vertex_program. |
| |
| 6) What should the initial value of the generic vertex attributes be? |
| |
| DISCUSSION: ARB_vertex_program leaves their initial values undefined. It |
| seems to make sense to do so, because of the undefined aliasing. In this |
| extension there is no aliasing among conventional and generic |
| attributes. Hence it could be desirable to define the initial values to |
| be (0, 0, 0, 1). |
| |
| RESOLUTION: The initial values are (0, 0, 0, 1). |
| |
| 7) Do generic attributes push and pop? |
| |
| DISCUSSION: There has been some concern that adding more state than |
| strictly necessary is a performance issue for applications that push and |
| pop a lot. Conventional attributes are pushed and popped, as well as |
| generic attributes, by ARB_vertex_program. |
| |
| RESOLUTION: YES, they are part of GL state, and such should push and pop |
| under the 'current' bit. Note that an OpenGL implementation could track |
| if a generic attribute has been set, and as long as it has not, never |
| push/pop that attribute. |
| |
| 8) How does user clipping work? |
| |
| DISCUSSION: The OpenGL Shading Language provides a gl_ClipVertex |
| built-in variable in the vertex shading language. This variable provides |
| a place for vertex shaders to specify a coordinate to be used by the |
| user clipping plane stage. The user must ensure that the clip vertex and |
| user clipping planes are defined in the same coordinate space. Note that |
| this is different than ARB_vertex_program, where user clipping is |
| ignored unless the position invariant option is enabled (where all |
| vertex transformation options are performed by the fixed functionality |
| pipeline). Here are some tips on how to use user clipping in a vertex |
| shader: |
| |
| 1) When using a traditional transform in a vertex shader, compute the |
| eye coordinates and store the result in gl_ClipVertex. |
| |
| 2) If clip planes are enabled with a vertex shader, gl_ClipVertex must |
| be written to, otherwise results will be undefined. |
| |
| 3) When doing object-space clipping, keep in mind that the clip planes |
| are automatically transformed to eye coordinates (see section 2.11 |
| of the GL 1.4 spec). Use an identity modelView matrix to avoid this |
| transformation. |
| |
| RESOLUTION: Resolved. See also section 2.11. |
| |
| 9) Do we need a vertex shader point size enable? |
| |
| DISCUSSION: ARB_vertex_program provides an enable, |
| VERTEX_PROGRAM_POINT_SIZE_ARB. This extension uses the same enable. If |
| VERTEX_PROGRAM_POINT_SIZE mode is enabled, and a vertex shader is |
| active, then the point size is taken from the vertex shader's point size |
| result, otherwise it is taken from the PointSize command. The OpenGL |
| Shading Language provides a built-in gl_PointSize that a vertex shader |
| can write to, to specify the point size in pixels. If gl_PointSize is |
| not written while the point size mode is enabled then the point size |
| used in the rasterization stage is undefined. |
| |
| This point size enable is convenient for the majority of applications |
| who do not change the point size. Not setting the enable means the point |
| size is picked up automatically, instead of having to write a shader |
| which always outputs the same point size. |
| |
| RESOLUTION: Yes. |
| |
| 10) How to handle the color sum stage? |
| |
| DISCUSSION: It is the vertex shader's responsibility to write a primary |
| and secondary color into the appropriate built in varying variables, if |
| subsequent stages in the pipeline use these. Otherwise results are |
| undefined. Section 3.9 of the OpenGL 1.4 spec states that the color sum |
| stage is always applied when lighting is enabled, ignoring the value of |
| the COLOR_SUM enable bit. Should we take out this automatic enable when |
| lighting is enabled? |
| |
| RESOLUTION: This automatic enable will only have effect when no vertex |
| shader is active. This behavior is the same in ARB_vertex_program. |
| |
| 11) Does generic attribute zero also provoke (signal the end of a |
| vertex), or just the glVertex command? |
| |
| DISCUSSION: To be more compatible with ARB_vertex_program this would be |
| desirable. It may be that no attribute directly expresses a vertex |
| position. The shader may derive the position based on multiple |
| attributes, where there is no clear attribute that can be marked as "the |
| vertex". On the other hand, it is mandatory in a vertex shader to write |
| to gl_Vertex. Thus it makes some sense that the glVertex API has to be |
| used to signal the end of a vertex. |
| |
| RESOLUTION: Resolved. For compatibility reasons, attribute zero will |
| also provoke. |
| |
| 12) How to handle texture access from a vertex shader? |
| |
| DISCUSSION: The OpenGL Shading Language allows for texture access from a |
| vertex shader. What is the OpenGL support necessary to make that |
| actually happen? Two approaches seem feasible. 1) Virtualize the number |
| of texture image units available in OpenGL. Deprecate the concept of |
| binding a texture object to a texture image unit. Instead, bind a |
| texture object directly to a sampler. 2) A not so drastic approach that |
| makes a maximum number of texture image units available to a vertex |
| shader as well as to the fragment processing part of the OpenGL |
| pipeline. The sum of the available texture image units cannot exceed the |
| constant MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB. |
| |
| RESOLUTION: Option 2) is what is used in this specification. Option 1) |
| is a more invasive approach, and left for a future extension. |
| |
| This approach allows for two types of hardware. One where the hardware |
| resources to perform the functions associated with a texture image unit |
| are not shared between a vertex and fragment shader, and one type of |
| hardware where they are shared. The maximum number of texture image |
| units available to a vertex shader is |
| MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB. The maximum number of texture image |
| units available to the fragment stage of OpenGL is |
| MAX_TEXTURE_IMAGE_UNITS_ARB. Now consider, for example, an |
| implementation that supports up to 16 texture stages and shares its |
| texture mapping resources between the vertex shader and fragment shader. |
| For this implementation MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB, |
| MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB and MAX_TEXTURE_IMAGE_UNITS_ARB would |
| all be set to 16. A hardware implementation which does not share its |
| texture mapping resources, and who can support 2 texture stages for a |
| vertex shader and 16 texture stages for the fragment processing, would |
| set MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB to 18, |
| MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB to 2 and MAX_TEXTURE_IMAGE_UNITS_ARB |
| to 16. A vertex shader cannot use more than |
| MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB texture image units. The fragment |
| processing part of OpenGL cannot use more than |
| MAX_TEXTURE_IMAGE_UNITS_ARB texture image units. |
| |
| Both the vertex shader and fragment processing combined cannot use more |
| than MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB texture image units. If a |
| vertex shader and fragment processing part of OpenGL both use the same |
| texture image unit, then that counts as separate units against the above |
| mentioned limits. |
| |
| Automatic LOD calculation does not happen during vertex processing in a |
| vertex shader, hence there is no automatic selection of an image array |
| level. Minification or magnification of a texture map is controlled by a |
| LOD value passed as an argument in some of the built-in texture lookup |
| functions. These built-in texture lookup functions, defined in the |
| OpenGL Shading Language, come in two flavors. One set of lookup |
| functions that take a LOD value as an input, and one set that does not |
| take a LOD value. |
| |
| If the former set of functions is used, then the LOD value passed in is |
| used directly as the LOD value lambda' in section 3.8.8 equation 3.16 on |
| page 140 of the OpenGL 1.4 spec. This in turn defines lambda, which then |
| is used as usual to determine magnification or minification and, when |
| mipmapping, which mipmap array(s) to select. |
| |
| If the latter set of functions is used, then lambda, the result of |
| equation 3.16, is set to zero. This effectively means a texture object |
| is considered magnified, and only paragraph 3.8.9 applies. |
| |
| 13) Do we split a texture unit into a texture image unit and a texture |
| coordinate set? |
| |
| DISCUSSION: This is what ARB_fragment_program does, and |
| ARB_fragment_shader as well. The OpenGL Shading Language allows for |
| texture lookups in a vertex shader. This means that a vertex shader |
| should have access to a texture image unit (texture maps and associated |
| parameters). A vertex shader also has access to state stored with a |
| texture coordinate set, which encompasses vertex texture coordinate |
| attributes, as well as the texture matrix stack and texture generation |
| state. The number of supported texture image units and texture |
| coordinate sets is not necessarily the same on a particular |
| implementation. |
| |
| RESOLUTION: Yes |
| |
| 14) Do we need to specify different texture coordinate sets for a vertex |
| shader and fragment processing? |
| |
| DISCUSSION: So far there are MAX_TEXTURE_COORDS_ARB texture coordinate |
| sets. This constant is defined in ARB_fragment_program, and re-used in |
| ARB_fragment_shader as well as the OpenGL Shading Language (see built-in |
| constants, section 7.4). Only a vertex shader has access to vertex |
| texture coordinate attributes. But both an ARB vertex and fragment |
| shader has access to the other state associated with a texture |
| coordinate set. That state is texture generation and the texture matrix |
| stack. |
| |
| RESOLUTION: NO. |
| |
| 15) What is the minimum value for MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB? |
| |
| DISCUSSION: Should this be zero, or more? |
| |
| RESOLUTION: Resolved, zero. |
| |
| 16) Do we also need a built in function to guarantee position invariance |
| with respect to user clip planes? |
| |
| DISCUSSION: Issue 1 discusses invariance with respect to the vertex |
| position. A vertex shader however can also output coordinates used for |
| subsequent user clipping, by writing to gl_ClipVertex. In other words, |
| do we need something like gl_ClipVertex = ftransformClip()? |
| |
| RESOLUTION: NO, position invariance with respect to user clipping seems |
| like a rarely needed feature. The OpenGL Shading Language does not have |
| a ftransformClip() built-in function. If this functionality is ever |
| needed, it is easy to add later. |
| |
| 17) What happens to the point size when a vertex shader is active? |
| |
| DISCUSSION: The point size is taken from the built-in gl_PointSize when |
| VERTEX_PROGRAM_POINT_SIZE_ARB is enabled, but what to do with distance |
| attenuation and point fade (see Section 3.3)? |
| |
| RESOLUTION: Resolved. The vertex shader should compute distance |
| attenuation. Fixed function computes it as a function of, among others, |
| eyeZ. It is not required for a vertex shader to compute eyeZ, and the |
| fixed function eyeZ might have nothing to do with the vertex position |
| computed in the vertex shader. Point fade, however, should still be |
| fixed function. The vertex shader could compute a point fade, but it'll |
| produce incorrect results if the application issues the following |
| commands: |
| |
| glPolygonMode(GL_FRONT, GL_FILL); |
| glPolygonMode(GL_BACK, GL_POINT); |
| |
| In this case you would want to fade if a vertex belonged to a |
| back-facing triangle, but not if it could belong to a front-facing one. |
| |
| 18) What is the deal with range and precision of colors once output from |
| the vertex shader? |
| |
| DISCUSSION: Section 2.13.6 of the GL 1.4 spec specifies that all |
| components of both the primary and secondary colors be clamped to the |
| range [0,1]. Section 2.13.9 furthermore specifies that each color |
| component be converted to a fixed-point value with enough bits to |
| satisfy the frame buffer depth. Section 2.1.1 says that the maximum |
| representable magnitude of a floating-point number for colors must be at |
| least 2^10. |
| |
| It is desirable to bypass clamping of colors when an ARB_fragment_shader |
| shader is also active. It has utility to be able to exceed the range |
| [0,1] and deal with extended range colors in a fragment shader. |
| |
| Varying variables, including the built-in color variables, are declared |
| as floating point vectors in the OpenGL Shading Language, and |
| interpolated as floating-point values. It does not seem to make much |
| sense to specify a conversion to fixed-point after the ARB vertex shader |
| writes colors, then interpolate those fixed-point colors, then convert |
| the interpolated values back to floating point for input in the ARB |
| fragment shader. |
| |
| ARB_fragment_program leaves the primary and secondary colors as the only |
| varying variables that have less range (2^10) than any other varying. It |
| promoted texture coordinates to full citizens with a maximum |
| representable magnitude of at least 2^32. |
| |
| There are three cases to consider: |
| |
| 1) An ARB_vertex_shader shader writing colors that are consumed by an |
| ARB_fragment_shader shader. |
| 2) An ARB_vertex_shader shader writing colors that are consumed by an |
| ARB_fragment_program shader. |
| 3) An ARB_vertex_shader shader writing colors that are consumed by |
| fixed-function fragment processing. |
| |
| An argument can be made that a shader writer can bypass the clamping and |
| conversion to fixed-point by defining its own varying variables, and use |
| that to interpolate colors. It can then use the built-in gl_FrontFacing |
| in a fragment shader for front or back face color selection. This is |
| certainly true, but it bypasses the (fixed-function) front and back face |
| color selection, which happens in a stage after the vertex shader. This |
| front/back face selection stage can only be used when writing to the |
| vertex shader built-in gl_FrontColor, gl_BackColor, |
| gl_FrontSecondaryColor and gl_BackSecondaryColor. |
| |
| RESOLUTION: We anticipate future extensions will generalize the final |
| color-processing clamp with an enable/disable clamp. Therefore, this |
| specification will leave the final color clamp and conversion to |
| fixed-point in place for gl_FrontColor, gl_FrontSecondaryColor, |
| gl_BackColor, and gl_BackSecondaryColor. |
| |
| 19) How do I get a list of all attributes and their types used by a |
| shader and when do I bind generic vertex attributes? |
| |
| DISCUSSION: GetActiveAttribARB will return the name of an attribute and |
| its type declared and actually used in the shader, as determined by the |
| compiler and linker. Looping over all attributes and calling |
| GetActiveAttribARB will generate the list of attribute names and types |
| used in a shader. This list is called the active attributes list. |
| GetActiveAttribARB can be called after a link attempt. It is not |
| necessary for the link to have succeeded. After all, one of the reasons |
| the link failed could be that there are too many active attributes. It |
| is not required to call BindAttribLocationARB before issuing |
| GetActiveAttribARB. BindAttributeLocationARB can be called any time. In |
| order to have a BindAttribLocationARB command take effect, the program |
| object will have to be (re)linked. Thus the order of commands to get the |
| list of active attributes could be: Link the program object, call |
| GetActiveAttribARB as many times as needed, call BindAttribLocationARB |
| one or more times, then call link again. |
| |
| It is allowed to issue BindAttribLocationARB before any vertex shader |
| objects are attached to a program object. Hence it is allowed to bind |
| any name to a location, including a name that is never used as an |
| attribute in any vertex shader object. |
| |
| RESOLUTION: Resolved, call GetActiveAttribARB. |
| |
| 20) Who assigns vertex attribute variable names to indices used in the |
| VertexAttrib*ARB commands? |
| |
| DISCUSSION: Both the GL and the application can do this. The linker will |
| assign indices to vertex attributes declared in a vertex shader. These |
| values can be queried by the application and used to load values for the |
| generic vertex attributes. Alternatively the application can override |
| this assignment, and bind attribute variable names to any generic vertex |
| attribute index of their choice, within the range 0 to |
| MAX_VERTEX_ATTRIBS_ARB. An application would have to do this when |
| building a display list, for example. In this case it is possible to |
| generate the display list before the program object has even been |
| created. |
| |
| Only indices for generic attributes can be queried, or set. Conventional |
| attributes are handled by the GL, and guaranteed to not alias with |
| generic attributes. |
| |
| RESOLUTION: Both the GL and the application. |
| |
| 21) How should this extension handle changes to material state within |
| Begin/End? |
| |
| DISCUSSION: Supporting per-vertex material properties places additional |
| pressure on the number of per-vertex bindings an OpenGL implementation |
| can support, which already is a scarce resource. |
| |
| RESOLUTION: Materials are declared as uniforms in the OpenGL Shading |
| Language. Any changes to the material properties inside a Begin/End |
| through Material commands, or indirectly through ColorMaterial and Color |
| commands, are not guaranteed to actually update material state until the |
| next End command. At that point, all material property state is |
| guaranteed to be updated. |
| |
| In practice, material properties are usually not changed within |
| Begin/End. Applications needing to change material properties inside a |
| Begin/End in a vertex shader can work around this limitation by storing |
| the color in a conventional or generic vertex attribute and modifying |
| the vertex shader accordingly. |
| |
| 22) What space are gl_Position and gl_ClipVertex in? |
| |
| DISCUSSION: The GL treats the values in the built-in output variable |
| gl_Position as being in clip space, for the purpose of clipping against |
| the clip volume. See Section 2.11 of the OpenGL 1.4 specification. The |
| GL treats the values in the (optional) built-in output variable |
| gl_ClipVertex as being in eye-space for clipping against a |
| client-defined clip plane. |
| |
| RESOLUTION: clip-space and eye-space respectively. |
| |
| 23) What texture operations are not affected by a vertex shader |
| performing a texture lookup? |
| |
| RESOLUTION: Whether or not a vertex shader is active, the following |
| operations still behave as specified: |
| |
| * texture image specification (pp. 119-128) |
| * alternate texture image specification (pp. 128-132) |
| * compressed texture image specification (pp. 132-135) |
| * texture parameters behave as specified even when a texture is |
| accessed from within a vertex shader (pp. 135-147) |
| * texture state and proxy state (pp. 148-149) |
| * texture object specification (pp. 149-152) |
| * texture comparison modes (p. 157) |
| |
| New Procedures and Functions |
| |
| void VertexAttrib1fARB(uint index, float v0) |
| void VertexAttrib1sARB(uint index, short v0) |
| void VertexAttrib1dARB(uint index, double v0) |
| void VertexAttrib2fARB(uint index, float v0, float v1) |
| void VertexAttrib2sARB(uint index, short v0, short v1) |
| void VertexAttrib2dARB(uint index, double v0, double v1) |
| void VertexAttrib3fARB(uint index, float v0, float v1, float v2) |
| void VertexAttrib3sARB(uint index, short v0, short v1, short v2) |
| void VertexAttrib3dARB(uint index, double v0, double v1, double v2) |
| void VertexAttrib4fARB(uint index, float v0, float v1, float v2, float v3) |
| void VertexAttrib4sARB(uint index, short v0, short v1, short v2, short v3) |
| void VertexAttrib4dARB(uint index, double v0, double v1, double v2, double v3) |
| void VertexAttrib4NubARB(uint index, ubyte x, ubyte y, ubyte z, ubyte w) |
| |
| void VertexAttrib1fvARB(uint index, const float *v) |
| void VertexAttrib1svARB(uint index, const short *v) |
| void VertexAttrib1dvARB(uint index, const double *v) |
| void VertexAttrib2fvARB(uint index, const float *v) |
| void VertexAttrib2svARB(uint index, const short *v) |
| void VertexAttrib2dvARB(uint index, const double *v) |
| void VertexAttrib3fvARB(uint index, const float *v) |
| void VertexAttrib3svARB(uint index, const short *v) |
| void VertexAttrib3dvARB(uint index, const double *v) |
| void VertexAttrib4fvARB(uint index, const float *v) |
| void VertexAttrib4svARB(uint index, const short *v) |
| void VertexAttrib4dvARB(uint index, const double *v) |
| void VertexAttrib4ivARB(uint index, const int *v) |
| void VertexAttrib4bvARB(uint index, const byte *v) |
| |
| void VertexAttrib4ubvARB(uint index, const ubyte *v) |
| void VertexAttrib4usvARB(uint index, const ushort *v) |
| void VertexAttrib4uivARB(uint index, const uint *v) |
| |
| void VertexAttrib4NbvARB(uint index, const byte *v) |
| void VertexAttrib4NsvARB(uint index, const short *v) |
| void VertexAttrib4NivARB(uint index, const int *v) |
| void VertexAttrib4NubvARB(uint index, const ubyte *v) |
| void VertexAttrib4NusvARB(uint index, const ushort *v) |
| void VertexAttrib4NuivARB(uint index, const uint *v) |
| |
| void VertexAttribPointerARB(uint index, int size, enum type, boolean normalized, |
| sizei stride, const void *pointer) |
| |
| void EnableVertexAttribArrayARB(uint index) |
| void DisableVertexAttribArrayARB(uint index) |
| |
| void BindAttribLocationARB(handleARB programObj, uint index, const charARB *name) |
| |
| void GetActiveAttribARB(handleARB programObj, uint index, sizei maxLength, |
| sizei *length, int *size, enum *type, charARB *name) |
| |
| GLint GetAttribLocationARB(handleARB programObj, const charARB *name) |
| |
| void GetVertexAttribdvARB(uint index, enum pname, double *params) |
| void GetVertexAttribfvARB(uint index, enum pname, float *params) |
| void GetVertexAttribivARB(uint index, enum pname, int *params) |
| void GetVertexAttribPointervARB(uint index, enum pname, void **pointer) |
| |
| New Tokens |
| |
| Accepted by the <shaderType> argument of CreateShaderObjectARB and |
| returned by the <params> parameter of GetObjectParameter{if}vARB: |
| |
| VERTEX_SHADER_ARB 0x8B31 |
| |
| Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, |
| GetFloatv, and GetDoublev: |
| |
| MAX_VERTEX_UNIFORM_COMPONENTS_ARB 0x8B4A |
| MAX_VARYING_FLOATS_ARB 0x8B4B |
| MAX_VERTEX_ATTRIBS_ARB 0x8869 |
| MAX_TEXTURE_IMAGE_UNITS_ARB 0x8872 |
| MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB 0x8B4C |
| MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB 0x8B4D |
| MAX_TEXTURE_COORDS_ARB 0x8871 |
| |
| Accepted by the <cap> parameter of Disable, Enable, and IsEnabled, and |
| by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and |
| GetDoublev: |
| |
| VERTEX_PROGRAM_POINT_SIZE_ARB 0x8642 |
| VERTEX_PROGRAM_TWO_SIDE_ARB 0x8643 |
| |
| Accepted by the <pname> parameter GetObjectParameter{if}vARB: |
| |
| OBJECT_ACTIVE_ATTRIBUTES_ARB 0x8B89 |
| OBJECT_ACTIVE_ATTRIBUTE_MAX_LENGTH_ARB 0x8B8A |
| |
| Accepted by the <pname> parameter of GetVertexAttrib{dfi}vARB: |
| |
| VERTEX_ATTRIB_ARRAY_ENABLED_ARB 0x8622 |
| VERTEX_ATTRIB_ARRAY_SIZE_ARB 0x8623 |
| VERTEX_ATTRIB_ARRAY_STRIDE_ARB 0x8624 |
| VERTEX_ATTRIB_ARRAY_TYPE_ARB 0x8625 |
| VERTEX_ATTRIB_ARRAY_NORMALIZED_ARB 0x886A |
| CURRENT_VERTEX_ATTRIB_ARB 0x8626 |
| |
| Accepted by the <pname> parameter of GetVertexAttribPointervARB: |
| |
| VERTEX_ATTRIB_ARRAY_POINTER_ARB 0x8645 |
| |
| Returned by the <type> parameter of GetActiveAttribARB: |
| |
| FLOAT 0x1406 |
| FLOAT_VEC2_ARB 0x8B50 |
| FLOAT_VEC3_ARB 0x8B51 |
| FLOAT_VEC4_ARB 0x8B52 |
| FLOAT_MAT2_ARB 0x8B5A |
| FLOAT_MAT3_ARB 0x8B5B |
| FLOAT_MAT4_ARB 0x8B5C |
| |
| Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation) |
| |
| Modify Section 2.1.1, Floating-Point Computation (p. 6) |
| |
| (modify first paragraph, p. 6) ... are accurate to about 1 part in 10^5. |
| The maximum representable magnitude of a floating-point number used to |
| represent positional, normal or texture coordinates must be at least |
| 2^32. The maximum representable magnitude for colors must be at least |
| 2^10. The maximum representable magnitude for all other floating-point |
| values must be at least 2^32. |
| |
| Modify Section 2.6, Begin/End Paradigm (p. 12) |
| |
| (modify last paragraph, p. 12) Each vertex is specified with two, three, |
| or four coordinates. In addition, a current normal, multiple current |
| texture coordinate sets, multiple current generic vertex attributes, |
| current color ... Generic vertex attributes can be accessed from within |
| vertex shaders (section 2.15) and used to compute values for consumption |
| by later processing stages. |
| |
| Modify Section 2.6.3, GL Commands within Begin/End (p. 19) |
| |
| (modify first paragraph of section, p. 19) The only GL commands that are |
| allowed within any Begin/End pairs are the commands for specifying |
| vertex coordinates, vertex colors, normal coordinates, texture |
| coordinates, generic vertex attributes and fog coordinates (Vertex, |
| Color, SecondaryColor, Index, Normal, TexCoord and MultiTexCoord, |
| VertexAttrib*ARB, FogCoord), ... |
| |
| Modify Section 2.7, Vertex Specification (p. 19) |
| |
| (modify second paragraph, p. 20) Implementations support more than one |
| set of texture coordinates. The commands |
| |
| void MultiTexCoord{1234}{sifd}(enum texture, T coords) |
| void MultiTexCoord{1234}{sifd}v(enum texture, T coords) |
| |
| take the coordinate set to be modified as the <texture> parameter. |
| <texture> is a symbolic constant of the form TEXTUREi, indicating that |
| texture coordinate set i is to be modified. The constants obey TEXTUREi |
| = TEXTURE0 + i (i is in the range 0 to k-1, where k is the |
| implementation-dependent number of texture coordinate sets defined by |
| MAX_TEXTURE_COORDS_ARB). |
| |
| (remove the "Finally" from the second paragraph on p. 21) |
| |
| (add the following prior to the last paragraph in the section, p. 21) |
| |
| Vertex shaders (see Section 2.15) can be written to access an array of |
| 4-component generic vertex attributes in addition to the conventional |
| attributes specified previously. The first slot of this array is |
| numbered 0, and the length of the array is specified by the |
| implementation-dependent constant MAX_VERTEX_ATTRIBS_ARB. |
| |
| The commands |
| |
| void VertexAttrib{1234}{sfd}ARB(uint index, T values) |
| void VertexAttrib{123}{sfd}vARB(uint index, T values) |
| void VertexAttrib4{bsifd ubusui}vARB(uint index, T values) |
| |
| can be used to load the given value(s) into the generic attribute at |
| slot <index>, whose components are named <x>, <y>, <z>, and <w>. The |
| VertexAttrib1*ARB family of commands sets the <x> coordinate to the |
| provided single argument while setting <y> and <z> to 0 and <w> to 1. |
| Similarly, VertexAttrib2*ARB commands set <x> and <y> to the specified |
| values, <z> to 0 and <w> to 1; VertexAttrib3*ARB commands set <x>, <y>, |
| and <z>, with <w> set to 1, and VertexAttrib4*ARB commands set all four |
| coordinates. The error INVALID_VALUE is generated if <index> is greater |
| than or equal to MAX_VERTEX_ATTRIBS_ARB. |
| |
| The commands |
| |
| void VertexAttrib4NubARB(uint index, T values) |
| void VertexAttrib4N{bsi ubusui}vARB(uint index, T values) |
| |
| also specify vertex attributes with fixed-point coordinates that are |
| scaled to a normalized range, according to Table 2.6. |
| |
| The VertexAttrib*ARB entry points defined earlier can also be used to |
| load attributes declared as a 2x2, 3x3 or 4x4 matrix in a vertex shader. |
| Each column of a matrix takes up one generic 4-component attribute slot |
| out of the MAX_VERTEX_ATTRIBS_ARB available slots. Matrices are loaded |
| into these slots in column major order. Matrix columns need to be loaded |
| in increasing slot numbers. |
| |
| Setting generic vertex attribute zero specifies a vertex; the four |
| vertex coordinates are taken from the values of attribute zero. A |
| Vertex2, Vertex3, or Vertex4 command is completely equivalent to the |
| corresponding VertexAttrib*ARB command with an index of zero. Setting |
| any other generic vertex attribute updates the current values of the |
| attribute. There are no current values for vertex attribute zero. |
| |
| There is no aliasing among generic attributes and conventional |
| attributes. In other words, an application can set all |
| MAX_VERTEX_ATTRIBS_ARB generic attributes and all conventional |
| attributes without fear of one particular attribute overwriting the |
| value of another attribute. |
| |
| (Change the first half of the last paragraph in the section, p. 21, to) |
| |
| The state required to support vertex specification consists of four |
| floating-point numbers per texture coordinate set to store the current |
| texture coordinates s, t, r, and q, three floating-point numbers to |
| store the three coordinates of the current normal, one floating-point |
| number to store the current fog coordinate, four floating- point values |
| to store the current RGBA color, four floating-point values to store the |
| current RGBA secondary color, one floating-point value to store the |
| current color index, and MAX_VERTEX_ATTRIBS_ARB-1 four-component |
| floating-point vectors for generic vertex attributes. There is no notion |
| of a current vertex, so no state is devoted to vertex coordinates or |
| generic vertex attribute zero. The initial texture coordinates are |
| (S,T,R,Q) = (0,0,0,1) for each texture coordinate set. The initial |
| current normal has coordinates (0,0,1). The initial fog coordinate is |
| zero. The initial RGBA color is (R,G,B,A) = (1,1,1,1) and the initial |
| RGBA secondary color is (0, 0, 0, 1). The initial color index is 1. The |
| initial values for all generic vertex attributes are (0, 0, 0, 1). |
| |
| Modify Section 2.8, Vertex Arrays (p. 23) |
| |
| (modify first paragraph of section, p.23) The vertex specification |
| commands described in section 2.7 accept data in almost any format, but |
| their use requires many command executions to specify even simple |
| geometry. Vertex data may also be placed into arrays that are stored in |
| the client's address space. Blocks of data in these arrays may then be |
| used to specify multiple geometric primitives through the execution of a |
| single GL command. The client may specify up to 7 plus the values of |
| MAX_TEXTURE_COORDS_ARB and MAX_VERTEX_ATTRIBS_ARB arrays: One each to |
| store vertex coordinates, edge flags, colors, secondary colors, color |
| indices, normals, fog coordinates, one or more texture coordinate sets, |
| and one or more generic vertex attributes. |
| |
| The commands |
| |
| ... |
| |
| void VertexAttribPointerARB(uint index, int size, enum type, |
| boolean normalized, sizei stride, |
| const void *pointer) |
| |
| describe the locations and organizations... |
| |
| (add after the first paragraph, p.24) The <index> parameter in the |
| VertexAttribPointerARB command identifies the generic vertex attribute |
| array being described. The error INVALID_VALUE is generated if <index> |
| is greater than or equal to MAX_VERTEX_ATTRIBS_ARB. The <normalized> |
| parameter in the VertexAttribPointerARB command identifies whether |
| fixed-point types should be normalized when converted to floating-point. |
| If <normalized> is TRUE, fixed-point data are converted as specified in |
| Table 2.6; otherwise, the fixed-point values are converted directly. |
| |
| (add to the beginning of the page, p. 25) An individual generic vertex |
| attribute array is enabled or disabled by calling one of |
| |
| void EnableVertexAttribArrayARB(uint index) |
| void DisableVertexAttribArrayARB(uint index) |
| |
| where <index> identifies the generic vertex attribute array to enable or |
| disable. The error INVALID_VALUE is generated if <index> is greater than |
| or equal to MAX_VERTEX_ATTRIBS_ARB. |
| |
| (modify Table 2.4, p.24) |
| |
| Normal |
| Command Sizes ized? Types |
| ---------------------- ------- ------ --------------------------- |
| VertexPointer 2,3,4 no short, int, float, double |
| NormalPointer 3 yes byte, short, int, float, |
| double |
| ColorPointer 3,4 yes byte, ubyte, short, ushort, |
| int, uint, float, double |
| SecondaryColorPointer 3 yes byte, ubyte, short, ushort, |
| int, uint, float, double |
| IndexPointer 1 no ubyte, short, int, float, |
| double |
| FogCoordPointer 1 n/a float, double |
| TexCoordPointer 1,2,3,4 no short, int, float, double |
| EdgeFlagPointer 1 no boolean |
| VertexAttribPointerARB 1,2,3,4 flag byte, ubyte, short, ushort, |
| int, uint, float, double |
| |
| Table 2.4: Vertex array sizes (values per vertex) and data types. The |
| "normalized" column indicates whether fixed-point types are accepted |
| directly or normalized to [0,1] (for unsigned types) or [-1,1] (for |
| signed types). For generic vertex attributes, fixed-point data are |
| normalized if and only if the <normalized> flag is set. |
| |
| (modify first paragraph, p. 25) The command |
| |
| void ClientActiveTexture(enum texture) |
| |
| is used to select the vertex array client state parameters to be |
| modified by the TexCoordPointer command and the array affected by |
| EnableClientState and DisableClientState with parameter |
| TEXTURE_COORD_ARRAY. This command sets the client state variable |
| CLIENT_ACTIVE_TEXTURE. Each texture coordinate set has a client state |
| vector which is selected when this command is invoked. This state vector |
| includes the vertex array state. This call also selects the texture |
| coordinate set state used for queries of client state. |
| |
| (modify third paragraph, p. 25) The command |
| |
| void ArrayElement(int i); |
| |
| transfers the ith element of every enabled array to the GL. The effect |
| of ArrayElement(i) is the same as the effect of the command sequence |
| |
| if (normal array enabled) { |
| Normal3[type]v(normal array element i); |
| } |
| if (color array enabled) { |
| Color[size][type]v(color array element i); |
| } |
| if (secondary color array enabled) { |
| SecondaryColor3[type]v(secondary color array element i); |
| } |
| if (fog coordinate array enabled) { |
| FogCoord[type]v(fog coordinate array element i); |
| } |
| for (j = 0; j < textureUnits; j++) { |
| if (texture coordinate set j array enabled) { |
| MultiTexCoord[size][type]v(TEXTURE0 + j, |
| texture coordinate set j |
| array element i); |
| } |
| if (color index array enabled) { |
| Index[type]v(color index array element i); |
| } |
| if (edge flag array enabled) { |
| EdgeFlagv(edge flag array element i); |
| } |
| for (j = 1; j < genericAttributes; j++) { |
| if (generic vertex attribute j array enabled) { |
| if (generic vertex attribute j array normalization flag |
| is set, and type is not FLOAT or DOUBLE) { |
| VertexAttrib[size]N[type]vARB(j, generic vertex attribute j |
| array element i); |
| } else { |
| VertexAttrib[size][type]vARB(j, generic vertex attribute j |
| array element i); |
| } |
| } |
| } |
| if (generic attribute array 0 enabled) { |
| if (generic vertex attribute 0 array normalization flag |
| is set, and type is not FLOAT or DOUBLE) { |
| VertexAttrib[size]N[type]vARB(0, generic vertex attribute 0 |
| array element i); |
| } else { |
| VertexAttrib[size][type]vARB(0, generic vertex attribute 0 |
| array element i); |
| } |
| } else if (vertex array enabled) { |
| Vertex[size][type]vARB(vertex array element i); |
| } |
| |
| where <textureUnits> and <genericAttributes> give the number of texture |
| coordinate sets and generic vertex attributes supported by the |
| implementation, respectively. "[size]" and "[type]" correspond to the |
| size and type of the corresponding array. For generic vertex attributes, |
| it is assumed that a complete set of vertex attribute commands exists, |
| even though not all such functions are provided by the GL. |
| |
| (modify the first paragraph on p. 26) ...with one exception: The current |
| edge flag, texture coordinates, color, secondary color, color index, fog |
| coordinate, normal coordinates and generic attributes are each |
| indeterminate after execution of DrawArrays, if the corresponding array |
| is enabled. |
| |
| (modify the first paragraph on p. 27) ...with one exception: The current |
| edge flag, texture coordinates, color, secondary color, color index, fog |
| coordinate, normal coordinates and generic attributes are each |
| indeterminate after execution of DrawElements, if the corresponding |
| array is enabled. |
| |
| (modify last paragraph of section, p. 30) If the number of supported |
| texture coordinate sets (the value of MAX_TEXTURE_COORDS_ARB) is m and |
| the number of supported generic vertex attributes (the value of |
| MAX_VERTEX_ATTRIBS_ARB) is n, then the client state required to |
| implement vertex arrays consists of 7+m+n Boolean values, 7+m+n memory |
| pointers, 7+m+n integer stride values, 7+m+n symbolic constants |
| representing array types, 3+m+n integers representing values per element |
| and n boolean values indicating normalization. In the initial state, the |
| boolean values are each disabled, the memory pointers are each null, the |
| strides are each zero, the array types are each FLOAT, and the integers |
| representing values per element are each four. |
| |
| Modify Section 2.10, Coordinate Transformations (p. 31) |
| |
| (add at the beginning of the section) This section and the discussion |
| through section 2.13 describe the state values and operations necessary |
| for transforming vertex attributes according to a fixed-functionality |
| method. An alternate method for transforming vertex attributes is |
| described in section 2.15. |
| |
| Modify Section 2.10.2, Matrices (p. 33) |
| |
| (modify first paragraph, p. 37) For each texture coordinate set, a 4x4 |
| matrix is applied to the corresponding texture coordinates. This matrix |
| is applied as... |
| |
| (modify third and fourth paragraphs, p. 37) The command |
| |
| void ActiveTexture(enum texture) |
| |
| specifies the active texture unit selector, ACTIVE_TEXTURE. Each texture |
| unit contains up to two distinct sub-units: a texture coordinate |
| processing unit (consisting of a texture matrix stack and texture |
| coordinate generation state) and a texture image unit (consisting of all |
| the texture state defined in Section 3.8). In implementations with a |
| different number of supported texture coordinate sets and texture image |
| units, some texture units may consist of only one of the two sub-units. |
| |
| The active texture unit selector specifies the texture coordinate set |
| accessed by commands involving texture coordinate processing. Such |
| commands include those accessing the current matrix stack (if |
| MATRIX_MODE is TEXTURE), TexGen (section 2.10.4), Enable/Disable (if any |
| texture coordinate generation enum is selected), as well as queries of |
| the current texture coordinates and current raster texture coordinates. |
| If the texture coordinate set number corresponding to the current value |
| of ACTIVE_TEXTURE is greater than or equal to the |
| implementation-dependent constant MAX_TEXTURE_COORDS_ARB, the error |
| INVALID_OPERATION is generated by any such command. The active texture |
| unit selector also selects the texture image unit accessed by commands |
| involving texture image processing (section 3.8). Such commands include |
| all variants of TexEnv, TexParameter, and TexImage commands, |
| BindTexture, Enable/Disable for any texture target (e.g., TEXTURE_2D), |
| and queries of all such state. If the texture image unit number |
| corresponding to the current value of ACTIVE_TEXTURE is greater than or |
| equal to the implementation-dependent constant |
| MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB, the error INVALID_OPERATION is |
| generated by any such command. |
| |
| ActiveTexture generates the error INVALID_ENUM if an invalid <texture> |
| is specified. <texture> is a symbolic constant of the form TEXTUREi, |
| indicating that texture unit i is to be modified. The constants obey |
| TEXTUREi = TEXTURE0 + i (i is in the range 0 to k-1, where k is the |
| larger of the MAX_TEXTURE_COORDS_ARB and |
| MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB). For compatibility with old OpenGL |
| specifications, the implementation-dependent constant MAX_TEXTURE_UNITS |
| specifies the number of conventional texture units supported by the |
| implementation. Its value must be no larger than the minimum of |
| MAX_TEXTURE_COORDS_ARB and MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB. |
| |
| (modify third paragraph, p. 38) The state required to implement |
| transformations consists of a 4-valued integer indicating the current |
| matrix mode, one stack of at least two 4x4 matrices for each of COLOR, |
| PROJECTION, each texture coordinate set, and TEXTURE and a stack of at |
| least 32 4x4 matrices for MODELVIEW. Each matrix stack has an associated |
| stack pointer. Initially, there is only one matrix on each stack, and |
| all matrices are set to the identity. The initial matrix mode is |
| MODELVIEW. The initial value of ACTIVE_TEXTURE is TEXTURE0. |
| |
| Modify Section 2.11, Clipping (p. 42) |
| |
| (Add a new paragraph between the first and second paragraph on page 43) |
| When a vertex shader is active, the vector (Xe Ye Ze We)T is no longer |
| computed by the GL. Instead, the OpenGL Shading Language provides a |
| gl_ClipVertex built-in variable, which is used in the dot product with |
| the client-defined clip planes. The user must ensure that the clip |
| vertex and client-defined clip planes are defined in the same coordinate |
| space. Note that the value in gl_ClipVertex is undefined if it is not |
| written by the vertex shader. |
| |
| Modify Section 2.12, Current Raster Position |
| |
| (modify fourth paragraph, p.44) The coordinates are treated as if they |
| were specified in a Vertex command. If a vertex shader is active, this |
| vertex shader is executed using the x, y, z, and w coordinates as the |
| object coordinates of the vertex. Otherwise, the x, y, z, and w |
| coordinates are transformed by the current model-view and projection |
| matrices. These coordinates, along with current values, are used to |
| generate primary and secondary colors and texture coordinates just as is |
| done for a vertex. The colors and texture coordinates produced using |
| either method replace the colors and texture coordinates stored in the |
| current raster position's associated data. If a vertex shader is active |
| then the current raster distance is set to the value of the shader built |
| in varying gl_FogFragCoord. Otherwise, if the value of the fog source |
| (see section 3.10) is FOG_COORDINATE_SOURCE, then the current raster |
| distance is set to the value of the current fog coordinate. Otherwise, |
| the current raster distance is set to the distance from the origin of |
| the eye coordinate system to the vertex as transformed by only the |
| current model-view matrix. This distance may be approximated as |
| discussed in section 3.10. |
| |
| Since vertex shaders may be executed when the raster position is set, |
| any attributes not written by the shader will result in undefined state |
| in the current raster position. Vertex shaders should output all varying |
| variables that would be used when rasterizing pixel primitives using the |
| current raster position. |
| |
| Modify section 2.13.1, Lighting |
| |
| (add just before the first paragraph on page 53) Additionally, vertex |
| shaders can operate in two-sided color mode. When a vertex shader is |
| active, front and back colors can be computed by the vertex shader and |
| written to the gl_FrontColor, gl_BackColor, gl_FrontSecondaryColor and |
| gl_BackSecondaryColor outputs. If VERTEX_PROGRAM_TWO_SIDE_ARB is |
| enabled, the GL chooses between front and back colors, as described |
| later. Otherwise, the front color output is always selected. Two-sided |
| color mode is enabled and disabled by calling Enable or Disable with the |
| symbolic value VERTEX_PROGRAM_TWO_SIDE_ARB. |
| |
| The selection between back color and front color depends ... |
| |
| Modify section 2.13.2, Lighting Parameter Specification (p. 53) |
| |
| (add a new paragraph between paragraph 2 and 3 on page 54) Material |
| properties can be changed inside a Begin/End pair by calling Material. |
| However, when a vertex shader is active such property changes are not |
| guaranteed to update material parameters, defined in Table 2.8, until |
| the following End command. |
| |
| Modify section 2.13.3, ColorMaterial |
| |
| (add a paragraph after the last paragraph, page 57) Material properties |
| can be changed inside a Begin/End pair indirectly by enabling |
| ColorMaterial mode and making Color calls. However, when a vertex shader |
| is active such property changes are not guaranteed to update material |
| parameters, defined in Table 2.8, until the following End command. |
| |
| Rename and Modify Section 2.13.8, Color and Texture Coordinate Clipping |
| (p.59) |
| |
| (modify second paragraph, p. 60) Texture coordinates, varying variables, |
| fog coordinates and point sizes computed on a per vertex basis must also |
| be clipped when a primitive is clipped. The method is exactly analogous |
| to that used for color clipping. |
| |
| Add Section 2.15 Vertex Shaders |
| |
| The sequence of operations described in Sections 2.10 through 2.13 is a |
| fixed- functionality method for processing vertex data. Applications can |
| more generally describe the operations that occur on vertex values and |
| their associated data by using a "vertex shader". |
| |
| A vertex shader is an array of strings containing source code for the |
| operations that are meant to occur on each vertex that is processed. The |
| language used for vertex shaders is described in the OpenGL Shading |
| Language Specification. |
| |
| Section 2.15.1 Creating and Using a Vertex Shader |
| |
| In order to create a vertex shader, use CreateShaderObjectARB with a |
| <shaderType> of VERTEX_SHADER_ARB. The source code for the vertex shader |
| can be specified in one call using the ShaderSourceARB command. A vertex |
| shader is compiled by issuing CompileShaderARB and attached to a program |
| object by calling AttachObjectARB. When LinkProgramARB is issued, all of |
| the attached shader objects of type VERTEX_SHADER_ARB are linked |
| together to create an executable program that can be used to process |
| vertex values and their associated data. This executable program will |
| become part of current state and used to process subsequent vertex data |
| when UseProgramObjectARB is called. |
| |
| CreateShaderObjectARB will set the object specific parameter |
| OBJECT_SUBTYPE_ARB to VERTEX_SHADER_ARB. |
| |
| Section 2.15.2 Vertex Attributes |
| |
| Conventional vertex attributes are communicated to the vertex shader via |
| the Vertex, Normal, Color, etc. API commands (or their vertex array |
| equivalents). Generic attributes are communicated via the |
| VertexAttrib*ARB and VertexAttribPointerARB commands. The binding of the |
| name of an attribute variable to a generic attribute index is assigned |
| by the GL and can be queried. This generic attribute index can be used |
| in the VertexAttrib*ARB and VertexAttribPointerARB commands. |
| Alternatively, this binding can be overridden and specified explicitly, |
| if so desired. These mechanisms make it possible for a vertex shader to |
| use descriptive names for attribute variables rather than having generic |
| variables numbered from 0 to MAX_VERTEX_ATTRIBS_ARB - 1. For example, an |
| application can specify that the attribute variable "tangentVec" in a |
| vertex shader will be mapped to generic vertex attribute number 6. |
| |
| When an attribute variable declared as a float, vec2, vec3 or vec4 is |
| bound to a generic attribute index <i>, its value(s) are stored in the |
| <x>, <x,y>, <x,y,z> or <x,y,z,w> components of the generic attribute at |
| slot <i>. Recall that the VertexAttrib*ARB commands will set unused |
| components to default values (either 0 or 1, see section 2.7). |
| |
| An attribute (either conventional or generic) is considered "active" if |
| it is determined by the compiler and linker that the attribute may be |
| accessed when the executable code is executed. The program object will |
| fail to link if the sum of the active generic and active conventional |
| attributes exceeds MAX_VERTEX_ATTRIBS_ARB. Attribute variables that are |
| declared in a vertex shader but never used will not count against the |
| limit. In cases where the compiler and linker cannot make a conclusive |
| determination, the attribute will be considered active. |
| |
| To determine which of the declared vertex attribute variables an |
| executable program uses and to determine their types, use the command: |
| |
| void GetActiveAttribARB(handleARB programObj, uint index, |
| sizei maxLength, sizei *length, int *size, |
| enum *type, charARB *name) |
| |
| This command provides information about the attribute selected by |
| <index>. The <index> of 0 selects the first active attribute, and |
| <index> of OBJECT_ACTIVE_ATTRIBUTES_ARB-1 selects the last active |
| attribute. The value of OBJECT_ACTIVE_ATTRIBUTES_ARB can be queried with |
| GetObjectParameter{if}vARB (see Section 6.1.12). If <index> is greater |
| than or equal to OBJECT_ACTIVE_ATTRIBUTES_ARB, the error INVALID_VALUE |
| is generated. |
| |
| The parameter <programObj> is a handle to a program object for which the |
| command LinkProgramARB has been issued in the past. It is not necessary |
| for <programObj> to have been linked successfully. The link could have |
| failed because the number of active attributes exceeded the limit. If |
| <programObj> is not of type PROGRAM_OBJECT_ARB, the error |
| INVALID_OPERATION is generated. |
| |
| For the selected attribute, the attribute name is returned into <name>. |
| The string <name> will be null terminated. The actual number of |
| characters written by the GL into <name> is returned in <length>. This |
| count excludes the null termination. If <length> is NULL then the GL |
| ignores this parameter. The maximum number of characters the GL is |
| allowed to write into <name> is passed in by <maxLength>. The returned |
| attribute name can be the name of a generic attribute or a conventional |
| attribute (which begin with the prefix "gl_", see the OpenGL Shading |
| Language specification for a complete list). The length of the longest |
| attribute name in <programObj> is given by |
| OBJECT_ACTIVE_ATTRIBUTE_MAX_LENGTH_ARB, which can be queried with |
| GetObjectParameter{if}vARB (see Section 6.1.12). |
| |
| For the selected attribute, the type of the attribute is returned into |
| <type>. The size of the attribute is returned into <size>. The value in |
| <size> is in units of the type returned in <type>. The type returned can |
| be any of FLOAT, FLOAT_VEC2_ARB, FLOAT_VEC3_ARB, FLOAT_VEC4_ARB, |
| FLOAT_MAT2_ARB, FLOAT_MAT3_ARB, or FLOAT_MAT4_ARB. |
| |
| If an error occurred, the return parameters <length>, <size>, <type> and |
| <name> will be unmodified. |
| |
| This command will return as much information about active attributes as |
| possible. If no information is available, <length> will be set to zero |
| and <name> will be an empty string. This situation could arise if |
| GetActiveAttribARB is issued after a failed link. |
| |
| After a program object has been linked successfully, the bindings of |
| attribute variable names to indices can be queried. |
| |
| The command |
| |
| GLint GetAttribLocationARB(handle programObj, const charARB *name) |
| |
| will return the generic attribute index that the attribute variable |
| named <name> is bound to. <name> has to be a null terminated string. |
| <programObj> is a handle to a program object that has been successfully |
| linked. If <name> is not an active attribute, or if <name> is a |
| conventional attribute, -1 will be returned. If <name> is an attribute |
| matrix, and it is active, then GetAttribLocationARB returns the index of |
| the first column of that matrix. If <programObj> has not been |
| successfully linked, or if <programObj> is not of type |
| PROGRAM_OBJECT_ARB, the error INVALID_OPERATION is generated. |
| |
| The binding of an attribute variable to a generic attribute index can |
| also be specified explicitly. |
| |
| The command |
| |
| void BindAttribLocationARB(handleARB programObj, uint index, |
| const charARB *name) |
| |
| binds the attribute variable named <name> to generic vertex attribute |
| <index> for the program object <programObj>. If <name> was bound |
| previously, that binding information is lost. <name> has to be a null |
| terminated string. If <name> is declared as an attribute matrix, <index> |
| indicates the first column of that matrix. The other matrix columns are |
| then automatically bound to locations <index> + 1 for a mat2, <index> + |
| 1 and <index> + 2 for a mat3 and <index> + 1, <index> + 2 and <index> + |
| 3 for a mat4. The error INVALID_VALUE is generated if <index> is equal |
| or greater than MAX_VERTEX_ATTRIBS_ARB. The error INVALID_OPERATION is |
| generated if <name> starts with the reserved "gl_" prefix. If |
| <programObj> is not of type PROGRAM_OBJECT_ARB, the error |
| INVALID_OPERATION is generated. |
| |
| Applications cannot bind any conventional attributes (the attributes |
| starting with "gl_" defined in the OpenGL Shading Language |
| specification). Conventional attributes used in a vertex shader will be |
| bound automatically. |
| |
| In order to have attribute bindings take effect the program object needs |
| to be linked after issuing the BindAttribLocationARB command. The linker |
| will bind any active attributes not already explicitly specified through |
| BindAttribLocationARB. After a successful link the complete list of |
| bindings can be queried using the command GetAttribLocationARB. |
| |
| It is generally not known to the GL until link time if <name> is |
| declared as an attribute matrix. Therefore LinkProgramARB can fail |
| because binding of a matrix to a generic attribute index caused one or |
| more columns of the matrix to be bound to indices outside the |
| MAX_VERTEX_ATTRIBS_ARB range. LinkProgramARB can also fail because |
| BindAttribLocationsARB commands have been issued leaving not enough |
| contiguous indices for a matrix to be fitted in by the linker. |
| |
| It is allowed to issue BindAttribLocationARB before any vertex shader |
| objects are attached to a program object. Hence it is allowed to bind |
| any name (except a name starting with "gl_") to an index, including a |
| name that is never used as an attribute in any vertex shader object. |
| |
| The values of generic attributes sent to generic attribute index <i> are |
| part of current GL state, just like the conventional attributes. If a |
| new program object has been made active, then these values will be |
| tracked by the GL in such a way that the same values will be observed by |
| attributes in the new program object that are also bound to index <i>. |
| |
| It is a link error to have a vertex shader statically consume the |
| conventional attribute gl_Vertex and have the same vertex shader |
| statically consume a generic vertex attribute that is bound to index |
| zero. This would result in aliasing between a generic vertex attribute |
| and the conventional attribute gl_Vertex, which is disallowed (see the |
| description of VertexAttrib*ARB in Section 2.7). |
| |
| It is possible for an application to bind more than one attribute name |
| to the same location. This is referred to as "aliasing". This will only |
| work if only one of the aliased attributes is active in the executable |
| program, or if no path through the shader consumes more than one |
| attribute of a set of attributes aliased to the same location. OpenGL |
| implementations are not required to detect violations of this rule. The |
| compiler and linker are allowed to assume that no aliasing is done, and |
| are free to employ optimizations that work only in the absence of |
| aliasing. It is not possible to alias generic attributes with |
| conventional ones. |
| |
| When a vertex shader is active, more (or less) vertex attributes might |
| be sent to OpenGL than the vertex shader uses. When fewer attributes |
| than the current vertex shader uses are sent, the vertex shader uses the |
| values in the current state for the attributes not provided. In the case |
| of a generic vertex attribute that current value comes from the slot |
| index number the generic attribute is bound to. When more attributes are |
| provided than the vertex shader uses the vertex shader ignores the extra |
| attributes but these extra attributes continue to modify the current |
| vertex attribute state. |
| |
| Section 2.15.3 Uniform Variables |
| |
| A vertex shader may define one or more "uniform" variables. These values |
| are to remain constant over a primitive or a sequence of primitives. The |
| OpenGL Shading Language specification defines a set of built-in uniform |
| variables for vertex shaders that correspond to the state that GL |
| manages for the purpose of processing vertices. The amount of storage |
| that is available for vertex shader uniform variables is specified by |
| the implementation dependent constant MAX_VERTEX_UNIFORM_COMPONENTS_ARB. |
| This value represents the number of individual floating point values, or |
| individual integer values or individual Boolean values that can be held |
| in uniform variable storage for a vertex shader. A link error will be |
| generated if an attempt is made to utilize more than the space available |
| for vertex shader uniform variables. |
| |
| Section 2.15.4 Varying Variables |
| |
| A vertex shader may define one or more "varying" variables (see the |
| OpenGL Shading Language specification). These values are expected to be |
| interpolated across the primitive being rendered. The OpenGL Shading |
| Language specification defines a set of built-in varying variables for |
| vertex shaders that correspond to the values required for the fixed |
| functionality processing that occurs after vertex processing. The number |
| of interpolators that is available for processing varying variables is |
| specified by the implementation dependent constant |
| MAX_VARYING_FLOATS_ARB. This value represents the number of individual |
| floating point values that can be interpolated, therefore interpolating |
| a vertex will consume 4 (x, y, z, w) and interpolating a color will also |
| consume 4 (R, G, B, A). A link error will be generated if an attempt is |
| made to utilize more than MAX_VARYING_FLOATS_ARB interpolators. |
| |
| Section 2.15.5 Texture access |
| |
| Vertex shaders have the ability to do a lookup into a texture map. Zero |
| or more texture image units are available to a vertex shader to access |
| textures. The maximum number of texture image units available to a |
| vertex shader is MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB. The maximum number |
| of texture image units available to the fragment stage of OpenGL is |
| MAX_TEXTURE_IMAGE_UNITS_ARB. Both the vertex shader and fragment |
| processing combined cannot use more than |
| MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB texture image units. If both the |
| vertex shader and the fragment processing stage access the same texture |
| image unit, then that counts as using two texture image units against |
| the MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB limit. |
| |
| When a texture lookup is performed in a vertex shader, the GL computes |
| the filtered texture value tau in the manner described in sections 3.8.8 |
| and 3.8.9, and converts it to a texture source color C_s according to |
| table 3.21 (section 3.8.13). The GL returns a four-component vector |
| (R_s, G_s, B_s, A_s) to the vertex shader. |
| |
| In a vertex shader, it is not possible to perform automatic LOD |
| calculations using partial derivatives of the texture coordinates with |
| respect to window coordinates as described in section 3.8.8. Hence, |
| there is no automatic selection of an image array level. Minification or |
| magnification of a texture map is controlled by a LOD value optionally |
| passed as an argument in the texture lookup functions. If the texture |
| lookup function supplies an explicit LOD value <l>, then the pre-bias |
| LOD value lambda_base(x,y) = l (equation 3.16a). If the texture lookup |
| function does not supply an explicit LOD value, then lambda_base(x,y) = |
| 0. The scale factor rho(x,y) and its approximation function f(x,y), |
| pages 141-142, are ignored. |
| |
| Texture comparison requires the vertex shader to use the shadow versions |
| of the texture lookup functions. This in turn means that samplers of |
| type sampler1DShadow or sampler2DShadow or sampler2DRectShadow need to |
| be used to indicate the texture image unit that has a depth texture |
| bound to it. |
| |
| The results of a texture lookup function are undefined if: |
| |
| * The sampler used in a texture lookup function is of type sampler1D |
| or sampler2D or sampler2DRect, and the texture object's internal |
| format is DEPTH_COMPONENT, and the TEXTURE_COMPARE_MODE is not NONE. |
| * The sampler used in a texture lookup function is of type |
| sampler1DShadow or sampler2DShadow or sampler2DRectShadow, and the |
| texture object's internal format is DEPTH_COMPONENT, and the |
| TEXTURE_COMPARE_MODE is NONE. |
| * The sampler used in a texture lookup function is of type |
| sampler1DShadow or sampler2DShadow or sampler2DRectShadow, and the |
| texture object's internal format is not DEPTH_COMPONENT. |
| |
| If a vertex shader uses a sampler which associated texture object is not |
| complete, as defined in section 3.8.10, the texture image unit will |
| return (R, G, B, A) = (0, 0, 0, 1). |
| |
| Section 2.15.6 Position Invariance |
| |
| If a vertex shader uses the built-in function ftransform() to generate a |
| vertex position, then this generally guarantees that the transformed |
| position will be the same whether using this vertex shader or the fixed |
| functionality OpenGL pipeline. This allows for correct mixed multi-pass |
| rendering algorithms. |
| |
| Section 2.15.7 Vertex Shader Execution |
| |
| If a successfully linked program object that contains a vertex shader is |
| made current by calling UseProgramObjectARB, the executable version of |
| the vertex shader is used to process incoming vertex values rather than |
| the fixed functionality vertex processing described in Sections |
| 2.10-2.13. In particular, |
| |
| * The model-view matrix is not applied to vertex coordinates (pp. |
| 31-32) |
| * The projection matrix is not applied to vertex coordinates (pp. |
| 31-32) |
| * The texture matrices are not applied to texture coordinates (p. 37) |
| * Normals are not transformed to eye coordinates (pp. 38-39) |
| * Normals are not rescaled or normalized (pp. 39-40) |
| * Normalization of AUTO_NORMAL evaluated normals is not performed. (p. |
| 191) |
| * Texture coordinates are not generated automatically (pp. 40-42) |
| * Per vertex lighting is not performed (pp. 48-53) |
| * Color material computations are not performed (pp. 54-57) |
| * Color index lighting is not performed (pp. 57-58) |
| * All of the above applies when setting the current raster position |
| (pp. 44-45) |
| |
| The following operations are applied to vertex values that are the |
| result of executing the vertex shader: |
| |
| * Color clamping or masking (p. 56) |
| * Perspective division on clip coordinates (pp. 31-32) |
| * Viewport mapping (pp. 32-33) |
| * Depth range (p. 33) |
| * Clipping, including user clipping (pp. 42-44) |
| * Front face determination (p. 53) |
| * Flat-shading (pp. 58-59) |
| * Color, texture coordinate, fog, point-size and generic attribute |
| clipping (pp. 59-60) |
| * Final color processing (p. 60) |
| |
| Section 2.15.8 Required State |
| |
| Besides the required state outlined in the ARB_shader_objects extension |
| document, the following state is also required: |
| |
| The state required to support vertex shaders consists of: |
| |
| * A bit indicating whether or not vertex program two-sided color mode |
| is enabled, initially disabled. |
| * A bit indicating whether or not vertex program point size mode is |
| enabled, initially disabled. |
| |
| The state required per program object consists of: |
| |
| * An array of strings holding the names of active attributes. |
| * An array of integers holding the sizes of active attributes. |
| * An array of integers holding the types of active attributes. |
| * An integer holding the number of active attributes |
| * An integer holding the length of the longest attribute name. |
| * An array of integers holding the locations of active generic |
| attributes. |
| * An array of MAX_VERTEX_UNIFORM_COMPONENTS_ARB words that holds |
| uniform values. |
| |
| Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization) |
| |
| Modify Section 3.3, Points (p. 66) |
| |
| (replace the first and second paragraph) If a vertex shader is not |
| active, then the rasterization of points is controlled with |
| |
| void PointSize(float size) |
| |
| <size> specifies the requested size of a point. The default value is |
| 1.0. A value less than or equal to zero results in the error |
| INVALID_VALUE. The requested point size is multiplied with a distance |
| attenuation factor, clamped to a specified point size range, and further |
| clamped to the implementation-dependent point size range to produce the |
| derived point size: |
| |
| derived_size = ... |
| |
| (add a paragraph between the third and fourth paragraph) |
| |
| If a vertex shader is active and vertex program point size mode is |
| enabled, then the derived point size is taken from the, potentially |
| clipped, shader built in gl_PointSize and clamped to the |
| implementation-dependent point size range. If the value written to |
| gl_PointSize is less than or equal to zero, results are undefined. If a |
| vertex shader is active and vertex program point size mode is disabled, |
| then the derived point size is taken from the point size state as |
| specified by the PointSize command. In this case no distance attenuation |
| is performed. Vertex program point size mode is enabled and disabled by |
| calling Enable or Disable with the symbolic value |
| VERTEX_PROGRAM_POINT_SIZE_ARB. |
| |
| If multisampling is enabled, an implementation ... |
| |
| Modify Section 3.8.8 Texture Minification (p. 140) |
| |
| (modify subsection Scale Factor and Level of Detail. Replace its first |
| paragraph) |
| |
| The choice is governed by a scale factor rho(x,y) and the level of |
| detail parameter lambda(x,y), defined as |
| |
| lambda_base(x,y) = log2[rho(x,y)] 3.16a |
| |
| lambda'(x,y) = lambda_base(x,y) + 3.16b |
| clamp(texobj_bias + texunit_bias) |
| |
| |------- LODmax lambda' > LODmax |
| lambda(x,y) = | lambda' LODmin <= lambda' <= LODmax 3.16c |
| | LODmin lambda' < LODmin |
| |------- undefined LODmin > LODmax |
| |
| texobj_bias is the value of TEXTURE_LOD_BIAS for the bound texture |
| object (as described in section 3.8.4), and texunit_bias is the value of |
| TEXTURE_LOD_BIAS for the current texture unit (as described in section |
| 3.8.13). The sum of these values is clamped to the range [-max_bias, |
| max_bias] where max_bias is the value of the implementation defined |
| constant MAX_TEXTURE_LOD_BIAS. |
| |
| Modify Section 3.9 Color Sum (p. 160) |
| |
| (modify third paragraph) Color sum is enabled or disabled using the |
| generic Enable and Disable commands, respectively, with the symbolic |
| constant COLOR_SUM. If lighting is enabled and if a vertex shader is not |
| active, the color sum stage is always applied, ignoring the value of |
| COLOR_SUM. |
| |
| Modify Section 3.10, Fog (p. 160) |
| |
| (modify second paragraph) If a vertex shader is active, or if the fog |
| source, as defined below, is FOG_COORDINATE, then c is the interpolated |
| value of the fog coordinate for this fragment. Otherwise, if the fog |
| source is FRAGMENT_DEPTH, then c is the eye-coordinate distance from the |
| eye, (0, 0, 0, 1) in eye coordinates, to the fragment center. The |
| equation and the fog source, along with either d or e and s, is |
| specified with |
| |
| Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment |
| Operations and the Frame Buffer) |
| |
| None |
| |
| Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions) |
| |
| Modify Section 5.1, Evaluators (p. 188) |
| |
| (modify next-to-last paragraph, p. 191) For MAP_VERTEX_3, let q = p. For |
| MAP_VERTEX_4, let q=(x/w,y/w,z/w), where (x,y,z,w) = p. Then let |
| |
| dq dq |
| m = -- x --. |
| du dv |
| |
| Then the generated analytic normal, n, is given by n=m if a vertex |
| shader is active, or else by n=m/|m|. |
| |
| Modify Section 5.4, Display Lists (p. 198) |
| |
| (change second paragraph, p. 202) |
| |
| Certain commands, when called when compiling a display list, are not |
| compiled into the display list but are executed immediately. These are: |
| IsList,...Flush, Finish, GetAttribLocationARB, GetActiveAttribARB, |
| BindAttribLocationARB, VertexAttribPointerARB, |
| EnableVertexAttribArrayARB, DisableVertexAttribArrayARB as well as |
| IsEnabled and all of the Get commands defined in Section 6.1.12. |
| |
| (add just before the final paragraph of the section on p. 202) |
| |
| When a program object is in use, a display list may be executed whose |
| vertex attribute calls do not match up exactly with what is expected by |
| the vertex shader contained in that program object. How this mismatch is |
| handled is described in section 2.15.2. |
| |
| Additions to Chapter 6 of the OpenGL 1.4 Specification (State and State |
| Requests) |
| |
| Modify Section 6.1.2, Data Conversions (p. 205) |
| |
| (add to end of last paragraph, p. 206) Queries of texture state |
| variables corresponding to texture coordinate processing unit (namely, |
| TexGen state and enables, and matrices) will produce an |
| INVALID_OPERATION error if the value of ACTIVE_TEXTURE is greater than |
| or equal to MAX_TEXTURE_COORDS_ARB. All other texture state queries will |
| result in an INVALID_OPERATION error if the value of ACTIVE_TEXTURE is |
| greater than or equal to MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB. |
| |
| Modify section 6.1.12 Generic Object Queries. |
| |
| The commands |
| |
| void GetObjectParameterfvARB(handleARB obj, enum pname, |
| float *params) |
| void GetObjectParameterivARB(handleARB obj, enum pname, int *params) |
| |
| return object specific parameter values for object <obj> in <params>. |
| The parameter value to return is specified by <pname>. |
| |
| If <pname> is OBJECT_SUBTYPE_ARB, GetObjectParameter{if}vARB returns |
| VERTEX_SHADER_ARB if <obj> references a shader object. If <obj> is not |
| of type SHADER_OBJECT_ARB, the error INVALID_OPERATION is generated. |
| |
| If <pname> is OBJECT_ACTIVE_ATTRIBUTES_ARB, GetObjectParameter{if}vARB |
| returns the number of active attributes. If no active attributes exist, |
| 0 or 0.0f is returned. If <obj> is not of type PROGRAM_OBJECT_ARB the |
| error INVALID_OPERATION is generated. |
| |
| If <pname> is OBJECT_ACTIVE_ATTRIBUTE_MAX_LENGTH_ARB, |
| GetObjectParameter{if}vARB returns the length of the longest active |
| attribute name, including a null termination. If no active attributes |
| exist, 0 or 0.0f is returned. If <obj> is not of type PROGRAM_OBJECT_ARB |
| the error INVALID_OPERATION is generated. |
| |
| The commands |
| |
| void GetVertexAttribdvARB(uint index, enum pname, double *params) |
| void GetVertexAttribfvARB(uint index, enum pname, float *params) |
| void GetVertexAttribivARB(uint index, enum pname, int *params) |
| |
| obtain the vertex attribute state named by <pname> for the generic |
| vertex attribute numbered <index> and places the information in the |
| array <params>. <pname> must be one of VERTEX_ATTRIB_ARRAY_ENABLED_ARB, |
| VERTEX_ATTRIB_ARRAY_SIZE_ARB, VERTEX_ATTRIB_ARRAY_STRIDE_ARB, |
| VERTEX_ATTRIB_ARRAY_TYPE_ARB, VERTEX_ATTRIB_ARRAY_NORMALIZED_ARB, or |
| CURRENT_VERTEX_ATTRIB_ARB. Note that all the queries except |
| CURRENT_VERTEX_ATTRIB_ARB return client state. The error INVALID_VALUE |
| is generated if <index> is greater than or equal to |
| MAX_VERTEX_ATTRIBS_ARB. |
| |
| All but the last query return information about generic vertex attribute |
| arrays. The enable state of a generic vertex attribute array is set by |
| the command EnableVertexAttribArrayARB and cleared by |
| DisableVertexAttribArrayARB. The size, stride, type and normalized flag |
| are set by the command VertexAttribPointerARB. The query |
| CURRENT_VERTEX_ATTRIB_ARB returns the current value for the generic |
| attribute <index>. In this case the error INVALID_OPERATION is generated |
| if <index> is zero, as there is no current value for generic attribute |
| zero. |
| |
| Note that all the queries except CURRENT_VERTEX_ATTRIB_ARB return client |
| state. The error INVALID_VALUE is generated if <index> is greater than |
| or equal to MAX_VERTEX_ATTRIBS_ARB. |
| |
| The command |
| |
| void GetVertexAttribPointervARB(uint index, enum pname, |
| void **pointer) |
| |
| obtains the pointer named <pname> for vertex attribute numbered <index> |
| and places the information in the array <pointer>. <pname> must be |
| VERTEX_ATTRIB_ARRAY_POINTER_ARB. The INVALID_VALUE error is generated if |
| <index> is greater than or equal to MAX_VERTEX_ATTRIBS_ARB. |
| |
| Additions to Appendix A of the OpenGL 1.4 Specification (Invariance) |
| |
| Add to end of Section A.3 (p. 250): |
| |
| The same vertex shader will produce the same result when run multiple |
| times with the same input. The wording 'the same shader' means a program |
| object that is populated with the same source strings, which are |
| compiled and then linked, possibly multiple times. This program object |
| is then executed using the same GL state vector. |
| |
| Additions to the AGL/GLX/WGL Specifications |
| |
| None |
| |
| Interactions with ARB_vertex_program and ARB_fragment_program |
| |
| Mixing a high level ARB_vertex_shader shader with a low level |
| ARB_fragment_program shader is allowed. However, a high level |
| ARB_vertex_shader shader and a low level ARB_vertex_program shader |
| cannot be active at the same time. |
| |
| Interactions with ARB_vertex_program |
| |
| Enabling an ARB_vertex_shader shader by issuing the command |
| UseProgramObjectARB(), with a handle which is not zero, results in any |
| low level vertex shader to be ignored and overrides the enable |
| VERTEX_PROGRAM_ARB. Note that the value for VERTEX_PROGRAM_ARB does not |
| change by installing an ARB_vertex_shader shader. |
| |
| The following enums and entry points are re-used from |
| ARB_vertex_program: |
| |
| MAX_VERTEX_ATTRIBS_ARB 0x8869 |
| VERTEX_ATTRIB_ARRAY_ENABLED_ARB 0x8622 |
| VERTEX_ATTRIB_ARRAY_SIZE_ARB 0x8623 |
| VERTEX_ATTRIB_ARRAY_STRIDE_ARB 0x8624 |
| VERTEX_ATTRIB_ARRAY_TYPE_ARB 0x8625 |
| VERTEX_ATTRIB_ARRAY_NORMALIZED_ARB 0x886A |
| CURRENT_VERTEX_ATTRIB_ARB 0x8626 |
| VERTEX_ATTRIB_ARRAY_POINTER_ARB 0x8645 |
| VERTEX_PROGRAM_TWO_SIDE_ARB 0x8643 |
| VERTEX_PROGRAM_POINT_SIZE_ARB 0x8642 |
| |
| VertexAttrib*ARB |
| VertexAttribPointerARB |
| EnableVertexAttribArrayARB |
| DisableVertexAttribArrayARB |
| GetVertexAttrib*ARB |
| GetVertexAttribPointervARB |
| |
| The ARB_vertex_program extension is modified to turn undefined vertex |
| attribute aliasing into non-aliasing. That means that generic vertex |
| attributes and conventional attributes do not alias on top of each |
| other. |
| |
| The following edits are against version 36 of the ARB_vertex_program |
| specification. |
| |
| * Section 2.7. Delete the paragraph above Table X.1, Generic and |
| Conventional Attribute Mappings. Add the following sentence in its |
| place: "There is no aliasing among generic attributes and |
| conventional attributes." |
| * Section 2.7. Delete the paragraph below Table X.1 |
| * Section 2.7. Delete Table X.1. |
| * Change the last sentence in Section 2.7 to: "The initial values for |
| all generic vertex attributes are (0, 0, 0, 1)." |
| * Section 2.8. Edit the paragraph below the pseudo code. Change "As |
| described in section 2.7, setting a generic vertex attributes ..." |
| into "As described in section 2.7, there is no aliasing among |
| generic vertex attributes and conventional attributes". |
| * Section 2.14.3.1. Delete the first part of the paragraph above Table |
| X.2.1. The new paragraph becomes "A vertex program will fail to load |
| if it binds both a conventional vertex attribute and a generic |
| vertex attribute listed in the same row of Table X.2.1." |
| |
| Interactions with ARB_fragment_program |
| |
| The following enums are re-used from ARB_fragment_program: |
| |
| MAX_TEXTURE_IMAGE_UNITS_ARB 0x8872 |
| MAX_TEXTURE_COORDS_ARB 0x8871 |
| |
| Interactions with ARB_vertex_blend |
| |
| If ARB_vertex_blend is supported, and if a vertex shader is active, the |
| executable version of the vertex shader is used to process incoming |
| vertex values rather than the fixed functionality vertex blend |
| processing described in ARB_vertex_blend. In particular, |
| |
| * Vertex coordinates are not transformed to eye space as described by |
| the equation in Section 2.10 provided by ARB_vertex_blend. |
| * Normals are not transformed to eye space as described by the |
| equations in Section 2.10.2 provided by ARB_vertex_blend. |
| |
| Interactions with ARB_matrix_palette |
| |
| If ARB_matrix_palette is supported, and if a vertex shader is active, |
| the executable version of the vertex shader is used to process incoming |
| vertex values rather than the fixed functionality matrix processing |
| described in ARB_matrix_palette. In particular, |
| |
| * Vertex coordinates are not transformed to eye space as described by |
| the equation in Section 2.10 of the ARB_matrix_palette |
| specification. |
| * Normals are not transformed to eye space as described by the |
| equations in Section 2.10.3 of the ARB_matrix_palette specification. |
| |
| GLX Protocol |
| |
| The ARB_vertex_program extension defines GLX protocol for the following |
| rendering commands. |
| |
| VertexAttrib1fvARB, VertexAttrib1svARB, VertexAttrib1dvARB, |
| VertexAttrib2fvARB, VertexAttrib2svARB, VertexAttrib2dvARB, |
| VertexAttrib3fvARB, VertexAttrib3svARB, VertexAttrib3dvARB, |
| VertexAttrib4fvARB, VertexAttrib4svARB, VertexAttrib4dvARB, |
| VertexAttrib4ivARB, VertexAttrib4bvARB, VertexAttrib4ubvARB, |
| VertexAttrib4usvARB, VertexAttrib4uivARB, VertexAttrib4NbvARB, |
| VertexAttrib4NsvARB, VertexAttrib4NivARB, VertexAttrib4NubvARB, |
| VertexAttrib4NusvARB, VertexAttrib4NuivARB |
| |
| The following rendering commands are sent to the server as part of a |
| glXRender request: |
| |
| BindAttribLocationARB |
| |
| 2 12+n+p rendering command length |
| 2 265 rendering command opcode |
| 4 CARD32 programObj |
| 4 CARD32 index |
| n LISTofBYTE name, n = strlen(name) + 1 |
| p unused, p = pad(n) |
| |
| The following non-rendering commands are added. |
| |
| GetActiveAttribARB |
| |
| 1 CARD8 opcode (X assigned) |
| 1 179 GLX opcode |
| 2 5 request length |
| 4 GLX_CONTEXT_TAG context tag |
| 4 CARD32 programObj |
| 4 CARD32 index |
| 4 CARD32 maxLength |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m = (n+p)/4 |
| 4 unused |
| 4 CARD32 n |
| 4 INT32 size |
| 4 ENUM type |
| 8 unused |
| n LISTofBYTE name, n = length+1 |
| p unused , p = pad(n) |
| |
| Note that n may be zero, indicating that a GL error occured. |
| |
| GetAttribLocationARB |
| |
| 1 CARD8 opcode (X assigned) |
| 1 180 GLX opcode |
| 2 (12+n+p)/4 request length, n = strlen(name) + 1 |
| 4 GLX_CONTEXT_TAG context tag |
| 4 CARD32 programObj |
| n LISTofBYTE name |
| p unused, p = pad(n) |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 0 reply length |
| 4 INT32 return value |
| 20 unused |
| |
| GetVertexAttribdvARB |
| |
| 1 CARD32 opcode (X assigned) |
| 1 181 GLX opcode |
| 2 4 request length |
| 4 GLX_CONTEXT_TAG context tag |
| 4 CARD32 index |
| 4 ENUM pname |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m = ((n == 1) ? 0 : 2*n) |
| 4 unused |
| 4 CARD32 n |
| |
| if (n = 1) this follows: |
| |
| 8 FL0AT64 params |
| 8 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| 8*n LISTofFLOAT64 params |
| |
| The ARB_vertex_program extension defines GLX protocol for the following |
| non-rendering commands. |
| |
| GetVertexAttribfvARB and GetVertexAttribivARB. |
| |
| The following are entirely client-side commands and do not |
| require GLX protocol. |
| |
| GetVertexAttribPointervARB, VertexAttribPointerARB |
| EnableVertexAttribArrayARB, DisableVertexAttribArrayARB |
| |
| Errors |
| |
| The error INVALID_VALUE is generated by any command that takes one or |
| more handles as input, and one or more handles are not an object handle |
| generated by OpenGL. |
| |
| The error INVALID_VALUE is generated by any of the VertexAttrib*ARB |
| commands if <index> is equal or greater than MAX_VERTEX_ATTRIBS_ARB. |
| |
| The error INVALID_VALUE is generated by VertexAttribPointerARB if |
| <index> is equal or greater than MAX_VERTEX_ATTRIBS_ARB. |
| |
| The error INVALID_VALUE is generated by VertexAttribPointerARB if <size> |
| is not one of 1, 2, 3, or 4. |
| |
| The error INVALID_VALUE is generated by VertexAttribPointerARB if |
| <stride> is negative. |
| |
| The error INVALID_VALUE is generated by EnableVertexAttribArrayARB or |
| DisableVertexAttribArrayARB if <index> is greater than or equal to |
| MAX_VERTEX_ATTRIBS_ARB. |
| |
| The error INVALID_OPERATION is generated by any command accessing |
| texture coordinate processing state if the texture unit number |
| corresponding to the current value of ACTIVE_TEXTURE is greater than or |
| equal to the implementation-dependent constant MAX_TEXTURE_COORDS_ARB. |
| |
| The error INVALID_OPERATION is generated by any command accessing |
| texture image processing state if the texture unit number corresponding |
| to the current value of ACTIVE_TEXTURE is greater than or equal to the |
| implementation-dependent constant MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB. |
| |
| The error INVALID_OPERATION is generated by GetActiveAttribARB if |
| <programObj> is not of type PROGRAM_OBJECT_ARB. |
| |
| The error INVALID_VALUE is generated by GetActiveAttribARB if <index> is |
| greater than or equal to OBJECT_ACTIVE_ATTRIBUTES_ARB. |
| |
| The error INVALID_OPERATION is generated by GetAttribLocationARB if |
| <programObj> is not of type PROGRAM_OBJECT_ARB or if <programObj> has |
| not been linked successfully. |
| |
| The error INVALID_OPERATION is generated by BindAttribLocationARB if |
| <name> starts with the reserved "gl_" prefix. |
| |
| The error INVALID_VALUE is generated by BindAttribLocationARB if <index> |
| is equal or greater than MAX_VERTEX_ATTRIBS_ARB. |
| |
| The error INVALID_OPERATION is generated by BindAttribLocationARB if |
| <programObj> is not of type PROGRAM_OBJECT_ARB. |
| |
| The error INVALID_OPERATION is generated by GetObjectParameter{if}vARB |
| if <pname> is OBJECT_ACTIVE_ATTRIBUTES_ARB or |
| OBJECT_ACTIVE_ATTRIBUTE_MAX_LENGTH_ARB and <obj> is not of type |
| PROGRAM_OBJECT_ARB. |
| |
| The error INVALID_OPERATION is generated by GetObjectParameter{if}vARB |
| if <pname> is OBJECT_SUBTYPE_ARB and <obj> is not of type |
| SHADER_OBJECT_ARB. |
| |
| The error INVALID_OPERATION is generated by GetVertexAttrib*ARB if |
| <index> is zero and <pname> is CURRENT_VERTEX_ATTRIB_ARB. |
| |
| The error INVALID_VALUE is generated by GetVertexAttrib*ARB if <index> |
| is greater than or equal to MAX_VERTEX_ATTRIBS_ARB. |
| |
| The error INVALID_VALUE is generated by GetVertexAttribPointervARB if |
| <index> is equal or greater than MAX_VERTEX_ATTRIBS_ARB. |
| |
| New State |
| Initial |
| Get Value Type Get Command Value Description Sec. Attribute |
| --------- ---- ------------------------- ------- ----------- ---- --------- |
| VERTEX_PROGRAM_TWO_SIDE_ARB B IsEnabled False two-sided color mode 2.13.1 enable |
| CURRENT_VERTEX_ATTRIB_ARB 16+xR4 GetVertexAttributeARB (0,0,0,1) generic vertex attribute 2.7 current |
| VERTEX_PROGRAM_POINT_SIZE_ARB B IsEnabled False point size mode 3.3 enable |
| |
| Table X. New Accessible State Introduced by ARB_vertex_shader |
| |
| |
| Get Value Type Get Command Initial Value Description Section Attribute |
| ------------------------------- ------ ------------- ------------- ------------------ ------- ------------ |
| VERTEX_ATTRIB_ARRAY_ENABLED_ARB 16+xB GetVertex- False vertex attrib 2.8 vertex-array |
| AttribARB array enable |
| VERTEX_ATTRIB_ARRAY_SIZE_ARB 16+xZ GetVertex- 4 vertex attrib 2.8 vertex-array |
| AttribARB array size |
| VERTEX_ATTRIB_ARRAY_STRIDE_ARB 16+xZ+ GetVertex- 0 vertex attrib 2.8 vertex-array |
| AttributeARB array stride |
| VERTEX_ATTRIB_ARRAY_TYPE_ARB 16+xZ4 GetVertex- FLOAT vertex attrib 2.8 vertex-array |
| AttributeARB array type |
| VERTEX_ATTRIB_ARRAY_ 16+xB GetVertex- False vertex attrib 2.8 vertex-array |
| NORMALIZED_ARB AttributeARB array normalized |
| VERTEX_ATTRIB_ARRAY_POINTER_ARB 16+xP GetVertex- NULL vertex attrib 2.8 vertex-array |
| AttribPointerARB array pointer |
| |
| Table X New Accessible Client State Introduced by ARB_vertex_shader |
| |
| Initial |
| Get Value Type Get Command Value Description Sec. Attribute |
| --------- ----- ----------------------- ------------- ----------- ---- --------- |
| OBJECT_TYPE_ARB Z2 GetObjectParameterivARB SHADER_OBJECT_ARB Type of object 2.15.1 - |
| OBJECT_SUBTYPE_ARB Z2 GetObjectParameterivARB VERTEX_SHADER_ARB Sub type of object 2.15.1 - |
| |
| Table X Shader object state. |
| |
| Initial |
| Get Value Type Get Command Value Description Sec. Attribute |
| --------- ----- ----------------------- -------- ----------- ---- --------- |
| - 0+xZ+ GetActiveAttribARB - Size of active attribute 2.15.2 - |
| - 0+xZ+ GetActiveAttribARB - Type of active attribute 2.15.2 - |
| - 0+xcharARB GetActiveAttribARB "" Name of active attribute 2.15.2 - |
| - 0+xZ GetAttribLocationARB - Location of active generic 2.15.2 - |
| attribute |
| 512+xR GetUniformARB 0 Uniform value 2.15.3 - |
| OBJECT_ACTIVE_ATTRIBUTES_ARB Z+ GetObjectParameterivARB 0 Number of active attributes 2.15.2 - |
| OBJECT_ACTIVE_ATTRIBUTES_ |
| MAX_LENGTH_ARB Z+ GetObjectParameterivARB 0 Max attribute name length 6.1.12 - |
| |
| Table X Program object state. |
| |
| |
| New Implementation Dependent State |
| |
| Minimum |
| Get Value Type Get Command Value Description Sec. Attr. |
| --------- ---- ----------- ------- ----------- ---- ----- |
| MAX_VERTEX_ATTRIBS_ARB Z+ GetIntegerv 16 Number of active 2.15.2 - |
| vertex attributes |
| MAX_VERTEX_UNIFORM_COMPONENTS_ARB Z+ GetIntegerv 512 Number of words 2.15.3 - |
| for vertex shader |
| uniform variables |
| MAX_VARYING_FLOATS_ARB Z+ GetIntegerv 32 Number of floats 2.15.4 - |
| for interpolated |
| (varying) variables |
| MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB Z+ GetIntegerv 2 Number of texture image 2.15.5 - |
| units that can be accessed |
| by a vertex shader and the |
| fragment processing part of |
| OpenGL combined. |
| MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB Z+ GetIntegerv 0 Number of separate 2.15.5 - |
| texture units that can |
| be accessed by a vertex |
| shader. |
| MAX_TEXTURE_IMAGE_UNITS_ARB Z+ GetIntegerv 2 Number of separate 2.15.5 - |
| texture units that can |
| be accessed by the fragment |
| processing part of OpenGL. |
| MAX_TEXTURE_COORDS_ARB Z+ GetIntegerv 2 Number of texture 2.7 - |
| coordinate sets |
| |
| Table X New Implementation Dependent State Introduced by ARB_vertex_shader |
| |
| Sample Usage |
| |
| GLboolean init(GLcharARB *vertexShader) |
| { |
| GLcharARB *pInfoLog; |
| GLboolean compiled = GL_FALSE; |
| GLboolean linked = GL_FALSE; |
| GLint length, maxLength; |
| |
| // |
| // Create shader and program objects. |
| // |
| ProgramObject = glCreateProgramObjectARB(); |
| VertexShaderObject = glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB); |
| |
| length = strlen(vertexShader); |
| glShaderSourceARB(VertexShaderObject, 1, &vertexShader, &length); |
| |
| // |
| // OpenGL made a copy of the shader, we can free our copy |
| // |
| free(vertexShader); |
| |
| // |
| // Compile the vertex shader, and print out the compiler log file. |
| // |
| glCompileShaderARB(VertexShaderObject); |
| glGetObjectParameterivARB(VertexShaderObject, |
| GL_OBJECT_COMPILE_STATUS_ARB, &compiled); |
| |
| glGetObjectParameterivARB(VertexShaderObject, |
| GL_OBJECT_INFO_LOG_LENGTH_ARB, &maxLength); |
| pInfoLog = (GLcharARB *) malloc(maxLength * sizeof(GLcharARB)); |
| glGetInfoLogARB(VertexShaderObject, maxLength, &length, pInfoLog); |
| |
| printf("%s\n", pInfoLog); |
| free(pInfoLog); |
| |
| if (!compiled) { |
| printf("Compile failed\n"); |
| return GL_FALSE; |
| } |
| |
| // |
| // Populate the program object with the compiled shader |
| // |
| glAttachObjectARB(ProgramObject, VertexShaderObject); |
| |
| // |
| // We want the shader object to go away as soon as it is detached |
| // from the program object it is attached to. We can call delete now |
| // to achieve that. Note that calling delete on a program object |
| // will result in all shaders attached to that program object to be |
| // detached. If delete has been called for the shader object, |
| // calling delete on the program object will result in the shader |
| // object being deleted as well. |
| // |
| glDeleteObjectARB(VertexShaderObject); |
| |
| // |
| // Bind user attributes before linking the program object. |
| // |
| glBindAttribLocationARB(ProgramObject, 1, "myFirstAttribute"); |
| glBindAttribLocationARB(ProgramObject, 2, "mySecondAttribute"); |
| |
| // |
| // Link the program and print out the linker log file |
| // |
| glLinkProgramARB(ProgramObject); |
| glGetObjectParameterivARB(ProgramObject, GL_OBJECT_LINK_STATUS_ARB, |
| &linked); |
| |
| glGetObjectParameterivARB(ProgramObject, |
| GL_OBJECT_INFO_LOG_LENGTH_ARB, &maxLength); |
| pInfoLog = (GLcharARB *) malloc(maxLength * sizeof(GLcharARB)); |
| glGetInfoLogARB(ProgramObject, maxLength, &length, pInfoLog); |
| |
| printf("%s\n", pInfoLog); |
| free(pInfoLog); |
| |
| // |
| // If all went well, make the ProgramObject part of the current state |
| // |
| if (linked) { |
| glUseProgramObjectARB(ProgramObject); |
| return GL_TRUE; |
| } else { |
| printf("Link failed\n"); |
| return GL_FALSE; |
| } |
| } |
| |
| GLhandleARB ProgramObject; |
| GLhandleARB VertexShaderObject; |
| |
| void main() |
| { |
| GLcharARB *vertexShader; // Holds source for the shader |
| int location; // Uniform location |
| float uniformData[3] = {0.0, 1.0. 2.0}; |
| float vertexData1[3] = {0.0, 1.0. 2.0}; |
| float vertexData2[3] = {0.0, 1.0. 2.0}; |
| |
| // |
| // Fill in the source in vertexShader |
| // |
| . |
| . |
| |
| // |
| // Create shader and program objects, setup generic attributes, |
| // compile the shader object and link the program object and make it |
| // part of the current state. |
| // |
| init(vertexShader); |
| |
| // |
| // Get the location of someUniformName in the vertex shader, then |
| // load its data. |
| // |
| location = glGetUniformLocationARB(ProgramObject, "someUniformName") |
| glUniform3fvARB(location, 1, &uniformData[0]); |
| |
| // |
| // Render |
| // |
| glBegin(...); |
| . |
| . |
| glVertexAttrib3fvARB(1, vertexData1); |
| glVertexAttrib3fvARB(2, vertexData2); |
| . |
| . |
| glEnd(); |
| } |
| |
| Revision History |
| |
| Revision: 0.5 6/5/2002 |
| - First draft for circulation |
| Revision: 0.51 |
| - Updated API entry points in the New Procedures and Functions section |
| - Named and explained all parameters to all API calls |
| - BindAttributeLocationGL2 and GetActiveAttributesGL2 now have a |
| length argument for their strings |
| - Updated the section that describes state required to support vertex |
| specification |
| - Changed how standard attribute values are preserved across program |
| changes (always preserved) |
| - Changed language describing what happens when too few or too many |
| attributes are provided |
| - Updated the list of OpenGL stages that are and are not replaced by a |
| vertex shader |
| - Added suggestion for what new vertex array functionality to include |
| - Added content to the errors section |
| - Expanded the issues section up to and including number 4. |
| Revision: 0.52 |
| - Generic vertex attributes, except for vertex arrays, are loaded |
| using the exact same API commands as ARB_vertex_program uses. Added |
| discussion of this to the issues section. |
| - Changed the vertex array section to be TBD. |
| Revision: 0.53 |
| - Now references V1.0 of the OpenGL Shading Language Specification |
| - Fixed minor typos |
| - Accepted by the GL2 working group |
| Revision: 0.54 10/17/2002 |
| - Removed IsObjectGL2(). |
| - Expanded GetObjectParameter{if}GL2. Added OBJECT_SUBTYPE_GL2. |
| Revision: 0.55 10/18/2002 |
| - The index parameter to BindAttributeLocation is now a uint instead |
| of a ubyte. |
| - Updated Errors section. |
| - Added language disallowing mixing GL2 high level vertex shader with |
| low level ARB vertex program or fragment program. |
| - Documented interaction with ARB_vertex_blend |
| Revision: 0.56 10/18/2002 |
| - Added vertex array interface, and added an issue discussing it. |
| - Changed re-using ARB_vertex_program VertexAttrib*ARB commands issue. |
| Revision: 0.57 10/21/2002 |
| - Changed VA interface to be exactly the same as ARB_vertex_program |
| - Replaced MAX_ACTIVE_ATTRIBUTES_GL2 with MAX_VERTEX_ATTRIBS_ARB. |
| - Went back to a different set of VertexAttribute*GL2 calls (instead |
| of re-using the ARB_vertex_program ones). |
| - Updated issues 2 and 3. |
| - Added code to the sample usage section. |
| Revision: 0.58 10/23/2002 |
| - Spelled out GetObjectParameter, instead of using 'T value' in its |
| parameter list. |
| - Fixed usage of const keyword in GetAttributeLocations. |
| - Added GetVertexAttribute{ifd}vGL2 |
| - Added GetVertexAttribPointervARB |
| - Updated interactions with ARB_vertex_program section |
| - Updated errors section. |
| - Moved shader resources section to GL2_shader_objects. |
| - Updated chapter 5, Display Lists. |
| Revision: 0.6 10/29/2002 |
| - Fixed typos. |
| - Changed Issue three to unresolved. |
| - Added issue number four. |
| - Second distribution to the GL2 working group. |
| - Now written against the OpenGL 1.4 specification. |
| Revision: 0.61 11/26/2002 |
| - Minimum for MAX_VARYING_FLOATS reduced from 40 to 32. |
| - Allowed mixing of a high level GL2 vertex shader with a low level |
| ARB_fragment_program shader. |
| Revision: 0.62 12/04/2002 |
| - Resolved Issue 5 the same way as ARB_vertex_program. As a result, |
| added language to section 5.1. |
| Revision: 0.63 1/29/2003 |
| - Marked issues 2 and 4 as unresolved. |
| - Updated list of contributors. |
| - Added issue 6, 7, 8, 9. |
| - Updated the 'state required' section of section 2.7 and 2.8. |
| - Renamed 'user-defined attribute' to 'generic attribute' to match |
| ARB_vertex_program terminology. |
| - Added language to section 2.13.2 and 2.13.3 about material and |
| ColorMaterial handling when a GL2 shader is active. |
| - Added wording to section 3.10 for PointSize and Fog. |
| - Added a two sided lighting enable to section 2.13.1. |
| - Added wording to explain how raster pos works, section 2.12 |
| - Added and resolved issue 10. Added wording to section 3.9. |
| - Added issue 11. |
| - Third working group distribution. |
| Revision: 0.64 2/03/2003 |
| - Added VERTEX_PROGRAM_TWO_SIDE_ARB to the new tokens section. |
| - Resolved issue 6, 7, 8, 10, 11 and updated the spec to reflect this. |
| - Added wording to section 2.11, clipping |
| - Updated the New State section |
| - Updated the New Tokens section |
| - Changed the VertexAttribute*GL2 entry points to VertexAttrib*ARB, |
| which are the same entry points as defined in ARB_vertex_program. |
| - Made generic attribute zero provoke a vertex |
| - Resolved issue 2,3 and 4. Edited the interactions with |
| ARB_vertex_program section to reflect this. |
| - Consistently used 'conventional attributes' instead of 'standard |
| attributes'. |
| - Tried to clarify the wording in section 2.15.2 regarding attribute |
| tracking. |
| - Updated the Errors section |
| - Added issue 12, texture access |
| - Fourth working group distribution. |
| Revision: 0.65 2/10/2003 |
| - Updated section 5.4, commands excluded from a display list. |
| - Added section 2.15.6, position invariance. Renamed the old section |
| 2.15.6 to 2.15.7. |
| - Added a discussion section to issue 1, invariance |
| - Updated Appendix A, invariance |
| - Added a proposed resolution to issue 12. Related to that are the new |
| issues 13, 14 and 15. |
| - Added language to sections 2.7, 2.8, 2.10.2 and 6.1.2 to support |
| texture access. |
| - Added a new section 2.15.5 to support texture access. |
| - Added MAX_FRAGMENT_TEXTURE_UNITS_GL2, MAX_VERTEX_TEXTURE_UNITS_GL2 |
| and MAX_TEXTURE_IMAGE_UNITS_GL2. |
| - Fifth working group distribution |
| Revision: 0.66 2/11/2003 |
| - Added issue 16. Position invariance with respect to user clipping |
| and closed it. |
| - Closed issue 1. |
| - Updated 'implementation dependent state' section. |
| - Renamed MAX_VERTEX_UNIFORM_FLOATS_GL2 to |
| MAX_VERTEX_UNIFORM_WORDS_GL2. |
| - Consistently used 'texture coordinate set' instead of 'texture |
| coordinate unit'. |
| - Distributed to HP |
| Revision: 0.67 2/13/2003 |
| - Added wording about interaction with ARB_matrix_palette. Same |
| applies as the interaction with ARB_vertex_blend. |
| - Sixth working group distribution |
| Revision: 0.68 2/20/2003 |
| - Renamed MAX_FRAGMENT_TEXTURE_UNITS_GL2 to |
| MAX_TEXTURE_IMAGE_UNITS_ARB |
| - Renamed MAX_VERTEX_TEXTURE_UNITS_GL2 to |
| MAX_VERTEX_TEXTURE_IMAGE_UNITS_GL2 |
| - Renamed MAX_TEXTURE_IMAGE_UNITS_GL2 to |
| MAX_COMBINED_TEXTURE_IMAGE_UNITS_GL2 |
| - Added wording to issue 12) explaining how LOD calculation works. |
| - Updated section 2.15.5 with respect to LOD calculations. |
| - Updated section 2.15.5. Accessing the same texture image unit from a |
| vertex shader and fragment processing counts as using two image |
| units against the limit MAX_COMBINED_TEXTURE_IMAGE_UNITS_GL2. |
| - Updated the interactions with ARB_vertex and fragment_program |
| section. |
| - Added the 'interactions with ARB_fragment_program' section. |
| Revision: 0.69 2/27/2003 |
| - Updated the interactions with ARB_vertex and fragment_program |
| section, again. |
| - Updated the texture access section 2.15.5. It is more carefully |
| worded and references the relevant texturing sections in chapter 3. |
| - Closed issues 2, 3 and 4. Attribute handling. |
| - Closed issue 9 and modified section 3.3 to reflect the resolution. |
| - Updated texture coordinates to full citizens with respect to their |
| dynamic range. Section 2.1.1. ARB_fragment_program already does |
| this. |
| Revision: 0.70 3/3/2003 |
| - Treatment of PointSize wasn't complete with respect to point |
| attenuation and point fade. Section 3.3. |
| - Added issue 17 explaining what happens to point distance attenuation |
| and point fade. |
| - Texture access now takes the texture object and texture unit bias |
| into account as well. See sections 2.15.5 and Section 3.8.8. |
| - Fixed numerous small typos and tried to clarify wording here and |
| there. |
| - It is no longer a requirement to load and/or compile a vertex shader |
| before specifying its attribute bindings. |
| - Added section 2.15.8 Required State. |
| - Rewrote the overview section. |
| Revision: 0.71 3/3/2003 |
| - Upgraded colors to be full floating point citizens, section 2.1.1. |
| - Added language about undefined results if a vertex shader does not |
| clamp when fixed-function fragment processing is used or an |
| ARB_fragment_program target is active. Section 2.15.7. |
| - Added issue number 18, explaining color clamping and conversion to |
| fixed-point. |
| Revision: 0.72 3/31/2003 |
| - Updated PointSize. Its value is undefined unless written by the |
| shader. |
| - Changed issue 9. We will have a point size enable after all. |
| - Updated IP Status section to point to the contributors agreement. |
| - Renamed BindAttributeLocation to BindAttribLocation to be in line |
| with the rest of the vertex attribute naming (VertexAttrib etc). |
| - Renamed GetActiveAttributes to GetActiveAttribs for the same reason. |
| Revision: 0.73 4/9/2003 |
| - Added to the example usage section. Shows how to use |
| GetActiveAttribs. |
| - GetActiveAttribs no longer returns the length of the strings. They |
| are always null terminated, a length parameter is no longer needed. |
| - GetActiveAttribs no longer returns a Boolean. It was never set. |
| - Added life time to the pointer returned by GetActiveAttribs. |
| - GetActiveAttribs now also returns the type of each attribute. |
| - It is no longer a link error if generic attributes are not bound yet |
| using BindAttribute. |
| - Renamed "handle" to "handleGL2". |
| - Updated section 2.15.8 |
| Revision: 0.74 4/17/2003 |
| - Added issues 19, 20 and 21. |
| - Re-ordered section 2.15.2. Vertex Attributes |
| - The GL will assign an index for an attribute variable in a vertex |
| shader. This index is queriable using the new GetAttribLocationGL2 |
| command. |
| - Clarified BindAttribLocationGL2. It can override any binding |
| assigned by the GL. It can be called at any time. Binding takes |
| effect once a program object is (re)linked. |
| - Added text that clarifies how to load and bind attributes declared |
| as a matrix to section 2.7 and 2.15.2. |
| - Clarified issues 1, 7, 8, 9, 11, 18 based on Pat's feedback. I |
| didn't change their resolution, just tried to make them clearer. |
| - Numerous other small clarifications based on Pat's feedback. |
| Revision: 0.75 4/18/2003 |
| - Made BindAttribLocationGL2 display-listable. |
| - Query of active attributes is still allowed after a failed link. |
| After all the link could fail because there were too many active |
| attributes. |
| - Added a size parameter to GetActiveAttribsGL2. |
| - Clarified when the linker can generate errors based on incorrect |
| user bindings of attributes. |
| - More clarification's based on Pat's feedback, most of them in |
| section 2.15.2 Vertex Attributes. |
| - Re-did section 2.13.1, two sided lighting with a vertex shader |
| enabled. |
| - Refined the section about aliasing attributes in section 2.15.2. |
| - Changed MAX_VERTEX_UNIFORM_WORDS_GL2 to |
| MAX_VERTEX_UNIFORM_COMPONENTS_GL2 |
| Revision: 0.76 4/21/2003 |
| - Changed a few occurances of "char" to charGL2. |
| - GetAttribLocation and BindAttribLocation no longer take a length, |
| just like GetUniformLocation. |
| - Updated the example section to reflect the latest API changes. |
| - Changed the location of the Contributors License to a publicly |
| accessible place on www.3dlabs.com. |
| - Version approved by the ARB-GL2 working group. |
| Revision: 0.77 5/09/2003 |
| - Fixed issues 17 and 19 where some language was out of sync with the |
| actual resolution in the spec. |
| - Change 'zero' to NULL in the text describing GetActiveAttribsGL2. |
| - Fixed typo in one of the comments in the example section and in the |
| revision history. |
| - Removed the VertexAttribMatrix*GL2 entry points from the 'new |
| procedures and functions' section. These were never intended to be |
| part of the spec. |
| - Added Kent Lin to the list of contributors. |
| - Added state tables. Not all state defined in the spec was present in |
| the tables. |
| - Section 2.15.8, required state for program objects was incorrect. |
| - Clarified the lifetime of the pointers returned by |
| GetActiveAttribsGL2. |
| - Clarified that you need to pass in three NULL pointers to |
| GetActiveAttribsGL2, to only get the count of active attributes. |
| - Listed (already defined in the Errors section) error conditions to |
| GetActiveUniformsGL2, GetAttribLocationGL2 and |
| BindAttribLocationGL2. |
| - Updated example section to reflect the latest API names. |
| - The first error rule should have been INVALID_VALUE (consistent with |
| GL2_shader_objects). |
| - Added Jon Leech, Evan Hart, Benjamin Lipchak and Jeremy Sandmel to |
| the list of contributors. |
| - Removed the two rules from Appendix A (invariance) and updated Issue |
| 1 to reflect this. Added the same repeatability rule as the fragment |
| shader. |
| - Assigned enum values. |
| Revision: 0.78 5/15/2003 |
| - Deleted reference to AppendShader (this call no longer exist). |
| - Renamed all GL2 occurrences to ARB. |
| - Added SHADER_OBJECT_ARB to the list of new tokens. |
| - Fixed typos. |
| - Added to the contributors list. If anyone is still left out, let |
| Bill Licea Kane, Jon Leech or myself know. |
| Revision: 0.79 6/24/2003 |
| - Changed MAX_VERTEX_TEXTURE_IMAGE_UNITS minimum value to 0 (from 1). |
| Updated issue 15 to reflect this. |
| - Updates issue 18 (color clamping). As a result, updated Section |
| 2.1.1 and 2.15.7. |
| - Changed GetActiveAttrib to no longer return a pointer to GL memory. |
| This call now returns data for one active attribute, instead of all |
| active attributes. As a results, added error conditions to the |
| Errors section. |
| - BindAttribLocationARB is not display-listable. |
| - Added OBJECT_ACTIVE_ATTRIBUTE_MAX_LENGTH_ARB and |
| OBJECT_ACTIVE_ATTRIBUTES_ARB as a queriable parameter to |
| GetObjectParameter{if}vARB. As a result, changed the New State |
| section, and the Required State section. |
| - Ordered the Errors section in the order of API commands described in |
| the spec. Also split errors in one error per API command. |
| - Updated the examples section. |
| - General language cleanup. |
| - ARB approved version. |
| Revision: 0.80 3/16/2004 |
| - Section 2.15.5 changed that zero or more, and not one or more, |
| texture image units are available to a vertex shader. |
| - Section 2.15.5 Added language (copied from the fragment shader spec) |
| about samplers and depth textures and undefined behavior. Also |
| copied the language that specifies what happens when a texture |
| object is incomplete. Also copied the language that specifies what |
| stays the same with texture operations. |
| - Added ARB extension number (31) and edited the status paragraph. |
| - Removed SHADER_OBJECT_ARB, OBJECT_TYPE_ARB and OBJECT_SUBTYPE_ARB |
| tokens from the New Tokens section. They are already defined in |
| ARB_shader_objects. Also removed references to these in Chapter 6, |
| GetObjectParameter{fi}v and the Errors section. |
| - Changed MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB to 2 (from 3). |
| - Changed a typo: OBJECT_ACTIVE_ATTRIBUTES_MAX_LENGTH_ARB should be |
| OBJECT_ACTIVE_ATTRIBUTE_MAX_LENGTH_ARB (without the 'S') |
| - Specified that the return parameters for GetACtiveAttribARB are |
| unmodified when a GL error occurs. |
| - Section 2.13.8. Varying variables, not generic vertex attributes, are |
| clipped. |
| - GetAttribLocationARB() in the 'New Procedures and Functions' section |
| takes a handleARB not a handle. |
| - Explained the meaning of the parameters to GetVertexAttrib*ARB. |
| - Added that the current values of secondary color, fog coord and generic |
| attributes are undefined after a call to DrawArrays or DrawElements, if |
| the respective arrays are enabled. |
| - Added resolution 22. |
| - Added a paragraph to section 2.15.2 that makes it a link error to have |
| both gl_Vertex an a generic attribute bound to index zero be used in a |
| vertex shader. |
| Revision: 0.81 3/30/2004 |
| - Removed ARB from DEPTH_COMPONENT_ARB |
| - GetObjectParameter{if}vARB instead of GetObjectParameter{fi}vARB. |
| - Updated the version of the Shading Language document referenced to |
| 100.53 |
| - Updated description of MAX_VERTEX_UNIFORM_COMPONENTS_ARB in the |
| state tables. |
| - Moved spec language related to texture operations not affected by a |
| vertex shader to issue 23. |
| - ARB-GL2 workgroup approved version. |
| Revision 0.82, 12/12/2006 |
| - Fixed spelling of glGetObjectParameterivARB in sample code. |
| Revision 0.83 12/14/2009 |
| - Added GLX protocol. |
| |