
12

> using STL than the difference between double precision and 'rational
> numbers'. Single precision is equivalent to just 67 significant digits.
But if you are speed obsessed you can just fixed point, which is more
stable, means all your operations occur on fixed sized cubes that don't
change with position, and is somewhat easier to vectorise, especially on
low end processors.
Alternatively you use the GPU to do the work.
Alan
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


nophead wrote
>>
>> CGAL may be slow, but the architects' decision to build on a rational
>> number representation had good reasons .
> Yes but OpenSCAD gains zero advantage from this because it converts back
> to
> doubles and snaps to a grid and then feeds the results back to CGAL.
I am aware that CGAL only internally gains advantage of this and that it
would be a large progress (and amount of work), if OpenSCAD didn't dismiss
CGAL representations when looping, respectively if OpenSCAD also supported
transformations in CGALrepresentation to avoid such conversions for all
intermediate steps. This would reduce the need of conversions to I/O
operations only.
What I don't know is, how many loops OpenSCAD actually uses when it renders
a design. So what happens exactly for
difference()
{
union() {A(); B();}
C();
}
with A(), B(), C() defined as modules with visual output? Will OpenSCAD
really convert the result of the
union twice before difference is called?
And here:
difference()
{
rotate(45)
union() {A(); B();}
C();
}
will OpenSCAD excute rotate in floating point representation?

Sent from: http://forum.openscad.org/_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


So the extended discussion of the internals is interesting and worthwhile but my original intent on the thread was to see if what I was doing made sense geometrically. Similar to the thread about taking apart the three cones that were joined. I later figured that since I was trying to join two things that were in different octants (which crossed over slightly at the end) would be to subtract a box that was in the other octant.
One concern I do have is that this makes 1/3 of my hallways and the rest would be made by 120 degree rotations. Earlier in this thread someone was noting that various rotations would give irrational numbers (maybe this isn't any worse than the standard floating point, because they are just implicitly 'rounded' into something nearby that isn't irrational?). How does one avoid doing a rotation operation which is "bad"? Is there a "safe" way to do rotations? nophead wrote
>>
>> CGAL may be slow, but the architects' decision to build on a rational
>> number representation had good reasons .
> Yes but OpenSCAD gains zero advantage from this because it converts back
> to
> doubles and snaps to a grid and then feeds the results back to CGAL.
I am aware that CGAL only internally gains advantage of this and that it
would be a large progress (and amount of work), if OpenSCAD didn't dismiss
CGAL representations when looping, respectively if OpenSCAD also supported
transformations in CGALrepresentation to avoid such conversions for all
intermediate steps. This would reduce the need of conversions to I/O
operations only.
What I don't know is, how many loops OpenSCAD actually uses when it renders
a design. So what happens exactly for
difference()
{
union() {A(); B();}
C();
}
with A(), B(), C() defined as modules with visual output? Will OpenSCAD
really convert the result of the
union twice before difference is called?
And here:
difference()
{
rotate(45)
union() {A(); B();}
C();
}
will OpenSCAD excute rotate in floating point representation?

Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


> ... So the extended discussion of the internals is interesting and
worthwhile but my original intent on the thread was to see if what I was
doing made sense geometrically. Similar to the thread about taking apart
the three cones that were joined. ...
The stuff in the original post doesn't seem correct to me. It seems like
you're confusing rotation by 180 degrees with reflection.
Can you try using:
"rotate (v=[0,1,0], a=180)"
instead of
"mirror([1,0,0])"
?

Sent from: http://forum.openscad.org/_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


The only exact rotations that can be relied on are by multiples of 90 degrees. If you rotate by 120 you get sqrt(0.75) factors in the matrix which are irrational.
will OpenSCAD excute rotate in floating point representation? Yes using matrices of doubles. > Will OpenSCAD really convert the result of the union twice before difference is called?
I think it depends if you have render anywhere and if you do an F5 before an F6. If you clear the cache and do F6 it tends to keep things in CGAL notation and give a cleaner result. So the extended discussion of the internals is interesting and worthwhile but my original intent on the thread was to see if what I was doing made sense geometrically. Similar to the thread about taking apart the three cones that were joined. I later figured that since I was trying to join two things that were in different octants (which crossed over slightly at the end) would be to subtract a box that was in the other octant.
One concern I do have is that this makes 1/3 of my hallways and the rest would be made by 120 degree rotations. Earlier in this thread someone was noting that various rotations would give irrational numbers (maybe this isn't any worse than the standard floating point, because they are just implicitly 'rounded' into something nearby that isn't irrational?). How does one avoid doing a rotation operation which is "bad"? Is there a "safe" way to do rotations?
nophead wrote
>>
>> CGAL may be slow, but the architects' decision to build on a rational
>> number representation had good reasons .
> Yes but OpenSCAD gains zero advantage from this because it converts back
> to
> doubles and snaps to a grid and then feeds the results back to CGAL.
I am aware that CGAL only internally gains advantage of this and that it
would be a large progress (and amount of work), if OpenSCAD didn't dismiss
CGAL representations when looping, respectively if OpenSCAD also supported
transformations in CGALrepresentation to avoid such conversions for all
intermediate steps. This would reduce the need of conversions to I/O
operations only.
What I don't know is, how many loops OpenSCAD actually uses when it renders
a design. So what happens exactly for
difference()
{
union() {A(); B();}
C();
}
with A(), B(), C() defined as modules with visual output? Will OpenSCAD
really convert the result of the
union twice before difference is called?
And here:
difference()
{
rotate(45)
union() {A(); B();}
C();
}
will OpenSCAD excute rotate in floating point representation?

Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


On 20190708 15:47, Alan Cox wrote:
>> using STL than the difference between double precision and 'rational
>> numbers'. Single precision is equivalent to just 67 significant
>> digits.
>
> But if you are speed obsessed you can just fixed point, which is more
> stable, means all your operations occur on fixed sized cubes that don't
> change with position, and is somewhat easier to vectorise, especially
> on
> low end processors.
>
> Alternatively you use the GPU to do the work.
>
> Alan
STL format has nothing to do with speed. You can use whatever method you
think will work (whether it does or not), but if you export to STL you
must adhere to the definition of that file format. In binary form that
means single precision with just 67 significant digits. This is
unrelated to computations employed, with or without obsessions.
Carsten Arnholm
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


Nate: what I was asking in the original post was how to take 1/6th of the hallway design my head and make 1/3. So yes it is a mirror operation. The best way to eliminate the stuff that overlapped the next octant turned out to be using a box.
After that I take that whole shape and need to displace it and rotate it by 120 (I need to do that twice).
Nop head: on the irrationals do I just get a rounding error or is there a more serious problem? If it is a more serious problem is it possible to avoid it? > ... So the extended discussion of the internals is interesting and
worthwhile but my original intent on the thread was to see if what I was
doing made sense geometrically. Similar to the thread about taking apart
the three cones that were joined. ...
The stuff in the original post doesn't seem correct to me. It seems like
you're confusing rotation by 180 degrees with reflection.
Can you try using:
"rotate (v=[0,1,0], a=180)"
instead of
"mirror([1,0,0])"
?

Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


You get rounding errors because it is impossible to represent exact rotations numerically on a digital computer. Of course it is accurate enough for real life but you can't rely vertex positions exactly meeting for example.
Even without rotations you can't accurately stack two 0.1mm blocks because 0.1 is a recurring fraction in binary. So it is safe to union two 1mm cubes without any overlap but not two 0.1mm cubes. One needs to understand how numbers work on a computer to be able to avoid problems. Nate: what I was asking in the original post was how to take 1/6th of the hallway design my head and make 1/3. So yes it is a mirror operation. The best way to eliminate the stuff that overlapped the next octant turned out to be using a box.
After that I take that whole shape and need to displace it and rotate it by 120 (I need to do that twice).
Nop head: on the irrationals do I just get a rounding error or is there a more serious problem? If it is a more serious problem is it possible to avoid it?
> ... So the extended discussion of the internals is interesting and
worthwhile but my original intent on the thread was to see if what I was
doing made sense geometrically. Similar to the thread about taking apart
the three cones that were joined. ...
The stuff in the original post doesn't seem correct to me. It seems like
you're confusing rotation by 180 degrees with reflection.
Can you try using:
"rotate (v=[0,1,0], a=180)"
instead of
"mirror([1,0,0])"
?

Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


Thanks nop head: I was just concerned because people were saying "barf" etc. Small errors, loss in precision, are acceptable to me. I just don't want a rotation to take a previously valid model and make it invalid. You get rounding errors because it is impossible to represent exact rotations numerically on a digital computer. Of course it is accurate enough for real life but you can't rely vertex positions exactly meeting for example.
Even without rotations you can't accurately stack two 0.1mm blocks because 0.1 is a recurring fraction in binary. So it is safe to union two 1mm cubes without any overlap but not two 0.1mm cubes. One needs to understand how numbers work on a computer to be able to avoid problems.
Nate: what I was asking in the original post was how to take 1/6th of the hallway design my head and make 1/3. So yes it is a mirror operation. The best way to eliminate the stuff that overlapped the next octant turned out to be using a box.
After that I take that whole shape and need to displace it and rotate it by 120 (I need to do that twice).
Nop head: on the irrationals do I just get a rounding error or is there a more serious problem? If it is a more serious problem is it possible to avoid it?
> ... So the extended discussion of the internals is interesting and
worthwhile but my original intent on the thread was to see if what I was
doing made sense geometrically. Similar to the thread about taking apart
the three cones that were joined. ...
The stuff in the original post doesn't seem correct to me. It seems like
you're confusing rotation by 180 degrees with reflection.
Can you try using:
"rotate (v=[0,1,0], a=180)"
instead of
"mirror([1,0,0])"
?

Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


Rotating a whole model doesn't usually cause problems but consider this: suppose you have a flat face and you union a cube with it. The intersection points will be exactly on the plane and so it remains a flat plane with a cube sticking out. Now rotate the plane so it is inclined. The intersection points probably can't be exactly on the plane because all its vertices are irrational. They will be the nearest grid points to where they should be put then the plane is no longer exactly flat. It has to be made with triangles. Whether that matters or not depends if you have some vertices that are very close and the rounding causes them to merge. For example if you have a knife edge it might collapse and become self intersecting. I think this is the reason CGAL uses rationals.
Even translating a model can cause it to break because as you move away from the origin floats get less accurate. So close vertices at the origin may merge when translated away from it. Thanks nop head: I was just concerned because people were saying "barf" etc. Small errors, loss in precision, are acceptable to me. I just don't want a rotation to take a previously valid model and make it invalid.
You get rounding errors because it is impossible to represent exact rotations numerically on a digital computer. Of course it is accurate enough for real life but you can't rely vertex positions exactly meeting for example.
Even without rotations you can't accurately stack two 0.1mm blocks because 0.1 is a recurring fraction in binary. So it is safe to union two 1mm cubes without any overlap but not two 0.1mm cubes. One needs to understand how numbers work on a computer to be able to avoid problems.
Nate: what I was asking in the original post was how to take 1/6th of the hallway design my head and make 1/3. So yes it is a mirror operation. The best way to eliminate the stuff that overlapped the next octant turned out to be using a box.
After that I take that whole shape and need to displace it and rotate it by 120 (I need to do that twice).
Nop head: on the irrationals do I just get a rounding error or is there a more serious problem? If it is a more serious problem is it possible to avoid it?
> ... So the extended discussion of the internals is interesting and
worthwhile but my original intent on the thread was to see if what I was
doing made sense geometrically. Similar to the thread about taking apart
the three cones that were joined. ...
The stuff in the original post doesn't seem correct to me. It seems like
you're confusing rotation by 180 degrees with reflection.
Can you try using:
"rotate (v=[0,1,0], a=180)"
instead of
"mirror([1,0,0])"
?

Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


On Mon, 08 Jul 2019 17:49:46 +0200
[hidden email] wrote:
> On 20190708 15:47, Alan Cox wrote:
> >> using STL than the difference between double precision and 'rational
> >> numbers'. Single precision is equivalent to just 67 significant
> >> digits.
> >
> > But if you are speed obsessed you can just fixed point, which is more
> > stable, means all your operations occur on fixed sized cubes that don't
> > change with position, and is somewhat easier to vectorise, especially
> > on
> > low end processors.
> >
> > Alternatively you use the GPU to do the work.
> >
> > Alan
>
> STL format has nothing to do with speed. You can use whatever method you
> think will work (whether it does or not), but if you export to STL you
> must adhere to the definition of that file format. In binary form that
> means single precision with just 67 significant digits. This is
> unrelated to computations employed, with or without obsessions.
Sure but that is the easy bit. Good STL exporters use a point dictionary.
It's not rocket science. Binary STL is not a good system in the first
place as you say.
Alan
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


DanS wrote
> Nate: what I was asking in the original post was how to take 1/6th of the
> hallway design my head and make 1/3. So yes it is a mirror operation.
> The
> best way to eliminate the stuff that overlapped the next octant turned out
> to be using a box.
>
> After that I take that whole shape and need to displace it and rotate it
> by
> 120 (I need to do that twice).
So you're trying to make something like a triangular pyramid but with ogee
profiles?

Sent from: http://forum.openscad.org/_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


Nate: it's not a pyramid, its a series of arched hallways. The form of the arch morphs between ogee and roman arch styles. The o. verall path of 1/3 of the hallways is in the shape of an ogee arch.
Once I finish with that I'll put in domes and decorative buttress works.
Nop head: given what you were saying about how if you had two things with an exact union, and then you rotated it and they came apart. I am wondering if I need to rethink how to make 1/3 of the archway. Since I intend to do it where I rotate it (and right now I'm using a box to exactly saw off what is in the next octant), I am thinking that for the ones I rotate I need to shift the bounding box so there is more overlap. But how much do I need? 1 unit, 0.5 units???? Any ideas? DanS wrote
> Nate: what I was asking in the original post was how to take 1/6th of the
> hallway design my head and make 1/3. So yes it is a mirror operation.
> The
> best way to eliminate the stuff that overlapped the next octant turned out
> to be using a box.
>
> After that I take that whole shape and need to displace it and rotate it
> by
> 120 (I need to do that twice).
So you're trying to make something like a triangular pyramid but with ogee
profiles?

Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


I usually use a 0.01 unit overlap, it really doesn't need to be much Nate: it's not a pyramid, its a series of arched hallways. The form of the arch morphs between ogee and roman arch styles. The o. verall path of 1/3 of the hallways is in the shape of an ogee arch.
Once I finish with that I'll put in domes and decorative buttress works.
Nop head: given what you were saying about how if you had two things with an exact union, and then you rotated it and they came apart. I am wondering if I need to rethink how to make 1/3 of the archway. Since I intend to do it where I rotate it (and right now I'm using a box to exactly saw off what is in the next octant), I am thinking that for the ones I rotate I need to shift the bounding box so there is more overlap. But how much do I need? 1 unit, 0.5 units???? Any ideas?
DanS wrote
> Nate: what I was asking in the original post was how to take 1/6th of the
> hallway design my head and make 1/3. So yes it is a mirror operation.
> The
> best way to eliminate the stuff that overlapped the next octant turned out
> to be using a box.
>
> After that I take that whole shape and need to displace it and rotate it
> by
> 120 (I need to do that twice).
So you're trying to make something like a triangular pyramid but with ogee
profiles?

Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


I use 1/128 because it is a round number in floating point. 0.01 is a recurring fraction. It probably doesn't make any difference in most cases, but seems like a good idea.
>Nop head: given what you were saying about how if you had two things with an exact union, and then you rotated it and they came apart.
They would only possibly come apart if you rotate them individually before the union. Rotating a unioned object should not break it, but it can perturb the vertices and make flat plans no longer exactly flat. I usually use a 0.01 unit overlap, it really doesn't need to be much
Nate: it's not a pyramid, its a series of arched hallways. The form of the arch morphs between ogee and roman arch styles. The o. verall path of 1/3 of the hallways is in the shape of an ogee arch.
Once I finish with that I'll put in domes and decorative buttress works.
Nop head: given what you were saying about how if you had two things with an exact union, and then you rotated it and they came apart. I am wondering if I need to rethink how to make 1/3 of the archway. Since I intend to do it where I rotate it (and right now I'm using a box to exactly saw off what is in the next octant), I am thinking that for the ones I rotate I need to shift the bounding box so there is more overlap. But how much do I need? 1 unit, 0.5 units???? Any ideas?
DanS wrote
> Nate: what I was asking in the original post was how to take 1/6th of the
> hallway design my head and make 1/3. So yes it is a mirror operation.
> The
> best way to eliminate the stuff that overlapped the next octant turned out
> to be using a box.
>
> After that I take that whole shape and need to displace it and rotate it
> by
> 120 (I need to do that twice).
So you're trying to make something like a triangular pyramid but with ogee
profiles?

Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


On Mon, Jul 08, 2019 at 05:13:15PM +0100, nop head wrote:
> You get rounding errors because it is impossible to represent exact
> rotations numerically on a digital computer. Of course it is accurate
> enough for real life but you can't rely vertex positions exactly meeting
> for example.
rotate (2) cube (10);
I have now represented a rotation with numbers (numerically) on a
digital computer (mine, yours currently in your Email program or maybe
browser).
But yes, that "2" represents 2 degrees, which for technical reasons
needs to be in radians ASAP. Then it becomes irrational. And most of
the vertices of the cube move to irrational coordinates.
For an example of "not exactly meeting":
Suppose I do something like:
rotate (30) {
for (i=[0:10:60])
rotate (i) cube (10);
}
now onthe last object you'd think it's rotated by 90 degrees but in fact
its 30+60. Each of which was at one point converted to radians, rounded to
the nearest double and then used to do trigonometry functions...
In fact in this case I know that 30 and 60 in radians will be rounded
precisely in the same direction: in floating point only the exponent
differs. Thus the tolerance on the 90 degrees is even larger. And now
that rotation is no longer precisely 90 degrees....
Roger.

** [hidden email] ** https://www.BitWizard.nl/ ** +31152049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brotherinlaw Phil. But unlike
Phil, this plan just might work.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


I have now represented a rotation with numbers (numerically) on a digital computer (mine, yours currently in your Email program or maybe browser).
I would say that is a symbolic representation like cos(30) or sqrt(3) /2. The numerical representation is 0.86602540378443864676372317075294........ On Mon, Jul 08, 2019 at 05:13:15PM +0100, nop head wrote:
> You get rounding errors because it is impossible to represent exact
> rotations numerically on a digital computer. Of course it is accurate
> enough for real life but you can't rely vertex positions exactly meeting
> for example.
rotate (2) cube (10);
I have now represented a rotation with numbers (numerically) on a
digital computer (mine, yours currently in your Email program or maybe
browser).
But yes, that "2" represents 2 degrees, which for technical reasons
needs to be in radians ASAP. Then it becomes irrational. And most of
the vertices of the cube move to irrational coordinates.
For an example of "not exactly meeting":
Suppose I do something like:
rotate (30) {
for (i=[0:10:60])
rotate (i) cube (10);
}
now onthe last object you'd think it's rotated by 90 degrees but in fact
its 30+60. Each of which was at one point converted to radians, rounded to
the nearest double and then used to do trigonometry functions...
In fact in this case I know that 30 and 60 in radians will be rounded
precisely in the same direction: in floating point only the exponent
differs. Thus the tolerance on the 90 degrees is even larger. And now
that rotation is no longer precisely 90 degrees....
Roger.

** [hidden email] ** https://www.BitWizard.nl/ ** +31152049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brotherinlaw Phil. But unlike
Phil, this plan just might work.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

12
