blob: 6e6149fa7ace556f3b5ac9c324ec7360f84defc8 [file] [log] [blame]
Name
NV_fragment_shader_barycentric
Name Strings
GL_NV_fragment_shader_barycentric
Contact
Pat Brown, NVIDIA (pbrown 'at' nvidia.com)
Contributors
Ashwin Lele, NVIDIA
Jeff Bolz, NVIDIA
Michael Chock, NVIDIA
Status
Shipping
Version
Last Modified: April 8, 2018
Revision: 2
Number
OpenGL Extension #526
OpenGL ES Extension #316
Dependencies
This extension is written against the OpenGL 4.6 Specification
(Compatibility Profile), dated July 30, 2017.
OpenGL 4.5 or OpenGL ES 3.2 is required.
This extension requires support for the OpenGL Shading Language (GLSL)
extension "NV_fragment_shader_barycentric", which can be found at the
Khronos Group Github site here:
https://github.com/KhronosGroup/GLSL
Overview
This extension advertises OpenGL support for the OpenGL Shading Language
(GLSL) extension "NV_fragment_shader_barycentric", which provides fragment
shader built-in variables holding barycentric weight vectors that identify
the location of the fragment within its primitive. Additionally, the GLSL
extension allows fragment the ability to read raw attribute values for
each of the vertices of the primitive that produced the fragment.
New Procedures and Functions
None
New Tokens
None
Modifications to the OpenGL 4.6 Specification (Compatibility Profile)
Modify Section 15.2.2, Shader Inputs (p. 586)
(insert new paragraphs after the first paragraph, p. 589)
Fragment shader input variables can be declared as per-vertex inputs using
the GLSL interpolation qualifier "pervertexNV". Such inputs are not
produced by attribute interpolation, but are instead taken directly from
corresponding output variables written by the previous shader stage, prior
to primitive clipping and rasterization. When reading per-vertex inputs,
a fragment shader specifies a vertex number (0, 1, or 2) that identifies a
specific vertex in the point, line, or triangle primitive that produced
the vertex.
When no tessellation or geometry shader is active, the vertices passed to
each draw call are arranged into point, line, or triangle primitives as
described in Section 10.1. If the <n> vertices passed to a draw call are
numbered 0 through <n>-1, and the point, line, and triangle primitives
produced by the draw call are numbered with consecutive integers beginning
with zero, Table X.1 and Table X.2 indicate the original vertex numbers
used as vertex 0, vertex 1, and vertex 2 when sourcing per-vertex
attributes for fragments produced by the primitive numbered <i>. Table
X.1 applies when the provoking vertex convention is
FIRST_VERTEX_CONVENTION, while Table X.2 applies when the provoking vertex
convention is LAST_VERTEX_CONVENTION.
Primitive Type Vertex 0 Vertex 1 Vertex 2
------------------------ -------- -------- --------
POINTS i - -
LINES 2i 2i+1 -
LINE_STRIP i i+1 -
LINE_LOOP i i+1 -
LINE_LOOP (last segment) n-1 0 -
TRIANGLES 3i 3i+1 3i+2
TRIANGLE_STRIP (even) i i+1 i+2
TRIANGLE_STRIP (odd) i i+2 i+1
TRIANGLE_FAN i+1 i+2 0
POLYGON 0 i i+1
LINES_ADJACENCY 4i+1 4i+2 -
LINES_STRIP_ADJACENCY i+1 i+2 -
TRIANGLES_ADJACENCY 6i 6i+2 6i+4
TRIANGLE_STRIP_ADJACENCY (even) 2i 2i+2 2i+4
TRIANGLE_STRIP_ADJACENCY (odd) 2i 2i+4 2i+2
Table X.1, Vertex Order for per-vertex attributes, using the provoking
vertex convention FIRST_VERTEX_CONVENTION.
Primitive Type Vertex 0 Vertex 1 Vertex 2
------------------------ -------- -------- --------
POINTS i - -
LINES 2i 2i+1 -
LINE_STRIP i i+1 -
LINE_LOOP i i+1 -
LINE_LOOP (last segment) n-1 0 -
TRIANGLES 3i 3i+1 3i+2
TRIANGLE_STRIP (even) i i+1 i+2
TRIANGLE_STRIP (odd) i+1 i i+2
TRIANGLE_FAN 0 i+1 i+2
POLYGON 0 i i+1
LINES_ADJACENCY 4i+1 4i+2
LINES_STRIP_ADJACENCY i+1 i+2
TRIANGLES_ADJACENCY 6i 6i+2 6i+4
TRIANGLE_STRIP_ADJACENCY (even) 2i 2i+2 2i+4
TRIANGLE_STRIP_ADJACENCY (odd) 2i+2 2i 2i+4
Table X.2, Vertex Order for per-vertex attributes, using the provoking
vertex convention LAST_VERTEX_CONVENTION.
When using geometry shaders, vertices used for per-vertex fragment shader
inputs are determined using Table X.1 or X.2 by treating the primitive(s)
produced by the geometry shader as though they were passed to a DrawArrays
calls. When using a tessellation evaluation shader, or when using QUADS
or QUAD_STRIP primitives, the vertices used for reading per-vertex
fragment shader inputs are assigned in an implementation-dependent order.
The built-in variables gl_BaryCoordNV and gl_BaryCoordNoPerspNV are
three-component floating-point vectors holding barycentric coordinates for
the fragment. These built-ins are computed by clipping (Section 13.6.1)
and interpolating (Sections 14.5.1 and 14.6.1) a three-component vector
attribute. The vertices that are numbered 0, 1, and 2 for the purposes of
reading per-vertex fragment shader inputs are assigned values of (1,0,0),
(0,1,0), and (0,0,1), respectively. For gl_BaryCoordNV, these values are
clipped and interpolated using perspective correction. For
gl_BaryCoordNoPerspNV, these values are clipped and interpolated without
perspective correction, like other fragment shader inputs qualified with
"noperspective".
Additions to the AGL/GLX/WGL Specifications
None
Interactions with OpenGL ES
Vertex order always corresponds to provoking vertex convention
LAST_VERTEX_CONVENTION.
Ignore references to unsupported primitive types QUADS, QUAD_STRIP, and
POLYGON.
Errors
None
New State
None
New Implementation Dependent State
None
Issues
(1) Can applications use the original order of vertices in a draw call to
determine the order of the three vertices used when reading per-vertex
fragment shader inputs?
RESOLVED: Yes, in most cases.
This extension allows fragment shaders to read inputs qualified with
"pervertexNV" using a vertex number 0, 1, or 2. For most primitive
types, the OpenGL Specification already specifies how the original
vertices passed to a draw call are assigned to individual point, line,
or triangle primitives. The extension extends that language to define a
specific vertex order that will be used for sourcing per-vertex
attributes. In some cases, this vertex order depends on the provoking
vertex convention.
When using a tessellation evaluation shader, QUADS primitives, or
QUAD_STRIP primitives, the OpenGL Specification already indicates that
patches or quadrilaterals can be decomposed into finer primitives in an
implementation-dependent order. In these cases, we do not guarantee a
specific vertex order. However, we still guarantee that the vertices
numbered 0, 1, 2 have corresponding barycentric weights (gl_BaryCoordNV)
of (1,0,0), (0,1,0), and (0,0,1), respectively. With this guarantee,
interpolating attributes manually in a fragment shader with code like:
float value = (gl_BaryCoordNV.x * v[0].attrib +
gl_BaryCoordNV.y * v[1].attrib +
gl_BaryCoordNV.z * v[2].attrib);
should produce results approximately equal to those that would be
obtained via conventional attribute interpolation.
(2) How are clipped primitives handled when using "pervertexNV"
fragment shader inputs?
RESOLVED: In the OpenGL pipeline, clipped primitives are normally
handled by having the clipper remove one of the original vertices,
introduce one or more new vertices, and process the result as an
unclipped primitive. In this model, the provoking vertex still needs to
be maintained because inputs qualified with "flat" use the values from
that vertex even if the provoking vertex is clipped.
In this extension, we guarantee that the three sets of per-vertex values
available as fragment shader inputs are those of the original primitive
vertices prior to clipping. To ensure consistent attribute handling,
the barycentric weights are computed relative to the original primitive,
not the clipped one. For example, if the left half of triangle ABC
below is clipped away, the clipper introduces a new vertex D and
rasterizes triangle DBC instead.
+ B (0,1,0)
/|\
/ | \
/ | \
/ | \
/ | \
/ | \
(1,0,0) A +------+------+ C (0,0,1)
D
When we process the clipped triangle, the three vertices available for
"pervertexNV" inputs are actually A, B, and C (in undefined order).
If vertices "v[0]", "v[1]", and "v[2]" are assigned to A, B, and C,
respectively, fragments at A, B, and C will have barycentric coordinates
of (1,0,0), (0,1,0), and (0,0,1), respectively. A fragment at the
vertex D introduced by the clipper will have a weight like (0.5, 0.0,
0.5) -- exactly the same value it would have if ABC were unclipped.
(3) Should we have any program interface query API support where
application code can inspect the active fragment shader inputs and
determine which ones were declared with "pervertexNV"?
RESOLVED: No. We don't have this for other interpolation qualifiers
like "flat" or "noperspective".
Also, please refer to issues in the GLSL extension specification.
Revision History
Revision 2 (mchock)
- Add support for OpenGL ES.
Revision 1 (pbrown)
- Internal revisions.