Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Support for $f_ variables #39

Closed
cbiffle opened this Issue Mar 16, 2012 · 3 comments

Comments

Projects
None yet
3 participants

cbiffle commented Mar 16, 2012

Consider the code

circle(r = R, $fn = 6);

In OpenSCAD, this is a regular hexagon inscribed inside a circle of radius R. In ImplicitCAD (as of today) it's a circle and a compile warning.

OpenSCAD global variables (starting with dollar signs) are a curious variety of scoped globals, which are in effect passed implicitly to every module and function. If I invoke a module M like so:

M($fn = 10);

it overrides the value of $fn inside M and any sub-modules it invokes -- unless they override $fn themselves.

While I often use these globals to adjust quality for 3D printing -- both to add vertices to overly chunky parts, and to remove them to speed up printing -- they're not purely cosmetic. I use $fn specifically for the regular-polygon-in-a-circle case described above, to model things like hex nuts.

In the interest of source compatibility with OpenSCAD I think these are worth implementing, even though they're weird.

Owner

colah commented Mar 17, 2012

The $_ variables don't really make sense in ImplicitCAD the way they do in OpenSCAD.

In ImplicitCAD, all models are of infinite resolution, exactly as you defined them. circle(10) is a perfect circle of radius 10. At the end, when ImplicitCAD renders the object (the output is not of infinite resolution, sadly) for export with the $res value in global scope or defaults to 1.

(Coincidently, cricle(10, $fn=100) would not just be a worse model of a circle in ImplicitCAD. It would also be much slower.)

ImplicitCAD does provide the $fn variable in some contexts, like circles and cylinders, but it specifically means 'a n-sided regular polygon' there, not a circle of resolution n.

We do not presently pass on $_ variables passed to a module as arguments to modules called by it. While I'm open to arguments, I think this is healthy behaviour for a number of reasons:

  • The openscad behaviour is more complicated and less intuitive.
  • One may very well, want to define a module where the object being produced has a number of sides. Keeping in-line with openscad's conventions, one may wish to have a $fn variable. Except, now all your circles are screwed up? This seems strange.
  • One can always do circle($fn=$fn); undoing it would be harder and would require knowledge of ImplicitCAD's internal design.

cbiffle commented Mar 17, 2012

I suppose it just depends on the degree of source compatibility you're shooting for with extopenscad. From the other bug reports I'd gotten the impression that source compatibility was a goal.

If you're not trying for that, then yes, the mechanisms behind the $f_ variables are ridiculous. But if you are, it's critical to correctness.

Collaborator

julialongtin commented Nov 20, 2016

I'm good with these functions continuing to not be implemented or passed. this feature of openscad is quirky.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment