Stephen J Rock wrote:
>
> Justin,
>
> You write:
> > ... for *medical* applications, I understand that contour-based is
> > better than STL...
>
> I'd say you'd have to define "better".
>
> Both representation approaches have both positive and negative aspects.
> "Better" may depend on things like:
> 1. are you storage limited (not much disk space for your data)?
> 2. are you compute power limited (don't want to slice a 3D model --
> especially if it's v. large)?
> 3. what error can you tollerate on the final part? is this error introduced
> by the process or by approximation of the data? if it's caused by
> data approximation, can you improve the tessellation of the original
> solid model to reduce error? if you do this, are the resulting files
> unwieldy (either to store or process)?
>
> I've published a few papers on STL model processing which may be of
> interest to you. You can find them at http://cat.rpi.edu/~rocks
>
Actually, the "better" part was not my invention, it is just what I read. I
was wondering why this might be, or why not. Perhaps medical data, which
is always(as far as I know) in the form of a multicurved surface, is easier
to convert to contour than STL? Or maybe since it is sliced already, less
work is needed to get it into CLI than STL? These are things I am really not
sure about, but I would like to find out. Thanks...
Justin
-- jkidder@spock.ecs.umass.edu Automation and Robotics Laboratory University of Massachusetts, Amherst http://www.ecs.umass.edu/mie/labs/arl/people/jkidder/jkidder.html -----------------------------------------------------------------------
This archive was generated by hypermail 2.1.2 : Tue Jun 05 2001 - 22:37:13 EEST