Re: [rp-ml] STL files

From: Wesley Brooks <>
Date: Fri Dec 08 2006 - 11:19:30 EET

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

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 10:16:19 2006

This archive was generated by hypermail 2.1.8 : Tue Jul 21 2009 - 10:27:52 EEST