1Name 2 3 ARB_point_sprite 4 5Name Strings 6 7 GL_ARB_point_sprite 8 9Contact 10 11 Matt Craighead, NVIDIA Corporation (mcraighead 'at' nvidia.com) 12 Mark Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) 13 Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) 14 15Notice 16 17 Copyright (c) 2003-2013 The Khronos Group Inc. Copyright terms at 18 http://www.khronos.org/registry/speccopyright.html 19 20Specification Update Policy 21 22 Khronos-approved extension specifications are updated in response to 23 issues and bugs prioritized by the Khronos OpenGL Working Group. For 24 extensions which have been promoted to a core Specification, fixes will 25 first appear in the latest version of that core Specification, and will 26 eventually be backported to the extension document. This policy is 27 described in more detail at 28 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 29 30IP Status 31 32 No known IP issues. 33 34Status 35 36 Approved by the ARB on July 24, 2003. 37 38Version 39 40 Last Modified Date: July 22, 2003 41 Revision: 7 42 43Number 44 45 ARB Extension #35 46 47Dependencies 48 49 Written based on the wording of the OpenGL 1.4 specification. 50 51 NV_point_sprite affects the definition of this extension. 52 53Overview 54 55 Applications such as particle systems have tended to use OpenGL quads 56 rather than points to render their geometry, since they would like 57 to use a custom-drawn texture for each particle, rather than the 58 traditional OpenGL round antialiased points, and each fragment in 59 a point has the same texture coordinates as every other fragment. 60 61 Unfortunately, specifying the geometry for these quads can be 62 expensive, since it quadruples the amount of geometry required, and 63 may also require the application to do extra processing to compute 64 the location of each vertex. 65 66 The purpose of this extension is to allow such applications to use 67 points rather than quads. When GL_POINT_SPRITE_ARB is enabled, 68 the state of point antialiasing is ignored. For each texture unit, 69 the app can then specify whether to replace the existing texture 70 coordinates with point sprite texture coordinates, which are 71 interpolated across the point. 72 73Issues 74 75 * Should this spec say that point sprites get converted into quads? 76 77 RESOLVED: No, this would make the spec much uglier, because then 78 we'd have to say that polygon smooth and stipple get turned off, 79 etc. Better to provide a formula for computing the texture 80 coordinates and leave them as points. 81 82 * How are point sprite texture coordinates computed? 83 84 RESOLVED: They move smoothly as the point moves around on the 85 screen, even though the pixels touched by the point do not. The 86 exact formula is given in the spec below. 87 88 A point sprite can be thought of as a quad whose upper-left corner has 89 (s,t) texture coordinates of (0,0) and whose lower-right corner has 90 texture coordinates of (1,1), as illustrated in the following figure. 91 In the figure "P" is the center of the point sprite, and "O" is the 92 origin (0,0) of the window coordinate system. Note that the y window 93 coordinate increases from bottom-to-top but the t texture coordinate 94 of point sprites increases from top-to-bottom. 95 96 ^ 97 +y| (0,0) 98 | +-----+ 99 | | | 100 | | P | 101 | | | 102 | +-----+ 103 | (1,1) 104 | +x 105 O---------------> 106 107 Applications using a single texture for both point sprites and other 108 geometry need to account for the fixed coordinate mapping of point 109 sprites. 110 111 * Is the ARB specification different from the NV version? 112 113 RESOLVED: Yes. The point sprite R mode has been removed. The 114 wording has also been updated to reflect version 1.4 of the core 115 OpenGL specification however. The enumerant values are unchanged. 116 117 * How do point sizes for point sprites work? 118 119 RESOLVED: This specification treats point sprite sizes like 120 antialiased point sizes, but with more leniency. Implementations 121 may choose to not clamp the point size to the antialiased point 122 size range. The set of point sprite sizes available must be 123 a superset of the antialiased point sizes. However, whereas 124 antialiased point sizes are all evenly spaced by the point size 125 granularity, point sprites can have an arbitrary set of sizes. 126 This lets implementations use, e.g., floating-point sizes. 127 128 * Should there be a way to query the list of supported point sprite 129 sizes? 130 131 RESOLVED: No. If an implementation were to use, say, a single- 132 precision IEEE float to represent point sizes, the list would be 133 rather long. 134 135 * Do mipmaps apply to point sprites? 136 137 RESOLVED: Yes. They are similar to quads in this respect. 138 139 * What of this extension's state is per-texture unit and what 140 of this extension's state is state is global? 141 142 RESOLVED: The GL_POINT_SPRITE_ARB enable is global. The 143 COORD_REPLACE_ARB state is per-texture unit (state set by TexEnv is 144 per-texture unit). 145 146 * Should there be a global on/off switch for point sprites, or 147 should the per-unit enable imply that switch? 148 149 RESOLVED: There is a global switch to turn it on and off. This 150 is probably more convenient for both driver and app, and it 151 simplifies the spec. 152 153 * What should the TexEnv mode for point sprites be called? 154 155 RESOLVED: COORD_REPLACE_ARB. 156 157 * What is the interaction with multisample points, which are round? 158 159 RESOLVED: Point sprites are rasterized as squares, even in 160 multisample mode. Leaving them as round points would make the 161 feature useless. 162 163 * How does the point sprite extension interact with fragment 164 program extensions (ARB_fragment_program, NV_fragment_program, 165 etc)? 166 167 RESOLVED: The primary issue is how the interpolated texture 168 coordinate set appears when fragment attribute variables 169 (ARB terminology) or fragment program attribute registers (NV 170 terminology) are accessed. 171 172 When point sprite is enabled and the GL_COORD_REPLACE_ARB state for 173 a given texture unit is GL_TRUE, the texture coordinate set for 174 that texture unit is (s,t,0,1) where the point sprite-overridden 175 s and t are described in the amended Section 3.3 below. The 176 important point is that r and q are forced to 0 and 1, respectively. 177 178 For fragment program extensions, r and q correspond to the z and w 179 components of the respective fragment attribute. 180 181 * How does this extension interact with PolygonMode? 182 183 RESOLVED: If a polygon is rendered in point mode and POINT_SPRITE_ARB 184 is enabled, its vertices will be rendered as point sprites. 185 186 * How does this extension interact with the point size attenuation 187 functionality in ARB_point_parameters and OpenGL 1.4? 188 189 RESOLVED: Point sprites sizes are attenuated just like the sizes of 190 non-sprite points. 191 192 * What push/pop attribute bits control the state of this extension? 193 194 RESOLVED: POINT_BIT for all the state. Also ENABLE_BIT for 195 the POINT_SPRITE_ARB enable. 196 197 * How are point sprites clipped? 198 199 RESOLVED: Point sprites are transformed as points, and standard point 200 clipping operations are performed. This can cause point sprites that 201 move off the edge of the screen to disappear abruptly, in the same way 202 that regular points do. As with any other primitive, standard 203 per-fragment clipping operations (scissoring, window ownership test) 204 still apply. 205 206New Procedures and Functions 207 208 None 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_ARB 0x8861 218 219 When the <target> parameter of TexEnvf, TexEnvfv, TexEnvi, TexEnviv, 220 GetTexEnvfv, or GetTexEnviv is POINT_SPRITE_ARB, then the value of 221 <pname> may be: 222 223 COORD_REPLACE_ARB 0x8862 224 225 When the <target> and <pname> parameters of TexEnvf, TexEnvfv, 226 TexEnvi, or TexEnviv are POINT_SPRITE_ARB and COORD_REPLACE_ARB 227 respectively, then the value of <param> or the value pointed to by 228 <params> may be: 229 230 FALSE 231 TRUE 232 233 234Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation) 235 236 None. 237 238Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization) 239 240 Insert the following paragraphs after the second paragraph of section 241 3.3 (page 66): 242 243 "Point sprites are enabled or disabled by calling Enable or Disable 244 with the symbolic constant POINT_SPRITE_ARB. The default state is for 245 point sprites to be disabled. When point sprites are enabled, the 246 state of the point antialiasing enable is ignored. 247 248 The point sprite texture coordinate replacement mode is set with one 249 of the commands 250 251 void TexEnv{if}(enum target, enum pname, T param) 252 void TexEnv{if}v(enum target, enum pname, const T *params) 253 254 where target is POINT_SPRITE_ARB and pname is COORD_REPLACE_ARB. The 255 possible values for param are FALSE and TRUE. The default value for 256 each texture unit is for point sprite texture coordinate replacement 257 to be disabled." 258 259 Replace the first two sentences of the second paragraph of section 260 3.3.1 (page 67) with the following: 261 262 "The effect of a point width other than 1.0 depends on the state of 263 point antialiasing and point sprites. If antialiasing and point 264 sprites are disabled, ..." 265 266 Replace the first sentences of the fourth paragraph of section 3.3.1 267 (page 68) with the following: 268 269 "If antialiasing is enabled and point sprites are disabled, ..." 270 271 Insert the following paragraphs at the end of section 3.3.1 (page 272 70): 273 274 "When point sprites are enabled, then point rasterization produces a 275 fragment for each framebuffer pixel whose center lies inside a square 276 centered at the point's (x_w, y_w), with side length equal to the 277 current point size. 278 279 All fragments produced in rasterizing a point sprite are assigned the 280 same associated data, which are those of the vertex corresponding to 281 the point, with texture coordinates s, t, and r replaced with s/q, 282 t/q, and r/q, respectively. If q is less than or equal to zero, the 283 results are undefined. However, for each texture unit where 284 COORD_REPLACE_ARB is TRUE, these texture coordinates are replaced 285 with point sprite texture coordinates. The s coordinate varies 286 from 0 to 1 across the point horizontally left-to-right, while 287 the t coordinate varies from 0 to 1 vertically top-to-bottom. 288 The r and q coordinates are replaced with the constants 0 and 1, 289 respectively. 290 291 The following formula is used to evaluate the s and t coordinates: 292 293 s = 1/2 + (x_f + 1/2 - x_w) / size 294 t = 1/2 - (y_f + 1/2 - y_w) / size 295 296 where size is the point's size, x_f and y_f are the (integral) window 297 coordinates of the fragment, and x_w and y_w are the exact, unrounded 298 window coordinates of the vertex for the point. 299 300 The widths supported for point sprites must be a superset of those 301 supported for antialiased points. There is no requirement that these 302 widths must be equally spaced. If an unsupported width is requested, 303 the nearest supported width is used instead." 304 305 Replace the text of section 3.3.2 (page 70) with the following: 306 307 "The state required to control point rasterization consists of the 308 floating-point point width, three floating-point values specifying 309 the minimum and maximum point size and the point fade threshold size, 310 three floating-point values specifying the distance attenuation 311 coefficients, a bit indicating whether or not antialiasing is 312 enabled, a bit indicating whether or not point sprites are enabled, 313 and a bit for the point sprite texture coordinate replacement mode 314 for each texture unit." 315 316 Replace the text of section 3.3.3 (page 70) with the following: 317 318 "If MULTISAMPLE is enabled, and the value of SAMPLE_BUFFERS is one, 319 then points are rasterized using the following algorithm, regardless 320 of whether point antialiasing (POINT_SMOOTH) is enabled or disabled. 321 Point rasterization produces a fragment for each framebuffer pixel 322 with one or more sample points that intersect a region centered at 323 the point's (x_w, y_w). This region is a circle having diameter 324 equal to the current point width if POINT_SPRITE_ARB is disabled, or 325 a square with side equal to the current point width if 326 POINT_SPRITE_ARB is enabled. Coverage bits that correspond to sample 327 points that intersect the region are 1, other coverage bits are 0. 328 All data associated with each sample for the fragment are the data 329 associated with the point being rasterized, with the exception of 330 texture coordinates when POINT_SPRITE_ARB is enabled; these texture 331 coordinates are computed as described in section 3.3. 332 333 Point size range and number of gradations are equivalent to those 334 supported for antialiased points when POINT_SPRITE_ARB is disabled. 335 The set of point sizes supported is equivalent to those for point 336 sprites without multisample when POINT_SPRITE_ARB is enabled." 337 338Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment 339Operations and the Frame Buffer) 340 341 None. 342 343Additions to Chapter 5 of the OpenGL 1.4 Specification (Special 344Functions) 345 346 None. 347 348Additions to Chapter 6 of the OpenGL 1.4 Specification (State and 349State Requests) 350 351 None. 352 353Interactions with NV_point_sprite 354 355 ARB_point_sprite is a functional subset of NV_point_sprite. 356 357 The only functional difference between the extensions is that 358 NV_point_sprite provides the POINT_SPRITE_R_MODE_NV control. This mode 359 allows applications to specify how the r texture coordinates for point 360 sprites are replaced. The r coordinate can be replaced with the 361 corresponding s texture coordinate ("S" mode), left unchanged ("R" mode), 362 or replaced with the constant zero ("ZERO" mode). ARB_point_sprite always 363 replaces r texture coordiantes of point sprites with zero. 364 365 Since ARB_point_sprite is functionally compatible with the default r mode 366 from NV_point_sprite, the two extensions can coexist nicely. Enumerant 367 values from NV_point_sprite are reused. 368 369 If NV_point_sprite is supported, the language describing the replacement 370 of r coordinates for point sprites (forced to zero) is replaced with the 371 corresponding language from NV_point_sprite (controlled by 372 POINT_SPRITE_R_MODE_NV). 373 374 375Errors 376 377 None. 378 379New State 380 381(table 6.12, p. 220) 382 383Get Value Type Get Command Initial Value Description Sec Attribute 384--------- ---- ----------- ------------- ----------- ------ --------- 385POINT_SPRITE_ARB B IsEnabled False point sprite enable 3.3 point/enable 386 387(table 6.17, p. 225) 388 389Get Value Type Get Command Initial Value Description Sec Attribute 390--------- ---- ----------- ------------- ----------- ------ --------- 391COORD_REPLACE_ARB 2* x B GetTexEnviv False coordinate replacement 3.3 point 392 enable 393 394Revision History 395 396 Initially based on the NV_point_sprite specification but updated for 397 OpenGL 1.4. 398 399 Rev. Date Author Changes 400 ---- -------- -------- -------------------------------------------- 401 7 07/22/03 pbrown Marked point parameter issue resolved. 402 403 6 07/18/03 pbrown Removed POINT_SPRITE_R_MODE_CONTROL. 404 405 Expanded on spec issue documenting the inversion 406 of the "t" texture coordinate relative to the 407 "y" window coordinate. Added issues on 408 interaction with PolygonMode, clipping, and 409 point parameters. Documented interaction with 410 NV_point_sprite. Removed now unneeded point 411 parameter interaction section and GLX protocol. 412