1XXX - Not complete yet!!! 2 3Name 4 5 REND_screen_coordinates 6 7Name Strings 8 9 GL_REND_screen_coordinates 10 11Version 12 13 $Date: 1998/06/15 20:37:15 $ $Revision: 1.1 $ 14 15Number 16 17 155 18 19Dependencies 20 21 OpenGL 1.1 is required 22 EXT_fog_coord affects the definition of this extension. 23 EXT_cull_vertex affects the definition of this extension. 24 25Overview 26 27 This extension allows the specification of screen coordinate vertex 28 data. Screen coordinate vertices completely bypass transformation, 29 texture generation, lighting and frustum clipping. It also allow for 30 fewer floating point computations to the performed by OpenGL. 31 32 If we get screen coordinate inputs then in order to perspectively 33 correct data (eg texture), the input data currently has to be 34 specified in one of the following manners 35 36 1. Specify all the data normally 37 eg. 38 glTexture2T(s, t); 39 and the coordinates as 40 glVertex4T(x*w, y*w, z*w, w); 41 or 42 2. Divide each data by w 43 eg. 44 glTexture4T(s/w, t/w, r/w, q/w); 45 and the coordinates as 46 glVertex3T(x, y, z); 47 48 Most hardware already performs some form of correction of the 49 coordinate data with respect to the w term prior to interpolation. 50 This is normally in the form of a multiplication of the terms by the 51 inverse w. It would be much more efficient to simply specify screen 52 coordinates as shown in the following example 53 glTexture2T(s, t, r, q); 54 and the coordinates as 55 glVertex4T(x, y, z, w); 56 and allow the hardware to bring the interpolated terms into a linear 57 screen space. 58 59 Additionally if the application derives screen coordinates it is 60 also highly likely that the 1/w term may already be computed. So it 61 would be advantageous to be able to specify 1/w directly instead of 62 w in the input screen coordinates. 63 64 For hardware that linearly interpolates data, the hardware 65 interpolates the following data: 66 s/w, t/w, r/w, q/w, x, y, z 67 If the input w represents the original 1/w, then the hardware can 68 avoid the division and instead interpolate: 69 s*w, t*w, r*w, q*w, x, y, z 70 71 72Issues 73 74 * Should screen coordinates have been done as a hint instead of 75 an enable bit? 76 77 RESOLVED: Since this extension specifies changes the semantics of 78 OpenGL, we need to make this an enable bit 79 80 * Should the texture matrix be applied to the input screen 81 coordinates? 82 83 This spec assumes that the texture matrix is applied 84 85 * Should the raster position valid be set to invalid when screen 86 coordinates are enabled. 87 88 RESOLVED: Raster position can still be defined. But the raster 89 position calls should act similar to the vertex specification calls. 90 So the raster position calls will be specifying screen space 91 coordinates. The raster position will always be valid. The 92 93 raster eye z will be defined to be 0 always. 94 95 * Should we allow evaluators in screen space? 96 97 This spec is written assuming the evaluators will act as if it is 98 disabled 99 100 * Should we ignore selection if screen coordinates is enabled, or 101 select everything? 102 103 * Should we ignore feedback in screen coordinates is enabled, or 104 return everything? 105 106New Procedures and Functions 107 108 None. 109 110New Tokens 111 112 Accepted by the <cap> parameter of Enable, Disable and IsEnabled: 113 114 SCREEN_COORDINATES_REND 0x8490 115 INVERTED_SCREEN_W_REND 0x8491 116 117Additions to Chapter 2 of the 1.2 Specification (OpenGL Operation) 118 119 Section 2.6 Begin/End Paradigm 120 121 <p 13, amend paragraph 1> 122 These associated colors are either based on the current color or 123 produced by lighting, depending on whether or not lighting is 124 enabled and whether or not screen coordinates are enabled. 125 Texture coordinates are similarly associated with each vertex. 126 Fig 2.2 summarizes the association of auxiliary data with a 127 transformed vertex to produce a processed vertex. 128 129 <p 13, amend paragraph 2> ... 130 Vertices and normals are transformed, colors may be affected or 131 replaced by lighting and texture coordinates are transformed and 132 possibly affected by a texture coordinate generation function. 133 However, if screen coordinates has been enabled, then neither 134 the vertices nor the normal undergo any transformation, the 135 current colors are not modifies by lighting, the texture 136 coordinates are transformed but are not affected by texture 137 coordinate generation functions. 138 139 <p 13, amend figure 2.2> 140 If screen coordinate vertex data is enabled, then the 141 coordinates are not transformed. 142 143 <p 13, amend figure 2.3> 144 If screen coordinate vertex data is enabled, then clipping is 145 bypassed. 146 147 Section 2.7 148 149 <p 20, add after paragraph 1> 150 If SCREEN_COORDINATES is enabled then the x, y, z and w values 151 represent screen coordinate values. Additionally if 152 INVERTED_SCREEN_W is enabled then the w coodinate is treated as 153 the actual 1/w coordinate. 154 155 Section 2.10 156 157 <p 28, modify paragraph 1> 158 Vertices, normals and texture coordinates are transformed before 159 their coordinates are used to produce an image in the 160 framebuffer. However if screen coordinates are enabled then only 161 the texture coordinate may undergo a transformation. 162 163 Section 2.10.4 164 165 <p 36, modify paragraph 1> 166 Texture coordinates associated with a vertex may either be taken 167 from the current texture coordinates or generated according to a 168 function dependant on vertex coordinates. However if screen 169 coordinate data is enabled then the texture coordinate 170 associated with the vertex always comes from the current 171 texture. 172 173 Section 2.12 174 175 <p 41, modify paragraph 2> 176 The coordinates are treated as if they were specified in a 177 Vertex command. The x, y, z, and w coordinates are transformed 178 by the current model-view and perspective matrices if screen 179 coordinates is disabled. These coordinates, along with the 180 current values, are used to generate a color and texture 181 coordinates just as is done for a vertex. The color and textures 182 coordinates so produced replace the color and texture 183 coordinates stored in the current raster position's associated 184 data. The distance from the origin of the eye coordinate system 185 to the vertex as transformed by only the current model-view 186 matrix replaces the current raster distance if screen 187 coordinates is disabled. If screen coordinates are enabled then 188 the current raster distance is always 0. This distance can be 189 approximted (see section 3.10). 190 191 <p 42, Modify figure 2.7> 192 If screen coordinate vertex data is enabled then the associated 193 data always gets the texture coordinates from the current 194 texture coordinate and the color from the current color 195 (lighting and texgen are as if they are disabled). 196 197 <p 43, Modify figure 2.9> 198 If screen coordinate vertex data is enabled then lighting and 199 color clipping is bypassed. 200 201 Section 2.13 202 203 <p 43, Modify paragraph 1> 204 Next lighting, if enabled and screen coordinate data is not 205 enabled, produces either a color index or primary and secondary 206 colors. ... 207 208 209 Section 2.13.8 210 211 <p 54, modify paragraph 1> 212 After lighting, clamping or masking, and possibly flat shading, 213 colors are clipped if screen coordinate data is not enabled. ... 214 215Additions to Chapter 3 of the 1.2 Specification (Rasterization) 216 217 Section 3.4.1 218 219 <p 66, modify equation 3.2> 220 If inverted screen w disabled or screen coordinate data is 221 disabled 222 223 (1-t) fa/wa + t fb/wb 224 f =----------------------- 225 (1-t) Aa/wa + t Ab/wb 226 227 otherwise 228 229 (1-t) fa.wa + t fb.wb 230 f =----------------------- 231 (1-t) Aa.wa + t Ab.wb 232 233 Section 3.5 234 235 <p 71, modify equation 3.4> 236 If inverted screen w disabled or screen coordinate data is 237 disabled 238 a.fa/wa + b.fb/wb + c.fc/wc 239 f =----------------------------- 240 a.Aa/wa + b.Ab/wb + c.Ac/wc 241 242 otherwise 243 a.fa.wa + b.fb.wb + c.fc.wc 244 f =----------------------------- 245 a.Aa.wa + b.Ab.wb + c.Ac.wc 246 247 Section 3.10 248 249 <p 139, modify paragraph 2> 250 This factor f is computed according to one of three equations: 251 252 f = exp(-d.z), (3.24) 253 2 254 f = exp(-(d.z) ), or (3.25) 255 256 e - z 257 f = ------ (3.26) 258 e - s 259 (z is the eye coordinate distance from the eye, (0,0,0,1) in 260 261 eye coordinates, to the fragment center if screen coordinates is 262 disabled, z is 0 otherwise). .... 263 264Additions to Chapter 4 of the 1.2 Specification (Per-Fragment Operations and the Framebuffer) 265 266Additions to Chapter 5 of the 1.2 Specification (Special Functions) 267 268 Section 5.1 269 270 <p 166, append at the end of paragraph 1> 271 Evaluators act as if they are disabled if screen coordinate data 272 is enabled. 273 274 Section 5.2 275 276 <p 172, append at the end paragraph 1> 277 If screen coordinate data is enabled then the primitives are 278 always selected. 279 280 Section 5.3 281 282 <p 175, append to the end of paragraph 1> 283 If screen coordinate data is enabled then every primitive is 284 always added to the feedback buffer if it is not an image 285 rectangle based primitive (bitmap or DrawPixels or CopyPixels). 286 287Additions to Chapter 6 of the 1.2 Specification (State and State Requests) 288 289 Section 6.2.1 290 291 <p 199, add to the end of Table 6.7> 292 Get Value Type Get Command Initial Description Sec. Attribute 293 Value 294 --------- ---- ----------- -------- ----------- ---- --------- 295 SCREEN_COORDINATES B IsEnabled False Input coord - enable 296 system 297 INVERTED_SCREEN_W B IsEnabled False Screen coor 2.7 enable 298 w semantics 299 300Additions to the GLX Specification 301 302 None 303 304GLX Protocol 305 306 TBD 307 308Dependencies on EXT_fog_coord 309 310 If EXT_fog_coord is supported then the section 3.10 is 311 further modified to read: 312 313 This factor f is computed according to one of three equations: 314 315 f = exp(-d.c), (3.24) 316 2 317 f = exp(-(d.c) ), or (3.25) 318 319 e - c 320 f = ------ (3.26) 321 e - s 322 If the fog source (as defined below) is FRAGMENT_DEPTH, then c 323 is the eye coordinate distance from the eye (0,0,0,1) in eye 324 coordinates, to the fragment center if screen coordinates is 325 disabled. If screen coordinates is enabled then it is always 0. 326 If the fog source is FOG_COORDINATE, then c is the interpolated 327 value of the fog coordinate for this fragment. ... 328 329Dependencies on EXT_cull_vertex 330 If screen coordinates are enabled and EXT_cull_vertex is supported, 331 then vertex culling is never performed regardless of whether 332 CULL_VERTEX_EXT is enabled or not. 333 334Errors 335 336 None. 337 338New State 339 340 Get Value Get Command Type Initial Value Attribute 341 --------- ----------- ---- ------------- --------- 342 SCREEN_COORDINATES IsEnabled 1* x B False enable 343 344 INVERTED_SCREEN_W IsEnabled 1* x B False enable 345 346New Implementation Dependent State 347 348 None. 349