1Name 2 3 ARB_vertex_blend 4 5Name Strings 6 7 GL_ARB_vertex_blend 8 9Contact 10 11 Evan Hart, NVIDIA (ehart 'at' nvidia.com) 12 Tom Frisinger, AMD (tom.frisinger 'at' amd.com) 13 14Notice 15 16 Copyright (c) 2000-2013 The Khronos Group Inc. Copyright terms at 17 http://www.khronos.org/registry/speccopyright.html 18 19Specification Update Policy 20 21 Khronos-approved extension specifications are updated in response to 22 issues and bugs prioritized by the Khronos OpenGL Working Group. For 23 extensions which have been promoted to a core Specification, fixes will 24 first appear in the latest version of that core Specification, and will 25 eventually be backported to the extension document. This policy is 26 described in more detail at 27 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 28 29Status 30 31 Complete. Approved by ARB on September 19, 2000. 32 33Version 34 35 Last Modified Date: November 4, 2006 36 Revision: 1.3 37 38Number 39 40 ARB Extension #15 41 42Dependencies 43 44 OpenGL 1.0 is required. 45 This extension is written against the OpenGL 1.2.1 Specification. 46 47Overview 48 49 This extension provides the ability to replace the single 50 modelview transformation with a set of n vertex units. (Where 51 n is constrained to an implementation defined maximum.) Each 52 unit has its own modelview transform matrix. For each unit, 53 there is a current weight associated with the vertex. When 54 this extension is enabled the vertices are transformed by 55 the modelview matrices of all of the enabled units. Afterward, 56 these results are scaled by the weights for the respective 57 units and then summed to create the eye-space vertex. A 58 similar procedure is followed for the normals, except they 59 are transformed by the inverse transpose of the modelview 60 matrices. 61 62 This extension is an orthoganalized version of functionality 63 already provided by other 3D graphics API's. 64 65 66IP Status 67 68 Unknown, but believed to be none. 69 70Issues 71 72 73 Should an indexed form of matrix addressing be used? 74 75 No, this should be added as an additional extension. 76 77 Should integer blending weights be allowed? 78 79 Yes, this was an over-sight in the original spec. Integer 80 formats allow for the potential to provide smaller data 81 types to the API. Integer data types are always mapped 82 to floats in the same manner as colors. 83 84 Should the blending weights be forced to sum to 1? 85 86 No, it should be provided as a convenience to developers, 87 since it is the most common case. Additionally, it should 88 be noted that even if the weights do not sum to one, 89 the result of the modelview transformation provides an 90 eye coordinate whose homogenous coordinate is equivalent 91 to the homogeneous coordinate after the transformation 92 had the weights been scaled to sum to one. 93 94 Additionally, NORMALIZE should in general be left on to 95 prevent non-unit normals. 96 97 What about projective modelview matrices? 98 99 Projective modelview matrices can cause problems with many 100 other features in GL, so this should not be a problem in 101 practice. This extension makes no attempts to handle 102 projective modelview matrices. 103 104 Should the set of modelview matrices affect parts of GL other 105 than vertices? 106 107 No, this seems to confuse the operation, and it forces 108 vertex components to affect setting of GL state. 109 110 Some transformations may cause the normals to be transformed in 111 such a way that they no longer represent the tangent plane to 112 the surface. 113 114 This is a basic property of the math of the technique. In 115 general with these varying transformations, it is impossible 116 to maintain the normal as the tangent plane to the surface 117 without topological information. 118 119 Lacking the topological data, the best approximation is to 120 transform the normals by the inverse transpose of the 121 blend of the modelview matrices. As the inverse per-vertex 122 may be computationally impractical, a slightly less accurate 123 blend of inverse transpose matrices is allowed as the 124 transformation. 125 126 When the less accurate blend is used, the normals will only 127 be identical to the normals formed by the more correct math 128 when the blending matrices are pair-wise orthogonal and 129 the sum of the square of the weights is equal to one. 130 131 Should weights be specified as vectors rather than independent 132 scalars? 133 134 Yes, this removes little flexibility and significantly 135 reduces the call overhead. 136 137 138New Procedures and Functions 139 140 void Weight{bsifd ubusui}vARB(int size, T* weights) 141 142 void WeightPointerARB(int size, enum type, sizei stride, 143 void *pointer) 144 145 void VertexBlendARB(int count) 146 147 148New Tokens 149 150 Accepted by the <value> parameters of GetBooleanv, GetIntegerv, 151 GetFloatv, and GetDoublev: 152 153 MAX_VERTEX_UNITS_ARB 0x86A4 154 ACTIVE_VERTEX_UNITS_ARB 0x86A5 155 156 Accepted by the <cap> parameters of Enable and Disable, by the 157 <value> parameter of IsEnabled, GetBooleanv, GetIntegerv, 158 GetFloatv, and GetDoublev: 159 160 WEIGHT_SUM_UNITY_ARB 0x86A6 161 VERTEX_BLEND_ARB 0x86A7 162 163 Accepted by the <mode> parameter of MatrixMode and by the 164 <value> parameter of GetBooleanv, GetIntegerv, GetFloatv, and 165 GetDoublev. 166 167 MODELVIEW0_ARB: 0x1700 (alias to MODELVIEW) 168 MODELVIEW1_ARB: 0x850a 169 MODELVIEW2_ARB: 0x8722 170 MODELVIEW3_ARB: 0x8723 171 MODELVIEW4_ARB: 0x8724 172 MODELVIEW5_ARB: 0x8725 173 MODELVIEW6_ARB: 0x8726 174 MODELVIEW7_ARB: 0x8727 175 MODELVIEW8_ARB: 0x8728 176 MODELVIEW9_ARB: 0x8729 177 MODELVIEW10_ARB: 0x872A 178 MODELVIEW11_ARB: 0x872B 179 MODELVIEW12_ARB: 0x872C 180 MODELVIEW13_ARB: 0x872D 181 MODELVIEW14_ARB: 0x872E 182 MODELVIEW15_ARB: 0x872F 183 MODELVIEW16_ARB: 0x8730 184 MODELVIEW17_ARB: 0x8731 185 MODELVIEW18_ARB: 0x8732 186 MODELVIEW19_ARB: 0x8733 187 MODELVIEW20_ARB: 0x8734 188 MODELVIEW21_ARB: 0x8735 189 MODELVIEW22_ARB: 0x8736 190 MODELVIEW23_ARB: 0x8737 191 MODELVIEW24_ARB: 0x8738 192 MODELVIEW25_ARB: 0x8739 193 MODELVIEW26_ARB: 0x873A 194 MODELVIEW27_ARB: 0x873B 195 MODELVIEW28_ARB: 0x873C 196 MODELVIEW29_ARB: 0x873D 197 MODELVIEW30_ARB: 0x873E 198 MODELVIEW31_ARB: 0x873F 199 200 Accepted by the <value> parameter of GetBooleanv, GetIntegerv, 201 GetFloatv, and GetDoublev: 202 203 CURRENT_WEIGHT_ARB 0x86A8 204 205 Accepted by the <value> parameter of GetBooleanv, GetIntegerv, 206 GetFloatv, and GetDoublev: 207 208 WEIGHT_ARRAY_TYPE_ARB 0x86A9 209 WEIGHT_ARRAY_STRIDE_ARB 0x86AA 210 WEIGHT_ARRAY_SIZE_ARB 0x86AB 211 212 Accepted by the <pname> parameter of GetPointerv: 213 WEIGHT_ARRAY_POINTER_ARB 0x86AC 214 215 Accepted by the <cap> parameters of EnableClientState and 216 DisableClientState, by the <value> parameter of IsEnabled, 217 GetBooleanv, GetIntegerv, GetFloatv, and GetDoublev: 218 219 WEIGHT_ARRAY_ARB 0x86AD 220 221Additions to Chapter 2 of the OpenGL 1.2.1 Specification (Operation) 222 223 - (2.6, p. 12) Second paragraph changed to: 224 225 "Each vertex is specified with two, three, or four 226 coordinates. In addition, a current normal, current texture 227 coordinates, current color, and a set of current weights 228 may be used in processing each vertex. Normals are used 229 by the GL in lighting calculations; the current normal is 230 a three-dimensional vector that may be set by sending three 231 coordinates that specify it. Texture coordinates determine 232 how a texture image is mapped onto a primitive. Weights are 233 used to blend between vertex transformations." 234 235 - (2.6.3, p. 19) First paragraph changed to: 236 237 "The only GL commands that are allowed within Begin/End 238 pairs are the commands for specifying vertex coordinates, 239 vertex color, normal coordinates, texture coordinates, and 240 weights (Vertex, Color, Index, Normal, TexCoord, 241 WeightvARB), the ArrayElement command (see section 2.8), 242 the EvalCoord and EvalPoint commands (see section 5.1), 243 commands for specifying lighting material parameters 244 (Material commands; see section 2.13.2), display list 245 invocation commands (CallList and CallLists; see section 246 5.4), and the EdgeFlag command. Executing any other GL 247 command between the execution of Begin and the 248 corresponding execution of End results in the error 249 INVALID_OPERATION. Executing Begin after Begin has already 250 been executed but before an End is executed generates the 251 INVALID_OPERATION error, as does executing End without a 252 previous corresponding Begin." 253 254 - (2.7, p. 20) Added after the third paragraph: 255 256 "The current weights are set using 257 258 void Weight{bsifd ubusui}vARB(int size, T* weights); 259 260 the floating point values are assigned to the current 261 weight vector. The first <size> current weights are 262 replaced with <weights> such that: 263 264 w[i] = <weights>[i] 265 266 When WEIGHT_SUM_UNITY_ARB is enabled, 267 268 <size>-1 269 w[<size>] = 1 - SUM <weights>[i] 270 i=0 271 272 otherwise the rest of the current weights are set to 273 0. If <size> is greater than MAX_VERTEX_UNITS_ARB or if 274 WEIGHT_SUM_UNITY_ARB is enabled and <size> equals 275 MAX_VERTEX_UNITS_ARB, then the error INVALID_VALUE is 276 generated. When the values are supplied as byte, short, 277 int, or their unsigned counterparts, they are converted to 278 floating-point values as indicated for the corresponding 279 type in Table 2.6." 280 281 - (2.8, p. 21) First paragraph changed to read: 282 283 "The vertex specification commands described in section 2.7 284 accept data in almost any format, but their use requires 285 many command executions to specify even simple geometry. 286 Vertex data may also be placed into arrays that are stored 287 in the client's address space. Blocks of data in these 288 arrays may then be used to specify multiple geometric 289 primitives through the execution of a single GL command. 290 The client may specify an implementation dependent set of 291 arrays: one each to store edge flags, texture coordinates, 292 colors, color indices, normals, vertices, and weights. 293 The commands 294 295 void EdgeFlagPointer( sizei stride, void *pointer); 296 297 void TexCoordPointer( int size, enum type, sizei stride, 298 void *pointer ); 299 300 void ColorPointer( int size, enum type, sizei stride, 301 void *pointer ); 302 303 void IndexPointer( enum type, sizei stride, void 304 *pointer ); 305 306 void NormalPointer( enum type, sizei stride, void 307 *pointer ); 308 309 void VertexPointer( int size, enum type, sizei stride, 310 void *pointer ); 311 312 void WeightPointerARB( int size, enum type, 313 sizei stride, void *pointer) 314 315 describe the locations and organizations of these arrays. 316 For each command, type specifies the data type of the 317 values stored in the array. Because edge flags are always 318 type boolean, EdgeFlagPointer has no type argument. Size, 319 when present, indicates the number of values per vertex 320 that are stored in the array. Because normals are always 321 specified with three values, NormalPointer has no size 322 argument. Likewise, because color indices, edge flags, and 323 weights are always specified with a single value, 324 IndexPointer, and EdgeFlagPointer also have no size 325 argument. Table 2.4 indicates the allowable values for size 326 and type (when present). For type the values BYTE, SHORT, 327 INT, FLOAT, and DOUBLE indicates types byte, short, int, 328 float, and double, respectively; and the values 329 UNSIGNED_BYTE, UNSIGNED_SHORT, and UNSIGNED_INT indicate 330 types ubyte, ushort, and uint, respectively. The error 331 INVALID_VALUE is generated if size is specified with 332 a value other than that indicated in the table, or if the 333 <size> parameter to WeightPointerARB is outside the range 334 allowed for WeightvARB in section 2.7." 335 336 - (2.8, p. 22) Change table 2.4 to read: 337 338 Command Sizes Types 339 ------- ----- ----- 340 VertexPointer 2,3,4 short, int, float, double 341 NormalPointer 3 byte, short, int, float, double 342 ColorPointer 3,4 byte, ubyte, short, ushort, 343 int, uint, float, double 344 IndexPointer 1 ubyte, short, int, float, 345 double 346 TexCoordPointer 1,2,3,4 short, int, float, double 347 EdgeFlagPointer 1 boolean 348 WeightPointerARB 1 ... byte, ubyte, short, ushort, 349 MAX_VERTEX_UNITS_ARB int, uint, float, double 350 351 352 - (2.8 p. 23) Change paragraph two to: 353 354 "An individual array is enabled or disabled by calling one 355 of 356 357 void EnableClientState( enum array ); 358 void DisableClientState( enum array ); 359 360 with array set to EDGE_FLAG_ARRAY, TEXTURE_COORD_ARRAY, 361 COLOR_ARRAY, INDEX_ARRAY, NORMAL_ARRAY, VERTEX_ARRAY, or 362 WEIGHT_ARRAY_ARB, for the edge flag, texture coordinate, 363 color, color index, normal, vertex, or weight array, 364 respectively." 365 366 - (2.8 p. 23) Change paragraph three to: 367 368 "The ith element of every enabled array is transferred to 369 the GL by calling 370 371 void ArrayElement( int i ); 372 373 For each enabled array, it is as though the corresponding 374 command form section 2.7 or 2.6.2 were called with a 375 pointer to element i. For the vertex array, the 376 corresponding command is Vertex[size][type]v, where size is 377 one of [2,3,4], and type is one of [s,i,f,d], corresponding 378 to array types short, int, float, and double respectively. 379 The corresponding commands for the edge flag, texture 380 coordinate, color, color index, normal, and weight arrays 381 are EdgeFlagv, TexCoord[size][type]v, Color[size][type]v, 382 Index[type]v, Normal[type]v, and Weight[type]vARB, 383 respectively. The <size> parameter to WeightvARB is the 384 current <size> for the weight array. If the vertex array 385 is enabled, it is as though Vertex[size][type]v is executed 386 last, after the executions of the other corresponding 387 commands." 388 389 - (2.10 p. 28) Added after the second paragraph: 390 391 "Alternatively, the model-view transformation may be 392 performed by a set of model-view matrices when vertex 393 blending is enabled. Enabling and disabling of vertex 394 blending is handled by Enable or Disable with the argument 395 of VERTEX_BLEND_ARB. When blending is enabled, the vertex 396 is transformed by multiple model-view transformations. 397 The number of active transformations applied is set by 398 399 void VertexBlendARB(int count) 400 401 where count is the number of transformations to blend. 402 If count is greater than the implementation defined 403 maximum number of transformations reported in 404 MAX_VERTEX_UNITS_ARB, then the error 405 INVALID_VALUE is generated." 406 407 - (2.10 p. 29) Add after the second paragraph: 408 409 "When vertex blending is enabled, the vertex's eye 410 coordinates are found as: 411 412 (xe) n-1 (xo) 413 (ye) = SUM w_i * M_i * (yo) 414 (ze) i=0 (zo) 415 (we) (wo) 416 417 where M_i is the i'th model-view matrix, w_i is the 418 vertex's associated weight for vertex unit i, 419 420 and 421 422 n = ACTIVE_VERTEX_UNITS_ARB 423 " 424 425 - (2.10.2 p. 31) Change the first paragraph to: 426 427 "The projection matrix and model-view matrices are set 428 with a variety of commands. The affected matrix is 429 determined by the current matrix mode. The current 430 matrix mode is set with 431 432 void MatrixMode( enum mode ); 433 434 which takes one of the pre-defined constants TEXTURE, 435 MODELVIEW, COLOR, PROJECTION, or MODELVIEWn_ARB. TEXTURE 436 is described later in section 2.10.2, and COLOR is 437 described in section 3.6.3. If the current matrix mode is 438 MODELVIEW, the matrix operations apply to the model-view 439 matrix; if PROJECTION, then they apply to the projection 440 matrix; if MODLEVIEWn_ARB, then they apply to the n'th 441 model-view matrix. MODELVIEW0_ARB is aliased to 442 MODELVIEW." 443 444 - (2.10.2 p. 34) Changed the second paragraph to read: 445 446 "There is a stack of matrices for each of the matrix 447 modes. For MODELVIEWn mode, the stack depth is at least 32 448 (that is, there is a stack of at least 32 MODELVIEWn 449 matrices). Additionally, all modelview matrices must 450 have the same stack depth. ..." 451 452 - (2.10.2 p. 34) Changed the third paragraph to read: 453 454 "... and a stack of at least 32 4 x 4 matrices with an 455 associated stack pointer for each MODELVIEWn. ..." 456 457 458 - (2.10.3 p. 35) Added after the third paragraph: 459 460 "When vertex blending is enabled, the normal is transformed 461 to eye space by: 462 463 n-1 464 (nx' ny' nz') = (nx ny nz) Inv ( SUM w_i * Mu_i) 465 i=0 466 467 Alternatively implementations may choose to transform the 468 normal to eye-space by: 469 470 n-1 471 (nx' ny' nz') = SUM w_i * (nx ny nz) Inv(Mu_i) 472 i=0 473 474 where Mu_i is the upper leftmost 3x3 matrix taken from the 475 model-view for vertex unit i, w_i is the vertex's 476 associated weight for vertex unit i, and 477 478 n = ACTIVE_VERTEX_UNITS_ARB" 479 480 481 - (2.10.3 p. 36) Added after the second paragraph: 482 483 "When vertex blending is enabled, rescaling is applied 484 within each vertex unit independently. The rescale factor 485 for each unit is derived from the modelview matrix for that 486 unit. Normalization is applied to the transformed, blended 487 normal." 488 489Additions to Chapter 3: 490 491 None 492 493Additions to Chapter 4: 494 495 None 496 497Additions to Chapter 5: 498 499 None 500 501Additions to Chapter 6: 502 503 None 504 505Additions to the GLX Specification 506 507 None 508 509GLX Protocol 510 511 Nine new GL rendering commandsl are added. The following commands 512 are sent to the server as part of a glXRender request: 513 514 WeightbvARB 515 516 2 8+n rendering command length 517 2 220 rendering command opcode 518 4 INT32 size 519 1*n INT8 weights 520 521 WeightubvARB 522 523 2 8+n rendering command length 524 2 221 rendering command opcode 525 4 INT32 size 526 1*n CARD8 weights 527 528 WeightsvARB 529 530 2 8+2*n rendering command length 531 2 222 rendering command opcode 532 4 INT32 size 533 2*n INT16 weights 534 535 WeightusvARB 536 537 2 8+2*n rendering command length 538 2 223 rendering command opcode 539 4 INT32 size 540 2*n CARD16 weights 541 542 WeightivARB 543 544 2 8+4*n rendering command length 545 2 224 rendering command opcode 546 4 INT32 size 547 4*n INT32 weights 548 549 WeightuivARB 550 551 2 8+4*n rendering command length 552 2 225 rendering command opcode 553 4 INT32 size 554 4*n CARD32 weights 555 556 VertexBlendARB 557 558 2 8 rendering command length 559 2 226 rendering command opcode 560 4 INT32 count 561 562 WeightfvARB 563 564 2 8+4*n rendering command length 565 2 227 rendering command opcode 566 4 INT32 size 567 4*n FLOAT32 weights 568 569 WeightdvARB 570 571 2 8+8*n rendering command length 572 2 228 rendering command opcode 573 4 INT32 size 574 8*n FLOAT64 weights 575 576Errors 577 578 INVALID_VALUE is generated if the <size> parameter for 579 WeightvARB or WeightPointerARB is greater than 580 MAX_VERTEX_UNITS_ARB, or if WEIGHT_SUM_UNITY_ARB is enabled 581 and <size> is equal to MAX_VERTEX_UNITS_ARB 582 583 INVALID_VALUE is generated if the <count> parameter to 584 VertexBlendARB is greater than MAX_VERTEX_UNITS_ARB or 585 if <count> is equal to zero. 586 587New State 588 589 Modified State in Table 6.5: 590 591Get Value Get Command Type Initial Value Attribute 592--------- ----------- ---- ------------- --------- 593CURRENT_WEIGHT_ARB GetFloatv Rn n=0 - 1.0 current 594 n>0 - 0.0 595 596 Modified State in Table 6.6: 597 598Get Value Get Command Type Initial Value Attribute 599--------- ----------- ---- ------------- --------- 600WEIGHT_ARRAY_ARB IsEnabled 1*B False vert-array 601WEIGHT_ARRAY_TYPE_ARB GetIntegerv 1*Z2 FLOAT vert-array 602WEIGHT_ARRAY_SIZE_ARB GetIntegerv 1*Z+ 0 vert-array 603WEIGHT_ARRAY_STRIDE_ARB GetIntegerv 1*Z+ 0 vert-array 604WEIGHT_ARRAY_POINTER_ARB GetPointerv 1*Y 0 vert-array 605 606 607 Modified state in Table 6.7: 608 609Get Value Get Command Type Initial Value Attribute 610--------- ----------- ---- ------------- --------- 611MODELVIEWn_ARB GetFloatv 1*32*xM4 Identity - 612ACTIVE_VERTEX_UNITS_ARB GetIntegerv Z+ 1 transform 613VERTEX_BLEND_ARB IsEnabled B False transform 614 enable 615 616 Modified state in Table 6.25: 617 618Get Value Get Command Type Minmum Value Attribute 619--------- ----------- ---- ------------ --------- 620MAX_VERTEX_UNITS_ARB GetIntegerv Z+ 2 - 621 622Additions to Appendix A: 623 624 None 625 626Revision History 627 628 * 1.0 (October 16, 2000) - initial version 629 630 * 1.1 (March 12, 2002) - added GLX protocol for Weight[df]v 631 632 * 1.2 (March 21, 2002) - correct Weightdv protocol 633 634 * 1.3 (November 4, 2006) - updated contact info after ATI/AMD merger 635