Imported stl's and strange behaviors
Using OpenSCAD version 2019.05 I am seeing a lot of problems with the import operator. It is EXCEEDINGLY finicky about what files it can accept.
Files attached: openscad import test.scad, chest extd.stl
The import looks fine as long as it stands alone, but the moment it intersects any OpenSCAD primitive, graphical weirdness sets in and some faces fail to be drawn under F5, especially when viewed from the side. F6 gets the following error message:
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e->incident_sface() != SFace_const_handle() File: /mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_S2/SM_const_decorator.h Line: 329
Now here's the weird part: chest extd.stl is not the file I downloaded from the Internet. It is the output of passing that file through the NetFabb "extended repair" process. Furthermore, before I begin repair, NetFabb tells me, "Mesh is closed, mesh is oriented."And I thought that NetFabb was one of the recommended tools! Please someone tell me, what is wrong with this STL file and how might it be repaired? Because I am having this problem with many STL files from many sources.
It does not fix self-intersections.
' EXCEEDINGLY finicky ' just wants good STLs.
From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of Ken Brooks
Sent: Sat, 21 Nov 2020 00:17
To: discuss@lists.openscad.org
Subject: [OpenSCAD] Imported stl's and strange behaviors
Using OpenSCAD version 2019.05 I am seeing a lot of problems with the import operator. It is
EXCEEDINGLY finicky about what files it can accept.
Files attached: openscad import test.scad, chest extd.stl
The import looks fine as long as it stands alone, but the moment it intersects any OpenSCAD
primitive, graphical weirdness sets in and some faces fail to be drawn under F5, especially when
viewed from the side. F6 gets the following error message:
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr:
e->incident_sface() != SFace_const_handle() File:
/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_S2/SM_const_decorator.h Line: 329
Now here's the weird part: chest extd.stl is not the file I downloaded from the Internet. It is the
output of passing that file through the NetFabb "extended repair" process. Furthermore, before I
begin repair, NetFabb tells me, "Mesh is closed, mesh is oriented."And I thought that NetFabb was
one of the recommended tools! Please someone tell me, what is wrong with this STL file and how
might it be repaired? Because I am having this problem with many STL files from many sources.
--
This email has been checked for viruses by AVG.
https://www.avg.com
I recently had a lot of problems using a large and complex STL file in
OpenSCAD. I used 4 or 5 different tools to validate and repair the STL,
and no two of the could agree on the degree of problems, and when one
finished repairing, another would find fault. I was getting nowhere,
and my OpenSCAD scripts were failing.
I ended up using AngelCAD:
https://forum.abmesh.com/index.php?topic=70.0
and was able to do what I wanted using my OpenSCAD script without
needing to change it.
AngelCAD has some limitations, as described here
https://forum.abmesh.com/index.php?topic=70.msg135;topicseen#msg135
but you might want to give it a try.
https://github.com/arnholm/angelcad/releases/tag/V1.5-02
Jon
On 11/20/2020 8:16 AM, Ken Brooks wrote:
Using OpenSCAD version 2019.05 I am seeing a lot of problems with the
import operator. It is EXCEEDINGLY finicky about what files it can accept.
Files attached: openscad import test.scad, chest extd.stl
The import looks fine as long as it stands alone, but the moment it
intersects any OpenSCAD primitive, graphical weirdness sets in and
some faces fail to be drawn under F5, especially when viewed from the
side. F6 gets the following error message:
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: e->incident_sface() != SFace_const_handle() File:
/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_S2/SM_const_decorator.h
Line: 329
Now here's the weird part: chest extd.stl is not the file I downloaded
from the Internet. It is the output of passing that file through the
NetFabb "extended repair" process. Furthermore, before I begin repair,
NetFabb tells me, "Mesh is closed, mesh is oriented."And I thought
that NetFabb was one of the recommended tools! Please someone tell me,
what is wrong with this STL file and how might it be repaired? Because
I am having this problem with many STL files from many sources.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 20.11.2020 14:16, Ken Brooks wrote:
Using OpenSCAD version 2019.05 I am seeing a lot of problems with the
import operator. It is EXCEEDINGLY finicky about what files it can accept.
Files attached: openscad import test.scad, chest extd.stl
The import looks fine as long as it stands alone, but the moment it
intersects any OpenSCAD primitive, graphical weirdness sets in and some
faces fail to be drawn under F5, especially when viewed from the side.
F6 gets the following error message:
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: e->incident_sface() != SFace_const_handle() File:
/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_S2/SM_const_decorator.h
Line: 329
Now here's the weird part: chest extd.stl is not the file I downloaded
from the Internet. It is the output of passing that file through the
NetFabb "extended repair" process. Furthermore, before I begin repair,
NetFabb tells me, "Mesh is closed, mesh is oriented."And I thought that
NetFabb was one of the recommended tools! Please someone tell me, what
is wrong with this STL file and how might it be repaired? Because I am
having this problem with many STL files from many sources.
No mesh repair tool is perfect, because STL is open to interpretation
wrt. coordinate tolerances. If at all possible, use another format such
as OFF or OBJ for example.
If you run your 'repaired' STL file through AngelCADs polyfix (another
repar tool), you get this report:
$ polyfix "chest extd.stl"
Parameters:
input_file = chest extd.stl
polyhedron 0 ================= volume=593408, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=389316 faces=129772
warning: nonmanifold edges: uc(1)=389316
merged 324635 vertices
removed 348 collapsed or zero area faces
removed 15 duplicate faces
removed 9 nonmanifold faces
total changes=325007
warning: nonmanifold edges: uc(1)=6 uc(3)=6 uc(4)=16
iteration 1: vertices=64681 faces=129400
warning: nonmanifold edges: uc(1)=6 uc(3)=6 uc(4)=16
removed 4 unused vertices
merged 9 vertices
removed 14 collapsed or zero area faces
split 3 faces
removed 3 duplicate faces
removed 5 nonmanifold faces
removed 5 zero area faces
total changes=43
warning: nonmanifold edges: uc(1)=3 uc(3)=7 uc(4)=16
iteration 2: vertices=64668 faces=129384
warning: nonmanifold edges: uc(1)=3 uc(3)=7 uc(4)=16
removed 2 unused vertices
total changes=2
warning: nonmanifold edges: uc(1)=3 uc(3)=7 uc(4)=16
iteration 3: vertices=64666 faces=129384
warning: nonmanifold edges: uc(1)=3 uc(3)=7 uc(4)=16
total changes=0
warning: nonmanifold edges: uc(1)=3 uc(3)=7 uc(4)=16
Summary:
polyhedron 0: vertices=64666 faces=129384 : warning:
nonmanifold edges: uc(1)=3 uc(3)=7 uc(4)=16
What it tells you is that it has gone through 4 iterations of automatic
repair attempts. Since this is an STL file, all triangles are from the
start completely independent of each other, it is a "triangle soup".
In iteration 0 therefore, the triangle vertex coordinates are matched,
so you get 324635 merged vertices, and in this process (which involves
tolerances), 384 triangles are evaluated as having zero area after
vertex merging, and thus discarded. Also there are 15 duplicate faces,
which may or may not be resulting from the vertex merging. Finally there
are some "non-manifold faces", i.e. faces that have edges with use count
different from 2.
In iteration 1, the process is repeated, but now much fewer vertices are
merged, but still this gives many ripple effects.
In iteration 2 only 2 vertices are removed.
In iteration 3 no further changes are possible, but the resulting
polyhedron has some remaining unsolvable problems:
3 edges has use count 1
7 edges have use count 3
16 edges have use count 4
So the result is still not perfect. If you save this to STL, some other
mesh repair tool may claim it has different issues. If you save it to
OFF or OBJ, there should be much less room for doubt.
As for running your OpenSCAD, script, you must edit it to refer to the
file you provided. If we assume you put the STL in the same folder as
the .scad file, it should look like this:
difference(){
import("chest extd.stl");
#cube ([300, 300, 7800]);
}
Granted, if you run this in OpenSCAD (version 2020.11.20.nightly (git
8a90513) ) you get the message you reported. I also tried using the
result of running polyfix, but this was still unsuccessful in OpenSCAD.
If you run the exact same file using AngelCAD V1.5-02 instead, it works.
You must have a bit of patience because polyfix will be automatically
executed, converting the STL to OFF before inserting the resulting
polyhedron to the process. But the net result is complete in less than
10 seconds on my Ubuntu and Windows machines.
If you remove the # and run as follows
difference(){
import("chest extd.stl");
cube ([300, 300, 7800]);
}
... the cube will subtract a tiny part of one of the back corners. But
it works.
Carsten Arnholm
Joymaker wrote
And I thought that NetFabb was one of the recommended tools! Please
someone tell me, what is wrong with this STL file and how might it be
repaired?
In NeFabb repair you have to manually do Repair/Detect-self-intersections.
They are common problems and not automatically fixable, unless you pay
megabucks for the pro version.
OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
- on the Forum, click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/