Direct slicing is good - the only problem is that sliced model itself
is not good for shipping between people - vendors, serv bureau etc. Since
the slicing is dependent on orientation of the build. You can not in general
reconstruct the 3D model from sliced data. So yes - ofcourse Slice data is
useful - afterall STL files do get sliced as part of the build process.
SLicing is also (in most cases) machine dependent i.e. if a model is to be
built on SLA 250 vs 5000 vs DTM - slicing would be done differently taking
advantage of the characteritics of each process/machine etc.
So while the idea is good (and nothing new) I am not sure it addresses the problem.
Unless we agree that STL or SLC is not a format for moving models around rather
IGES, STEP etc are the data file formats.
Also - how do u fix some body's bad slices - I know in FDM software its painful
you have to fix it layer by layer.
AR
Anshuman Razdan
> From owner-rp-ml@ltk.hut.fi Tue Dec 21 02:08:07 1999
> Received: from post2.inre.asu.edu (post2.inre.asu.edu [129.219.13.72]) by taurus.eas.asu.edu (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id CAA26277 for <razdan@taurus.eas.asu.edu>; Tue, 21 Dec 1999 02:07:56 -0800 (MST)
> Received: from bart.lpt.fi (bart.lpt.fi [193.166.66.1])
> by asu.edu (PMDF V5.2-31 #33824) with ESMTP id <0FN300I5O2FB33@asu.edu> for
> razdan@taurus.eas.asu.edu (ORCPT rfc822;razdan@asu.edu); Tue,
> 21 Dec 1999 02:02:02 -0700 (MST)
> Received: from major by bart.lpt.fi with local (Exim 1.90 #2)
> for rp-ml-outgoing@bart.lpt.fi id 120KQV-0005lU-00; Tue,
> 21 Dec 1999 08:13:47 +0000
> Received: from ds9.sci.fi ([195.74.0.54]) by bart.lpt.fi with esmtp
> (Exim 1.90 #2) for rp-ml@bart.lpt.fi id 120KQT-0004zK-00; Tue,
> 21 Dec 1999 10:13:46 +0200
> Received: from apollo.deskartes.fi
> (MMCMXXI.hdyn.saunalahti.fi [195.197.45.221]) by ds9.sci.fi (8.9.1/8.9.1)
> with SMTP id KAA16870; Tue, 21 Dec 1999 10:13:42 +0200 (EET)
> Received: from roba by apollo.deskartes.fi (AIX 4.1/UCB 5.64/4.03)
> id AA73754; Tue, 21 Dec 1999 10:13:00 +0200
> Date: Tue, 21 Dec 1999 10:13:37 +0200
> From: Ismo =?UNKNOWN?Q?M=E4kel=E4?= <Makela@deskartes.fi>
> Subject: Die STL.die
> Sender: owner-rp-ml@ltk.hut.fi
> To: ATiburon@AOL.COM
> Cc: rp-ml@bart.lpt.fi
> Message-id: <385F36B1.F3894885@deskartes.fi>
> Organization: DeskArtes Oy
> MIME-version: 1.0
> X-MIME-Autoconverted: from 8bit to quoted-printable by ds9.sci.fi id KAA16870
> X-Mailer: Mozilla 4.04 [en] (WinNT; I)
> Content-type: text/plain; charset=iso-8859-1
> Content-transfer-encoding: quoted-printable
> Precedence: bulk
> References: <0.b784fede.258afaa3@aol.com>
>
> Dear Mr. Scott and rp-ml,
>
> The discussion about the usefulness of the stl-format=20
> has been a very interesting one. Here at DeskArtes
> we have taken another way to avoid the problems=20
> caused by the usage of triangles.
>
> The accuracy of the result decreases when a faceting step
> is needed between the surface model and the slices. This can
> be minimized by doing the slicing directly on the surface
> model. The user supplies the slice thickness and the maximum=20
> deviation of the slice segments from the original surface.
> The result is a smooth looking set of curves following=20
> nicely the original surface. Also, you do not see the typical
> triangle pattern on your slice data.
>
> This is a new product. The direct slicing functionality is=20
> available in the latest version 4.2 of DeskArtes Rapid Tools sw.=20
> It runs on Unix and Windows NT. Rapid Tools can=20
> input IGES or VDA surface data and output slices in=20
> IGES, VDA, CLI, SLI, SSL and SLC formats.
>
> We would be very happy to co-operate if somebody is interested
> to do some tests with the direct slicing.
>
> Best regards,
>
> Ismo M=E4kel=E4,
> DeskArtes Oy
>
> P.S. Please have a look at our web pages at=20
> http://www.deskartes.com
>
>
> ATiburon@aol.com wrote:
> >=20
> > In a message dated 99-12-16 14:11:02 EST, gfadel@ces.clemson.edu writes=
> :
> >=20
> > << One advantage I saw mentioned by Stephen Rock in the exchanges is
> > that slicing would be much faster - say 2 to 3 times faster on the ave=
> rage.
> > Would that be good enough a reason to migrate? >>
> > The major drawback to STL is the FACET. The STL is great for describing
> > boxes. But really sucks for curved surfaces, small radii, internal
> > passageways etc. It's ludicrous in the extreme for RP manufacterers to =
> be
> > claiming .001 in plane accuracies when the file format won't come that =
> close.
> > Not with a zillion triangles! There have been formats already that did
> > perform better when used on curved models, things like Cars, Airplanes,
> > barbie dolls, etc. One is CATSLICE, available for Catia only I believe,=
> I
> > don't know if it is still supported. The other was the approach as by =
> Fockle
> > and Schwatrz, and perhaps a few others to use HPGL slices, supported by
> > Magics etc. The STL is the major impediment for RP's progression/evolve=
> ment
> > into RM (rapid manufacturing). Accuracy, surface finish and utlity all =
> suffer
> > because STL will never be more than just an approximation. That is OK p=
> erhaps
> > for many models, but totally inadiquate for tooling or production.
> > Andy Scott
> > Lockheed Martin Aero Sys
> >=20
> > For more information about the rp-ml, see http://ltk.hut.fi/rp-ml/
>
> For more information about the rp-ml, see http://ltk.hut.fi/rp-ml/
>
Dr. Anshuman Razdan
Technical Director PRISM
***************************************************************
* Ph: (602) 965 5368 FAX: (602) 965 2910
* Office: GWC 574 Email: razdan@asu.edu
* Snail Mail: PRISM, MCode 5106 Az St. Univ, Tempe AZ 852815106
* http://surdas.eas.asu.edu/~razdan
***************************************************************
For more information about the rp-ml, see http://ltk.hut.fi/rp-ml/
This archive was generated by hypermail 2.1.2 : Tue Jun 05 2001 - 22:53:50 EEST