1Name 2 3 NV_point_sprite 4 5Name Strings 6 7 GL_NV_point_sprite 8 9Contact 10 11 Matt Craighead, NVIDIA Corporation (mcraighead 'at' nvidia.com) 12 13Notice 14 15 Copyright NVIDIA Corporation, 2001, 2002. 16 17IP Status 18 19 No known IP issues. 20 21Status 22 23 Shipping (version 1.1) 24 25Version 26 27 NVIDIA Date: March 6, 2003 (version 1.3) 28 29Number 30 31 262 32 33Dependencies 34 35 Written based on the wording of the OpenGL 1.3 specification. 36 37 Assumes support for the EXT_point_parameters extension. 38 39Overview 40 41 Applications such as particle systems usually must use OpenGL quads 42 rather than points to render their geometry, since they would like to 43 use a custom-drawn texture for each particle, rather than the 44 traditional OpenGL round antialiased points, and each fragment in 45 a point has the same texture coordinates as every other fragment. 46 47 Unfortunately, specifying the geometry for these quads can be quite 48 expensive, since it quadruples the amount of geometry required, and 49 it may also require the application to do extra processing to compute 50 the location of each vertex. 51 52 The goal of this extension is to allow such apps to use points rather 53 than quads. When GL_POINT_SPRITE_NV is enabled, the state of point 54 antialiasing is ignored. For each texture unit, the app can then 55 specify whether to replace the existing texture coordinates with 56 point sprite texture coordinates, which are interpolated across the 57 point. Finally, the app can set a global parameter for the way to 58 generate the R coordinate for point sprites; the R coordinate can 59 either be zero, the input S coordinate, or the input R coordinate. 60 This allows applications to use a 3D texture to represent a point 61 sprite that goes through an animation, with filtering between frames, 62 for example. 63 64Issues 65 66 * Should this spec say that point sprites get converted into quads? 67 68 RESOLVED: No, this would make the spec much uglier, because then 69 we'd have to say that polygon smooth and stipple get turned off, 70 etc. Better to provide a formula for computing the texture 71 coordinates and leave them as points. 72 73 * How are point sprite texture coordinates computed? 74 75 RESOLVED: They move smoothly as the point moves around on the 76 screen, even though the pixels touched by the point do not. The 77 exact formula is given in the spec. Note that point sprites' T 78 texture coordinate decreases, not increases, with Y; that is, 79 point sprite textures go top-down, not bottom-up. 80 81 * How do point sizes for point sprites work? 82 83 RESOLVED: The original NV_point_sprite spec treated point sprites 84 as being sized like aliased points, i.e., integral sizes only. 85 This was a mistake, because it can lead to visible popping 86 artifacts. In addition, it limits the size of points 87 unnecessarily. 88 89 This revised specification treats point sprite sizes more like 90 antialiased point sizes, but with more leniency. Implementations 91 may choose to not clamp the point size to the antialiased point 92 size range. The set of point sprite sizes available must be a 93 superset of the antialiased point sizes. However, whereas 94 antialiased point sizes are all evenly spaced by the point size 95 granularity, point sprites can have an arbitrary set of sizes. 96 This lets implementations use, e.g., floating-point sizes. 97 98 It is anticipated that this behavior change will not cause any 99 problems for compatibility. In fact, it should be beneficial to 100 quality. 101 102 * Should there be a way to query the list of supported point sprite 103 sizes? 104 105 RESOLVED: No. If an implementation were to use, say, a single- 106 precision IEEE float to represent point sizes, the list would be 107 rather long. 108 109 * Do mipmaps apply to point sprites? 110 111 RESOLVED: Yes. They are similar to quads in this respect. 112 113 * What of this extension's state is per-texture unit and what 114 of this extension's state is state is global? 115 116 RESOLVED: The GL_POINT_SPRITE_NV enable and POINT_SPRITE_R_MODE_NV 117 state are global. The COORD_REPLACE_NV state is per-texture unit 118 (state set by TexEnv is per-texture unit). 119 120 * Should we create an entry point for the R mode? 121 122 RESOLVED: No, we take advantage of the existing glPointParameter 123 interface. Unfortunately, EXT_point_parameters does not define a 124 PointParameteri entry point. This extension adds one. It could 125 live without, but it's a little annoying to have to use a float 126 interface to specify an enumerant. 127 128 This is definitely not TexEnv state, because it is global, not 129 per texture unit. 130 131 * What should the suffix for PointParameteri[v] be? 132 133 RESOLVED: NV. This is an NV extension, and therefore any new 134 entry points must be NV also. This is a bit less aesthetically 135 pleasing than matching the EXT suffixes of EXT_point_parameters, 136 but it is the right thing to do. 137 138 * Should there be a global on/off switch for point sprites, or 139 should the per-unit enable imply that switch? 140 141 RESOLVED: There is a global switch to turn it on and off. This 142 is probably more convenient for both driver and app, and it 143 simplifies the spec. 144 145 * What should the TexEnv mode for point sprites be called? 146 147 RESOLVED: After much deliberation, COORD_REPLACE_NV seems to be 148 appropriate. 149 150 * What is the motivation for each of the three point sprite R 151 modes? 152 153 The R mode is most convenient for applications that may already 154 be drawing their own "point sprites" by rendering quads. These 155 applications already need to put the R coordinate in R, and they 156 do not need to change their code. 157 158 The S mode is most convenient for applications that do not use 159 vertex programs, because it allows them to use TexCoord1 rather 160 than TexCoord3 to specify their third texture coordinate. This 161 reduces the size of the vertex data. Applications that use 162 vertex programs are largely unaffected by this, because they can 163 map the input S texture coordinate into the output R coordinate 164 if they so desire. 165 166 The zero mode may allow some applications to more easily obtain 167 the behavior they want out of the dot product functionality of 168 the NV_texture_shader extension. It reduces these dot products 169 from three-component dot products into two-component dot 170 products. In some implementations, it may also have higher 171 performance than the other modes. 172 173 There is no mode corresponding to the T or Q coordinates because 174 we cannot envision a scenario where such modes would be useful. 175 176 * What is the interaction with multisample points, which are round? 177 178 RESOLVED: Point sprites are rasterized as squares, even in 179 multisample mode. Leaving them as round points would make the 180 feature useless. 181 182 * How does the point sprite extension interact with fragment 183 program extensions (ARB_fragment_program, NV_fragment_program, 184 etc)? 185 186 RESOLVED: The primary issue is how the interpolanted texture 187 coordinate set appears when fragment attribute variables 188 (ARB terminology) or fragment program attribute registers (NV 189 terminology) are accessed. 190 191 When point sprite is enabled and the GL_COORD_REPLACE_NV state for 192 a given texture unit is GL_TRUE, the texture coordinate set for 193 that texture unit is (s,t,r,1) where the point sprite-overriden 194 s, t, and r are described in the amended Section 3.3 below. 195 The important point is that q is forced to 1. 196 197 For fragment program extensions, q cooresponds to the w component 198 of the respective fragment attribute. 199 200 * What push/pop attribute bits control the state of this extension? 201 202 RESOLVED: POINT_BIT for all the state. Also ENABLE_BIT for 203 the POINT_SPRITE_NV enable. 204 205New Procedures and Functions 206 207 void PointParameteriNV(enum pname, int param) 208 void PointParameterivNV(enum pname, const int *params) 209 210New Tokens 211 212 Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, by 213 the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and 214 GetDoublev, and by the <target> parameter of TexEnvi, TexEnviv, 215 TexEnvf, TexEnvfv, GetTexEnviv, and GetTexEnvfv: 216 217 POINT_SPRITE_NV 0x8861 218 219 When the <target> parameter of TexEnvf, TexEnvfv, TexEnvi, TexEnviv, 220 GetTexEnvfv, or GetTexEnviv is POINT_SPRITE_NV, then the value of 221 <pname> may be: 222 223 COORD_REPLACE_NV 0x8862 224 225 When the <target> and <pname> parameters of TexEnvf, TexEnvfv, 226 TexEnvi, or TexEnviv are POINT_SPRITE_NV and COORD_REPLACE_NV 227 respectively, then the value of <param> or the value pointed to by 228 <params> may be: 229 230 FALSE 231 TRUE 232 233 Accepted by the <pname> parameter of PointParameteriNV, 234 PointParameterfEXT, PointParameterivNV, PointParameterfvEXT, 235 GetBooleanv, GetIntegerv, GetFloatv, and GetDoublev: 236 237 POINT_SPRITE_R_MODE_NV 0x8863 238 239 When the <pname> parameter of PointParameteriNV, PointParameterfEXT, 240 PointParameterivNV, or PointParameterfvEXT is 241 POINT_SPRITE_R_MODE_NV, then the value of <param> or the value 242 pointed to by <params> may be: 243 244 ZERO 245 S 246 R 247 248Additions to Chapter 2 of the OpenGL 1.3 Specification (OpenGL Operation) 249 250 None. 251 252Additions to Chapter 3 of the OpenGL 1.3 Specification (Rasterization) 253 254 Insert the following paragraphs after the second paragraph of section 255 3.3 (page 63): 256 257 "Point sprites are enabled or disabled by calling Enable or Disable 258 with the symbolic constant POINT_SPRITE_NV. The default state is for 259 point sprites to be disabled. When point sprites are enabled, the 260 state of the point antialiasing enable is ignored. 261 262 The point sprite R coordinate mode is set with one of the commands 263 264 void PointParameter{if}NV(enum pname, T param) 265 void PointParameter{if}vNV(enum pname, const T *params) 266 267 where pname is POINT_SPRITE_R_MODE_NV. The possible values for param 268 are ZERO, S, and R. The default value is ZERO. 269 270 The point sprite texture coordinate replacement mode is set with one 271 of the commands 272 273 void TexEnv{if}(enum target, enum pname, T param) 274 void TexEnv{if}v(enum target, enum pname, const T *params) 275 276 where target is POINT_SPRITE_NV and pname is COORD_REPLACE_NV. The 277 possible values for param are FALSE and TRUE. The default value for 278 each texture unit is for point sprite texture coordinate replacement 279 to be disabled." 280 281 Replace the first two sentences of the fourth paragraph of section 282 3.3 (page 63) with the following: 283 284 "The effect of a point width other than 1.0 depends on the state of 285 point antialiasing and point sprites. If antialiasing and point 286 sprites are disabled, ..." 287 288 Replace the first sentences of the sixth paragraph of section 3.3 289 (page 64) with the following: 290 291 "If antialiasing is enabled and point sprites are disabled, ..." 292 293 Insert the following paragraphs at the end of section 3.3 (page 66): 294 295 "When point sprites are enabled, then point rasterization produces a 296 fragment for each framebuffer pixel whose center lies inside a square 297 centered at the point's (x_w, y_w), with side length equal to the 298 current point size. 299 300 All fragments produced in rasterizing a point sprite are assigned the 301 same associated data, which are those of the vertex corresponding to 302 the point, with texture coordinates s, t, and r replaced with s/q, 303 t/q, and r/q, respectively. If q is less than or equal to zero, the 304 results are undefined. However, for each texture unit where 305 COORD_REPLACE_NV is TRUE, these texture coordinates are replaced with 306 point sprite texture coordinates. The s coordinate varies from 0 to 307 1 across the point horizontally, while the t coordinate varies from 0 308 to 1 vertically. The r coordinate depends on the value of 309 POINT_SPRITE_R_MODE_NV. If this is set to ZERO, then the r 310 coordinate is set to zero. If it is set to S, then the r coordinate 311 is set to the s texture coordinate before coordinate replacement 312 takes place. If it is set to R, then the r coordinate is set to the 313 r texture coordinate before coordinate replacement takes place. 314 315 The following formula is used to evaluate the s and t coordinates: 316 317 s = 1/2 + (x_f + 1/2 - x_w) / size 318 t = 1/2 - (y_f + 1/2 - y_w) / size 319 320 where size is the point's size, x_f and y_f are the (integral) window 321 coordinates of the fragment, and x_w and y_w are the exact, unrounded 322 window coordinates of the vertex for the point. 323 324 The widths supported for point sprites must be a superset of those 325 supported for antialiased points. There is no requirement that these 326 widths must be equally spaced. If an unsupported width is requested, 327 the nearest supported width is used instead." 328 329 Replace the text of section 3.3.1 (page 66) with the following: 330 331 "The state required to control point rasterization consists of the 332 floating-point point width, a bit indicating whether or not 333 antialiasing is enabled, a bit indicating whether or not point 334 sprites are enabled, the current value of the point sprite R 335 coordinate mode, and a bit for the point sprite texture coordinate 336 replacement mode for each texture unit." 337 338 Replace the text of section 3.3.2 (page 66) with the following: 339 340 "If MULTISAMPLE is enabled, and the value of SAMPLE_BUFFERS is one, 341 then points are rasterized using the following algorithm, regardless 342 of whether point antialiasing (POINT_SMOOTH) is enabled or disabled. 343 Point rasterization produces a fragment for each framebuffer pixel 344 with one or more sample points that intersect a region centered at 345 the point's (x_w, y_w). This region is a circle having diameter 346 equal to the current point width if POINT_SPRITE_NV is disabled, or 347 a square with side equal to the current point width if 348 POINT_SPRITE_NV is enabled. Coverage bits that correspond to sample 349 points that intersect the region are 1, other coverage bits are 0. 350 All data associated with each sample for the fragment are the data 351 associated with the point being rasterized, with the exception of 352 texture coordinates when POINT_SPRITE_NV is enabled; these texture 353 coordinates are computed as described in section 3.3. 354 355 Point size range and number of gradations are equivalent to those 356 supported for antialiased points when POINT_SPRITE_NV is disabled. 357 The set of point sizes supported is equivalent to those for point 358 sprites without multisample when POINT_SPRITE_NV is enabled." 359 360Additions to Chapter 4 of the OpenGL 1.3 Specification (Per-Fragment 361Operations and the Frame Buffer) 362 363 None. 364 365Additions to Chapter 5 of the OpenGL 1.3 Specification (Special Functions) 366 367 None. 368 369Additions to Chapter 6 of the OpenGL 1.3 Specification (State and 370State Requests) 371 372 None. 373 374GLX Protocol 375 376 Two new GL rendering commands are added. The following commands are 377 sent to the server as part of a glXRender request: 378 379 PointParameteriNV 380 2 12 rendering command length 381 2 4221 rendering command opcode 382 4 ENUM pname 383 0x8126 n==1 POINT_SIZE_MIN_ARB 384 0x8127 n==1 POINT_SIZE_MAX_ARB 385 0x8128 n==1 POINT_FADE_THRESHOLD_SIZE_ARB 386 0x8863 n==1 POINT_SPRITE_R_MODE_NV 387 4 INT32 param 388 389 PointParameterivNV 390 2 8+4*n rendering command length 391 2 4222 rendering command opcode 392 4 ENUM pname 393 0x8126 n==1 POINT_SIZE_MIN_ARB 394 0x8127 n==1 POINT_SIZE_MAX_ARB 395 0x8128 n==1 POINT_FADE_THRESHOLD_SIZE_ARB 396 0x8129 n==3 DISTANCE_ATTENUATION_ARB 397 0x8863 n==1 POINT_SPRITE_R_MODE_NV 398 4*n LISTofINT32 params 399 400Errors 401 402 None. 403 404New State 405 406(table 6.12, p. 220) 407 408 Get Value Type Get Command Initial Value Description Sec Attribute 409 --------- ---- ----------- ------------- ----------- ------ --------- 410 POINT_SPRITE_NV B IsEnabled False point sprite enable 3.3 point/enable 411 POINT_SPRITE_R_MODE_NV Z3 GetIntegerv ZERO R coordinate mode 3.3 point 412 413(table 6.17, p. 225) 414 415 Get Value Type Get Command Initial Value Description Sec Attribute 416 --------- ---- ----------- ------------- ----------- ------ --------- 417 COORD_REPLACE_NV 2* x B GetTexEnviv False coordinate replacement 3.3 point 418 enable 419 420NVIDIA Implementation Details 421 422 This extension was first supported for GeForce4 Ti only in NVIDIA's 423 Release 25 drivers. Future drivers will support this extension on 424 all GeForce products. 425 426 However, the extension is only hardware-accelerated on the GeForce3 427 and GeForce4 Ti platforms. In addition, there are restrictions on 428 the cases that are accelerated on the GeForce3. 429 430 In order to ensure that you get hardware acceleration on GeForce3, 431 make sure that: 432 433 1. The point sprite R mode is set to GL_ZERO. (This is the default.) 434 2. Coordinate replacement is turned on for texture unit 3 and for no 435 other texture units. This is non-obvious; using texture unit zero 436 will _not_ be accelerated. Also, if coordinate replacement is off 437 for _all_ texture units, that's also unaccelerated. 438 439 So, in the typical usage case where you just want a single texture on 440 some points, you should enable TEXTURE_2D on unit 3 but disable it on 441 unit zero. 442 443 The GeForce4 Ti platform supports point sprites as large as 8192, but 444 the spacing between sizes becomes larger as the size increases. All 445 other platforms do not support point sprite sizes above 64. 446 447ATI Implementation Details 448 449 This extension is supported on the Radeon 8000 series and later 450 platforms. 451 452 In order to ensure that Radeon 8000 series will accelerate point 453 sprite rendering using TCL hardware, make sure that the point sprite 454 R mode is set to GL_ZERO. (This is the default.) 455 456 Radeon 8000 series can render points as large as 2047. 457 458Revision History 459 460 June 4, 2002 - Added implementation details section. Fixed a typo in 461 the overview. Changed behavior of point sizes so that fractional 462 sizes are allowed and so that implementations can support large point 463 sprites or use floating-point point size representations. 464 Significant rewrite of spec language to cover this new point size 465 behavior. 466 467 July 5, 2002 - Finished GLX protocol. 468 469 March 6, 2003 - Added issue to clarify Q handling for fragment 470 program extensions. Added issue to clarify push/pop attrib handling. 471 Adjusted state tables so COORD_REPLACE_NV state appears in the 472 texture environment and generation table. 473