blob: b157297c2169f4db19bb138dd0cd18526bf342ff [file] [log] [blame]
Name Strings
Mark J. Kilgard, NVIDIA Corporation (mjk 'at'
Timo Suoranta, Broadcom
Piers Daniell, NVIDIA
Stefan Dösinger, CodeWeavers
Jeff Bolz, NVIDIA
John McDonald, NVIDIA
Brian Paul, VMware, Mesa3D
Jason Mitchell, Valve
Alex Corscadden, VMware
Simon Bennett, VMware
Mark Callow, HI Corporation
Patrick Doane, Blizzard
Pat Brown, NVIDIA
Brano Kemen
Copyright (c) 2014 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
Approved by the ARB on June 26, 2014.
Ratified by the Khronos Board of Promoters on August 7, 2014.
Last Modified Date: 2018/04/06
NVIDIA Revision: 19
ARB Extension #160
Written based on the wording of the OpenGL 4.4 (Compatibility Profile)
This extension provides additional clip control modes to configure how
clip space is mapped to window space. This extension's goal is to 1)
allow OpenGL to effectively match Direct3D's coordinate system
conventions, and 2) potentially improve the numerical precision of the Z
coordinate mapping.
Developers interested in this functionality may be porting content
from Direct3D to OpenGL and/or interested in improving the numerical
accuracy of depth testing, particularly with floating-point depth
OpenGL's initial and conventional clip control state is configured by:
where geometry with (x,y) normalized device coordinates of (-1,-1)
correspond to the lower-left corner of the viewport and the near and far
planes correspond to z normalized device coordinates of -1 and +1,
This extension can be used to render content used in a Direct3D
application in OpenGL in a straightforward way without modifying vertex or
matrix data. When rendering into a window, the command
configures the near clip plane to correspond to a z normalized device
coordinate of 0 as in Direct3D. Geometry with (x,y) normalized device
coordinates of (-1,-1) correspond to the lower-left corner of the viewport
in Direct3D, so no change relative to OpenGL conventions is needed there.
Other state related to screen-space coordinates may need to be modified
for the application to map from Direct3D to OpenGL window coordinate
conventions. For example, the viewport rectangle in Direct3D needs to be
inverted within the window to work properly in OpenGL windowed rendering:
window_height - (d3d_viewport_y + d3d_viewport_height),
d3d_viewport_width, d3d_viewport_height);
When rendering Direct3D content into a framebuffer object in OpenGL, there
is one complication -- how to get a correct image *out* of the related
textures. Direct3D applications would expect a texture coordinate of
(0,0) to correspond to the upper-left corner of a rendered image, while
OpenGL FBO conventions would map (0,0) to the lower-left corner of the
rendered image. For applications wishing to use Direct3D content with
unmodified texture coordinates, the command
configures the OpenGL to invert geometry vertically inside the viewport.
Content at the top of the viewport for Direct3D will be rendered to the
bottom of the viewport from the point of view of OpenGL, but will have a
<t> texture coordinate of zero in both cases. When operating in this
mode, applications need not invert the programmed viewport rectangle as
recommended for windowed rendering above.
Applications happy with OpenGL's origin conventions but seeking
potentially improved depth precision can configure clip controls using:
to avoid the loss of precision from the DepthRange transformation
(which by default is z_window = z_ndc * 0.5 + 0.5).
New Procedures and Functions
void ClipControl(enum origin, enum depth);
New Tokens
Accepted by the <origin> parameter of ClipControl:
Accepted by the <depth> parameter of ClipControl:
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
GetFloatv, and GetDoublev:
Additions to Chapter 13 of the OpenGL 4.4 (Compatibility Profile)
Specification (Fixed-Function Vertex Post-Processing)
-- Modify section 13.5 "Primitive Clipping"
Insert before the 1st paragraph...
"The command
ClipControl(enum origin, enum depth);
controls the clipping volume behavior. /origin/ must be either
LOWER_LEFT or UPPER_LEFT, otherwise the error INVALID_ENUM is
generated. /depth/ must be either NEGATIVE_ONE_TO_ONE or
ZERO_TO_ONE, otherwise the error INVALID_ENUM is generated.
These parameters update the clip control origin and
depth mode respectively. The state required for clip control is one
bit for clip control origin and one bit for clip control depth mode.
The initial value of the clip control origin is LOWER_LEFT and the
initial value of the depth mode is NEGATIVE_ONE_TO_ONE.
The error INVALID_OPERATION is generated if ClipControl is
executed between the execution of Begin and the corresponding
execution of End."
Replace the first paragraph with...
"Primitives are clipped to the clip volume. In clip coordinates,
the view volume is defined by
-w_c <= x_c <= w_c
-w_c <= y_c <= w_c
zm <= z_c <= w_c
where zm is -w_c when the clip control depth mode is
NEGATIVE_ONE_TO_ONE or zero when the mode is ZERO_TO_ONE."
Change the last sentence of the 7th paragraph to read...
"If depth clamping is enabled, the
zm <= z_c <= w_c
plane equation (see the clip volume definition) is ignored by
view volume clipping (effectively, there is no near or far plane
-- Modify section 13.6 "Coordinate Transformations"
Replace the 3rd paragraph with (where ^T means transpose):
"If a vertex in clip coordinates is given by (x_c y_c z_c w_c)^T
then the vertex's normalized device coordinates are (x_d y_d z_d)^T =
(x_c/w_c f*y_c/w_c z_c/w_c)^T where /f/ is +1 when the clip control
origin is LOWER_LEFT and -1 when the origin is UPPER_LEFT."
-- Modify section 13.6.1 "Controlling the Viewport"
Replace the 2nd sentence of the 1st paragraph with (where ^T means
"The vertex's window coordinates, (x_w y_w z_w)^T are given by:
( x_w ) ( p_x/2 x_d + o_x )
( y_w ) = ( p_y/2 y_d + o_y )
( z_w ) ( s z_d + b )
where s is (f-n)/2 and b is (n+f)/2 when the clip control depth mode
is NEGATIVE_ONE_TO_ONE; or s is (f-n) and b is n when the mode
Additions to Chapter 14 of the OpenGL 4.4 (Compatibility Profile)
Specification (Fixed-Function Primitive Assembly and Rasterization)
-- Modify section 14.6.1 "Basic Polygon Rasterization"
Replace the 3rd sentence of the 1st paragraph with:
"One way to compute this area is
a = 1/2 f \ x^i_w * y^i(+)1_w - x^i(+)1_w * y^i_w
where f is +1 when the clip control origin is LOWER_LEFT and -1 when
the origin is UPPER_LEFT, x^i_w and y^i_w are the x and y window
coordinates of the ith vertex of the n-vertex polygon (vertices
are numbered starting at zero for purposes of this computation),
and i(+)1 is (i+1) mod n."
Additions to the AGL/GLX/WGL Specifications
GLX Protocol
A new GL rendering command is added. The following command is sent to the
server as part of a glXRender request:
2 12 rendering command length
2 1340 rendering command opcode
4 ENUM origin
4 ENUM depth
The error INVALID_ENUM is generated by ClipControl if origin is not
The error INVALID_ENUM is generated by ClipControl if depth is not
The error INVALID_OPERATION is generated if ClipControl is executed
between the execution of Begin and the corresponding execution of
New State
Get Value Type Get Command Initial Value Description Sec Attribute
---------------- ---- ----------- ------------------- --------------- ---- ---------
CLIP_ORIGIN Z2 GetIntegerv LOWER_LEFT Clip origin 13.5 xform
CLIP_DEPTH_MODE Z2 GetIntegerv NEGATIVE_ONE_TO_ONE Clip depth mode 13.5 xform
New Implementation Dependent State
1) What should this extension be called?
RESOLVED: ARB_clip_control
We frame this extension in terms of how the fixed-function
transformation from clip coordinates to window coordinates
is specified. The crucial modifications to OpenGL's existing
behavior involve controlling how clip space is interpreted.
An upper-left origin is really simply negating (flipping) the
clip space Y coordinate. Subsequently the sense of counter-clockwise
and clockwise for face culling must be adjusted (flipped).
A zero-to-one Z mode involves adjusting the clipping equation
for the clip space Z coordinate. Subsequently the depth range
transform equation must be adjusted (scaled and biased).
Hence clip control is a sensible name.
2) Should this functionality be exposed with glEnable/glDisable or
with a new command.
RESOLVED: With a new command, glClipControl.
We note that this extension does not actually enable or disable
functionality, but rather modifies an existing transformation.
We note that Direct3D is different in two ways: clip Y inversion
and zero-to-one clip Z.
We note the difficulty of a clear enable name.
are very explicit about how the Z clip coordinate is treated by
the clip equations. Likewise, GL_LOWER_LEFT and GL_UPPER_LEFT
are explicit (and match the token names and meaning for the
point sprite functionality).
We also note the possibility for other possible conventions.
For example, an origin at the center of the window. Hence an
enumeration of clip modes is a better choice. Likewise, a future
Z mode could expose W-buffering.
3) Why does unextended OpenGL have symmetric clip equations?
RESOLVED: This is a legacy of implementation worthy of some
Handling the X, Y, and Z directions the same way better
facilitates vector operation for hardware efficiency.
When transformations are done with 32-bit IEEE-754 floating-point
values, after transformation to clip space for clipping, the
Z values are typically converted to fixed-point for use by a
conventional 24-bit fixed-point depth buffer.
The process of scaling by 0.5 and adding 0.5 to a 32-bit
floating-point number in the range [-1,+1] has the effect of
appropriately rounding the value so it can be efficiently
bit-shifted into a 24-bit fixed-point value in the [0,1]
range suitable for depth buffering via linear fixed-point
4) Should the face culling behavior be modified in GL_UPPER_LEFT
clip origin mode?
See how the modifications to section 14.6.1 "Basic Polygon
Rasterization" negate the sign of the polygon area when the clip
control origin is GL_UPPER_LEFT.
Since culling behavior is specified as CW (clockwise) or CCW
(counter-clockwise) different triangle faces would be culled
when the clip origin is changed, which would be an unacceptable
side effect.
5) Are the projective matrices generated by glFrustum and glOrtho
appropriate when the clip Z mode is GL_ZERO_TO_ONE?
6) Should the behavior of glFrustum and glOrtho change?
It's not worth encumbering these routines with adjustments,
plus it is easy to make the proper adjustments...
Taking advantage of how matrix changes concatenate...
If your clip control origin is GL_UPPER_LEFT, prior to your
glFrustum or glOrtho command by:
If your clip control depth mode is GL_ZERO_TO_ONE, precede
your glFrustum or glOrtho command by:
For example, if your code to configure the projection matrix
glFrustum(-0.5, 0.5, -0.5, 0.5, 1, 3);
And you wanted to call:
Then configure your projection matrix as
// adjust for GL_UPPER_LEFT
// adjust for GL_ZERO_TO_ONE
glFrustum(-0.5, 0.5, -0.5, 0.5, 1, 3);
Technically, the two glScalef could be combined as
7) Has this topic been discussed elsewhere?
RESOLVED: Yes, see:
"Maximizing Depth Buffer Range and Precision"
Brano Kemen
November 28, 2012
"Minimum Triangle Separation for Correct Z-Buffer"
Kurt Akeley and Jonathan Su
August 2006
"Tightening the Precision of Perspective Rendering"
Paul Upchurch and Mathieu Desbrun
Journal of Graphics Tools, Volume 16, Issue 1, 2012.
8) How does this extension interact with the unclamped depth range
parameters of NV_depth_buffer_float's glDepthRangedNV and OpenGL
RESOLVED: Simply apply the equations as specified.
The implications of this are explored...
An unclamped depth range applies to floating-point depth buffers.
(For a conventional [0,1] fixed-point depth buffer, the depth
range is clamped to "the range appropriate to the depth buffer's
representation." In practice, this means that unclamped depth
values are clamped to the [0,1] range when used with a
conventional depth buffer so are effectively still clamped.)
If an application were to mix the two like this:
this would lead to generating interpolated depth values in a
[-1,+1] range. Because floating-point has more precision in the
neighborhood of zero, the depth buffer precision is concentrated
at zero in window-space Z. This corresponds to 0.5 in normalized
device coordinates.
Consider if our projection matrix mapped eye-space 2 to
clip-space 0.0 and eye-space 1000 to 1.0 with the Z matrix row:
[ 0 0 (n+f)/(n-f) f*n/(n-f) ]
so that
Zc = -0.5 = 0*x_e + 0*y_e + ((2+1000)/(2-1000))*z_e + (2*1000/(2-1000))*w_e
solving for z_e when w_e is one, means z_e equals -1.498
OpenGL 4.3 made a slightly incompatible change in the parameter
types for glDepthRange (and related commands) from clamped
floating-point types (GLclampd) to unclamped floating-point
types (GLdouble). Hence the functionality of glDepthRangedNV
also applies to OpenGL 4.3 in the case of floating-point depth
9) Can an application be guaranteed the exact same pixels being
rasterized when the clip control origin is GL_UPPER_LEFT versus
GL_LOWER_LEFT, except having the scanlines reversed?
RESOLVED: No such rasterization invariance is reasonable to
guarantee. Slight pixel variances are possible.
The polygon rasterization rules for OpenGL (section 14.6.1,
"Polygon Rasterization") states: In such a case [fragment's center
lies on a polygon boundary edge] we require that if two polygons
lie on either side of a common edge (with identical endpoints)
on which a fragment center lies, then exactly one of the polygons
results in the production of the fragment during rasterization."
The specification leaves it to implementations to define the
exact edge rule in this case. If the sense of Y in clip space
is flipped, this rule may be decided differently.
This is further complicated by multisampling where the sample pattern
is unlikely to be mirrored in the Y direction.
These issues are razor's edge cases and should not be an issue
for real applications.
10) Are all the possible combinations of glClipControl useful?
RESOLVED: Yes, the initial state (GL_LOWER_LEFT/
GL_NEGATIVE_ONE_TO_ONE) corresponds to OpenGL's traditional
The state GL_LOWER_LEFT/GL_ZERO_TO_ONE corresponds to OpenGL's
traditional origin and Direct3D's depth mode.
The state GL_UPPER_LEFT/GL_ZERO_TO_ONE corresponds to Direct3D's
clip volume definition.
The state GL_UPPER_LEFT/GL_NEGATIVE_ONE_TO_ONE is consistent with
the upper-left origin of the window coordinate system of Microsoft
Windows and the X Window System.
11) Should all the possible combinations of glClipControl
parameters supported be supported?
RESOLVED: Yes, all the combinations should be supported. The cost
is low and this provides orthogonality.
So it is legal to call:
12) Does setting the clip control origin to GL_UPPER_LEFT change the
origin of the window coordinate system use for commands such as
glViewport, glScissor, glWindowPos2i, and glReadPixels?
The (x,y) window space location passed to these commands have the
(0,0) origin at the lower left corner of the window, independent
of the state of the clip control origin.
So, for example, an application wanting a Direct3D upper-left orign
specifying the scissor with upper-left (x,y) coordinates would call:
window_height - upper_left_y,
window_width, window_height);
The rationale for this choice is to avoid confusion for how
window space coordinates are passed to commands. When rendering
to resizable windows, the window width and height can change
asychronously. This would mean the scissor command would need
to specify a "gravity" for the window origin. There would also
need to be a way to "query" this state relative to difference
origin conventions and subject asynchronous window resizes.
Moreover, this extension is not changing how window space is
specified but rather how clip space is specified.
13) Does the polygon stipple orientation change when the clip control
origin is set to GL_UPPER_LEFT?
14) Will using the GL_ZERO_TO_ONE clip control depth mode improve
my depth precision?
RESOLVED: Yes, if you use a floating-point depth buffer and
place the near and far values at 1.0 and 0.0 (reversed from the
normal convention).
But not much if you use a conventional fixed-point depth buffer.
This really depends on whether the particular hardware
implementation can numerically improve its depth interpolation
result. This depends on a lot of things including the quality
of the depth plane equation setup, the number of bits of
sub-pixel precision available, and how the depth interpolation
is performed.
With a conventional 24-bit fixed-point depth buffer, applications
may be able to achieve half a least significant bit (LSB) of
improved depth buffer precision.
There are typically far better strategies for improving depth
precision such as W-buffering, avoiding concatenation of the
modelview and projection matrices, and (probably the easiest)
better managing your scene's near and far planes.
With a floating-point depth buffer, it is more likely the
GL_ZERO_TO_ONE depth mode will improve depth precision.
Unfortunately in the conventional depth range [0,1], the
improvement is primarily close to the near plane where there
is already excessive precision. Reversing the depth range with
the command
glDepthRange(1.0, 0.0);
effectively reverses the near and far values in the depth
buffer. Also remember to reverse the depth function; so
glDepthFunc(GL_LESS) should become glDepthFunc(GL_GREATER).
However, this involves computing 1-Z which effectively truncates
far values (for much the same reason adding +0.5 does).
Alternatively, the reversal of near and far can happen as part
of the projection transformation so the depth range specified
with glDepthRange can be the conventional range [0,1]. Arguably
folding the near and far reversal into the projection matrix is
slightly better than reversing the depth range. However the
problem remains that a very large value is added with a small
value close to the far plane so effective depth precision is
not substantially improved with a fixed-point depth buffer but
has a substantial advantage for a floating-point depth buffer.
15) How does this extension interact with geometry shaders?
RESOLVED: If there is a geometry shader active, it is the
geometry shader which is actually writing the clip space position
(not the vertex shader).
One way to implement this extension (ignoring geometry shaders
for now) would be to add an epilogue to the application's vertex
shader to invert the clip space Y output when the clip control
origin is GL_UPPER_LEFT and perform a scale by 2 and bias by negative
clip space W to the clip space Z (biasing by negative clip space
W is like subtracting 1 in normalized device coordinates).
However, this epilogue would need to be moved to the geometry
shader if a geometry shader was active.
16) How does this extension interact with tessellation evaluation
shaders (without a geometry shader)?
RESOLVED: Then the epilogue discussed in issue #15 would need to
be added to the tessellation evaluation shader (and not the vertex
shader since it is really transforming patch control points).
If there was a geometry shader active, the geometry shader is
where the epilogue would be done.
17) Does the discussion of the use an epilogue in the last two issues
mean using the GL_UPPER_LEFT or GL_ZERO_TO_ONE modes is
necessarily slower?
RESOLVED: Generally no.
GPUs that support Direct3D are expected to have a mode to support
GL_UPPER_LEFT and GL_ZERO_TO_ONE at full speed and OpenGL
implementations for such GPUs should operate at full speed.
18) Should the clip control state be changed frequently?
RESOLVED: Most applications are expected to set the clip control
conventions once; for example, to match the Direct3D conventions.
Some implementations may introduce a flush when changing the
clip control state. Hence frequent clip control changes are
not recommended.
No flush is explicitly required when the clip control changes
and some implementations (NVIDIA) will have no significant
performance penalty for changing the clip control state.
19) Issue #6 addresses fixed-function vertex processing adjustments
under different clip control modes. How would a GLSL vertex
shader be adjusted, assuming how the shader computes its
clip-space position does not change, for different clip control
RESOLVED: The following GLSL epilogues could be added...
If the clip control origin is GL_UPPER_LEFT, you could add a final
operation to negate the clip-space Y component. So:
gl_Position.y *= -1;
If the clip control depth mode is GL_ZERO_TO_ONE, you
could scale and bias the conventional [-1,+1] range of
normalized-device-coordinate-space Z to the [0,1] range like
gl_Position.z = 0.5*gl_Positon.z + 0.5*gl_Position.w;
z_ndc = z_c / w_c
so the epilogue above computes an adjusted z_ndc':
z_ndc' = (0.5*z_c + 0.5+w_c)/w_c
which is the same as:
z_ndc' = 0.5*z_c/w_c + 0.5
= 0.5*z_ndc + 0.5
and scaling a [-1,+1] range by 0.5 and biasing by 0.5 computes
a linear mapping to the range [0,1].
Alternatively, rather than adding an epilogue as described,
the adjustments above could be folded into the transform matrix
typically used to transform object-space to clip-space. This is
a faster approach since it avoids extra math operations in the
vertex shaders.
20) Explain the numerical advantage for potential increased depth
precision for the GL_ZERO_TO_ONE clip control depth mode.
RESOLVED: If the normal depth range sets near to 0.0 and far
to 1.0, this means the effective viewport transform for Z (see
section 13.6.1 "Controlling the Viewport") becomes an identity
mapping. So the mapping in GL_ZERO_TO_ONE depth mode is:
z_w = (f-n) * z_d + n
and when near (n) is 0.0 and far (f) is 1.0, this becomes simply:
z_w = z_d;
This identity mapping results in no lose or change in the
per-vertex window space position.
Contrast this with the same situation with the
GL_NEGATIVE_ONE_TO_ONE depth mode with the mapping:
z_w = (f-n)/2 * z_d + (n+f)/2
and when near (n) is 0.0 and far (f) is 1.0, this becomes simply:
z_w = 0.5 * z_d + 0.5
While multiplying z_d by 0.5 has no precision loss (ignoring
denorms, this scale simply decrements the exponent by 1 without
disturbing the mantissa). However a bias by 0.5 does distrurb
the floating-point precision (also see Issue #3), losing one
least-significant-bit (LSB) of precision.
21) What should the state to control the GL_NEGATIVE_ONE_TO_ONE
and GL_ZERO_TO_ONE convention be called?
An alternative would be GL_CLIP_Z_MODE but the convention
is well-established in the OpenGL API that Z values that are
interpreted as depth values are described as DEPTH.
22) Direct3D 8 and 9 have a window-space coordinate system where
pixel centers are centered on integer coordinates. OpenGL
(and Direct3D 10 and 11) position pixel centers at half-pixel
locations. Should ARB_clip_control account for the older Direct3D
integer pixel center convention?
RESOLVED: No, because existing functionality covers this...
The EXT_viewport_array extension (made a core part of OpenGL
with version 4.1) extends the viewport state to be specified as
floating-point (technically fixed-point) values. Prior to this
extension, the viewport parameters were integral.
With the EXT_viewport_array functionality, you can add a bias of
(0.5,0.5) to the viewport (x,y) to shift integer Direct3D 8/9
style window space locations to OpenGL's half-pixel convention.
If you had a Direct3D upper-left viewport (x,y), you'd match
the Direct3D clip-space AND window-space conventions like this:
const GLuint viewport_index = 0; // Prior to DirectX 10, there's only a single viewport
x + 0.5f, window_height - (y + view_height) + 0.5f,
view_width, view_height);
where window_height is the height of the window/surface in pixels.
Also note the EXT_fragment_coord_conventions (made a core part
of OpenGL with version 3.2) allows the window position varying
input to fragment shaders to reflect the Direct3D 9 window-space
convention. See that extension for details.
23) Does this extension's state affect user clip planes?
RESOLVED: No, user clip planes operate on eye-space coordinates
which are not affected by this extension's state.
24) Does this extension's state affect fixed-function fog?
RESOLVED: No, fixed-function fog operates on eye-space distance
which is not affected by this extension's state.
25) Does this extension's state affect the point sprite origin?
When the EXT_point_sprite functionality was promoted to a core
feature in OpenGL 2.0, the GL_POINT_SPRITE_ORIGIN state was added
to specify whether the 2D texture coordinate has a lower-left
(OpenGL's convention in EXT_point_sprite and NV_point_sprite)
or upper-left (Direct3D convention).
An application wanting to emulate Direct3D's upper-left point
sprite texture coordinate origin should change the origin state
with an explicit point parameter command. Specifically:
This command is in addition to calling glClipControl and
specifying a GL_UPPER_LEFT origin.
26) Issue #12 says the origin for glWindowPos2i and other glWindowPos*
commands is lower-left independent of the clip control state.
What about glRasterPos2i and other glRasterPos* commands?
RESOLVED: Yes, the raster position specified by glRasterPos2i,
etc. is affected by the clip control state because the
object-space position is transformed and clipped just as a point
vertex position would be to arrive at the clip-space raster
position that is further transformed to window space.
27) Is the depth value specified for glClearDepth affected by this
extension's clip control state?
RESOLVED: No, glClearDepth takes a window-space depth value.
This extension only affects how clip space clipping and the
transformation from clip space to window space operates.
Likewise depth values read (glReadPixels), drawn (glDrawPixels),
or copied (glCopyPixels, glBlitFramebuffer) are unaffected by
this extension's clip control state.
28) Does this extension's state affect the operation of polygon
RESOLVED: No, polygon offset operates on window-space depth
values. This extension's clip control state operates prior
to polygon offset.
29) Can glClipControl be display listed?
30) Should the command be glClipParameteri to anticipate more
control of clipping state?
RESOLVED: No. Given over 20 years with basically zero extensions
in the area of clipping state, we realistically don't anticipate
more clipping parameters. Even in the case of this extension, the
rationale for this extension is quite limited and not about adding
any "features" to clipping. Instead the purpose is simply to
match the conventions of Direct3D (not a functional change).
While Direct3D's convention is different from OpenGL, there
simply aren't any futher 3D APIs or standards which clip
Also glClipControl maintains consistency with the existing
glClipPlane command pattern for the clipping API.
Historically "Parameter" has been used for commands that affect
managed "object" state and/or have a speciailized "Get" query
command (glGetColorTableParameter*) rather than fixed-function
pipeline state. This isn't completely uniform (exceptions:
point parameters, patch parameters) but the vast majority of
fixed-function rendering state isn't set with gl*Parameter
style commands. When "Parameter" commands are used there
is typically a plurality of state settings with different
integer/float/double/boolean types. None of the situations
that justify gl*Parameter style commands are present in this
31) This extension is only useful if it is widely available. So how
easy would this extension be to implement?
RESOLVED: No special hardware is required due to the careful
way this extension is specified. The clip control functionality
could all be done by inexpensive epilogue math appended to the
last shader in the graphics pipeline. The Y inversion could be
performed as part of the viewport transform.
Given the prevalance of Direct3D-capable hardware, we expect
some hardware vendors will implement this extension with
special existing modes in their hardware to handle the Direct3D
conventions. However we emphasize no special hardware is required
and the performance benefit attributable to such hardware is
likely to be extremely meager.
With respect to Mesa3D and Gallium, Brian Paul observes: "This
extension should be pretty easy to implement in Mesa/gallium.
In Gallium we already have a state variable for Z 0/1 vs. -1/+1
clipping. And I think we could implement the Y origin via our
viewport state (which is specified in floats)."
32) Is support for the GL_UPPER_LEFT convention just to match
RESOLVED: No. Along with Windows/Direct3D/Direct2D, X11 and
Java also have upper-left graphics device coordinate systems.
OpenGL, PostScript, PHIGS, GKS, and Apple's Core Graphics
(Quartz 2D) have lower-left graphics device coordinate systems.
33) When rendering to off-screen framebuffer objects (FBOs) that
will subsequently be textured from, how do I make sure the texture
coordinate origin and the window space origin are consistent?
RESOLVED: Use GL_LOWER_LEFT for the origin parameter of
glClipControl in this case. Use the GL_UPPER_LEFT for the
origin parameter when matching Direct3D's origin *and* drawing
into a window framebuffer to be directly presented.
34) Can you provide an example illustrating how applications using the
coordinate system conventions of Direct3D map onto this extension?
RESOLVED: Consider a Direct3D application rendering a triangle ABC
(with counter-clockwise orientation) to a viewport in the upper-left
quadrant of the destination surface. The surface (with Direct3D
window coordinates) is illustrated here.
(0,0) (960,0) (1920,0)
|^ Y_c == +W_c ^ | |
| | |
| | |
| | |
|v Y_c == -W_c v | |
| | |
| | |
| | |
| | |
| | |
(0,1080) (1920,1080)
In this example, assume vertices A, B, and C have clip coordinates of:
A = (+0.0, +1.0, +0.5, +1.0)
B = (-0.8, -1.0, +0.5, +1.0)
C = (+0.8, -1.0, +0.5, +1.0)
Direct3D's coordinate transformations are functionally similar to
OpenGL's, except that (a) the Y coordinate is inverted as part of the
viewport transformation mapping normalized device coordinates (NDCs)
to window coordinates and (b) the depth range transformation maps Z==0
to the near value instead of halfway between near and far as in
Because of the Y inversion from (a), vertices in Direct3D with a Y NDC
of -1.0 map to the bottom of the viewport (larger Y window coordinates
in the Direct3D coordinate system). This is exactly like OpenGL
windowed rendering, where a Y NDC of -1 maps to smaller Y window
coordinates (bottom) in the OpenGL coordinate system. Thanks to this
inversion in the Direct3D viewport transformation, rendering a
Direct3D scene with the same coordinates and matrices in OpenGL will
produce an image with identical vertical orientation and winding
(CW/CCW). However, since the viewport rectangle itself is programmed
in window coordinates, a Direct3D-centric viewport of (0,0,960,540)
needs to be flipped to (0,540,960,540) to work in OpenGL.
Additionally, to get identical near/far clipping and Z values, it's
necessary to use the ZERO_TO_ONE mode in this extension to have OpenGL
process Z coordinates identically to Direct3D.
When rendering to off-screen surfaces later used as textures, the
issue is a little bit more complex. A Direct3D application will use
the texture coordinates (0,0) to refer to the upper left corner of the
upper leftmost pixel of the image. However, in OpenGL, texture
coordinates of (0,0) refer to the lower-left corner of the
lower-leftmost pixel of the image. One way to compensate for this is
to remap the <t> texture coordinate with:
t_OpenGL = 1.0 - t_Direct3D
Unfortunately, that requires a modification to shaders or other input
data in the application. Instead of doing this, the UPPER_LEFT mode
in this extension provides a simple way to use Direct3D texture
coordinate conventions -- by rendering the entire scene *upside-down*
from the point of view of OpenGL. The image we want to produce using
this technique (below) is a vertically inverted version of the
previous image, where OpenGL lower-left window coordinates are
depicted in the figure.
(0,1080) (1920,1080)
| | |
| | |
| | |
| | |
| | |
|v Y_c == -W_c v | |
| | |
| | |
| | |
|^ Y_c == +W_c ^ | |
(0,0) (960,0) (1920,0)
In this example, the UPPER_LEFT mode in this extension inverts the
geometry as part of the transformation from clip coordinates to NDCs,
so that vertex A has a Y NDC of -1.0 instead of +1.0. This puts A at
the bottom of the viewport, while B and C remain at the top. One
thing to note is that the inversion changes the orientation of
triangle ABC, which is now clockwise instead of counter-clockwise. To
compensate, this extension also inverts the value computed to compute
face direction when in UPPER_LEFT mode. The one other thing to note
here is that when rendering this way, the Direct3D viewport should be
used as-is in OpenGL.
Note that a similar inversion technique can be used to implement
OpenGL FBO rendering on graphics hardware supporting only Direct3D
coordinate systems. If this technique is used on an implementation
doing something like this, the two inversions cancel each other out.
35) Does this extension affect the primitive's winding order in tessellation
evaluation shader when origin is changed to GL_UPPER_LEFT?
RESOLVED: No, the winding order is not affected. If a change in winding
order of the primitive is needed, it must be done from the tessellation
shader explicitly.
Revision History
Rev. Date Author Changes
---- -------- --------- ----------------------------------------------
3 04/26/13 mjk Add issues 15 to 21
4 04/30/13 mjk Add issue 22
5 05/01/13 mjk Add issues 22 to 28, fix typos
6 05/09/13 mjk Add issue 29 to 31
7 05/13/13 pdaniell Internal revisions
8 05/13/13 mjk Valve feedback; change to KHR in issues
9 05/13/13 mjk Change to KHR in issues
10 05/28/13 pdaniell Fold in feedback from Mark Callow in bug 10245
11 05/30/13 pdaniell Internal revisions
12 06/06/13 pdaniell Internal revisions
13 06/17/13 pdaniell Fix the enum token values
14 07/03/13 mjk D3D off-screen discussion; issue 32 and 33
15 04/16/14 pdaniell Prepare spec for OpenGL 4.5
16 04/17/14 pdaniell Fixes "UPPER_RIGHT" typos to UPPER_LEFT
17 07/30/14 pbrown Fix incorrect language in the overview
describing when to use UPPER_LEFT and LOWER_LEFT
modes; add detailed examples in issue 34.
18 09/17/15 Jon Leech Correct typo in issue 7 and add contributor
Brano Kemen from that issue.
19 04/06/18 Vikram Add issue 35