[vtkusers] Re: VTK24 vs. 312, quality and performance

[David E. Jones]

Lisa Sobierajski Avila wrote:

> Hello Malcolm,
>
> If under "normal" circumstances (meaning your data has reasonable bounds
> and is not pushing the limits of precision) you are seeing bad images due
> to the clipping range, then we probably should tweak
> ResetCameraClippingRange(). It does attempt to determine the depth buffer
> depth and base the minimum near value on that. How deep is your depth
> buffer? What are the near / far values when you see a bad image?
>
> Thanks,
>
> Lisa
>
> At 04:02 PM 3/23/2001, Malcolm Drummond wrote:
> >I have also just upgraded from vtk24. Some apparent degradation may be due
> >to a more generous automated camera clipping range in vtk31. On some of my
> >datasets this results in polygon flickering with camera movement (as the
> >depth resolution is not fine enough) and "ragged" intersections. My
> >immediate fix was to introduce near range-clamping methods to the camera, as
> >this affects depth resolution (I didn't want to mess with the renderers
> >ResetCameraClippingRange() - but that might be another route to go). I've
> >attached my files.
> >
> >The methods are ...
> >
> >// Description:
> >   // Set/Get clamping of ClippingRange[0]. Prevents value <
> >ClipRangeNearClampValue.
> >   vtkSetMacro(ClippingRangeNearClamping,int);
> >   vtkGetMacro(ClippingRangeNearClamping,int);
> >   void ClippingRangeNearClampingOn();
> >   void ClippingRangeNearClampingOff();
> >
> >   // Description:
> >   // Set/Get value to clamp ClippingRange[0] by.
> >   vtkSetMacro(ClippingRangeNearClampValue,double);
> >   vtkGetMacro(ClippingRangeNearClampValue,double);
> >
> >You can test if depth resolution is a problem via tcl script, just reset the
> >camera range via the interactive command window and see if there's any
> >remarkable change when you render (but call the render through the command
> >window - using the mouse to force a render could cause the renderer to
> >recompute the bounds and reset the camera to the old range again).
> >
> >I don't know if this is the best solution ... it just worked in a hurry. If
> >the Gurus think it's OK I'll introduce ClippingRangeFarClamping etc.for
> >completeness and submit the code.
> >

I think I have something to contribute here but I'm joining the discussion late.
There is an aritcle called "W Pleasure, W Fun" in the May/June IEEE CG&A
 magazine in which Jim Blinn demonstrates that the location of the near
 clipping plane must be a significant fraction (at least .3) of the far clipping
 plane location for Z buffering to be accurate when PERSPECTIVE projections
 are used.   Interestingly (see Fig 3b) things get even worse when high precision
 floating point is used !  The problem is that the perspective projection causes
  points projected to screen space to be spaced non-linearly relative to the
  points in eye space to which they correspond.

  Dave

 Dave


--
David E Jones
Du Pont Central Research
Experimental Station, Bldg 320
Wilmington, DE 19880-0320


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20010324/6fc98ffe/attachment.htm>