blob: e463481fca244e327d1900163b948fc640d6c929 [file] [log] [blame]
Name Strings
Brian Paul, brian_e_paul 'at'
Copyright (c) 2002-2013 The Khronos Group Inc. Copyright terms at
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
Complete. Approved by ARB on February 14, 2002.
Last Modified Date: June 11, 2002
ARB Extension #25
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.
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
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
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
IP Status
No IP 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
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
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
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
(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
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
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.
with each color component clamped to the range [0,1].
In color index mode, CURRENT_RASTER_INDEX is updated from
All sets of CURRENT_RASTER_TEXTURE_COORDS are updated from
the corresponding CURRENT_TEXTURE_COORDS sets.
If EXT_fog_coord is not supported.
If EXT_fog_coord is supported:
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
GLX Protocol
One new GL rendering command is added. The following command is
sent to the server as part of a glXRender request:
2 16 rendering command length
2 230 rendering command opcode
4 FLOAT32 x
4 FLOAT32 y
4 FLOAT32 z
INVALID_OPERATION is generated if WindowPosARB is called betweeen
Begin and End.
New State
New Implementation Dependent State
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.