On 2 February 2016 at 19:00, Carsten Arnholm arnholm@arnholm.org wrote:

OK if they are distinct then there is no problem representing them in STL.
Your "plate with crack represented as STL" is not how that surface will
actually be represented in an STL file.

difference() {
cube([20, 10, 1]);
translate([10, 0, 0])
cube([1, 5, 3], center = true);

}

This is how the triangles appear in the STL file.

​
​
Here I import the STL file and do CSG on it.

difference() {
import("cracked_plate.stl");

translate([5,5,-1]) cylinder(h = 3, r = 1);

}

​

No the above shows that you are incorrect. You don't seem to able to
comprehend how a triangle mesh can represent a 3D object. There is no
information lost writing an STL file and reading again unless the vertices
can't be represented accurately in floats.

No it is you. You don't seem to grasp that STL representation preserves
everything apart from possible numerical exactness as long as the reader
and writer preserve distinct vertices.

If distinct vertices get merged then there is no problem importing it again
UNLESS the topology is changed from a 2-manifold to something else due to
self intersections.

In my mind the geometry has not changed when you import your STL files.
They are still geometrically classed as intersecting planes. The fact their
vertices are minutely different doesn't change the geometrical
classification or the topology. You can still perform CSG on them.

All it shows is that if you create some planes with irrational vertices
they can't be represented accurately in floats. If you shift those vertices
by minute amounts and then subtract from the original you get some minute
slivers that OpenScad cannot handle. You might as well have done this:

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();
rotate([0.0001,.0001,.0001])
planes();
}
}

diff3();

Top level object is a 3D object:

Simple: no

Vertices: 64

Halfedges: 198

Edges: 99

Halffacets: 76

Facets: 38

Volumes: 4

WARNING: Object may not be a valid 2-manifold and may need repair!

Nothing to do with STL files at all.

No the geometry is preserved. They are still intersecting rectangles
planes. They haven't become triangular or something.

If as a I said many times before "if the conversion to floats does not
collapse vertices and the object is 2-manifold then the STL file can be
read back into OpenScad and operated on with CSG". There isn't  any missing
topological information as you keep suggesting. It is implicit in the list
of triangles. When it is read in you can make a list of unique vertices and
a list of triangle edges that connect them. You can then convert to
OpenScad's internal representation just the same as the polyhedron module
can given a list of points and faces linking those points. The result is a
first class OpenScad object. It has lost nothing being converted to STL and
back except perhaps some numerical accuracy.

The loss of numerical accuracy is nothing to do with STL in particular. Any
file format that is less precise that OpenScad's internal precision will do
the same. My understanding is some vertices are represented with rational
numbers, so it is unlikely any file format will preserves those exactly. So
your example would probably do the same exported and imported as AMF.
Having extra topological information in the file doesn't make any
difference at all unless you have the situation where numerical truncation
collapses vertices. Then you can use extra information about the faces and
edges to know which vertices are actually distinct topologically but not
numerically. However it is possible for the STL writer to handle this, it
is just that many don't because it isn't trivial to do. Vertices that
collapse numerically have to be tweaked by an LSB so they are distinct but
that has to be done in a way that doesn't corrupt the topology. E.g. if
they are moved in the wrong direction they might cause flipped triangles or
self intersections.

So basically everything you have asserted about STL files is false and I
have demonstrated that with counter examples. We seem to have different
ideas of what geometry and topology are but that isn't really central to
the issue of what STL files can or can't do.

On 02. feb. 2016 21:38, nop head wrote:

Just continue where you are heading, you will do it anyway. There is no
point in debating this anymore.

Carsten Arnholm

I don't understand what you mean by that but if you mean that I will
continue to use STL files to represent manifold geometry without any loss
of topological information you will be dead right.

On 2 February 2016 at 21:10, Carsten Arnholm arnholm@arnholm.org wrote:

cacb wrote

Sorry, Carsten, but I desagree. This is a fascinating discussion!

You may code a polyhedron in OSCAD topologically representing a Klein bottle
but for any set of vertices you use the result will not represent a Klein
bottle. Non-orientable spaces are not embedable in Euclidean 3D spaces. So,
even with added topological information, some models are misundertanded or
misrepresented by any CAD software.

Now, consider the following two polyhedrons:

p1 = [ [0,0,0], [0,0,100], [100,0,0] , [0,100,0] ];
f1 = [ [0,1,2], [0,3,1], [1,3,2], [0,2,3] ];
module P(){
polyhedron( points=p1, faces=f1);
}

t2 = [10,10,10];
p2 = concat( p1,  [ [0,0,0] + t2, [0,0,100] + t2, [100,0,0] +t2, [0,100,0]
+t2];
f2 = [ [0,1,2], [0,3,1], [1,3,2], [0,2,3], // just the 4 first points
[4,5,6], [4,7,5], [5,7,6], [4,6,7] ];// just the 4 last points
module Q(){
polyhedron( points=p2, faces=f2);
};

P() is a tetrahedron. Q() is formed of two intersecting tetrahedrons. You
may render any of them and generate their STLs without any error. I was able
to union Q() with a small cube centered at the origin with no CGAL error.
But don't try it with a bigger cube. Neither try any projection-cut of Q()
translating it down by something between 10 and 110. The imported STL of it
shows the same behaviours of CGAL.

If you load the STL of Q() in Slic3r or Simplify3D you will be able to
generate G-code files. And print it! However don't have great expectancy of
them. Slic3r and Simplify3D will show distinct interpretations of the STL:
Slic3r will take the union of the two tetrahedrons and Simplify3D will leave
a void where they intersect.

The lesson here is that a topological 2-manifold embeded in 3D with
self-intersection is a trouble for all software. It is hard for the
algorithms to detect self-intersections. And there is not an unique way to
interpret what it means, what is inside, what it represents.

I agree with your criticism to STL format. But the inclusion of topological
information is not sufficient to get rid of troubles. From the point of view
of CAD software and 3D printer software, both, topology and geometry, must
be considered together.

--
View this message in context: http://forum.openscad.org/dxf-and-stl-import-rendering-issue-tp15979p16026.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Yes polyhedron should actually check the object is manifold and so should
import. You don't get any errors until CGAL operates on it and then only
cryptic ones.

Also CGALs simple: yes is misleading. I thought simple meant it was
manifold but it must mean something else. Volumes: 3 is a give away.

On 3 February 2016 at 15:07, Ronaldo rcmpersiano@gmail.com wrote:

On 03. feb. 2016 16:07, Ronaldo wrote:

I don't have any issues discussing these topics with open minds, anyone
willing to be constructive and consider the factual evidence. I just
resent being met with misrepresentations of my own position in
combination with simple strawmen.

You bring in new aspects, which I find interesting, so I will comment.
Thank you for taking the initiative to do so.

A Klein bottle is a rather theoretical self-intersecting thing, I am
mostly interested in physical things that can be realized. That does not
invalidate what you say, but it is not really an argument in favour of
an even worse alternative: No topology and degraded geometry (as is the
case with STL).

It is not contested that it is possible to create meaningful STL files
for many cases. Obviously it is, I have done so. As I have stressed, the
message is that STL fails for the class of problems being discussed,
i.e. import further booleans.  If STL is the "end of the line" with the
intent of slicing and printing it works in most (but not necessarily
all) cases.

I am not 100% sure exactly what you are saying here, it seems to me you
are pointing to the fact that there are several situations where
exporting to STL and importing with the intent of doing boolean
operations will cause unsolvable problems. If that is what you are
saying, I agree. If I have misunderstood, please accept my apology.

This is an interesting observation in support of what I said above and
earlier. Even for the primary purpose of 3d printing, STL does not work
very well in some cases.

"All software" is a wide definition. 3d modeling has many applications,
not just 3d printing. I think what you are describing is either the
result of a boolean operation gone wrong or a failure to represent the
presumably correct result on an external file (STL) so that other
software have a chance to interpret it correctly. It is hard to say what
it is when the topology is non-existent.

My point is that we should try to be as as explicit as possible about
the nature of the models created. The most common way to do that for 3d
meshes is to separate geometry (vertex coordinates) from topology and
describe the topological connections. This is how it is done in FEM
analysis for example. It is similar in the CAD world (B-rep).

I don't mean to suggest that including topology will solve every problem
known to man, and I have not said so. There are still many ways things
can fail. But topology is a well established way of describing models
accurately, and it will solve a vast amount of problems seen in real life.

If you mean that both topology and geometry needs to be carefully
considered, that was also my message.

Thank you for the interesting comments.

Carsten Arnholm

nophead wrote

That is not exactly true. CGAL processed without any error message the union
(and even difference) of Q() with a small cube centered at the origin. It
outcries only if the cube side is between 20 and 220.

Manifold is simple because you can deal with it using simpler algorithms.
But there is non-manifolds with singularities simple enough to be easily
processed or even 3d printed.

I didn't get it.

--
View this message in context: http://forum.openscad.org/dxf-and-stl-import-rendering-issue-tp15979p16029.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

I don't understand how this is a strawman argument.

The central point is of contention seems to be whether a simple list of
triangles can convey topology implicitly or whether extra topological
information is required.

My argument is that as long as the mesh is 2 manifold and as long as
distinct vertices are numerically distinct and identical vertices are
numerically identical in the file then all the edge information is not
needed. You can reconstruct the edge information by building a table of
unique vertices and connecting them with the triangle edges they belong to.
You should then find any pair of vertices should either not be connected or
connected by two triangle edges into opposite directions. You then know
exactly how the triangles are connected, so you know the complete surface
topology.

Your argument is that topology is lost by exporting to STL and when
reimported you cannot do CSG operations. You supported it by two examples
but neither actually show this. The crack example has a diagram that
suggests the STL file will ignore the crack. The diagram states  "vertices
5 & 7" have identical coordinates. So I replied it was non manifold. Then
you said "The example is manifold and the vertices 5 and 7 are distinct
because I told you they are, and it is plain to see." Well its plain to see
the vertices are distinct and therefore can't have identical coordinates.
If they actually have identical coordinates the object is not 2 manifold
and you won't be able to do CSG on it anyway, regardless of whether it is
written to STL or not. It isn't something that can physically exist and I
can't find a way of making it in OpenScad. I might be able to make a crack
so thin it gets lost when converted to float but I have always said that
STL only works when the vertices are numerically distinct in the STL file.

Your second example simply shows loss of numerical accuracy converting
OpenScad's internal representation to strings and back. It also shows
OpenScad can't difference two objects that are nearly identical but not
quite. It doesn't show writing to STL  loses some topological information.
You can in fact do CSG on the imported version.  You just can't difference
it with the non-imported version.

STL files only go wrong in the real world because many programs write
non-manifold objects into them or the readers and writers are not careful
with truncation and rounding. You will still get problems with other file
formats that do store the topology explicitly if the topology is not
manifold if you try to do CSG with it in OpenScad. As, has been
demonstrated Ronaldo, it doesn't like self intersecting shapes.

On 3 February 2016 at 17:44, Carsten Arnholm arnholm@arnholm.org wrote:

On 3 February 2016 at 18:19, Ronaldo rcmpersiano@gmail.com wrote:

Yes that is unusual. I expect it sees the cube is totally internal and
simply discards it as a shortcut.

Yes but they are best avoided as they are unpredictable when passed on to
other programs. They can easily cause an extra edge to be counted by a
slicer and cause inside and outside to be flipped.

The number of volumes is always plus one as it counts the universe outside
of the objects as a volume. So for a single solid with no internal voids it
should be 2.

On 4 February 2016 at 02:50, nop head nop.head@gmail.com wrote:

Amen.

Mathematically, "2-manifold" means that the volumetric topology can be
accurately reconstructed from the mesh, and non-manifold means that the
topology is somehow ambiguous.

The whole idea of 2-manifold is that the triangles in the mesh depict a
contiguous topological boundary between the volumes "inside" and "outside"
in 3-space. That's why CGAL reports 2 volumes for single objects.

If there are coincident triangles, holes in the mesh, self-intersections,
singularities (ie shared vertex), etc etc, then the topological boundary is
ambiguous and the mesh is not 2-manifold.

Precision truncation is a slightly separate issue whereby a valid (but
degenerate) 2-manifold mesh can become a non-manifold mesh when saved -
this is an implementation problem, not a purely mathematical one.

To reiterate, topology can always be accurately reconstructed from a
2-manifold mesh. If the mesh is not 2-manifold, then the topology cannot be
accurately recovered and various implementations must guess and will
invariably get different results or spit errors.

If an implementation fails to reconstruct topology for a valid 2-manifold
mesh, or writes a non-manifold mesh for a non-degenerate 2-manifold mesh,
it has a bug.

If an implementation writes a non-manifold mesh given a degenerate
2-manifold mesh, then the designer should go back and make the model
non-degenerate :P This is frequently what causes openscad to not be able to
import its own exports...