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.