[vtkusers] Re: VTK24 vs. 312, quality and performance
Malcolm Drummond
geov at netactive.co.za
Thu Apr 19 12:51:50 EDT 2001
Thanks Lisa, I'll back out of my camera extensions.
Malcolm
----- Original Message -----
From: Lisa S. Avila
To: Malcolm Drummond
Sent: Tuesday, April 10, 2001 7:12 PM
Subject: Re: [vtkusers] Re: VTK24 vs. 312, quality and performance
Hello Malcolm,
I am going to somehow change the automatic near/far calculations to have a few user adjustable parameters. This will probably take a week or two - for now you can simply change the calculation yourself (if you are compiling VTK) in the ResetCameraClippingRange method on the vtkRenderer.
Lisa
At 07:56 AM 3/25/2001, you wrote:
Hi Lisa
I tried sending this to the group but the attachments were too large ...
I'll resend without attachments.
I'd call my conditions highly unreasonable. I'm looking at sedimentary
basins many kilometers in extent but some of my features and glyphs are only
a couple of meters in size. I provide users with the ability to set extents
but often they require regional views. The bad images typically occur on the
polygons where I've wrapped tubes around sections of boreholes (radius
~2.5m, resolution 10) or glyphs (eg. I place cones at the borehole collars -
users can pick these cones to retrieve additional borehole data). I must say
I've never experienced any problems under 2.4 or with any of the vtk
examples I try under 3.1.
The card is nVidia GeForce2 (Creative) which claims a 32 bit z-buffer. With
respect to the images I've sent you, the near/far values when the problem
kicks in are around 0.15 and 1500 respectively - in this case clamping the
near value to 1.0 gives acceptable results.
>> then we probably should tweak ResetCameraClippingRange().
Sure, how about run-time tweaking? If the user could control some
parameter/s within the method (perhaps the hard-wired "breathing space"
parameters for starters) that would make a big difference in cases like
this. I initially liked optional clamping of the near and far range values
as this approach retained the dynamic behaviour when conditions were
favourable.
What do you suggest?
Thanks
Malcolm
----- Original Message -----
From: Lisa Sobierajski Avila <lisa.avila at kitware.com>
To: Malcolm Drummond <geov at netactive.co.za>; vtkusers
<vtkusers at public.kitware.com>
Sent: Saturday, March 24, 2001 11:26 AM
Subject: Re: [vtkusers] Re: VTK24 vs. 312, quality and performance
> 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
> > >
> >
> >
>
>
>
> _______________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20010419/4700edb7/attachment.htm>
More information about the vtkusers
mailing list