<!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>Thanks Lisa, I'll back out of my camera
extensions.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Malcolm</FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A href="mailto:lisa.avila@kitware.com" title=lisa.avila@kitware.com>Lisa S.
Avila</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A href="mailto:geov@netactive.co.za"
title=geov@netactive.co.za>Malcolm Drummond</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, April 10, 2001 7:12
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [vtkusers] Re: VTK24 vs.
312, quality and performance</DIV>
<DIV><BR></DIV>Hello Malcolm,<BR><BR>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.<BR><BR>Lisa<BR><BR><BR>At
07:56 AM 3/25/2001, you wrote:<BR>
<BLOCKQUOTE class=cite cite type="cite"><FONT face=arial size=2>Hi
Lisa</FONT><BR> <BR><FONT face=arial size=2>I tried sending this to the
group but the attachments were too large ... </FONT><BR><FONT face=arial
size=2>I'll resend without attachments.</FONT><BR> <BR><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>><BR></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>