1Name 2 3 ARB_window_pos 4 5Name Strings 6 7 GL_ARB_window_pos 8 9Contact 10 11 Brian Paul, brian_e_paul 'at' yahoo.com 12 13Notice 14 15 Copyright (c) 2002-2013 The Khronos Group Inc. Copyright terms at 16 http://www.khronos.org/registry/speccopyright.html 17 18Specification Update Policy 19 20 Khronos-approved extension specifications are updated in response to 21 issues and bugs prioritized by the Khronos OpenGL Working Group. For 22 extensions which have been promoted to a core Specification, fixes will 23 first appear in the latest version of that core Specification, and will 24 eventually be backported to the extension document. This policy is 25 described in more detail at 26 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 27 28Status 29 30 Complete. Approved by ARB on February 14, 2002. 31 32Version 33 34 Last Modified Date: June 11, 2002 35 36Number 37 38 ARB Extension #25 39 40Dependencies 41 42 OpenGL 1.0 is required. 43 The extension is written against the OpenGL 1.3 Specification 44 GL_EXT_fog_coordinate effects the definition of this extension. 45 GL_EXT_secondary_color effects the definition of this extension. 46 47Overview 48 49 In order to set the current raster position to a specific window 50 coordinate with the RasterPos command, the modelview matrix, projection 51 matrix and viewport must be set very carefully. Furthermore, if the 52 desired window coordinate is outside of the window's bounds one must rely 53 on a subtle side-effect of the Bitmap command in order to avoid frustum 54 clipping. 55 56 This extension provides a set of functions to directly set the current 57 raster position in window coordinates, bypassing the modelview matrix, the 58 projection matrix and the viewport-to-window mapping. Furthermore, clip 59 testing is not performed, so that the current raster position is always 60 valid. 61 62 This greatly simplifies the process of setting the current raster position 63 to a specific window coordinate prior to calling DrawPixels, CopyPixels or 64 Bitmap. Many matrix operations can be avoided when mixing 2D and 3D 65 rendering. 66 67IP Status 68 69 No IP issues. 70 71Issues 72 73 (1) Should we offer all 24 entrypoints, just like glRasterPos? 74 75 RESOLVED. No. Don't implement the 4-coordinate functions as 76 they're really useless. However, we will implement the short 77 and double-type functions for completeness. 78 79 For example, it's conceivable that an application may have 80 data structures encoding window coordinates as a 2- or 3-vector 81 of shorts and will want to use WindowPos3svARB(). Chris Hecker 82 lobbied for this on the grounds of orthogonality. 83 84 (2) Should we have unique GLX protocol requests for every entrypoint 85 or just a 3-float version? 86 87 RESOLVED. Just a 3-float version will suffice since all reasonable 88 window coordinate values can be perfectly represented with 89 single-precision floating point. 90 91 (4) For WindowPos2*ARB(), is zero the correct value for z? Afterall, 92 z is a window coordinate, not an object coordinate. 93 94 RESOLVED. Yes, zero is correct. Zero corresponds to the front 95 of the depth range. That's where one would usually want Bitmap, 96 DrawPixels and CopyPixels to be positioned in z when rendering 2D 97 primitives over a 3D scene. 98 99 (5) What about glDepthRange? 100 101 RESOLVED. Map the WindowPos z value into the range specified by 102 DepthRange. There's a popular optimization used to avoid depth 103 buffer clears for scenes that completely fill the window in which 104 the depth buffer is effectively halfed and reversed in alternate 105 frames by calling DepthRange. The WindowPos z value should be 106 subjected to depth range mapping so that it will work with this 107 optimization, and in other scenarios. 108 109 (6) Should we mention EXT_fog_coord and EXT_secondary_color in this 110 extension? 111 112 RESOLVED. Yes, otherwise implementors may not know what to do 113 with them. It's been suggested that we instead go back and 114 update the EXT_fog_coordinate and EXT_secondary_color specifications 115 with respect to ARB_window_pos instead. However, that seems 116 unlikely to happen and seems error-prone/obscure for implementors. 117 118 (7) What about the raster fog coordinate? 119 120 RESOLVED. If EXT_fog_coord is not supported, CURRENT_RASTER_DISTANCE 121 is set to zero. 122 123 If EXT_fog_coord is supported, the behavior is dependent on 124 the current state of FOG_COORDINATE_SOURCE_EXT. If the fog 125 coordinate source is FRAGMENT_DEPTH_EXT, CURRENT_RASTER_DISTANCE 126 is set to zero. If the fog coordinate source is FOG_COORDINATE_EXT, 127 CURRENT_RASTER_DISTANCE is set to the current fog coordinate. 128 129 The value chosen for CURRENT_RASTER_DISTANCE state matches the value 130 that would be chosen for normal vertices, except that WindowPos 131 does not allow the GL to compute eye coordinates that would be 132 used to generate a fog distance value. Instead, a value of zero is 133 always used as a fog distance. 134 135 With the current EXT_fog_coord specification, there are two pieces 136 of RasterPos state that drive fog (CURRENT_RASTER_DISTANCE and 137 the current raster fog coordinate). The setting of the fog 138 coordinate source selects which piece of state is used at 139 rasterization (Bitmap, DrawPixels) time. Instead, this extension 140 moves the selection of fog state to RasterPos state computation instead 141 of rasterization and combines the two pieces of state into a 142 single CURRENT_RASTER_DISTANCE. 143 144 Current implementations of EXT_fog_coord that support two pieces of 145 state can either change the implementations to merge the two pieces 146 into a single state or contiue to maintain two pieces of state. 147 If the implementations continue to maintain two pieces of state, 148 both the CURRENT_RASTER_DISTANCE and current raster fog coordinate 149 are set to the same value. 150 151 (8) What about the secondary raster color? 152 153 RESOLVED. If EXT_secondary_color is supported, the (unnamed) current 154 raster secondary color is set by taking the current secondary color and 155 clamping the components to the range [0,1]. 156 157 If EXT_secondary_color is not supported, the current raster secondary 158 color is set to (0,0,0). 159 160 (9) How is this extension specification different from the 161 MESA_window_pos extension? 162 163 (a) Clarified that lighting and texgen aren't used when updating 164 the current raster state. 165 166 (b) Explicitly state the effect on CURRENT_RASTER_DISTANCE and 167 CURRENT_RASTER_POSITION_VALID. 168 169 (c) Explain how the raster position's secondary color and fog 170 coordinate are handled. 171 172 (d) Z is mapped according to the DEPTH_RANGE values. 173 174 (e) Removed the functions which take 4 coordinates. 175 176New Procedures and Functions 177 178 void WindowPos2dARB(double x, double y) 179 void WindowPos2fARB(float x, float y) 180 void WindowPos2iARB(int x, int y) 181 void WindowPos2sARB(short x, short y) 182 183 void WindowPos2dvARB(const double *p) 184 void WindowPos2fvARB(const float *p) 185 void WindowPos2ivARB(const int *p) 186 void WindowPos2svARB(const short *p) 187 188 void WindowPos3dARB(double x, double y, double z) 189 void WindowPos3fARB(float x, float y, float z) 190 void WindowPos3iARB(int x, int y, int z) 191 void WindowPos3sARB(short x, short y, short z) 192 193 void WindowPos3dvARB(const double *p) 194 void WindowPos3fvARB(const float *p) 195 void WindowPos3ivARB(const int *p) 196 void WindowPos3svARB(const short *p) 197 198New Tokens 199 200 none 201 202Additions to Chapter 2 of the OpenGL 1.3 Specification (OpenGL Operation) 203 204 In section 2.12 (Current Raster Position), p. 42, insert after 205 fifth paragraph: 206 207 Alternately, the current raster position may be set by one of the 208 WindowPosARB commands: 209 210 void WindowPos{23}{ifds}ARB( T coords ); 211 void WindowPos{23}{ifds}vARB( const T coords ); 212 213 WindosPos3ARB takes three values indicating x, y and z while 214 WindowPos2ARB takes two values indicating x and y with z implicitly 215 set to 0. 216 217 The CURRENT_RASTER_POSITION, (RPx, RPy, RPz, RPw), is updated as 218 follows: 219 220 RPx = x 221 222 RPy = y 223 224 { n, if z <= 0 225 RPz = { f, if z >= 1 226 { n + z * (f - n), otherwise 227 228 RPw = 1 229 230 where <n> is the DEPTH_RANGE's near value, and <f> is the 231 DEPTH_RANGE's far value. 232 233 In RGBA mode, CURRENT_RASTER_COLOR is updated from CURRENT_COLOR 234 with each color component clamped to the range [0,1]. 235 236 In color index mode, CURRENT_RASTER_INDEX is updated from 237 CURRENT_INDEX. 238 239 All sets of CURRENT_RASTER_TEXTURE_COORDS are updated from 240 the corresponding CURRENT_TEXTURE_COORDS sets. 241 242 CURRENT_RASTER_POSITION_VALID is set to TRUE. 243 244 If EXT_fog_coord is not supported. 245 246 CURRENT_RASTER_DISTANCE is set to zero. 247 248 If EXT_fog_coord is supported: 249 250 CURRENT_RASTER_DISTANCE is set to 251 252 { CURRENT_FOG_COORDINATE, if FOG_COORDINATE_SOURCE_EXT is set 253 { to FOG_COORDINATE_EXT, or 254 { 0, if FOG_COORDINATE_SOURCE_EXT is set 255 { to FRAGMENT_DEPTH_EXT. 256 257 If EXT_secondary_color is supported: 258 259 The current raster secondary color is set by clamping the components 260 of CURRENT_SECONDARY_COLOR_EXT to [0,1], if in RGBA mode. 261 262 If EXT_secondary_color is not supported: 263 264 The current raster secondary color (the secondary color used for all 265 pixel and bitmap rasterization) is set to (0,0,0), if in RGBA mode. 266 267 Note that lighting, texture coordinate generation, and clipping are 268 not performed by the WindowPos*ARB functions. 269 270Additions to Chapter 5 of the OpenGL 1.3 Specification (Special Functions) 271 272 In section 5.2 (Selection), p. 188, modify the fourth paragraph to read: 273 274 In selection mode, if a point, line, polygon, or the valid 275 coordinates produced by a RasterPos command intersects the clip 276 volume (section 2.11) then this primitive (or RasterPos command) 277 causes a selection hit. WindowPos commands always generate a 278 selection hit since the resulting raster position is always 279 valid. In the case of polygons (...) 280 281Additions to the AGL/GLX/WGL Specifications 282 283 None 284 285GLX Protocol 286 287 One new GL rendering command is added. The following command is 288 sent to the server as part of a glXRender request: 289 290 WindowPosARB 291 2 16 rendering command length 292 2 230 rendering command opcode 293 4 FLOAT32 x 294 4 FLOAT32 y 295 4 FLOAT32 z 296 297Errors 298 299 INVALID_OPERATION is generated if WindowPosARB is called betweeen 300 Begin and End. 301 302New State 303 304 None. 305 306New Implementation Dependent State 307 308 None. 309 310Revision History 311 312 May 17, 2001 313 - Initial version based on GL_MESA_window_pos extension 314 May 22, 2001 315 - Explicitly state that x, y, z are window coordinates and w is 316 a clip space coordinate. (Dan Brokenshire) 317 May 23, 2001 318 - Resolved issues 1 and 2. 319 - Added issues 4 and 5. 320 May 24, 2001 321 - Rewrote body of specification to more clearly indicate how all 322 raster position state is updated by WindowPos. 323 - Updated the issues section. 324 Jun 13, 2001 325 - Added back the double and short versions of WindowPos() 326 - Added fog coord issue and discusstion. 327 - Reordered/renumbered the issues section. 328 Jun 22, 2001 329 - Set raster secondary color to current secondary color, not black 330 Jun 25, 2001 331 - Another change to secondary color, think I got it now! 332 Nov 16, 2001 333 - updated email address 334 - List options "A" and "B" to determine behaviour of current raster 335 fog coordinate. 336 Nov 17, 2001 337 - minor clean-ups 338 Dec 12, 2001 339 - rewrite against the OpenGL 1.3 spec 340 - fixed a few typos 341 Jan 10, 2002 342 - update the interaction with EXT_fog_coord and EXT_secondary_color 343 based on the proposed resolution from the December 2001 ARB 344 meeting. (Pat Brown) 345 Jan 18, 2002 346 - Merges two pieces of fog state into a single state. (Bimal Poddar) 347 Mar 12, 2002 348 - Added GLX protocol. (Jon Leech) 349 June 11, 2002 350 - Clarifications: RGBA/index color updates apply only in 351 RGBA/index mode respectively. Hits are generated in selection mode. 352