On 2016-01-31 23:40, MichaelAtOz wrote:

These cases appear to be good examples illustrating that STL will always
be a problem for import with the intent of performing further boolean
operations. The fact that different software report different problems
(or sometimes none at all), is a further aspect of this.

STL isn't perfect as input to slicers, but for that purpose it isn't
quite as critical that everything is water tight. For booleans, however
it is critical. Put differently, any format that does not bring along
its own topology will be an eternal problem for booleans.

Carsten Arnholm

It doesn't matter what the file format is, if it has self intersections
some programs won't like it, others don't care. If you look at the
kisslicer key you see there is no colour for self intersections.

Also what classes as degenerate triangles seems to vary between programs. A
true degenerate triangle has zero area, so is a line or a point but very
thin triangles are counted as degenerate by some programs.

I think anything with vertices too close together will upset OpenScad due
to its snap to grid, nothing to do with STL.

You keep repeating STL cant preserve topology, but that doesn't make it
true. If it is written correctly and read correctly topology can be
preserved unambiguously it is just implicit not explicit. If the source or
target resolution is different from the file resolution then it is
difficult to get right, which is why most programs are buggy.

Using a file format with explicit topology would still fail in this case.

On 1 February 2016 at 08:36, arnholm@arnholm.org wrote:

On 01. feb. 2016 10:26, nop head wrote:

That's pretty much beside the issue. If the original topology is
self-intersecting or otherwise wrong, the file format obviously does not
matter. However, when the file representation does not include explicit
topology, then you have no way of knowing what the original definition
was, it might have been good. It might be the guess the software made on
import that was wrong, you cannot tell. That was sort of my point.

Also, the fact you point to, that different programs interpret the same
input differently, should be a pretty strong sign that using geometry
only representation is too weak for further boolean work.

Sure, but how is that relevant for topology and boolean operations? I
Use KISSlicer. KISSlicer is a slicer and does not do boolean operations.
As I mentioned earlier "STL isn't perfect as input to slicers, but for
that purpose it isn't quite as critical that everything is water tight."

This is talking about geometry. Topology is completely decoupled from
geometry.

Again, this is geometry.

Again, you are talking about geometry. That is a different issue,
although important.

Well, you keep asserting the opposite, but mere assertions does not make
it true either. Therefore, let me give you one very simple example where
a geometry-only representation will fail to preserve the original
topology: http://arnholm.org/tmp/openscad/topology_stl.png

The above is simplified, but from a real-life case in a related field
and has not been constructed from pure theory.

With all due respect, this is not true. See above for one example.

Correct geometry is also very important, I agree with that. OpenSCAD has
the problem you describe.

But it is a separate issue from topology. I will give some examples
below on how STL as implemented also fails to preserve geometry
correctly given the intent of performing boolean operations.

Understanding communicated topology is unrelated to numerical
resolution. How you apply the topology and geometry is something else.

On the question of geometry: I did some simple tests on creating and
importing STL files with the intent of performing boolean operations.
The .scad and related STL files (the STL files can also be created from
the example itself) are found in
http://arnholm.org/tmp/openscad/topo_geo_test.7z

I also copy the OpenSCAD code below. This illustrates that STL files as
implemented today also fail to preserve geometry 100%, leading to errors
when trying to import and perform boolean operations. Like it or not,
STL is not suited for such purposes.

// Render with "F6" on each step
step=1;

if(step==1)
planes();
// export as "step1.stl"

else if(step==2)
import(file="step1.stl");
// re-export as "step2.stl"

else if(step==3)
diff3();
else if(step==4)
diff4();
else if(step==5)
diff5();
else if(step==6)
diff6();

module planes(h=.1)
{
rotate([22,33,44])
union() {
linear_extrude(height=h)square(30);
translate([-25,15,-15])
rotate([90,0,0])
linear_extrude(height=h)square(30);
}
}

module diff3()
{
difference() {
planes();
planes();
}
}

module diff4()
{
difference() {
planes();
import(file="step1.stl");
}
}

module diff5()
{
difference() {
planes();
import(file="step2.stl");
}
}

module diff6()
{
difference() {
import(file="step1.stl");
import(file="step2.stl");
}
}

Carsten Arnholm

What is the alternative to STL? What's an example of a polyhedral mesh file
format that includes explicit topology?

On 1 February 2016 at 14:49, Carsten Arnholm arnholm@arnholm.org wrote:

On 01. feb. 2016 21:06, doug moen wrote:

AMF has already been mentioned. Not because it is ideal, but simply
because it exists and is already available as an export format in OpenSCAD.

Other possibilities have been mentioned also.

Carsten Arnholm

The example you gave of the crack is non-manifold if vertices 5 & 7 are not
distinct.  STL can represent manifold meshes unambiguously and you can then
do boolean ops on them. It is no different to constructing a polyhedron
inside OpenScad. As long as you make it manifold CGAL will work, if you
don't it will barf.

As soon as you have topologically distinct vertices that are numerically
the same STL can't represent the topology, but that doesn't matter because
we are only interested in 2 manifold meshes for CSG.

As long as you have the property that topologically distinct vertices that
are numerically distinct then you can convert a mesh to a list of triangles
and then reconstruct the mesh from those triangles. It will be exactly the
same. Although there is no explicit topological information in the file the
reconstructed mesh has exactly the same topology as the original. If this
wasn't the case STL would be completely useless.

The weakness of STL is it relies on vertex values not being rounded or
truncated. They must be written and read with great care, especially in
ASCII. The reason lots of programs can't read it or write it correctly is
because it isn't easy. OpenScad can't do it correctly in all circumstances.
As soon as you round or truncate you run the risk of breaking the topology.
Yes topology: if you collapse two vertices that were not previously
touching you have changed the geometry minutely but you have changed the
topology, which is what causes the problem.

Degenerate triangles are a different problem. Agreed they don't break the
topology and are still manifold. They still have a winding order, so you
can work out which way out they face but you can't work out a face normal,
which upsets some programs.

Your multi-step problem is nothing to do with topology. It is simply that
converting the vertices to float from a higher resolution has moved them a
bit. When differenced with the internal representation you get a non zero
result. When the vertices are very close then truncation can cause
topological corruption and that needs to be corrected before writing the
STL, but in this case that doesn't apply. The original vertices are at
least 0.1mm apart.

When imported the results are differenced with the non-trucated versions
the result is very thin slivers and OpenScad seems to not be able to handle
them correctly. Not too surprising as they only differ by less that the
resolution of a float.

Doing the same thing with any other file format will result in the same
mess if the vertex representation is different from OpenScad's. The
problems are purely due to truncation to floats.

step1.stl and step2.stl have exactly the same vertices. The only difference
is the face normals differ slightly. This must be because they are
calculated using the higher precision internal representation, not the
actual vertex values written in the file. Step 6 is correctly empty.

On 1 February 2016 at 20:25, Carsten Arnholm arnholm@arnholm.org wrote: