Long journey to no where...

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

Long journey to no where...

Dan Zuras 3D


        Folks,

        After suggestions from both William Adams
        <[hidden email]> & Whosawhatsis
        <[hidden email]>, I spent some
        time looking at using skeinforge to solve
        my problem.

        Recall, the task is to make 100 polygonal
        objects to represent the entries in a 10x10
        multiplication table as an aid to teaching
        a 4-year old his math.

        My original design involved toroidal polygons
        with N segments around the major diameter &
        M segments around the minor to represent the
        problem NxM.  The design exposed a minor bug
        which both William & Whosawhatsis suggested
        work arounds for.

        One of those suggestions was to look into
        making a skeinforge model that only printed
        hollow objects with no top or bottom.  After
        some fooling around, I figured out how to do
        1, 2, & 3 layer objects with no fill at all.

        I have to thank you guys for that because I've
        been trying to figure out how to do that ever
        since I started spitting plastic.

        (BTW, I would like to figure out a model that
        can make 2 or 3 layer walls & a thick bottom
        but no top.  I'd like to make some cups for
        Christmas presents & that sounds like the
        ideal way.  But that is a question for another
        day.)

        Anyway, this led me to redesigning my table
        entry objects.  I now make them as barrels
        with N staves around the barrel & M from top
        to bottom for the NxM entry.  I even made an
        actual 5x7 barrel.

        Alas, while it is a beautifully light &
        transparent object & looks nicely pentagonal
        going around, you cannot see the 7 bottom to
        top faces.  They are even difficult to find
        to the touch.

        I thought, no big deal.  We're still on the
        right track.  I'll make the faces slightly
        concave so they are easy to see & feel.

        And that's where I got bit by a CGAL problem
        again.

        The following code fragment illustrates the
        problem.  It renders fine under openCSG but
        chokes under CGAL due to the following error:

                ERROR: Illegal polygonal object - make sure
                all polygons are defined with the same winding
                order. Skipping affected object.

        on the console & this one in stderr:

                CGAL::Polyhedron_incremental_builder_3<HDS>::
                lookup_hole(): input error: at vertex 1 a closed
                surface already exists and facet 291 is nonetheless
                adjacent.
                        The closed cycle of facets is: 232 0 58 116 174.

        It is kind of understandable.  After all, I
        made the faces concave by taking a small bite
        out of it with a circle.  So that face is,
        I'll say naturally, different from the others.

        But that is a 2D object.  It has not yet been
        extruded.  Is it reasonable for it to be said
        to have a winding order at all?

        Anyway, as always, I'm open to suggestions as
        to how to proceed.

        Thanks all,


                           Dan



module stick(s,t) union() {
        translate([-s/2,0,0]) scale([t/2,t/2]) unitCircle();
        translate([s/2,0,0]) scale([t/2,t/2]) unitCircle();
        scale([s,t]) unitSquare();
}

module mul1(n,s,t) for (i=[1:n]) rotate([0,0,i*360/n])
        translate([0,-s/(2*tan(180/n)),0]) stick(s,t);

module entry(n,m,s,t) rotate_extrude(convexity=2,$fn=m)
        translate([s+s/(2*sin(180/n)),s/(2*tan(180/n))+t/2,0]) mul1(n,s,t);

//intersection() {
// entry(5,5,10,2);
// translate([50,0,0]) cube([100,100,100],center=true);
//}
// translate([-30,0,0]) entry(7,5,10,2);


module piSlice(n) scale([cos(180/n),sin(180/n),1]) unitTriangle();

module fourPi(n) for (i=[0:4*n-1]) rotate([0,0,i*90/n-((n%2==0)?45/n:0)]) piSlice(4*n);

// translate([-30,0,25]) cube([50,50,50],center=true);
// translate([30,0,0])
// scale([25,25,25*sqrt(2)])
// translate([0,0,1/sqrt(2)])
// rotate_extrude(convexity=1,$fn=5)
// intersection() {
// fourPi(7);
// translate([1,0,0]) scale([2,sqrt(2),1]) unitSquare();
// }

module unitSquare() square([1,1],center=true);
module unitCircle() circle(1,$fn=400);
module unitTriangle() polygon(points=[[0,0],[1,-1],[1,1]], paths=[[0,1,2]]);
module unitPip(n) difference() { unitTriangle(); translate([1+sqrt(n*n-1),0,0]) scale([n,n,1]) unitCircle(); }
module pipSlice(n) scale([cos(180/n),sin(180/n),1]) unitPip(n);
module fourPips(n) for (i=[0:4*n-1]) rotate([0,0,i*90/n-((n%2==0)?45/n:0)]) pipSlice(4*n);

// intersection() {
// union() {
// rotate([0,0,45]) translate([1,1,0]) scale([2,2,1]) unitSquare();
// rotate([0,0,45]) translate([-1,-1,0]) scale([2,2,1]) unitSquare();
// fourPips(1); }
// translate([1,0,0]) scale([2,sqrt(2),1]) unitSquare(); }

module staves(n) intersection() { union() { rotate([0,0,45]) translate([1,1,0]) scale([2,2,1]) unitSquare(); rotate([0,0,45]) translate([-1,-1,0]) scale([2,2,1]) unitSquare(); fourPips(n); } translate([1,0,0]) scale([2,sqrt(2),1]) unitSquare(); }

// staves(1);

module barrel(n) scale([25,25,25*sqrt(2)]) translate([0,0,1/sqrt(2)]) rotate_extrude(convexity=1,$fn=5) staves(n);

translate([-55,0,0]) barrel(1);
// translate([0,0,0]) barrel(2);
// translate([55,0,0]) barrel(3);

Reply | Threaded
Open this post in threaded view
|

Re: Long journey to no where...

Whosawhatsis
You can't subtract a 2D object from a 3D object. It appears to work in OpenCSG because OpenCSG can't actually render 2D objects, so it quietly extrudes them to 1mm or so thick. CGAL can render 2D shapes, so you'll have to do this extrusion manually for the boolean operations to make any sense to CGAL.

On Sunday, October 30, 2011 at 3:02 AM, Dan Zuras 3D wrote:



Folks,

After suggestions from both William Adams
<[hidden email]> & Whosawhatsis
<[hidden email]>, I spent some
time looking at using skeinforge to solve
my problem.

Recall, the task is to make 100 polygonal
objects to represent the entries in a 10x10
multiplication table as an aid to teaching
a 4-year old his math.

My original design involved toroidal polygons
with N segments around the major diameter &
M segments around the minor to represent the
problem NxM. The design exposed a minor bug
which both William & Whosawhatsis suggested
work arounds for.

One of those suggestions was to look into
making a skeinforge model that only printed
hollow objects with no top or bottom. After
some fooling around, I figured out how to do
1, 2, & 3 layer objects with no fill at all.

I have to thank you guys for that because I've
been trying to figure out how to do that ever
since I started spitting plastic.

(BTW, I would like to figure out a model that
can make 2 or 3 layer walls & a thick bottom
but no top. I'd like to make some cups for
Christmas presents & that sounds like the
ideal way. But that is a question for another
day.)

Anyway, this led me to redesigning my table
entry objects. I now make them as barrels
with N staves around the barrel & M from top
to bottom for the NxM entry. I even made an
actual 5x7 barrel.

Alas, while it is a beautifully light &
transparent object & looks nicely pentagonal
going around, you cannot see the 7 bottom to
top faces. They are even difficult to find
to the touch.

I thought, no big deal. We're still on the
right track. I'll make the faces slightly
concave so they are easy to see & feel.

And that's where I got bit by a CGAL problem
again.

The following code fragment illustrates the
problem. It renders fine under openCSG but
chokes under CGAL due to the following error:

ERROR: Illegal polygonal object - make sure
all polygons are defined with the same winding
order. Skipping affected object.

on the console & this one in stderr:

CGAL::Polyhedron_incremental_builder_3<HDS>::
lookup_hole(): input error: at vertex 1 a closed
surface already exists and facet 291 is nonetheless
adjacent.
The closed cycle of facets is: 232 0 58 116 174.

It is kind of understandable. After all, I
made the faces concave by taking a small bite
out of it with a circle. So that face is,
I'll say naturally, different from the others.

But that is a 2D object. It has not yet been
extruded. Is it reasonable for it to be said
to have a winding order at all?

Anyway, as always, I'm open to suggestions as
to how to proceed.

Thanks all,


Dan



module stick(s,t) union() {
translate([-s/2,0,0]) scale([t/2,t/2]) unitCircle();
translate([s/2,0,0]) scale([t/2,t/2]) unitCircle();
scale([s,t]) unitSquare();
}

module mul1(n,s,t) for (i=[1:n]) rotate([0,0,i*360/n])
translate([0,-s/(2*tan(180/n)),0]) stick(s,t);

module entry(n,m,s,t) rotate_extrude(convexity=2,$fn=m)
translate([s+s/(2*sin(180/n)),s/(2*tan(180/n))+t/2,0]) mul1(n,s,t);

//intersection() {
// entry(5,5,10,2);
// translate([50,0,0]) cube([100,100,100],center=true);
//}
// translate([-30,0,0]) entry(7,5,10,2);


module piSlice(n) scale([cos(180/n),sin(180/n),1]) unitTriangle();

module fourPi(n) for (i=[0:4*n-1]) rotate([0,0,i*90/n-((n%2==0)?45/n:0)]) piSlice(4*n);

// translate([-30,0,25]) cube([50,50,50],center=true);
// translate([30,0,0])
// scale([25,25,25*sqrt(2)])
// translate([0,0,1/sqrt(2)])
// rotate_extrude(convexity=1,$fn=5)
// intersection() {
// fourPi(7);
// translate([1,0,0]) scale([2,sqrt(2),1]) unitSquare();
// }

module unitSquare() square([1,1],center=true);
module unitCircle() circle(1,$fn=400);
module unitTriangle() polygon(points=[[0,0],[1,-1],[1,1]], paths=[[0,1,2]]);
module unitPip(n) difference() { unitTriangle(); translate([1+sqrt(n*n-1),0,0]) scale([n,n,1]) unitCircle(); }
module pipSlice(n) scale([cos(180/n),sin(180/n),1]) unitPip(n);
module fourPips(n) for (i=[0:4*n-1]) rotate([0,0,i*90/n-((n%2==0)?45/n:0)]) pipSlice(4*n);

// intersection() {
// union() {
// rotate([0,0,45]) translate([1,1,0]) scale([2,2,1]) unitSquare();
// rotate([0,0,45]) translate([-1,-1,0]) scale([2,2,1]) unitSquare();
// fourPips(1); }
// translate([1,0,0]) scale([2,sqrt(2),1]) unitSquare(); }

module staves(n) intersection() { union() { rotate([0,0,45]) translate([1,1,0]) scale([2,2,1]) unitSquare(); rotate([0,0,45]) translate([-1,-1,0]) scale([2,2,1]) unitSquare(); fourPips(n); } translate([1,0,0]) scale([2,sqrt(2),1]) unitSquare(); }

// staves(1);

module barrel(n) scale([25,25,25*sqrt(2)]) translate([0,0,1/sqrt(2)]) rotate_extrude(convexity=1,$fn=5) staves(n);

translate([-55,0,0]) barrel(1);
// translate([0,0,0]) barrel(2);
// translate([55,0,0]) barrel(3);
_______________________________________________
OpenSCAD mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Long journey to no where...

Dan Zuras 3D
> Date: Sun, 30 Oct 2011 04:04:27 -0700
> From: Whosawhatsis <[hidden email]>
> To: Dan Zuras 3D <[hidden email]>, [hidden email]
> Subject: Re: [OpenSCAD] Long journey to no where...
>
>
> You can't subtract a 2D object from a 3D object. It appears to work
> in OpenCSG because OpenCSG can't actually render 2D objects, so it
> quietly extrudes them to 1mm or so thick. CGAL can render 2D shapes,
> so you'll have to do this extrusion manually for the boolean operations
> to make any sense to CGAL.
>

        Well, as I'm subtracting a circle from a polygon
        (specifically a triangle), I thought I was subtracting
        one 2D object from another.  And CGAL never sees it
        until it is already extruded into 3D.

        But you must be right as the following snippet exhibits
        the problem:

module unitTriangle() polygon(points=[[0,0],[1,-1],[1,1]], paths=[[0,1,2]]);
module unitCircle() circle(1,$fn=400);
module unitPip(n) difference() { unitTriangle(); translate([1+sqrt(n*n-1),0,0]) scale([n,n,1]) unitCircle(); }
module pipSlice(n) scale([cos(180/n),sin(180/n),1]) unitPip(n);
rotate_extrude(convexity=1,$fn=5) pipSlice(4);

        OK, what is the work around for THIS one?

        Realize I'm not married to the notion of subtracting a
        circle from a triangle.  My goal is to make the faces
        of the solid stand out from one another & still be
        printable with a 1 layer wall.  So I tried nipping out
        the arc of the circle to make each face concave.  OK,
        so they stand in rather than stand out.  But anything
        similar will do.

        Any suggestions?

        Thanks,

                                Dan

Reply | Threaded
Open this post in threaded view
|

Re: Long journey to no where...

Whosawhatsis
Ah, I misunderstood your description of the problem and didn't look closely enough at the code to verify it.

You've definitely found a bug with the code you posted above. If you remove the rotate_extrude() statement from that code and render with OpenCSG, the object renders on the z=0 plane as I would expect (I extruded it to 0.001mm thickness, which made it appear much thinner in OpenCSG, to verify this. However, when I render the un-extruded polygon in CGAL, it appears slightly below this plane. This is very weird, and I have no idea where this error is being introduced, though I admit that I find your style of coding difficult to follow and to debug.

On Sunday, October 30, 2011 at 7:29 AM, Dan Zuras 3D wrote:

Date: Sun, 30 Oct 2011 04:04:27 -0700
From: Whosawhatsis <[hidden email]>
To: Dan Zuras 3D <[hidden email]>, [hidden email]
Subject: Re: [OpenSCAD] Long journey to no where...


You can't subtract a 2D object from a 3D object. It appears to work
in OpenCSG because OpenCSG can't actually render 2D objects, so it
quietly extrudes them to 1mm or so thick. CGAL can render 2D shapes,
so you'll have to do this extrusion manually for the boolean operations
to make any sense to CGAL.

Well, as I'm subtracting a circle from a polygon
(specifically a triangle), I thought I was subtracting
one 2D object from another. And CGAL never sees it
until it is already extruded into 3D.

But you must be right as the following snippet exhibits
the problem:

module unitTriangle() polygon(points=[[0,0],[1,-1],[1,1]], paths=[[0,1,2]]);
module unitCircle() circle(1,$fn=400);
module unitPip(n) difference() { unitTriangle(); translate([1+sqrt(n*n-1),0,0]) scale([n,n,1]) unitCircle(); }
module pipSlice(n) scale([cos(180/n),sin(180/n),1]) unitPip(n);
rotate_extrude(convexity=1,$fn=5) pipSlice(4);

OK, what is the work around for THIS one?

Realize I'm not married to the notion of subtracting a
circle from a triangle. My goal is to make the faces
of the solid stand out from one another & still be
printable with a 1 layer wall. So I tried nipping out
the arc of the circle to make each face concave. OK,
so they stand in rather than stand out. But anything
similar will do.

Any suggestions?

Thanks,

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Long journey to no where...

kintel
Administrator
In reply to this post by Dan Zuras 3D
On Oct 30, 2011, at 15:29 PM, Dan Zuras 3D wrote:

> module unitTriangle() polygon(points=[[0,0],[1,-1],[1,1]], paths=[[0,1,2]]);
> module unitCircle() circle(1,$fn=400);
> module unitPip(n) difference() { unitTriangle(); translate([1+sqrt(n*n-1),0,0]) scale([n,n,1]) unitCircle(); }
> module pipSlice(n) scale([cos(180/n),sin(180/n),1]) unitPip(n);
> rotate_extrude(convexity=1,$fn=5) pipSlice(4);
>
> OK, what is the work around for THIS one?
>

I'm pretty sure this is the same problem as the "horn torus" issue, see:
http://rocklinux.net/pipermail/openscad/2011-August/001421.html

The resulting 3D object has a single point in the middle (it touches itself) , so it's not longer a manifold surface, and CGAL barfs on that.

Two ways of fixing it, depending on what you want:
1) make a tiny hole in the middle:
 rotate_extrude(convexity=1,$fn=12) translate([0.1,0,0]) pipSlice(4);
2) eliminate the single point by giving it a thickness:
 rotate_extrude(convexity=1,$fn=12) translate([-0.1,0,0]) pipSlice(4);

 -Marius

PS! I guess you're using the 2011.06 version. In the github master, the error messages are changed since the "winding order" issue was often misleading.


Reply | Threaded
Open this post in threaded view
|

Re: Long journey to no where...

Dan Zuras 3D
In reply to this post by Whosawhatsis
> Date: Sun, 30 Oct 2011 08:04:24 -0700
> From: Whosawhatsis <[hidden email]>
> To: Dan Zuras 3D <[hidden email]>
> Cc: [hidden email]
> Subject: Re: [OpenSCAD] Long journey to no where...
>
>
> Ah, I misunderstood your description of the problem and didn't
> look closely enough at the code to verify it.
>
> You've definitely found a bug with the code you posted above.
> If you remove the rotate_extrude() statement from that code and
> render with OpenCSG, the object renders on the z=0 plane as I
> would expect (I extruded it to 0.001mm thickness, which made it
> appear much thinner in OpenCSG, to verify this. However, when I
> render the un-extruded polygon in CGAL, it appears slightly below
> this plane. This is very weird, and I have no idea where this
> error is being introduced, though I admit that I find your style
> of coding difficult to follow and to debug.

        Well part of that style is truncating the actual
        application to demonstrate the bug only.  Picking
        out just those parts looks funny out of context.

        But I take your point & if there is a style guide
        anywhere I'm willing to follow it.

        Or perhaps you refer to the use of "unit" objects
        in this code.  It is something I have been toying
        with lately.

        I noticed that OpenSCAD has an overlap in its
        capabilities between how one describes things like
        circles, squares, cubes, cylinders & the like with
        all the various parameters one has to fill out &
        one's ability to scale things independently in
        each dimension.  In a recent source I noticed that
        I was making a bunch of objects that only differed
        in their scales.  It was not only verbose but I was
        constantly stumbling over various bugs & typos of
        my own making.  So I made a canonical or "unit"
        object & just rescaled it every in every instance
        of its use.

        The idea is that every square (or rectangle) is
        really one square rescaled, translated, & rotated
        to taste.  As is every circle (or ellipse).  And
        cylinder.  And cube.  And so on.

        I suppose it looks obtuse in the code but after
        I came to that realization, it became much easier
        for me to get it right every time I needed another
        flavor of some canonical object.

        Still, you are correct in that a source is meant
        to be read as much as written.  So if there is a
        style that is more canonical than these objects,
        I am willing to follow it.


                            Dan

Reply | Threaded
Open this post in threaded view
|

Re: Long journey to no where...

Dan Zuras 3D
In reply to this post by kintel
> Subject: Re: [OpenSCAD] Long journey to no where...
> From: Marius Kintel <[hidden email]>
> Date: Sun, 30 Oct 2011 16:25:08 +0100
> Cc: Whosawhatsis <[hidden email]>
> To: Dan Zuras 3D <[hidden email]>,
>  [hidden email]
>
> On Oct 30, 2011, at 15:29 PM, Dan Zuras 3D wrote:
>
> > module unitTriangle() polygon(points=[[0,0],[1,-1],[1,1]], =
> paths=[[0,1,2]]);
> > module unitCircle() circle(1,$fn=400);
> > module unitPip(n) difference() { unitTriangle(); =
> translate([1+sqrt(n*n-1),0,0]) scale([n,n,1]) unitCircle(); }
> > module pipSlice(n) scale([cos(180/n),sin(180/n),1]) unitPip(n);
> > rotate_extrude(convexity=1,$fn=5) pipSlice(4);
> >
> > OK, what is the work around for THIS one?
> >
>
> I'm pretty sure this is the same problem as the "horn torus" issue, see:
> http://rocklinux.net/pipermail/openscad/2011-August/001421.html
>
> The resulting 3D object has a single point in the middle (it touches
> itself) , so it's not longer a manifold surface, and CGAL barfs on that.
>
> Two ways of fixing it, depending on what you want:
> 1) make a tiny hole in the middle:
>  rotate_extrude(convexity=1,$fn=12) translate([0.1,0,0])
> pipSlice(4);
> 2) eliminate the single point by giving it a thickness:
>  rotate_extrude(convexity=1,$fn=12) translate([-0.1,0,0])
> pipSlice(4);
>
>  -Marius

        I wouldn't be so sure of that.  I can entirely cover up
        that point in the middle as follows:

module unitSquare() square([1,1],center=true);
module unitTriangle() polygon(points=[[0,0],[1,-1],[1,1]], paths=[[0,1,2]]);
module unitCircle() circle(1,$fn=400);
module unitPip(n) difference() { unitTriangle(); translate([1+sqrt(n*n-1),0,0]) scale([n,n,1]) unitCircle(); }
module pipSlice(n) scale([cos(180/n),sin(180/n),1]) unitPip(n);

rotate_extrude(convexity=1,$fn=5) intersection() {
        union() {
                pipSlice(4);
                rotate([0,0,45]) translate([0,1,0]) scale([2,2,1])
                        unitSquare();
                rotate([0,0,-45]) translate([0,-1,0]) scale([2,2,1])
                        unitSquare();
        }
        translate([(sqrt(2)-1)/2,0,0]) scale([1,sqrt(2),1]) unitSquare();
}

        & still run into the problem.

>
> PS! I guess you're using the 2011.06 version. In the github master, the
> error messages are changed since the "winding order" issue was often
> misleading.
>

        I am using the 2011.06 version.  If you are recommending
        that I download a newer version, just which directory in
        github should I use?

        Thanks,

                                Dan

Reply | Threaded
Open this post in threaded view
|

Re: Long journey to no where...

Whosawhatsis
In reply to this post by Dan Zuras 3D
I'm not necessarily saying there's anything wrong with your style, just that it's hard for me to follow. For someone familiar with the language, the meaning of circle(1) is obvious, while you would have to locate the UnitCircle() module to make sure it means what it sounds like (and even if you know it does, the inclusion of the compound word makes the entire block of code that much more difficult to process at a glance).

BTW, are you aware that you can set the $fn variable globally, not just as an argument to a module? The global definition can then be overridden when calling an individual module.

On Sunday, October 30, 2011 at 10:02 AM, Dan Zuras 3D wrote:

Date: Sun, 30 Oct 2011 08:04:24 -0700
From: Whosawhatsis <[hidden email]>
To: Dan Zuras 3D <[hidden email]>
Subject: Re: [OpenSCAD] Long journey to no where...


Ah, I misunderstood your description of the problem and didn't
look closely enough at the code to verify it.

You've definitely found a bug with the code you posted above.
If you remove the rotate_extrude() statement from that code and
render with OpenCSG, the object renders on the z=0 plane as I
would expect (I extruded it to 0.001mm thickness, which made it
appear much thinner in OpenCSG, to verify this. However, when I
render the un-extruded polygon in CGAL, it appears slightly below
this plane. This is very weird, and I have no idea where this
error is being introduced, though I admit that I find your style
of coding difficult to follow and to debug.

Well part of that style is truncating the actual
application to demonstrate the bug only. Picking
out just those parts looks funny out of context.

But I take your point & if there is a style guide
anywhere I'm willing to follow it.

Or perhaps you refer to the use of "unit" objects
in this code. It is something I have been toying
with lately.

I noticed that OpenSCAD has an overlap in its
capabilities between how one describes things like
circles, squares, cubes, cylinders & the like with
all the various parameters one has to fill out &
one's ability to scale things independently in
each dimension. In a recent source I noticed that
I was making a bunch of objects that only differed
in their scales. It was not only verbose but I was
constantly stumbling over various bugs & typos of
my own making. So I made a canonical or "unit"
object & just rescaled it every in every instance
of its use.

The idea is that every square (or rectangle) is
really one square rescaled, translated, & rotated
to taste. As is every circle (or ellipse). And
cylinder. And cube. And so on.

I suppose it looks obtuse in the code but after
I came to that realization, it became much easier
for me to get it right every time I needed another
flavor of some canonical object.

Still, you are correct in that a source is meant
to be read as much as written. So if there is a
style that is more canonical than these objects,
I am willing to follow it.


Dan

Reply | Threaded
Open this post in threaded view
|

Re: Long journey to no where...

kintel
Administrator
In reply to this post by Dan Zuras 3D
On Oct 30, 2011, at 18:12 PM, Dan Zuras 3D wrote:
> I wouldn't be so sure of that.  I can entirely cover up
> that point in the middle as follows:
>
This looks like a different problem. With my build, the new code of yours doesn't trigger the CGAL error, it just results in nothing.
The reason for this is the following:

> union() {
> pipSlice(4);
> rotate([0,0,45]) translate([0,1,0]) scale([2,2,1])
> unitSquare();
> rotate([0,0,-45]) translate([0,-1,0]) scale([2,2,1])
> unitSquare();
> }

This creates a union of three disparate objects which actually doesn't overlap, but just touches. The uncertainty in the numbers cause the resulting union'ed 2D polygon to have a thin gap, which appears to cause problems later (self-intersection?). You can see this by looking at the CGAL rendering of that snippet - it will have a line segment poking into the object.
Change to e.g. pipSlice(3.9) to make them overlap and it should work again.

I realize that it's hard to debug such issues. Suggestions for improvement are welcome :)

As you're using a different version, you might experience slightly different problems. It might also be that I'm suppressing something which should be an error message in the current version.
For this specific issue, I'll go through and see if I can report a (meaningful) error message for it.

> I am using the 2011.06 version.  If you are recommending
> that I download a newer version, just which directory in
> github should I use?
>
On github, the master branch is always the most stable - that 's of course source code only.
For binaries, check "Download Development Snapshots" on openscad.org. These are updated whenever developers feel like it, but can probably be requested on this mailing list if they appear to be outdated.

You'll experience different bugs with the development version, but these need to be discovered anyway ;)

 -Marius