Hi Steve,
For those of you who don't know him, Steve's company is responsible for
Chip Hazard and those other great characters in the movie, "Small Soldiers."
Take a bow, Steve.
Your comments on the StL spec are accurate. The normal data are
redundant and are often not used by software reading StL files. Using the
normal fields for other purposes would result in files that are
*conditionally* backward compatible. In other words, they would be
compatible except for software that is diligent enough to check those
fields.
The idea of extending the StL format to convey color and other info has
come up before. Due to other limitations in the format, I am more inclined
to favor superceding the format with a more robust and more versatile spec.
This will probably be done by the next company to take the lead in delivery
of large numbers of fabbers in the marketplace. It will always be easy for
software to continue to support old StL files while beginning to standardize
on a new format.
Best regards,
Marshall Burns
*****************************************************************
Marshall Burns, President
Ennex(TM) Corporation
Fabbing the Future(TM)
10911 Weyburn Avenue, Suite 332, Los Angeles, U.S.A. 90024
Phone: +1 (310) 824-8700. Fax: +1 (310) 824-5185
E-mail: fabbers@Ennex.com. Web site: http://www.Ennex.com
*****************************************************************
***** Copyright (c) 1999, Ennex Corporation
-----Original Message-----
From: SCat3D@aol.com <SCat3D@aol.com>
To: rp-ml@bart.lpt.fi <rp-ml@bart.lpt.fi>
Date: Friday, May 07, 1999 09:40
Subject: Re: STL spec
>Marshall,
>
>Glancing at the binary STL file spec on your site.... I believe there is
room
>in the spec to add color or layer information for each triangle. (Or
anything
>else, such as storing supports and part in the same file.) Where? The 3
>4-byte floats storing normal information seem redundant. The normals can
be
>computed on-the-fly by looking at the clockwise-orientation of each
triangles
>3 vertices. Therefore these normal bytes can be used for storing other
info.
>
>This method would actually be backwards compatible with older software. I
>regularly feed stl files to programs like Solidview, Deskartes viewer,
>Allegro, etc. that have ZEROES where the normal info is stored. None of
>these programs seem to have a problem with that. (we use some custom
>programs made by a programmmer too lazy to add normal-computation to the
stl
>output routines.) In other words, for example, I don't think Solidview
even
>looks at the normal data.
>
>In addition, the 80 byte header could be used to store translation
>information concerning the new information stored where the normals were.
>
>It seems to me that we could get a lot more mileage out of the STL spec for
>use in future technologies and software. I leave it up to the keepers of
the
>format, 3D Systems, to do something to bring this file format into the 21st
>century. It could start with a simple re-write of the STL spec, or a
>users-group initiative.
>
>-Steve
>Gentle Giant Studios.
>
>For more information about the rp-ml, see http://ltk.hut.fi/rp-ml/
For more information about the rp-ml, see http://ltk.hut.fi/rp-ml/
This archive was generated by hypermail 2.1.2 : Tue Jun 05 2001 - 22:51:40 EEST