Model Not rendering, CGal error
Hi:
Seems my stl model has some error, because OpenSCAD won't render it. Preview
is fine. But when I try to render or export it gives me this CGAL error. See
attached stl. back_cover_no_stand-2.stl
http://forum.openscad.org/file/n22122/back_cover_no_stand-2.stl
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: e->incident_sface() != SFace_const_handle() File:
/opt/mxe/usr/i686-w64-mingw32.static/include/CGAL/Nef_S2/SM_const_decorator.h
Line: 326
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: e->incident_sface() != SFace_const_handle() File:
/opt/mxe/usr/i686-w64-mingw32.static/include/CGAL/Nef_S2/SM_const_decorator.h
Line: 326
Geometries in cache: 52
Geometry cache size in bytes: 636256
CGAL Polyhedrons in cache: 32
CGAL cache size in bytes: 831776
Total rendering time: 0 hours, 0 minutes, 1 seconds
Rendering finished.
Also, is there a good tool for fixing stl files? I have tried several of the
major ones like netfabb but they don't always actually fix the file even
though they say it is fixed. And after being fixed the stl opens in my 3D
printing software without a "not manifold" error. But when I want to use
OpenSCAD to say puzzle a large piece into smaller parts it often still won't
render or export.
Thanks.
--
View this message in context: http://forum.openscad.org/Model-Not-rendering-CGal-error-tp22122.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Well, I tried a few random models that are manifold for thingivese and it
seem any model that was not originally created inside of OpenSCAD will not
render. I'm confused as to why that would be the case??
--
View this message in context: http://forum.openscad.org/Model-Not-rendering-CGal-error-tp22122p22132.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
I think OpenSCAD doesn't accept an STLs with very close vertices. I think
it snaps them to a grid making close vertices coincident.
On 28 August 2017 at 09:04, FourthDr who_doctor@hotmail.com wrote:
Well, I tried a few random models that are manifold for thingivese and it
seem any model that was not originally created inside of OpenSCAD will not
render. I'm confused as to why that would be the case??
--
View this message in context: http://forum.openscad.org/
Model-Not-rendering-CGal-error-tp22122p22132.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
This has been my experience exactly, where as I'd rather edit STL's with
openSCAD I increasingly find myself
using blender, which ain't great for mm perfect aligning of hole / objects!
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
On 28/08/17 09:04, FourthDr wrote:
Well, I tried a few random models that are manifold for thingivese and it
seem any model that was not originally created inside of OpenSCAD will not
render. I'm confused as to why that would be the case??
--
View this message in context: http://forum.openscad.org/Model-Not-rendering-CGal-error-tp22122p22132.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.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
I think it only goes wrong because OpenSCAD snaps to a grid. If it just
read the floating point numbers without adjusting them it would work. You
can't snap geometry blindly to a grid without breaking the topology.
On 28 August 2017 at 21:48, Carsten Arnholm arnholm@arnholm.org 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
Good question, and a very good answer.
I appreciate much hard work has been done on OpenSCAD already, and if
the import "AMF, OBJ, OFF and more" was trivial it would be done by now.
Do you think this is likely to be added in the near future?
Thanks, Rob
On 29/08/17 06: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
--
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 01:28, Rob Ward wrote:
Good question, and a very good answer.
I appreciate much hard work has been done on OpenSCAD already, and if
the import "AMF, OBJ, OFF and more" was trivial it would be done by
now.
Do you think this is likely to be added in the near future?
Thanks, Rob
On the last question, I am not an OpenSCAD developer so I cannot answer
for what will be added or when.
The assumption about what is trivial to import is in fact 180 degrees
wrong (no disrespect). It is STL import that is non-trivial for the
reasons given, and the opening posts in this thread are examples of
users experiencing the problems that can occur with it. Importing from a
format with given topology is trivial in comparison because no
coordinate assumptions are required.
I have developed a similar application that does AMF import (as
described at
https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format ). I
have also done work on converting of STL files, so I know it from both
angles. It is STL that is non-trivial, for the reasons given.
Carsten Arnholm
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
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