This list has seen many messages recently regarding the VRML
format, STL etc. I would like to share some observations of my own.
I will start by a brief evaluation of the STL format both the
strengths and the weaknesses of it:
STL STRENGTHS
It is not surprising that the STL format gained so much popularity,
and the reason is the simplicity of the format (syntax). The format
is simple, it represents only triangular polygons, and on top of it it
is unambiguous (there is no room for different interpretations).
People who dismiss simplicity of a format as a key component to
its success miss the point.
Earlier, a message from Mr. Rooney mentioned "legal STL files".
I would like to comment on that statement. One has to distinguish
between syntactical correctness, and topologycal correctness. It is
true that the STL format definition requires that the object be a
manifold object through numerous topological constraints, however,
the file syntax cannot enforce those requirements and in
reality (and we live in reality) most of the STL files generated
are not topologically correct. Moreover, the RP machines are willing
to tolerate a certain level of topological improperties.
Unfortunately it is hard to quantify the level of topological
tolerance allowed by each of the machines.
So yes, it is always better to have a topologically correct STL file if
you can, but to be realistic, one cannot throw all topologicalloy
incorrect files, because we will be left with very few.
To identify topological problems and to correct them, you can use
dedicated software tools such as Imageware's RPM tool.
STL WEAKNESSES
The first weakness of the STL format (both ASCII and binary) is the
representation of every vertex coordinates per facet. This is in
contrast to an indexing scheme whereby all the vertices are defined
first, and the facets point to the vertices by index. Such an indexed
representation can be found in the Cubital CFL format, in Wavefornt's
OBJ format, in the NASTRAN format, in the AutoForm format, in the VRML
format or in Imageware's IMW format (just to name a few).
The use of an indexed format has three advantages:
1. Space efficiency, since most vertices are expected to be shared
across numerous facets, it is more efficient to define the coordinates
once and use a pointing scheme. (It is no magic that the VRML
representation is more compact).
2. For different topological operations, it is necessary to maintain
the topological relations between vertices edges and facets. Thus, a
representation that provides the relationship explicitly svaes some
effort.
3. In addition to saving this minimal effort (2), maintaining an
explicit relationship (vertex shared across specified facets) avoids
tolerance ambiguities: namely, how close should two coordinates be, to
be considered the same?
A second weakness is the fact that only the coordinate location
information of the facets is representable (no other properties).
If I had my choice I would add the two following elements to the
representation:
Normal information (normal information per vertex
was originally available if cominf from a
CAD surface representation).
Color Information. (3D fax machines, etc..)
VRML
I started examining the VRML format and implemented a reader and
writer for it after the discussions on the list.
The advantages of the VRML format are that it is an indexed format,
and that it can represent normals and colors.
HOWEVER, the VRML format was designed for visualization om the net
and not for geometry creation/maintenance/transfer and that is evident.
1. It has many more options which will force any reader to decide
which parts of the vocabulary will be supported, and which will
not. For example, you can represent cylinders, spheres, and cones:
should those be supported for an RP application?, or it supports
extensions (IsA, DEF, USE), should/will these be supported by
an RP application?
What if different vendors decide to support different options
(which will happen)?
2. It also has ambiguous options particularly with respect to
transformations, and color definitions. In the term ambiguous, I
mean that semantically one could interpret some options in
different ways.
3. It is not as simple as the STL format!
Based on the above, you will not find me on the band wagon chearing
for the VRML format as a replacement for the STL format.
We have implemented the format and will support it in our products for
other reasons.
However, I am extremely interested in participating in a serious discussion
and effort to define a new format to enhance the STL format.
The requirements of such a format (my private opinion) will be:
1. The file will represent only polygons (preferably only triangles - simpler).
2. Indexed vertex representation.
3. Color and Normals representation but such that it is valid and simple
to omit (on write) or to ignore (on read).
4. For the color and normals: support for per vertex definition,
or per part definition, specifically with the ability to define
normals across creases (tangent discontinuities - at a single vertex
more than a single normal).
5. SIMPLICITY.
6. ????
In fact, I have started playing around with syntax definitions for a
format I coined TFF (Triangular Facet File). I will be more than
happy to share this discussion directly with all interested, or if
enough interest is generated, to open the discussion on the mailing list.
Yuval Roth, Imageware Inc, 313 N. First St, Ann Arbor, MI 48103
Email: yr@iware.com Voice: (313) 994-7300 (28) Fax: (313) 994-7303
This archive was generated by hypermail 2.1.2 : Tue Jun 05 2001 - 22:37:05 EEST