RE: [rp-ml] Colour STL files?

Several people leaped to my aid with information about colour STL file
variations - and the Wikipedia article entitled "STL (file format)" now
includes all of that information.

Thanks to the MANY people who sent me this information.

Sadly, the two variations on colour STL are horribly incompatible
because one company put the colours in the order R, G, B
and the other in B, G, R.

There can be no technical justification for doing that. This
kind of thing just shouldn't happen.

Even software and machine vendors who are competitors should have
a responsible attitude to the community and design data formats
that are inter-operable. Especially as (in this case) it would
have been quite utterly trivial for the two companies to have
been compatible on this score.

Both variations abuse the original binary STL "standard".

In the standard there are two bytes at the end of each triangle's
description that are supposed to indicate the number of ADDITIONAL
bytes of 'attribute' data included after the vertices. This number
is generally zero because there are no attributes defined yet.

So, theoretically, if you wanted (say) a three byte Red/Green/Blue
colour per facet, you'd have set the the two attribute length bytes
to say '3' and tacked on three extra bytes for each facet. That way,
a correctly written existing STL parser (that doesn't expect colour)
might be expected to skip those three bytes.

However, both variations abuse that mechanism by using the two attribute
length bytes to directly store the colour. It is clear that the reason
for this is that both vendors believed that those two bytes were
'padding' to round out the binary data size to 50 bytes (although
why the heck anyone who works with computers would think 50 was a
more 'round' number than 48 is a complete mystery - especially because
those two extra bytes mis-align the 'float' data records which makes
programming the reader harder, not easier). Ignoring the
many versions of the binary STL specification out there (which
clearly states the true purpose of those two bytes) - clearly someone
assumed they were spare and could be used to store the colour directly.

Hence, both variations of the format use the most significant bit
of those 16 bits as a flag that indicates whether this facet has
a colour or not, then they pack the three colour components into
the remaining 15 bits as three five bit numbers.

OK - well, I guess that works...but, oh - wait...

Unfortunately (if my information is correct - and I have multiple
sources that agree on this point), one format stores the colour
components in the order Red/Green/Blue and the other in the
order Blue/Green/Red!

This means that not only is it impossible to write a loader that
correctly figures out which varient of the STL format you've got - but
if you guess incorrectly, your colours look exceedingly weird!

Neither version is reverse-compatible with a correctly written loader
for the original binary STL format.

Aaaaarrrggggghhhhh!!!!!! Stupid, stupid, stupid!

The STL format really is a piece of junk - that this could have
become the de-facto standard across the entire industry is horrifying.

We could have come up with a vastly better standard in about 2 minutes
flat and fitted the description on the back of an envelope.
Received on Thu Nov 23 15:29:23 2006