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