<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-GB link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Paul<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
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. <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
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?<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>JB<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></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;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> vtk-developers-bounces@vtk.org
[mailto:vtk-developers-bounces@vtk.org] <b>On Behalf Of </b>Paul Harris<br>
<b>Sent:</b> 03 November 2009 07:51<br>
<b>To:</b> vtk-developers@vtk.org<br>
<b>Subject:</b> [vtk-developers] Depth buffer and near plane clipping<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></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">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<o:p></o:p></p>
</div>
</div>
</body>
</html>