RE: [rp-ml] STL files

 Great topic, Anyone interested in presenting on this at our 2007 3DSUG
conference in March? This topic would work great before or after a
Materialize Magics stl fixer presentation.

Regards,
Bob Z.
3DSUG Chairperson

-----Original Message-----
From: owner-rp-ml@rapid.lpt.fi [mailto:owner-rp-ml@rapid.lpt.fi] On
Behalf Of Wesley Brooks
Sent: Friday, December 08, 2006 4:20 AM
To: rp-ml@rapid.lpt.fi
Subject: Re: [rp-ml] STL files

Cheers for starting this thread of, it's help me refine a few of my
arguments around STL files Thanks also for confirming that the binary
and ASCII files are essentially no different, just one is optimised to
be read by a computer in the shortest possible time and one is written
so we can read it and understand how the file is structured.

So in essence if your software wrote an STL like format file and
verified it against the rules you would end up with a surface CAD model
that isn't guaranteed to be a definite volume, rather than infinite, may
not protect against flipped triangles (unless I missed an a-b b-a rule
somewhere above, beg your pardon if I have!), doesn't protect against
intersecting intersecting triangles which are either in the same plane
or not, and finally forces your RM/RP operating software into a load
more leg work loading it into a reasonable data structure and
subsequently checking for co-incident points.

If you try and resolve the situation by using an alternative format you
hit problems if you assume you have a solid surface, these formats not
setting rules that the surface have to be complete. Having said this it
would be foolish to run with RP/RM operating software that assumed
supplied STL files where closed, and didn't take appropriate action when
an open contour was detected on a slice!

I can see situations where using open surface files could be useful,
such as a support generator. For example in the laser processing systems
you may only want to trace the support structures once, and follow
certain lines - not loops. If this open surface file type was loaded,
the system would know to treat it as a support. As I said earlier this
could be included in the header, simply 'closed', or 'open'.

If some one gives me a link to a good description of a common
slice/contour format (ASCII at first!) which machines will read in I'll
write a slicer which will read in a surface file which we define here
(again ASCII at first), and slice it (exactly!). It's then up to you
guys to hatch it using a suitable system within your RP/RM software.
I'll write this in Python using other Open Source libraries and it will
run from the command line with no interface. The choice of these
languages will mean the code is portable between different OS (eg
Linux/Windows). I won't include a validation tool for the time being as
this will take a while to write (with all the new rules) and I'm busy!

If we get this working here then the manufacturers will have less of an
argument against taking it up. Once the basics are working we can
discuss the best way of including colour, and the best validation method
to use.

Any one game?

Wesley Brooks
Received on Fri Dec 08 12:41:32 2006