back  Return to list

GL_NV_depth_clamp
homeprevnext Name
  
    NV_depth_clamp  
  
homeprevnext Name Strings
  
    GL_NV_depth_clamp  
  
homeprevnext Contact
  
    Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com)  
  
homeprevnext Notice
  
    Copyright NVIDIA Corporation, 2001.  
  
homeprevnext Status
  
    Shipping  
  
homeprevnext Version
  
    Last Modified Date:  $Date: 2003/01/08 $  
    NVIDIA Revision: $Revision: #4 $  
  
homeprevnext Number
  
    260  
  
homeprevnext Dependencies
  
    Written based on the wording of the OpenGL 1.2.1 specification.  
  
homeprevnext Overview
  
    Conventional OpenGL clips geometric primitives to a clip volume  
    with six faces, two of which are the near and far clip planes.  
    Clipping to the near and far planes of the clip volume ensures that  
    interpolated depth values (after the depth range transform) must be  
    in the [0,1] range.  
  
    In some rendering applications such as shadow volumes, it is useful  
    to allow line and polygon primitives to be rasterized without  
    clipping the primitive to the near or far clip volume planes (side  
    clip volume planes clip normally).  Without the near and far clip  
    planes, rasterization (pixel coverage determination) in X and Y  
    can proceed normally if we ignore the near and far clip planes.  
    The one major issue is that fragments of a  primitive may extend  
    beyond the conventional window space depth range for depth values  
    (typically the range [0,1]).  Rather than discarding fragments that  
    defy the window space depth range (effectively what near and far  
    plane clipping accomplish), the depth values can be clamped to the  
    current depth range.  
  
    This extension provides exactly such functionality.  This  
    functionality is useful to obviate the need for near plane capping  
    of stenciled shadow volumes.  The functionality may also be useful  
    for rendering geometry "beyond" the far plane if an alternative  
    algorithm (rather than depth testing) for hidden surface removal is  
    applied to such geometry (specifically, the painter's algorithm).  
    Similar situations at the near clip plane can be avoided at the  
    near clip plane where apparently solid objects can be "seen through"  
    if they intersect the near clip plane.  
  
homeprevnext Issues
  
    Another way to specify this functionality is to describe it in terms  
    of generating the equivalent capping geometry that would need to be  
    drawn at the near or far clip plane to have the same effect as not  
    clipping to the near and far clip planes and clamping interpolated  
    depth values outside the window-space depth range.  Should the  
    functionality be described this way?  
  
      RESOLUTION:  No.  Describing the functionality as capping is  
      fairly involved.  Eliminating far and near plane clipping and  
      clamping interpolated depth values to the depth range is much  
      simpler to specify.  
  
    Should depth clamping affect points or just line and polygon geometric  
    primitives?  
  
      RESOLUTION:  All geometric primitives are affected by depth  
      clamping.  
  
      In the case of points, if you render a point "in front of" the  
      near clip plane, it should be rendered with the zw value min(n,f)  
      where n and f are the near and far depth range values if depth  
      clamping is enabled.  Similarly, a point "behind" the far clip  
      plane should be rendered with the zw value max(n,f).  
  
    How should the setting of the raster position function when depth  
    clamping is enabled?  
  
      RESOLUTION:  When setting the raster position, clamp the raster  
      position zw to the range [min(n,f),max(n,f)] where n and f are  
      the near and far depth range values.  
  
      This rule ensures that the raster position zw will never be outside  
      the [0,1] range (because n and far are clamped to the [0,1] range).  
      We specify the raster position to be updated this way because  
      otherwise a raster position zw could be specified outside the [0,1]  
      range when depth clamping is enabled, but then if depth clamping  
      is subsequently disabled, that out-of-range raster position zw  
      could not be written to the depth buffer.  
  
      This semantic can make for some unexpected semantics that are  
      described here.  Say that depth clamping is enabled and the raster  
      position is set to point behind the far clip plane such that the  
      pre-clamped zw is 2.5.  Because depth clamping is enabled the  
      raster position zw is clamped to the current near and far depth  
      range values.  Say these values are 0.1 and 0.9.  So 2.5 is clamped  
      to 0.9.  
  
      Now consider what happens if a bitmap (or image rectangle) is  
      rendered with depth testing enabled under various situations.  
      If depth clamping remains enabled and the depth range is unchanged,  
      the bitmap fragments are generated with a zw of 0.9.  
  
      However, if depth range is subsequently set to 0.2 and 0.8 and  
      depth clamping is enabled, the bitmap fragments will have their  
      zw depth component clamped to 0.8.  But if the depth range was  
      changed to 0.2 and 0.8 but depth range clamped is disabled, the  
      bitmap fragments will have a 0.9 zw depth component since then  
      the depth clamping is then not applied.  
  
    What push/pop attrib bits should affect the depth clamp enable?  
  
      RESOLUTION:  GL_ENABLE_BIT and GL_TRANSFORM_BIT.  
  
    How does depth clamping interact with depth replace operations (say  
    from NV_texture_shader)?  
  
      RESOLUTION:  The depth clamp operation occurs as part of the depth  
      test so depth clamping occurs AFTER any depth replace operation  
      in the pipeline.  A depth replace operation can reassign the  
      fragment's zw, but depth clamping if enabled will subsequently  
      clamp this new zw.  
  
    Does depth clamping affect read/draw/copy pixels operations involving  
    depth component pixels?  
  
      RESOLUTION:  No.  
  
    Does depth clamping occur after polygon offset?  
  
      RESOLUTION:  Yes.  Depth clamping occurs immediately before the  
      depth test.  
  
    Can fragments with wc<=0 be generated when this extension is supported?  
  
      RESOLUTION:  No.  The core OpenGL specification (section 2.11) is  
      worded to allow the possibility of generating fragments where wc<=0.  
      These should never be generated when this extension is supported.  
  
homeprevnext New Procedures and Functions
  
    None  
  
homeprevnext New Tokens
  
    Accepted by the <cap> parameter of Enable, Disable, and IsEnabled,  
    and by the <pname> parameter of GetBooleanv, GetIntegerv,  
    GetFloatv, and GetDoublev:  
  
        DEPTH_CLAMP_NV                                0x864F  
  
homeprevnext Additions to Chapter 2 of the OpenGL 1.2.1 Specification (OpenGL Operation)
  
 --  Section 2.11 "Clipping"  
   
    Add to the end of the 3rd paragraph:  
  
    "Depth clamping is enabled with the generic Enable command and  
    disabled with the Disable command.  The value of the argument to  
    either command is DEPTH_CLAMP_NV.  If depth clamping is enabled, the  
    "-wc <= zc <= wc" plane equation are ignored by video volume clipping  
    (effectively, there is no near or far plane clipping)."  
  
    Change the 8th paragraph to indicate that only wc>0 fragments should  
    be generated rather than even allowing the posibility that wc<=0  
    fragments may be generated:  
  
    "A line segment or polygon whose vertices have wc values of differing  
    signs may generate multiple connected components after clipping.  
    GL implementations are not required to handle this situation.  
    That is, only the portion of the primitive that lies in the region  
    of wc>0 should be produced by clipping."  
  
 --  Section 2.12 "Current Raster Position"  
   
    Add to the end of the 4th paragraph:  
  
    "If depth clamping (see section 2.11) is enabled, then raster position  
    zw is first clamped as follows.  If the raster postition's wc>0,  
    then zw is clamped the range [min(n,f),max(n,f)] where n and f are  
    the current near and far depth range values (see section 2.10.1)."  
  
homeprevnext Additions to Chapter 3 of the OpenGL 1.2.1 Specification (Rasterization)
  
    None  
  
homeprevnext Additions to Chapter 4 of the OpenGL 1.2.1 Specification (Per-Fragment Operations and the Framebuffer)
  
 --  Section 4.1.5 "Depth buffer test"  
   
    Add to the end of the 2nd paragraph:  
  
    "If depth clamping (see section 2.11) is enabled, before the incoming  
    fragment's zw is compared, zw must first be clamped as follows: If the  
    fragment's wc>0, then zw is clamped to the range [min(n,f),max(n,f)]  
    where n and f are the current near and far depth range values (see  
    section 2.10.1)."  
  
homeprevnext Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions)
  
    None  
  
homeprevnext Additions to Chapter 6 of the OpenGL 1.2.1 Specification (State and State Requests)
  
    None  
  
homeprevnext Additions to the AGL/GLX/WGL Specifications
  
    None  
  
homeprevnext GLX Protocol
  
    None  
  
homeprevnext Errors
  
    None  
  
homeprevnext New State
  
(table 6.7)  
Get Value       Type  Get Command  Initial Value  Description     Sec      Attribute  
--------------  ----  -----------  -------------  --------------  ------   ----------------  
DEPTH_CLAMP_NV  B     IsEnabled    False          Depth clamping  2.10.2   transform/enable  
                                                  on/off  
  
homeprevnext New Implementation Dependent State
  
    None  
  
homeprevnext Revision History
  
    None  
    None  
Valid XHTML 1.1! Valid CSS! Last update: November 14, 2006.
Cette page doit être lue avec un navigateur récent respectant le standard XHTML 1.1.