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