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