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