1Name 2 3 ARB_provoking_vertex 4 5Name Strings 6 7 GL_ARB_provoking_vertex 8 9Contributors 10 11 Cynthia Allison, NVIDIA 12 Gregory Roth, NVIDIA 13 Daniel Koch, TransGaming 14 Gavriel State, TransGaming 15 Jason Green, TransGaming 16 Ian Romanick, Intel 17 Marcus Steyer, NVIDIA 18 Pat Brown, NVIDIA 19 Stefan Dosinger, CodeWeavers 20 Henri Verbeet, CodeWeavers 21 22Contact 23 24 Mark Kilgard, NVIDIA (mjk 'at' nvidia.com) 25 Daniel Koch, TransGaming (daniel 'at' transgaming.com) 26 27Notice 28 29 Copyright (c) 2009-2013 The Khronos Group Inc. Copyright terms at 30 http://www.khronos.org/registry/speccopyright.html 31 32Specification Update Policy 33 34 Khronos-approved extension specifications are updated in response to 35 issues and bugs prioritized by the Khronos OpenGL Working Group. For 36 extensions which have been promoted to a core Specification, fixes will 37 first appear in the latest version of that core Specification, and will 38 eventually be backported to the extension document. This policy is 39 described in more detail at 40 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 41 42Status 43 44 Complete. Approved by the ARB on July 3, 2009. 45 Implemented by NVIDIA, March 2009 46 47Version 48 49 Last Modified Date: August 2, 2009 50 Version: 3 51 52Number 53 54 ARB Extension #64 55 56Dependencies 57 58 This extension is written against the OpenGL 2.1 Specification but 59 can apply to any prior specification. 60 61 ARB_geometry_shader4, EXT_geometry_shader4, NV_geometry_shader4, 62 and NV_gpu_program4 interact with this extension 63 64 EXT_transform_feedback, NV_transform_feedback, and the transform 65 feedback functionality made core by OpenGL 3.0 are clarified by 66 this extension. 67 68Overview 69 70 This extension provides an alternative provoking vertex convention 71 for rendering lines, triangles, and (optionally depending on the 72 implementation) quads. 73 74 The provoking vertex of a primitive is the vertex that determines the 75 constant primary and secondary colors when flat shading is enabled. 76 77 In OpenGL, the provoking vertex for triangle, quad, line, and 78 (trivially) point primitives is the last vertex used to assemble 79 the primitive. The polygon primitive is an exception in OpenGL where 80 the first vertex of a polygon primitive determines the color of the 81 polygon, even if actually broken into triangles and/or quads. 82 83 See section 2.14.7 (Flatshading) of the OpenGL 2.1 specification, 84 particularly Table 2.12 for more details. 85 86 Alternatively the provoking vertex could be the first vertex of 87 the primitive. Other APIs with flat-shading functionality such 88 as Reality Lab and Direct3D have adopted the "first vertex of the 89 primitive" convention to determine the provoking vertex. However, 90 these APIs lack quads so do not have a defined provoking vertex 91 convention for quads. 92 93 The motivation for this extension is to allow applications developed 94 for APIs with a "first vertex of the primitive" provoking vertex to 95 be easily converted to OpenGL. 96 97New Procedures and Functions 98 99 void ProvokingVertex(enum mode); 100 101New Tokens 102 103 Accepted by the <mode> parameter of ProvokingVertex: 104 105 FIRST_VERTEX_CONVENTION 0x8E4D 106 LAST_VERTEX_CONVENTION 0x8E4E 107 108 Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, 109 GetFloatv, and GetDoublev: 110 111 PROVOKING_VERTEX 0x8E4F 112 QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION 0x8E4C 113 114Additions to Chapter 2 of the OpenGL 2.1 Specification (OpenGL Operation) 115 116 -- Section 2.14.7 "Flatshading" (page 69) 117 118 Replace the entire section with: 119 120 "For fixed-function vertex processing, flatshading a primitive means 121 to assign all vertices of the primitive the same primary and 122 secondary colors (in RGBA mode) or the same color index (in color 123 index mode). If a vertex shader is active, flatshading a varying 124 output means to assign all vertices of the primitive the same value 125 for that output. 126 127 The color and/or varying output values assigned are those of the 128 provoking vertex of the primitive. The provoking vertex is 129 controlled with the command 130 131 void ProvokingVertex(enum provokeMode); 132 133 provokeMode must be either FIRST_VERTEX_CONVENTION or 134 LAST_VERTEX_CONVENTION, and controls selection of the vertex whose 135 values are assigned to the flatshaded colors and varying outputs, as 136 shown in Table 2.12. 137 138 The provoking vertex behavior of quad primitives is implementation 139 dependent, and may be determined by calling GetBooleanv with the 140 symbolic constant QUADS_FOLLOW_PROVOKING_VERTEX. A return value of 141 TRUE indicates that the provoking vertex mode is respected for quad 142 primitives, while a return value of FALSE indicates that the 143 implementation always behaves as though the provoking vertex mode 144 were LAST_VERTEX_CONVENTION. 145 146 Flatshading of colors in fixed-function vertex processing, and of 147 the built-in varying variables gl_FrontColor, gl_BackColor, 148 gl_FrontSecondaryColor and gl_BackSecondaryColor when a vertex 149 shader is active, is controlled with the command 150 151 void ShadeModel(enum mode); 152 153 <mode> must be SMOOTH or FLAT. If <mode> is SMOOTH, vertex colors 154 are treated individually. If <mode> is FLAT, flatshading is enabled 155 and colors are taken from the provoking vertex of the primitive. The 156 colors selected are those derived from current values, generated by 157 lighting, or generated by vertex shading, if lighting is disabled, 158 enabled, or a vertex shader is in use, respectively. 159 160 If a vertex or geometry shader is active, user-defined varying 161 outputs may be flatshaded by using the <flat> qualifer when 162 declaring the ouput, as described in section 4.3.6 of the OpenGL 163 Shading Language Specification (version 1.40.06). 164 165 The state required for flatshading is one bit for the shade mode, 166 one bit for the provoking vertex mode, and one 167 implementation-dependent bit for the provoking vertex behavior of 168 quad primitives. The initial value of the shade mode is SMOOTH and 169 the initial value of the provoking vertex mode is 170 LAST_VERTEX_CONVENTION. 171 172 First vertex Last vertex 173 Primitive type of polygon i convention convention 174 =========================== ============ ================================================== 175 point i i <- same 176 177 independent line 2i-1 2i 178 line loop i i+1, if i<n 179 1, if i==n 180 line strip i i+1 181 182 independent triangle 3i-2 3i 183 triangle strip i i+2 184 triangle fan i+1 i+2 185 186 independent quad 4i-3 4i, if QUADS_FOLLOW_PROVOKING_VERTEX = true 187 4i 4i, if QUADS_FOLLOW_PROVOKING_VERTEX = false <- same 188 quad strip 2i-1 2i+2, if QUADS_FOLLOW_PROVOKING_VERTEX = true 189 2i+2 2i+2, if QUADS_FOLLOW_PROVOKING_VERTEX = false <- same 190 191 single polygon (i=1) 1 1 <- same 192 193 line adjacency 4i-2 4i-1 194 line strip adjacency i+1 i+2 195 triangle adjacency 6i-5 6i-1 196 triangle strip adjacency 2i-1 2i+3 197 198 Table 2.12: Provoking vertex selection. The vertex colors and/or 199 varying values used for flatshading the <i>th primitive generated by 200 the drawing commands with the indicated primitive type are derived 201 from the corresponding values of the vertex whose index is shown in 202 the table. Vertices are numbered 1 through n, where n is the number 203 of vertices drawn." 204 205Additions to Chapter 3 of the OpenGL 2.1 Specification (Rasterization) 206 207 None 208 209Additions to Chapter 4 of the OpenGL 2.1 Specification (Per-Fragment 210Operations and the Frame Buffer) 211 212 None 213 214Additions to Chapter 5 of the OpenGL 2.1 Specification (Special 215Functions) 216 217 None 218 219Additions to Chapter 6 of the OpenGL 2.1 Specification (State and 220State Requests) 221 222 None 223 224Additions to the AGL/GLX/WGL Specifications 225 226 None 227 228Additions to the OpenGL Shading Language 229 230 None 231 232Dependencies on ARB_geometry_shader4, EXT_geometry_shader4, 233NV_geometry_shader4, NV_gpu_program4, and/or the geometry shader 234functionality integrated into the core by OpenGL 3.2: 235 236 If none of ARB_geometry_shader4, EXT_geometry_shader4, 237 NV_geometry_shader4, NV_gpu_program4, or OpenGL 3.2 (or later) are 238 supported: 239 * ignore the rows of table 2.12 for line adjacency, line strip 240 adjacency, triangle adjacency, and triangle strip adjacency. 241 * ignore any references to geometry shaders. 242 243Dependencies on EXT_gpu_shader4 and/or the flat shading functionality 244integrated into the core by OpenGL 3.0: 245 246 If neither EXT_gpu_shader4 or OpenGL 3.0 (or later) are supported, 247 ignore the references to the <flat> qualifier in the shading 248 language. 249 250Dependencies on EXT_transform_feedback, NV_transform_feedback, and/or 251the transform feedback functionality integrated into the core by OpenGL 2523.0: 253 254 Clarify the statement describing when transform feedback occurs 255 (in section 2.18 of the OpenGL 3.1 specification) to read: 256 257 "The vertices are fed back after vertex color clamping, but before 258 flatshading and clipping." 259 260 (The "flatshading and" phrase is newly clarifying.) 261 262Dependencies on ARB_compatibility and OpenGL 3.1 (or later): 263 264 If using OpenGL 3.1 (or later) and ARB_compatibility is not 265 supported ignore all references to the following: 266 267 * fixed function vertex processing, 268 * primary and secondary vertex colors and related built-in 269 varyings, 270 * color-index mode, 271 * shade mode, ShadeModel and the associated state, 272 * quad primitives, the QUADS_FOLLOW_PROVOKING_VERTEX query, and 273 the associated state, and 274 * the rows in table 2.12 for independent quad, quad strip and 275 single polygon. 276 277Dependencies on OpenGL 3.1: 278 279 When OpenGL 3.1 is supported make the following changes: 280 281 Modify the last sentence of Section 3.5.1 "Basic Line Segment 282 Rasterization" to read: 283 284 "When the flat keyword is specified, no interpolation is performed, 285 and varying outputs are taken from the corresponding generic 286 attribute value of the provoking vertex corresponding to that 287 primitive (see section 2.14.7)." 288 289 Modify the sentence in Section 3.6.1 "Basic Polygon Rasterization" 290 describing the <flat> keyword semantics to read: 291 292 "When the flat keyword is specified, no interpolation is performed, 293 and varying outputs are taken from the corresponding generic 294 attribute value of the provoking vertex corresponding to that 295 primitive (see section 2.14.7)." 296 297 Modify the paragraph in Section 3.6.5 "Polygon Multisample 298 Rasterization" describing the <noperspective> and <flat> qualifiers 299 semantices to read: 300 301 "When using a vertex shader, the <noperspective> and <flat> 302 qualifiers affect how varying shader outputs are interpolated in the 303 same fashion as described for basic polygon rasterization in section 304 3.6.1" 305 306GLX Protocol 307 308 A new GL rendering command is added. The following command is sent 309 to the server as part of a glXRender request: 310 311 ProvokingVertex 312 2 8 rendering command length 313 2 4227 rendering command opcode 314 4 ENUM provokeMode 315 316Errors 317 318 INVALID_ENUM is generated when ProvokingVertex is called with a 319 <provokeMode> that is not either FIRST_VERTEX_CONVENTION or 320 LAST_VERTEX_CONVENTION. 321 322New State 323 324(table 6.11, page 276) add the following entry: 325 326Get Value Type Get Command Initial Value Description Sec Attribute 327---------------- ---- ----------- ---------------------- ---------------- ------ --------- 328PROVOKING_VERTEX Z2 GetIntegerv LAST_VERTEX_CONVENTION Provoking vertex 2.14.7 lighting 329 convention 330 331New Implementation Dependent State 332 333(table 6.36, page 301) add the following entry: 334 335Get Value Type Get Command Initial Value Description Sec Attribute 336----------------------------- ---- ----------- ------------- ----------------- ------ --------- 337QUADS_FOLLOW_PROVOKING_VERTEX B GetBooleanv - True if quad 2.14.7 - 338 primitives follow 339 provoking vertex 340 convention 341 342NVIDIA Implementation Details 343 344 GeForce 8 (G8x, G9x, GT1xx) and up GPUs report true for 345 QUADS_FOLLOW_PROVOKING_VERTEX. 346 347 GeForce 6 and 7 (NV4x, G7x) GPUs report false for 348 QUADS_FOLLOW_PROVOKING_VERTEX. 349 350Issues 351 352 1. What should this extension be called? 353 354 RESOLVED: ARB_provoking_vertex 355 356 The phrase "provoking vertex" is not used in the core OpenGL 357 specification but it is the accepted jargon for the 358 functionality in question. This is the ARB-ratified version of 359 the EXT_provoking_vertext extension. 360 361 2. How should quads be handled? 362 363 RESOLVED: Ideally, quadrilateral primitives (GL_QUADS and 364 GL_QUAD_STRIP) would follow the provoking vertex mode. 365 366 Other existing APIs with different flatshading conventions do 367 not support quads. 368 369 Rather than force support for both the first and last convention 370 for quads (which no other API supports), instead this extension 371 provides implementations the flexibility to advertise whether 372 or not quads respect the provoking vertex or not. 373 374 This resolution ensures more hardware vendors can support 375 this extension. Hardware vendors which support both OpenGL and 376 Direct3D's provoking vertex conventions must have support for 377 "first vertex" for triangles and lines because Direct3D demands 378 these conventions. Direct3D does not demand a convention for 379 quads. However every vendor supporting OpenGL can support the 380 "last vertex" mode for quads. Leaving the quad behavior up 381 to the OpenGL implementation means hardware can simply always 382 switch to the OpenGL quad behavior when emitting quads. 383 384 See issue #12 for more details about how the 385 implementation-dependent handling of quads is advertised. 386 387 3. How should the specification language be written for this 388 extension? 389 390 RESOLVED: Update table 2.12 for all supported primitives. 391 392 The current language describes how points and lines are handled 393 in prose but the behavior for triangles, quads, and polygons is 394 specified in table 2.12. 395 396 Put all the Begin/End batch types in a single table with two 397 columns specifying the "first vertex convention" and "last vertex 398 convention" provoking vertex modes respectively. 399 400 A unified table is less ambiguous than a combination of a table 401 and prose. 402 403 4. What token names for the provoking vertex conventions should 404 be used? 405 406 RESOLVED: GL_FIRST_VERTEX_CONVENTION and 407 GL_LAST_VERTEX_CONVENTION (the initial state, consistent 408 with OpenGL's unextended operation). 409 410 The word "convention" is used because (see issue #2), the "first 411 vertex" or "last vertex" rules are not iron-clad as they may or 412 may do not apply to quads. 413 414 The provoking vertex behavior for polygons and triangle fans 415 also isn't strictly first or last vertex: Polygons always use 416 the first vertex (no matter the provoking vertex convention). 417 Triangle fans don't really use the first vertex (the spoke vertex) 418 when using the "first vertex" provoking vertex rule; see issue #7. 419 420 5. IRIS GL had a provoking vertex convention for polygons where the 421 last vertex of a polygon primitive determined the flat shaded 422 color of the polygon. Should we support this convention? 423 424 RESOLVED: No. 425 426 Interesting IRIS GL applications relying on this convention 427 are assuredly non-existent at this point. This convention 428 also requires waiting until all the vertices for a polygon 429 (which OpenGL does not bound) are specified before the polygon 430 can begin being rasterized. The IRIS GL convention was dubious 431 for this reason and OpenGL's designers were correct to abandon 432 IRIS GL's polygon provoking vertex convention. 433 434 6. How should line loops behave? 435 436 RESOLVED: Line loops in GL_FIRST_VERTEX_CONVENTION mode 437 should behave as though it were a line strip with the first 438 vertex repeated at the end. In other words, the first vertex 439 of the line loop provokes the color for the line primitive that 440 closes the line loop. 441 442 Direct3D does not support line loops. 443 444 7. How are triangle fans handled? 445 446 RESOLVED: The first vertex of a triangle fan is the spoke vertex. 447 Triangle fans in GL_FIRST_VERTEX_CONVENTION mode should use 448 the first non-spoke vertex of the primitive as the provoking 449 vertex. In other words, the spoke vertex is never the provoking 450 vertex (in either convention). 451 452 The rationale for this is to match DirectX 9's triangle 453 fan behavior. The rationale for the DirectX 9 behavior is 454 (presumably) that if the spoke vertex was considered the "first 455 vertex" of every primitive in a triangle fan, every flat shaded 456 primitive in a triangle fan would necessarily have the spoke 457 vertex's color, which isn't very interesting. 458 459 (DirectX 10 does not support triangle fans.) 460 461 8. How does the provoking vertex convention affect primitives 462 generated by a geometry shader? 463 464 RESOLVED: The provoking vertex convention affects primitives 465 whether they are generated by geometry shaders or conventional 466 (non-geometry shader) primitive assembly. 467 468 Geometry shaders only generate point, line strips, and triangle 469 strips (not line loops, triangle fans, polygons, or quads). 470 (So the GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION is 471 irrelevant when a geometry program or shader is active.) 472 473 This makes the supporting the first and last vertex conventions 474 for primitives generated by geometry shaders "simple" because in 475 the points, line strip, and triangle strip cases, the convention 476 really is to use either first or last vertex to define the 477 provoking vertex (no caveats). 478 479 There's no special specification language to support the fact that 480 the provoking vertex convention applies to primitives generated 481 by geometry shaders because flat shading behavior is described 482 in Chapter 3's rasterization discussion which is all subsequent 483 to the geometry shader processing inserted into Chapter 2. 484 485 DirectX 10 geometry shaders can output flat attributes according 486 to Direct3D's "first vertex provokes" convention for line and 487 triangle output primitives from a geometry shader. So matching 488 the DirectX 10 geometry shader behavior for flat shading requires 489 setting the provoking vertex to GL_FIRST_VERTEX_CONVENTION. 490 491 This said, the OpenGL default convention of "last vertex" for the 492 provoking vertex tends to be more useful for geometry shaders. 493 By deferring the computation of the flat shaded color to the 494 last vertex of every primitive, that tends to give the geometry 495 shader compiler the maximum allowance for scheduling computation 496 and texturing operations required to compute the flat shaded 497 color as long as possible (that is, until the last vertex of 498 the primitive). 499 500 9. Should there be an OPTION or #pragma for geometry shader assembly 501 and GLSL respectively to request the specific provoking vertex 502 convention for the shader? 503 504 RESOLVED: No. 505 506 The provoking vertex is context state that doesn't belong within 507 a shader as a pragma anymore than the stencil state belongs 508 within the shader. Overriding context state based on a pragma 509 in a shader introduces unfortunate validation interactions that 510 will slow down shader binds. 511 512 Geometry shaders written for DirectX 10 and using flat attributes 513 expect the "first vertex" provoking vertex convention but the 514 application is better off specifying the proper provoking vertex 515 convention for shaders just as is done with other context state. 516 517 TransGaming supports this resolution to not support a pragma. 518 519 10. How do geometry shader input primitives interact with this 520 extension? 521 522 RESOLVED: Table 2.12 includes the new primitives types 523 introduced by geometry shaders (GL_LINES_ADJACENCY_ARB, 524 GL_LINE_STRIP_ADJACENCY_ARB, GL_TRIANGLES_ADJACENCY_ARB, and 525 GL_TRIANGLE_STRIP_ADJACENCY_ARB). However the entries for these 526 primitive types are only relevant when these new primitive types 527 are used with NO geometry shader enabled. 528 529 When a geometry shader is enabled, the only primitive output types 530 are points, line strips, and triangle strips. 531 532 11. To what attribute set should the provoking vertex belong? 533 534 RESOLVED: Lighting (GL_LIGHTING_BIT). 535 536 This is because the provoking vertex bit is described in the 537 same context as the shade model (GL_SHADE_MODEL) setting, and 538 the shade model state is part of the lighting attribute set. 539 540 12. How should the allowance for handling quadrilateral primitives 541 be advertised? 542 543 RESOLVED: Because this extension is intended to facilitate 544 supporting Direct3D content that depends on the Direct3D's 545 provoking vertex convention yet Direct3D does not support quad 546 primitives (as OpenGL provides with GL_QUAD_STRIP and GL_QUADS), 547 the particular provoking vertex behavior of quads is not crucial 548 to this extension's intended application. 549 550 In the interest of making this extension's functionality for 551 triangle and line primitives broadly available (the primitives 552 Direct3D does support with a first vertex provoking vertex 553 convention), this extension does not mandate a single uniform 554 behavior for quad primitives. Mandating a particular behavior 555 for quad primitives would, for some implementations, encumber the 556 performance of this extension in the non-quad case or make this 557 implementation of this extension needlessly complex to implement. 558 559 Instead the GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION 560 implementation-dependent boolean indicates whether or not quads 561 (generated by GL_QUADS or GL_QUAD_STRIP) should abide by the 562 provoking vertex convention or not. 563 564 Whether or not the GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION 565 state is true or false, the provoking vertex behavior of quads 566 is well-defined in either case. 567 568 The recommended, though implementation-dependent, value for 569 GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION is true because 570 this means quads, will like lines and triangles, follow the 571 GL_PROVOKING_VERTEX state as indicated. 572 573 13. How does the provoking vertex state interact with primitive 574 restart? 575 576 RESOLVED: Orthogonally so no specific specification language 577 describing the interaction is required. 578 579 Specifically a primitive restart acts as a glEnd/glBegin 580 sequence so it restarts the primitive numbering to 1 for the 581 vertex immediately following the restart index. 582 583 14. Should the provoking vertex behavior apply to both the primary 584 and secondary color? 585 586 RESOLVED: Yes, the provoking vertex decides both the primary and 587 secondary color of a flat-shaded primitive. That's consistent 588 with Direct3D's provoking vertex convention as well as OpenGL's 589 current behavior. 590 591 15. Should the provoking vertex behavior be specified with a 592 glEnable/glDisable token instead of glProvokingVertex? 593 594 RESOLVED: The provoking vertex API is closely related 595 to glShadeModel which uses an enumerated mode rather than 596 glEnable/glDisable to specify flat or smooth shading so the API 597 mimics the glShadeModel approach. 598 599 This results in a fairly readable API usage that is more easily 600 groaked by unfamiliar programmers: 601 602 glProvokingVertex(GL_FIRST_VERTEX_CONVENTION); 603 604 instead of: 605 606 glEnable(GL_FIRST_VERTEX_CONVENTION); 607 608 It is also not clear that the provoking vertex convention is 609 really a single enable. The convention behaves differently 610 depending on the primitive type. For example, GL_POLYGON always 611 uses the first vertex as the provoking vertex regardless of the 612 provoking vertex state. 613 614 16. Does the OpenGL Shading Language (GLSL) 1.30 "flat" varying 615 qualifier respect the provoking vertex state? 616 617 RESOLVED: Yes. 618 619 The GLSL 1.30 specification says "This variable [qualified as 620 flat] will come from a single provoking vertex, as described by 621 the OpenGL Graphics System Specification." This extension amends 622 how the provoking vertex is described so no GLSL specification 623 update is required. This does imply that user-declared varyings 624 in a GLSL shader declared with "flat" will have the provoking 625 vertex convention applied to determine their value. 626 627 17. How does the provoking vertex apply to Direct3D 10? 628 629 RESOLVED: Direct3D 10 has deprecated the D3DSHADEMODE state for 630 controlling flat or smooth (Gouraud) shading. However there is 631 still the concept of a provoking vertex (called the "leading 632 vertex" by Direct3D 10) which still corresponds to this 633 extension's "first vertex" convention. 634 635 Use of the leading (provoking) vertex for constant (flat) 636 interpolation is indicated by Direct3D 10's "nointerpolation" 637 variable storage class (sometimes called an interpolation 638 modifier). 639 640 18. Does the NV_gpu_program4 "FLAT" attribute modifier respect the 641 provoking vertex state? 642 643 RESOLVED: Yes. NVIDIA's NV_gpu_program4 extension, describing 644 an OpenGL assembly for Shader Model 4.0, allows a FLAT modifier 645 to be specified for fragment program inputs. The NV_gpu_program4 646 specification says "If an attribute is flat-shaded, it will be 647 taken from the output attribute of the provoking vertex of the 648 primitive using the same data type." This extension amends 649 how the provoking vertex is described so no NV_gpu_program4 650 specification update is required. 651 652 19. How does this extension interact with transform feedback? 653 654 RESOLVED: Attribute components written out by transform feedback 655 are NOT affected by the flatshading or provoking vertex state. 656 657 While this specification is written against OpenGL 2.1, transform 658 feedback was made core functionality with OpenGL 3.0 and then 659 the order of the transform feedback was moved in the OpenGL 660 3.1 specification. Therefore the subsequent discussion uses 661 the more recent 3.1 sectioning. 662 663 Specifically the OpenGL 3.1 specification (section 2.18: Transform 664 Feedback) says "The vertices are fed back after vertex color 665 clamping, but before clipping." 666 667 This statement is unclear because flatshading (section 2.13.7: 668 Flatshading) happens inbetween vertex color clamping (section 669 2.13.6: Clamping or Masking) and primitive clipping (section 2.20: 670 Primitive Clipping). 671 672 Base on this issue the sentence is clarified to read: "The 673 vertices are fed back after vertex color clamping, but before 674 [flatshading and] clipping." 675 676 For reference, the original EXT_transform_feedback extension has 677 this same language ("The vertices are fed back after vertex color 678 clamping, but before clipping.") but follows that sentence with: 679 "If a geometry shader is active, the vertices recorded are those 680 emitted from the geometry shader." Technically geometry shading 681 takes place prior to even vertex color clamping. 682 683 Clearly flat shading needs to happen prior to clipping so that 684 clipped vertices can share the flat shaded attributes of the 685 primitive prior to any potential clipping. 686 687 This resolution is consistent with DirectX 10's behavior. 688 Technically, DirectX 10 says that vertices output through 689 transform feedback (which DirectX 10 calls "stream output") 690 only have to be defined for constant attributes of the primitive's 691 leading vertex (constant attributes are those that OpenGL would 692 call flatshaded). Other constant attributes for non-leading 693 vertices may be undefined. Leaving such constant attributes 694 undefined is undesirable, particularly given how OpenGL operates. 695 It is well-defined and more useful to simply output the value 696 of the vertex's attribute prior to any flatshading. This is 697 particularly desirable for OpenGL because with this extension 698 (and even prior to supporting this extension), the provoking 699 vertex is not always the leading vertex. 700 701 To clarify further, while this resolution is consistent with 702 DirectX 10, an OpenGL implementation that supports transform 703 feedback has no undefined behavior specified. The simplest way 704 to describe what happens is that attribute components written 705 out by transform feedback are the attribute component values 706 of vertices AFTER (optional) geometry shading and vertex color 707 clamping but PRIOR to flatshading and primitive clipping. 708 709 20. Why don't the new tokens and entry points in this extension have 710 "ARB" suffixes like other ARB extensions? 711 712 RESOLVED: Unlike most ARB extensions, this is a strict subset of 713 functionality already approved in OpenGL 3.2. This extension 714 exists only to support that functionality on older hardware that 715 cannot implement a full OpenGL 3.x driver. Since there are no 716 possible behavior changes between the ARB extension and core 717 features, source code compatibility is improved by not using 718 suffixes on the extension. 719 720Revision History 721 722 Rev. Date Author Changes 723 ---- -------- --------- --------------------------------------------- 724 1 5/19/09 dgkoch copy & rename from EXT_provoking_vertex v12 725 2 6/26/09 dgkoch resync with GL 3.2. reorder edits so they 726 fit better with ARB_compatibility. update 727 dependencies with GL 3.1, 3.2 and 728 ARB_compatibility. 729 3 8/02/09 Jon Leech Reformat to 80 columns and assign ARB 730 extension number. 731