Perhaps they intersect, so that although each mesh is manifold, the result
isn't.

On 27 January 2016 at 11:42, Johan Jonker johangjonker@zonnet.nl wrote:

On second thoughts that shouldn't be a problem. Please can you attach the
STL for the outside.

On 27 January 2016 at 11:48, nop head nop.head@gmail.com wrote:

According to Netfabb the mouthpiece inside has degenerate triangles.

​

On 27 January 2016 at 11:53, nop head nop.head@gmail.com wrote:

Just click on the red cross button.

On 27 January 2016 at 12:17, Johan Jonker johangjonker@zonnet.nl wrote:

It is caused by vertices so close together in one dimension that the
triangle collapses into a line or a point when its vertices are converted
to floats. OpenScad should fix when exporting STLs but as yet it doesn't.
The only way to avoid it is to avoid very close vertices. E.g. don't have
things meeting tangentially, overlap a bit, etc.

I can be tricky if you mix vertices created in 2D with ones created in 3D
as they can be slightly difference numerically.

On 27 January 2016 at 12:32, Johan Jonker johangjonker@zonnet.nl wrote:

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.

On 27. jan. 2016 17:18, nop head wrote:

From what I said before it is clear this is not a sufficient requirement.

Anyway, I just shared some thoughts, you are of course free to ignore them.

Carsten Arnholm
http://arnholm.org

Have you considered creating these 3 parts as a single OpenSCAD
operation, rather than as 3 separate ones?  Is the issue that they each
take a long time to calculate, so you are trying to pre-compute some of
them to save time?  Perhaps we can help you optimize some of the code so
that re-calculating each one is more tolerable.

Jon

On 1/27/2016 11:37 AM, Johan Jonker wrote:

It isn't a good tool for reading STL files. If you create all the geometry
in OpenScad and then write an STL it should be fine.

On 27 January 2016 at 16:37, Johan Jonker johangjonker@zonnet.nl wrote:

I agree with this.
Also, we’ll eventually get this fixed, so the future will be brighter :)

-Marius

Isn't this a very good argument for the idea of an openSCAD format cache of objects, and the ability to programatically  load/save individuals shapes from a list of shapes? These two concepts have been discussed at length in other threads and deserve consideration as a valuable in house feature if not of universal use to the 3-D community as a whole? Or have I oversimplified it all?

On 28 January 2016 2:11:21 AM AEDT, Carsten Arnholm arnholm@arnholm.org wrote:

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.