| Name |
| |
| ARB_provoking_vertex |
| |
| Name Strings |
| |
| GL_ARB_provoking_vertex |
| |
| Contributors |
| |
| Cynthia Allison, NVIDIA |
| Gregory Roth, NVIDIA |
| Daniel Koch, TransGaming |
| Gavriel State, TransGaming |
| Jason Green, TransGaming |
| Ian Romanick, Intel |
| Marcus Steyer, NVIDIA |
| Pat Brown, NVIDIA |
| Stefan Dosinger, CodeWeavers |
| Henri Verbeet, CodeWeavers |
| |
| Contact |
| |
| Mark Kilgard, NVIDIA (mjk 'at' nvidia.com) |
| Daniel Koch, TransGaming (daniel 'at' transgaming.com) |
| |
| Notice |
| |
| Copyright (c) 2009-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 |
| |
| Status |
| |
| Complete. Approved by the ARB on July 3, 2009. |
| Implemented by NVIDIA, March 2009 |
| |
| Version |
| |
| Last Modified Date: August 2, 2009 |
| Version: 3 |
| |
| Number |
| |
| ARB Extension #64 |
| |
| Dependencies |
| |
| This extension is written against the OpenGL 2.1 Specification but |
| can apply to any prior specification. |
| |
| ARB_geometry_shader4, EXT_geometry_shader4, NV_geometry_shader4, |
| and NV_gpu_program4 interact with this extension |
| |
| EXT_transform_feedback, NV_transform_feedback, and the transform |
| feedback functionality made core by OpenGL 3.0 are clarified by |
| this extension. |
| |
| Overview |
| |
| This extension provides an alternative provoking vertex convention |
| for rendering lines, triangles, and (optionally depending on the |
| implementation) quads. |
| |
| The provoking vertex of a primitive is the vertex that determines the |
| constant primary and secondary colors when flat shading is enabled. |
| |
| In OpenGL, the provoking vertex for triangle, quad, line, and |
| (trivially) point primitives is the last vertex used to assemble |
| the primitive. The polygon primitive is an exception in OpenGL where |
| the first vertex of a polygon primitive determines the color of the |
| polygon, even if actually broken into triangles and/or quads. |
| |
| See section 2.14.7 (Flatshading) of the OpenGL 2.1 specification, |
| particularly Table 2.12 for more details. |
| |
| Alternatively the provoking vertex could be the first vertex of |
| the primitive. Other APIs with flat-shading functionality such |
| as Reality Lab and Direct3D have adopted the "first vertex of the |
| primitive" convention to determine the provoking vertex. However, |
| these APIs lack quads so do not have a defined provoking vertex |
| convention for quads. |
| |
| The motivation for this extension is to allow applications developed |
| for APIs with a "first vertex of the primitive" provoking vertex to |
| be easily converted to OpenGL. |
| |
| New Procedures and Functions |
| |
| void ProvokingVertex(enum mode); |
| |
| New Tokens |
| |
| Accepted by the <mode> parameter of ProvokingVertex: |
| |
| FIRST_VERTEX_CONVENTION 0x8E4D |
| LAST_VERTEX_CONVENTION 0x8E4E |
| |
| Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, |
| GetFloatv, and GetDoublev: |
| |
| PROVOKING_VERTEX 0x8E4F |
| QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION 0x8E4C |
| |
| Additions to Chapter 2 of the OpenGL 2.1 Specification (OpenGL Operation) |
| |
| -- Section 2.14.7 "Flatshading" (page 69) |
| |
| Replace the entire section with: |
| |
| "For fixed-function vertex processing, flatshading a primitive means |
| to assign all vertices of the primitive the same primary and |
| secondary colors (in RGBA mode) or the same color index (in color |
| index mode). If a vertex shader is active, flatshading a varying |
| output means to assign all vertices of the primitive the same value |
| for that output. |
| |
| The color and/or varying output values assigned are those of the |
| provoking vertex of the primitive. The provoking vertex is |
| controlled with the command |
| |
| void ProvokingVertex(enum provokeMode); |
| |
| provokeMode must be either FIRST_VERTEX_CONVENTION or |
| LAST_VERTEX_CONVENTION, and controls selection of the vertex whose |
| values are assigned to the flatshaded colors and varying outputs, as |
| shown in Table 2.12. |
| |
| The provoking vertex behavior of quad primitives is implementation |
| dependent, and may be determined by calling GetBooleanv with the |
| symbolic constant QUADS_FOLLOW_PROVOKING_VERTEX. A return value of |
| TRUE indicates that the provoking vertex mode is respected for quad |
| primitives, while a return value of FALSE indicates that the |
| implementation always behaves as though the provoking vertex mode |
| were LAST_VERTEX_CONVENTION. |
| |
| Flatshading of colors in fixed-function vertex processing, and of |
| the built-in varying variables gl_FrontColor, gl_BackColor, |
| gl_FrontSecondaryColor and gl_BackSecondaryColor when a vertex |
| shader is active, is controlled with the command |
| |
| void ShadeModel(enum mode); |
| |
| <mode> must be SMOOTH or FLAT. If <mode> is SMOOTH, vertex colors |
| are treated individually. If <mode> is FLAT, flatshading is enabled |
| and colors are taken from the provoking vertex of the primitive. The |
| colors selected are those derived from current values, generated by |
| lighting, or generated by vertex shading, if lighting is disabled, |
| enabled, or a vertex shader is in use, respectively. |
| |
| If a vertex or geometry shader is active, user-defined varying |
| outputs may be flatshaded by using the <flat> qualifer when |
| declaring the ouput, as described in section 4.3.6 of the OpenGL |
| Shading Language Specification (version 1.40.06). |
| |
| The state required for flatshading is one bit for the shade mode, |
| one bit for the provoking vertex mode, and one |
| implementation-dependent bit for the provoking vertex behavior of |
| quad primitives. The initial value of the shade mode is SMOOTH and |
| the initial value of the provoking vertex mode is |
| LAST_VERTEX_CONVENTION. |
| |
| First vertex Last vertex |
| Primitive type of polygon i convention convention |
| =========================== ============ ================================================== |
| point i i <- same |
| |
| independent line 2i-1 2i |
| line loop i i+1, if i<n |
| 1, if i==n |
| line strip i i+1 |
| |
| independent triangle 3i-2 3i |
| triangle strip i i+2 |
| triangle fan i+1 i+2 |
| |
| independent quad 4i-3 4i, if QUADS_FOLLOW_PROVOKING_VERTEX = true |
| 4i 4i, if QUADS_FOLLOW_PROVOKING_VERTEX = false <- same |
| quad strip 2i-1 2i+2, if QUADS_FOLLOW_PROVOKING_VERTEX = true |
| 2i+2 2i+2, if QUADS_FOLLOW_PROVOKING_VERTEX = false <- same |
| |
| single polygon (i=1) 1 1 <- same |
| |
| line adjacency 4i-2 4i-1 |
| line strip adjacency i+1 i+2 |
| triangle adjacency 6i-5 6i-1 |
| triangle strip adjacency 2i-1 2i+3 |
| |
| Table 2.12: Provoking vertex selection. The vertex colors and/or |
| varying values used for flatshading the <i>th primitive generated by |
| the drawing commands with the indicated primitive type are derived |
| from the corresponding values of the vertex whose index is shown in |
| the table. Vertices are numbered 1 through n, where n is the number |
| of vertices drawn." |
| |
| Additions to Chapter 3 of the OpenGL 2.1 Specification (Rasterization) |
| |
| None |
| |
| Additions to Chapter 4 of the OpenGL 2.1 Specification (Per-Fragment |
| Operations and the Frame Buffer) |
| |
| None |
| |
| Additions to Chapter 5 of the OpenGL 2.1 Specification (Special |
| Functions) |
| |
| None |
| |
| Additions to Chapter 6 of the OpenGL 2.1 Specification (State and |
| State Requests) |
| |
| None |
| |
| Additions to the AGL/GLX/WGL Specifications |
| |
| None |
| |
| Additions to the OpenGL Shading Language |
| |
| None |
| |
| Dependencies on ARB_geometry_shader4, EXT_geometry_shader4, |
| NV_geometry_shader4, NV_gpu_program4, and/or the geometry shader |
| functionality integrated into the core by OpenGL 3.2: |
| |
| If none of ARB_geometry_shader4, EXT_geometry_shader4, |
| NV_geometry_shader4, NV_gpu_program4, or OpenGL 3.2 (or later) are |
| supported: |
| * ignore the rows of table 2.12 for line adjacency, line strip |
| adjacency, triangle adjacency, and triangle strip adjacency. |
| * ignore any references to geometry shaders. |
| |
| Dependencies on EXT_gpu_shader4 and/or the flat shading functionality |
| integrated into the core by OpenGL 3.0: |
| |
| If neither EXT_gpu_shader4 or OpenGL 3.0 (or later) are supported, |
| ignore the references to the <flat> qualifier in the shading |
| language. |
| |
| Dependencies on EXT_transform_feedback, NV_transform_feedback, and/or |
| the transform feedback functionality integrated into the core by OpenGL |
| 3.0: |
| |
| Clarify the statement describing when transform feedback occurs |
| (in section 2.18 of the OpenGL 3.1 specification) to read: |
| |
| "The vertices are fed back after vertex color clamping, but before |
| flatshading and clipping." |
| |
| (The "flatshading and" phrase is newly clarifying.) |
| |
| Dependencies on ARB_compatibility and OpenGL 3.1 (or later): |
| |
| If using OpenGL 3.1 (or later) and ARB_compatibility is not |
| supported ignore all references to the following: |
| |
| * fixed function vertex processing, |
| * primary and secondary vertex colors and related built-in |
| varyings, |
| * color-index mode, |
| * shade mode, ShadeModel and the associated state, |
| * quad primitives, the QUADS_FOLLOW_PROVOKING_VERTEX query, and |
| the associated state, and |
| * the rows in table 2.12 for independent quad, quad strip and |
| single polygon. |
| |
| Dependencies on OpenGL 3.1: |
| |
| When OpenGL 3.1 is supported make the following changes: |
| |
| Modify the last sentence of Section 3.5.1 "Basic Line Segment |
| Rasterization" to read: |
| |
| "When the flat keyword is specified, no interpolation is performed, |
| and varying outputs are taken from the corresponding generic |
| attribute value of the provoking vertex corresponding to that |
| primitive (see section 2.14.7)." |
| |
| Modify the sentence in Section 3.6.1 "Basic Polygon Rasterization" |
| describing the <flat> keyword semantics to read: |
| |
| "When the flat keyword is specified, no interpolation is performed, |
| and varying outputs are taken from the corresponding generic |
| attribute value of the provoking vertex corresponding to that |
| primitive (see section 2.14.7)." |
| |
| Modify the paragraph in Section 3.6.5 "Polygon Multisample |
| Rasterization" describing the <noperspective> and <flat> qualifiers |
| semantices to read: |
| |
| "When using a vertex shader, the <noperspective> and <flat> |
| qualifiers affect how varying shader outputs are interpolated in the |
| same fashion as described for basic polygon rasterization in section |
| 3.6.1" |
| |
| GLX Protocol |
| |
| A new GL rendering command is added. The following command is sent |
| to the server as part of a glXRender request: |
| |
| ProvokingVertex |
| 2 8 rendering command length |
| 2 4227 rendering command opcode |
| 4 ENUM provokeMode |
| |
| Errors |
| |
| INVALID_ENUM is generated when ProvokingVertex is called with a |
| <provokeMode> that is not either FIRST_VERTEX_CONVENTION or |
| LAST_VERTEX_CONVENTION. |
| |
| New State |
| |
| (table 6.11, page 276) add the following entry: |
| |
| Get Value Type Get Command Initial Value Description Sec Attribute |
| ---------------- ---- ----------- ---------------------- ---------------- ------ --------- |
| PROVOKING_VERTEX Z2 GetIntegerv LAST_VERTEX_CONVENTION Provoking vertex 2.14.7 lighting |
| convention |
| |
| New Implementation Dependent State |
| |
| (table 6.36, page 301) add the following entry: |
| |
| Get Value Type Get Command Initial Value Description Sec Attribute |
| ----------------------------- ---- ----------- ------------- ----------------- ------ --------- |
| QUADS_FOLLOW_PROVOKING_VERTEX B GetBooleanv - True if quad 2.14.7 - |
| primitives follow |
| provoking vertex |
| convention |
| |
| NVIDIA Implementation Details |
| |
| GeForce 8 (G8x, G9x, GT1xx) and up GPUs report true for |
| QUADS_FOLLOW_PROVOKING_VERTEX. |
| |
| GeForce 6 and 7 (NV4x, G7x) GPUs report false for |
| QUADS_FOLLOW_PROVOKING_VERTEX. |
| |
| Issues |
| |
| 1. What should this extension be called? |
| |
| RESOLVED: ARB_provoking_vertex |
| |
| The phrase "provoking vertex" is not used in the core OpenGL |
| specification but it is the accepted jargon for the |
| functionality in question. This is the ARB-ratified version of |
| the EXT_provoking_vertext extension. |
| |
| 2. How should quads be handled? |
| |
| RESOLVED: Ideally, quadrilateral primitives (GL_QUADS and |
| GL_QUAD_STRIP) would follow the provoking vertex mode. |
| |
| Other existing APIs with different flatshading conventions do |
| not support quads. |
| |
| Rather than force support for both the first and last convention |
| for quads (which no other API supports), instead this extension |
| provides implementations the flexibility to advertise whether |
| or not quads respect the provoking vertex or not. |
| |
| This resolution ensures more hardware vendors can support |
| this extension. Hardware vendors which support both OpenGL and |
| Direct3D's provoking vertex conventions must have support for |
| "first vertex" for triangles and lines because Direct3D demands |
| these conventions. Direct3D does not demand a convention for |
| quads. However every vendor supporting OpenGL can support the |
| "last vertex" mode for quads. Leaving the quad behavior up |
| to the OpenGL implementation means hardware can simply always |
| switch to the OpenGL quad behavior when emitting quads. |
| |
| See issue #12 for more details about how the |
| implementation-dependent handling of quads is advertised. |
| |
| 3. How should the specification language be written for this |
| extension? |
| |
| RESOLVED: Update table 2.12 for all supported primitives. |
| |
| The current language describes how points and lines are handled |
| in prose but the behavior for triangles, quads, and polygons is |
| specified in table 2.12. |
| |
| Put all the Begin/End batch types in a single table with two |
| columns specifying the "first vertex convention" and "last vertex |
| convention" provoking vertex modes respectively. |
| |
| A unified table is less ambiguous than a combination of a table |
| and prose. |
| |
| 4. What token names for the provoking vertex conventions should |
| be used? |
| |
| RESOLVED: GL_FIRST_VERTEX_CONVENTION and |
| GL_LAST_VERTEX_CONVENTION (the initial state, consistent |
| with OpenGL's unextended operation). |
| |
| The word "convention" is used because (see issue #2), the "first |
| vertex" or "last vertex" rules are not iron-clad as they may or |
| may do not apply to quads. |
| |
| The provoking vertex behavior for polygons and triangle fans |
| also isn't strictly first or last vertex: Polygons always use |
| the first vertex (no matter the provoking vertex convention). |
| Triangle fans don't really use the first vertex (the spoke vertex) |
| when using the "first vertex" provoking vertex rule; see issue #7. |
| |
| 5. IRIS GL had a provoking vertex convention for polygons where the |
| last vertex of a polygon primitive determined the flat shaded |
| color of the polygon. Should we support this convention? |
| |
| RESOLVED: No. |
| |
| Interesting IRIS GL applications relying on this convention |
| are assuredly non-existent at this point. This convention |
| also requires waiting until all the vertices for a polygon |
| (which OpenGL does not bound) are specified before the polygon |
| can begin being rasterized. The IRIS GL convention was dubious |
| for this reason and OpenGL's designers were correct to abandon |
| IRIS GL's polygon provoking vertex convention. |
| |
| 6. How should line loops behave? |
| |
| RESOLVED: Line loops in GL_FIRST_VERTEX_CONVENTION mode |
| should behave as though it were a line strip with the first |
| vertex repeated at the end. In other words, the first vertex |
| of the line loop provokes the color for the line primitive that |
| closes the line loop. |
| |
| Direct3D does not support line loops. |
| |
| 7. How are triangle fans handled? |
| |
| RESOLVED: The first vertex of a triangle fan is the spoke vertex. |
| Triangle fans in GL_FIRST_VERTEX_CONVENTION mode should use |
| the first non-spoke vertex of the primitive as the provoking |
| vertex. In other words, the spoke vertex is never the provoking |
| vertex (in either convention). |
| |
| The rationale for this is to match DirectX 9's triangle |
| fan behavior. The rationale for the DirectX 9 behavior is |
| (presumably) that if the spoke vertex was considered the "first |
| vertex" of every primitive in a triangle fan, every flat shaded |
| primitive in a triangle fan would necessarily have the spoke |
| vertex's color, which isn't very interesting. |
| |
| (DirectX 10 does not support triangle fans.) |
| |
| 8. How does the provoking vertex convention affect primitives |
| generated by a geometry shader? |
| |
| RESOLVED: The provoking vertex convention affects primitives |
| whether they are generated by geometry shaders or conventional |
| (non-geometry shader) primitive assembly. |
| |
| Geometry shaders only generate point, line strips, and triangle |
| strips (not line loops, triangle fans, polygons, or quads). |
| (So the GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION is |
| irrelevant when a geometry program or shader is active.) |
| |
| This makes the supporting the first and last vertex conventions |
| for primitives generated by geometry shaders "simple" because in |
| the points, line strip, and triangle strip cases, the convention |
| really is to use either first or last vertex to define the |
| provoking vertex (no caveats). |
| |
| There's no special specification language to support the fact that |
| the provoking vertex convention applies to primitives generated |
| by geometry shaders because flat shading behavior is described |
| in Chapter 3's rasterization discussion which is all subsequent |
| to the geometry shader processing inserted into Chapter 2. |
| |
| DirectX 10 geometry shaders can output flat attributes according |
| to Direct3D's "first vertex provokes" convention for line and |
| triangle output primitives from a geometry shader. So matching |
| the DirectX 10 geometry shader behavior for flat shading requires |
| setting the provoking vertex to GL_FIRST_VERTEX_CONVENTION. |
| |
| This said, the OpenGL default convention of "last vertex" for the |
| provoking vertex tends to be more useful for geometry shaders. |
| By deferring the computation of the flat shaded color to the |
| last vertex of every primitive, that tends to give the geometry |
| shader compiler the maximum allowance for scheduling computation |
| and texturing operations required to compute the flat shaded |
| color as long as possible (that is, until the last vertex of |
| the primitive). |
| |
| 9. Should there be an OPTION or #pragma for geometry shader assembly |
| and GLSL respectively to request the specific provoking vertex |
| convention for the shader? |
| |
| RESOLVED: No. |
| |
| The provoking vertex is context state that doesn't belong within |
| a shader as a pragma anymore than the stencil state belongs |
| within the shader. Overriding context state based on a pragma |
| in a shader introduces unfortunate validation interactions that |
| will slow down shader binds. |
| |
| Geometry shaders written for DirectX 10 and using flat attributes |
| expect the "first vertex" provoking vertex convention but the |
| application is better off specifying the proper provoking vertex |
| convention for shaders just as is done with other context state. |
| |
| TransGaming supports this resolution to not support a pragma. |
| |
| 10. How do geometry shader input primitives interact with this |
| extension? |
| |
| RESOLVED: Table 2.12 includes the new primitives types |
| introduced by geometry shaders (GL_LINES_ADJACENCY_ARB, |
| GL_LINE_STRIP_ADJACENCY_ARB, GL_TRIANGLES_ADJACENCY_ARB, and |
| GL_TRIANGLE_STRIP_ADJACENCY_ARB). However the entries for these |
| primitive types are only relevant when these new primitive types |
| are used with NO geometry shader enabled. |
| |
| When a geometry shader is enabled, the only primitive output types |
| are points, line strips, and triangle strips. |
| |
| 11. To what attribute set should the provoking vertex belong? |
| |
| RESOLVED: Lighting (GL_LIGHTING_BIT). |
| |
| This is because the provoking vertex bit is described in the |
| same context as the shade model (GL_SHADE_MODEL) setting, and |
| the shade model state is part of the lighting attribute set. |
| |
| 12. How should the allowance for handling quadrilateral primitives |
| be advertised? |
| |
| RESOLVED: Because this extension is intended to facilitate |
| supporting Direct3D content that depends on the Direct3D's |
| provoking vertex convention yet Direct3D does not support quad |
| primitives (as OpenGL provides with GL_QUAD_STRIP and GL_QUADS), |
| the particular provoking vertex behavior of quads is not crucial |
| to this extension's intended application. |
| |
| In the interest of making this extension's functionality for |
| triangle and line primitives broadly available (the primitives |
| Direct3D does support with a first vertex provoking vertex |
| convention), this extension does not mandate a single uniform |
| behavior for quad primitives. Mandating a particular behavior |
| for quad primitives would, for some implementations, encumber the |
| performance of this extension in the non-quad case or make this |
| implementation of this extension needlessly complex to implement. |
| |
| Instead the GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION |
| implementation-dependent boolean indicates whether or not quads |
| (generated by GL_QUADS or GL_QUAD_STRIP) should abide by the |
| provoking vertex convention or not. |
| |
| Whether or not the GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION |
| state is true or false, the provoking vertex behavior of quads |
| is well-defined in either case. |
| |
| The recommended, though implementation-dependent, value for |
| GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION is true because |
| this means quads, will like lines and triangles, follow the |
| GL_PROVOKING_VERTEX state as indicated. |
| |
| 13. How does the provoking vertex state interact with primitive |
| restart? |
| |
| RESOLVED: Orthogonally so no specific specification language |
| describing the interaction is required. |
| |
| Specifically a primitive restart acts as a glEnd/glBegin |
| sequence so it restarts the primitive numbering to 1 for the |
| vertex immediately following the restart index. |
| |
| 14. Should the provoking vertex behavior apply to both the primary |
| and secondary color? |
| |
| RESOLVED: Yes, the provoking vertex decides both the primary and |
| secondary color of a flat-shaded primitive. That's consistent |
| with Direct3D's provoking vertex convention as well as OpenGL's |
| current behavior. |
| |
| 15. Should the provoking vertex behavior be specified with a |
| glEnable/glDisable token instead of glProvokingVertex? |
| |
| RESOLVED: The provoking vertex API is closely related |
| to glShadeModel which uses an enumerated mode rather than |
| glEnable/glDisable to specify flat or smooth shading so the API |
| mimics the glShadeModel approach. |
| |
| This results in a fairly readable API usage that is more easily |
| groaked by unfamiliar programmers: |
| |
| glProvokingVertex(GL_FIRST_VERTEX_CONVENTION); |
| |
| instead of: |
| |
| glEnable(GL_FIRST_VERTEX_CONVENTION); |
| |
| It is also not clear that the provoking vertex convention is |
| really a single enable. The convention behaves differently |
| depending on the primitive type. For example, GL_POLYGON always |
| uses the first vertex as the provoking vertex regardless of the |
| provoking vertex state. |
| |
| 16. Does the OpenGL Shading Language (GLSL) 1.30 "flat" varying |
| qualifier respect the provoking vertex state? |
| |
| RESOLVED: Yes. |
| |
| The GLSL 1.30 specification says "This variable [qualified as |
| flat] will come from a single provoking vertex, as described by |
| the OpenGL Graphics System Specification." This extension amends |
| how the provoking vertex is described so no GLSL specification |
| update is required. This does imply that user-declared varyings |
| in a GLSL shader declared with "flat" will have the provoking |
| vertex convention applied to determine their value. |
| |
| 17. How does the provoking vertex apply to Direct3D 10? |
| |
| RESOLVED: Direct3D 10 has deprecated the D3DSHADEMODE state for |
| controlling flat or smooth (Gouraud) shading. However there is |
| still the concept of a provoking vertex (called the "leading |
| vertex" by Direct3D 10) which still corresponds to this |
| extension's "first vertex" convention. |
| |
| Use of the leading (provoking) vertex for constant (flat) |
| interpolation is indicated by Direct3D 10's "nointerpolation" |
| variable storage class (sometimes called an interpolation |
| modifier). |
| |
| 18. Does the NV_gpu_program4 "FLAT" attribute modifier respect the |
| provoking vertex state? |
| |
| RESOLVED: Yes. NVIDIA's NV_gpu_program4 extension, describing |
| an OpenGL assembly for Shader Model 4.0, allows a FLAT modifier |
| to be specified for fragment program inputs. The NV_gpu_program4 |
| specification says "If an attribute is flat-shaded, it will be |
| taken from the output attribute of the provoking vertex of the |
| primitive using the same data type." This extension amends |
| how the provoking vertex is described so no NV_gpu_program4 |
| specification update is required. |
| |
| 19. How does this extension interact with transform feedback? |
| |
| RESOLVED: Attribute components written out by transform feedback |
| are NOT affected by the flatshading or provoking vertex state. |
| |
| While this specification is written against OpenGL 2.1, transform |
| feedback was made core functionality with OpenGL 3.0 and then |
| the order of the transform feedback was moved in the OpenGL |
| 3.1 specification. Therefore the subsequent discussion uses |
| the more recent 3.1 sectioning. |
| |
| Specifically the OpenGL 3.1 specification (section 2.18: Transform |
| Feedback) says "The vertices are fed back after vertex color |
| clamping, but before clipping." |
| |
| This statement is unclear because flatshading (section 2.13.7: |
| Flatshading) happens inbetween vertex color clamping (section |
| 2.13.6: Clamping or Masking) and primitive clipping (section 2.20: |
| Primitive Clipping). |
| |
| Base on this issue the sentence is clarified to read: "The |
| vertices are fed back after vertex color clamping, but before |
| [flatshading and] clipping." |
| |
| For reference, the original EXT_transform_feedback extension has |
| this same language ("The vertices are fed back after vertex color |
| clamping, but before clipping.") but follows that sentence with: |
| "If a geometry shader is active, the vertices recorded are those |
| emitted from the geometry shader." Technically geometry shading |
| takes place prior to even vertex color clamping. |
| |
| Clearly flat shading needs to happen prior to clipping so that |
| clipped vertices can share the flat shaded attributes of the |
| primitive prior to any potential clipping. |
| |
| This resolution is consistent with DirectX 10's behavior. |
| Technically, DirectX 10 says that vertices output through |
| transform feedback (which DirectX 10 calls "stream output") |
| only have to be defined for constant attributes of the primitive's |
| leading vertex (constant attributes are those that OpenGL would |
| call flatshaded). Other constant attributes for non-leading |
| vertices may be undefined. Leaving such constant attributes |
| undefined is undesirable, particularly given how OpenGL operates. |
| It is well-defined and more useful to simply output the value |
| of the vertex's attribute prior to any flatshading. This is |
| particularly desirable for OpenGL because with this extension |
| (and even prior to supporting this extension), the provoking |
| vertex is not always the leading vertex. |
| |
| To clarify further, while this resolution is consistent with |
| DirectX 10, an OpenGL implementation that supports transform |
| feedback has no undefined behavior specified. The simplest way |
| to describe what happens is that attribute components written |
| out by transform feedback are the attribute component values |
| of vertices AFTER (optional) geometry shading and vertex color |
| clamping but PRIOR to flatshading and primitive clipping. |
| |
| 20. Why don't the new tokens and entry points in this extension have |
| "ARB" suffixes like other ARB extensions? |
| |
| RESOLVED: Unlike most ARB extensions, this is a strict subset of |
| functionality already approved in OpenGL 3.2. This extension |
| exists only to support that functionality on older hardware that |
| cannot implement a full OpenGL 3.x driver. Since there are no |
| possible behavior changes between the ARB extension and core |
| features, source code compatibility is improved by not using |
| suffixes on the extension. |
| |
| Revision History |
| |
| Rev. Date Author Changes |
| ---- -------- --------- --------------------------------------------- |
| 1 5/19/09 dgkoch copy & rename from EXT_provoking_vertex v12 |
| 2 6/26/09 dgkoch resync with GL 3.2. reorder edits so they |
| fit better with ARB_compatibility. update |
| dependencies with GL 3.1, 3.2 and |
| ARB_compatibility. |
| 3 8/02/09 Jon Leech Reformat to 80 columns and assign ARB |
| extension number. |