Dear Dr. Anshuman Razdan and rp-ml,
The direct slicing and slices are not intended to replace the
stl as a data transfer format. I was addressing the part
accuracy problem rather than the data size problem.
To utilize the direct slicing fully we should use IGES/STEP etc.
to transfer the data to the RP machine site and slice the
surface model locally, according to the different needs of
different RP machines. I believe this will be available in a
couple of years.
Best regards,
Ismo Mäkelä,
DeskArtes Oy
Dr Anshuman Razdan wrote:
>
> 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/
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