Name ARB_window_pos Name Strings GL_ARB_window_pos Contact Brian Paul, brian_e_paul 'at' yahoo.com Notice Copyright (c) 2002-2013 The Khronos Group Inc. Copyright terms at http://www.khronos.org/registry/speccopyright.html Specification Update Policy Khronos-approved extension specifications are updated in response to issues and bugs prioritized by the Khronos OpenGL Working Group. For extensions which have been promoted to a core Specification, fixes will first appear in the latest version of that core Specification, and will eventually be backported to the extension document. This policy is described in more detail at https://www.khronos.org/registry/OpenGL/docs/update_policy.php Status Complete. Approved by ARB on February 14, 2002. Version Last Modified Date: June 11, 2002 Number ARB Extension #25 Dependencies OpenGL 1.0 is required. The extension is written against the OpenGL 1.3 Specification GL_EXT_fog_coordinate effects the definition of this extension. GL_EXT_secondary_color effects the definition of this extension. Overview In order to set the current raster position to a specific window coordinate with the RasterPos command, the modelview matrix, projection matrix and viewport must be set very carefully. Furthermore, if the desired window coordinate is outside of the window's bounds one must rely on a subtle side-effect of the Bitmap command in order to avoid frustum clipping. This extension provides a set of functions to directly set the current raster position in window coordinates, bypassing the modelview matrix, the projection matrix and the viewport-to-window mapping. Furthermore, clip testing is not performed, so that the current raster position is always valid. This greatly simplifies the process of setting the current raster position to a specific window coordinate prior to calling DrawPixels, CopyPixels or Bitmap. Many matrix operations can be avoided when mixing 2D and 3D rendering. IP Status No IP issues. Issues (1) Should we offer all 24 entrypoints, just like glRasterPos? RESOLVED. No. Don't implement the 4-coordinate functions as they're really useless. However, we will implement the short and double-type functions for completeness. For example, it's conceivable that an application may have data structures encoding window coordinates as a 2- or 3-vector of shorts and will want to use WindowPos3svARB(). Chris Hecker lobbied for this on the grounds of orthogonality. (2) Should we have unique GLX protocol requests for every entrypoint or just a 3-float version? RESOLVED. Just a 3-float version will suffice since all reasonable window coordinate values can be perfectly represented with single-precision floating point. (4) For WindowPos2*ARB(), is zero the correct value for z? Afterall, z is a window coordinate, not an object coordinate. RESOLVED. Yes, zero is correct. Zero corresponds to the front of the depth range. That's where one would usually want Bitmap, DrawPixels and CopyPixels to be positioned in z when rendering 2D primitives over a 3D scene. (5) What about glDepthRange? RESOLVED. Map the WindowPos z value into the range specified by DepthRange. There's a popular optimization used to avoid depth buffer clears for scenes that completely fill the window in which the depth buffer is effectively halfed and reversed in alternate frames by calling DepthRange. The WindowPos z value should be subjected to depth range mapping so that it will work with this optimization, and in other scenarios. (6) Should we mention EXT_fog_coord and EXT_secondary_color in this extension? RESOLVED. Yes, otherwise implementors may not know what to do with them. It's been suggested that we instead go back and update the EXT_fog_coordinate and EXT_secondary_color specifications with respect to ARB_window_pos instead. However, that seems unlikely to happen and seems error-prone/obscure for implementors. (7) What about the raster fog coordinate? RESOLVED. If EXT_fog_coord is not supported, CURRENT_RASTER_DISTANCE is set to zero. If EXT_fog_coord is supported, the behavior is dependent on the current state of FOG_COORDINATE_SOURCE_EXT. If the fog coordinate source is FRAGMENT_DEPTH_EXT, CURRENT_RASTER_DISTANCE is set to zero. If the fog coordinate source is FOG_COORDINATE_EXT, CURRENT_RASTER_DISTANCE is set to the current fog coordinate. The value chosen for CURRENT_RASTER_DISTANCE state matches the value that would be chosen for normal vertices, except that WindowPos does not allow the GL to compute eye coordinates that would be used to generate a fog distance value. Instead, a value of zero is always used as a fog distance. With the current EXT_fog_coord specification, there are two pieces of RasterPos state that drive fog (CURRENT_RASTER_DISTANCE and the current raster fog coordinate). The setting of the fog coordinate source selects which piece of state is used at rasterization (Bitmap, DrawPixels) time. Instead, this extension moves the selection of fog state to RasterPos state computation instead of rasterization and combines the two pieces of state into a single CURRENT_RASTER_DISTANCE. Current implementations of EXT_fog_coord that support two pieces of state can either change the implementations to merge the two pieces into a single state or contiue to maintain two pieces of state. If the implementations continue to maintain two pieces of state, both the CURRENT_RASTER_DISTANCE and current raster fog coordinate are set to the same value. (8) What about the secondary raster color? RESOLVED. If EXT_secondary_color is supported, the (unnamed) current raster secondary color is set by taking the current secondary color and clamping the components to the range [0,1]. If EXT_secondary_color is not supported, the current raster secondary color is set to (0,0,0). (9) How is this extension specification different from the MESA_window_pos extension? (a) Clarified that lighting and texgen aren't used when updating the current raster state. (b) Explicitly state the effect on CURRENT_RASTER_DISTANCE and CURRENT_RASTER_POSITION_VALID. (c) Explain how the raster position's secondary color and fog coordinate are handled. (d) Z is mapped according to the DEPTH_RANGE values. (e) Removed the functions which take 4 coordinates. New Procedures and Functions void WindowPos2dARB(double x, double y) void WindowPos2fARB(float x, float y) void WindowPos2iARB(int x, int y) void WindowPos2sARB(short x, short y) void WindowPos2dvARB(const double *p) void WindowPos2fvARB(const float *p) void WindowPos2ivARB(const int *p) void WindowPos2svARB(const short *p) void WindowPos3dARB(double x, double y, double z) void WindowPos3fARB(float x, float y, float z) void WindowPos3iARB(int x, int y, int z) void WindowPos3sARB(short x, short y, short z) void WindowPos3dvARB(const double *p) void WindowPos3fvARB(const float *p) void WindowPos3ivARB(const int *p) void WindowPos3svARB(const short *p) New Tokens none Additions to Chapter 2 of the OpenGL 1.3 Specification (OpenGL Operation) In section 2.12 (Current Raster Position), p. 42, insert after fifth paragraph: Alternately, the current raster position may be set by one of the WindowPosARB commands: void WindowPos{23}{ifds}ARB( T coords ); void WindowPos{23}{ifds}vARB( const T coords ); WindosPos3ARB takes three values indicating x, y and z while WindowPos2ARB takes two values indicating x and y with z implicitly set to 0. The CURRENT_RASTER_POSITION, (RPx, RPy, RPz, RPw), is updated as follows: RPx = x RPy = y { n, if z <= 0 RPz = { f, if z >= 1 { n + z * (f - n), otherwise RPw = 1 where is the DEPTH_RANGE's near value, and is the DEPTH_RANGE's far value. In RGBA mode, CURRENT_RASTER_COLOR is updated from CURRENT_COLOR with each color component clamped to the range [0,1]. In color index mode, CURRENT_RASTER_INDEX is updated from CURRENT_INDEX. All sets of CURRENT_RASTER_TEXTURE_COORDS are updated from the corresponding CURRENT_TEXTURE_COORDS sets. CURRENT_RASTER_POSITION_VALID is set to TRUE. If EXT_fog_coord is not supported. CURRENT_RASTER_DISTANCE is set to zero. If EXT_fog_coord is supported: CURRENT_RASTER_DISTANCE is set to { CURRENT_FOG_COORDINATE, if FOG_COORDINATE_SOURCE_EXT is set { to FOG_COORDINATE_EXT, or { 0, if FOG_COORDINATE_SOURCE_EXT is set { to FRAGMENT_DEPTH_EXT. If EXT_secondary_color is supported: The current raster secondary color is set by clamping the components of CURRENT_SECONDARY_COLOR_EXT to [0,1], if in RGBA mode. If EXT_secondary_color is not supported: The current raster secondary color (the secondary color used for all pixel and bitmap rasterization) is set to (0,0,0), if in RGBA mode. Note that lighting, texture coordinate generation, and clipping are not performed by the WindowPos*ARB functions. Additions to Chapter 5 of the OpenGL 1.3 Specification (Special Functions) In section 5.2 (Selection), p. 188, modify the fourth paragraph to read: In selection mode, if a point, line, polygon, or the valid coordinates produced by a RasterPos command intersects the clip volume (section 2.11) then this primitive (or RasterPos command) causes a selection hit. WindowPos commands always generate a selection hit since the resulting raster position is always valid. In the case of polygons (...) Additions to the AGL/GLX/WGL Specifications None GLX Protocol One new GL rendering command is added. The following command is sent to the server as part of a glXRender request: WindowPosARB 2 16 rendering command length 2 230 rendering command opcode 4 FLOAT32 x 4 FLOAT32 y 4 FLOAT32 z Errors INVALID_OPERATION is generated if WindowPosARB is called betweeen Begin and End. New State None. New Implementation Dependent State None. Revision History May 17, 2001 - Initial version based on GL_MESA_window_pos extension May 22, 2001 - Explicitly state that x, y, z are window coordinates and w is a clip space coordinate. (Dan Brokenshire) May 23, 2001 - Resolved issues 1 and 2. - Added issues 4 and 5. May 24, 2001 - Rewrote body of specification to more clearly indicate how all raster position state is updated by WindowPos. - Updated the issues section. Jun 13, 2001 - Added back the double and short versions of WindowPos() - Added fog coord issue and discusstion. - Reordered/renumbered the issues section. Jun 22, 2001 - Set raster secondary color to current secondary color, not black Jun 25, 2001 - Another change to secondary color, think I got it now! Nov 16, 2001 - updated email address - List options "A" and "B" to determine behaviour of current raster fog coordinate. Nov 17, 2001 - minor clean-ups Dec 12, 2001 - rewrite against the OpenGL 1.3 spec - fixed a few typos Jan 10, 2002 - update the interaction with EXT_fog_coord and EXT_secondary_color based on the proposed resolution from the December 2001 ARB meeting. (Pat Brown) Jan 18, 2002 - Merges two pieces of fog state into a single state. (Bimal Poddar) Mar 12, 2002 - Added GLX protocol. (Jon Leech) June 11, 2002 - Clarifications: RGBA/index color updates apply only in RGBA/index mode respectively. Hits are generated in selection mode.