1Name 2 3 ARB_depth_clamp 4 5Name Strings 6 7 GL_ARB_depth_clamp 8 9Contact 10 11 Jon Leech (jon 'at' alumni.caltech.edu) 12 Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) 13 14Notice 15 16 Copyright (c) 2009-2013 The Khronos Group Inc. Copyright terms at 17 http://www.khronos.org/registry/speccopyright.html 18 19Status 20 21 Complete. Approved by the ARB on July 3, 2009. 22 23Version 24 25 Version 3, 2009/08/02. 26 Based on NV_depth_clamp version 4, modified 2003/01/08. 27 28Number 29 30 ARB Extension #61 31 32Dependencies 33 34 Written based on the wording of the OpenGL 3.1 specification. 35 36 ARB_compatibility affects the behavior of this extension. 37 38Overview 39 40 Conventional OpenGL clips geometric primitives to a clip volume 41 with six faces, two of which are the near and far clip planes. 42 Clipping to the near and far planes of the clip volume ensures that 43 interpolated depth values (after the depth range transform) must be 44 in the [0,1] range. 45 46 In some rendering applications such as shadow volumes, it is useful 47 to allow line and polygon primitives to be rasterized without 48 clipping the primitive to the near or far clip volume planes (side 49 clip volume planes clip normally). Without the near and far clip 50 planes, rasterization (pixel coverage determination) in X and Y 51 can proceed normally if we ignore the near and far clip planes. 52 The one major issue is that fragments of a primitive may extend 53 beyond the conventional window space depth range for depth values 54 (typically the range [0,1]). Rather than discarding fragments that 55 defy the window space depth range (effectively what near and far 56 plane clipping accomplish), the depth values can be clamped to the 57 current depth range. 58 59 This extension provides exactly such functionality. This 60 functionality is useful to obviate the need for near plane capping 61 of stenciled shadow volumes. The functionality may also be useful 62 for rendering geometry "beyond" the far plane if an alternative 63 algorithm (rather than depth testing) for hidden surface removal is 64 applied to such geometry (specifically, the painter's algorithm). 65 Similar situations at the near clip plane can be avoided at the 66 near clip plane where apparently solid objects can be "seen through" 67 if they intersect the near clip plane. 68 69Issues 70 71 Another way to specify this functionality is to describe it in terms 72 of generating the equivalent capping geometry that would need to be 73 drawn at the near or far clip plane to have the same effect as not 74 clipping to the near and far clip planes and clamping interpolated 75 depth values outside the window-space depth range. Should the 76 functionality be described this way? 77 78 RESOLUTION: No. Describing the functionality as capping is 79 fairly involved. Eliminating far and near plane clipping and 80 clamping interpolated depth values to the depth range is much 81 simpler to specify. 82 83 Should depth clamping affect points or just line and polygon geometric 84 primitives? 85 86 RESOLUTION: All geometric primitives are affected by depth 87 clamping. 88 89 In the case of points, if you render a point "in front of" the 90 near clip plane, it should be rendered with the zw value min(n,f) 91 where n and f are the near and far depth range values if depth 92 clamping is enabled. Similarly, a point "behind" the far clip 93 plane should be rendered with the zw value max(n,f). 94 95 How should the setting of the raster position function when depth 96 clamping is enabled? 97 98 RESOLUTION: When setting the raster position, clamp the raster 99 position zw to the range [min(n,f),max(n,f)] where n and f are 100 the near and far depth range values. 101 102 This rule ensures that the raster position zw will never be outside 103 the [0,1] range (because n and far are clamped to the [0,1] range). 104 We specify the raster position to be updated this way because 105 otherwise a raster position zw could be specified outside the [0,1] 106 range when depth clamping is enabled, but then if depth clamping 107 is subsequently disabled, that out-of-range raster position zw 108 could not be written to the depth buffer. 109 110 This semantic can make for some unexpected semantics that are 111 described here. Say that depth clamping is enabled and the raster 112 position is set to point behind the far clip plane such that the 113 pre-clamped zw is 2.5. Because depth clamping is enabled the 114 raster position zw is clamped to the current near and far depth 115 range values. Say these values are 0.1 and 0.9. So 2.5 is clamped 116 to 0.9. 117 118 Now consider what happens if a bitmap (or image rectangle) is 119 rendered with depth testing enabled under various situations. 120 If depth clamping remains enabled and the depth range is unchanged, 121 the bitmap fragments are generated with a zw of 0.9. 122 123 However, if depth range is subsequently set to 0.2 and 0.8 and 124 depth clamping is enabled, the bitmap fragments will have their 125 zw depth component clamped to 0.8. But if the depth range was 126 changed to 0.2 and 0.8 but depth range clamped is disabled, the 127 bitmap fragments will have a 0.9 zw depth component since then 128 the depth clamping is then not applied. 129 130 What push/pop attrib bits should affect the depth clamp enable? 131 132 RESOLUTION: GL_ENABLE_BIT and GL_TRANSFORM_BIT. 133 134 How does depth clamping interact with depth replace operations (say 135 from NV_texture_shader)? 136 137 RESOLUTION: The depth clamp operation occurs as part of the depth 138 test so depth clamping occurs AFTER any depth replace operation 139 in the pipeline. A depth replace operation can reassign the 140 fragment's zw, but depth clamping if enabled will subsequently 141 clamp this new zw. 142 143 Does depth clamping affect read/draw/copy pixels operations involving 144 depth component pixels? 145 146 RESOLUTION: No. 147 148 Does depth clamping occur after polygon offset? 149 150 RESOLUTION: Yes. Depth clamping occurs immediately before the 151 depth test. 152 153 Can fragments with wc<=0 be generated when this extension is supported? 154 155 RESOLUTION: No. The OpenGL Specification was revised in 2006/08 to 156 remove explicit references to w_c <= 0, since the clip volume test 157 disallows all such vertices. Corresponding language has been 158 removed from this extension specification as well. Such fragments 159 should never be generated. 160 161New Procedures and Functions 162 163 None 164 165New Tokens 166 167 Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, 168 and by the <pname> parameter of GetBooleanv, GetIntegerv, 169 GetFloatv, and GetDoublev: 170 171 DEPTH_CLAMP 0x864F 172 173Additions to Chapter 2 of the OpenGL 3.1 Specification (OpenGL Operation) 174 175 -- Section 2.17 "Clipping" 176 177 Add to the end of the 3rd paragraph: 178 179 "Depth clamping is enabled with the generic Enable command and 180 disabled with the Disable command. The value of the argument to 181 either command is DEPTH_CLAMP. If depth clamping is enabled, the 182 "-w_c <= z_c <= w_c" plane equation are ignored by view volume 183 clipping (effectively, there is no near or far plane clipping)." 184 185 186 If and only if the ARB_compatibility extension is supported: 187 188 -- Section 2.22 "Current Raster Position" 189 190 Add to the end of the 4th paragraph: 191 192 "If depth clamping (see section 2.11) is enabled, then raster 193 position z_w is first clamped to the range [min(n,f),max(n,f)], 194 where n and f are the current near and far depth range values (see 195 section 2.12.1)." 196 197Additions to Chapter 3 of the OpenGL 3.1 Specification (Rasterization) 198 199 None 200 201Additions to Chapter 4 of the OpenGL 3.1 Specification (Per-Fragment Operations 202and the Framebuffer) 203 204 -- Section 4.1.5 "Depth buffer test" 205 206 Add to the end of the 2nd paragraph: 207 208 "If depth clamping (see section 2.17) is enabled, before the 209 incoming fragment's z_w is compared z_w is clamped to the range 210 [min(n,f),max(n,f)], where n and f are the current near and far 211 depth range values (see section 2.12.1)." 212 213Additions to Chapter 5 of the OpenGL 3.1 Specification (Special Functions) 214 215 None 216 217Additions to Chapter 6 of the OpenGL 3.1 Specification (State and State Requests) 218 219 None 220 221Additions to the AGL/GLX/WGL Specifications 222 223 None 224 225GLX Protocol 226 227 None 228 229Errors 230 231 None 232 233New State 234 235Add to table 6.7, transformation state 236 237Get Value Type Get Command Initial Value Description Sec Attribute 238-------------- ---- ----------- ------------- -------------- ------ ---------------- 239DEPTH_CLAMP B IsEnabled False Depth clamping 2.12.2 transform/enable 240 on/off 241 242New Implementation Dependent State 243 244 None 245 246Interactions with ARB_compatibility 247 248 If ARB_compatibility is not supported, the language about current 249 raster position in section 2.22 is removed. 250 251Revision History 252 253 Version 1, 2009/05/14 (Jon Leech) - rewrite NV_depth_clamp against 254 OpenGL 3.1 instead of OpenGL 1.2.1. Clarify which functionality only 255 applies to GL 3.1 + ARB_compatibility. Remove NV suffix and assign 256 ARB extension string in preparation for inclusion in OpenGL 3.2. 257 258 Version 2, 2009/05/15 (Jon Leech) - Note interaction with 259 ARB_compatibility. 260 261 Version 3, 2009/07/01 (Jon Leech) - Match core 3.2 spec updates, 262 removing w_c <= 0 language. Update corresponding issue to note this 263 was done to the core spec in 2006/08. 264 265 Version 4, 2009/08/02 (Jon Leech) - Assign ARB extension number. 266