RE: [rp-ml] STL Round off errors

This thread begs the question of why we, as users and vendors, tolerate STL
at all.
A vertex list with separate vertex traversal order is far more efficient,
flexible and robust. And dare we even want for a part structure that
maintains shells and meta data that passes such inconsequential information
as UNITS.

We seem to be able to debate nomenclature at great length but the far more
fundamental issues facing industry growth is a defacto acceptance of, as
Steve points out, (>dealing with this since the 1970's.), obsolete file
formats.

We also seem to be able to innovate in wonderful and exciting ways but again
base this innovation on decrepit triangle transfer to the AF machines.

A great presentation at Terry Wholers Euromold plenary conference last year
hinted at one of the real weaknesses of STL beyond geometry transfer. I
believe it was BMW who was exploring the potential for Rapid Manufacturing,
but found that it was difficult to qualify parts because they could be built
so differently even with the same machine. For instance, as the Z axis very
often has different physical characteristics than the x or y, rotation in
the build envelope changed the way the part performed. As STL does not even
specify units, it is light-years away from containing the kind of meta data
that would allow a part to be remotely 3d printed in a reproducible manner.

RISE UP ADDITIVE FABRICATORS OF THE WORLD and throw off the chains of
STL....
Ask your vendors (both CAD and AF) to support anything and everything
besides STL..
OFF< PLY< ZPR< FBX <OBJ < X3D

Or even, a backward compatible, XMSTL? oh yea, we cant even agree on a
name. Monday morning, back to threeding some more parts..

Best

Charles

 Charles Overy : Director of Engineering
 lgm :: architectural visualization
  http://www.lgmmodel.com
  cwho@lgmmodel.com <mailto:cwho@lgmmodel.com>
 970.827.5274
 800 448 8808

> -----Original Message-----
> From: owner-rp-ml@rapid.lpt.fi [mailto:owner-rp-ml@rapid.lpt.fi]On
> Behalf Of steve
> Sent: Monday, June 12, 2006 6:12 AM
> To: Liam MacGinley
> Cc: rp-ml@rapid.lpt.fi
> Subject: Re: [rp-ml] STL Round off errors
>
>
> Liam MacGinley wrote:
> > Hi there
> > I have an STL question thats related to round off errors that
> occur in
> > typical STL files.
> >
> > I have come across a number of papers which state that if two or more
> > vertices are within some tolerance error value of each other then they
> > can be grouped together effectively removing the round off error.
>
> If roundoff error is causing two polygons which should join together
> to somehow pull apart and not make up a continuous surface anymore
> thereby causing 'leaks' that the surface skin to volumetric conversion
> stage can't plug - then you need to zip them back together again.
>
> However, this can be done selectively. Only when a polygon has
> one or more edges that are not shared with another polygon do you
> need to look for another one that's nearby to zip together with.
>
> Other than that, roundoff error should be utterly negligable for
> and RP machine. A single precision floating point number should
> remain accurate to at least one part in a million - it's inherently
> accurate to one part in four million - so it would take a lot of
> consecutive math operations to introduce enough roundoffs (and all
> in the same direction) to make the surface be wrong by more than
> one part per million.
>
> I very much doubt that any RP machine out there is accurate to
> one part per million. So aside from 'plugging leaks' - there
> should never be any need to attempt to fix roundoff problems.
>
> One common design error that causes gaps (which can't always
> be plugged by snapping things together) is when you model a
> 'T-edge' like this:
>
> /\
> / \
> / \
> / \
> / A \
> /__________\
> \ /\ /
> \ / \ /
> \/____\/
> \ /
> \ /
> \/
>
> The vertex at 'A' is shared by the three triangles below it but
> not by the top one. So the edge that's shared between bottom
> and top triangles can come apart and form a teeny-tiny crack
> if 'A' moves by even an infinitely small amount. Since this
> kind of roundoff problem is both inevitable - and utterly
> impossible to fix - the rule is quite simply "Don't Do That".
>
> MOREOVER: If two vertices started off at the exact same
> position then well-designed software should perform precisely the
> same math on both of them - so the roundoff error will be the
> same for both copies and there is no way for them to come
> apart. So you have to ask yourself where this problem you're
> having is coming from in the first place.
>
> > My question is how do they come up with a value for this tolerance
> > error?
>
> Well, there shouldn't have to BE an error tolerance in the first
> place. If you have thin gaps and cracks in the skin of the model
> that cause it to fail to convert into a volumetric object then
> you either designed it poorly - or you have some REALLY poor
> software somewhere in your tool chain. Either way, the thing
> that zips up those rogue edges should be doing it selectively.
> Rather than snapping together any vertices that are within some
> arbitary tolerance, it should be detecting those small gaps and
> only snapping together vertices that are along the edges of those
> gaps.
>
> Since gaps shouldn't happen in the first place, the tolerance you
> set should only be to determine whether the software silently
> snaps vertices together to fill gaps - or whether it reports that
> the gap is so big that there is a design error or something.
>
> This is not a new problem - computer graphics people (like me!)
> have been thinking about and dealing with this since the 1970's.
Received on Mon Jun 12 17:47:58 2006