Re: [rp-ml] STL Round off errors

Charles Overy wrote:
> This thread begs the question of why we, as users and vendors, tolerate STL
> at all.
> A vertex list with separate vertex traversal order is far more efficient,
> flexible and robust. And dare we even want for a part structure that
> maintains shells and meta data that passes such inconsequential information
> as UNITS.

Certainly it seems that of all the 3D formats in all the world, this is
by far the crudest.

That has plusses and minuses:

* Plus: It's easy to write software to read it.
* Plus: It's stable - many proprietary formats change with each new
   software release causing terrible grief.
* Minus: It's missing some features you need (like units).
* Minus: It's just a description of WHAT the object is - not HOW to
   make it (eg: Z is up please!)

There are a million alternatives - and that's really the problem here.
Too many standards.

Whenever anyone in power sees this problem they invariably say "OMG!
There are a gazillion different 3D file formats out there! We need a
standard!"....and shortly after we have a gazillion-and-one file
formats.

We have (or arguably, *had*) the same problem with 2D image file
formats. Two things have helped that:

1) Most images need to end up on the Internet at some stage - which
    means that we need browsers to support our file formats or else
    they are almost useless. Hence JPEG, GIF and PNG end up being the
    three most prevelant formats (JPEG is great for photos where quality
    doesn't matter, GIF is best for simple diagrams and PNG is the gold
    standard for quality that does everything). Since 3D models are
    rarely used on the web (VERY rarely!) there are no really common web
    standards (No - please don't say VRML).

2) With a 2D image, it's easy to provide a standard library that reads
    the file and passes it to an application. Since all images tend to
    end up looking like a 2D array of pixels - those image load/save
    libraries can present a very simple interface to the application
    program - and it's very easy for application authors to support a
    bunch of formats with very little effort. This existance of standard
    libraries tends to result in good portability of data - if 'libpng'
    wrote your PNG image then it's pretty certain that libpng will be
    able to read it back again. Since 99% of applications that use PNG
    use libpng - they are easily 99% compatible.

    With 3D data, there is no standard for how the data is represented
    inside the application program. Generally you want to load it into
    a highly structured 'scene graph' - but there are as many scene graph
    packages as there are file formats - so it's impossible to write
    file load/save libraries that many applications can use. This is
    indeed a hard nut to crack - and I don't have anything remotely like
    a good solution.

    The consequences of a lack of useful standard 3D loaders is that
    it's hard work for application authors to support a wide range of
    formats - and when they do, they tend to find it hard to support
    *ALL* of the features that the file format can represent. Hence,
    when you import a 3DStudio file into (say) Blender, you find that
    something small didn't come across correctly - maybe some 'edge
    group' flag is missed. So when you import a 3DS file into blender
    and simply export it again - a whole bunch of stuff is missing.

    This is a REALLY hard problem - and the more sophisticated the
    file formet - the worse things become.

So if STL had "Units=Inches" or "Units=Meters" or "Units=Cubits"
in it's header, the odds are good that some existing 3D modellers
would have no place to keep that fact. The odds are good that you'd
read the file in inches - then find that when you save it, the tool
wrote it out with "Units=Meters" and everything would still be
screwed up (but more authoritatively than before).

I don't know what the answer is - but it's not a trivial thing
for the industry to fix.
Received on Wed Jun 21 23:28:44 2006