stl and such

From: Gill Barequet (Tel Aviv  University)
To: RP-ML
Date: Thursday, September 29, 1994
Subject: stl and such
Hi all.

There has been quite a massive correspondence lately here, concerning the
need/wish/etc. of a file-format in which there is a vertex list first
and then a polygon list, referring the first list.

For example, Elaine Persall asks (message dated 26/9/94):
> Is an RP vendor working on this and who has input into its development?

True, a lot of words were said here, so it is impossible to remember what
has been said, when, where, by whom, etc. I would like to repeat a message
I posted in this mailing group few months ago. It relates to the above
mentioned question.

During the past 7 years, Cubital Ltd has been using such a file format.
It includes a general header, object header, vertex list and a facet list.
The group of the last three   (-----1------, -----2-----,      -----3----)
may appear many times, for supporting multiple objects in one file.
The ascii version aims to minimize the number of needed keywords (just count
how many keywords you write in order to specify one triangle in STL), and
to support as many info-fields as you like. The binary version contains the
same info, occupies less disk space, but is somewhat less readable in a text
editor...

In my opinion, an example is better than a formal definition. So below
you can find the definition of a unit cube in this format. I do not try to
claim anything in favor of this specific format, but only in favor of the
SPIRIT of it. After all, a format is only a format, and once you agree WHAT
you want to say, the choice of the details are of much less importance.

This is the point to thank Andre' Dolenc for his helpful comments which helped
in the design of later versions of the format. For example, he offered the
option of specifying a global vertex list, to which ALL the objects in one
file can refer, in addition to a vertex list local to its object. (This
option is not included in the example below.)

************************************************************************
(I marked this paragraph in order to get your attention to it.)
By the way, there was a meeting during the Autofact '91 exhibition, with
the participation of representatives of all the major RP vendors + few
users and journalists. The subject was the future of the STL format. The
users and journalists were not active enough (I can compile a list, so
that we can know who to blame now...), and one vendor, guess
yourselves who it was, succeeded in preventing any serious attempt to
suggest any changes.
Now that the users (+ academia) speak louder and say what they need, it is
time to demand needed changes, if there are any. I suggest to just consider
the following scenario:
SUPPOSE, only suppose, that the users community decides upon a nice format,
and accommodate it with simple from/to software. At the beginning there will
be no compatibility problems (due to this from/to software). If this format
proves itself sufficiently useful, than there will come the point in time
where packages/whoever prefer to write directly in this format. Just suppose.
************************************************************************

Gill.

----------------------------------------------------------------------------

! I'm a comment (always from a "!" sign till the end-of-line)
! (Few hints: format is case INSENSITIVE, blank characters [blank, NL,
!  FF, tab etc.] can appear everywhere, every field of the form <name=value>
!  can also appear as <name  =  value>, <name: value> or even <name value>,
!  string values which contain blank characters should be quoted.)
HEADER
   name = "Unit cube"
   unit = MM
   ! ... and some other OPTIONAL fields. Every reading software should at
   ! least know how to read expressions of the form   X = Y   and ignore
   ! them if it doesn't understand what  X  is.
   ! To avoid the known scaling problem, we enforced only the <UNITS=???> field.
   ! Also, every UNAMBIGUOUS abbreviation is legal.
END

OBJECT  cube
   N_POINTS = 8  ! \  We are OPTIONAL fields. We appear only for checking
   N_FACETS = 6  ! /  purposes, and the reading software should compare us
                 !    to the actual numbers. If we do not appear, the
                 !    reading software will find us by itself.
END

POINTS
! seq #     X     Y     Z        ! The seq # may start from ANY number,
   0       0.0   0.0   0.0       ! not only from 0! The only important thing
   1       1.0   0.0   0.0       ! is that the numbers will be IN SEQUENCE
   2       1.0   1.0   0.0       ! with no missing indices, so that the
   3       0.0   1.0   0.0       ! reading software can detect missing
   4       0.0   0.0   1.0       ! vertices, if any.
   5       1.0   0.0   1.0
   6       1.0   1.0   1.0
   7       0.0   1.0   1.0
END

FACETS
! # of holes
!  \   /
!   \ /
!  # * len ...indices...   ! As is seen on the left, each facet is composed of
   0 0 4   0 1 2 3         ! its seq # (again, can start from ANY number, but
   1 0 4   0 4 5 1         ! should be in sequence!), number of holes (in this
   2 0 4   1 5 6 2         ! example all the facets have 0 holes; an example
   3 0 4   2 6 7 3         ! with holes is given below), number of vertices
   4 0 4   3 7 4 0         ! (all the facets in this example have 4 vertices),
   5 0 4   4 7 6 5         ! and finally a list of vertex indices.

   ! An example to a facet with holes: Suppose a rectangular facet (#17)
   ! has two triangular holes. Then the sequence should look:
   ! ...
   ! 16 ....   (facet #16)   Note that facet #17 has 2 holes, as indicated.
   ! 17 2 4    1 2 3 4       After its description you see the two holes.
   !  0 -17 3    21 22 23    They have a separate sequence of numbers! They do
   !  1 -17 3    24 25 26    not have holes, so instead of the #-of-holes field
   ! 18 ....   (facet #18)   they indicate their parent facet by specifying
   ! ...                     the negation of its seq # (-17, in this example)
END

------------------------------------------------------------------------
Gill Barequet