Re: [rp-ml] STL files

The STL specification requires that the model be topologically correct.
That is, it is the job of the creating software to output correct data that
conforms to the specification.
A solid modeler should certainly be aware of its own topology, and is thus
is the best place to do this.
Other triangle formats do not require closed volumes, and thus can not be
expected to drive this application.

This industrial application requires a topologically correct model to
produce robust sections and hatches capable of reliably building a part.
The topology itself is not needed to slice or hatch, so there is no need to
include it in the file. Even intersecting volumes can usually be handled
in a reasonable way with a little work.

It is not that difficult to verify that the topology of an STL file is
correct, certainly NOT megabytes of code. (Fixing a bad one is another
story.) This however is part of the work of Creating a valid STL file.
Sticking .stl on the end of a file of triangles does not an STL file make.

At 07:39 PM 12/6/06 +0000, Adrian Bowyer wrote
>Quoting Todd Pederzani <tpederzani@protocam.com>:
>
>> Are you sure that the problem with STL aren't due to incomplete
>> specifications? The 3D Lightyear help file (interestingly enough
>> labeled 1.2.1 even in the 1.5.1 release) has a section in "STL Format"
>> with the following rules:
>>
>> 1. All triangles much conform to the right hand rule
>> 2. All exterior surfaces must be devoid of gaps
>> 3. Each triangle must share two of its vertices with each adjacent triangle
>
>Yes, but that's just saying: "An STL file must be of a real solid,"
>which is a bit like saying, "Then all we need to do to fix the STL
>format is to go back in a time machine."
>
>The point is that the format _could_ have made it trivial to _check_
>any object against the Euler-Poincaré formula for solidity using
>_only_logical_operations_ (no floating point involved), but it didn't.
>Even then, there would be no guarantee against, for example,
>self-intersection (or worse, very near self-intersection within
>rounding error). But it would have made an awful lot of things
>megabytes of code easier. That is, it would have saved human time, let
>alone machine time.
>
C. Brock Rooney (President) Brock Rooney & Associates Inc.
915 Westwood, Birmingham, MI 48009 USA
(248) 645-0236 Fax (248) 645-9020 Email: brock@mich.com
Received on Thu Dec 07 20:03:07 2006