I'm working on a nut/bolt library that renders a little more efficiently than what I've found on thingiverse so far. Even printed a few prototypes from the models, and they come out very well, paired nuts and bolts fit together exactly. One critical feature to make a thread insert easily from a bolt into a nut is to have a conical taper into the first thread. Doing that difference() operation was no problem at first. I decided to try adding an option in the library for both sides of a nut or bolt thread to be tapered. The nut doesn't have a problem, but when performing a difference() operation on the bolt with a cylinder that has a cone cut out of it and inset slightly into the top & bottom edges of the thread, I get an error when I do the F6 CGAL render: Compiling design (CSG Tree generation)... Rendering Polygon Mesh using CGAL... ERROR: CGAL error in CGALUtils::applyBinaryOperator difference: CGAL ERROR: assertion violation! Expr: itl != it->second.end() File: /opt/mxe/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_3/SNC_external_structure.h Line: 1102 The rest of the model renders just fine, except without this one difference() operation performed. The odd part is that I can do the operation of tapering just the top, or just the bottom, and no error occurs. If both are differenced from the thread structure at the same time, this error occurs and no tapering is produced in the model on either side. I've attached the bolt-nut.scad library that this error occurs with. The very last line is the example bolt that produces the error. Changing the taper_side parameter at the end of the bolt() module call from "both" to "top" or "bottom" will produce the correct models. I'm curious if anyone knows how this sort of error can occur, since it is not due to something like a singularity or non-manifold operation being created (the usual reason a CGAL binary operation fails), since neither of the individual operations of creating the top/bottom taper on the thread creates this error, only when both are done together. Thanks in advance for any help! - David

The reason it only fails when both ends are tapered is because the points of the two tapers overlap each other. The singularity at the point seems to confuse CGAL. If I truncate the cone like this it works. module taper_cone_nut(radius=5, angle=60){ height = radius * tan(angle); translate([0, 0, height / 2]) cylinder(h=height / 2, r1=radius / 2, r2=radius); } I also needed to set convexity in the extrudes to make the preview work. On 3 March 2017 at 05:11, David Coneff <david.coneff@gmail.com> wrote: > I'm working on a nut/bolt library that renders a little more efficiently > than what I've found on thingiverse so far. Even printed a few prototypes > from the models, and they come out very well, paired nuts and bolts fit > together exactly. > > One critical feature to make a thread insert easily from a bolt into a nut > is to have a conical taper into the first thread. Doing that difference() > operation was no problem at first. I decided to try adding an option in the > library for both sides of a nut or bolt thread to be tapered. The nut > doesn't have a problem, but when performing a difference() operation on the > bolt with a cylinder that has a cone cut out of it and inset slightly into > the top & bottom edges of the thread, I get an error when I do the F6 CGAL > render: > > Compiling design (CSG Tree generation)... > > Rendering Polygon Mesh using CGAL... > > ERROR: CGAL error in CGALUtils::applyBinaryOperator difference: CGAL > ERROR: assertion violation! Expr: itl != it->second.end() File: > /opt/mxe/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_3/SNC_external_structure.h > Line: 1102 > > > The rest of the model renders just fine, except without this one > difference() operation performed. > > The odd part is that I can do the operation of tapering just the top, or > just the bottom, and no error occurs. If both are differenced from the > thread structure at the same time, this error occurs and no tapering is > produced in the model on either side. > > I've attached the bolt-nut.scad library that this error occurs with. The > very last line is the example bolt that produces the error. Changing the > taper_side parameter at the end of the bolt() module call from "both" to > "top" or "bottom" will produce the correct models. > > I'm curious if anyone knows how this sort of error can occur, since it is > not due to something like a singularity or non-manifold operation being > created (the usual reason a CGAL binary operation fails), since neither of > the individual operations of creating the top/bottom taper on the thread > creates this error, only when both are done together. > > Thanks in advance for any help! > > - David > > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

Hmm, you must have been having a different error then. Changing the taper_cone_nut should not, theoretically, effect the bolt code, since it uses taper_cone_bolt to create the volume that's subtracted on the outer edge of the external bolt threads. I also didn't need to change any convexity settings for mine to work, but that may be since it's recycling geometries from previous renders. It probably does look ugly the first time you load the script, after an initial F6 render even the F5 preview should look cleaner with successive modifications. I'll look into what's going on there though, I think you might have something that doesn't require me to re-work the code much. Thanks! On Fri, Mar 3, 2017 at 1:58 AM, nop head <nop.head@gmail.com> wrote: > The reason it only fails when both ends are tapered is because the points > of the two tapers overlap each other. The singularity at the point seems to > confuse CGAL. If I truncate the cone like this it works. > > module taper_cone_nut(radius=5, angle=60){ > height = radius * tan(angle); > translate([0, 0, height / 2]) > cylinder(h=height / 2, r1=radius / 2, r2=radius); > } > > I also needed to set convexity in the extrudes to make the preview work. > > On 3 March 2017 at 05:11, David Coneff <david.coneff@gmail.com> wrote: > >> I'm working on a nut/bolt library that renders a little more efficiently >> than what I've found on thingiverse so far. Even printed a few prototypes >> from the models, and they come out very well, paired nuts and bolts fit >> together exactly. >> >> One critical feature to make a thread insert easily from a bolt into a >> nut is to have a conical taper into the first thread. Doing that >> difference() operation was no problem at first. I decided to try adding an >> option in the library for both sides of a nut or bolt thread to be tapered. >> The nut doesn't have a problem, but when performing a difference() >> operation on the bolt with a cylinder that has a cone cut out of it and >> inset slightly into the top & bottom edges of the thread, I get an error >> when I do the F6 CGAL render: >> >> Compiling design (CSG Tree generation)... >> >> Rendering Polygon Mesh using CGAL... >> >> ERROR: CGAL error in CGALUtils::applyBinaryOperator difference: CGAL >> ERROR: assertion violation! Expr: itl != it->second.end() File: >> /opt/mxe/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_3/SNC_external_structure.h >> Line: 1102 >> >> >> The rest of the model renders just fine, except without this one >> difference() operation performed. >> >> The odd part is that I can do the operation of tapering just the top, or >> just the bottom, and no error occurs. If both are differenced from the >> thread structure at the same time, this error occurs and no tapering is >> produced in the model on either side. >> >> I've attached the bolt-nut.scad library that this error occurs with. The >> very last line is the example bolt that produces the error. Changing the >> taper_side parameter at the end of the bolt() module call from "both" to >> "top" or "bottom" will produce the correct models. >> >> I'm curious if anyone knows how this sort of error can occur, since it is >> not due to something like a singularity or non-manifold operation being >> created (the usual reason a CGAL binary operation fails), since neither of >> the individual operations of creating the top/bottom taper on the thread >> creates this error, only when both are done together. >> >> Thanks in advance for any help! >> >> - David >> >> >> >> _______________________________________________ >> OpenSCAD mailing list >> 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 > >

Hmm, I must have confused myself with the bug in OpenSCAD that only displays errors once. I have never known preview to work without setting convexity in linear_extrude unless there are no subsequent CSG ops. It is a complete mess in preview without convexity on my system. Removing the knife edges from taper_cone_bolt seems to fix it. You don't want to do CSG ops with coincident faces and vertexes unless they are absolutely coincident in several number representation used by OpenSCAD. So if you make a knife edge by subtracting a cone from a cylinder that are the same size and then subtract that from a bolt that is the same size you are going to get problems. There was a similar issue recently where hair was made by subtracting a head sphere from a cylinder creating a knife edge and then that was unioned with the head. Knife edges that just touch something create a non-manifold shape at best. They need to overlap slightly or just miss slightly. On 3 March 2017 at 15:26, David Coneff <david.coneff@gmail.com> wrote: > Hmm, you must have been having a different error then. Changing the > taper_cone_nut should not, theoretically, effect the bolt code, since it > uses taper_cone_bolt to create the volume that's subtracted on the outer > edge of the external bolt threads. > > I also didn't need to change any convexity settings for mine to work, but > that may be since it's recycling geometries from previous renders. It > probably does look ugly the first time you load the script, after an > initial F6 render even the F5 preview should look cleaner with successive > modifications. > > I'll look into what's going on there though, I think you might have > something that doesn't require me to re-work the code much. Thanks! > > On Fri, Mar 3, 2017 at 1:58 AM, nop head <nop.head@gmail.com> wrote: > >> The reason it only fails when both ends are tapered is because the points >> of the two tapers overlap each other. The singularity at the point seems to >> confuse CGAL. If I truncate the cone like this it works. >> >> module taper_cone_nut(radius=5, angle=60){ >> height = radius * tan(angle); >> translate([0, 0, height / 2]) >> cylinder(h=height / 2, r1=radius / 2, r2=radius); >> } >> >> I also needed to set convexity in the extrudes to make the preview work. >> >> On 3 March 2017 at 05:11, David Coneff <david.coneff@gmail.com> wrote: >> >>> I'm working on a nut/bolt library that renders a little more efficiently >>> than what I've found on thingiverse so far. Even printed a few prototypes >>> from the models, and they come out very well, paired nuts and bolts fit >>> together exactly. >>> >>> One critical feature to make a thread insert easily from a bolt into a >>> nut is to have a conical taper into the first thread. Doing that >>> difference() operation was no problem at first. I decided to try adding an >>> option in the library for both sides of a nut or bolt thread to be tapered. >>> The nut doesn't have a problem, but when performing a difference() >>> operation on the bolt with a cylinder that has a cone cut out of it and >>> inset slightly into the top & bottom edges of the thread, I get an error >>> when I do the F6 CGAL render: >>> >>> Compiling design (CSG Tree generation)... >>> >>> Rendering Polygon Mesh using CGAL... >>> >>> ERROR: CGAL error in CGALUtils::applyBinaryOperator difference: CGAL >>> ERROR: assertion violation! Expr: itl != it->second.end() File: >>> /opt/mxe/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_3/SNC_external_structure.h >>> Line: 1102 >>> >>> >>> The rest of the model renders just fine, except without this one >>> difference() operation performed. >>> >>> The odd part is that I can do the operation of tapering just the top, or >>> just the bottom, and no error occurs. If both are differenced from the >>> thread structure at the same time, this error occurs and no tapering is >>> produced in the model on either side. >>> >>> I've attached the bolt-nut.scad library that this error occurs with. The >>> very last line is the example bolt that produces the error. Changing the >>> taper_side parameter at the end of the bolt() module call from "both" to >>> "top" or "bottom" will produce the correct models. >>> >>> I'm curious if anyone knows how this sort of error can occur, since it >>> is not due to something like a singularity or non-manifold operation being >>> created (the usual reason a CGAL binary operation fails), since neither of >>> the individual operations of creating the top/bottom taper on the thread >>> creates this error, only when both are done together. >>> >>> Thanks in advance for any help! >>> >>> - David >>> >>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> 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 >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

What convexity value did you use? I found setting it manually in just one of them made the model a lot more "weighty" for rotating in preview mode. What I liked about this construction method is that the original code I used produces a model that may look ugly in F5 preview, but with an appropriate $fn=30 or higher it renders just fine for making an STL model. Most of the other screw libraries I've ran into on thingiverse use a construction method that leads to highly detailed, but also very computationally expensive models for even an example 2-revolution thread even in preview mode. On Fri, Mar 3, 2017 at 8:26 AM, David Coneff <david.coneff@gmail.com> wrote: > Hmm, you must have been having a different error then. Changing the > taper_cone_nut should not, theoretically, effect the bolt code, since it > uses taper_cone_bolt to create the volume that's subtracted on the outer > edge of the external bolt threads. > > I also didn't need to change any convexity settings for mine to work, but > that may be since it's recycling geometries from previous renders. It > probably does look ugly the first time you load the script, after an > initial F6 render even the F5 preview should look cleaner with successive > modifications. > > I'll look into what's going on there though, I think you might have > something that doesn't require me to re-work the code much. Thanks! > > On Fri, Mar 3, 2017 at 1:58 AM, nop head <nop.head@gmail.com> wrote: > >> The reason it only fails when both ends are tapered is because the points >> of the two tapers overlap each other. The singularity at the point seems to >> confuse CGAL. If I truncate the cone like this it works. >> >> module taper_cone_nut(radius=5, angle=60){ >> height = radius * tan(angle); >> translate([0, 0, height / 2]) >> cylinder(h=height / 2, r1=radius / 2, r2=radius); >> } >> >> I also needed to set convexity in the extrudes to make the preview work. >> >> On 3 March 2017 at 05:11, David Coneff <david.coneff@gmail.com> wrote: >> >>> I'm working on a nut/bolt library that renders a little more efficiently >>> than what I've found on thingiverse so far. Even printed a few prototypes >>> from the models, and they come out very well, paired nuts and bolts fit >>> together exactly. >>> >>> One critical feature to make a thread insert easily from a bolt into a >>> nut is to have a conical taper into the first thread. Doing that >>> difference() operation was no problem at first. I decided to try adding an >>> option in the library for both sides of a nut or bolt thread to be tapered. >>> The nut doesn't have a problem, but when performing a difference() >>> operation on the bolt with a cylinder that has a cone cut out of it and >>> inset slightly into the top & bottom edges of the thread, I get an error >>> when I do the F6 CGAL render: >>> >>> Compiling design (CSG Tree generation)... >>> >>> Rendering Polygon Mesh using CGAL... >>> >>> ERROR: CGAL error in CGALUtils::applyBinaryOperator difference: CGAL >>> ERROR: assertion violation! Expr: itl != it->second.end() File: >>> /opt/mxe/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_3/SNC_external_structure.h >>> Line: 1102 >>> >>> >>> The rest of the model renders just fine, except without this one >>> difference() operation performed. >>> >>> The odd part is that I can do the operation of tapering just the top, or >>> just the bottom, and no error occurs. If both are differenced from the >>> thread structure at the same time, this error occurs and no tapering is >>> produced in the model on either side. >>> >>> I've attached the bolt-nut.scad library that this error occurs with. The >>> very last line is the example bolt that produces the error. Changing the >>> taper_side parameter at the end of the bolt() module call from "both" to >>> "top" or "bottom" will produce the correct models. >>> >>> I'm curious if anyone knows how this sort of error can occur, since it >>> is not due to something like a singularity or non-manifold operation being >>> created (the usual reason a CGAL binary operation fails), since neither of >>> the individual operations of creating the top/bottom taper on the thread >>> creates this error, only when both are done together. >>> >>> Thanks in advance for any help! >>> >>> - David >>> >>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> 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 >> >> >

I set convexity to 4. Here is the difference it makes with it set just on the bolt. ​ On 3 March 2017 at 15:55, David Coneff <david.coneff@gmail.com> wrote: > What convexity value did you use? I found setting it manually in just one > of them made the model a lot more "weighty" for rotating in preview mode. > What I liked about this construction method is that the original code I > used produces a model that may look ugly in F5 preview, but with an > appropriate $fn=30 or higher it renders just fine for making an STL model. > Most of the other screw libraries I've ran into on thingiverse use a > construction method that leads to highly detailed, but also very > computationally expensive models for even an example 2-revolution thread > even in preview mode. > > On Fri, Mar 3, 2017 at 8:26 AM, David Coneff <david.coneff@gmail.com> > wrote: > >> Hmm, you must have been having a different error then. Changing the >> taper_cone_nut should not, theoretically, effect the bolt code, since it >> uses taper_cone_bolt to create the volume that's subtracted on the outer >> edge of the external bolt threads. >> >> I also didn't need to change any convexity settings for mine to work, but >> that may be since it's recycling geometries from previous renders. It >> probably does look ugly the first time you load the script, after an >> initial F6 render even the F5 preview should look cleaner with successive >> modifications. >> >> I'll look into what's going on there though, I think you might have >> something that doesn't require me to re-work the code much. Thanks! >> >> On Fri, Mar 3, 2017 at 1:58 AM, nop head <nop.head@gmail.com> wrote: >> >>> The reason it only fails when both ends are tapered is because the >>> points of the two tapers overlap each other. The singularity at the point >>> seems to confuse CGAL. If I truncate the cone like this it works. >>> >>> module taper_cone_nut(radius=5, angle=60){ >>> height = radius * tan(angle); >>> translate([0, 0, height / 2]) >>> cylinder(h=height / 2, r1=radius / 2, r2=radius); >>> } >>> >>> I also needed to set convexity in the extrudes to make the preview work. >>> >>> On 3 March 2017 at 05:11, David Coneff <david.coneff@gmail.com> wrote: >>> >>>> I'm working on a nut/bolt library that renders a little more >>>> efficiently than what I've found on thingiverse so far. Even printed a few >>>> prototypes from the models, and they come out very well, paired nuts and >>>> bolts fit together exactly. >>>> >>>> One critical feature to make a thread insert easily from a bolt into a >>>> nut is to have a conical taper into the first thread. Doing that >>>> difference() operation was no problem at first. I decided to try adding an >>>> option in the library for both sides of a nut or bolt thread to be tapered. >>>> The nut doesn't have a problem, but when performing a difference() >>>> operation on the bolt with a cylinder that has a cone cut out of it and >>>> inset slightly into the top & bottom edges of the thread, I get an error >>>> when I do the F6 CGAL render: >>>> >>>> Compiling design (CSG Tree generation)... >>>> >>>> Rendering Polygon Mesh using CGAL... >>>> >>>> ERROR: CGAL error in CGALUtils::applyBinaryOperator difference: CGAL >>>> ERROR: assertion violation! Expr: itl != it->second.end() File: >>>> /opt/mxe/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_3/SNC_external_structure.h >>>> Line: 1102 >>>> >>>> >>>> The rest of the model renders just fine, except without this one >>>> difference() operation performed. >>>> >>>> The odd part is that I can do the operation of tapering just the top, >>>> or just the bottom, and no error occurs. If both are differenced from the >>>> thread structure at the same time, this error occurs and no tapering is >>>> produced in the model on either side. >>>> >>>> I've attached the bolt-nut.scad library that this error occurs with. >>>> The very last line is the example bolt that produces the error. Changing >>>> the taper_side parameter at the end of the bolt() module call from "both" >>>> to "top" or "bottom" will produce the correct models. >>>> >>>> I'm curious if anyone knows how this sort of error can occur, since it >>>> is not due to something like a singularity or non-manifold operation being >>>> created (the usual reason a CGAL binary operation fails), since neither of >>>> the individual operations of creating the top/bottom taper on the thread >>>> creates this error, only when both are done together. >>>> >>>> Thanks in advance for any help! >>>> >>>> - David >>>> >>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> 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 >>> >>> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

Yeah, I suppose I should have been more careful with the cone part of the code. After trying out your example I saw that it resolved the error, however, the F6 render still didn't result in a tapered bolt thread. I tried adapting that modification to the taper_cone_bolt() module, but there's something wrong with how I did it because the thread is not tapered correctly.. something to do with the interaction of the translation of the taper_cone_bolt's height, the taper_angle still looks correct. On Fri, Mar 3, 2017 at 8:54 AM, nop head <nop.head@gmail.com> wrote: > Hmm, I must have confused myself with the bug in OpenSCAD that only > displays errors once. > > I have never known preview to work without setting convexity in > linear_extrude unless there are no subsequent CSG ops. It is a complete > mess in preview without convexity on my system. > > Removing the knife edges from taper_cone_bolt seems to fix it. You don't > want to do CSG ops with coincident faces and vertexes unless they are > absolutely coincident in several number representation used by OpenSCAD. > So if you make a knife edge by subtracting a cone from a cylinder that are > the same size and then subtract that from a bolt that is the same size you > are going to get problems. > > There was a similar issue recently where hair was made by subtracting a > head sphere from a cylinder creating a knife edge and then that was unioned > with the head. Knife edges that just touch something create a non-manifold > shape at best. They need to overlap slightly or just miss slightly. > > On 3 March 2017 at 15:26, David Coneff <david.coneff@gmail.com> wrote: > >> Hmm, you must have been having a different error then. Changing the >> taper_cone_nut should not, theoretically, effect the bolt code, since it >> uses taper_cone_bolt to create the volume that's subtracted on the outer >> edge of the external bolt threads. >> >> I also didn't need to change any convexity settings for mine to work, but >> that may be since it's recycling geometries from previous renders. It >> probably does look ugly the first time you load the script, after an >> initial F6 render even the F5 preview should look cleaner with successive >> modifications. >> >> I'll look into what's going on there though, I think you might have >> something that doesn't require me to re-work the code much. Thanks! >> >> On Fri, Mar 3, 2017 at 1:58 AM, nop head <nop.head@gmail.com> wrote: >> >>> The reason it only fails when both ends are tapered is because the >>> points of the two tapers overlap each other. The singularity at the point >>> seems to confuse CGAL. If I truncate the cone like this it works. >>> >>> module taper_cone_nut(radius=5, angle=60){ >>> height = radius * tan(angle); >>> translate([0, 0, height / 2]) >>> cylinder(h=height / 2, r1=radius / 2, r2=radius); >>> } >>> >>> I also needed to set convexity in the extrudes to make the preview work. >>> >>> On 3 March 2017 at 05:11, David Coneff <david.coneff@gmail.com> wrote: >>> >>>> I'm working on a nut/bolt library that renders a little more >>>> efficiently than what I've found on thingiverse so far. Even printed a few >>>> prototypes from the models, and they come out very well, paired nuts and >>>> bolts fit together exactly. >>>> >>>> One critical feature to make a thread insert easily from a bolt into a >>>> nut is to have a conical taper into the first thread. Doing that >>>> difference() operation was no problem at first. I decided to try adding an >>>> option in the library for both sides of a nut or bolt thread to be tapered. >>>> The nut doesn't have a problem, but when performing a difference() >>>> operation on the bolt with a cylinder that has a cone cut out of it and >>>> inset slightly into the top & bottom edges of the thread, I get an error >>>> when I do the F6 CGAL render: >>>> >>>> Compiling design (CSG Tree generation)... >>>> >>>> Rendering Polygon Mesh using CGAL... >>>> >>>> ERROR: CGAL error in CGALUtils::applyBinaryOperator difference: CGAL >>>> ERROR: assertion violation! Expr: itl != it->second.end() File: >>>> /opt/mxe/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_3/SNC_external_structure.h >>>> Line: 1102 >>>> >>>> >>>> The rest of the model renders just fine, except without this one >>>> difference() operation performed. >>>> >>>> The odd part is that I can do the operation of tapering just the top, >>>> or just the bottom, and no error occurs. If both are differenced from the >>>> thread structure at the same time, this error occurs and no tapering is >>>> produced in the model on either side. >>>> >>>> I've attached the bolt-nut.scad library that this error occurs with. >>>> The very last line is the example bolt that produces the error. Changing >>>> the taper_side parameter at the end of the bolt() module call from "both" >>>> to "top" or "bottom" will produce the correct models. >>>> >>>> I'm curious if anyone knows how this sort of error can occur, since it >>>> is not due to something like a singularity or non-manifold operation being >>>> created (the usual reason a CGAL binary operation fails), since neither of >>>> the individual operations of creating the top/bottom taper on the thread >>>> creates this error, only when both are done together. >>>> >>>> Thanks in advance for any help! >>>> >>>> - David >>>> >>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> 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 >>> >>> >> >> _______________________________________________ >> OpenSCAD mailing list >> 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 > >

That's about what I see when $fn=20 or 30 and I do the F6 render. For me at least, it is better to have a preview render that looks ugly but doesn't slow down the model much since it is only one part that will be integrated into a larger model. Makes it easier to iterate the design and check for spacing configurations (e.g., did I write a translation function correctly so two pieces join correctly). On Fri, Mar 3, 2017 at 8:59 AM, nop head <nop.head@gmail.com> wrote: > I set convexity to 4. Here is the difference it makes with it set just on > the bolt. > > > ​ > > On 3 March 2017 at 15:55, David Coneff <david.coneff@gmail.com> wrote: > >> What convexity value did you use? I found setting it manually in just one >> of them made the model a lot more "weighty" for rotating in preview mode. >> What I liked about this construction method is that the original code I >> used produces a model that may look ugly in F5 preview, but with an >> appropriate $fn=30 or higher it renders just fine for making an STL model. >> Most of the other screw libraries I've ran into on thingiverse use a >> construction method that leads to highly detailed, but also very >> computationally expensive models for even an example 2-revolution thread >> even in preview mode. >> >> On Fri, Mar 3, 2017 at 8:26 AM, David Coneff <david.coneff@gmail.com> >> wrote: >> >>> Hmm, you must have been having a different error then. Changing the >>> taper_cone_nut should not, theoretically, effect the bolt code, since it >>> uses taper_cone_bolt to create the volume that's subtracted on the outer >>> edge of the external bolt threads. >>> >>> I also didn't need to change any convexity settings for mine to work, >>> but that may be since it's recycling geometries from previous renders. It >>> probably does look ugly the first time you load the script, after an >>> initial F6 render even the F5 preview should look cleaner with successive >>> modifications. >>> >>> I'll look into what's going on there though, I think you might have >>> something that doesn't require me to re-work the code much. Thanks! >>> >>> On Fri, Mar 3, 2017 at 1:58 AM, nop head <nop.head@gmail.com> wrote: >>> >>>> The reason it only fails when both ends are tapered is because the >>>> points of the two tapers overlap each other. The singularity at the point >>>> seems to confuse CGAL. If I truncate the cone like this it works. >>>> >>>> module taper_cone_nut(radius=5, angle=60){ >>>> height = radius * tan(angle); >>>> translate([0, 0, height / 2]) >>>> cylinder(h=height / 2, r1=radius / 2, r2=radius); >>>> } >>>> >>>> I also needed to set convexity in the extrudes to make the preview work. >>>> >>>> On 3 March 2017 at 05:11, David Coneff <david.coneff@gmail.com> wrote: >>>> >>>>> I'm working on a nut/bolt library that renders a little more >>>>> efficiently than what I've found on thingiverse so far. Even printed a few >>>>> prototypes from the models, and they come out very well, paired nuts and >>>>> bolts fit together exactly. >>>>> >>>>> One critical feature to make a thread insert easily from a bolt into a >>>>> nut is to have a conical taper into the first thread. Doing that >>>>> difference() operation was no problem at first. I decided to try adding an >>>>> option in the library for both sides of a nut or bolt thread to be tapered. >>>>> The nut doesn't have a problem, but when performing a difference() >>>>> operation on the bolt with a cylinder that has a cone cut out of it and >>>>> inset slightly into the top & bottom edges of the thread, I get an error >>>>> when I do the F6 CGAL render: >>>>> >>>>> Compiling design (CSG Tree generation)... >>>>> >>>>> Rendering Polygon Mesh using CGAL... >>>>> >>>>> ERROR: CGAL error in CGALUtils::applyBinaryOperator difference: CGAL >>>>> ERROR: assertion violation! Expr: itl != it->second.end() File: >>>>> /opt/mxe/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_3/SNC_external_structure.h >>>>> Line: 1102 >>>>> >>>>> >>>>> The rest of the model renders just fine, except without this one >>>>> difference() operation performed. >>>>> >>>>> The odd part is that I can do the operation of tapering just the top, >>>>> or just the bottom, and no error occurs. If both are differenced from the >>>>> thread structure at the same time, this error occurs and no tapering is >>>>> produced in the model on either side. >>>>> >>>>> I've attached the bolt-nut.scad library that this error occurs with. >>>>> The very last line is the example bolt that produces the error. Changing >>>>> the taper_side parameter at the end of the bolt() module call from "both" >>>>> to "top" or "bottom" will produce the correct models. >>>>> >>>>> I'm curious if anyone knows how this sort of error can occur, since it >>>>> is not due to something like a singularity or non-manifold operation being >>>>> created (the usual reason a CGAL binary operation fails), since neither of >>>>> the individual operations of creating the top/bottom taper on the thread >>>>> creates this error, only when both are done together. >>>>> >>>>> Thanks in advance for any help! >>>>> >>>>> - David >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> 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 >>>> >>>> >>> >> >> _______________________________________________ >> OpenSCAD mailing list >> 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 > >

>After trying out your example I saw that it resolved the error, however, the F6 render still didn't result in a tapered bolt thread You got fooled by the same bug as me. You have to flush the caches to see the error again. This seems to work. module taper_cone_bolt(radius=5, angle=60){ height = radius * tan(angle); // note that height approaches infinity as angle approaches 90. putting in 90 will create a nonsensical result, 89 works fine though. difference(){ cylinder(h=height + 0.01, r=radius); // cylinder that matches the maximum outer radius of the threads cylinder(h=height,r1=radius,r2=0); // subtracted cone } } It avoids the point of the cone touching the top. On 3 March 2017 at 16:04, David Coneff <david.coneff@gmail.com> wrote: > That's about what I see when $fn=20 or 30 and I do the F6 render. For me > at least, it is better to have a preview render that looks ugly but doesn't > slow down the model much since it is only one part that will be integrated > into a larger model. Makes it easier to iterate the design and check for > spacing configurations (e.g., did I write a translation function correctly > so two pieces join correctly). > > On Fri, Mar 3, 2017 at 8:59 AM, nop head <nop.head@gmail.com> wrote: > >> I set convexity to 4. Here is the difference it makes with it set just on >> the bolt. >> >> >> ​ >> >> On 3 March 2017 at 15:55, David Coneff <david.coneff@gmail.com> wrote: >> >>> What convexity value did you use? I found setting it manually in just >>> one of them made the model a lot more "weighty" for rotating in preview >>> mode. What I liked about this construction method is that the original code >>> I used produces a model that may look ugly in F5 preview, but with an >>> appropriate $fn=30 or higher it renders just fine for making an STL model. >>> Most of the other screw libraries I've ran into on thingiverse use a >>> construction method that leads to highly detailed, but also very >>> computationally expensive models for even an example 2-revolution thread >>> even in preview mode. >>> >>> On Fri, Mar 3, 2017 at 8:26 AM, David Coneff <david.coneff@gmail.com> >>> wrote: >>> >>>> Hmm, you must have been having a different error then. Changing the >>>> taper_cone_nut should not, theoretically, effect the bolt code, since it >>>> uses taper_cone_bolt to create the volume that's subtracted on the outer >>>> edge of the external bolt threads. >>>> >>>> I also didn't need to change any convexity settings for mine to work, >>>> but that may be since it's recycling geometries from previous renders. It >>>> probably does look ugly the first time you load the script, after an >>>> initial F6 render even the F5 preview should look cleaner with successive >>>> modifications. >>>> >>>> I'll look into what's going on there though, I think you might have >>>> something that doesn't require me to re-work the code much. Thanks! >>>> >>>> On Fri, Mar 3, 2017 at 1:58 AM, nop head <nop.head@gmail.com> wrote: >>>> >>>>> The reason it only fails when both ends are tapered is because the >>>>> points of the two tapers overlap each other. The singularity at the point >>>>> seems to confuse CGAL. If I truncate the cone like this it works. >>>>> >>>>> module taper_cone_nut(radius=5, angle=60){ >>>>> height = radius * tan(angle); >>>>> translate([0, 0, height / 2]) >>>>> cylinder(h=height / 2, r1=radius / 2, r2=radius); >>>>> } >>>>> >>>>> I also needed to set convexity in the extrudes to make the preview >>>>> work. >>>>> >>>>> On 3 March 2017 at 05:11, David Coneff <david.coneff@gmail.com> wrote: >>>>> >>>>>> I'm working on a nut/bolt library that renders a little more >>>>>> efficiently than what I've found on thingiverse so far. Even printed a few >>>>>> prototypes from the models, and they come out very well, paired nuts and >>>>>> bolts fit together exactly. >>>>>> >>>>>> One critical feature to make a thread insert easily from a bolt into >>>>>> a nut is to have a conical taper into the first thread. Doing that >>>>>> difference() operation was no problem at first. I decided to try adding an >>>>>> option in the library for both sides of a nut or bolt thread to be tapered. >>>>>> The nut doesn't have a problem, but when performing a difference() >>>>>> operation on the bolt with a cylinder that has a cone cut out of it and >>>>>> inset slightly into the top & bottom edges of the thread, I get an error >>>>>> when I do the F6 CGAL render: >>>>>> >>>>>> Compiling design (CSG Tree generation)... >>>>>> >>>>>> Rendering Polygon Mesh using CGAL... >>>>>> >>>>>> ERROR: CGAL error in CGALUtils::applyBinaryOperator difference: CGAL >>>>>> ERROR: assertion violation! Expr: itl != it->second.end() File: >>>>>> /opt/mxe/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_3/SNC_external_structure.h >>>>>> Line: 1102 >>>>>> >>>>>> >>>>>> The rest of the model renders just fine, except without this one >>>>>> difference() operation performed. >>>>>> >>>>>> The odd part is that I can do the operation of tapering just the top, >>>>>> or just the bottom, and no error occurs. If both are differenced from the >>>>>> thread structure at the same time, this error occurs and no tapering is >>>>>> produced in the model on either side. >>>>>> >>>>>> I've attached the bolt-nut.scad library that this error occurs with. >>>>>> The very last line is the example bolt that produces the error. Changing >>>>>> the taper_side parameter at the end of the bolt() module call from "both" >>>>>> to "top" or "bottom" will produce the correct models. >>>>>> >>>>>> I'm curious if anyone knows how this sort of error can occur, since >>>>>> it is not due to something like a singularity or non-manifold operation >>>>>> being created (the usual reason a CGAL binary operation fails), since >>>>>> neither of the individual operations of creating the top/bottom taper on >>>>>> the thread creates this error, only when both are done together. >>>>>> >>>>>> Thanks in advance for any help! >>>>>> >>>>>> - David >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenSCAD mailing list >>>>>> 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 >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> 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 >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

I did the same thing (h=height + 1, radius = radius+1) for the main cylinder that gets a cone subtracted from it. I was trying to make a cone with a "flat" point like in the taper_cone_nut code like you did, but I did it incorrectly and it affected the math of what the angle of the conical surface was. In either case, the code works now, and the taper_cone_nut() won't create point singularity intersections, so I believe this code will work pretty well. Hopefully it is easy to for other people to re-use as well, I put some effort into documenting what's going on and structuring it to be easy to read. Thanks for the help! That really saved a lot of head scratching for me. On Fri, Mar 3, 2017 at 9:26 AM, nop head <nop.head@gmail.com> wrote: > >After trying out your example I saw that it resolved the error, however, > the F6 render still didn't result in a tapered bolt thread > > You got fooled by the same bug as me. You have to flush the caches to see > the error again. This seems to work. > > module taper_cone_bolt(radius=5, angle=60){ > height = radius * tan(angle); // note that height > approaches infinity as angle approaches 90. putting in 90 will create a > nonsensical result, 89 works fine though. > difference(){ > cylinder(h=height + 0.01, r=radius); // cylinder that > matches the maximum outer radius of the threads > cylinder(h=height,r1=radius,r2=0); // subtracted cone > } > } > > It avoids the point of the cone touching the top. > > On 3 March 2017 at 16:04, David Coneff <david.coneff@gmail.com> wrote: > >> That's about what I see when $fn=20 or 30 and I do the F6 render. For me >> at least, it is better to have a preview render that looks ugly but doesn't >> slow down the model much since it is only one part that will be integrated >> into a larger model. Makes it easier to iterate the design and check for >> spacing configurations (e.g., did I write a translation function correctly >> so two pieces join correctly). >> >> On Fri, Mar 3, 2017 at 8:59 AM, nop head <nop.head@gmail.com> wrote: >> >>> I set convexity to 4. Here is the difference it makes with it set just >>> on the bolt. >>> >>> >>> ​ >>> >>> On 3 March 2017 at 15:55, David Coneff <david.coneff@gmail.com> wrote: >>> >>>> What convexity value did you use? I found setting it manually in just >>>> one of them made the model a lot more "weighty" for rotating in preview >>>> mode. What I liked about this construction method is that the original code >>>> I used produces a model that may look ugly in F5 preview, but with an >>>> appropriate $fn=30 or higher it renders just fine for making an STL model. >>>> Most of the other screw libraries I've ran into on thingiverse use a >>>> construction method that leads to highly detailed, but also very >>>> computationally expensive models for even an example 2-revolution thread >>>> even in preview mode. >>>> >>>> On Fri, Mar 3, 2017 at 8:26 AM, David Coneff <david.coneff@gmail.com> >>>> wrote: >>>> >>>>> Hmm, you must have been having a different error then. Changing the >>>>> taper_cone_nut should not, theoretically, effect the bolt code, since it >>>>> uses taper_cone_bolt to create the volume that's subtracted on the outer >>>>> edge of the external bolt threads. >>>>> >>>>> I also didn't need to change any convexity settings for mine to work, >>>>> but that may be since it's recycling geometries from previous renders. It >>>>> probably does look ugly the first time you load the script, after an >>>>> initial F6 render even the F5 preview should look cleaner with successive >>>>> modifications. >>>>> >>>>> I'll look into what's going on there though, I think you might have >>>>> something that doesn't require me to re-work the code much. Thanks! >>>>> >>>>> On Fri, Mar 3, 2017 at 1:58 AM, nop head <nop.head@gmail.com> wrote: >>>>> >>>>>> The reason it only fails when both ends are tapered is because the >>>>>> points of the two tapers overlap each other. The singularity at the point >>>>>> seems to confuse CGAL. If I truncate the cone like this it works. >>>>>> >>>>>> module taper_cone_nut(radius=5, angle=60){ >>>>>> height = radius * tan(angle); >>>>>> translate([0, 0, height / 2]) >>>>>> cylinder(h=height / 2, r1=radius / 2, r2=radius); >>>>>> } >>>>>> >>>>>> I also needed to set convexity in the extrudes to make the preview >>>>>> work. >>>>>> >>>>>> On 3 March 2017 at 05:11, David Coneff <david.coneff@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> I'm working on a nut/bolt library that renders a little more >>>>>>> efficiently than what I've found on thingiverse so far. Even printed a few >>>>>>> prototypes from the models, and they come out very well, paired nuts and >>>>>>> bolts fit together exactly. >>>>>>> >>>>>>> One critical feature to make a thread insert easily from a bolt into >>>>>>> a nut is to have a conical taper into the first thread. Doing that >>>>>>> difference() operation was no problem at first. I decided to try adding an >>>>>>> option in the library for both sides of a nut or bolt thread to be tapered. >>>>>>> The nut doesn't have a problem, but when performing a difference() >>>>>>> operation on the bolt with a cylinder that has a cone cut out of it and >>>>>>> inset slightly into the top & bottom edges of the thread, I get an error >>>>>>> when I do the F6 CGAL render: >>>>>>> >>>>>>> Compiling design (CSG Tree generation)... >>>>>>> >>>>>>> Rendering Polygon Mesh using CGAL... >>>>>>> >>>>>>> ERROR: CGAL error in CGALUtils::applyBinaryOperator difference: CGAL >>>>>>> ERROR: assertion violation! Expr: itl != it->second.end() File: >>>>>>> /opt/mxe/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_3/SNC_external_structure.h >>>>>>> Line: 1102 >>>>>>> >>>>>>> >>>>>>> The rest of the model renders just fine, except without this one >>>>>>> difference() operation performed. >>>>>>> >>>>>>> The odd part is that I can do the operation of tapering just the >>>>>>> top, or just the bottom, and no error occurs. If both are differenced from >>>>>>> the thread structure at the same time, this error occurs and no tapering is >>>>>>> produced in the model on either side. >>>>>>> >>>>>>> I've attached the bolt-nut.scad library that this error occurs with. >>>>>>> The very last line is the example bolt that produces the error. Changing >>>>>>> the taper_side parameter at the end of the bolt() module call from "both" >>>>>>> to "top" or "bottom" will produce the correct models. >>>>>>> >>>>>>> I'm curious if anyone knows how this sort of error can occur, since >>>>>>> it is not due to something like a singularity or non-manifold operation >>>>>>> being created (the usual reason a CGAL binary operation fails), since >>>>>>> neither of the individual operations of creating the top/bottom taper on >>>>>>> the thread creates this error, only when both are done together. >>>>>>> >>>>>>> Thanks in advance for any help! >>>>>>> >>>>>>> - David >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OpenSCAD mailing list >>>>>>> Discuss@lists.openscad.org >>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.ope >>>>>>> nscad.org >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenSCAD mailing list >>>>>> 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 >>>> >>>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> 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 >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >