Re: [rp-ml] STL files

From: steve <sjbaker1_at_airmail.net>
Date: Tue Nov 07 2006 - 08:44:08 EET

Delft Spline Systems wrote:
> Hi to all,
>
> As a countermovement to all STL bashing on this list:
> the STL format is the best CAD data exchange format I have
> ever worked with (and I am active in the field for over 20 years).

Weird - I look at how it's put together and specified and conclude
that it's by far the worst 3D format I've ever seen!

> Positive points:
> - all 3D CAD programs can export STL

Yep. That's because it's a de-facto standard - not because the
format has anything particularly special to recommend it.

> - no incompatible variations do exist (I do not use color).
> Compare this to DXF, where the specification is changed with
> every new Autocad release, and to IGES, where every CAD system
> has its own flavour, often incompatible.

...because you don't happen to use colour - if you did then there
are indeed two completely incompatible variations - neither of which
follows the extension guidelines for the original format (in fact,
both completely undermine that ability by stealing the field that
was put there for that reason and misusing it!)

XML-based formats like COLLADA get around many of these versioning
problems quite nicely.

> - there is no choice in entities (like a sphere being described
> OR as a center + radius OR as or NURBS surface OR as polygon data
> OR ...). All geometry is described using the same trangle entity.
> I think this is in fact the best point of STL.

Ditto for PLY.

> - the specification is so very simple that there is not much room
> for error (it is also inefficient, however large files are not a
> large problem).

For PLY, there are free libraries you can use for loading up the files -
and since everyone seems to use them, there is no room for error and
loading them is just a couple of lines of code.

The file size issue may not worry you - but it bothers some people
for some applications and could EASILY have been much, much better.

For COLLADA, that is also true - but you can also load them as XML
files - which requires zero code for JAVA programs and absolutely
could not be simpler.

> - it allways works, at least for me: our STL processing software
> does not care about cracks, gaps or orphan surfaces (www.deskproto.com).
> I would say that refusing to build is a problem of the RP software,
> not of the STL data format.

I agree about that. Dealing with cracks, etc is a matter for the
application - not the file format.

> The only limitation is that STL can be used for downstream processes
> only, like RP and rendering. Modelling polygon data is not a good
> option. Since I am in model building this does not bother me.

That's a pretty serious problem IMHO. The lack of support for polygon
attributes like colour, shininess, texture, etc means it's utterly
useless for 2D rendering and being forced to use a different format
for sending to the RP machine than you use for other purposes is
just asking for problems (unless you run a pretty tight ship
version-control-wise).
Received on Thu Dec 07 07:25:57 2006

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