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

[Malcolm Drummond]

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
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtkCamera.h
Type: application/octet-stream
Size: 14688 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20010323/cb4bde2b/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtkCamera.cxx
Type: application/octet-stream
Size: 34628 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20010323/cb4bde2b/attachment-0001.obj>