It is a sad fact that OpenScad can't import a lot of the STLs it makes
itself. I think it re-quantises vertices and they collapse. It also doesn't
detect invalid meshes until you do a CGAL operation on them.

You can isolate the problem one by just importing each one in turn and
unioning it with a cube().

If you post the code for the problem piece I might be able to suggest a
fix. I spent a many hours fixing up Mendel90 recently.

On 27 January 2016 at 13:04, Johan Jonker johangjonker@zonnet.nl wrote:

I often use NetFabb Basic on larger STL files. It usually produces
visually identical STL files which are much smaller than the originals.

Jon

On 1/27/2016 8:49 AM, Trygon wrote:

I that because it writes binary STL files by default?

On 27 January 2016 at 13:59, jon jon@jonbondy.com wrote:

On 27. jan. 2016 14:23, nop head wrote:

Regardless of how OpenSCAD treats the STL files on import (it probably
could be improved), it shows that STL is the wrong format for
intermediate storage of parts when the intention is re-import for assembly.

Why is it the wrong format? Because STL files do not contain any
topology at all, so when you import the STL for further use in boolean
operations, the topology must be guessed and reconstructed using unsafe
coordinate comparisons. It is inefficient and bound to fail in many
cases, and it does. By 'fail' I mean the reconstructed topology is not
exactly the same as the original.

A better solution for this purpose would probably be to store one or
more computed polyhedrons to a file (assuming one takes an approach
native to OpenSCAD). The idea would be to allow such polyhedron files to
be re-imported as an alternative to STL. It would guarantee that the
imported object is the same as the exported object, it would be more
compact since each vertex is mentioned only once, and it would be faster
to process because no vertex matching would have to be done. You could
think of it as ready made 'parts' files that needs to be imported into
openscad as in the original mouthpiece example, just using a different
format for intermediate storage.

If you don't want to introduce another format for this purpose, perhaps
AMF could serve the same purpose, although the present (2015.03-2)
implementation of AMF export does not seem to separate between
independent bodies. I just tested it with a model containing several
bodies and they were written to AMF as a single <object>. For AMF to
work as intermediate format the way I described, each <object> on AMF
would have to be a valid polyhedron. AMF is an XML format so you could
perhaps add a property to the object type to indicate it is indeed a
polyhedron:
<object id="0" type="polyhedron">

Just my thoughts.

Carsten Arnholm

However deficient STL is, it is still possible to use it to represent 2
manifold meshes unambiguously, although it is very easy to make broken
ones. It is safe to compare vertex values as long as it has been written
correctly. I.e. topologically distinct vertices must have different
numerical values in the file representation and all vertices that are
equivalent must have exactly the same file representation.

The only reasons OpenScad can't import some of its own STLs and a lot of
perfectly good ones from other systems too is because it reduces the
precision of vertices without correcting the topological consequences. I
don't think AMF will help in this respect. You can't simply truncate from
higher precision to float or snap vertices to a grid without running the
risk of corrupting the topology.

On 27 January 2016 at 15:11, Carsten Arnholm arnholm@arnholm.org wrote:

In addition: Zero area triangles is a perfectly valid in a manifold topology, but CGAL cannot handle that since it computes normal vectors in isolation and zero area gives no useful normal vector.

-Marius

On 27. jan. 2016 16:34, nop head wrote:

It appears I didn't manage to communicate properly. I have been doing
similar stuff in other areas and my experience is that a coordinate
based approach will often fail in preserving the original topology.
Maybe you are unlucky and end up with a valid topology describing
something different than the original intent, or alternatively it
becomes invalid. Wrong in both cases.

Yes, topologically distinct vertices must have different numerical
values when using STL. But since vertices are repeated you don't have
any guarantee that what should be one and the same vertex ends up with
numerically identical values in all repetitions. There could be many
reasons for this and you have to apply some tolerance on import,
creating its own set of issues.

Another thing is that there is no guarantee that an STL file even had a
valid topology in the first place, i.e. face corners ending between
vertices of another face. Or you might end up in that situation because
the wrong tolerance approach was applied.

My point is that this is really impossible to get right in all cases and
the solution is not to try, because there are simple and safe
alternatives which store the topology. AMF was just a suggestion since
it already exists in OpenSCAD, a native polyhedron format would perhaps
be better for openscad.

No, coordinate precision is irrelevant wrt. restoring the topology when
you represent the vertices separately as in AMF and other formats. The
topology is explicitly stated separately from the vertices and no
guessing/interpretation is required.

Carsten Arnholm
http://arnholm.org/

Yes they are still manifold but they cause other programs problems for the
same reason so should be removed.

On 27 January 2016 at 15:54, Marius Kintel marius@kintel.net wrote:

At the time OpenScad writes the STL it knows the topology, so there is no
reason why it can't write every repetition of a vertex with an identical
numerical value and ensure all non identical values are distinct.

Yes you can't guaranteed an STL from another program is valid but can
guarantee to write valid ones and be able to read ones that are valid.