Re: [rp-ml] STL files

From: Adrian Bowyer <A.Bowyer_at_bath.ac.uk>
Date: Wed Dec 06 2006 - 21:39:08 EET

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.

Quoting Delft Spline Systems <info@spline.nl>:

> Thanks for the comment, and of course you are absolutely right that
> the Euler formula was long known, and could have been somehow 'built
> in' the STL file definition. And then the STL file would cause less
> problems for all slicing algorithms that aren't sufficiently robust
> to handle gaps.
>
> However: this would not have solved the problem but only have shifted
> it: in that case surface modellers like Alias and Rhino would not
> have been able to export STL files easily.

Yes - because they can't force the modelling of real solids! That is,
they are not true solid modellers. So it's not surprising that they
can't create a solid (except by luck) if they don't know what one is...

> From my point of view the current STL file is ideal as any 3D CAD
> program can easily write one, and as incompatibility problems do not
> exist because of its simplicity. I can understand though that from a
> different point of view STL is not so ideal.

This whole debate was being had 30 years ago in the CAD world when one
group wanted to stick with wire-frame and face representations
(essentially STL), and the others (people like Ari Requicha and Ian
Braid) pointing out that software based on that would always have bugs
because decisions were being made deliberately and permanently to build
the bugs in. Requicha and Braid were right, the others were wrong, and
every self-respecting CAD system these days uses the schemes invented
by one or the other of them (or a hybrid). And all that was resolved
in their favour before STL was defined.

If people are going to re-invent the wheel, they should at least try
not to make it square...

> I just wanted to also illuminate the positive side of STL, as that
> absolutely is present too.

That's a completely fair point.

An anecdote:

A few years ago at a meeting of the UK's Geometric Modelling Society a
friend of mine was describing a meeting between his (very
distinguished) software company and some of their customers.

The customers said, "What we need is a function that gives us the
middle lines and surfaces of an object."

"Ah," said my friend, "I'm not quite sure I understand what you mean.
For example, what about this shape?" And he drew a T on the flipchart:

   --------------------------
   | |
   | |
   ----------- ----------
              | |
              | |
              | |
              | |
              -------

"That's easy," said the customers. And one of their number even bolder
then the rest stood, took the felt pen, and drew:

   --------------------------
   |_________________________|
   | | |
   ----------- | ----------
              | | |
              | | |
              | | |
              | | |
              -------

When my friend drew that* the entire Geometric Modelling Society
meeting fell into hysterics. When we had recovered we decided that
that story couldn't be capped so we'd to go to lunch (a decision that
may have also been prompted by the fact that we were at an Oxford
college who keep a particularly fine cellar).

The morals of this story are:

   1. The customer is always wrong,
   2. The customer doesn't even know that he's wrong,
   3. The customer doesn't understand his problem,
   4. Even if he did, he'd still be wrong, and
   5. Geometry is more subtle than one at first imagines.

STL seems simple. But really it's just wrong.

[*The thing that the customers might reasonably have got was the medial
axis transform, but - when asked - they didn't want that either...]

Yours

Adrian

http://staff.bath.ac.uk/ensab
http://reprap.org
Received on Wed Dec 06 20:21:58 2006

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