possible bug in intersection() (or the use there-of)

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

possible bug in intersection() (or the use there-of)

clothbot
Hi Clifford and Marius,

I'm getting some segfaults on the following design at early Compile time.  The only significant difference between it and the previous version is the inclusion of "nut_blank()" modules, little hexagons constructed using intersection():

http://github.com/clothbot/makerbot/blob/723dabc4285e004d09ed3db55c3fb0acf86e4a6a/fabjects/SewableSockets/SewableSocketsLib.scad

If you uncomment the top "render_part=7;" line and comment out "render_part=8;" the holes should render fine.  It's only when they are diff'd out in the "dip_socket_alternating()" module that OpenSCAD dies.

The previous version using cubes works fine:

http://github.com/clothbot/makerbot/blob/626c6c113e32e54728880d03191ed8ce31784a95/fabjects/SewableSockets/SewableSocketsLib.scad

I use the same chunk of module nut_blank() code in this other design, so the problem doesn't appear to be with intersection() directly:

http://github.com/clothbot/makerbot/blob/84087645a7caa2eed218bd27990c13b8bc9286ea/fabjects/MakerBeamConnectors/MakerBeamLib.scad

Any ideas?

Thanks!

Andrew.


--

"The future is already here.  It's just not very evenly distributed" -- William Gibson

Me: http://clothbot.com/wiki/




Reply | Threaded
Open this post in threaded view
|

Re: possible bug in intersection() (or the use there-of)

kintel
Administrator
On Apr 19, 2010, at 22:39 PM, Andrew Plumb wrote:

> I'm getting some segfaults on the following design at early Compile time.

I'm not able to reproduce your crash here.
I do, however, get a lot of "ERROR: Illegal polygonal object - make sure all polygons are defined with the same winding order. Skipping affected object."

I assume you're using your own build. Could you give me a stack trace or smth. which could help pinpointing your issue? Also, some info about your build environment could help (which versions of which libs etc.).

I'll take a look at what could cause the errors on my end in the meantime.

~/= Marius

--
We are Elektropeople for a better living.





Reply | Threaded
Open this post in threaded view
|

Re: possible bug in intersection() (or the use there-of)

clothbot
Hi Marius,

When I get home I'll run it again on my Mac Mini using your _latest (64bit) image and send you the crash log.  It was segfaulting there as well when I tried it, but perhaps something has been changed/fixed since.

I worked around the problem by rendering the intersection() parts to unit-scaled STL and import_stl() instantiating them into the main design.

There's always a way. ;-)

Andrew.

On 2010-04-23, at 12:33 PM, Marius Kintel wrote:

> On Apr 19, 2010, at 22:39 PM, Andrew Plumb wrote:
>
>> I'm getting some segfaults on the following design at early Compile time.
>
> I'm not able to reproduce your crash here.
> I do, however, get a lot of "ERROR: Illegal polygonal object - make sure all polygons are defined with the same winding order. Skipping affected object."
>
> I assume you're using your own build. Could you give me a stack trace or smth. which could help pinpointing your issue? Also, some info about your build environment could help (which versions of which libs etc.).
>
> I'll take a look at what could cause the errors on my end in the meantime.
>
> ~/= Marius
>
> --
> We are Elektropeople for a better living.
>
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad

--

"The future is already here.  It's just not very evenly distributed" -- William Gibson

Me: http://clothbot.com/wiki/




Reply | Threaded
Open this post in threaded view
|

Re: possible bug in intersection() (or the use there-of)

kintel
Administrator
Hi again,

I just tested some more, and there are two problems:
1) Rendering CSG: OpenSCAD hangs in CSGTerm::normalize() using > 2GB memory.
2) Rendering using CGAL: The polygon error happens immediately and no geometry is returned.

Your model is a bit complex so it's hard to progress from there..

~/= Marius

--
We are Elektropeople for a better living.





Reply | Threaded
Open this post in threaded view
|

Re: possible bug in intersection() (or the use there-of)

kintel
Administrator
In reply to this post by clothbot
On Apr 19, 2010, at 22:39 PM, Andrew Plumb wrote:

> I'm getting some segfaults on the following design at early Compile time.  The only significant difference between it and the previous version is the inclusion of "nut_blank()" modules, little hexagons constructed using intersection():
>
> http://github.com/clothbot/makerbot/blob/723dabc4285e004d09ed3db55c3fb0acf86e4a6a/fabjects/SewableSockets/SewableSocketsLib.scad
>
OK, more than 1.5 years have passed and this is still an issue.
I've been digging into this to figure out what's really going on:

As you're pointing out, the culprit is intersection:
Simply put, OpenCSG cannot render more than one negative node at once. To work around this, we have to render A-(B*C) as (A-B) + (A-C) (aka. normalization). If you look at your design, this means that every intersection will have to be combined with every other negative object. Since you're having a fair number of intersections going, this makes the CSG tree explode in size.

I have recently fixed some CSG tree normalization bugs, but this seems to be a hard limitation.
I might of course be wrong - perhaps one of the OpenCSG gurus have an idea how to better deal with this.

Anyway, as you also pointed out, your nut_blank() module can be rewritten not to used intersections.
Other ideas are: cylinder($fn=6), or use a render() statement directly in front of the intersection.

Also, I've now hard-limited the normalization to stop at 5000 nodes. This should at least keep OpenSCAD from crunching on the tree indefinitely or until the process crashes.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: possible bug in intersection() (or the use there-of)

clothbot
Hi Marius,

Using render() has proven to be the most general-purpose approach to addressing this and similar issues.

Thanks!

Andrew.

On 2011-12-26, at 1:11 PM, Marius Kintel wrote:

> On Apr 19, 2010, at 22:39 PM, Andrew Plumb wrote:
>
>> I'm getting some segfaults on the following design at early Compile time.  The only significant difference between it and the previous version is the inclusion of "nut_blank()" modules, little hexagons constructed using intersection():
>>
>> http://github.com/clothbot/makerbot/blob/723dabc4285e004d09ed3db55c3fb0acf86e4a6a/fabjects/SewableSockets/SewableSocketsLib.scad
>>
> OK, more than 1.5 years have passed and this is still an issue.
> I've been digging into this to figure out what's really going on:
>
> As you're pointing out, the culprit is intersection:
> Simply put, OpenCSG cannot render more than one negative node at once. To work around this, we have to render A-(B*C) as (A-B) + (A-C) (aka. normalization). If you look at your design, this means that every intersection will have to be combined with every other negative object. Since you're having a fair number of intersections going, this makes the CSG tree explode in size.
>
> I have recently fixed some CSG tree normalization bugs, but this seems to be a hard limitation.
> I might of course be wrong - perhaps one of the OpenCSG gurus have an idea how to better deal with this.
>
> Anyway, as you also pointed out, your nut_blank() module can be rewritten not to used intersections.
> Other ideas are: cylinder($fn=6), or use a render() statement directly in front of the intersection.
>
> Also, I've now hard-limited the normalization to stop at 5000 nodes. This should at least keep OpenSCAD from crunching on the tree indefinitely or until the process crashes.
>
> -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad

--

"The future is already here.  It's just not very evenly distributed" -- William Gibson

Me: http://clothbot.com/wiki/



Reply | Threaded
Open this post in threaded view
|

Re: possible bug in intersection() (or the use there-of)

Laszlo KREKACS
In reply to this post by kintel
Hey,

On Mon, Dec 26, 2011 at 7:11 PM, Marius Kintel <[hidden email]> wrote:
> Other ideas are: cylinder($fn=6), or use a render() statement directly in front of the intersection.

Speaking of cylinder($fn=6), could we somehow specify the inner radius?
Because cylinder(r=4, $fn=6) means the outer circle (drawing a circle
through the vertices).

In the most common usecase when I model a hex nut, I usually do like this:
1. I measure the face-face distance with a caliper,
2. I fire up qcad, and I draw the hexagon.
3. I measure the outer radius in qcad
4. I write this measured radius in openscad and specify $fn=6

If we had a $fno or something like this option, it could simplify to
1. cylinder(r=4, $fno=6)

(inner radius: drawing a circle meeting each edge center
outer radius: drawing a circle meeting each vertex)

Just an idea.

Best,
 Laszlo

Reply | Threaded
Open this post in threaded view
|

Re: possible bug in intersection() (or the use there-of)

Whosawhatsis
I and others have requested an inner radius specification in the past.
When you are setting the $fn variable so that the number of sides is
known, it's pretty easy to convert using simple trigonometry, and in
the case of $fn=6, I just use a ratio of 7/6.

On Dec 28, 2011, at 0:55, Laszlo KREKACS <[hidden email]> wrote:

> Hey,
>
> On Mon, Dec 26, 2011 at 7:11 PM, Marius Kintel <[hidden email]> wrote:
>> Other ideas are: cylinder($fn=6), or use a render() statement directly in front of the intersection.
>
> Speaking of cylinder($fn=6), could we somehow specify the inner radius?
> Because cylinder(r=4, $fn=6) means the outer circle (drawing a circle
> through the vertices).
>
> In the most common usecase when I model a hex nut, I usually do like this:
> 1. I measure the face-face distance with a caliper,
> 2. I fire up qcad, and I draw the hexagon.
> 3. I measure the outer radius in qcad
> 4. I write this measured radius in openscad and specify $fn=6
>
> If we had a $fno or something like this option, it could simplify to
> 1. cylinder(r=4, $fno=6)
>
> (inner radius: drawing a circle meeting each edge center
> outer radius: drawing a circle meeting each vertex)
>
> Just an idea.
>
> Best,
> Laszlo
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad

Reply | Threaded
Open this post in threaded view
|

Re: possible bug in intersection() (or the use there-of)

Giles Bathgate-2
On 28 December 2011 11:33, Whosa whatsis <[hidden email]> wrote:
> I and others have requested an inner radius specification in the past.
> When you are setting the $fn variable so that the number of sides is
> known, it's pretty easy to convert using simple trigonometry, and in
> the case of $fn=6, I just use a ratio of 7/6.

I implemented this in RapCAD, there is an apothem diameter and radius
parameters a, d, and r respctively
you can use any one of these parameters to specify the cylinder as required.

This can be considered as a reference implementation to include into openscad.

Regards

Giles

Reply | Threaded
Open this post in threaded view
|

Re: possible bug in intersection() (or the use there-of)

Triffid Hunter
In reply to this post by Laszlo KREKACS
On Wed, Dec 28, 2011 at 7:55 PM, Laszlo KREKACS
<[hidden email]> wrote:
> Hey,
>
> Speaking of cylinder($fn=6), could we somehow specify the inner radius?
> Because cylinder(r=4, $fn=6) means the outer circle (drawing a circle
> through the vertices).

easy, cylinder(r=radius / cos(180 / n_faces), $fn=n_faces)

so for a M6 hex nut (10mm face to face) I use cylinder(r=10 / cos(180
/ 6), $fn=6);
and for a horizontal octagonal hole, cylinder(r=6 / cos(180 / 8), $fn=8)

See http://triffid-hunter.no-ip.info/nut_trap_size.png for the
geometry if you're curious how I worked that out.

Reply | Threaded
Open this post in threaded view
|

Re: possible bug in intersection() (or the use there-of)

Laszlo KREKACS
> so for a M6 hex nut (10mm face to face) I use cylinder(r=10 / cos(180
> / 6), $fn=6);
> and for a horizontal octagonal hole, cylinder(r=6 / cos(180 / 8), $fn=8)
>
> See http://triffid-hunter.no-ip.info/nut_trap_size.png for the
> geometry if you're curious how I worked that out.


Thank you!