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

Sat Mar 24 04:26:30 EST 2001

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.
>
>----- Original Message -----
>From: Tom G. Smith (B75826) <smitty at kcc.com>
>To: <vtkusers at public.kitware.com>
>Sent: Friday, March 23, 2001 3:25 PM
>Subject: [vtkusers] Re: VTK24 vs. 312, quality and performance
>
>
> > Prabhu hit the nail squarely on the head regarding the ImageMagick
> > convert utility not using compression in RH7.  The original ppm files
> > were all 270015 bytes, and the gif files out of the convert utility
> > are all 91492 bytes on the RH7 system, and range from 4178 to 8629
> > bytes on the older SGI system.
> >
> > That explains the gif file size differences, but still doesn't address
> > the performance and rendering quality issues.  My performance test was
> > done with the VTK Interactor, and a GIF file was not involved there,
> > just vtk:  vtk star.tcl -- -c yellow.  Regarding the rendering quality,
> > there are artifacts that shouldn't be there, shadows have sharp edges
> > where they should be blended, and objects are clipped where they shouldn't
> > be.  The best description I can give, it looks like Andy Warhol had an
> > influence in the renderings from VTK 3.1.2 :-)
> >
> > Forwarded message:
> > > From: "Prabhu Ramachandran" <prabhu at aero.iitm.ernet.in>
> > > Date: Fri, 23 Mar 2001 10:15:35 +0530 (IST)
> > > To: "Tom G. Smith (B75826)" <smitty at kcc.com>,
> > >    "VTK users list" <vtkusers at public.kitware.com>
> > > Subject: [vtkusers] VTK24 vs. 312, quality and performance
> > >
> > > hi,
> > >
> > > >>>>> "Tom" == B75826  <smitty at kcc.com> writes:
> > >
> > >     Tom> The first brings up the Interactor, and the second generates
> > >     Tom> an animated gif file, showing the star rotating 360 degrees
> > >     Tom> about its vertical axis.  Here's the sizes of the two gif
> > >     Tom> files, and as you can see, the one from VTK 3.1.2 is over 12
> > >     Tom> times the size of the gif from VTK 2.4:
> > >
> > >     Tom> -rw-r--r-- 1 smitty mst 65589 Mar 22 14:06 star24.gif
> > >     Tom> -rw-r--r-- 1 smitty mst 805580 Mar 22 13:29 star312.gif
> > >
> > >     Tom> To give some measure of the difference in performance, using
> > >     Tom> the Interactor, I left-clicked and dragged from the center to
> > >     Tom> the edge of the rendering window, which of course causes the
> > >     Tom> image to rotate.  Then I timed the rotation through 360
> > >     Tom> degrees.  The rendering from VTK 2.4 takes 16 seconds, and
> > >     Tom> that from vtk312 72 seconds, 4.5 times longer.
> > >
> > > I havent looked at your code, but I read in the comments that you use
> > > ImageMagick to convert ppm's to gif.  I think this is the source of
> > > the problem.  Since Unisys patented the compression with gifs and
> > > started enforcing the patent, most sensible Linux distributions avoid
> > > shipping with libraries that use the compression.  The new
> > > uncompressed gif library is usually called 'libungif'.  I think that
> > > the basic problem is there.  This is the reason why you see a file
> > > that is 12 times larger: No compression.  I believe that your SGI has
> > > a libgif that does compression and ImageMagick on the SGI uses it.
> > > Older linux distro's also shipped with these kind of libraries.  The
> > > rendering time may be slower simply because the gif files are so large
> > > and processing them will take longer.  I cannot explain the poor
> > > quality of the rendering.
> > >
> > > Hope this helps,
> > >
> > > prabhu
> > >
> >
> >
> > --
> >
> > --------------------------------------------------------------------------
>----
> > This e-mail is intended for the use of the addressee(s) only and may
>contain privileged, confidential, or proprietary information that is exempt
>from disclosure under law.  If you have received this message in error,
>please inform us promptly by reply e-mail, then delete the e-mail and
>destroy any printed copy.   Thank you.
> >
> >
>============================================================================
>==
> >
> > _______________________________________________
> > This is the private VTK discussion list.
> > Please keep messages on-topic. Check the FAQ at:
><http://public.kitware.com/cgi-bin/vtkfaq>
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/vtkusers
> >
>
>