back  Return to list

GL_ARB_window_pos
homeprevnext Name
  
    ARB_window_pos  
  
homeprevnext Name Strings
  
    GL_ARB_window_pos  
  
homeprevnext Contact
  
    Brian Paul, brian_e_paul 'at' yahoo.com  
  
homeprevnext Status
  
    Complete. Approved by ARB on February 14, 2002.  
  
homeprevnext Version
  
    Last Modified Date: June 11, 2002  
  
homeprevnext Number
  
    ARB Extension #25  
  
homeprevnext 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.  
  
homeprevnext 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.  
  
homeprevnext IP Status
  
    No IP issues.  
  
homeprevnext 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.  
  
homeprevnext 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)  
  
homeprevnext New Tokens
  
    none  
  
homeprevnext 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 <n> is the DEPTH_RANGE's near value, and <f> 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.  
  
homeprevnext 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 (...)  
  
homeprevnext Additions to the AGL/GLX/WGL Specifications
  
    None  
  
homeprevnext 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	  
  
homeprevnext Errors
  
    INVALID_OPERATION is generated if WindowPosARB is called betweeen  
    Begin and End.  
  
homeprevnext New State
  
    None.  
  
homeprevnext New Implementation Dependent State
  
    None.  
  
homeprevnext 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.  
  
  
  
Valid XHTML 1.1! Valid CSS! Last update: November 14, 2006.
Cette page doit être lue avec un navigateur récent respectant le standard XHTML 1.1.