[vtk-developers] Depth buffer and near plane clipping

[Paul Harris]

Hi John,

2009/11/3 Biddiscombe, John A. <biddisco at cscs.ch>

>  Paul
>
>
>
> I think the main reason is that the calculation for depth is done by
> Val/NearPlaneDist – when the near plane is very close to zero, the accuracy
> of the overall Z depth starts to fall apart. [you need (far-near)/near bins
> of Z and only 32 bits to store them in – large far and small near causes
> trouble] – my memory is failing and I expect you’ll get a better answer once
> someone reads this and gasps in horror at what I’ve written.
>

or 16 bits, apparently, which is all this algorithm tests for I think.  I
saw some old code, it used to test for 24 bits.  I am not sure if it tests
for 32bits, i got hung up on the unexplained "0.001" threshold.  I think it
only tests for 8 or 16 bit depths, but I'm probably wrong.


> Having said that, if you are having trouble with near objects being clipped
> and have a better algorithm to throw away far ones, then implement it, add
> an option to turn it on and contribute it as I’m sure others will like to
> try it.
>

To do that, I would need to understand the reasoning behind the current
algorithm, and maybe even the location of the *other* code that does the
depth buffer binning... although that code might be built into the GPU,
rather than VTK.


>  NB. I didn’t read the bug report carefully – but it looks like a fix for
> parallel projection mode is  there – I wonder why it hasn’t been looked at
> in a year?
>
>
>
My guess was
1) the original bug fix had a patch for old code.  i have attempted to
remedy this with a new unified patch against the CVS trunk, I think i have
accurately translated it.
or
b) not many people use parallel projection unless its with a flat image in
front of the camera

In a month or so, I will be using parallel projection with a set of actors
in 3d space (including your sprite-mapper), so its in my interest to work
this out.

thanks,
Paul




>  JB
>
>
>
>
>
>
>
>
>
> *From:* vtk-developers-bounces at vtk.org [mailto:
> vtk-developers-bounces at vtk.org] *On Behalf Of *Paul Harris
> *Sent:* 03 November 2009 07:51
> *To:* vtk-developers at vtk.org
> *Subject:* [vtk-developers] Depth buffer and near plane clipping
>
>
>
> Hi all,
>
> Could someone please explain to me this bit of code from vtkRenderer.cxx,
> about line 1162
>
>   if (range[0] < this->NearClippingPlaneTolerance*range[1])
>     {
>     range[0] = this->NearClippingPlaneTolerance*range[1];
>     }
>
> I've been thinking about it, in relation to this bug report:
> http://public.kitware.com/Bug/view.php?id=7823
>
> I'm interested in WHY the decision has been made to "push" the near-field
> clipping plane out further when the depth range is too broad.
> Why don't we bring the far-field clipping plane back towards us, and clip
> the stuff that is a long way away?
> If we do that, then what should range[1] be reset to when range[0] is zero
> ?  (ie we have objects at or behind the camera, I would expect to see all
> the objects immediately in front of the camera).
>
> I find it annoying when you have an object close to the camera (but not
> behind the camera) that is clipped when you also have object a long long way
> away.  My focus is on the near-field object, not the far-field object, yet
> it is the one that is 'punished'.
>
> The Tolerance for 16-bit depth buffers is set to 0.001, which seems
> arbitrary to me.  Is this a value based on experience rather than
> calculated?
>
> thanks,
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20091104/30d2746e/attachment.html>