Confused as how a this could happen
I was writing a module to replace rotate_extrude() so that I could deal with
the issue that I mentioned in the Does rotate_extrude angle property allow
for values that don't divide 360 evenly?
http://forum.openscad.org/Does-rotate-extrude-angle-property-allow-for-values-that-don-t-divide-360-evenly-td19835.html
thread. However, I got some weird error which I can only describe as a
rounding error, but I am not exactly positive that it is.
Here is the full executable code:
and this is what I'm getting at the interface between the rotate_extrude()
and the extrude_end_segments():
http://forum.openscad.org/file/n19958/rounding_error.png
Note that the extrude_end_segments() is producing an object that is not the
same size as the rotate_extrude(). However, since these are only supposed
to be rotations, should there be that much of a change in size? Looks to be
in the 1-0.1 unit range. Is this indeed a rounding error?
Thanks,
A
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 2017-01-09 03:51, adrian wrote:
I was writing a module to replace rotate_extrude() so that I could deal
with
the issue that I mentioned in the Does rotate_extrude angle property
allow
for values that don't divide 360 evenly?
I don't understand the premise of the problem. Where does this idea of
"values that don't divide 360 evenly" come from? That is just weird.
There is no such limitation, or at least there should not be. The only
thing is that in versions prior to 2016.xx, the angle parameter is
silently ignored and assumed to be 360.
Just use whatever angle you want with rotate_extrude. Granted, I have
not tried OpenSCAD 2016.xx yet, so if there is an issue it should be
identified and fixed. I think a simple example demonstrating the problem
should be provided, for example:
rotate_extrude(angle=57.295779513082320876798154814105)
translate([50,0,0]) circle(10);
Doesn't it work in 2016.xx ?
Carsten Arnholm
cacb wrote
rotate_extrude(angle=57.295779513082320876798154814105)
translate([50,0,0]) circle(10);
Doesn't it work in 2016.xx ?
well, you won't get more than 7 digits (single) or so resolved, but of
course it works.
Where is the problem to download a 2016.xx and test it?
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958p19963.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 2017-01-09 11:17, Parkinbot wrote:
Where is the problem to download a 2016.xx and test it?
The problem is not here. I have been using other software recently...
:-) I just figured the link to 2016.xx was at the bottom of the download
page. As could be expected my little example works, so the whole issue
is a non-problem.
Carsten Arnholm
cacb wrote
the whole issue is a non-problem.
Yes and no. A solution based on sweep() can easily be extended to something
more general than just a rotate_extrude. Remember our discussion about
threads http://www.thingiverse.com/thing:1659079 .
Adrian, this is your code using 2016.xx, some odd angle and an arbitrary
resolution.
rotate_extrude(angle = 42.234, $fn = 200) arrow_2d(1, .5, .25);
module arrow_2d(l,w,a) polygon([[0,0],[w,0],[w,l-a],[w*1.3,l-a],[0,l]]);
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958p19965.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 2017-01-09 12:07, Parkinbot wrote:
cacb wrote
the whole issue is a non-problem.
Yes and no. A solution based on sweep() can easily be extended to
something
more general than just a rotate_extrude. Remember our discussion about
threads http://www.thingiverse.com/thing:1659079 .
The non-problem referred to the value of the angle parameter.
Sure, a general sweep would be extremely useful, I agree. However, when
talking specifically about threads, one can imagine extending
rotate_extrude to take a pitch parameter and allow angles spanning
several whole revolutions. The model below was created using my own
variant of rotate_extrude (on top of carve), rotating 15*360 degrees and
with a suitable pitch. It is smart enough to protest if self
intersections will occur, so in practice it works.
http://www.thingiverse.com/thing:1445033
Carsten Arnholm
cacb wrote
On 2017-01-09 03:51, adrian wrote:
I was writing a module to replace rotate_extrude() so that I could deal
with
the issue that I mentioned in the Does rotate_extrude angle property
allow
for values that don't divide 360 evenly?
I don't understand the premise of the problem. Where does this idea of
"values that don't divide 360 evenly" come from? That is just weird.
There is no such limitation, or at least there should not be. The only
thing is that in versions prior to 2016.xx, the angle parameter is
silently ignored and assumed to be 360.
The premise is that $fn must be an integer, so you cannot have a
rotate_extrude produce an extrusion that doesn't result in a whole number of
angled segments.
cacb wrote
Just use whatever angle you want with rotate_extrude. Granted, I have
not tried OpenSCAD 2016.xx yet, so if there is an issue it should be
identified and fixed. I think a simple example demonstrating the problem
should be provided, for example:
rotate_extrude(angle=57.295779513082320876798154814105)
translate([50,0,0]) circle(10);
Doesn't it work in 2016.xx ?
I never got a clear answer if the angle of the extrusion would have a
complete, 100% scaled, 2d representation of the original on either end of
the extrusion.
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958p19976.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Parkinbot wrote
Where is the problem to download a 2016.xx and test it?
I've not bothered as yet because afaik, I would have to build it and I'm
just too lazy.
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958p19977.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
cacb wrote
On 2017-01-09 11:17, Parkinbot wrote:
Where is the problem to download a 2016.xx and test it?
The problem is not here. I have been using other software recently...
:-) I just figured the link to 2016.xx was at the bottom of the download
page. As could be expected my little example works, so the whole issue
is a non-problem.
Good to know about that. Never bothered to go down the page recently. I'll
try it out. :)
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958p19978.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
adrian wrote
The premise is that $fn must be an integer, so you cannot have a
rotate_extrude produce an extrusion that doesn't result in a whole number
of angled segments.
Your premise is wrong. You may assign a fraction value to $fn: it will be
adjusted to an integer (with floor, I guess). If an angle is specified in
rotate_extrude, $fn is adjusted in order to ensure that the total angle is
met. See this example from above and bellow to confirm a perfect match:
color("blue")
translate([0,0,-7])
rotate_extrude(r=10, $fn=14.5)
translate([10,0]) square(5,center=true);
rotate_extrude(r=10, angle=360/7, $fn=14)
translate([10,0]) square(5,center=true);
color("red")
translate([0,0,7])
rotate_extrude(r=10, angle=360/7, $fn=18.5)
translate([10,0]) square(5,center=true);
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958p19980.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Ronaldo wrote
adrian wrote
The premise is that $fn must be an integer, so you cannot have a
rotate_extrude produce an extrusion that doesn't result in a whole number
of angled segments.
Your premise is wrong. You may assign a fraction value to $fn: it will be
adjusted to an integer (with floor, I guess). If an angle is specified in
rotate_extrude, $fn is adjusted in order to ensure that the total angle is
met. See this example from above and bellow to confirm a perfect match:
My premise wasn't wrong, but my wording was. ;) Yes, I know that $fn can be
a floating point number, but it will be coerced into a integer in the
context that I was referring to.
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958p19981.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 2017-01-09 15:00, adrian wrote:
cacb wrote
The premise is that $fn must be an integer, so you cannot have a
rotate_extrude produce an extrusion that doesn't result in a whole
number of
angled segments.
When you cut a cake, you will always get a whole number of slices, there
is simply no other way....
Carsten Arnholm
So given the following:
I would get this:
http://forum.openscad.org/file/n19983/my-rotate-extrude.png
Changing the last parameter in test1() to false, I would get this:
http://forum.openscad.org/file/n19983/2016-rotate-extrude.png
If you notice, in my implementation, the extrusion is broken up into 6
parts, 4 of which are 10 degrees in size and the other 2, the remaining 2
being 2.3/2 (1.15) in size. In the builtin, it is only 4 segments,
presumably 10.575 degrees in size.
I'm not saying anything is wrong with that, even if you can't control the
maximum rotation segment angle, but there is still a matter of the fit of my
implementation that I find odd. AFAICS, this should fit properly and I'm
trying to confirm that this is due to a rounding error or not.
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958p19983.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
cacb wrote
On 2017-01-09 15:00, adrian wrote:
cacb wrote
The premise is that $fn must be an integer, so you cannot have a
rotate_extrude produce an extrusion that doesn't result in a whole
number of
angled segments.
When you cut a cake, you will always get a whole number of slices, there
is simply no other way....
Depends on your definition of "whole". You can't get half a piece as each
piece is a whole piece, but there is no stipulation that each piece must be
exactly the same size. I could cut it into 10 slices of totally different
sizes.
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958p19984.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
adrian wrote
cacb wrote
On 2017-01-09 15:00, adrian wrote:
cacb wrote
The premise is that $fn must be an integer, so you cannot have a
rotate_extrude produce an extrusion that doesn't result in a whole
number of
angled segments.
When you cut a cake, you will always get a whole number of slices, there
is simply no other way....
Depends on your definition of "whole". You can't get half a piece as each
piece is a whole piece, but there is no stipulation that each piece must
be exactly the same size. I could cut it into 10 slices of totally
different sizes.
In any case, this question has gone beyond the original. I'm trying to
determine why there seems to be fitting errors and if they are due to
something I did or just rounding errors.
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958p19985.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
I was writing a module to replace rotate_extrude() so that I could deal
with the issue that I mentioned in the Does rotate_extrude angle property
allow for values that don't divide 360 evenly?
http://forum.openscad.org/Does-rotate-extrude-angle-property-allow-for-values-that-don-t-divide-360-evenly-td19835.html
thread.
I still don't understand what your original issue is so I can't understand
what your replacement module is trying to do.
The angle value for rotate_extruder does not need to divide evenly into
360. The end of the object should have exactly the angle you specify. Is
that the not the case? Or is it something to do with how $fn creates the
facets that you find wrong?
On 9 January 2017 at 15:29, adrian adrianh.bsc@gmail.com wrote:
adrian wrote
cacb wrote
On 2017-01-09 15:00, adrian wrote:
cacb wrote
The premise is that $fn must be an integer, so you cannot have a
rotate_extrude produce an extrusion that doesn't result in a whole
number of
angled segments.
When you cut a cake, you will always get a whole number of slices, there
is simply no other way....
Depends on your definition of "whole". You can't get half a piece as
each
piece is a whole piece, but there is no stipulation that each piece must
be exactly the same size. I could cut it into 10 slices of totally
different sizes.
In any case, this question has gone beyond the original. I'm trying to
determine why there seems to be fitting errors and if they are due to
something I did or just rounding errors.
--
View this message in context: http://forum.openscad.org/
Confused-as-how-a-this-could-happen-tp19958p19985.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
The original issue is no longer an issue. Turns out that it will force the
correct angle segment size in 2016 which is close to 360/$fn such that it
will evenly divide the sweeping angle.
I was in 2015 so there wasn't an angle parameter, so I was trying to make
something that would do the same thing. That is what the above programme
does. The issue that I am pointing out here is only related to that thread
because that is how this started. Ignore that thread now.
The issue that I am having is that I am trying to determine why the code
that I wrote doesn't result in sections that fit together exactly. Is this
not working because the multiple transforms are causing the coordinate of
the objects to drift enough to see the issue that can be seen in the above
images where the surfaces are out of alignment?
Thanks,
A
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958p19987.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Adding a # to extrude_end_segments shows that they overlap the middle of the
object, angle wise. So I think that might be why there is a step radially.
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958p19991.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
I am struggling to understand why it is so complicated. Why do you do the
end bits separately and not just intersect some oversized wedges with
rotate_extrude?
On 9 January 2017 at 19:35, nophead nop.head@gmail.com wrote:
Adding a # to extrude_end_segments shows that they overlap the middle of
the
object, angle wise. So I think that might be why there is a step radially.
--
View this message in context: http://forum.openscad.org/
Confused-as-how-a-this-could-happen-tp19958p19991.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Something like this ?:
module pie_slice(r, start_angle, end_angle) {
R = r * sqrt(2) + 1;
a0 = (4 * start_angle + 0 * end_angle) / 4;
a1 = (3 * start_angle + 1 * end_angle) / 4;
a2 = (2 * start_angle + 2 * end_angle) / 4;
a3 = (1 * start_angle + 3 * end_angle) / 4;
a4 = (0 * start_angle + 4 * end_angle) / 4;
if(end_angle > start_angle)
intersection() {
circle(r);
polygon([
[0,0],
[R * cos(a0), R * sin(a0)],
[R * cos(a1), R * sin(a1)],
[R * cos(a2), R * sin(a2)],
[R * cos(a3), R * sin(a3)],
[R * cos(a4), R * sin(a4)],
]);
}
}
$fn = 32;
module rotate_extrude_angle(angle, radius, convexity)
intersection() {
rotate_extrude(convexity = convexity)
children();
hull()
linear_extrude(height = 1, convexity = convexity)
pie_slice(radius, 0, angle);
}
rotate_extrude_angle(angle=45, radius=1, convexity=5)
arrow_2d(1, .5, .25);
module arrow_2d(l,w,a)
{
polygon([[0,0],[w,0],[w,l-a],[w*1.3,l-a],[0,l]]);
}
On 9 January 2017 at 20:58, nop head nop.head@gmail.com wrote:
I am struggling to understand why it is so complicated. Why do you do the
end bits separately and not just intersect some oversized wedges with
rotate_extrude?
On 9 January 2017 at 19:35, nophead nop.head@gmail.com wrote:
Adding a # to extrude_end_segments shows that they overlap the middle of
the
object, angle wise. So I think that might be why there is a step radially.
--
View this message in context: http://forum.openscad.org/Conf
used-as-how-a-this-could-happen-tp19958p19991.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Simple solution indeed. And easier to understand. I guess the hull() is an
innocuous remaining of a previous version.
On 09. jan. 2017 22:19, nop head wrote:
Something like this ?:
$fn=8*4;
rotate_extrude(angle=45)
union() {
square([.5,.75]);
polygon([[0,.75],[.65,.75],[0,1]]);
}
Carsten Arnholm
Yes but Adrian said he has a version before rotate_extrude takes an angle.
And easier to understand. I guess the hull() is an innocuous remaining of
On 09. jan. 2017 22:19, nop head wrote:
Something like this ?:
$fn=8*4;
rotate_extrude(angle=45)
union() {
square([.5,.75]);
polygon([[0,.75],[.65,.75],[0,1]]);
}
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
If @adrian is worried out getting whole segments then why not use $fa,
while setting $fs to a very small number?
On 9 January 2017 at 23:31, nop head nop.head@gmail.com wrote:
Yes but Adrian said he has a version before rotate_extrude takes an angle.
And easier to understand. I guess the hull() is an innocuous remaining of
On 09. jan. 2017 22:19, nop head wrote:
Something like this ?:
$fn=8*4;
rotate_extrude(angle=45)
union() {
square([.5,.75]);
polygon([[0,.75],[.65,.75],[0,1]]);
}
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nophead,
You already calculated the new radius. With this pie_slice() doesn't need
more than the intersection of a circle with a triag. Also negative angles
may be allowed.
module pie_slice(r, start_angle, end_angle)
intersection() {
circle(r);
polygon((r * sqrt(2) + 1)*[ [0,0],[cos(start_angle),
sin(start_angle)], [cos(end_angle), sin(end_angle)]]);
}
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958p19998.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
You cant get more than 180 degrees of a pie with a triangle intersection
and its radius would tend towards infinity. I think 4 triangles is the
least needed for an angle close to 360 without the radius getting very
large.
The version I presented works up to 360. I wrote it long before
rotate_extrude took an angle and before list comprehensions and offset.
On 10 January 2017 at 10:58, Parkinbot rudolf@parkinbot.com wrote:
nophead,
You already calculated the new radius. With this pie_slice() doesn't need
more than the intersection of a circle with a triag. Also negative angles
may be allowed.
module pie_slice(r, start_angle, end_angle)
intersection() {
circle(r);
polygon((r * sqrt(2) + 1)*[ [0,0],[cos(start_angle),
sin(start_angle)], [cos(end_angle), sin(end_angle)]]);
}
--
View this message in context: http://forum.openscad.org/
Confused-as-how-a-this-could-happen-tp19958p19998.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 9 January 2017 at 21:19, nop head nop.head@gmail.com wrote:
Something like this ?:
module pie_slice(r, start_angle, end_angle) {
R = r * sqrt(2) + 1;
a0 = (4 * start_angle + 0 * end_angle) / 4;
a1 = (3 * start_angle + 1 * end_angle) / 4;
a2 = (2 * start_angle + 2 * end_angle) / 4;
a3 = (1 * start_angle + 3 * end_angle) / 4;
a4 = (0 * start_angle + 4 * end_angle) / 4;
if(end_angle > start_angle)
intersection() {
circle(r);
polygon([
[0,0],
[R * cos(a0), R * sin(a0)],
[R * cos(a1), R * sin(a1)],
[R * cos(a2), R * sin(a2)],
[R * cos(a3), R * sin(a3)],
[R * cos(a4), R * sin(a4)],
]);
}
}
That looks like a similar approach to something I did to make short arcs of
tube. It boils down to making a torus by rotate_extruding a circle,
subtracting a thinner torus to make a hollow one then intersecting with the
output of this module, which produces an 8-sided wedge (which becomes a
hexagon when ang=360) by linear_extruding a polygon.
module wedge (thickness, rad, ang)
translate ([0,0,-(thickness/2)-1]) {
linear_extrude (height = thickness+2) {
polygon(points=[
[radcos(ang/2),-radsin(ang/2)],
[0,0],
[radcos(ang/2),radsin(ang/2)],
[radcos(ang/3),radsin(ang/3)],
[radcos(ang/6),radsin(ang/6)],
[rad,0],
[radcos(ang/6),-radsin(ang/6)],
[radcos(ang/3),-radsin(ang/3)]],
paths=[[0,1,2,3,4,5,6,7]]);}
}
Just remember to make rad big enough that the wedge will totally enclose
the object to be rotate_extruded.
Ian
--
Stand firm for what you believe in, until and unless logic and experience
prove you wrong. Remember: when the emperor looks naked, the emperor is
naked, the truth and a lie are not "sort-of the same thing" and there is
no aspect, no facet, no moment of life that can't be improved with pizza.
-Daria Morgendorffer
Yes but since rotate extrude now takes an angle these workarounds are just
an exercise.
On 10 January 2017 at 13:59, Ian Nichols ian.a.nichols@gmail.com wrote:
On 9 January 2017 at 21:19, nop head nop.head@gmail.com wrote:
Something like this ?:
module pie_slice(r, start_angle, end_angle) {
R = r * sqrt(2) + 1;
a0 = (4 * start_angle + 0 * end_angle) / 4;
a1 = (3 * start_angle + 1 * end_angle) / 4;
a2 = (2 * start_angle + 2 * end_angle) / 4;
a3 = (1 * start_angle + 3 * end_angle) / 4;
a4 = (0 * start_angle + 4 * end_angle) / 4;
if(end_angle > start_angle)
intersection() {
circle(r);
polygon([
[0,0],
[R * cos(a0), R * sin(a0)],
[R * cos(a1), R * sin(a1)],
[R * cos(a2), R * sin(a2)],
[R * cos(a3), R * sin(a3)],
[R * cos(a4), R * sin(a4)],
]);
}
}
That looks like a similar approach to something I did to make short arcs
of tube. It boils down to making a torus by rotate_extruding a circle,
subtracting a thinner torus to make a hollow one then intersecting with the
output of this module, which produces an 8-sided wedge (which becomes a
hexagon when ang=360) by linear_extruding a polygon.
module wedge (thickness, rad, ang)
translate ([0,0,-(thickness/2)-1]) {
linear_extrude (height = thickness+2) {
polygon(points=[
[radcos(ang/2),-radsin(ang/2)],
[0,0],
[radcos(ang/2),radsin(ang/2)],
[radcos(ang/3),radsin(ang/3)],
[radcos(ang/6),radsin(ang/6)],
[rad,0],
[radcos(ang/6),-radsin(ang/6)],
[radcos(ang/3),-radsin(ang/3)]],
paths=[[0,1,2,3,4,5,6,7]]);}
}
Just remember to make rad big enough that the wedge will totally enclose
the object to be rotate_extruded.
Ian
--
Stand firm for what you believe in, until and unless logic and experience
prove you wrong. Remember: when the emperor looks naked, the emperor is
naked, the truth and a lie are not "sort-of the same thing" and there is
no aspect, no facet, no moment of life that can't be improved with pizza.
-Daria Morgendorffer
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Sorry, of course you are right ...
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958p20003.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Hi @nophead,
I'll have to take a look at your solution later to see what you've done.
However, I have discovered the reason for the issue I was having. The wedge
extrude when centred around the xy plane, was too big.The problem was that
the ends were not scaled on the x-axis properly to make the end faces fit.
Here is my solution (I updated the module comment to show how width is
calculated and added a comment in module where the change was made):
This will make the pieces fit perfectly.
--
View this message in context: http://forum.openscad.org/Confused-as-how-a-this-could-happen-tp19958p20004.html
Sent from the OpenSCAD mailing list archive at Nabble.com.