1Name 2 3 NV_evaluators 4 5Name Strings 6 7 GL_NV_evaluators 8 9Contact 10 11 Matt Craighead, NVIDIA Corporation (mcraighead 'at' nvidia.com) 12 Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) 13 14Notice 15 16 Copyright NVIDIA Corporation, 2000, 2001. 17 18IP Status 19 20 NVIDIA Proprietary. 21 22Status 23 24 Discontinued. 25 26 NVIDIA no longer supports this extension in driver updates after 27 November 2002. Instead, use conventional OpenGL evaluators or 28 tessellate surfaces within your application. 29 30Version 31 32 NVIDIA Date: January 3, 2003 33 $Date$ $Revision$ 34 $Id: //sw/main/docs/OpenGL/specs/old/GL_NV_evaluators.txt#2 $ 35 36Number 37 38 225 39 40Dependencies 41 42 Written based on the wording of the OpenGL 1.2.1 specification. 43 44 Assumes support for the ARB_multitexture extension. 45 46 NV_vertex_program affects the definition of this extension. 47 48Overview 49 50 OpenGL evaluators provide applications with the capability to 51 specify polynomial or rational curves and surfaces using control 52 points relative to the Bezier basis. The curves and surfaces are 53 then drawn by evaluating the polynomials provided at various values 54 for the u parameter of a curve or the (u,v) parameters of a surface. 55 A tensor product formulation is used for the surfaces. 56 57 For various historical reasons, evaluators have not been 58 particularly popular as an interface for drawing curves and surfaces. 59 This extension proposes a new interface for surfaces that provides a 60 number of significant enhancements to the functionality provided by 61 the original OpenGL evaluators. 62 63 Many implementations never optimized evaluators, so applications 64 often implemented their own algorithms instead. This extension 65 relaxes some restrictions that make it difficult to optimize 66 evaluators. 67 68 Also, new vertex attributes have been added to OpenGL through 69 extensions, including multiple sets of texture coordinates, a 70 secondary color, a fog coordinate, a vertex weight, and others. 71 The extensions which added these vertex attributes never bothered 72 to update the functionality of evaluators, since they were used so 73 little in the first place. In turn, evaluators have become more and 74 more out of date, making it even less likely that developers will 75 want to use them. Most of the attributes are not a big loss, but 76 support for multiple sets of texture coordinates would be absolutely 77 essential to developers considering the use of evaluators. 78 79 OpenGL evaluators only support rectangular patches, not triangular 80 patches. Although triangular patches can be converted into 81 rectangular patches, direct support for triangular patches is likely 82 to be more efficient. 83 84 The tessellation algorithm used is too inflexible for most purposes; 85 only the number of rows and columns can be specified. Adjacent 86 patches must then have identical numbers of rows and columns, or 87 severe cracking will occur. Ideally, a number of subdivisions could 88 be specified for all four sides of a rectangular patch and for all 89 three of a triangular patch. This extension goes one step further 90 and allows those numbers to be specified in floating-point, providing 91 a mechanism for smoothly changing the level of detail of the surface. 92 93 Meshes evaluated with EvalMesh are required to match up exactly 94 with equivalent meshes evaluated with EvalCoord or EvalPoint. 95 This makes it difficult or impossible to use optimizations such as 96 forward differencing. 97 98 Finally, little attention is given to some of the difficult problems 99 that can arise when multiple patches are drawn. Depending on the 100 way evaluators are implemented, and depending on the orientation of 101 edges, numerical accuracy problems can cause cracks to appear between 102 patches with the same boundary control points. This extension makes 103 guarantees that an edge shared between two patches will match up 104 exactly under certain conditions. 105 106Issues 107 108 * Should one-dimensional evaluators be supported? 109 110 RESOLVED: No. This extension is intended for surfaces only. 111 112 * Should we support triangular patches? 113 114 RESOLVED: Yes. Otherwise, applications will have to convert 115 them to rectangular patches themselves. We can do this more 116 efficiently. 117 118 * What domain should triangular patches be defined on? 119 120 RESOLVED: (0,0),(1,0),(0,1). 121 122 * What memory layout should we use for triangular patch control 123 points? 124 125 RESOLVED: Both a[i][j], where i+j <= n, and a packed format are 126 supported. 127 128 * Is it worth it to have "evaluator objects"? 129 130 RESOLVED: No. We will leave these out for now. 131 132 * Should we support the original evaluators' ability to specify 133 a map from an arbitrary (u1,v1) to an arbitrary (u2,v2)? 134 135 RESOLVED: No. Maps will always extend from (0,0) to (1,1) 136 and will always be evaluated from (0,0) to (1,1). 137 138 * Should the new interface support an EvalCoord-like syntax? 139 140 RESOLVED: No. We are only interested in evaluating an entire 141 mesh at once. 142 143 * Should we support the "mode" parameter to the existing EvalMesh2, 144 which allows the mesh to be tessellated in wireframe or as points? 145 146 RESOLVED: No. We will leave in the parameter and require that 147 it be FILL, though, to leave room for a future extension. 148 149 * Should there be a new interface to specify control points or should 150 Map2{fd} be reused? 151 152 RESOLVED: A new interface. There are enough changes compared to 153 the original evaluators that we can't reuse the old interface 154 without causing more problems. For example, the target 155 parameter of Map2{fd} is really a cross of target and index 156 in MapControlPointsNV, and so it ends up creating an excessive 157 number of enumerants. 158 159 * How should grids be specified? 160 161 RESOLVED: A MapParameter command. This is better than a new 162 MapGrid- style command because it can be extended to include 163 new parameter types. 164 165 * Should there be any rules about the order of generation of 166 primitives within a single patch? 167 168 RESOLVED: No. The tessellation algorithm itself is not even 169 specified, so it makes no sense to do this. Applications must 170 not depend on the order in which the primitives are drawn. 171 172 * Should the stride for MapControlPointsNV be specified in basic 173 machine units (i.e. unsigned bytes) or in floats/doubles? 174 175 RESOLVED: ubytes. Most of the rest of OpenGL (vertex arrays, 176 pixel path, etc.) uses ubytes; evaluators are actually 177 inconsistent. 178 179 * How much leeway should implementations be given to choose their own 180 algorithm for tessellation? 181 182 RESOLVED: The integral tessellation scheme will require a 183 specific tessellation of the boundary edges of the patch, but the 184 interior tessellation is implementation-specific. The fractional 185 tessellation scheme will only require a minimum number of segments 186 along each edge. In either case, a minimum number of triangles 187 for the entire patch is specified. 188 189 * Should there be rules to ensure that the triangles will be 190 oriented in a consistent fashion? 191 192 RESOLVED: Yes. This is essential for features such as backface 193 culling to work properly. The rule given ensures that the 194 orientation will be identical to the orientation used for the 195 original evaluators. 196 197 * Should there be a separate MAX_EVAL_ORDER for rational surfaces? 198 199 RESOLVED: Yes. Rational surfaces require additional calculation to 200 be done by the implementation, especially if AUTO_NORMAL is 201 enabled. Furthermore, the most useful rational surfaces are of low 202 order. For example, all the conic sections are quadratic rational 203 surfaces. 204 205 * Should there be enables similar to AUTO_NORMAL that generate 206 partials of U (tangents), partials of V, and/or binormals? 207 208 RESOLVED: No. The application is responsible for configuring 209 the evaluators appropriately. 210 211 The auto normal functionality is supported because it is fairly 212 complicated and was already a core part of OpenGL for evaluators. 213 Plus there is already a "normal" vertex attribute for it to 214 automatically generate. 215 216 The partials of U and partials of V are fairly straightforward 217 to evaluate (just take the derivative of the bivariate polynomial 218 in terms of either U or V) plus there is not a particular vertex 219 attribute associated with each of these. 220 221New Procedures and Functions 222 223 void MapControlPointsNV(enum target, uint index, enum type, 224 sizei ustride, sizei vstride, 225 int uorder, int vorder, 226 boolean packed, 227 const void *points) 228 229 void MapParameterivNV(enum target, enum pname, const int *params) 230 void MapParameterfvNV(enum target, enum pname, const float *params) 231 232 void GetMapControlPointsNV(enum target, uint index, enum type, 233 sizei ustride, sizei vstride, 234 boolean packed, void *points) 235 236 void GetMapParameterivNV(enum target, enum pname, int *params) 237 void GetMapParameterfvNV(enum target, enum pname, float *params) 238 void GetMapAttribParameterivNV(enum target, uint index, enum pname, 239 int *params) 240 void GetMapAttribParameterfvNV(enum target, uint index, enum pname, 241 float *params) 242 243 void EvalMapsNV(enum target, enum mode) 244 245New Tokens 246 247 Accepted by the <target> parameter of MapControlPointsNV, 248 MapParameter[if]vNV, GetMapControlPointsNV, GetMapParameter[if]vNV, 249 GetMapAttribParameter[if]vNV, and EvalMapsNV: 250 251 EVAL_2D_NV 0x86C0 252 EVAL_TRIANGULAR_2D_NV 0x86C1 253 254 Accepted by the <pname> parameter of MapParameter[if]vNV and 255 GetMapParameter[if]vNV: 256 257 MAP_TESSELLATION_NV 0x86C2 258 259 Accepted by the <pname> parameter of GetMapAttribParameter[if]vNV: 260 261 MAP_ATTRIB_U_ORDER_NV 0x86C3 262 MAP_ATTRIB_V_ORDER_NV 0x86C4 263 264 Accepted by the <cap> parameter of Disable, Enable, and IsEnabled, 265 and by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, 266 and GetDoublev: 267 268 EVAL_FRACTIONAL_TESSELLATION_NV 0x86C5 269 270 EVAL_VERTEX_ATTRIB0_NV 0x86C6 271 EVAL_VERTEX_ATTRIB1_NV 0x86C7 272 EVAL_VERTEX_ATTRIB2_NV 0x86C8 273 EVAL_VERTEX_ATTRIB3_NV 0x86C9 274 EVAL_VERTEX_ATTRIB4_NV 0x86CA 275 EVAL_VERTEX_ATTRIB5_NV 0x86CB 276 EVAL_VERTEX_ATTRIB6_NV 0x86CC 277 EVAL_VERTEX_ATTRIB7_NV 0x86CD 278 EVAL_VERTEX_ATTRIB8_NV 0x86CE 279 EVAL_VERTEX_ATTRIB9_NV 0x86CF 280 EVAL_VERTEX_ATTRIB10_NV 0x86D0 281 EVAL_VERTEX_ATTRIB11_NV 0x86D1 282 EVAL_VERTEX_ATTRIB12_NV 0x86D2 283 EVAL_VERTEX_ATTRIB13_NV 0x86D3 284 EVAL_VERTEX_ATTRIB14_NV 0x86D4 285 EVAL_VERTEX_ATTRIB15_NV 0x86D5 286 287 Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, 288 GetFloatv, and GetDoublev: 289 290 MAX_MAP_TESSELLATION_NV 0x86D6 291 MAX_RATIONAL_EVAL_ORDER_NV 0x86D7 292 293Additions to Chapter 2 of the 1.2 Specification (OpenGL Operation) 294 295 None. 296 297Additions to Chapter 3 of the 1.2 Specification (Rasterization) 298 299 None. 300 301Additions to Chapter 4 of the 1.2 Specification (Per-Fragment Operations 302and the Frame Buffer) 303 304 None. 305 306Additions to Chapter 5 of the 1.2 Specification (Special Functions) 307 308 -- NEW Section 5.7 "General Evaluators" 309 310 "General evaluators are similar to evaluators in that they can 311 be used to evaluate polynomial and rational mappings, but general 312 evaluators have several new features that the original evaluators 313 do not. First, they support triangular surfaces in addition to 314 (quadrilateral) tensor product surfaces. Second, the tessellation 315 can be varied continuously as well as in integral steps. Finally, 316 general evaluators can evaluate all vertex attributes, not just the 317 vertex, color, normal, and texture coordinates. 318 319 Several elements of the original evaluators have been removed in 320 the general evaluators interface. The general evaluators always 321 evaluate four components in parallel, whereas the original evaluators 322 might evaluate between 1 and 4 (see the "k" column in Table 5.1 on 323 page 165). The original evaluators can map on an arbitrary domain 324 and can map grids on an arbitrary region, whereas the general 325 evaluators only use the [0,1] range. Support for 1D evaluators, 326 an EvalCoord-style interface, and the "mode" parameter of EvalMesh* 327 has also been removed from the general evaluators. 328 329 The command 330 331 void MapControlPointsNV(enum target, uint index, enum type, 332 sizei ustride, sizei vstride, 333 int uorder, int vorder, boolean packed, 334 const void *points); 335 336 specifies control points for a general evaluator map. target 337 is the type of evaluator map and can be either EVAL_2D_NV or 338 EVAL_TRIANGULAR_2D_NV. index is the number of the vertex attribute 339 register the map will be used to evaluate for; these are the same 340 indices used in the GL_NV_vertex_program extension. Table X.1 341 shows the relationship between these indices and the conventional 342 per-vertex attributes for implementations that do not support 343 GL_NV_vertex_program. 344 345Vertex 346Attribute Conventional Conventional 347Register Per-vertex Conventional Component 348Number Parameter Per-vertex Parameter Command Mapping 349--------- --------------- -------------------------------------- ------------ 350 0 vertex position Vertex x,y,z,w 351 1 vertex weights VertexWeightEXT w,0,0,1 352 2 normal Normal x,y,z,1 353 3 primary color Color r,g,b,a 354 4 secondary color SecondaryColorEXT r,g,b,1 355 5 fog coordinate FogCoordEXT fc,0,0,1 356 6 - - - 357 7 - - - 358 8 texture coord 0 MultiTexCoordARB(GL_TEXTURE0_ARB, ...) s,t,r,q 359 9 texture coord 1 MultiTexCoordARB(GL_TEXTURE1_ARB, ...) s,t,r,q 360 10 texture coord 2 MultiTexCoordARB(GL_TEXTURE2_ARB, ...) s,t,r,q 361 11 texture coord 3 MultiTexCoordARB(GL_TEXTURE3_ARB, ...) s,t,r,q 362 12 texture coord 4 MultiTexCoordARB(GL_TEXTURE4_ARB, ...) s,t,r,q 363 13 texture coord 5 MultiTexCoordARB(GL_TEXTURE5_ARB, ...) s,t,r,q 364 14 texture coord 6 MultiTexCoordARB(GL_TEXTURE6_ARB, ...) s,t,r,q 365 15 texture coord 7 MultiTexCoordARB(GL_TEXTURE7_ARB, ...) s,t,r,q 366 367Table X.1: Aliasing of vertex attributes with conventional per-vertex 368parameters. 369 370 type is either FLOAT or DOUBLE. ustride and vstride are the numbers 371 of basic machine units (typically unsigned bytes) between control 372 points in the u and v directions. uorder and vorder have the same 373 meaning they do in the Map2{fd} command. The error INVALID_VALUE 374 is generated if either uorder or vorder is less than one or greater 375 than MAX_EVAL_ORDER. The error INVALID_OPERATION is generated if 376 target is EVAL_TRIANGULAR_2D_NV and uorder is not equal to vorder. 377 378 points is a pointer to an array of control points. If target is 379 EVAL_2D_NV, there are uorder*vorder control points in the array, 380 and if it is EVAL_TRIANGULAR_2D_NV, there are uorder*(uorder+1)/2 381 points in the array. If packed is FALSE, control point i,j is 382 located 383 384 (ustride)i + (vstride)j 385 386 basic machine units from points. If target is EVAL_2D_NV, i ranges 387 from 0 to uorder-1, and j ranges from 0 to vorder-1. If target is 388 EVAL_TRIANGULAR_2D_NV, i and j range from 0 to uorder-1, and i+j 389 must be less than or equal to uorder-1. 390 391 If packed is TRUE and target is EVAL_2D_NV, control point i,j is 392 located 393 394 (ustride)(j*uorder + i) 395 396 basic machine units from points. If packed is TRUE and target is 397 EVAL_TRIANGULAR_2D_NV, control point i,j is located 398 399 (ustride)(j*uorder + i - j*(j-1)/2) 400 401 basic machine units from points. 402 403 The error INVALID_OPERATION is generated if index is 0, one of the 404 control points' fourth components is not equal to 1, and either uorder 405 of vorder is greater than MAX_RATIONAL_EVAL_ORDER_NV. 406 407 The evaluation of a 2D tensor product map is performed in the same 408 way as for the original evaluators. The exact coordinates produced 409 by the original evaluators may differ from those produced by the 410 general evaluators, since different algorithms may be used. 411 412 A triangular map may be evaluated as follows. Let Ri,j be the 413 4-component vector for control point i,j and n be the degree of the 414 patch (i.e. uorder-1). Then: 415 416 --- 417 \ (n) (n-i) i j n-i-j 418 p_t(u,v) = / (i) ( j ) u v (1-u-v) Ri,j 419 --- 420 i,j >= 0 421 i+j <= n 422 423 evaluates the point p_t(u,v) on the triangular patch at parameter 424 values (u,v). (The notation on the left indicates "n choose i" and 425 "n minus i choose j", i.e., binomial coefficients.) 426 427 The evaluation of any particular attribute can be enabled or disabled 428 with Enable and Disable using one of the EVAL_VERTEX_ATTRIBi_NV 429 constants. 430 431 If AUTO_NORMAL is enabled (see section 5.1), analytically computed 432 normals are evaluated as well. The formula for the normal is the same 433 as the one in section 5.1, except that the magnitude of the normals is 434 undefined. These normals should be renormalized by enabling NORMALIZE, 435 or by normalizing them in a vertex program. The w of the normal 436 vertex attribute will always be 1. 437 438 The commands 439 440 void MapParameter{if}vNV(enum target, enum pname, T params); 441 442 can be used to specify the level of tessellation to evaluate, 443 where target is EVAL_2D_NV or EVAL_TRIANGULAR_2D_NV and pname is 444 MAP_TESSELLATION_NV. If target is EVAL_2D_NV, params contains the 445 four values [nu0,nu1,nv0,nv1], and if it is EVAL_TRIANGULAR_2D_NV, 446 params contains the three values [n1,n2,n3]. The state for each 447 target is independent of the other. These values are clamped to 448 the range [1.0, MAX_MAP_TESSELLATION_NV]. 449 450 The use of a fractional tessellation algorithm can be 451 enabled or disabled with Enable and Disable using the 452 EVAL_FRACTIONAL_TESSELLATION_NV constant. The fractional tessellation 453 algorithm allows the tessellation to smoothly morph without popping 454 as the tessellation parameters are varied by small amounts. 455 456 The command 457 458 void EvalMapsNV(enum target, enum mode); 459 460 evaluates the currently enabled maps. target is either EVAL_2D_NV 461 or EVAL_TRIANGULAR_2D and specifies which set of maps to evaluate. 462 mode must be FILL. If EVAL_VERTEX_ATTRIB0_NV is not enabled, the 463 error INVALID_OPERATION results. 464 465 If EVAL_FRACTIONAL_TESSELLATION_NV is disabled, tensor product maps 466 are evaluated such that the boundaries of the mesh are divided into 467 ceil(nu0) segments on the edge from (0,0) to (1,0), ceil(nu1) segments 468 on the edge from (0,1) to (1,1), ceil(nv0) segments on the edge from 469 (0,0) to (0,1), and ceil(nv1) segments on the edge from (1,0) to 470 (1,1). These segments must be evaluated at equal spacings in (u,v) 471 parameter space. 472 473 Triangular maps are evaluated such that the boundary of the mesh from 474 (0,0) to (1,0) has ceil(n1) equally-spaced segments, the boundary 475 from (1,0) to (0,1) has ceil(n2) equally-spaced segments, and the 476 boundary from (0,1) to (0,0) has ceil(n3) equally-spaced segments. 477 478 If EVAL_FRACTIONAL_TESSELLATION_NV is enabled, each edge must be 479 tessellated with no fewer the number of segments that would be used in 480 the non- fractional case for any values of the tessellation parameters. 481 Furthermore, the tessellation of each edge must vary smoothly with the 482 parameters; that is, a small change in any or all of the parameters 483 must cause a small change in the tessellation. Whenever a new vertex 484 is introduced into the tessellation, it must be coincident with another 485 vertex, and whenever a vertex is removed, it must have been coincident 486 with a different vertex. The parameter-space position of any vertex 487 must be a continuous function of the tessellation parameters. 488 489 The same minimum triangle requirements apply to fractional 490 tessellations as to integral tessellations. 491 492 A tensor product patch must always be tessellated with no fewer than 493 494 2 * ceil((nu0+nu1)/2) * ceil((nv0+nv1)/2) 495 496 triangles in total. 497 498 A triangular patch must always be tessellated with no fewer than 499 500 ceil((n1+n2+n3)/3)^2 501 502 triangles in total. 503 504 If a triangle is formed by evaluating the maps at the three 505 coordinates (u1,v1), (u2,v2), and (u3,v3), it must be true that 506 507 (u3-u1)*(v2-v1) - (u2-u1)*(v3-v1) >= 0 508 509 to ensure that all triangles in a patch have a consistent 510 orientation. 511 512 The current value of any vertex attribute for which the evaluation 513 of a map is enabled becomes undefined after an EvalMapsNV command. 514 If AUTO_NORMAL is enabled, the current normal becomes undefined as 515 well. 516 517 If AUTO_NORMAL is enabled, the analytically computed normals take 518 precedence over the currently enabled map for vertex attribute 2 519 (the normal). 520 521 To prevent cracks, certain rules must be established for performing 522 the evaluations. The goal of these rules is to ensure that no 523 matter what order control points are specified in and what the 524 tessellation parameters are, so long as the control points on any edge 525 exactly match the control points of an adjacent edge, and so long as 526 the subdivision parameter for that edge is the same for the adjacent 527 patch, there will be no cracking artifacts between the two patches. 528 These requirements are completely independent of numerical precision. 529 In particular, we will require that these shared vertices' positions 530 be equal. Furthermore, there must be no cracking inside the geometry 531 of any patch, and normals must not change in a discontinuous fashion 532 so that there are no discontinuities in lighting or other effects 533 that use the normal. 534 535 Let two patches share an edge of equal order (the order of an edge is 536 the order of the patch in that direction for a tensor product patch, 537 or the order of the patch for a triangular patch). Then this edge is 538 said to be consistent if all the vertex control points (vertex 539 attribute 0) are identical on each edge (although they may be specified 540 in the opposite direction, or even in a different coordinate; one may 541 an edge in the u direction, and one may be an edge in the v direction). 542 543 If an edge is consistent, and if each of the two patches are 544 tessellated with identical tessellation parameters for that edge, 545 then the vertex coordinates given to vertex processing must be 546 exactly equal for each of the vertices. 547 548 The vertex coordinates given to vertex processing for the corner 549 vertices of any patch must be exactly equal to the values of the 550 corner control points of that patch, regardless of the patch's 551 order, type, tessellation parameters, the state of the AUTO_NORMAL or 552 EVAL_FRACTIONAL_TESSELLATION_NV enables, the control points, order, 553 or enable of any other associated map, or any other OpenGL state. 554 555 The vertex coordinates and normals given to vertex processing for 556 any vertex of a patch must be exactly equal each time that vertex 557 is evaluated during the tessellation of a patch. Since each vertex 558 is shared between several triangles in the patch, any variation in 559 these coordinates and normals would result in cracks or lighting 560 discontinuities. 561 562 The state required for the general evaluators consists of a bit 563 indicating whether fractional tessellation is enabled or disabled, 16 564 bits indicating whether the evaluation of each vertex attribute is 565 enabled or disabled, four floating-point map tessellation values for 566 tensor product patches, three floating-point map tessellation values 567 for triangular patches, and a map specification for a tensor product 568 patch and a triangular patch for each vertex attribute. A map 569 specification consists of two integers indicating the order of the 570 map in u and v and a two-dimensional array of vectors of four 571 floating-point values containing the control points for that map. 572 The initial state of fractional tessellation is disabled. The initial 573 state of evaluation of vertex attribute 0 is enabled, and the initial 574 state of evaluation for any other vertex attribute is disabled. The 575 initial value of the tessellation parameters is 1.0. The initial order 576 of each map specification is an order of 1 in both u and v and a 577 single control point of [0,0,0,1]." 578 579Additions to Chapter 6 of the 1.2 Specification (State and State Requests) 580 581 -- NEW Section 6.1.13 "General Evaluator Queries" 582 583 "The commands 584 585 void GetMapParameterivNV(enum target, enum pname, int *params); 586 void GetMapParameterfvNV(enum target, enum pname, float *params); 587 588 obtain the parameters for a map target. target may be one of 589 EVAL_2D_NV or EVAL_TRIANGULAR_2D_NV. pname must be MAP_TESSELLATION_NV. 590 The map tessellation is placed in params. 591 592 The commands 593 594 void GetMapAttribParameterivNV(enum target, uint index, enum pname, 595 int *params); 596 void GetMapAttribParameterfvNV(enum target, uint index, enum pname, 597 float *params); 598 599 obtain parameters for a single map. target may be one of EVAL_2D_NV 600 or EVAL_TRIANGULAR_2D_NV. index is the number of the vertex attribute 601 register the map is used for evaluating. If pname is 602 MAP_ATTRIB_U_ORDER_NV, the u order of the map is placed in params. If 603 pname is MAP_ATTRIB_V_ORDER_NV, the v order of the map is placed in 604 params. 605 606 The command 607 608 void GetMapControlPointsNV(enum target, uint index, enum type, 609 sizei ustride, sizei vstride, boolean packed, 610 void *points); 611 612 obtains the control points of a map. target may be one of EVAL_2D_NV 613 or EVAL_TRIANGULAR_2D_NV. index is the number of the vertex attribute 614 register the map is used for evaluating. type is either FLOAT or 615 DOUBLE. ustride and vstride are the numbers of basic machine units 616 (typically unsigned bytes) between control points in the u and v 617 directions. points is a pointer to an array where the control points 618 are to be written. If target is EVAL_2D_NV, there are uorder*vorder 619 control points in the array, and if it is EVAL_TRIANGULAR_2D_NV, there 620 are uorder*(uorder+1)/2 points in the array. If packed is FALSE, 621 control point i,j is located 622 623 (ustride)i + (vstride)j 624 625 basic machine units from points. If packed is TRUE and target is 626 EVAL_2D_NV, control point i,j is located 627 628 (ustride)(j*uorder + i) 629 630 basic machine units from points. If packed is TRUE and target is 631 EVAL_TRIANGULAR_2D_NV, control point i,j is located 632 633 (ustride)(j*uorder + i - j*(j-1)/2) 634 635 basic machine units from points. If target is EVAL_2D_NV, i ranges 636 from 0 to uorder-1, and j ranges from 0 to vorder-1. If target is 637 EVAL_TRIANGULAR_2D_NV, i and j range from 0 to uorder-1, and i+j 638 must be less than or equal to uorder-1." 639 640Additions to the GLX Specification 641 642 Nine new GL commands are added. 643 644 The following three rendering commands are sent to the sever 645 as part of a glXRender request: 646 647 MapParameterivNV 648 2 12+4*n rendering command length 649 2 ???? rendering command opcode 650 4 ENUM target 651 4 ENUM pname 652 0x86C2 GL_MAP_TESSELLATION_NV 653 n=3 if (target == GL_EVAL_TRIANGULAR_2D_NV) 654 n=4 if (target == GL_EVAL_2D_NV) 655 else n=0 command is erroneous 656 4*n LISTofINT32 params 657 658 659 MapParameterfvNV 660 2 12+4*n rendering command length 661 2 ???? rendering command opcode 662 4 ENUM target 663 4 ENUM pname 664 0x86C2 GL_MAP_TESSELLATION_NV 665 n=3 if (target == GL_EVAL_TRIANGULAR_2D_NV) 666 n=4 if (target == GL_EVAL_2D_NV) 667 else n=0 command is erroneous 668 4*n LISTofFLOAT32 params 669 670 671 EvalMapsNV 672 2 12 rendering command length 673 2 ???? rendering command opcode 674 4 ENUM target 675 4 ENUM mode 676 677 The following rendering command is potentially large and can be sent 678 in a glXRender or glXRenderLarge request: 679 680 MapControlPointsNV 681 2 24+m rendering command length 682 2 ???? rendering command opcode 683 4 ENUM target 684 4 CARD32 index 685 4 CARD32 type 686 4 INT32 uorder 687 4 INT32 vorder 688 m (see below) points 689 690 Determine m from the table below; n depends on the target. If the 691 target is GL_EVAL_2D_NV, then n = uorder*vorder. If the target 692 is GL_EVAL_TRIANGULAR_2D_NV, then n = uorder * (uorder+1)/2. 693 The points data is packed such that when unpacked by the server, 694 the value of ustride is 16 for GL_FLOAT typed data and 32 for 695 GL_DOUBLE typed data. 696 697 type encoding of type type of lists m (bytes) 698 --------- ---------------- ------------- --------- 699 GL_FLOAT 0x1406 LISTofFLOAT32 n*4 700 GL_DOUBLE 0x140A LISTofFLOAT64 n*8 701 702 If the command is encoded in a glXRenderLarge request, the command 703 opcode and command length fields above are expanded to 4 bytes each: 704 705 4 28+m rendering command length 706 4 ???? rendering command opcode 707 708 The remaining five commands are non-rendering commands. These commands 709 are sent separately (i.e., not as part of a glXRender or glXRenderLarge 710 request), using the glXVendorPrivateWithReply request: 711 712 GetMapParameterivNV 713 1 CARD8 opcode (X assigned) 714 1 17 GLX opcode (glXVendorPrivateWithReply) 715 2 5 request length 716 4 ???? vendor specific opcode 717 4 GLX_CONTEXT_TAG context tag 718 4 ENUM target 719 4 ENUM pname 720 => 721 1 1 reply 722 1 unused 723 2 CARD16 sequence number 724 4 m reply length, m=(n==1?0:n) 725 4 unused 726 4 CARD32 n 727 728 if (n=1) this follows: 729 730 4 INT32 params 731 12 unused 732 733 otherwise this follows: 734 735 16 unused 736 n*4 LISTofINT32 params 737 738 GetMapParameterfvNV 739 1 CARD8 opcode (X assigned) 740 1 17 GLX opcode (glXVendorPrivateWithReply) 741 2 5 request length 742 4 ???? vendor specific opcode 743 4 GLX_CONTEXT_TAG context tag 744 4 ENUM target 745 4 ENUM pname 746 => 747 1 1 reply 748 1 unused 749 2 CARD16 sequence number 750 4 m reply length, m=(n==1?0:n) 751 4 unused 752 4 CARD32 n 753 754 if (n=1) this follows: 755 756 4 FLOAT32 params 757 12 unused 758 759 otherwise this follows: 760 761 16 unused 762 n*4 LISTofFLOAT32 params 763 764 GetMapAttribParameterivNV 765 1 CARD8 opcode (X assigned) 766 1 17 GLX opcode (glXVendorPrivateWithReply) 767 2 6 request length 768 4 ???? vendor specific opcode 769 4 GLX_CONTEXT_TAG context tag 770 4 ENUM target 771 4 CARD32 index 772 4 ENUM pname 773 => 774 1 1 reply 775 1 unused 776 2 CARD16 sequence number 777 4 m reply length, m=(n==1?0:n) 778 4 unused 779 4 CARD32 n 780 781 if (n=1) this follows: 782 783 4 INT32 params 784 12 unused 785 786 otherwise this follows: 787 788 16 unused 789 n*4 LISTofINT32 params 790 791 GetMapAttribParameterfvNV 792 1 CARD8 opcode (X assigned) 793 1 17 GLX opcode (glXVendorPrivateWithReply) 794 2 6 request length 795 4 ???? vendor specific opcode 796 4 GLX_CONTEXT_TAG context tag 797 4 ENUM target 798 4 CARD32 index 799 4 ENUM pname 800 => 801 1 1 reply 802 1 unused 803 2 CARD16 sequence number 804 4 m reply length, m=(n==1?0:n) 805 4 unused 806 4 CARD32 n 807 808 if (n=1) this follows: 809 810 4 FLOAT32 params 811 12 unused 812 813 otherwise this follows: 814 815 16 unused 816 n*4 LISTofFLOAT32 params 817 818 GetMapControlPointsNV 819 1 CARD8 opcode (X assigned) 820 1 17 GLX opcode (glXVendorPrivateWithReply) 821 2 6 request length 822 4 ???? vendor specific opcode 823 4 GLX_CONTEXT_TAG context tag 824 4 ENUM target 825 4 CARD32 index 826 4 ENUM type 827 => 828 1 1 reply 829 1 unused 830 2 CARD16 sequence number 831 4 m reply length, m 832 4 unused 833 4 CARD32 uorder 834 4 CARD32 vorder 835 12 unused 836 837 if type == 0x1406 (GL_FLOAT) and target == 0x86C0 838 (GL_EVAL_2D_NV), m = 4*uorder*vorder and the packed control 839 points follow assuming ustride = 16 840 841 m*4 LISTofFLOAT32 params 842 843 if type == 0x140A (GL_DOUBLE) and target == 0x86C0 844 (GL_EVAL_2D_NV), m = 4*uorder*vorder and the packed control 845 points follow asssuming ustride = 32 846 847 m*8 LISTofFLOAT64 params 848 849 if type == 0x1406 (GL_FLOAT) and target == 0x86C1 850 (GL_EVAL_TRIANGULAR_2D_NV), m = 4*uorder*(uorder+1)/2 and 851 the packed control points follow assuming ustride = 16 852 853 m*4 LISTofFLOAT32 params 854 855 if type == 0x140A (GL_DOUBLE) and target == 0x86C1 856 (GL_EVAL_TRIANGULAR_2D_NV), m = 4*uorder*(uorder+1)/2 and 857 the packed control points follow asssuming ustride = 32 858 859 m*8 LISTofFLOAT64 params 860 861 otherwise m = 0 and nothing else follows. 862 863Errors 864 865 The error INVALID_VALUE is generated if MapControlPointsNV, 866 GetMapControlPointsNV, or GetMapAttribParameter{if}v is called where 867 index is greater than 15. 868 869 The error INVALID_VALUE is generated if MapControlPointsNV 870 or GetMapControlPointsNV is called where ustride or vstride is 871 negative. 872 873 The error INVALID_VALUE is generated if MapControlPointsNV is 874 called where uorder or vorder is less than one or greater than 875 MAX_EVAL_ORDER. 876 877 The error INVALID_OPERATION is generated if MapControlPointsNV is 878 called where target is EVAL_TRIANGULAR_2D_NV and uorder is not equal 879 to vorder. 880 881 The error INVALID_OPERATION is generated if MapControlPointsNV is 882 called where index is 0, one of the control points' fourth 883 components is not equal to 1, and either uorder of vorder is greater 884 than MAX_RATIONAL_EVAL_ORDER_NV. 885 886 The error INVALID_OPERATION is generated if EvalMapsNV is called 887 where EVAL_VERTEX_ATTRIB0_NV is disabled. 888 889New State 890 891(add to table 6.22, page 212) 892 893Get Value Type Get Command Initial Value Description Sec Attribute 894------------------------------- ----------- ------------------------ ---------------- -------------- ----- --------- 895EVAL_FRACTIONAL_TESSELLATION_NV B IsEnabled False fractional 5.7 eval/enable 896 tess. enable 897EVAL_VERTEX_ATTRIBi_NV Bx16 IsEnabled True if i=0, attrib eval 5.7 eval/enable 898 false otherwise enable 899 900EVAL_2D_NV R4x16x8*x8* GetMapControlPointsNV [0,0,0,1] control points 5.7 - 901EVAL_TRIANGULAR_2D_NV R4x16x8*x8* GetMapControlPoints [0,0,0,1] control points 5.7 - 902 903MAP_TESSELLATION_NV R4,R3 GetMapParameter*NV all 1.0 level of 5.7 eval 904 tessellation 905 906MAP_ATTRIB_U_ORDER_NV Z8*x16x2 GetMapAttribParameter*NV 1 map order in 5.7 - 907 U direction 908MAP_ATTRIB_V_ORDER_NV Z8*x16x2 GetMapAttribParameter*NV 1 map order in 5.7 - 909 V direction 910New Implementation Dependent State 911 912(add to table 6.24/6.25, page 214) 913 914Get Value Type Get Command Minimum Value Description Sec Attribute 915------------------------ ---- ------------ ------------- ----------- ----- --------- 916MAX_MAP_TESSELLATION_NV Z+ GetIntegerv 256 maximum level 5.7 - 917 of tessellation 918MAX_RATIONAL_EVAL_ORDER_NV Z+ GetIntegerv 4 maximum order 5.7 - 919 of rational 920 surfaces 921 922Revision History 923 924 1/3/2003 changed status to "discontinued" 925