| 0,0 → 1,190 |
|---|
| Name |
| |
| MESA_sprite_point |
| |
| Name Strings |
| |
| GL_MESA_sprite_point |
| |
| Contact |
| |
| Brian Paul, VA Linux Systems Inc. (brianp 'at' valinux.com) |
| |
| Status |
| |
| Obsolete - see GL_ARB_point_sprite. |
| |
| Version |
| |
| |
| Number |
| |
| ??? |
| |
| Dependencies |
| |
| GL_EXT_point_parameters effects the definition of this extension |
| GL_ARB_multitexture effects the definition of this extension |
| |
| Overview |
| |
| This extension modifies the way in which points are rendered, |
| specifically when they're textured. When SPRITE_POINT_MESA is enabled |
| a point is rendered as if it were a quadrilateral with unique texture |
| coordinates at each vertex. This extension effectively turns points |
| into sprites which may be rendered more easily and quickly than using |
| conventional textured quadrilaterals. |
| |
| When using point size > 1 or attenuated points this extension is an |
| effective way to render many small sprite images for particle systems |
| or other effects. |
| |
| Issues: |
| |
| 1. How are the texture coordinates computed? |
| |
| The lower-left corner has texture coordinate (0,0,r,q). |
| The lower-right, (1,0,r,q). The upper-right, (1,1,r,q). |
| The upper-left, (0,1,r,q). |
| |
| 2. What about texgen and texture matrices? |
| |
| Texgen and the texture matrix have no effect on the point's s and t |
| texture coordinates. The r and q coordinates may have been computed |
| by texgen or the texture matrix. Note that with a 3D texture and/or |
| texgen that the r coordinate could be used to select a slice in the |
| 3D texture. |
| |
| 3. What about point smoothing? |
| |
| When point smoothing is enabled, a triangle fan could be rendered |
| to approximate a circular point. This could be problematic to |
| define and implement so POINT_SMOOTH is ignored when drawing sprite |
| points. |
| |
| Smoothed points can be approximated by using an appropriate texture |
| images, alpha testing and blending. |
| |
| POLYGON_SMOOTH does effect the rendering of the quadrilateral, however. |
| |
| 4. What about sprite rotation? |
| |
| There is none. Sprite points are always rendered as window-aligned |
| squares. One could define rotated texture images if desired. A 3D |
| texture and appropriate texture r coordinates could be used to |
| effectively specify image rotation per point. |
| |
| 5. What about POLYGON_MODE? |
| |
| POLYGON_MODE does not effect the rasterization of the quadrilateral. |
| |
| 6. What about POLYGON_CULL? |
| |
| TBD. Polygon culling is normally specified and implemented in the |
| transformation stage of OpenGL. However, some rasterization hardware |
| implements it later during triangle setup. |
| |
| Polygon culling wouldn't be useful for sprite points since the |
| quadrilaterals are always defined in counter-clockwise order in |
| window space. For that reason, polygon culling should probably be |
| ignored. |
| |
| 7. Should sprite points be alpha-attenuated if their size is below the |
| point parameter's threshold size? |
| |
| 8. Should there be an advertisized maximum sprite point size? |
| |
| No. Since we're rendering the point as a quadrilateral there's no |
| need to limit the size. |
| |
| |
| New Procedures and Functions |
| |
| None. |
| |
| New Tokens |
| |
| Accepted by the <pname> parameter of Enable, Disable, IsEnabled, |
| GetIntegerv, GetBooleanv, GetFloatv and GetDoublev: |
| |
| SPRITE_POINT_MESA 0x???? |
| MAX_SPRITE_POINT_SIZE_MESA 0x???? (need this?) |
| |
| Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation) |
| |
| None |
| |
| Additions to Chapter 3 of the 1.1 Specification (Rasterization) |
| |
| Section ???. |
| |
| When SPRITE_POINT_MESA is enabled points are rasterized as screen- |
| aligned quadrilaterals. If the four vertices of the quadrilateral |
| are labeled A, B, C, and D, starting at the lower-left corner and moving |
| counter-clockwise around the quadrilateral, then the vertex and |
| texture coordinates are computed as follows: |
| |
| vertex window coordinate texture coordinate |
| A (x-r, y-r, z, w) (0, 0, r, q) |
| B (x+r, y-r, z, w) (1, 0, r, q) |
| C (x+r, y+r, z, w) (1, 1, r, q) |
| D (x-r, y+r, z, w) (0, 1, r, q) |
| |
| where x, y, z, w are the point's window coordinates, r and q are the |
| point's 3rd and 4th texture coordinates and r is half the point's |
| size. The other vertex attributes (such as the color and fog coordinate) |
| are simply duplicated from the original point vertex. |
| |
| Point size may either be specified with PointSize or computed |
| according to the EXT_point_parameters extension. |
| |
| The new texture coordinates are not effected by texgen or the texture |
| matrix. Note, however, that the texture r and q coordinates are passed |
| unchanged and may have been computed with texgen and/or the texture |
| matrix. |
| |
| If multiple texture units are present the same texture coordinate is |
| used for all texture units. |
| |
| The point is then rendered as if it were a quadrilateral using the |
| normal point sampling rules. POLYGON_MODE does not effect the |
| rasterization of the quadrilateral but POLYGON_SMOOTH does. |
| |
| POINT_SMOOTH has no effect when SPRITE_POINT_MESA is enabled. |
| |
| Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations |
| and the Frame Buffer) |
| |
| None. |
| |
| Additions to Chapter 5 of the 1.1 Specification (Special Functions) |
| |
| None |
| |
| Additions to Chapter 6 of the 1.1 Specification (State and State Requests) |
| |
| None |
| |
| Additions to the GLX Specification |
| |
| None |
| |
| GLX Protocol |
| |
| TBD |
| |
| Errors |
| |
| None |
| |
| New State |
| |
| Add boolean variable SPRITE_POINT_MESA to the point attribute group. |
| |
| Revision History |
| |
| Version 1.0 - 4 Dec 2000 |
| Original draft. |
| |
| |
| |