XXX - Not complete yet!!! Name 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? New Procedures and Functions None. New Tokens Accepted by the 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

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.

... 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.

If screen coordinate vertex data is enabled, then the coordinates are not transformed.

If screen coordinate vertex data is enabled, then clipping is bypassed. Section 2.7

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

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

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

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).

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).

If screen coordinate vertex data is enabled then lighting and color clipping is bypassed. Section 2.13

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

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

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

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

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

Evaluators act as if they are disabled if screen coordinate data is enabled. Section 5.2

If screen coordinate data is enabled then the primitives are always selected. Section 5.3

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

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.