1Name 2 3 ARB_texture_compression_rgtc 4 5Name Strings 6 7 GL_ARB_texture_compression_rgtc 8 9Contributors 10 11 Mark J. Kilgard, NVIDIA 12 Pat Brown, NVIDIA 13 Yanjun Zhang, S3 14 Attila Barsi, Holografika 15 16Contact 17 18 Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) 19 20Notice 21 22 Copyright (c) 2008-2013 The Khronos Group Inc. Copyright terms at 23 http://www.khronos.org/registry/speccopyright.html 24 25Specification Update Policy 26 27 Khronos-approved extension specifications are updated in response to 28 issues and bugs prioritized by the Khronos OpenGL Working Group. For 29 extensions which have been promoted to a core Specification, fixes will 30 first appear in the latest version of that core Specification, and will 31 eventually be backported to the extension document. This policy is 32 described in more detail at 33 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 34 35Status 36 37 Approved by the ARB on July 11, 2008 38 39Version 40 41 Last Modified Date: January 27, 2015 42 Revision: 1.7 43 44Number 45 46 ARB Extension #52 47 48Dependencies 49 50 OpenGL 1.3 or ARB_texture_compression required 51 52 This extension is written against the OpenGL 2.0 (September 7, 53 2004) specification. 54 55 This extension interacts with OpenGL 2.0 and ARB_texture_non_power_of_two. 56 57Overview 58 59 This extension introduces four new block-based texture compression 60 formats suited for unsigned and signed red and red-green textures 61 (hence the name "rgtc" for Red-Green Texture Compression). 62 63 These formats are designed to reduce the storage requirements 64 and memory bandwidth required for red and red-green textures by 65 a factor of 2-to-1 over conventional uncompressed luminance and 66 luminance-alpha textures with 8-bit components (GL_LUMINANCE8 and 67 GL_LUMINANCE8_ALPHA8). 68 69 The compressed signed red-green format is reasonably suited for 70 storing compressed normal maps. 71 72 This extension uses the same compression format as the 73 EXT_texture_compression_latc extension except the color data is stored 74 in the red and green components rather than luminance and alpha. 75 Representing compressed red and green components is consistent with 76 the BC4 and BC5 compressed formats supported by DirectX 10. 77 78New Procedures and Functions 79 80 None. 81 82New Tokens 83 84 Accepted by the <internalformat> parameter of TexImage2D, 85 CopyTexImage2D, and CompressedTexImage2D and the <format> parameter 86 of CompressedTexSubImage2D: 87 88 COMPRESSED_RED_RGTC1 0x8DBB 89 COMPRESSED_SIGNED_RED_RGTC1 0x8DBC 90 COMPRESSED_RG_RGTC2 0x8DBD 91 COMPRESSED_SIGNED_RG_RGTC2 0x8DBE 92 93Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation) 94 95 None. 96 97Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) 98 99 -- Section 3.8.1, Texture Image Specification 100 101 Add to Table 3.17 (page 155): Specific compressed internal formats 102 103 Compressed Internal Format Base Internal Format 104 --------------------------------- -------------------- 105 COMPRESSED_RED_RGTC1 RED 106 COMPRESSED_SIGNED_RED_RGTC1 RED 107 COMPRESSED_RG_RGTC2 RG 108 COMPRESSED_SIGNED_RG_RGTC2 RG 109 110 -- Section 3.8.2, Alternative Texture Image Specification Commands 111 112 Add to the end of the section (page 163): 113 114 "If the internal format of the texture image 115 being modified is COMPRESSED_RED_RGTC1, 116 COMPRESSED_SIGNED_RED_RGTC1, COMPRESSED_RG_RGTC2, 117 or COMPRESSED_SIGNED_RG_RGTC2, the texture is stored 118 using one of the two RGTC compressed texture image encodings (see 119 appendix). Such images are easily edited along 4x4 texel boundaries, 120 so the limitations on TexSubImage2D or CopyTexSubImage2D parameters 121 are relaxed. TexSubImage2D and CopyTexSubImage2D will result in 122 an INVALID_OPERATION error only if one of the following conditions 123 occurs: 124 125 * <width> is not a multiple of four, <width> plus <xoffset> is not 126 equal to TEXTURE_WIDTH, and either <xoffset> or <yoffset> is 127 non-zero; 128 129 * <height> is not a multiple of four, <height> plus <yoffset> is not 130 equal to TEXTURE_HEIGHT, and either <xoffset> or <yoffset> is 131 non-zero; or 132 133 * <xoffset> or <yoffset> is not a multiple of four. 134 135 The contents of any 4x4 block of texels of an RGTC compressed texture 136 image that does not intersect the area being modified are preserved 137 during valid TexSubImage2D and CopyTexSubImage2D calls." 138 139 -- Section 3.8.3, Compressed Texture Images 140 141 Add after the 4th paragraph (page 164) at the end of the 142 CompressedTexImage discussion: 143 144 "If <internalformat> is COMPRESSED_RED_RGTC1, 145 COMPRESSED_SIGNED_RED_RGTC1, COMPRESSED_RG_RGTC2, 146 or COMPRESSED_SIGNED_RG_RGTC2, the compressed texture is 147 stored using one of several RGTC compressed texture image formats. 148 The RGTC texture compression algorithm supports only 2D images 149 without borders. CompressedTexImage1D and CompressedTexImage3D 150 produce an INVALID_ENUM error if <internalformat> is an RGTC format. 151 CompressedTexImage2D will produce an INVALID_OPERATION error if 152 <border> is non-zero. 153 154 Add to the end of the section (page 166) at the end of the 155 CompressedTexSubImage discussion: 156 157 "If the internal format of the texture image 158 being modified is COMPRESSED_RED_RGTC1, 159 COMPRESSED_SIGNED_RED_RGTC1, COMPRESSED_RG_RGTC2, 160 or COMPRESSED_SIGNED_RG_RGTC2, the texture is stored 161 using one of the several RGTC compressed texture image formats. 162 Since the RGTC texture compression algorithm supports only 2D images, 163 CompressedTexSubImage1D and CompressedTexSubImage3D produce an 164 INVALID_ENUM error if <format> is an RGTC format. Since RGTC images 165 are easily edited along 4x4 texel boundaries, the limitations on 166 CompressedTexSubImage2D are relaxed. CompressedTexSubImage2D will 167 result in an INVALID_OPERATION error only if one of the following 168 conditions occurs: 169 170 * <width> is not a multiple of four, and <width> plus <xoffset> is not 171 equal to TEXTURE_WIDTH; 172 173 * <height> is not a multiple of four, and <height> plus <yoffset> is 174 not equal to TEXTURE_HEIGHT; or 175 176 * <xoffset> or <yoffset> is not a multiple of four. 177 178 The contents of any 4x4 block of texels of an RGTC compressed texture 179 image that does not intersect the area being modified are preserved 180 during valid TexSubImage2D and CopyTexSubImage2D calls." 181 182 -- Section 3.8.8, Texture Minification 183 184 Add a sentence to the last paragraph (page 174) just prior to the 185 "Mipmapping" subheading: 186 187 "If the texture's internal format lacks components that exist in 188 the texture's base internal format, such components are considered 189 zero when the texture border color is sampled. (So despite the 190 RGB base internal format of the COMPRESSED_RED_RGTC1 and 191 COMPRESSED_SIGNED_RED_RGTC1 formats, the green and blue 192 components of the texture border color are always considered 193 zero. Likewise for the COMPRESSED_RG_RGTC2, and 194 COMPRESSED_SIGNED_RG_RGTC2 formats, the blue component 195 is always considered zero.)" 196 197Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment 198Operations and the Frame Buffer) 199 200 None. 201 202Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) 203 204 None. 205 206Additions to Chapter 6 of the OpenGL 2.0 Specification (State and 207State Requests) 208 209 None. 210 211Additions to Appendix A of the OpenGL 2.0 Specification (Invariance) 212 213 None. 214 215Additions to the AGL/GLX/WGL Specifications 216 217 None. 218 219GLX Protocol 220 221 None. 222 223Dependencies on ARB_texture_compression 224 225 If ARB_texture_compression is supported, all the 226 errors and accepted tokens for CompressedTexImage1D, 227 CompressedTexImage2D, CompressedTexImage3D, CompressedTexSubImage1D, 228 CompressedTexSubImage2D, and CompressedTexSubImage3D also apply 229 respectively to the ARB-suffixed CompressedTexImage1DARB, 230 CompressedTexImage2DARB, CompressedTexImage3DARB, 231 CompressedTexSubImage1DARB, CompressedTexSubImage2DARB, and 232 CompressedTexSubImage3DARB. 233 234Dependencies on OpenGL 2.0 or ARB_texture_non_power_of_two 235 236 If OpenGL 2.0 or ARB_texture_non_power_of_two is supported, compressed 237 texture images can have sizes that are neither multiples of four nor small 238 values like one or two. The original version of this specification didn't 239 allow TexSubImage2D and CompressedTexSubImage2D to update only a portion 240 of such images. The spec has been updated to allow such edits in the 241 spirit of the resolution of issue (3) of the EXT_texture_compression_s3tc 242 specification. See the "Implementation Note" section for more details. 243 244Errors 245 246 INVALID_ENUM is generated by CompressedTexImage1D 247 or CompressedTexImage3D if <internalformat> is 248 COMPRESSED_RED_RGTC1, COMPRESSED_SIGNED_RED_RGTC1, 249 COMPRESSED_RG_RGTC2, or 250 COMPRESSED_SIGNED_RG_RGTC2. 251 252 INVALID_OPERATION is generated by CompressedTexImage2D 253 if <internalformat> is COMPRESSED_RED_RGTC1, 254 COMPRESSED_SIGNED_RED_RGTC1, COMPRESSED_RG_RGTC2, 255 or COMPRESSED_SIGNED_RG_RGTC2 and <border> is not equal 256 to zero. 257 258 INVALID_ENUM is generated by CompressedTexSubImage1D 259 or CompressedTexSubImage3D if 260 <format> is COMPRESSED_RED_RGTC1, 261 COMPRESSED_SIGNED_RED_RGTC1, COMPRESSED_RG_RGTC2, 262 or COMPRESSED_SIGNED_RG_RGTC2. 263 264 INVALID_OPERATION is generated by TexSubImage2D or CopyTexSubImage2D if 265 TEXTURE_INTERNAL_FORMAT is COMPRESSED_RED_RGTC1, 266 COMPRESSED_SIGNED_RED_RGTC1, COMPRESSED_RG_RGTC2, or 267 COMPRESSED_SIGNED_RG_RGTC2 and any of the following apply: 268 269 * <width> is not a multiple of four, <width> plus <xoffset> is not 270 equal to TEXTURE_WIDTH, and either <xoffset> or <yoffset> is 271 non-zero; 272 273 * <height> is not a multiple of four, <height> plus <yoffset> is not 274 equal to TEXTURE_HEIGHT, and either <xoffset> or <yoffset> is 275 non-zero; or 276 277 * <xoffset> or <yoffset> is not a multiple of four. 278 279 INVALID_OPERATION is generated by CompressedTexSubImage2D if 280 TEXTURE_INTERNAL_FORMAT is COMPRESSED_RED_RGTC1, 281 COMPRESSED_SIGNED_RED_RGTC1, COMPRESSED_RG_RGTC2, or 282 COMPRESSED_SIGNED_RG_RGTC2 and any of the following apply: 283 284 * <width> is not a multiple of four, and <width> plus <xoffset> is not 285 equal to TEXTURE_WIDTH; 286 287 * <height> is not a multiple of four, and <height> plus <yoffset> is 288 not equal to TEXTURE_HEIGHT; or 289 290 * <xoffset> or <yoffset> is not a multiple of four. 291 292 The following restrictions from the ARB_texture_compression 293 specification do not apply to RGTC texture formats, since subimage 294 modification is straightforward as long as the subimage is properly 295 aligned. 296 297 DELETE: INVALID_OPERATION is generated by TexSubImage1D, TexSubImage2D, 298 DELETE: TexSubImage3D, CopyTexSubImage1D, CopyTexSubImage2D, or 299 DELETE: CopyTexSubImage3D if the internal format of the texture image is 300 DELETE: compressed and <xoffset>, <yoffset>, or <zoffset> does not equal 301 DELETE: -b, where b is value of TEXTURE_BORDER. 302 303 DELETE: INVALID_VALUE is generated by CompressedTexSubImage1D, 304 DELETE: CompressedTexSubImage2D, or CompressedTexSubImage3D if the 305 DELETE: entire texture image is not being edited: if <xoffset>, 306 DELETE: <yoffset>, or <zoffset> is greater than -b, <xoffset> + <width> is 307 DELETE: less than w+b, <yoffset> + <height> is less than h+b, or <zoffset> 308 DELETE: + <depth> is less than d+b, where b is the value of 309 DELETE: TEXTURE_BORDER, w is the value of TEXTURE_WIDTH, h is the value of 310 DELETE: TEXTURE_HEIGHT, and d is the value of TEXTURE_DEPTH. 311 312 See also errors in the GL_ARB_texture_compression specification. 313 314New State 315 316 4 new state values are added for the per-texture object 317 GL_TEXTURE_INTERNAL_FORMAT state. 318 319 In the "Textures" state table( page 278), increment the 320 TEXTURE_INTERNAL_FORMAT subscript for Z by 4 in the "Type" row. 321 322 [NOTE: The OpenGL 2.0 specification actually should read "n x Z48*" 323 because of the 6 generic compressed internal formats in table 3.18.] 324 325New Implementation Dependent State 326 327 None 328 329Appendix 330 331 RGTC Compressed Texture Image Formats 332 333 Compressed texture images stored using the RGTC compressed image 334 encodings are represented as a collection of 4x4 texel blocks, 335 where each block contains 64 or 128 bits of texel data. The image 336 is encoded as a normal 2D raster image in which each 4x4 block is 337 treated as a single pixel. If an RGTC image has a width or height 338 that is not a multiple of four, the data corresponding to texels 339 outside the image are irrelevant and undefined. 340 341 When an RGTC image with a width of <w>, height of <h>, and block 342 size of <blocksize> (8 or 16 bytes) is decoded, the corresponding 343 image size (in bytes) is: 344 345 ceil(<w>/4) * ceil(<h>/4) * blocksize. 346 347 When decoding an RGTC image, the block containing the texel at offset 348 (<x>, <y>) begins at an offset (in bytes) relative to the base of the 349 image of: 350 351 blocksize * (ceil(<w>/4) * floor(<y>/4) + floor(<x>/4)). 352 353 The data corresponding to a specific texel (<x>, <y>) are extracted 354 from a 4x4 texel block using a relative (x,y) value of 355 356 (<x> modulo 4, <y> modulo 4). 357 358 There are four distinct RGTC image formats: 359 360 361 COMPRESSED_RED_RGTC1: Each 4x4 block of texels consists of 362 64 bits of unsigned red image data. 363 364 Each red image data block is encoded as a sequence of 8 bytes, called 365 (in order of increasing address): 366 367 red0, red1, bits_0, bits_1, bits_2, bits_3, bits_4, bits_5 368 369 The 6 "bits_*" bytes of the block are decoded into a 48-bit bit 370 vector: 371 372 bits = bits_0 + 373 256 * (bits_1 + 374 256 * (bits_2 + 375 256 * (bits_3 + 376 256 * (bits_4 + 377 256 * bits_5)))) 378 379 red0 and red1 are 8-bit unsigned integers that are unpacked to red 380 values RED0 and RED1 as though they were pixels with a <format> 381 of LUMINANCE and a type of UNSIGNED_BTYE. 382 383 bits is a 48-bit unsigned integer, from which a three-bit control 384 code is extracted for a texel at location (x,y) in the block 385 using: 386 387 code(x,y) = bits[3*(4*y+x)+2..3*(4*y+x)+0] 388 389 where bit 47 is the most significant and bit 0 is the least 390 significant bit. 391 392 The red value R for a texel at location (x,y) in the block is 393 given by: 394 395 RED0, if red0 > red1 and code(x,y) == 0 396 RED1, if red0 > red1 and code(x,y) == 1 397 (6*RED0+ RED1)/7, if red0 > red1 and code(x,y) == 2 398 (5*RED0+2*RED1)/7, if red0 > red1 and code(x,y) == 3 399 (4*RED0+3*RED1)/7, if red0 > red1 and code(x,y) == 4 400 (3*RED0+4*RED1)/7, if red0 > red1 and code(x,y) == 5 401 (2*RED0+5*RED1)/7, if red0 > red1 and code(x,y) == 6 402 ( RED0+6*RED1)/7, if red0 > red1 and code(x,y) == 7 403 404 RED0, if red0 <= red1 and code(x,y) == 0 405 RED1, if red0 <= red1 and code(x,y) == 1 406 (4*RED0+ RED1)/5, if red0 <= red1 and code(x,y) == 2 407 (3*RED0+2*RED1)/5, if red0 <= red1 and code(x,y) == 3 408 (2*RED0+3*RED1)/5, if red0 <= red1 and code(x,y) == 4 409 ( RED0+4*RED1)/5, if red0 <= red1 and code(x,y) == 5 410 MINRED, if red0 <= red1 and code(x,y) == 6 411 MAXRED, if red0 <= red1 and code(x,y) == 7 412 413 MINRED and MAXRED are 0.0 and 1.0 respectively. 414 415 Since the decoded texel has a red format, the resulting RGBA value 416 for the texel is (R,0,0,1). 417 418 419 COMPRESSED_SIGNED_RED_RGTC1: Each 4x4 block of texels consists of 420 64 bits of signed red image data. The red values of a texel are 421 extracted in the same way as COMPRESSED_RED_RGTC1 except red0, red1, 422 RED0, RED1, MINRED, and MAXRED are signed values defined as follows: 423 424 red0 and red1 are 8-bit signed (two's complement) integers. 425 426 { red0 / 127.0, red0 > -128 427 RED0 = { 428 { -1.0, red0 == -128 429 430 { red1 / 127.0, red1 > -128 431 RED1 = { 432 { -1.0, red1 == -128 433 434 MINRED = -1.0 435 436 MAXRED = 1.0 437 438 CAVEAT for signed red0 and red1 values: the expressions "red0 > 439 red1" and "red0 <= red1" above are considered undefined (read: may 440 vary by implementation) when red0 equals -127 and red1 equals -128, 441 This is because if red0 were remapped to -127 prior to the comparison 442 to reduce the latency of a hardware decompressor, the expressions 443 would reverse their logic. Encoders for the signed LA formats should 444 avoid encoding blocks where red0 equals -127 and red1 equals -128. 445 446 447 COMPRESSED_RG_RGTC2: Each 4x4 block of texels consists of 448 64 bits of compressed unsigned red image data followed by 64 bits 449 of compressed unsigned green image data. 450 451 The first 64 bits of compressed red are decoded exactly like 452 COMPRESSED_RED_RGTC1 above. 453 454 The second 64 bits of compressed green are decoded exactly like 455 COMPRESSED_RED_RGTC1 above except the decoded value R for this 456 second block is considered the resulting green value G. 457 458 Since the decoded texel has a red-green format, the resulting RGBA 459 value for the texel is (R,G,0,1). 460 461 462 COMPRESSED_SIGNED_RG_RGTC2: Each 4x4 block of texels consists 463 of 64 bits of compressed signed red image data followed by 64 bits 464 of compressed signed green image data. 465 466 The first 64 bits of compressed red are decoded exactly like 467 COMPRESSED_SIGNED_RED_RGTC1 above. 468 469 The second 64 bits of compressed green are decoded exactly like 470 COMPRESSED_SIGNED_RED_RGTC1 above except the decoded value R 471 for this second block is considered the resulting green value G. 472 473 Since this image has a red-green format, the resulting RGBA value is 474 (R,G,0,1). 475 476Issues 477 478 1) What should these new formats be called? 479 480 RESOLVED: "rgtc" for Red-Green Texture Compression. 481 482 2) How should the uncompressed and filtered texels be returned by 483 texture fetches? 484 485 RESOLVED: Red values show up as (R,0,0,1) where R is the red 486 value, green and blue are forced to 0, and alpha is forced to 1. 487 Likewise, red-green values show up as (R,G,0,1) where G is the 488 green value. 489 490 Prior extensions such as NV_float_buffer and NV_texture_shader 491 have introduced formats such as GL_FLOAT_R_NV and GL_DSDT_NV where 492 one- and two-component texture formats show up as (X,0,0,1) or 493 (X,Y,0,1) RGBA texels. The RGTC formats mimic these two-component 494 formats. 495 496 The (X,Y,0,1) convention, particularly with signed components, 497 is nice for normal maps because a normalized vector can be 498 formed by a shader program by computing sqrt(abs(1-X*X-Y*Y)) 499 for the Z component. 500 501 While GL_RED is a valid external format, core OpenGL provides 502 no GL_RG external format. Applications can either use 503 GL_RGB or GL_RGBA and pad out the blue and alpha components, 504 or use the two-component GL_LUMINANCE_ALPHA color format and 505 use the color matrix functionality to swizzle the luminance and 506 alpha values into red and green respectively. 507 508 3) Should red and red-green compression formats with signed 509 components be introduced when the core specification lacked 510 uncompressed red and red-green texture formats? 511 512 RESOLVED: Yes, signed red and red-green compression formats 513 should be added. 514 515 Signed red-green formats are suited for compressed normal maps. 516 Compressed normal maps may well be the dominant use of this 517 extension. 518 519 Unsigned red-green formats require an extra "expand normal" 520 operation to convert [0,1] to [-1,+1]. Direct support for signed 521 red-green formats avoids this step in a shader program. 522 523 4) Should there be a mix of signed red and unsigned green or 524 vice versa? 525 526 RESOLVED: No. 527 528 NV_texture_shader provided an internal format 529 (GL_SIGNED_RGB_UNSIGNED_ALPHA_NV) with mixed signed and unsigned 530 components. The format saw little usage. There's no reason to 531 think a GL_SIGNED_RED_UNSIGNED_GREEN format would be any more 532 useful or popular. 533 534 5) How are signed integer values mapped to floating-point values? 535 536 RESOLVED: A signed 8-bit two's complement value X is computed to 537 a floating-point value Xf with the formula: 538 539 { X / 127.0, X > -128 540 Xf = { 541 { -1.0, X == -128 542 543 This conversion means -1, 0, and +1 are all exactly representable, 544 however -128 and -127 both map to -1.0. Mapping -128 to -1.0 545 avoids the numerical awkwardness of have a representable value 546 slightly more negative than -1.0. 547 548 This conversion is intentionally NOT the "byte" conversion listed 549 in Table 2.9 for component conversions. That conversion says: 550 551 Xf = (2*X + 1) / 255.0 552 553 The Table 2.9 conversion is incapable of exactly representing 554 zero. 555 556 6) How will signed components resulting 557 from GL_COMPRESSED_SIGNED_RED_RGTC1 and 558 GL_COMPRESSED_SIGNED_RG_RGTC2 texture fetches interact 559 with fragment coloring? 560 561 RESOLVED: The specification language for this extension is silent 562 about clamping behavior leaving this to the core specification 563 and other extensions. The clamping or lack of clamping is left 564 to the core specification and other extensions. 565 566 For assembly program extensions supporting texture fetches 567 (ARB_fragment_program, NV_fragment_program, NV_vertex_program3, 568 etc.) or the OpenGL Shading Language, these signed formats will 569 appear as expected with unclamped signed components as a result 570 of a texture fetch instruction. 571 572 If ARB_color_buffer_float is supported, its clamping controls 573 will apply. 574 575 NV_texture_shader extension, if supported, adds support for 576 fixed-point textures with signed components and relaxed the 577 fixed-function texture environment clamping appropriately. If the 578 NV_texture_shader extension is supported, its specified behavior 579 for the texture environment applies where intermediate values 580 are clamped to [-1,1] unless stated otherwise as in the case 581 of explicitly clamped to [0,1] for GL_COMBINE. or clamping the 582 linear interpolation weight to [0,1] for GL_DECAL and GL_BLEND. 583 584 Otherwise, the conventional core texture environment clamps 585 incoming, intermediate, and output color components to [0,1]. 586 587 This implies that the conventional texture environment 588 functionality of unextended OpenGL 1.5 or OpenGL 2.0 without 589 using GLSL (and with none of the extensions referred to above) 590 is unable to make proper use of the signed texture formats added 591 by this extension because the conventional texture environment 592 requires texture source colors to be clamped to [0,1]. Texture 593 filtering of these signed formats would be still signed, but 594 negative values generated post-filtering would be clamped to 595 zero by the core texture environment functionality. The 596 expectation is clearly that this extension would be co-implemented 597 with one of the previously referred to extensions or used with 598 GLSL for the new signed formats to be useful. 599 600 7) Should a specific normal map compression format be added? 601 602 RESOLVED: No. 603 604 It's probably short-sighted to design a format just for normal 605 maps. Indeed, NV_texture_shader added a GL_SIGNED_HILO_NV 606 format with exactly the kind of "hemisphere remap" useful for 607 normal maps and the format went basically unused. Instead, 608 this extension provides the mechanism for compressed normal maps 609 based on the more conventional red-green format. 610 611 The GL_COMPRESSED_RG_RGTC2 and 612 GL_COMPRESSED_SIGNED_RG_RGTC2 formats are sufficient 613 for normal maps with additional shader instructions used to 614 generate the 3rd component. 615 616 8) Should uncompressed signed red and red-green formats be added 617 by this extension? 618 619 RESOLVED: No, this extension is focused on just adding compressed 620 texture formats. 621 622 The NV_texture_shader extension adds such uncompressed signed 623 texture formats. A distinct multi-vendor extension for signed 624 fixed-point texture formats could provide all or a subset of 625 the signed fixed-point uncompressed texture formats introduced 626 by NV_texture_shader. 627 628 9) What compression ratios does this extension provide? 629 630 The RGTC1 formats are 8 bytes (64 bits) per 4x4 pixel block. 631 A 4x4 block of GL_LUMINANCE8 data requires 16 bytes (1 byte 632 per texel). This is a 2-to-1 compression ratio. 633 634 The RGTC2 formats are 16 bytes (128 bits) per 4x4 pixel block. 635 A 4x4 block of GL_LUMINANCE8_ALPHA8 data requires 32 bytes 636 (2 bytes per texel). This is again a 2-to-1 compression ratio. 637 638 In contrast, the comparable compression ratio for the S3TC 639 formats is 4-to-1. 640 641 Arguably, the lower compression ratio allows better compression 642 quality particularly because the RGTC formats compress each 643 component separately. 644 645 10) How do these new formats compare with the existing GL_LUMINANCE4, 646 GL_LUMINANCE4_ALPHA4, and GL_LUMINANCE6_ALPHA2 internal formats? 647 648 RESOLVED: The existing GL_LUMINANCE4, GL_LUMINANCE4_ALPHA4, 649 and GL_LUMINANCE6_ALPHA2 internal formats provide a similar 650 2-to-1 compression ratio but mandate a uniform quantization 651 for all components. In contrast, this extension provides a 652 compression format with 3-bit quantization over a specifiable 653 min/max range that can vary per 4x4 texel tile. 654 655 Additionally, many OpenGL implementations do not natively support 656 the GL_LUMINANCE4, GL_LUMINANCE4_ALPHA4, and GL_LUMINANCE6_ALPHA2 657 internal formats but rather silently promote these formats 658 to store 8 bits per component, thereby eliminating any 659 storage/bandwidth advantage for these formats. 660 661 11) Does this extension require EXT_texture_compression_s3tc? 662 663 RESOLVED: No. 664 665 As written, this specification does not rely on wording of the 666 EXT_texture_compression_s3tc extension. For example, certain 667 discussion added to Sections 3.8.2 and 3.8.3 is quite similar 668 to corresponding EXT_texture_compression_s3tc language. 669 670 12) Should anything be said about the precision of texture filtering 671 for these new formats? 672 673 RESOLVED: No precision requirements are part of the specification 674 language since OpenGL extensions typically leave precision 675 details to the implementation. 676 677 Realistically, at least 8-bit filtering precision can be expected 678 from implementations (and probably more). 679 680 13) Should these formats be allowed to specify 3D texture images 681 when NV_texture_compression_vtc is supported? 682 683 RESOLVED: The NV_texture_compression_vtc stacks 4x4 blocks into 684 4x4x4 bricks. It may be more desirable to represent compressed 685 3D textures as simply slices of 4x4 blocks. 686 687 However the NV_texture_compression_vtc extension expects data 688 passed to the glCompressedTexImage commands to be "bricked" 689 rather than blocked slices. 690 691 14) How is the texture border color handled for the blue component 692 of an RGTC2 texture and the green and blue components of an 693 RGTC1 texture? 694 695 RESOLVED: The base texture format is RGB for the RGTC1 and 696 RGTC2 texture formats. This would mean table 3.15 would be 697 used to determine how the texture border color is interpreted 698 and which components are considered. 699 700 However since only red or red/green components exist for the 701 RGTC1 and RGTC2 formats, it makes little sense to require 702 the blue component be supplied by the texture border color and 703 hence be involved (meaningfully only when the border is sampled) 704 in texture filtering. 705 706 For this reason, a statement is added to section 3.8.8 says that 707 if a texture's internal format lacks components that exist in 708 the texture's base internal format, such components contain 709 zero (ignoring the texture's corresponding texture border color 710 component value) when the texture border color is sampled. 711 712 So the green and blue components of the filtered result of a 713 RGTC1 texture are always zero, even when the border is sampled. 714 Similarly the blue component of the filtered result of a RGTC2 715 texture is always zero, even when the border is sampled. 716 717 15) What should glGetTexLevelParameter return for 718 GL_TEXTURE_GREEN_SIZE and GL_TEXTURE_BLUE_SIZE for the RGTC1 719 formats? What should glGetTexLevelParameter return for 720 GL_TEXTURE_BLUE_SIZE for the RGTC2 formats? 721 722 RESOLVED: Zero bits. 723 724 These formats always return 0.0 for these respective components 725 and have no bits devoted to these components. 726 727 Returning 8 bits for red size of RGTC1 and the red and green 728 sizes of RGTC2 makes sense because that's the maximum potential 729 precision for the uncompressed texels. 730 731 16) Should the token names contain R and RG or RED and RED_GREEN? 732 733 RESOLVED: RED and RG. See issue #3 in the ARB_texture_rg 734 specification. 735 736 17) Can you use the GL_RED external format with glTexImage2D and other 737 such commands to load textures with the 738 GL_COMPRESSED_RED_RGTC1 or GL_COMPRESSED_SIGNED_RED_RGTC1 739 internal formats? 740 741 RESOLVED: Yes. 742 743 GL_RED has been a valid external format parameter to glTexImage 744 and similar commands since OpenGL 1.0. 745 746 18) Should any of the generic compression GL_COMPRESSED_* tokens in 747 OpenGL 2.1 map to RGTC formats? 748 749 RESOLVED: No. The RGTC formats are missing color components 750 so are not adequate implementations for any of the generic 751 compression formats. 752 753 19) Should the GL_NUM_COMPRESSED_TEXTURE_FORMATS and 754 GL_COMPRESSED_TEXTURE_FORMATS queries return the RGTC formats? 755 756 RESOLVED: No. 757 758 The OpenGL 2.1 specification says "The only values returned 759 by this query [GL_COMPRESSED_TEXTURE_FORMATS"] are those 760 corresponding to formats suitable for general-purpose usage. 761 The renderer will not enumerate formats with restrictions that 762 need to be specifically understood prior to use." 763 764 Compressed textures with just red or red-green components are 765 not general-purpose so should not be returned by these queries 766 because they have restrictions. 767 768 Applications that seek to use the RGTC formats should do so 769 by looking for this extension's name in the string returned by 770 glGetString(GL_EXTENSIONS) rather than 771 what GL_NUM_COMPRESSED_TEXTURE_FORMATS and 772 GL_COMPRESSED_TEXTURE_FORMATS return. 773 774 20) Why don't the new tokens and entry points in this extension have 775 "ARB" suffixes like other ARB extensions? 776 777 RESOLVED: Unlike most ARB extensions, this is a strict subset 778 of functionality already approved in OpenGL 3.0. This extension 779 exists only to support that functionality on older hardware that 780 cannot implement a full OpenGL 3.0 driver. Since there are no 781 possible behavior changes between the ARB extension and core 782 features, source code compatibility is improved by not using 783 suffixes on the extension. 784 785Implementation Note 786 787 This extension allows TexSubImage2D and CompressedTexSubImage2D to perform 788 partial updates to compressed images, but generally requires that the 789 updated area be aligned to 4x4 block boundaries. If the width or height 790 is not a multiple of four, there will be 4x4 blocks at the edge of the 791 image that contain "extra" texels that are not part of the image. This 792 spec has an exception allowing edits that partially cover such blocks as 793 long as the edit covers all texels in the block belonging to the image. 794 For example, in a 2D texture of size 70x50, it is legal to update the 795 single partial block covering the four texels from (68,48) to (69,49) by 796 setting (<xoffset>, <yoffset>) to (68,48) and <width> and <height> to 2. 797 798 This specification derived some of its language from the 799 EXT_texture_compression_s3tc specification. When that extension was 800 originally written, non-bordered textures were required to have widths and 801 heights that were powers of two. Therefore, the only cases where partial 802 blocks could occur were if the width or height of the texture image was 803 one or two. The original spec language allowed partial block edits only 804 if the width or height of the region edited was equal to the full texture 805 size. That language didn't handle cases such as the 70x50 example above. 806 807 This specification was updated in May, 2009 to allow such edits. 808 Multiple OpenGL implementers correctly implemented the original 809 restriction, and partial edits that include partially covered tiles will 810 result in INVALID_OPERATION errors on older drivers. 811 812Revision History 813 814 Revision 1.1, April 24, 2007: mjk 815 - Add caveat about how signed LA decompression happens when 816 lum0 equals -127 and lum1 equals -128. This caveat matches 817 a decoding allowance in DirectX 10. 818 819 Revision 1.2, January 21, 2008: mjk 820 - Add issues #18 and #19. 821 822 Revision 1.3, June 30, 2008: js 823 - trivial conversion to ARB from EXT 824 825 Revision 1.4, August 7, 2008: jleech 826 - Remove ARB suffixes. 827 828 Revision 1.5, May 29, 2009: jleech 829 - Sync with pbrown's fixes to the EXT version of this extension: 830 Add interaction with non-power-of-two textures from OpenGL 2.0 831 / ARB_texture_non_power_of_two. Allow CompressedTexSubImage2D 832 to perform edits that include partial tiles at the edge of the 833 image as long as the specified width/height parameters line up 834 with the edge. Thanks to Emil Persson for finding this issue. 835 836 Revision 1.6, April 17, 2014: jleech 837 - Fix table 3.17 so base type for COMRPESSED*RG_RGTC2 formats 838 is RG instead of RGB, matching core GL spec (Bug 7812). 839 840 Revision 1.7, January 27, 2015: jleech 841 - Fix table 3.17 so base type for COMRPESSED*RED_RGTC1 formats 842 is RED instead of RGB, matching core GL spec (Bug 13260). 843