Re: Data exchange formats (longish)

From: Michael Brindley
Date: Thursday, September 29, 1994

From: Michael Brindley
To: André Dolenc (Helsinki University of Technology)
Cc: RP-ML
Date: Thursday, September 29, 1994
Subject: Re: Data exchange formats (longish) 
> Although the STL file format has its drawbacks, many of the problems experienced
> by users are related to poorly designed and implemented software tools.
> Even a good data exchange format such as CFL would not eliminate these problems.

I don't suppose you'd care to elaborate on these software problems.  
Besides the occasional CAD package which has a great deal of trouble
creating valid STL files (I won't mention any names here), I haven't
seen any problems with STL files which were not directly related to
to it being an STL file.  A good file format would solve those problems.
Note: the above is contingent on limiting the discussion to polygonal
planar faceted models.  Using more complicated geometric models is
another issue.
 
> Nowadays, all efforts in the direction of finding a substitute for the
> representation of facetted models should be done within STEP. There are two

Is STEP officially released?  Last I heard it was still 'the coming thing'.
It's been that way for a while now.

> 
> This forum could, instead, collect the REQUIREMENTS for a new format, instead
> attempting to define one. This alone is one of the most important STEPs in
> defining a neutral data exchange format. And, believe me, it is not easy.

Good suggestion.  Anyone care to bite?

> For instance, most of the discussions assume that the data exchange flows in
> one direction, from the sender to the receiver. What if the receiver would
> like to tell the sender the problems identified in the model, and how they were
> corrected, *if* they were corrected. We fall in the silly situation of using
> the good old IGES/VDAFS/SET standards that have been around for years, and
> which everyone is trying to get rid of.

Interesting suggestion.  Any attempt to define a new format should have
the purpose (objectives) clearly stated.  If the major objective is to
transfer the geometry is a reasonable way to the RP machine, then the
above ECO type feedback falls outside the scope of the format.  But
including such feedback may be worth while.

> 
> Concerning data exchange formats, the MAJOR BOTTLENECK is the absence of
> an OPEN FORMAT for sliced models. As far as I know, the only serious effort

Would you also care to explain why this is a MAJOR BOTTLENECK?   Pre-sliced
representations lose a lot of information.  To change the slicing,
you need to go back to the original geometry.  Also, who says that future
RP machines will build things in horizontal slices at an even spacing?

  --> Mike Brindley


Previous message | Next message
Back to 1994 index