RE: STL for ever?

From: Anshuman Razdan (razdan@asu.edu)
Date: Thu Dec 16 1999 - 19:55:49 EET


Thanks for the pot shot at the academia. I am sure my collegues would
appreciate that comment.

Now to the point (without turning this into a flame war) - Yes, the
prevasiveness of STL is not in question. The debate is whether to look ahead
and cure the problems. Ofcourse STL format is so simple it can be translated
into any new format that is designed. Even though bandwidth and memory is
not that much an issue now (again we in academia are used to T1/3 lines and
internet-2) the redundancy of vertices is still a waste and any good
software architect will tell you that this kind is a drag on the performace.
I make my academic case below:

Lets look at some numbers:

If there are N vertices, atmax there are 2N triangles in a mesh. For a STL
file (binary format - minus the header of 80 bytes) its 50 bytes per face

so total bytes come to 2*50 N bytes.

For N = 1000,000 (1 million traingles)

total bytes = 100 * 1000,000 = 100 x 1e6 = 100 MB of memory

Now lets consider another format for comparison sake to generate the same
information as the STL file (I am not recommending this format this is for
comparison only). All the vertices are listed first so they appear only once
in the file so there is 12 bytes/vertex information (keeping it the same
i.e. floats). Its followed by faces. Each face has three unsigned int for
vertex id (4bytes for the vertex id - a vertex id is generated from 0 to N
where vertex appearing at 'l' would get id 'l') i.e. 12 bytes. No need for
the normals since normals can be computed by doing a simple cross product.

So per vertex 12 bytes - for N vertices = 12 N bytes
Per face 12 bytes and for 2N faces = 12*2*N bytes = 24 N bytes

In this case if 2N = 1e6 i.e. number of faces 2N = 1 million then number of
vertices = N = 1e6/2 = 5 e5

for 1 million triangles - i.e. 2N = 12 * 1e6 = 12 MB
number of vertices 5* e5 * 12 = 6 e6 MB

Total bytes = 12 MB (faces) + 6 MB (vertices) = 18 MB

Hmmm that is less than 1/5th of the stl file. You dont have to do any
checking whether two vertices that are off in 4th decimal place are really
the same or not, etc etc etc. I wont even go into processing times and other
software issues.

This information provided as a free service of the academia.

AR

-----Original Message-----
From: Tom Richards [mailto:tomr@aicasting.com]
Sent: Thursday, December 16, 1999 1:24 PM
To: Anshuman Razdan
Cc: rp-ml@bart.lpt.fi
Subject: RE: STL for ever?

I don't design and export stl files. I USE good stl files made by others. I
process about five to ten stl files per day. Perhaps those of you in
academia are not aware of the heavy use of stl files around the world.

At 10:08 AM 12/16/99 -0700, you wrote:
>If it was robust STL repair software would not be in business.
>
>AR
>
>-----Original Message-----
>From: owner-rp-ml@ltk.hut.fi [mailto:owner-rp-ml@ltk.hut.fi]On Behalf Of
>Tom Richards
>Sent: Thursday, December 16, 1999 9:36 AM
>To: rp-ml@bart.lpt.fi
>Subject: STL for ever?
>
>
>Hello all:
>
>Charly Fruth said:
>
>"STL- Format has also big advantages:
>1. Public
>2. Available in nearly all Systems
>3. Easy to use
>4. Flexible in use
>I could imagine to define an easy Extension:
>We could use the SOLID keyword. SOLID INSIDE will define an area in the
>part with special specifications, like SOLID INSIDE Ccolor
>Mmaterial,...
>This could be ease because everybody could use STL like before. If there
>is a CAD System they can use the new extension. A filter could seperate
>SOLIDS with the new extension."
>
>I would add:
>5. Robust in transfers
>
>My experience with STL in foundry work suggests that it is a robust format
>for file transfers in getting fabber business done. If you need better
>detail, you simply go to a larger file (more bytes), and today's computers
>and data transfer systems handle them with ease.
>
>I hope that some of you software gurus will jump onto Charly Fruth's
>bandwagon, and develop the extensions, which will make STL "all that it can
>be".
>
>
>
>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:53:48 EEST