<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.2614.3500" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>
<DIV><FONT face=Arial size=2>Hi Lisa</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I'd call my conditions highly unreasonable. I'm
looking at sedimentary<BR>basins many kilometers in extent but some of my
features and glyphs are only<BR>a couple of meters in size. I provide users with
the ability to set extents<BR>but often they require regional views. The bad
images typically occur on the<BR>polygons where I've wrapped tubes around
sections of boreholes (radius<BR>~2.5m, resolution 10) or glyphs (eg. I place
cones at the borehole collars -<BR>users can pick these cones to retrieve
additional borehole data). I must say<BR>I've never experienced any problems
under 2.4 or with any of the vtk<BR>examples I try under 3.1.<BR><BR>The card is
nVidia GeForce2 (Creative) which claims a 32 bit z-buffer. With<BR>respect to
the images I've sent you, the near/far values when the problem<BR>kicks in are
around 0.15 and 1500 respectively - in this case clamping the<BR>near value to
1.0 gives acceptable results.<BR><BR>>> then we probably should tweak
ResetCameraClippingRange().<BR>Sure, how about run-time tweaking? If the user
could control some<BR>parameter/s within the method (perhaps the hard-wired
"breathing space"<BR>parameters for starters) that would make a big difference
in cases like<BR>this. I initially liked optional clamping of the near and far
range values<BR>as this approach retained the dynamic behaviour when conditions
were<BR>favourable.<BR><BR>What do you
suggest?<BR><BR>Thanks<BR>Malcolm<BR><BR>----- Original Message -----<BR>From:
Lisa Sobierajski Avila <<A
href="mailto:lisa.avila@kitware.com">lisa.avila@kitware.com</A>><BR>To:
Malcolm Drummond <<A
href="mailto:geov@netactive.co.za">geov@netactive.co.za</A>>;
vtkusers<BR><<A
href="mailto:vtkusers@public.kitware.com">vtkusers@public.kitware.com</A>><BR>Sent:
Saturday, March 24, 2001 11:26 AM<BR>Subject: Re: [vtkusers] Re: VTK24 vs. 312,
quality and performance<BR><BR><BR>> Hello Malcolm,<BR>><BR>> 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?<BR>><BR>> Thanks,<BR>><BR>> Lisa<BR>><BR>><BR>> At
04:02 PM 3/23/2001, Malcolm Drummond wrote:<BR>> >I have also just
upgraded from vtk24. Some apparent degradation may be<BR>due<BR>> >to a
more generous automated camera clipping range in vtk31. On some of<BR>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,<BR>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<BR>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<BR>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.<BR>If<BR>> >the
Gurus think it's OK I'll introduce ClippingRangeFarClamping etc.for<BR>>
>completeness and submit the code.<BR>> ><BR>> >----- Original
Message -----<BR>> >From: Tom G. Smith (B75826) <<A
href="mailto:smitty@kcc.com">smitty@kcc.com</A>><BR>> >To: <<A
href="mailto:vtkusers@public.kitware.com">vtkusers@public.kitware.com</A>><BR>>
>Sent: Friday, March 23, 2001 3:25 PM<BR>> >Subject: [vtkusers] Re:
VTK24 vs. 312, quality and performance<BR>> ><BR>> ><BR>> >
> Prabhu hit the nail squarely on the head regarding the ImageMagick<BR>>
> > convert utility not using compression in RH7. The original ppm
files<BR>> > > were all 270015 bytes, and the gif files out of the
convert utility<BR>> > > are all 91492 bytes on the RH7 system, and
range from 4178 to 8629<BR>> > > bytes on the older SGI system.<BR>>
> ><BR>> > > That explains the gif file size differences, but
still doesn't address<BR>> > > the performance and rendering quality
issues. My performance test was<BR>> > > done with the VTK
Interactor, and a GIF file was not involved there,<BR>> > > just
vtk: vtk star.tcl -- -c yellow. Regarding the
rendering<BR>quality,<BR>> > > there are artifacts that shouldn't be
there, shadows have sharp edges<BR>> > > where they should be blended,
and objects are clipped where they<BR>shouldn't<BR>> > > be. The
best description I can give, it looks like Andy Warhol had an<BR>> > >
influence in the renderings from VTK 3.1.2 :-)<BR>> > ><BR>> >
> Forwarded message:<BR>> > > > From: "Prabhu Ramachandran"
<<A
href="mailto:prabhu@aero.iitm.ernet.in">prabhu@aero.iitm.ernet.in</A>><BR>>
> > > Date: Fri, 23 Mar 2001 10:15:35 +0530 (IST)<BR>> > >
> To: "Tom G. Smith (B75826)" <<A
href="mailto:smitty@kcc.com">smitty@kcc.com</A>>,<BR>> > >
> "VTK users list" <<A
href="mailto:vtkusers@public.kitware.com">vtkusers@public.kitware.com</A>><BR>>
> > > Subject: [vtkusers] VTK24 vs. 312, quality and
performance<BR>> > > ><BR>> > > > hi,<BR>> > >
><BR>> > > > >>>>> "Tom" == B75826 <<A
href="mailto:smitty@kcc.com">smitty@kcc.com</A>> writes:<BR>> > >
><BR>> > > > Tom> The first brings up
the Interactor, and the second<BR>generates<BR>> > >
> Tom> an animated gif file, showing the star
rotating 360 degrees<BR>> > > > Tom>
about its vertical axis. Here's the sizes of the two gif<BR>> > >
> Tom> files, and as you can see, the one from VTK
3.1.2 is over<BR>12<BR>> > > > Tom> times
the size of the gif from VTK 2.4:<BR>> > > ><BR>> > >
> Tom> -rw-r--r-- 1 smitty mst 65589 Mar 22 14:06
star24.gif<BR>> > > > Tom> -rw-r--r-- 1
smitty mst 805580 Mar 22 13:29 star312.gif<BR>> > > ><BR>> >
> > Tom> To give some measure of the difference
in performance,<BR>using<BR>> > > > Tom>
the Interactor, I left-clicked and dragged from the center<BR>to<BR>> >
> > Tom> the edge of the rendering window,
which of course causes<BR>the<BR>> > > >
Tom> image to rotate. Then I timed the rotation through 360<BR>>
> > > Tom> degrees. The rendering from
VTK 2.4 takes 16 seconds, and<BR>> > > >
Tom> that from vtk312 72 seconds, 4.5 times longer.<BR>> > >
><BR>> > > > I havent looked at your code, but I read in the
comments that you<BR>use<BR>> > > > ImageMagick to convert ppm's to
gif. I think this is the source of<BR>> > > > the
problem. Since Unisys patented the compression with gifs and<BR>> >
> > started enforcing the patent, most sensible Linux
distributions<BR>avoid<BR>> > > > shipping with libraries that use
the compression. The new<BR>> > > > uncompressed gif library
is usually called 'libungif'. I think that<BR>> > > > the
basic problem is there. This is the reason why you see a file<BR>> >
> > that is 12 times larger: No compression. I believe that your
SGI<BR>has<BR>> > > > a libgif that does compression and ImageMagick
on the SGI uses it.<BR>> > > > Older linux distro's also shipped
with these kind of libraries. The<BR>> > > > rendering time
may be slower simply because the gif files are so<BR>large<BR>> > >
> and processing them will take longer. I cannot explain the
poor<BR>> > > > quality of the rendering.<BR>> > >
><BR>> > > > Hope this helps,<BR>> > > ><BR>> >
> > prabhu<BR>> > > ><BR>> > ><BR>> >
><BR>> > > --<BR>> > ><BR>> ><BR>>
--------------------------------------------------------------------------<BR>>
>----<BR>> > > This e-mail is intended for the use of the
addressee(s) only and may<BR>> >contain privileged, confidential, or
proprietary information that is<BR>exempt<BR>> >from disclosure under
law. If you have received this message in error,<BR>> >please inform
us promptly by reply e-mail, then delete the e-mail and<BR>> >destroy any
printed copy. Thank you.<BR>> > ><BR>> >
><BR>><BR>>===========================================================================<BR>=<BR>>
>==<BR>> > ><BR>> > >
_______________________________________________<BR>> > > This is the
private VTK discussion list.<BR>> > > Please keep messages on-topic.
Check the FAQ at:<BR>> ><<A
href="http://public.kitware.com/cgi-bin/vtkfaq">http://public.kitware.com/cgi-bin/vtkfaq</A>><BR>>
> > Follow this link to subscribe/unsubscribe:<BR>> > > <A
href="http://public.kitware.com/mailman/listinfo/vtkusers">http://public.kitware.com/mailman/listinfo/vtkusers</A><BR>>
> ><BR>> ><BR>> ><BR>><BR>><BR>><BR>>
_______________________________________________<BR>> This is the private VTK
discussion list.<BR>> Please keep messages on-topic. Check the FAQ
at:<BR><<A
href="http://public.kitware.com/cgi-bin/vtkfaq">http://public.kitware.com/cgi-bin/vtkfaq</A>><BR>>
Follow this link to subscribe/unsubscribe:<BR>> <A
href="http://public.kitware.com/mailman/listinfo/vtkusers">http://public.kitware.com/mailman/listinfo/vtkusers</A><BR>></DIV></FONT></FONT></DIV></BODY></HTML>