Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 4 of 4 FirstFirst ... 234
Results 31 to 35 of 35

Thread: Customized clipping volume

  1. #31
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    600
    Quote Originally Posted by Yandersen View Post
    kRogue, let's not try to estimate how much sand it will cost unless you are the one who actually writes machine codes for the GPU or the designer of those chips.
    I am not estimating as I have consulted those that have been hardware engineers. Even now, clipping from user defined clip distances for much hardware out there is horror slow implemented and the thing still takes up lots of gates.

    The brutal part is this: the main use case (z-fighting near the eye) you are after can actually be implemented by floating point depth buffer already together with an infinite far plane (which is just a different projection matrix).

    Personally, I'd like to modify the beans for normalized z, where the value for depth buffer is taken from the z after w-divide directly and the clip values for that z are user defined, or even possibly disabled. This makes perfect sense with a floating point depth buffer (which everyone implements), has minimal hardware intrusions (and is infact trivial to implement). That alone would give you what you are after since floating point has built into it different degrees of accuracy.

  2. #32
    Junior Member Regular Contributor
    Join Date
    Dec 2010
    Location
    Oakville, ON, CA
    Posts
    107
    Quote Originally Posted by kRogue View Post
    I am not estimating as I have consulted those that have been hardware engineers. Even now, clipping from user defined clip distances for much hardware out there is horror slow implemented and the thing still takes up lots of gates.
    Well, sounds like removing redundant far clipping plane may benefit the rendering speed.
    Quote Originally Posted by kRogue View Post
    The brutal part is this: the main use case (z-fighting near the eye) you are after can actually be implemented by floating point depth buffer already together with an infinite far plane (which is just a different projection matrix).
    Can you be more specific, please? I am interested. Isn't your solution the same as mine on the previous page:
    Quote Originally Posted by Yandersen View Post
    The best workaround for high zFar/zNear values, I think, would be:
    1) using the FP depth buffer,
    2) glDepthFunc(GL_GREATER),
    3) glClipControl(...,GL_ZERO_TO_ONE),
    4) the following projection matrix:
    Code :
        | f/aspect  0      0      0    |
        |                              |
        |    0      f      0      0    |
    P = |                              |
        |    0      0      0    zNear  |
        |                              |
        |    0      0     -1      0    |
    where f = ctan(ViewAngleVertical/2),
    aspect = Viewport.x / Viewport.y,
    zNear: distance to the near clipping plane; this value could be very small (in 1e-XX range).

    This setup will cull all the geometry behind the near clipping plane, and the resulting depth will decrease as the object get drawn further away asymptotically approaching 0 for the infinitely distant objects.
    Obviously that will only work for FP buffers heavily exploiting the exponent part of the numbers in it's negative range (Xe-XXX), because 99% of depth values will be less than 0.000...

  3. #33
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    600
    yep something like that.

    The best case for this to be shiny is what I said for extension: ability to disable z-clipping without clamping the value. This would avoid the near plane issue, and I am not worried about w being close to zero since the clip bits -w <= x <= w and -w <=y <=w make sure w is not zero anyways. That would require that the depth buffer is FP32 (or some other floating point format) and some hairy icky things to handle really big numbers and likewise very small (unnormalized) numbers too.

  4. #34
    Junior Member Regular Contributor
    Join Date
    Dec 2010
    Location
    Oakville, ON, CA
    Posts
    107
    Actually, this will work only if z values are mapped from [0...1] range to [0...1] depth values directly, because in case of [-1...1] to [0...1] mapping the addition of 0.5 will kill the precision of Xe-XX values, therefore glClipControl(...,GL_ZERO_TO_ONE) is a must, otherwise FP buffer will work as 23bpp integer buffer.
    The equations "-w <= x <= w and -w <=y <=w" do not ensure "w is not zero" at all. In fact, those 4 clipping planes constrain viewing volume into two inverted point-connected frustums. But do not worry, this equation cuts the back frustum:

    0 <= zNear <= -z

    So all geometry behind the near clipping plane is clipped. The left part of the equation (0<=zNear) is always true, therefore there is no far clipping plane. But even without glClipControl the equation above will produce the same result:

    z <= zNear <= -z

    because the second part is just a more strict limit of the first part of the equation. However, the result with FP depth buffer will not be any better than with 24bpp integer depth buffer. In any case, the resulting Zc will be 1.0 for the points at near clipping plane and it will be lower for further points, producing Zc values in range [1...0), not [-1...1]. That is the another reason to use glClipControl with such setup.

    The glClipControl-enabling extension is not available to me yet, so I keep playing games waiting for Xmas to come...
    Last edited by Yandersen; 09-05-2014 at 08:02 AM.

  5. #35
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    600
    um,

    The clipping equations:

    -w <= x <= w
    -w <= y <= w
    -w <= z <= w

    do just as good job of avoiding w being small as

    -w <= x <= w
    -w <= y <= w

    in practice. Now the main pain is when x and y are close to zero and w is too, that means w is tiny positive and the fragment is close to the center of the viewport. This case is handled by hardware already [in particular, when depth clamping is enabled those are the effective clip planes]

    Just to be clear: there is no "near clipping plane" in the hardware really, it is just clipped in clip space. The concept of near clipping plane comes from what happens to the condition -w <= z when inverted through a traditional projection matrix.

    For the z-stuff, one does not need this clip control thing, one just needs the ability to allow for the normalized z-value to be unbounded (instead of [-1,1] or [0,1]) and to disable the clip equations in clipping. Together with FP32 depth buffer, one is done completely for the use cases I think you are after. This change is tiny and relatively trivial to implement. In short this is what is needed:

    • glDepthRange to accept values outside of [0,1]
    • ability to turn off one or both clip conditions -w<=z, z<=w.

    That is all you need.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •