1Name 2 3 NV_fragment_shader_barycentric 4 5Name Strings 6 7 GL_NV_fragment_shader_barycentric 8 9Contact 10 11 Pat Brown, NVIDIA (pbrown 'at' nvidia.com) 12 13Contributors 14 15 Ashwin Lele, NVIDIA 16 Jeff Bolz, NVIDIA 17 Michael Chock, NVIDIA 18 19Status 20 21 Shipping 22 23Version 24 25 Last Modified: April 8, 2018 26 Revision: 2 27 28Number 29 30 OpenGL Extension #526 31 OpenGL ES Extension #316 32 33Dependencies 34 35 This extension is written against the OpenGL 4.6 Specification 36 (Compatibility Profile), dated July 30, 2017. 37 38 OpenGL 4.5 or OpenGL ES 3.2 is required. 39 40 This extension requires support for the OpenGL Shading Language (GLSL) 41 extension "NV_fragment_shader_barycentric", which can be found at the 42 Khronos Group Github site here: 43 44 https://github.com/KhronosGroup/GLSL 45 46Overview 47 48 This extension advertises OpenGL support for the OpenGL Shading Language 49 (GLSL) extension "NV_fragment_shader_barycentric", which provides fragment 50 shader built-in variables holding barycentric weight vectors that identify 51 the location of the fragment within its primitive. Additionally, the GLSL 52 extension allows fragment the ability to read raw attribute values for 53 each of the vertices of the primitive that produced the fragment. 54 55New Procedures and Functions 56 57 None 58 59New Tokens 60 61 None 62 63Modifications to the OpenGL 4.6 Specification (Compatibility Profile) 64 65 Modify Section 15.2.2, Shader Inputs (p. 586) 66 67 (insert new paragraphs after the first paragraph, p. 589) 68 69 Fragment shader input variables can be declared as per-vertex inputs using 70 the GLSL interpolation qualifier "pervertexNV". Such inputs are not 71 produced by attribute interpolation, but are instead taken directly from 72 corresponding output variables written by the previous shader stage, prior 73 to primitive clipping and rasterization. When reading per-vertex inputs, 74 a fragment shader specifies a vertex number (0, 1, or 2) that identifies a 75 specific vertex in the point, line, or triangle primitive that produced 76 the vertex. 77 78 When no tessellation or geometry shader is active, the vertices passed to 79 each draw call are arranged into point, line, or triangle primitives as 80 described in Section 10.1. If the <n> vertices passed to a draw call are 81 numbered 0 through <n>-1, and the point, line, and triangle primitives 82 produced by the draw call are numbered with consecutive integers beginning 83 with zero, Table X.1 and Table X.2 indicate the original vertex numbers 84 used as vertex 0, vertex 1, and vertex 2 when sourcing per-vertex 85 attributes for fragments produced by the primitive numbered <i>. Table 86 X.1 applies when the provoking vertex convention is 87 FIRST_VERTEX_CONVENTION, while Table X.2 applies when the provoking vertex 88 convention is LAST_VERTEX_CONVENTION. 89 90 Primitive Type Vertex 0 Vertex 1 Vertex 2 91 ------------------------ -------- -------- -------- 92 POINTS i - - 93 LINES 2i 2i+1 - 94 LINE_STRIP i i+1 - 95 LINE_LOOP i i+1 - 96 LINE_LOOP (last segment) n-1 0 - 97 TRIANGLES 3i 3i+1 3i+2 98 TRIANGLE_STRIP (even) i i+1 i+2 99 TRIANGLE_STRIP (odd) i i+2 i+1 100 TRIANGLE_FAN i+1 i+2 0 101 POLYGON 0 i i+1 102 LINES_ADJACENCY 4i+1 4i+2 - 103 LINES_STRIP_ADJACENCY i+1 i+2 - 104 TRIANGLES_ADJACENCY 6i 6i+2 6i+4 105 TRIANGLE_STRIP_ADJACENCY (even) 2i 2i+2 2i+4 106 TRIANGLE_STRIP_ADJACENCY (odd) 2i 2i+4 2i+2 107 108 Table X.1, Vertex Order for per-vertex attributes, using the provoking 109 vertex convention FIRST_VERTEX_CONVENTION. 110 111 Primitive Type Vertex 0 Vertex 1 Vertex 2 112 ------------------------ -------- -------- -------- 113 POINTS i - - 114 LINES 2i 2i+1 - 115 LINE_STRIP i i+1 - 116 LINE_LOOP i i+1 - 117 LINE_LOOP (last segment) n-1 0 - 118 TRIANGLES 3i 3i+1 3i+2 119 TRIANGLE_STRIP (even) i i+1 i+2 120 TRIANGLE_STRIP (odd) i+1 i i+2 121 TRIANGLE_FAN 0 i+1 i+2 122 POLYGON 0 i i+1 123 LINES_ADJACENCY 4i+1 4i+2 124 LINES_STRIP_ADJACENCY i+1 i+2 125 TRIANGLES_ADJACENCY 6i 6i+2 6i+4 126 TRIANGLE_STRIP_ADJACENCY (even) 2i 2i+2 2i+4 127 TRIANGLE_STRIP_ADJACENCY (odd) 2i+2 2i 2i+4 128 129 Table X.2, Vertex Order for per-vertex attributes, using the provoking 130 vertex convention LAST_VERTEX_CONVENTION. 131 132 When using geometry shaders, vertices used for per-vertex fragment shader 133 inputs are determined using Table X.1 or X.2 by treating the primitive(s) 134 produced by the geometry shader as though they were passed to a DrawArrays 135 calls. When using a tessellation evaluation shader, or when using QUADS 136 or QUAD_STRIP primitives, the vertices used for reading per-vertex 137 fragment shader inputs are assigned in an implementation-dependent order. 138 139 The built-in variables gl_BaryCoordNV and gl_BaryCoordNoPerspNV are 140 three-component floating-point vectors holding barycentric coordinates for 141 the fragment. These built-ins are computed by clipping (Section 13.6.1) 142 and interpolating (Sections 14.5.1 and 14.6.1) a three-component vector 143 attribute. The vertices that are numbered 0, 1, and 2 for the purposes of 144 reading per-vertex fragment shader inputs are assigned values of (1,0,0), 145 (0,1,0), and (0,0,1), respectively. For gl_BaryCoordNV, these values are 146 clipped and interpolated using perspective correction. For 147 gl_BaryCoordNoPerspNV, these values are clipped and interpolated without 148 perspective correction, like other fragment shader inputs qualified with 149 "noperspective". 150 151 152Additions to the AGL/GLX/WGL Specifications 153 154 None 155 156Interactions with OpenGL ES 157 158 Vertex order always corresponds to provoking vertex convention 159 LAST_VERTEX_CONVENTION. 160 161 Ignore references to unsupported primitive types QUADS, QUAD_STRIP, and 162 POLYGON. 163 164Errors 165 166 None 167 168New State 169 170 None 171 172New Implementation Dependent State 173 174 None 175 176Issues 177 178 (1) Can applications use the original order of vertices in a draw call to 179 determine the order of the three vertices used when reading per-vertex 180 fragment shader inputs? 181 182 RESOLVED: Yes, in most cases. 183 184 This extension allows fragment shaders to read inputs qualified with 185 "pervertexNV" using a vertex number 0, 1, or 2. For most primitive 186 types, the OpenGL Specification already specifies how the original 187 vertices passed to a draw call are assigned to individual point, line, 188 or triangle primitives. The extension extends that language to define a 189 specific vertex order that will be used for sourcing per-vertex 190 attributes. In some cases, this vertex order depends on the provoking 191 vertex convention. 192 193 When using a tessellation evaluation shader, QUADS primitives, or 194 QUAD_STRIP primitives, the OpenGL Specification already indicates that 195 patches or quadrilaterals can be decomposed into finer primitives in an 196 implementation-dependent order. In these cases, we do not guarantee a 197 specific vertex order. However, we still guarantee that the vertices 198 numbered 0, 1, 2 have corresponding barycentric weights (gl_BaryCoordNV) 199 of (1,0,0), (0,1,0), and (0,0,1), respectively. With this guarantee, 200 interpolating attributes manually in a fragment shader with code like: 201 202 float value = (gl_BaryCoordNV.x * v[0].attrib + 203 gl_BaryCoordNV.y * v[1].attrib + 204 gl_BaryCoordNV.z * v[2].attrib); 205 206 should produce results approximately equal to those that would be 207 obtained via conventional attribute interpolation. 208 209 (2) How are clipped primitives handled when using "pervertexNV" 210 fragment shader inputs? 211 212 RESOLVED: In the OpenGL pipeline, clipped primitives are normally 213 handled by having the clipper remove one of the original vertices, 214 introduce one or more new vertices, and process the result as an 215 unclipped primitive. In this model, the provoking vertex still needs to 216 be maintained because inputs qualified with "flat" use the values from 217 that vertex even if the provoking vertex is clipped. 218 219 In this extension, we guarantee that the three sets of per-vertex values 220 available as fragment shader inputs are those of the original primitive 221 vertices prior to clipping. To ensure consistent attribute handling, 222 the barycentric weights are computed relative to the original primitive, 223 not the clipped one. For example, if the left half of triangle ABC 224 below is clipped away, the clipper introduces a new vertex D and 225 rasterizes triangle DBC instead. 226 227 + B (0,1,0) 228 /|\ 229 / | \ 230 / | \ 231 / | \ 232 / | \ 233 / | \ 234 (1,0,0) A +------+------+ C (0,0,1) 235 D 236 237 When we process the clipped triangle, the three vertices available for 238 "pervertexNV" inputs are actually A, B, and C (in undefined order). 239 If vertices "v[0]", "v[1]", and "v[2]" are assigned to A, B, and C, 240 respectively, fragments at A, B, and C will have barycentric coordinates 241 of (1,0,0), (0,1,0), and (0,0,1), respectively. A fragment at the 242 vertex D introduced by the clipper will have a weight like (0.5, 0.0, 243 0.5) -- exactly the same value it would have if ABC were unclipped. 244 245 (3) Should we have any program interface query API support where 246 application code can inspect the active fragment shader inputs and 247 determine which ones were declared with "pervertexNV"? 248 249 RESOLVED: No. We don't have this for other interpolation qualifiers 250 like "flat" or "noperspective". 251 252 Also, please refer to issues in the GLSL extension specification. 253 254Revision History 255 256 Revision 2 (mchock) 257 - Add support for OpenGL ES. 258 259 Revision 1 (pbrown) 260 - Internal revisions. 261