Model Not rendering, CGal error
I am not an expert here.... apologies where required... So what you are
saying nop head, is the vertices of some STLs are close enough for a
slicer to make a satisfactory model, but not reliable enough to be
always be deconstructed to an unambiguous OpenSCAD topology (reverse
engineered)? In other words, the fact that OpenSCAD allows practical
construction of STLs, does not mean OpenSCAD can perfectly interpret
every STL (even though it may be printable in practice), even some
OpenSCAD exported STL's?
Rob
On 29/08/17 22:01, nop head wrote:
I don't think the problem has anything to do with STL or floating
point. I think it is this:
https://github.com/openscad/openscad/blob/0904a3b3a5b56b16bb423b177972468eeca775a9/src/grid.h
You can't snap vertices to a grid without risking breaking the
topology when they are close compared to the grid size. If I import
STLs from CAD systems that produce high resolution curves it breaks.
Nothing wrong with the STL file, just vertices closer that the grid.
On 29 August 2017 at 12:45, Ronaldo Persiano <rcmpersiano@gmail.com
mailto:rcmpersiano@gmail.com> wrote:
There are some aspects of this discussion that are not clear to
me. It is clear that STL file format has no topology information
however I don't see this as the main cause of troubles. In the
Openscad polyhedron primitive, for instance, we have some topology
information in the face list that is specified by vertex
references and not vertex coordinates like in STL files. If I
define a polyhedron with 5 faces of a cube (and 8 vertices) it
could easily be discarded as a manifold, by just reading the face
list, once there are some topological edges with only one adjacent
face. Suppose now that I add the 6th cube face but refer its
topological vertices as 4 new distinguished geometrical vertices
as in the following:
verts = [ [0,0,0], [1,0,0], [1,1,0], [0,1,0],
[0,0,1], [1,0,1], [1,1,1], [0,1,1],
[1,1,0], [1,0,0], [1,0,1], [1,1,1] ];
faces = [ [0,1,2,3], [5,4,7,6],
[1,0,4,5], [3,2,6,7],
[0,3,7,4],
[8,9,10,11] ]; // instead of [2,1,5,6] ];
polyhedron(points=verts, faces=faces);
If we just look at the topological information of this polyhedron
(its face list) we would say it is not a manifold because the
topological edge [1,2], for instance, has just the first face
incident to it. But if we take in account the vertex coordinate
list it is clear that vertex 2 and 8 are geometrically identical (
and so are 1 and 9, 5 and 10, 6 and 11).
We have two main ways to consider the check of manifoldness for
this case: either rely only on the topological information or
also consider the geometrical information. In the former case, the
above polyhedron would be considered as two separate (but not
disjoint) manifold with boundary. In the later, it will be
considered a manifold without boundary (a closed manifold).
Which way to choose is a design decision but any of them has its
merits and demerits. In the former option, we will be in trouble
if two topological vertices have the same geometry. In the later,
we must compare vertex geometries to complete the topological
model. In any case, self intersections in the object boundary
geometry has to be considered and threshold are needed in the
vertex coordinate comparisons.
In the current version of Openscad, the later option seems to be
the choice as the following code may suggest.
d = epsilon*[1,1,1];
verts = [ [0,0,0], [1,0,0], [1,1,0], [0,1,0],
[0,0,1], [1,0,1], [1,1,1], [0,1,1],
[1,1,0]+d, [1,0,0]+d, [1,0,1]+d, [1,1,1]+d ];
faces = [ [0,1,2,3], [5,4,7,6],
[1,0,4,5], [3,2,6,7],
[0,3,7,4],
[8,9,10,11] ]; // instead of [2,1,5,6] ];
difference(){
polyhedron(points=verts, faces=faces);
translate([0.5,-0.5,-0.5]) cube(1);
}
If we set epsilon to some absolute value bellow 1e-08, CGAL will
not complaint. With epsilon=1e-4, it does.
It seems to me that we cannot get rid of the geometrical
information and all its burden to check manifold validity. Even
when the topological information is part of the file like in AMF,
the comparison of vertex geometries are unavoidable. Concluding, I
don't think the missing topological information in STL files is
the cause of troubles. The devil is in the floating point
representation of the geometry.
2017-08-28 21:48 GMT+01:00 Carsten Arnholm <arnholm@arnholm.org
<mailto:arnholm@arnholm.org>>:
On 28. aug. 2017 12:18, Mr C Camacho wrote:
Its a real shame something can't be done about the STL
importer munging vetices together, and indeed
I assume this is a bug because I can't see it being a feature!
This is one area where openSCAD has a particular weakness
which is in sharp contrast to the rest of the
package!
Chris
OpenSCAD and other CAD programs use internal data structures
with explicit topology, i.e. it has explicit representation of
which faces connect to which vertices etc.
The STL format is one of the few file formats that does not
contain such topology information. An STL file is just a
"soup" of disconnected triangles.
To import from STL to OpenSCAD, the program has to make a
guess at what the topology should really be, i.e. how to
"munge vertices together". There is in fact no other way as
long as you deal with STL. The guess is really assuming
coordinate tolerances.
If the STL file has (unstated) coordinate units sufficiently
different from the assumptions in OpenSCAD, you will indeed
get "odd" results, i.e. results that do not match your
expectations. But no software can read your mind so it is
unable to adjust for such expectations.
To handle the problem better there are some possibilities:
One is to make sure the assumptions of the STL files to be
imported at least roughly match the assumptions in OpenSCAD.
Easier said than done, but without modifying the software this
is what is required. I.e. use millimeter coordinates and don't
make the models unreasonably small.
Another possibility would be to be able to state in the
import() command what the coordinate tolerance in the STL file
is supposed to be (such a feature does not exist now). Still,
it can be difficult to choose a good tolerance value so it
would not solve all cases, plus other side effects tend to
show up here.
A third option would be to also allow import of file formats
with explicit topology, and thus avoid making any coordinate
tolerance assumptions during import. Such formats include AMF,
OBJ, OFF and more. Then there would be absolutely no "munging"
going on and it would work the same in all programs.
In short, STL was not relly designed for exchanging models
between CAD applications. It is mostly ok as input to a slicer
program, but as a CAD-to-CAD exchange format it is poor, and
prone to surprises when used that way.
Carsten Arnholm
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
<http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org>
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
<http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org>
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
Rob Ward
Lake Tyers Beach, 3909
Lake Tyers Beach Website http://www.laketyersbeach.net.au
Ubuntu Mate - A great OS https://ubuntu-mate.org/
On 2017-08-29 13:45, Ronaldo Persiano wrote:
It seems to me that we cannot get rid of the geometrical information
and all its burden to check manifold validity. Even when the
topological information is part of the file like in AMF, the
comparison of vertex geometries are unavoidable. Concluding, I don't
think the missing topological information in STL files is the cause of
troubles. The devil is in the floating point representation of the
geometry.
You are talking about something else.
My point was exchanging 3d surface meshes between different CAD
applications in a non-ambiguous way, without having to make assumptions.
Whether the mesh has such things as non-manifoldness or duplicate
vertices (different vertices with identical coordinates) is a very
different question to the question of reliably exchanging models.
OpenSCAD may disagree or disallow such cases if it wishes to do so,
but at least it is possible to know what has been described. That is in
general not the case with STL.
Anyway, as long as these things are not recognized, the same issues will
occur again and again. I recommend giving it a thought though.
Carsten Arnholm
I must be misunderstanding something because especially the OBJ format
when I have written an importer
for games all you get is a "soup" of triangles...
On 28/08/17 21:48, Carsten Arnholm wrote:
On 28. aug. 2017 12:18, Mr C Camacho wrote:
Its a real shame something can't be done about the STL importer
munging vetices together, and indeed
I assume this is a bug because I can't see it being a feature!
This is one area where openSCAD has a particular weakness which is in
sharp contrast to the rest of the
package!
Chris
OpenSCAD and other CAD programs use internal data structures with
explicit topology, i.e. it has explicit representation of which faces
connect to which vertices etc.
The STL format is one of the few file formats that does not contain
such topology information. An STL file is just a "soup" of
disconnected triangles.
To import from STL to OpenSCAD, the program has to make a guess at
what the topology should really be, i.e. how to "munge vertices
together". There is in fact no other way as long as you deal with STL.
The guess is really assuming coordinate tolerances.
If the STL file has (unstated) coordinate units sufficiently different
from the assumptions in OpenSCAD, you will indeed get "odd" results,
i.e. results that do not match your expectations. But no software can
read your mind so it is unable to adjust for such expectations.
To handle the problem better there are some possibilities:
One is to make sure the assumptions of the STL files to be imported at
least roughly match the assumptions in OpenSCAD. Easier said than
done, but without modifying the software this is what is required.
I.e. use millimeter coordinates and don't make the models unreasonably
small.
Another possibility would be to be able to state in the import()
command what the coordinate tolerance in the STL file is supposed to
be (such a feature does not exist now). Still, it can be difficult to
choose a good tolerance value so it would not solve all cases, plus
other side effects tend to show up here.
A third option would be to also allow import of file formats with
explicit topology, and thus avoid making any coordinate tolerance
assumptions during import. Such formats include AMF, OBJ, OFF and
more. Then there would be absolutely no "munging" going on and it
would work the same in all programs.
In short, STL was not relly designed for exchanging models between CAD
applications. It is mostly ok as input to a slicer program, but as a
CAD-to-CAD exchange format it is poor, and prone to surprises when
used that way.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 2017-08-29 15:41, Mr C Camacho wrote:
I must be misunderstanding something because especially the OBJ format
when I have written an importer
for games all you get is a "soup" of triangles...
https://en.wikipedia.org/wiki/Wavefront_.obj_file#Vertex_Indices
Vertices
v 0.123 0.234 0.345 1.0
v ...
Faces
f 214 27 29
f ...
Example e.g. whistle.obj
https://www.thingiverse.com/thing:1046/#files
Vertices are independent from faces. Faces refer to vertices, that is
the topology. It is not a soup of disconnected triangles when multiple
faces refer to the same vertex.
For graphics in games the topology is unimportant. For CAD it is
important.
Carsten Arnholm
On 29 August 2017 at 13:43, Rob Ward rl.ward@bigpond.com wrote:
I am not an expert here.... apologies where required... So what you are
saying nop head, is the vertices of some STLs are close enough for a slicer
to make a satisfactory model, but not reliable enough to be always be
deconstructed to an unambiguous OpenSCAD topology (reverse engineered)?
Yes it is possible to have manifold STL files that a slicer would not have
a problem with but OpenSCAD will.
If STLs contain manifold geometry, that is still manifold when represented
as floats, then there is no problem recovering it unambiguously from the
soup of triangles. I.e. as long as facet vertices with the same numerical
value are coincident in the geometry no information is lost. If the
geometry was non-manifold to start with, for example if it has self
intersections like two cubes sharing an edge then STL is not a good way to
represent it.
In other words, the fact that OpenSCAD allows practical construction of
STLs, does not mean OpenSCAD can perfectly interpret every STL (even
though it may be printable in practice), even some OpenSCAD exported STL's?
My understanding is OpenSCAD cannot read perfectly constructed STL files if
they have vertices closer than its internal grid. That is a bug.
OpenSCAD also does not always produce correct STL files because when it
converts from greater precision to floating point some vertices can get
truncated to the same value and merged. That is another bug but is
fundamentally the same problem. You can't reduce the precision of the
vertices of a mesh without ensuring that distinct vertices don't end up
with identical truncated values.
Rob
On 29/08/17 22:01, nop head wrote:
I don't think the problem has anything to do with STL or floating point. I
think it is this: https://github.com/openscad/openscad/blob/
0904a3b3a5b56b16bb423b177972468eeca775a9/src/grid.h
You can't snap vertices to a grid without risking breaking the topology
when they are close compared to the grid size. If I import STLs from CAD
systems that produce high resolution curves it breaks. Nothing wrong with
the STL file, just vertices closer that the grid.
On 29 August 2017 at 12:45, Ronaldo Persiano rcmpersiano@gmail.com
wrote:
There are some aspects of this discussion that are not clear to me. It is
clear that STL file format has no topology information however I don't see
this as the main cause of troubles. In the Openscad polyhedron primitive,
for instance, we have some topology information in the face list that is
specified by vertex references and not vertex coordinates like in STL
files. If I define a polyhedron with 5 faces of a cube (and 8 vertices) it
could easily be discarded as a manifold, by just reading the face list,
once there are some topological edges with only one adjacent face. Suppose
now that I add the 6th cube face but refer its topological vertices as 4
new distinguished geometrical vertices as in the following:
verts = [ [0,0,0], [1,0,0], [1,1,0], [0,1,0],
[0,0,1], [1,0,1], [1,1,1], [0,1,1],
[1,1,0], [1,0,0], [1,0,1], [1,1,1] ];
faces = [ [0,1,2,3], [5,4,7,6],
[1,0,4,5], [3,2,6,7],
[0,3,7,4],
[8,9,10,11] ]; // instead of [2,1,5,6] ];
polyhedron(points=verts, faces=faces);
If we just look at the topological information of this polyhedron (its
face list) we would say it is not a manifold because the topological edge
[1,2], for instance, has just the first face incident to it. But if we take
in account the vertex coordinate list it is clear that vertex 2 and 8 are
geometrically identical ( and so are 1 and 9, 5 and 10, 6 and 11).
We have two main ways to consider the check of manifoldness for this
case: either rely only on the topological information or also consider the
geometrical information. In the former case, the above polyhedron would be
considered as two separate (but not disjoint) manifold with boundary. In
the later, it will be considered a manifold without boundary (a closed
manifold).
Which way to choose is a design decision but any of them has its merits
and demerits. In the former option, we will be in trouble if two
topological vertices have the same geometry. In the later, we must compare
vertex geometries to complete the topological model. In any case, self
intersections in the object boundary geometry has to be considered and
threshold are needed in the vertex coordinate comparisons.
In the current version of Openscad, the later option seems to be the
choice as the following code may suggest.
d = epsilon*[1,1,1];
verts = [ [0,0,0], [1,0,0], [1,1,0], [0,1,0],
[0,0,1], [1,0,1], [1,1,1], [0,1,1],
[1,1,0]+d, [1,0,0]+d, [1,0,1]+d, [1,1,1]+d ];
faces = [ [0,1,2,3], [5,4,7,6],
[1,0,4,5], [3,2,6,7],
[0,3,7,4],
[8,9,10,11] ]; // instead of [2,1,5,6] ];
difference(){
polyhedron(points=verts, faces=faces);
translate([0.5,-0.5,-0.5]) cube(1);
}
If we set epsilon to some absolute value bellow 1e-08, CGAL will not
complaint. With epsilon=1e-4, it does.
It seems to me that we cannot get rid of the geometrical information and
all its burden to check manifold validity. Even when the topological
information is part of the file like in AMF, the comparison of vertex
geometries are unavoidable. Concluding, I don't think the missing
topological information in STL files is the cause of troubles. The devil is
in the floating point representation of the geometry.
2017-08-28 21:48 GMT+01:00 Carsten Arnholm arnholm@arnholm.org:
On 28. aug. 2017 12:18, Mr C Camacho wrote:
Its a real shame something can't be done about the STL importer munging
vetices together, and indeed
I assume this is a bug because I can't see it being a feature!
This is one area where openSCAD has a particular weakness which is in
sharp contrast to the rest of the
package!
Chris
OpenSCAD and other CAD programs use internal data structures with
explicit topology, i.e. it has explicit representation of which faces
connect to which vertices etc.
The STL format is one of the few file formats that does not contain such
topology information. An STL file is just a "soup" of disconnected
triangles.
To import from STL to OpenSCAD, the program has to make a guess at what
the topology should really be, i.e. how to "munge vertices together". There
is in fact no other way as long as you deal with STL. The guess is really
assuming coordinate tolerances.
If the STL file has (unstated) coordinate units sufficiently different
from the assumptions in OpenSCAD, you will indeed get "odd" results, i.e.
results that do not match your expectations. But no software can read your
mind so it is unable to adjust for such expectations.
To handle the problem better there are some possibilities:
One is to make sure the assumptions of the STL files to be imported at
least roughly match the assumptions in OpenSCAD. Easier said than done, but
without modifying the software this is what is required. I.e. use
millimeter coordinates and don't make the models unreasonably small.
Another possibility would be to be able to state in the import() command
what the coordinate tolerance in the STL file is supposed to be (such a
feature does not exist now). Still, it can be difficult to choose a good
tolerance value so it would not solve all cases, plus other side effects
tend to show up here.
A third option would be to also allow import of file formats with
explicit topology, and thus avoid making any coordinate tolerance
assumptions during import. Such formats include AMF, OBJ, OFF and more.
Then there would be absolutely no "munging" going on and it would work the
same in all programs.
In short, STL was not relly designed for exchanging models between CAD
applications. It is mostly ok as input to a slicer program, but as a
CAD-to-CAD exchange format it is poor, and prone to surprises when used
that way.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing listDiscuss@lists.openscad.orghttp://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
Rob Ward
Lake Tyers Beach, 3909
Lake Tyers Beach Website http://www.laketyersbeach.net.au
Ubuntu Mate - A great OS https://ubuntu-mate.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
yes but quite often you end up with each face (of an OBJ) getting its
own vertices, even if really they should
be sharing vertices, so I'm not sure if an OBJ like this would be much
better than a STL ?
On 29/08/17 15:34, arnholm@arnholm.org wrote:
On 2017-08-29 15:41, Mr C Camacho wrote:
I must be misunderstanding something because especially the OBJ format
when I have written an importer
for games all you get is a "soup" of triangles...
https://en.wikipedia.org/wiki/Wavefront_.obj_file#Vertex_Indices
Vertices
v 0.123 0.234 0.345 1.0
v ...
Faces
f 214 27 29
f ...
Example e.g. whistle.obj
https://www.thingiverse.com/thing:1046/#files
Vertices are independent from faces. Faces refer to vertices, that is
the topology. It is not a soup of disconnected triangles when multiple
faces refer to the same vertex.
For graphics in games the topology is unimportant. For CAD it is
important.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 29. aug. 2017 19:57, Mr C Camacho wrote:
yes but quite often you end up with each face (of an OBJ) getting its
own vertices, even if really they should
be sharing vertices,
No, not in CAD programs. Not in OpenSCAD or other programs doing
booleans on surface meshes. As mentioned before: "OpenSCAD and other CAD
programs use internal data structures with explicit topology, i.e. it
has explicit representation of which faces connect to which vertices etc. "
http://forum.openscad.org/Model-Not-rendering-CGal-error-tp22122p22135.html
A well defined topology is required to do booleans. To be more
specific, OpenSCAD requires a 2-manifold topology. You either have it or
you must guess it. Guessing often does not work, as demonstrated by the
topic of this thread.
so I'm not sure if an OBJ like this would be much
better than a STL ?
See above, it has been explained already.
Carsten Arnholm
well I've had plenty of experience of seeing badly formed OBJ files, and
there is nothing intrinsic in
file format to prevent this.
On 29/08/17 23:02, Carsten Arnholm wrote:
On 29. aug. 2017 19:57, Mr C Camacho wrote:
yes but quite often you end up with each face (of an OBJ) getting its
own vertices, even if really they should
be sharing vertices,
No, not in CAD programs. Not in OpenSCAD or other programs doing
booleans on surface meshes. As mentioned before: "OpenSCAD and other
CAD programs use internal data structures with explicit topology, i.e.
it has explicit representation of which faces connect to which
vertices etc. "
http://forum.openscad.org/Model-Not-rendering-CGal-error-tp22122p22135.html
A well defined topology is required to do booleans. To be more
specific, OpenSCAD requires a 2-manifold topology. You either have it
or you must guess it. Guessing often does not work, as demonstrated by
the topic of this thread.
so I'm not sure if an OBJ like this would be much
better than a STL ?
See above, it has been explained already.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 2017-08-30 09:22, Mr C Camacho wrote:
well I've had plenty of experience of seeing badly formed OBJ files,
and there is nothing intrinsic in
file format to prevent this.
You are missing the point. The issue is being able to communicate the
topology of a surface mesh in a non-ambiguous way. You can choose to
communicate a badly formed topology, but that is a completely different
issue.
Carsten Arnholm
WOW lots of replies. So it seems a complicated issue to resolve. In the mean
time is there some free software that can break up a large print into
smaller pieces that can be re-assembled once printed? And lock together
securely with a secure shape like ball sock/dovetail/etc? I don't always
need this because the print is too large. Sometime it's because the print
has some features that otherwise need major support or are just plain hard
to print correctly in one piece. Any suggestions? I know I searched for some
software like that and found some, but the software was either costly or was
experimental and not really available, like a research project etc..
--
Sent from: http://forum.openscad.org/