Hi John,<br><br><div class="gmail_quote">2009/11/3 Biddiscombe, John A. <span dir="ltr"><<a href="mailto:biddisco@cscs.ch">biddisco@cscs.ch</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-GB" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Paul</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">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. </span></p></div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">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.</span></p></div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">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?</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p></div></div></blockquote><div>My guess was</div><div>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.</div>
<div>or</div><div>b) not many people use parallel projection unless its with a flat image in front of the camera</div><div><br></div><div>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.</div>
<div><br></div><div>thanks,</div><div>Paul</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-GB" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">JB</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt">From:</span></b><span lang="EN-US" style="font-size:10.0pt"> <a href="mailto:vtk-developers-bounces@vtk.org" target="_blank">vtk-developers-bounces@vtk.org</a>
[mailto:<a href="mailto:vtk-developers-bounces@vtk.org" target="_blank">vtk-developers-bounces@vtk.org</a>] <b>On Behalf Of </b>Paul Harris<br>
<b>Sent:</b> 03 November 2009 07:51<br>
<b>To:</b> <a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a><br>
<b>Subject:</b> [vtk-developers] Depth buffer and near plane clipping</span></p>
</div>
</div><div><div></div><div class="h5">
<p class="MsoNormal"> </p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi all,<br>
<br>
Could someone please explain to me this bit of code from vtkRenderer.cxx, about
line 1162<br>
<br>
if (range[0] < this->NearClippingPlaneTolerance*range[1])<br>
{<br>
range[0] = this->NearClippingPlaneTolerance*range[1];<br>
}<br>
<br>
I've been thinking about it, in relation to this bug report:<br>
<a href="http://public.kitware.com/Bug/view.php?id=7823" target="_blank">http://public.kitware.com/Bug/view.php?id=7823</a><br>
<br>
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.<br>
Why don't we bring the far-field clipping plane back towards us, and clip the
stuff that is a long way away?<br>
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).<br>
<br>
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'.<br>
<br>
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?<br>
<br>
thanks,<br>
Paul</p>
</div></div></div>
</div>
</div>
</blockquote></div><br>