Limits to Polygon ordered pair resolution?
Is there a limit to the distance between ordered pairs when making polygons?
I am trying to get "smoother" polygons by making the ordered pairs closer
together but at a certain point what I get are "rougher" polygons.
At least that is what I think is the trouble. see code below and a table
showing the number of facets created.
What is happening?
-------------------------code-------------------------------------------------------
lenght=1;
step_size=0.04;
// function to create x^2 points up to d with increment size s
function pow2(d,s)=
[for(i=[0:s:d+s])
[i,pow(i,2)]
];
//this makes the actual points for the polygon
v1=pow2(lenght,step_size);//curve points
v2=[[0,pow(lenght,2)]];//end point
//this is the polygon
linear_extrude(height = 1,convexity = 10)polygon(concat(v1,v2));
//debug info
echo(v1);
echo(v2);
------------end
code--------------------------------------------------------------------
table showing the facet count decreases at 0.03 step size.
step size ending i value facets on polygon ordered pairs generated
0.1 1.1 11 10
0.09 1.08 12 13
0.08 1.04 13 14
0.07 1.05 15 16
0.06 1.02 17 18
0.05 1 20 21
0.04 1 20 26
0.03 1.02 16 35
0.02 1 13 51
0.01 1 7 101
0.009 1.008 7 113
0.008 1 6 126
0.007 1.001 5
0.006 1.002 5
0.005 1 4
0.004 1 3
0.003 1.002 4
0.002 1 5
0.001 1 2
It's a known bug. There is some code that attempts to reduce the complexity
of polygons with close together vertices, for performance reasons.
On Sunday, 15 January 2017, Mark Peeters peetersmarkg@gmail.com wrote:
Is there a limit to the distance between ordered pairs when making
polygons?
I am trying to get "smoother" polygons by making the ordered pairs closer
together but at a certain point what I get are "rougher" polygons.
At least that is what I think is the trouble. see code below and a table
showing the number of facets created.
What is happening?
-------------------------code-------------------------------
lenght=1;
step_size=0.04;
// function to create x^2 points up to d with increment size s
function pow2(d,s)=
[for(i=[0:s:d+s])
[i,pow(i,2)]
];
//this makes the actual points for the polygon
v1=pow2(lenght,step_size);//curve points
v2=[[0,pow(lenght,2)]];//end point
//this is the polygon
linear_extrude(height = 1,convexity = 10)polygon(concat(v1,v2));
//debug info
echo(v1);
echo(v2);
------------end code--------------------------
table showing the facet count decreases at 0.03 step size.
step size ending i value facets on polygon ordered pairs generated
0.1 1.1 11 10
0.09 1.08 12 13
0.08 1.04 13 14
0.07 1.05 15 16
0.06 1.02 17 18
0.05 1 20 21
0.04 1 20 26
0.03 1.02 16 35
0.02 1 13 51
0.01 1 7 101
0.009 1.008 7 113
0.008 1 6 126
0.007 1.001 5
0.006 1.002 5
0.005 1 4
0.004 1 3
0.003 1.002 4
0.002 1 5
0.001 1 2
On 15. jan. 2017 16:02, doug moen wrote:
It's a known bug. There is some code that attempts to reduce the
complexity of polygons with close together vertices, for performance
reasons.
A possibly related bug is the following:
-
Import an STL with some flat areas subdivided into smaller triangles.
Process it with F6, but don't perform any booleans. -
Export to STL and you get a copy of the original (as expected?).
-
Export to AMF and you get a completely different tessellation
I think the choice of export file format should not affect the resulting
tessellation.
The above example is slightly academic since there was no modification
to the model, but in this case the tessellation was significant and the
AMF export ruined it, I think that is a bug. More generally, it may be a
sign that some of the export logic is wrong.
Carsten Arnholm
On 01/15/2017 04:49 PM, Carsten Arnholm wrote:
A possibly related bug is the following:
Nope, this has absolutely nothing to do with eachother,
it's not even touching the same libraries for calculation.
Is this some kind of contest to confuse people who
have questions by digging out random other issues?
Sorry if that sounds a bit harsh, but I really wonder
why pretty much every thread asking for some kind of
issue goes into that direction lately.
Otherwise, here's the issue to follow that relates to
the original question:
https://github.com/openscad/openscad/issues/999
ciao,
Torsten.
Not only a bug, it's a bad regression, but still hangs around for more than
2 years.
On 15 January 2017 at 16:01, Torsten Paul Torsten.Paul@gmx.de wrote:
On 01/15/2017 04:49 PM, Carsten Arnholm wrote:
A possibly related bug is the following:
Nope, this has absolutely nothing to do with eachother,
it's not even touching the same libraries for calculation.
Is this some kind of contest to confuse people who
have questions by digging out random other issues?
Sorry if that sounds a bit harsh, but I really wonder
why pretty much every thread asking for some kind of
issue goes into that direction lately.
Otherwise, here's the issue to follow that relates to
the original question:
https://github.com/openscad/openscad/issues/999
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 01/15/2017 05:14 PM, nop head wrote:
Not only a bug, it's a bad regression, but still hangs around
for more than 2 years.
Yes, that's not nice, but it's not like there's a 10 people team
working on OpenSCAD full time.
It would be awesome to get the issue count down, but that means
someone has to find the time and motivation for this. Currently
I don't have much spare time and the motivation is pretty down
too.
ciao,
Torsten.
On 15. jan. 2017 17:01, Torsten Paul wrote:
On 01/15/2017 04:49 PM, Carsten Arnholm wrote:
A possibly related bug is the following:
Nope, this has absolutely nothing to do with eachother,
it's not even touching the same libraries for calculation.
Is this some kind of contest to confuse people who
have questions by digging out random other issues?
Don't be rude.
I thought it could be related, that's why. If it is not, then fine. No
reason to throw insults. If you are not interested in what I said,
never mind.
Carsten Arnholm
Thanks Torsten,
that link is the perfect explanation to what is happening. I was scaling it
after making the polygon, so I will rework my code to not use scaling.
Kind Regards,
Mark
On Sun, Jan 15, 2017 at 11:01 AM, Torsten Paul Torsten.Paul@gmx.de wrote:
Otherwise, here's the issue to follow that relates to
the original question:
https://github.com/openscad/openscad/issues/999
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 01/15/2017 05:33 PM, Carsten Arnholm wrote:
If you are not interested in what I said, never mind.
I am interested in bug reports, the preferred place for those
is github though. Otherwise there's a high probability of them
just getting lost after a couple of weeks sitting in some mailing
list thread.
See https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#How_do_I_report_bugs.3F
ciao,
Torsten.
On 15. jan. 2017 17:59, Torsten Paul wrote:
On 01/15/2017 05:33 PM, Carsten Arnholm wrote:
If you are not interested in what I said, never mind.
I am interested in bug reports, the preferred place for those
is github though. Otherwise there's a high probability of them
just getting lost after a couple of weeks sitting in some mailing
list thread.
See https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#How_do_I_report_bugs.3F
ciao,
Torsten.
"If you are not sure it's a bug, asking on the mailing list/forum can
help clarifying things."
Carsten Arnholm