Back to the OpenGL extension cross reference
GL_REND_screen_coordinates
XXX - Not complete yet!!!
REND_screen_coordinates
Name Strings
GL_REND_screen_coordinates
Version
$Date: 1998/06/15 20:37:15 $ $Revision: 1.1 $
Number
155
Dependencies
OpenGL 1.1 is required
EXT_fog_coord affects the definition of this extension.
EXT_cull_vertex affects the definition of this extension.
Overview
This extension allows the specification of screen coordinate vertex
data. Screen coordinate vertices completely bypass transformation,
texture generation, lighting and frustum clipping. It also allow for
fewer floating point computations to the performed by OpenGL.
If we get screen coordinate inputs then in order to perspectively
correct data (eg texture), the input data currently has to be
specified in one of the following manners
1. Specify all the data normally
eg.
glTexture2T(s, t);
and the coordinates as
glVertex4T(x*w, y*w, z*w, w);
or
2. Divide each data by w
eg.
glTexture4T(s/w, t/w, r/w, q/w);
and the coordinates as
glVertex3T(x, y, z);
Most hardware already performs some form of correction of the
coordinate data with respect to the w term prior to interpolation.
This is normally in the form of a multiplication of the terms by the
inverse w. It would be much more efficient to simply specify screen
coordinates as shown in the following example
glTexture2T(s, t, r, q);
and the coordinates as
glVertex4T(x, y, z, w);
and allow the hardware to bring the interpolated terms into a linear
screen space.
Additionally if the application derives screen coordinates it is
also highly likely that the 1/w term may already be computed. So it
would be advantageous to be able to specify 1/w directly instead of
w in the input screen coordinates.
For hardware that linearly interpolates data, the hardware
interpolates the following data:
s/w, t/w, r/w, q/w, x, y, z
If the input w represents the original 1/w, then the hardware can
avoid the division and instead interpolate:
s*w, t*w, r*w, q*w, x, y, z
Issues
* Should screen coordinates have been done as a hint instead of
an enable bit?
RESOLVED: Since this extension specifies changes the semantics of
OpenGL, we need to make this an enable bit
* Should the texture matrix be applied to the input screen
coordinates?
This spec assumes that the texture matrix is applied
* Should the raster position valid be set to invalid when screen
coordinates are enabled.
RESOLVED: Raster position can still be defined. But the raster
position calls should act similar to the vertex specification calls.
So the raster position calls will be specifying screen space
coordinates. The raster position will always be valid. The
raster eye z will be defined to be 0 always.
* Should we allow evaluators in screen space?
This spec is written assuming the evaluators will act as if it is
disabled
* Should we ignore selection if screen coordinates is enabled, or
select everything?
* Should we ignore feedback in screen coordinates is enabled, or
return everything?
None.
Accepted by the <cap> parameter of Enable, Disable and IsEnabled:
SCREEN_COORDINATES_REND 0x8490
INVERTED_SCREEN_W_REND 0x8491
Additions to Chapter 2 of the 1.2 Specification (OpenGL Operation)
Section 2.6 Begin/End Paradigm
<p 13, amend paragraph 1>
These associated colors are either based on the current color or
produced by lighting, depending on whether or not lighting is
enabled and whether or not screen coordinates are enabled.
Texture coordinates are similarly associated with each vertex.
Fig 2.2 summarizes the association of auxiliary data with a
transformed vertex to produce a processed vertex.
<p 13, amend paragraph 2> ...
Vertices and normals are transformed, colors may be affected or
replaced by lighting and texture coordinates are transformed and
possibly affected by a texture coordinate generation function.
However, if screen coordinates has been enabled, then neither
the vertices nor the normal undergo any transformation, the
current colors are not modifies by lighting, the texture
coordinates are transformed but are not affected by texture
coordinate generation functions.
<p 13, amend figure 2.2>
If screen coordinate vertex data is enabled, then the
coordinates are not transformed.
<p 13, amend figure 2.3>
If screen coordinate vertex data is enabled, then clipping is
bypassed.
Section 2.7
<p 20, add after paragraph 1>
If SCREEN_COORDINATES is enabled then the x, y, z and w values
represent screen coordinate values. Additionally if
INVERTED_SCREEN_W is enabled then the w coodinate is treated as
the actual 1/w coordinate.
Section 2.10
<p 28, modify paragraph 1>
Vertices, normals and texture coordinates are transformed before
their coordinates are used to produce an image in the
framebuffer. However if screen coordinates are enabled then only
the texture coordinate may undergo a transformation.
Section 2.10.4
<p 36, modify paragraph 1>
Texture coordinates associated with a vertex may either be taken
from the current texture coordinates or generated according to a
function dependant on vertex coordinates. However if screen
coordinate data is enabled then the texture coordinate
associated with the vertex always comes from the current
texture.
Section 2.12
<p 41, modify paragraph 2>
The coordinates are treated as if they were specified in a
Vertex command. The x, y, z, and w coordinates are transformed
by the current model-view and perspective matrices if screen
coordinates is disabled. These coordinates, along with the
current values, are used to generate a color and texture
coordinates just as is done for a vertex. The color and textures
coordinates so produced replace the color and texture
coordinates stored in the current raster position's associated
data. The distance from the origin of the eye coordinate system
to the vertex as transformed by only the current model-view
matrix replaces the current raster distance if screen
coordinates is disabled. If screen coordinates are enabled then
the current raster distance is always 0. This distance can be
approximted (see section 3.10).
<p 42, Modify figure 2.7>
If screen coordinate vertex data is enabled then the associated
data always gets the texture coordinates from the current
texture coordinate and the color from the current color
(lighting and texgen are as if they are disabled).
<p 43, Modify figure 2.9>
If screen coordinate vertex data is enabled then lighting and
color clipping is bypassed.
Section 2.13
<p 43, Modify paragraph 1>
Next lighting, if enabled and screen coordinate data is not
enabled, produces either a color index or primary and secondary
colors. ...
Section 2.13.8
<p 54, modify paragraph 1>
After lighting, clamping or masking, and possibly flat shading,
colors are clipped if screen coordinate data is not enabled. ...
Additions to Chapter 3 of the 1.2 Specification (Rasterization)
Section 3.4.1
<p 66, modify equation 3.2>
If inverted screen w disabled or screen coordinate data is
disabled
(1-t) fa/wa + t fb/wb
f =-----------------------
(1-t) Aa/wa + t Ab/wb
otherwise
(1-t) fa.wa + t fb.wb
f =-----------------------
(1-t) Aa.wa + t Ab.wb
Section 3.5
<p 71, modify equation 3.4>
If inverted screen w disabled or screen coordinate data is
disabled
a.fa/wa + b.fb/wb + c.fc/wc
f =-----------------------------
a.Aa/wa + b.Ab/wb + c.Ac/wc
otherwise
a.fa.wa + b.fb.wb + c.fc.wc
f =-----------------------------
a.Aa.wa + b.Ab.wb + c.Ac.wc
Section 3.10
<p 139, modify paragraph 2>
This factor f is computed according to one of three equations:
f = exp(-d.z), (3.24)
2
f = exp(-(d.z) ), or (3.25)
e - z
f = ------ (3.26)
e - s
(z is the eye coordinate distance from the eye, (0,0,0,1) in
eye coordinates, to the fragment center if screen coordinates is
disabled, z is 0 otherwise). ....
Additions to Chapter 4 of the 1.2 Specification (Per-Fragment Operations and the Framebuffer)
Additions to Chapter 5 of the 1.2 Specification (Special Functions)
Section 5.1
<p 166, append at the end of paragraph 1>
Evaluators act as if they are disabled if screen coordinate data
is enabled.
Section 5.2
<p 172, append at the end paragraph 1>
If screen coordinate data is enabled then the primitives are
always selected.
Section 5.3
<p 175, append to the end of paragraph 1>
If screen coordinate data is enabled then every primitive is
always added to the feedback buffer if it is not an image
rectangle based primitive (bitmap or DrawPixels or CopyPixels).
Additions to Chapter 6 of the 1.2 Specification (State and State Requests)
Section 6.2.1
<p 199, add to the end of Table 6.7>
Get Value Type Get Command Initial Description Sec. Attribute
Value
--------- ---- ----------- -------- ----------- ---- ---------
SCREEN_COORDINATES B IsEnabled False Input coord - enable
system
INVERTED_SCREEN_W B IsEnabled False Screen coor 2.7 enable
w semantics
Additions to the GLX Specification
None
GLX Protocol
TBD
Dependencies on EXT_fog_coord
If EXT_fog_coord is supported then the section 3.10 is
further modified to read:
This factor f is computed according to one of three equations:
f = exp(-d.c), (3.24)
2
f = exp(-(d.c) ), or (3.25)
e - c
f = ------ (3.26)
e - s
If the fog source (as defined below) is FRAGMENT_DEPTH, then c
is the eye coordinate distance from the eye (0,0,0,1) in eye
coordinates, to the fragment center if screen coordinates is
disabled. If screen coordinates is enabled then it is always 0.
If the fog source is FOG_COORDINATE, then c is the interpolated
value of the fog coordinate for this fragment. ...
Dependencies on EXT_cull_vertex
If screen coordinates are enabled and EXT_cull_vertex is supported,
then vertex culling is never performed regardless of whether
CULL_VERTEX_EXT is enabled or not.
Errors
None.
New State
Get Value Get Command Type Initial Value Attribute
--------- ----------- ---- ------------- ---------
SCREEN_COORDINATES IsEnabled 1* x B False enable
INVERTED_SCREEN_W IsEnabled 1* x B False enable
New Implementation Dependent State
None.
Implementation Support
List of OpenGL implementations supporting the GL_REND_screen_coordinates extension
Original File
Original text file for the GL_REND_screen_coordinates extension
Page generated on Sun Nov 20 18:38:58 2005