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.

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!

As a workaround you can scale your points up, then back down like this: scale(1e6) polygon(circ(1)); translate([2, 0]) scale(1e6) 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 _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
@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 ... <quote author="thehans"> As a workaround you can scale your points up, then back down like this: scale(1e6) polygon(circ(1)); translate([2, 0]) scale(1e6) polygon(circ(0.01)); function circ(step=1) = [for(i=[0:step:360]) [1e6*sin(i), 1e6*cos(i)]]; 
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 builtin 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 
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

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 
Not only a huge bug but also a regression. Polygon used to work before the 2D subsystem was rewritten 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 _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
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 rewritten 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

Free forum by Nabble  Edit this page 