strange polygon() behaviour in small scale

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

strange polygon() behaviour in small scale

Parkinbot
I know OpenSCAD has some problems when small scales come into play. Nevertheless, this result astounds me. Looks like polygon() tries to simply its points using some Voronoi magic.

polygon(circ(1));
translate([2, 0]) polygon(circ(.01));

function circ(step=1) = [for(i=[0:step:360])  [sin(i), cos(i)]];
Reply | Threaded
Open this post in threaded view
|

Re: strange polygon() behaviour in small scale

nophead
Yes, it's completely bonkers. As step reduces you get more facets until about 2 then they reduce again. circ(0.001) is a square!
Reply | Threaded
Open this post in threaded view
|

Re: strange polygon() behaviour in small scale

thehans
As a workaround you can scale your points up, then back down like this:

scale(1e-6) polygon(circ(1));
translate([2, 0]) scale(1e-6) polygon(circ(0.01));

function circ(step=1) = [for(i=[0:step:360])  [1e6*sin(i), 1e6*cos(i)]];


On Sat, May 21, 2016 at 8:09 AM, nophead <[hidden email]> wrote:
Yes, it's completely bonkers. As step reduces you get more facets until about
2 then they reduce again. circ(0.001) is a square!



--
View this message in context: http://forum.openscad.org/strange-polygon-behaviour-in-small-scale-tp17390p17391.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: strange polygon() behaviour in small scale

Parkinbot
@thehans: stability around 1 should be granted, as many (vector based) problems have normalized approaches. I tracked the effect down to a simplistic example from a much more sophisticated context. But be honest: You don't wanna use a workaround like yours in every second function of a sophisticated context.

I'd rather prefer this form, which I would expect polygon() could do itself ...  

 
factor = 1e4;
scale([1e-4, 1e-4]) polygon(1e4*circ(.01));

function circ(step=1) = [for(i=[0:step:360])   [sin(i), cos(i)]];
<quote author="thehans">
As a workaround you can scale your points up, then back down like this:

scale(1e-6) polygon(circ(1));
translate([2, 0]) scale(1e-6) polygon(circ(0.01));

function circ(step=1) = [for(i=[0:step:360])  [1e6*sin(i), 1e6*cos(i)]];


Reply | Threaded
Open this post in threaded view
|

Re: strange polygon() behaviour in small scale

cacb
In reply to this post by Parkinbot
On 21. mai 2016 14:37, Parkinbot wrote:

> I know OpenSCAD has some problems when small scales come into play.
> Nevertheless, this result astounds me. Looks like polygon() tries to simply
> its points using some Voronoi magic.
>
>
>> polygon(circ(1));
>> translate([2, 0]) polygon(circ(.01));
>>
>> function circ(step=1) = [for(i=[0:step:360])  [sin(i), cos(i)]];
>
> <http://forum.openscad.org/file/n17390/polygons.png>


The explanation for this behaviour is clear. A 2d shape like polygon is
tessellated using integer coordinates. There is no infinite precision,
and in fact not even floating point precision. As you use smaller and
smaller (floating point) steps, more and more neighbouring points end up
having identical integer coordinates during tessellation.

There is a silent built-in assumption of model scale in 2d tessellation
and thus an assumption of minimum point separation. In your case, this
assumption of minimum point separation breaks down. You would still
expect some kind of uniform distribution and not what you got, so there
is probably more to the story, but that's another issue.

As mentioned elsewhere, a work around is to scale up the coordinates
enough to get unique integer coordinates during tessellation, then scale
down the resulting shape afterwards, for example:

f = 10;
scale(1/f)polygon(circ(1));
translate([2, 0]) scale(1/f) polygon(circ(1/f));

function circ(step=1) = [for(i=[0:step:360]) [f*sin(i), f*cos(i)]];


Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: strange polygon() behaviour in small scale

tp3
The issue is known for some time, it's simply the problem nobody
found the time to fix it yet.

https://github.com/openscad/openscad/issues/999

ciao,
  Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: strange polygon() behaviour in small scale

Parkinbot
Torsten, thanx for the link. Seems to be another brillant example of a time consuming but effectless discussion.

My opinion is, that if I call polygon() with a points argument containing N points, I want to have a polygon with N points and not even one less.

A reasonable grain control should at least enforce some minimum grid or distance (max or even Euclidean norm) so that one would end up with some maximum number of points in my example. The implemented "the more you put in, the less you get out" scheme is a clear bug.

Rudolf
 
Reply | Threaded
Open this post in threaded view
|

Re: strange polygon() behaviour in small scale

nophead
Not only a huge bug but also a regression. Polygon used to work before the 2D subsystem was re-written to not use CGAL. I preferred the slow version that gave accurate results.

On 22 May 2016 at 22:06, Parkinbot <[hidden email]> wrote:
Torsten, thanx for the link. Seems to be another brillant example of a time
consuming but effectless discussion.

My opinion is, that if I call polygon() with a points argument containing N
points, I want to have a polygon with N points and not even one less.

A reasonable grain control should at least enforce some minimum grid or
distance (max or even Euclidean norm) so that one would end up with some
maximum number of points in my example. The implemented "the more you put
in, the less you get out" scheme is a clear bug.

Rudolf




--
View this message in context: http://forum.openscad.org/strange-polygon-behaviour-in-small-scale-tp17390p17404.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
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
tp3
Reply | Threaded
Open this post in threaded view
|

Re: strange polygon() behaviour in small scale

tp3
On 05/23/2016 12:52 AM, nop head wrote:
> Not only a huge bug but also a regression. Polygon used to
> work before the 2D subsystem was re-written to not use CGAL.
> I preferred the slow version that gave accurate results.
>
That sounds like the change was made to annoy people, I'm
pretty sure that was not the intention. While CGAL might be
accurate in most cases, it's also very much unstable at times,
which is not really a good thing for an application either.

Otherwise, I agree with Parkinbot: "Seems to be another brillant
example of a time consuming but effectless discussion."

It's raised and acknowledged as a bug, so talking circles
around it will only make this thread longer.

ciao,
  Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten