# strange polygon() behaviour in small scale Classic List Threaded 9 messages Open this post in threaded view
|

## strange polygon() behaviour in small scale

 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)]]; Open this post in threaded view
|

## Re: strange polygon() behaviour in small scale

 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!
Open this post in threaded view
|

## Re: strange polygon() behaviour in small scale

Open this post in threaded view
|

## Re: strange polygon() behaviour in small scale

 @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)]]; 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)]];
Open this post in threaded view
|

## Re: strange polygon() behaviour in small scale

 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)]]; > > 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
Open this post in threaded view
|

## Re: strange polygon() behaviour in small scale

 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/999ciao,   Torsten. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org -- Torsten
Open this post in threaded view
|

## Re: strange polygon() behaviour in small scale

 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