<HTML>
Lisa Sobierajski Avila wrote:
<BLOCKQUOTE TYPE=CITE>Hello Malcolm,
<P>If under "normal" circumstances (meaning your data has reasonable bounds
<BR>and is not pushing the limits of precision) you are seeing bad images
due
<BR>to the clipping range, then we probably should tweak
<BR>ResetCameraClippingRange(). It does attempt to determine the depth
buffer
<BR>depth and base the minimum near value on that. How deep is your depth
<BR>buffer? What are the near / far values when you see a bad image?
<P>Thanks,
<P>Lisa
<P>At 04:02 PM 3/23/2001, Malcolm Drummond wrote:
<BR>>I have also just upgraded from vtk24. Some apparent degradation may
be due
<BR>>to a more generous automated camera clipping range in vtk31. On some
of my
<BR>>datasets this results in polygon flickering with camera movement (as
the
<BR>>depth resolution is not fine enough) and "ragged" intersections. My
<BR>>immediate fix was to introduce near range-clamping methods to the
camera, as
<BR>>this affects depth resolution (I didn't want to mess with the renderers
<BR>>ResetCameraClippingRange() - but that might be another route to go).
I've
<BR>>attached my files.
<BR>>
<BR>>The methods are ...
<BR>>
<BR>>// Description:
<BR>> // Set/Get clamping of ClippingRange[0]. Prevents value
<
<BR>>ClipRangeNearClampValue.
<BR>> vtkSetMacro(ClippingRangeNearClamping,int);
<BR>> vtkGetMacro(ClippingRangeNearClamping,int);
<BR>> void ClippingRangeNearClampingOn();
<BR>> void ClippingRangeNearClampingOff();
<BR>>
<BR>> // Description:
<BR>> // Set/Get value to clamp ClippingRange[0] by.
<BR>> vtkSetMacro(ClippingRangeNearClampValue,double);
<BR>> vtkGetMacro(ClippingRangeNearClampValue,double);
<BR>>
<BR>>You can test if depth resolution is a problem via tcl script, just
reset the
<BR>>camera range via the interactive command window and see if there's
any
<BR>>remarkable change when you render (but call the render through the
command
<BR>>window - using the mouse to force a render could cause the renderer
to
<BR>>recompute the bounds and reset the camera to the old range again).
<BR>>
<BR>>I don't know if this is the best solution ... it just worked in a
hurry. If
<BR>>the Gurus think it's OK I'll introduce ClippingRangeFarClamping etc.for
<BR>>completeness and submit the code.
<BR>></BLOCKQUOTE>
I think I have something to contribute here but I'm joining the discussion
late.
<BR>There is an aritcle called "W Pleasure, W Fun" in the May/June IEEE CG&A
<BR> magazine in which Jim Blinn demonstrates that the location of
the near
<BR> clipping plane must be a significant fraction (at least .3) of
the far clipping
<BR> plane location for Z buffering to be accurate when PERSPECTIVE
projections
<BR> are used. Interestingly (see Fig 3b) things get even
worse when high precision
<BR> floating point is used ! The problem is that the perspective
projection causes
<BR> points projected to screen space to be spaced non-linearly relative
to the
<BR> points in eye space to which they correspond.
<P> Dave
<P> Dave
<BR>
<PRE>--
David E Jones
Du Pont Central Research
Experimental Station, Bldg 320
Wilmington, DE 19880-0320</PRE>
</HTML>