Assertion violation
I'm using OpenSCAD to create a big .STL file to send to a 3D print service.
Basically, the 3D print service gives me a volume to pack anyway I want and
then they print it.
So I'm using OpenSCAD to fill the allowed volume with 14 shapes. My approach
was to import a bunch of .STL files holding the 14 shapes (previously
generated in OpenSCAD); then use translate()'s and rotate()'s to move the
shapes to the correct location; and then export to a final, large, .STL
file.
But this error message comes up on the console:
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: pe_prev->is_border() ||
!internal::Plane_constructor::get_plane(pe_prev->facet(),pe_prev->facet()->plane()).is_degenerate()
File:
/data/OpenSCAD/libraries-mingw32-master/mxe/usr/i686-w64-mingw32.static/include/CGAL/Nef_3/polyhedron_3_to_nef_3.h
Line: 293
It renders 12 of the 14 shapes and stops.
Is this a known bug and is there a work-around?
As usual, thanks for the help!
--
View this message in context: http://forum.openscad.org/Assertion-violation-tp14417.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Is this a known bug and is there a work-around?
This is a known issue due to a limitation in a library we’re depending on:
https://github.com/openscad/openscad/issues/945
One workaround could be to process the file in Meshlab to flip so-called "T-vertices”.
-Marius
OK, good to know it's a known issue with the CGAL library but I think there
might be something more going on. For one thing, the .STL file that seems to
be making OpenSCAD unhappy - that is, the file that might have the zero-area
triangle(s) in it - was itself created by OpenSCAD. Would OpenSCAD write a
.STL file containing collinear vertices?
For another thing, I used MeshLab to remove the T-vertices (or tried to) and
the problem didn't go away. I don't know that much about MeshLab, so I may
have screwed this up: when I opened each of the .STL files in MeshLab, it
presented me with a dialog box called "Post-Open Processing" and allowed me
to check a "Unify Duplicated Vertices" box. I checked the box and hit OK;
then I used Export Mesh to write out a new .STL file (which doesn't seem to
have helped).
Was there some other steps I should have taken to make MeshLab remove the
T-vertices?
--
View this message in context: http://forum.openscad.org/Assertion-violation-tp14417p14425.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
CGAL creates a perfectly valid mesh, then some other code screws up the
mesh in the process of exporting to STL. That's why OpenSCAD can refuse to
read an STL that it created. It's a well known bug that is periodically
reported on the forum, and it's even being debated right now on another
thread. There is some controversy about what the underlying problem is.
On 12 November 2015 at 18:56, Mekko serve@perdix.org wrote:
OK, good to know it's a known issue with the CGAL library but I think there
might be something more going on. For one thing, the .STL file that seems
to
be making OpenSCAD unhappy - that is, the file that might have the
zero-area
triangle(s) in it - was itself created by OpenSCAD. Would OpenSCAD write a
.STL file containing collinear vertices?
For another thing, I used MeshLab to remove the T-vertices (or tried to)
and
the problem didn't go away. I don't know that much about MeshLab, so I may
have screwed this up: when I opened each of the .STL files in MeshLab, it
presented me with a dialog box called "Post-Open Processing" and allowed me
to check a "Unify Duplicated Vertices" box. I checked the box and hit OK;
then I used Export Mesh to write out a new .STL file (which doesn't seem to
have helped).
Was there some other steps I should have taken to make MeshLab remove the
T-vertices?
--
View this message in context:
http://forum.openscad.org/Assertion-violation-tp14417p14425.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 Nov 12, 2015, at 18:56 PM, Mekko serve@perdix.org wrote:
Would OpenSCAD write a .STL file containing collinear vertices?
Yes we might, due to conversion errors when converging CGAL polyhedrons to floating point.
Was there some other steps I should have taken to make MeshLab remove the
T-vertices?
Filters->Cleaning and Repairing->Remove T-vertices by Edge Flip.
-Marius
Thanks, Marius. I've spent most of today struggling with this issue and
MeshLab has been helpful with diagnosing what's going on. The .STL files I'm
generating from OpenSCAD definitely contain T-vertices or worse. MeshLab was
sometimes able to repair them but also crashed several times. Even when it
repaired the T-vertices, it changed the shape so badly it was unusable.
All in all, it's been very frustrating. For one of my designs, I was never
able to get OpenSCAD to generate an .STL file that would pass muster with
MeshLab and that OpenSCAD could import and render without an assertion
violation (I've seen at least two different ones so far). Perhaps I'm using
OpenSCAD for a purpose for which it's not really designed: to import objects
from a collection of .STL files, position them so they don't overlap, and
then write out an "aggregating" .STL file. It's so good at everything else I
do, I just assumed it would be good for this too.
If anyone knows a better tool for this kind of work, I'm all ears.
--
View this message in context: http://forum.openscad.org/Assertion-violation-tp14417p14432.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On Nov 13, 2015, at 00:54 AM, Mekko serve@perdix.org wrote:
Perhaps I'm using OpenSCAD for a purpose for which it's not really designed: to import objects
from a collection of .STL files, position them so they don't overlap, and
then write out an "aggregating" .STL file.
This is slightly outside of the intended scope of OpenSCAD.
The problem is that we blindly pass all imported meshes into the CSG engine (CGAL), which is very picky.
If we would just bypass this for known non-overlapping objects, or let the user decide, this wouldn’t be an issues.
This is related to work done on https://github.com/openscad/openscad/issues/350
-Marius
Mekko wrote
Perhaps I'm using
OpenSCAD for a purpose for which it's not really designed: to import
objects
from a collection of .STL files, position them so they don't overlap, and
then write out an "aggregating" .STL file. It's so good at everything else
I
do, I just assumed it would be good for this too.
I'm curious how you intend to achieve this, assuming even if importing went
perfectly smoothly.
OpenSCAD lacks a language structure and capability that takes an 2D/3D
object as input and return a number. Say:
--
View this message in context: http://forum.openscad.org/Assertion-violation-tp14417p14435.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Von: Mekko serve@perdix.org
sometimes able to repair them but also crashed several times. Even when it
repaired the T-vertices, it changed the shape so badly it was unusable.
The "Remove T-Vertices by Edge-Flip" can do more than is actually is needed
here. What we need to fix the zero-area triangles is to remove only those
which have essentially infinite ratio.
Giving a very high number, e.g. 1000000 for ratio should prevent the mesh
from being distorted.
See also that FAQ entry for reference:
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_is_my_imported_STL_file_only_showing_up_with_F5_but_not_F6.3F
ciao,
Torsten.
@ctchin, I don't think I explained my use case very well. I didn't mean to
suggest I was programming OpenSCAD to find an optimal packing or even a
possible packing. I do all the positioning by hand.
My point was that I don't know of any other tool that lets me reposition a
collection of objects, each in its own .STL file, and then write out a
single comprehensive .STL file. I had considered putting the OpenSCAD code
for all 14 objects into one gigantic source code file but I thought that
wouldn't work. I would have had to resolve all the identifier name conflicts
between the files. Also, I worried that the rendering would take hours or
require too much memory and crash.
I like your idea for making objects manipulable but that's more than I need
for now.
--
View this message in context: http://forum.openscad.org/Assertion-violation-tp14417p14442.html
Sent from the OpenSCAD mailing list archive at Nabble.com.