1Name
2
3    MESA_sprite_point
4
5Name Strings
6
7    GL_MESA_sprite_point
8
9Contact
10
11    Brian Paul, VA Linux Systems Inc. (brianp 'at' valinux.com)
12
13Status
14
15    Obsolete - see GL_ARB_point_sprite.
16
17Version
18
19
20Number
21
22    ???
23
24Dependencies
25
26    GL_EXT_point_parameters effects the definition of this extension
27    GL_ARB_multitexture effects the definition of this extension
28
29Overview
30	
31    This extension modifies the way in which points are rendered,
32    specifically when they're textured.  When SPRITE_POINT_MESA is enabled
33    a point is rendered as if it were a quadrilateral with unique texture
34    coordinates at each vertex.  This extension effectively turns points
35    into sprites which may be rendered more easily and quickly than using
36    conventional textured quadrilaterals.
37
38    When using point size > 1 or attenuated points this extension is an
39    effective way to render many small sprite images for particle systems
40    or other effects.
41
42Issues:
43
44    1. How are the texture coordinates computed?
45
46       The lower-left corner has texture coordinate (0,0,r,q).
47       The lower-right, (1,0,r,q).  The upper-right, (1,1,r,q).
48       The upper-left, (0,1,r,q).
49
50    2. What about texgen and texture matrices?
51
52       Texgen and the texture matrix have no effect on the point's s and t
53       texture coordinates.  The r and q coordinates may have been computed
54       by texgen or the texture matrix.  Note that with a 3D texture and/or
55       texgen that the r coordinate could be used to select a slice in the
56       3D texture.
57
58    3. What about point smoothing?
59
60       When point smoothing is enabled, a triangle fan could be rendered
61       to approximate a circular point.  This could be problematic to
62       define and implement so POINT_SMOOTH is ignored when drawing sprite
63       points.
64
65       Smoothed points can be approximated by using an appropriate texture
66       images, alpha testing and blending.
67
68       POLYGON_SMOOTH does effect the rendering of the quadrilateral, however.
69
70    4. What about sprite rotation?
71
72       There is none.  Sprite points are always rendered as window-aligned
73       squares.  One could define rotated texture images if desired.  A 3D
74       texture and appropriate texture r coordinates could be used to
75       effectively specify image rotation per point.
76
77    5. What about POLYGON_MODE?
78
79       POLYGON_MODE does not effect the rasterization of the quadrilateral.
80
81    6. What about POLYGON_CULL?
82
83       TBD.  Polygon culling is normally specified and implemented in the
84       transformation stage of OpenGL.  However, some rasterization hardware
85       implements it later during triangle setup.
86
87       Polygon culling wouldn't be useful for sprite points since the
88       quadrilaterals are always defined in counter-clockwise order in
89       window space.  For that reason, polygon culling should probably be
90       ignored.
91
92    7. Should sprite points be alpha-attenuated if their size is below the
93       point parameter's threshold size?
94
95    8. Should there be an advertisized maximum sprite point size?
96
97       No.  Since we're rendering the point as a quadrilateral there's no
98       need to limit the size.
99
100
101New Procedures and Functions
102
103    None.
104
105New Tokens
106    
107    Accepted by the <pname> parameter of Enable, Disable, IsEnabled,
108    GetIntegerv, GetBooleanv, GetFloatv and GetDoublev:
109
110	SPRITE_POINT_MESA		0x????
111        MAX_SPRITE_POINT_SIZE_MESA      0x????   (need this?)
112
113Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation)
114
115    None
116
117Additions to Chapter 3 of the 1.1 Specification (Rasterization)
118
119    Section ???.
120
121    When SPRITE_POINT_MESA is enabled points are rasterized as screen-
122    aligned quadrilaterals.  If the four vertices of the quadrilateral
123    are labeled A, B, C, and D, starting at the lower-left corner and moving
124    counter-clockwise around the quadrilateral, then the vertex and
125    texture coordinates are computed as follows:
126
127      vertex   window coordinate       texture coordinate
128        A      (x-r, y-r, z, w)          (0, 0, r, q)
129        B      (x+r, y-r, z, w)          (1, 0, r, q)
130        C      (x+r, y+r, z, w)          (1, 1, r, q)
131        D      (x-r, y+r, z, w)          (0, 1, r, q)
132
133    where x, y, z, w are the point's window coordinates, r and q are the
134    point's 3rd and 4th texture coordinates  and r is half the point's
135    size.  The other vertex attributes (such as the color and fog coordinate)
136    are simply duplicated from the original point vertex.
137
138    Point size may either be specified with PointSize or computed
139    according to the EXT_point_parameters extension.
140
141    The new texture coordinates are not effected by texgen or the texture
142    matrix.  Note, however, that the texture r and q coordinates are passed
143    unchanged and may have been computed with texgen and/or the texture
144    matrix.
145
146    If multiple texture units are present the same texture coordinate is
147    used for all texture units.
148
149    The point is then rendered as if it were a quadrilateral using the
150    normal point sampling rules.  POLYGON_MODE does not effect the
151    rasterization of the quadrilateral but POLYGON_SMOOTH does.
152
153    POINT_SMOOTH has no effect when SPRITE_POINT_MESA is enabled.
154
155Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations
156and the Frame Buffer)
157
158    None.
159
160Additions to Chapter 5 of the 1.1 Specification (Special Functions)
161
162    None
163
164Additions to Chapter 6 of the 1.1 Specification (State and State Requests)
165
166    None
167
168Additions to the GLX Specification
169
170    None
171
172GLX Protocol
173
174    TBD
175
176Errors
177
178    None
179
180New State
181
182    Add boolean variable SPRITE_POINT_MESA to the point attribute group.
183
184Revision History
185
186    Version 1.0 - 4 Dec 2000
187        Original draft.
188
189
190
191