I've tried searching google for any hints but nothing productive. The full assertion is: 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: /opt/mxe/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_3/polyhedron_3_to_nef_3.h Line: 251 This is with version 2016.01.26 on win64. The entire file is this: difference() { import("robot_draft_front.stl"); translate([-20, 0.1, -30]) cube([40, 35, 60]); } where robot_draft_front.stl was generated by OpenSCAD. For the background, the goal is to take a model and use a minkowski sum to add a draft angle such that a mold can be made for casting the object. Beginning with the model, a minkowski sum is calculated with a fairly narrow cone minkowski() { import("robot_nomarks_3000.stl"); rotate([-90, 0, 0]) cylinder(r1=0, r2=3, h=20); } This takes a while to compute, but I let it do its thing and then I save as robot_draft_front.stl so that it doesn't have to recalculate the minkowski. The resulting stl can be loaded and rendered alone just fine, but when using difference() to remove the back side of the object, the object appears correct in preview but rendering generates an error. I am guessing that the outcome of the minkowski sum contains a subtle error that is propagating to the stl file, and that the second step of loading and intersecting is not the true problem. But that's just a guess. The original object "robot_nomarks_3000.stl" I've put here: https://www.dropbox.com/s/8tkphayu33z8sod/Robot_nomarks_3000.stl?dl=0 The resulting object "robot_draft_front.stl" I've put here: https://www.dropbox.com/s/k998y45ah4bfj56/robot_draft_front.stl?dl=0 I'd be interested to hear any suggestions or whether this is something that should be fixed. -Jamie -- View this message in context: http://forum.openscad.org/CGAL-ERROR-assertion-violation-tp17026.html Sent from the OpenSCAD mailing list archive at Nabble.com.

This looks like a known bug, or pair of bugs. 1. OpenSCAD sometimes exports bad STL files (the mesh is not 2-manifold). 2. The import() module doesn't tell you when it imports a bad STL file. In this circumstance, the mesh will be displayed correctly in the preview window (since this operation displays each triangle independently, and doesn't rely on correct connectivity between the triangles). You only get an error when you perform a CSG operation on the bad mesh. On 10 April 2016 at 12:53, Jamie_K <vector76@gmail.com> wrote: > I've tried searching google for any hints but nothing productive. The full > assertion is: > 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: > > /opt/mxe/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_3/polyhedron_3_to_nef_3.h > Line: 251 > > This is with version 2016.01.26 on win64. > > The entire file is this: > > difference() { > import("robot_draft_front.stl"); > > translate([-20, 0.1, -30]) > cube([40, 35, 60]); > } > > where robot_draft_front.stl was generated by OpenSCAD. > > For the background, the goal is to take a model and use a minkowski sum to > add a draft angle such that a mold can be made for casting the object. > Beginning with the model, a minkowski sum is calculated with a fairly > narrow > cone > > minkowski() { > import("robot_nomarks_3000.stl"); > > rotate([-90, 0, 0]) > cylinder(r1=0, r2=3, h=20); > } > > This takes a while to compute, but I let it do its thing and then I save as > robot_draft_front.stl so that it doesn't have to recalculate the minkowski. > The resulting stl can be loaded and rendered alone just fine, but when > using > difference() to remove the back side of the object, the object appears > correct in preview but rendering generates an error. > > I am guessing that the outcome of the minkowski sum contains a subtle error > that is propagating to the stl file, and that the second step of loading > and > intersecting is not the true problem. But that's just a guess. > > The original object "robot_nomarks_3000.stl" I've put here: > https://www.dropbox.com/s/8tkphayu33z8sod/Robot_nomarks_3000.stl?dl=0 > > The resulting object "robot_draft_front.stl" I've put here: > https://www.dropbox.com/s/k998y45ah4bfj56/robot_draft_front.stl?dl=0 > > I'd be interested to hear any suggestions or whether this is something that > should be fixed. > > -Jamie > > > > > -- > View this message in context: > http://forum.openscad.org/CGAL-ERROR-assertion-violation-tp17026.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 Apr 10, 2016, at 12:53 PM, Jamie_K <vector76@gmail.com> wrote: > > […] > import("robot_draft_front.stl"); > […] > where robot_draft_front.stl was generated by OpenSCAD. > This looks like the following common issue: https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_is_my_imported_STL_file_only_showing_up_with_F5_but_not_F6.3F -Marius

kintel wrote > This looks like the following common issue: > https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_is_my_imported_STL_file_only_showing_up_with_F5_but_not_F6.3F Yes, but OpenSCAD generated the bad .stl file. The original .stl is valid, the minkowski() causes both degenerate faces, and, in a version I did testing to see if it is the small size rounding error issue, at scale(100) - both the imported .stl and the cone - also made holes (7 volumes 8 holes, fewer degen faces). When I scaled each to 10,000 and then down 0.0001, the stl had no holes, but still degen faces. ----- Admin - PM me if you need anything, or if I've done something stupid... 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. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out! -- View this message in context: http://forum.openscad.org/CGAL-ERROR-assertion-violation-tp17026p17036.html Sent from the OpenSCAD mailing list archive at Nabble.com.

> On Apr 10, 2016, at 21:55 PM, MichaelAtOz <oz.at.michael@gmail.com> wrote: > > Yes, but OpenSCAD generated the bad .stl file. This is two separate issues: 1) When downsampling from the internal representation used by CGAL into doubles or floats, we lose precision and this can cause mesh degeneracies, including so-called T-vertices. 2) When importing STL files into OpenSCAD, we’re unable to process certain degenerate meshes (typically T-vertices) It’s possible to fix both these. 2) is probably more appropriate as such STL files can appear other places, but it wouldn’t hurt to also output cleaner meshes. -Marius