Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cylinder/circle radius modes #599

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
@brianolson
Copy link

commented Jan 12, 2014

adds $rm={INNER_RADIUS,MIDPOINT_RADIUS,OUTER_RADIUS} to cylinder and circle. This adjusts the facets so that the radius is inside the facets, straddling the facets, or outside the facets (the radius lies on the vertexes) (the current current behavior and default behavior).

Adds example025.scad demonstrating this feature, and reference images rendering that as tests.

There may be a glitch in my linux box's OpenGL drivers and the reference images may need to be re-generated to be pixel-perfect.

@MichaelAtOz

This comment has been minimized.

Copy link
Member

commented Jan 12, 2014

Is that case sensitive? Any chance of accepting shortened version i/m/o, save my carpel tunnel.

@brianolson

This comment has been minimized.

Copy link
Author

commented Jan 12, 2014

@MichaelAtOz , INNER_RADIUS,MIDPOINT_RADIUS,OUTER_RADIUS are implemented as global constants like PI. You could skip them and use 1,2,3 if you want to type less.

@kintel

This comment has been minimized.

Copy link
Member

commented Jan 12, 2014

@brianolson One question: What is the rationale for using a $-variable? It sounds like this parameter should be a normal variable as it changes the dimensions of geometry, not only the resolution.

@brianolson

This comment has been minimized.

Copy link
Author

commented Jan 12, 2014

@kintel I imagined it as similar to $fn and friends, modifying the rendered interpretation of the geometry, but not the fundamental variables. The faceted interpretation of a circle or cylinder isn't the fundamental geometry, but we have modifiers for how that interpretation is rendered. I'd be open to phrasing that differently. Are there other geometry primitives that have a comparable optional modifiers?

@kintel

This comment has been minimized.

Copy link
Member

commented Jan 12, 2014

OK, point taken. I can't think of any other primitives having comparable modifiers.
I'll take a look your patches.

@nophead

This comment has been minimized.

Copy link
Member

commented Jan 12, 2014

Seems odd to have a global modifier because you would tend to use different
values depending if the circle was an outside perimeter or a hole.

On 12 January 2014 16:55, Marius Kintel notifications@github.com wrote:

OK, point taken. I can't think of any other primitives having comparable
modifiers.
I'll take a look your patches.


Reply to this email directly or view it on GitHubhttps://github.com//pull/599#issuecomment-32126972
.

@GilesBathgate

This comment has been minimized.

Copy link
Contributor

commented Jan 12, 2014

@nophead Sorry to be a fusspot, But I don't really consider $-variables (or "special variables" for want of a better name) as global. They are local to a specific syntactical scope, and cascade down into lower scopes. As to whether you want $rm to cascade down to children I am also unsure. But I also don't think that creating a hole is the only use case where you would want control over these radius modes.

@nophead

This comment has been minimized.

Copy link
Member

commented Jan 12, 2014

Yes global was the wrong word but most people set $fn and $fa at the top of
the file to have global effect. $fn then gets overridden when you want a
hexagon, for example.

When you have a hole it is normally to accept something round so you need
the facets on the radius. An outer radius doesn't usually matter much
unless it fits into something, in which case you need the vertices on the
radius. You would get odd effects when a radius meets a flat edge
tangentially, e.g. when making a rounded corner on something, if you use
anything but the vertex radius you would get a bulge.

In my case I would never use these because I use a poly_cylinder module for
3D printed holes and everything else uses normal circles with sufficient
sides that it wouldn't make a noticeable difference.

On 12 January 2014 19:35, Giles Bathgate notifications@github.com wrote:

@nophead https://github.com/nophead Sorry to be a fusspot, But I don't
really consider $-variables (or "special variables" for want of a better
name) as global. They are local to a specific syntactical scope, and
cascade down into lower scopes. As to whether you want $rm to cascade down
to children I am also unsure. But I also don't think that the hole use case
is the only time you would want control over these radius modes.


Reply to this email directly or view it on GitHubhttps://github.com//pull/599#issuecomment-32131348
.

@kintel

This comment has been minimized.

Copy link
Member

commented Jan 12, 2014

I'm a bit wary of introducing new use-cases for $-variables as the $ variable design is a bit dubious.
I sounds like the uses of the variable being discussed here is really about being able to override certain named parameters globally (or for some subtrees) in order to define what certain objects should be interpreted as.
We could construct a similar argument for overriding e.g. the center parameter to avoid having to specify it everywhere. Perhaps we should think about a general mechanism for such overrides as an alternative to $-variables?

For now I'm not sure what to do with this particular variable, but it's trivial to modify it as long as we do it before the next release.

@nophead

This comment has been minimized.

Copy link
Member

commented Jan 12, 2014

Being able to override the default value of center would be bad because if
you cut and paste bits of code it will break and you also would not be
able to read a snippet of code without knowing the global setting.

On 12 January 2014 20:17, Marius Kintel notifications@github.com wrote:

I'm a bit wary of introducing new use-cases for $-variables as the $
variable design is a bit dubious.
I sounds like the uses of the variable being discussed here is really
about being able to override certain named parameters globally (or for some
subtrees) in order to define what certain objects should be interpreted as.
We could construct a similar argument for overriding e.g. the centerparameter to avoid having to specify it everywhere. Perhaps we should think
about a general mechanism for such overrides as an alternative to
$-variables?

For now I'm not sure what to do with this particular variable, but it's
trivial to modify it as long as we do it before the next release.


Reply to this email directly or view it on GitHubhttps://github.com//pull/599#issuecomment-32132621
.

@brianolson

This comment has been minimized.

Copy link
Author

commented Jan 12, 2014

@nophead The use case I make this for is indeed drilling holes.

numberSixOD = 3.5052;  // 6-32 screw
difference() {
  cube([blah]); // sheet of stuff
  cylinder(r=numberSixOD/2.0, 99, $rm=INNER_RADIUS, $fn=8); // this makes a hole than a #6 screw fits in nicely.
}

I think we all know how if I didn't have the INNER_RADIUS modifier there they resulting hole would wind up too small for the screw because the vertexes would be on the circumference of the screw and the facets would cut into the space where it wants to go.

On the other side, just today I made a design with a peg that fit into the mounting holes on a circuit board. I used the default (a.k.a. OUTER_RADIUS) for that.
I imagine if I were making a calibrated winch thing where the circumference mattered I might try MIDPOINT_RADIUS, or maybe I might want to be yet more picky and do those calculations by hand, but I think as a first pass of getting the radius right on average I would try that setting.

@GilesBathgate

This comment has been minimized.

Copy link
Contributor

commented Jan 12, 2014

@nophead Aw you forgot to post a reference to your polyholes script, @brianolson take a look at this if you haven't already seen it: http://hydraraptor.blogspot.co.uk/2011/02/polyholes.html

@brianolson

This comment has been minimized.

Copy link
Author

commented Jan 12, 2014

@GilesBathgate Yes, I did see that. And I kinda decided that the fix for that was so important that I wanted it built into OpenSCAD natively!

@nophead

This comment has been minimized.

Copy link
Member

commented Jan 12, 2014

Yes but the poly_cylinder module also picks the number of sides depending
on the diameter so it still couldn't use your mod directly.

My point was that parameter depends on whether the circle in internal or
external, so it should just be a normal parameter, not a special variable
with dynamic scope. That could cause chaotic side effects to the geometry
of children. Only the existing circle type is compatible with cubes.

On 12 January 2014 21:52, Brian Olson notifications@github.com wrote:

@GilesBathgate https://github.com/GilesBathgate Yes, I did see that.
And I kinda decided that the fix for that was so important that I wanted it
built into OpenSCAD natively!


Reply to this email directly or view it on GitHubhttps://github.com//pull/599#issuecomment-32135300
.

@brianolson

This comment has been minimized.

Copy link
Author

commented Jan 12, 2014

If the debate is about whether it's "$rm=..." or "rm=...", I don't care. I just named it "$rm" because I thought it sounded like $fn. To me it has similar usage, being a modifier on how the curve is rendered.

@brianolson

This comment has been minimized.

Copy link
Author

commented Jan 12, 2014

OpenSCAD also has an algorithm for deciding how many facets to build a circle out of (if you don't specify $fn, $fa, $fs), but in the example above I set $fn=8 because in my experience with my models and my reprap, that works better (I think the automatic value was 6).
Oh, also my $rm mod also works with explicit or automatic $fn.

@nophead

This comment has been minimized.

Copy link
Member

commented Jan 12, 2014

The debate is about it being a $ variable. That gives it dynamic scope
meaning not only does it affect the current lexical scope and those nested
in it, but also all called functions and modules and any children. So if it
is only used inside circle and cylinder parameter lists all is well as it
works like a normal parameter but if you set it outside it could cause
chaos, because it then changes the default for all circles and cylinders
and they no longer mate with faces of cubes.

What about spheres, by the way?

On 12 January 2014 22:41, Brian Olson notifications@github.com wrote:

OpenSCAD also has an algorithm for deciding how many facets to build a
circle out of (if you don't specify $fn, $fa, $fs), but in the example
above I set $fn=8 because in my experience with my models and my reprap,
that works better (I think the automatic value was 6).
Oh, also my $rm mod also works with explicit or automatic $fn.


Reply to this email directly or view it on GitHubhttps://github.com//pull/599#issuecomment-32136675
.

@brianolson

This comment has been minimized.

Copy link
Author

commented Jan 12, 2014

I didn't look into spheres, but I'd guess they're using the same current behavior of putting the vertexes at the specified radius. I haven't personally needed spheres in my openscad designs, and it would be a different and slightly more complex solution to work out setting the facets tangent to the radius. I did make a //TODO comment noting this.

@brianolson

This comment has been minimized.

Copy link
Author

commented Jan 13, 2014

The discussion wandered a bit and I'm not sure where people stand. Does anyone have something concrete to say along these lines:

  1. This feature is AWESOME and should be integrated immediately!
  2. This feature is TERRIBLE and should never be integrated.
  3. This feature needs design tweaks (change foo to bar, etc) ...
  4. I like pie
@t-paul

This comment has been minimized.

Copy link
Member

commented Jan 13, 2014

I'd vote for 3. I think it's useful, but I agree with the point that the $ variable might create more problems than it solves (but then I'm not perfectly familiar with the subtle behavior effect that introduces).

  • In case the decision is to leave the $rm, then I think it really should include sphere too as having a general setting that affects only circle and cylinder but not sphere is confusing
  • With a special parameter only on the primitive itself it might be ok to just document that it's not supported by sphere.

My personal favorite (don't know if that matches the view of others) would be to have it as a special parameter of type string (e.g. align="middle", or something like that) and explicitly check all 3 possible cases and issue a warning in case an invalid value is given (e.g. Unknown value for the align parameter (use "inner", "middle" or "outer")). If the parameter is not set at all, it should of cause default to the current behavior.

I do agree with 4.

@kintel

This comment has been minimized.

Copy link
Member

commented Jan 13, 2014

I plan to look at this soon. I agree with @t-paul: drop the $ variable, add for sphere and think about the enum stuff.

@nophead

This comment has been minimized.

Copy link
Member

commented Jan 13, 2014

Didn't Giles suggest this a while ago but using alternative parameters
names for the different types of radii? That avoids the need for enums and
strings.

On 13 January 2014 16:37, Marius Kintel notifications@github.com wrote:

I plan to look at this soon. I agree with @t-paulhttps://github.com/t-paul:
drop the $ variable, add for sphere and think about the enum stuff.


Reply to this email directly or view it on GitHubhttps://github.com//pull/599#issuecomment-32185961
.

@t-paul

This comment has been minimized.

Copy link
Member

commented Jan 13, 2014

With different parameter name for every case the handling will get quite complicated, especially with cylinder. This currently has: r, r1, r2, d, d1, d2. Multiplied with the 3 cases we'll get 18 parameter names and the strange option to have different cases for the top and bottom polygon.
Due to the diameter option I think we should drop the "radius" part to select the behavior.

@brianolson

This comment has been minimized.

Copy link
Author

commented Jan 13, 2014

I kinda like @nophead 's suggestion.
It does lead to a slightly nasty combinatoric explosion:
cylinder(d=,r=,d1=,r1=,d2=,r2=,[$fn=,$fa=,$fs]
those six diameter/radius variables then gain 'o' variants and 'm' variants, becoming 18 variables that cylinder() is looking for.
Thanks to the lookup_radius() function that would collapse to 9 radius variations in the code. Not too bad. Manageable.
I could recode it this way if there's consensus.

@brianolson

This comment has been minimized.

Copy link
Author

commented Jan 13, 2014

cylinder(d, r, d1, d2, r1, r2,
do, ro, d1o, d2o, r1o, r2o,
dm, rm, d1m, d2m, r1m, r2o,
$fn, $fa, $fs);
@MichaelAtOz

This comment has been minimized.

Copy link
Member

commented Jan 13, 2014

My personal favorite (don't know if that matches the view of others) would be to have it as a special parameter of type string (e.g. align="middle", or something like that)

Having just reviewed the manual, the syntax 'style' does not favour strings for options, strings are used for filenames and the second form of color() [an understandable exception].
Options generally use boolean, such as cut=, center=, auto= [or a vector of booleans], other parameters are numbers because they are real measurable things, convexity=, size= etc.

So this instance seems to be the first need for a trinary (or higher) option.

I think the 18 parameters path is nasty.

What about reversing it, facet=, saying the radius/diameter is inside/outside/midpoint. Still need to choose how to represent the trinary.

Alternatively, {inside=boolean | outside=boolean | mid=boolean} obviously only one (or last) is valid.

@MichaelAtOz

This comment has been minimized.

Copy link
Member

commented Jan 13, 2014

p.s. sphere needs doing too, need to be able to match them
cylinder_sphere

@GilesBathgate

This comment has been minimized.

Copy link
Contributor

commented Jan 15, 2014

Update getCircle now accepts the 'approx' parameter as discussed:

module circle(radius,approx="outer") {
 f=getFragments(radius,$fn,$fs,$fa);
 if(approx=="inner") {
  assign(apothem=radius*cos(360/f)) {
   polygon(getCircle(apothem,f),[getRange(0,f)]);
  }
 } else {
  polygon(getCircle(radius,f),[getRange(0,f)]);
 }
}
@brianolson

This comment has been minimized.

Copy link
Author

commented Jan 29, 2014

Ping.
So, the last bit of the discussion showed that it's possible to do circle adjustment in user space in scad code. Right now it requires either fully generating the geometry in user space, or explicitly specifying the $fn facet number, or copying the C library code that calculates $fn out into scad code. It's possible to do it currently, but I still think it's not the best way and extending the circle/cylinder primitives is better. If we're going to have geometry primitives and not reimplement everything in the scad language, then we should extend circle and cylinder with the proposed feature.

@GilesBathgate

This comment has been minimized.

Copy link
Contributor

commented Jan 29, 2014

Right now it requires either fully generating the geometry in user space, or explicitly specifying the $fn facet number, or copying the C library code that calculates $fn out into scad code.

Not really, you can just adjust your radius accordingly:

apothem=radius*cos(360/f)
circle(r=apothem...);
cylinder... //etc
@brianolson

This comment has been minimized.

Copy link
Author

commented Jan 29, 2014

@GilesBathgate right, that's the "explicitly specify" option I mentioned. If you calculate the apothem for an N-gon then you have to specify that the circle or cylinder is rendered $fn=N

@kintel

This comment has been minimized.

Copy link
Member

commented Feb 1, 2014

Sorry for letting this drag out - language changes are always a sensitive topic in terms of compatibility worries and feature creep.
I've boiled the Pro-side of this discussion down to the following alternatives, which I find decent enough. Any opinions on which one(s) are preferred? (cylinder and sphere would need the same treatment)

circle(approx = <INNER | OUTER | MIDDLE >);
circle(approx = <"inner" | "outer" | "middle" >);
circle(align = <INNER | OUTER | MIDDLE >);
circle(align = <"inner" | "outer" | "middle" >);
@OskarLinde

This comment has been minimized.

Copy link
Contributor

commented Feb 2, 2014

I’m sorry to jump in here. These kinds of discussions never tend to be very productive. :-)

There seem to be two different questions being discussed. 1) Do we need this feature, and 2) can we come up with a nice syntax.

If we skip the syntax discussion and start with the need part:

  1. Does this feature enable something we can’t already do today?
  2. Does this feature solve a problem for a significant group of users?
  3. What do we gain by implementing this in the core language (vs userspace)?
  4. What is the cost of implementing this in the core language?
  5. Is the feature well defined, and can it be generalized further?
  6. Does this feature enable something we can’t already do today? Well, no. As @GilesBathgate shows, it is already doable today by typing *cos(360/$fn) next to the radius. I.e. 13 characters of code. But as everyone who ever encounters such a problem should write a function or a module, it basically saves a user having to write 1 line of code once, and then never again. So, to be crass, its use would be limited to those that are less than fluent in trigonometry. :-)
  7. Does this feature solve a problem for a significant group of users? The use case that has been put forth is that of 3D printing holes. Is it so simple that by measuring the outer diameter of a screw or rod and then creating a hole by extruding a polygon exactly circumscribing a circle of that specific outer diameter you will get an exact and well defined fit? Is there no need to consider things like material, shrinkage, outflow, surface smoothness, accuracy, slicing? What is the well defined fit you get? Tight (how tight?), loose (how loose?) etc. I think, that as for example @nophead has shown with polyholes, that it is much more complex than so. Which would mean that in the end, we gain almost nothing.
  8. What do we gain by implementing this in the core language? Since a user-space implementation is one line of code and would have been done in a fraction of the time spent typing this message so far, it certainly sounds like the way to go unless the core language implementation offers significant advantages. The only advantage I can see would be to establish a standard for how these kind of parameters are defined in other Openscad libraries. Do we have a brilliant and well thought out syntax that generalizes to other similar problems of curve and surface discretization? (See 5.)
  9. What is the cost of implementing this in the core language? I won’t go further into this than say that one should not underestimate the maintenance costs.
  10. Is the feature well defined, and can it be generalized further? This is basically the only part of this discussion I find interesting. The current segmentation performed by circle(), cylinder() and sphere() can be seen as a chordal (consisting of discretizing the circular arc into $fn points, connecting them with a straight line, i.e. a chord.) while the other one (outer or inner, depending on perspective) can be seen as a tangental discretization. Same starting point: discretize the arc into $fn points, but instead of connecting the points with chords, draw tangents at each point. The resulting vertices will be the intersection points of neighboring tangent lines. It would mean that the larger (tangental) polygon should be rotated one half segment compared to the smaller (chordal) one. The nice thing about this definition is that it generalizes to any curve shape. Where does that leave ”mid”? I don’t know how it should be defined for anything but a circle, and even then I’m not sure which definition is correct. The most likely intent would be to minimize the linearization error, for example the integral of ∆r(θ) dθ. How do we calculate that consistently for other curves and where should the vertices be placed? I would suggest scrapping ”mid” until at the very least the definition is clear. I think the use case is a bit unclear too.

About syntax: I’ll prefer not to dwell into this (but can’t resist so I’ll try to be short)

  • Global constants such as INNER, OUTER, MIDDLE are quite likely to be used in other existing code, so care would have to be taken to handle clashes. Would the variables be reassignable? Would they have well-defined values that could be passed instead?
  • Even though having read the proposed definitions above serveral times, I still can’t remember if ”inner” is supposed to mean polygon inscribed in circle, or circle inscribed in polygon. Personally, ”chordal” and ”tangental” would be what made the meaning perfectly clear to me.

So there is basically my $.02. Take it for what’s it worth. :-)

@MichaelAtOz

This comment has been minimized.

Copy link
Member

commented Feb 2, 2014

Any opinions on which one(s) are preferred?

I like "align" over "approx".
INNER|MIDDLE|OUTER is in one regard better, less typing (but you have to use shift, which is a pain for me [tl;dr]), and yes they are reassignable, I just tried with PI.
However, when considering future expansion of the language the align="inner" is probably a better standard as you wont be creating more reserved words, there is a reason XML etc adopted that style.

So I'm for circle(align = <"inner" | "outer" | "middle" >);

  1. Do we need this feature, ...
    it is already doable today by typing *cos(360/$fn) next to the radius.
    So, to be crass, its use would be limited to those that are less than fluent in trigonometry. :-)

I'm not that fluent in trig. I think you will find that a lot of people will have forgotten much of the detail from high school days.

So, yes, I would like this feature.

@laird

This comment has been minimized.

Copy link

commented Feb 2, 2014

I thing align is more clear than approx.

And I think it's a good convenience, similar to using either r or d for
circles. Yes, people who know trig can write a function to do this, but
lots of people don't know this particular bit of trig, and the concept of
polygons fitting to a circle at inner/outer/middle seems pretty general and
useful.

  • Laird Popkin

Sent from my iPhone. Apologies in advance for typo's.

On Feb 1, 2014, at 10:29 PM, Michael notifications@github.com wrote:

Any opinions on which one(s) are preferred?

I like "align" over "approx".
INNER|MIDDLE|OUTER is in one regard better, less typing (but you have to
use shift, which is a pain for me [tl;dr]), and yes they are reassignable,
I just tried with PI.
However, when considering future expansion of the language the
align="inner" is probably a better standard as you wont be creating more
reserved words, there is a reason XML etc adopted that style.

So I'm for circle(align = <"inner" | "outer" | "middle" >);

  1. Do we need this feature, ...
    it is already doable today by typing *cos(360/$fn) next to the radius.
    So, to be crass, its use would be limited to those that are less than
    fluent in trigonometry. :-)

I'm not that fluent in trig. I think you will find that a lot of people
will have forgotten much of the detail from high school days.

So, yes, I would like this feature.

Reply to this email directly or view it on
GitHubhttps://github.com//pull/599#issuecomment-33891019
.

@GilesBathgate

This comment has been minimized.

Copy link
Contributor

commented Feb 2, 2014

Thanks for that very thoughtful discussion @OskarLinde , But you have taken my argument out of context. The "one line of trig code" comment was in reaction to the comment about "fully generating the geometry in user space", I was merely making the point that its not the only way of doing it. Having said that doing all the primitives in user space that it is the way I would prefer to see it done. (Although admittedly this should probably be filed under a separate issue) The end user shouldn't need to wrangle any trig functions because this feature would also be shipped in the userspace primitives bundled with the openscad distributable. The main advantage which I can see, for doing things in userspace, is that it makes adding this sort of thing accessible to end users who do not want to get involved in C++ programming. I admit however that users who are unfamiliar with trig might have to go back to high school if they want to play with the userspace libraries ;)

@nophead

This comment has been minimized.

Copy link
Member

commented Feb 2, 2014

You are not going to get very far with OpenScad if you don't know high
school level trig.
This https://github.com/nophead/Mendel90/blob/master/dibond/stls/x_carriage_fan_bracket.stl simple
webbed fan bracket was straightforward until I added the webs. They
required a lot of simple trig.

Fortunately I remember the basics, but it can easily be Googled nowadays.
Wolfram has formulas for virtually everything. I don't remember ever doing
the circumference of ellipse at school, but I needed that for Mendel90,
Googled it and found there is only an approximate formula, very surprising.

On 2 February 2014 06:14, Laird Popkin notifications@github.com wrote:

I thing align is more clear than approx.

And I think it's a good convenience, similar to using either r or d for
circles. Yes, people who know trig can write a function to do this, but
lots of people don't know this particular bit of trig, and the concept of
polygons fitting to a circle at inner/outer/middle seems pretty general and
useful.

  • Laird Popkin

Sent from my iPhone. Apologies in advance for typo's.

On Feb 1, 2014, at 10:29 PM, Michael notifications@github.com wrote:

Any opinions on which one(s) are preferred?

I like "align" over "approx".
INNER|MIDDLE|OUTER is in one regard better, less typing (but you have to
use shift, which is a pain for me [tl;dr]), and yes they are reassignable,
I just tried with PI.
However, when considering future expansion of the language the
align="inner" is probably a better standard as you wont be creating more
reserved words, there is a reason XML etc adopted that style.

So I'm for circle(align = <"inner" | "outer" | "middle" >);

  1. Do we need this feature, ...
    it is already doable today by typing *cos(360/$fn) next to the radius.
    So, to be crass, its use would be limited to those that are less than
    fluent in trigonometry. :-)

I'm not that fluent in trig. I think you will find that a lot of people
will have forgotten much of the detail from high school days.

So, yes, I would like this feature.

Reply to this email directly or view it on
GitHub<#599 (comment)

.

Reply to this email directly or view it on GitHubhttps://github.com//pull/599#issuecomment-33893424
.

@TakeItAndRun

This comment has been minimized.

Copy link

commented Feb 2, 2014

I dont see a compelling arguments for the middle option.
Thus only two option for approx/align are really needed: use a simple
bolean true/false.
The old state should get the value false, the new option the value true.
(standard being false)
What to name it?
Not align: there are no two objects aligned to each other

apothem=true

makes sense to me. (but it is not a well known word.)

Sincerely,

TakeItAndRun

2014-02-02 Chris notifications@github.com:

You are not going to get very far with OpenScad if you don't know high
school level trig.
This<
https://github.com/nophead/Mendel90/blob/master/dibond/stls/x_carriage_fan_bracket.stl

simple
webbed fan bracket was straightforward until I added the webs. They
required a lot of simple trig.

Fortunately I remember the basics, but it can easily be Googled nowadays.
Wolfram has formulas for virtually everything. I don't remember ever doing
the circumference of ellipse at school, but I needed that for Mendel90,
Googled it and found there is only an approximate formula, very surprising.

On 2 February 2014 06:14, Laird Popkin notifications@github.com wrote:

I thing align is more clear than approx.

And I think it's a good convenience, similar to using either r or d for
circles. Yes, people who know trig can write a function to do this, but
lots of people don't know this particular bit of trig, and the concept of
polygons fitting to a circle at inner/outer/middle seems pretty general
and
useful.

  • Laird Popkin

Sent from my iPhone. Apologies in advance for typo's.

On Feb 1, 2014, at 10:29 PM, Michael notifications@github.com wrote:

Any opinions on which one(s) are preferred?

I like "align" over "approx".
INNER|MIDDLE|OUTER is in one regard better, less typing (but you have to
use shift, which is a pain for me [tl;dr]), and yes they are
reassignable,
I just tried with PI.
However, when considering future expansion of the language the
align="inner" is probably a better standard as you wont be creating more
reserved words, there is a reason XML etc adopted that style.

So I'm for circle(align = <"inner" | "outer" | "middle" >);

  1. Do we need this feature, ...
    it is already doable today by typing *cos(360/$fn) next to the radius.
    So, to be crass, its use would be limited to those that are less than
    fluent in trigonometry. :-)

I'm not that fluent in trig. I think you will find that a lot of people
will have forgotten much of the detail from high school days.

So, yes, I would like this feature.

Reply to this email directly or view it on
GitHub<
#599 (comment)

.

Reply to this email directly or view it on GitHub<
https://github.com/openscad/openscad/pull/599#issuecomment-33893424>

.

Reply to this email directly or view it on GitHubhttps://github.com//pull/599#issuecomment-33897301
.

stempeldergeschichte@googlemail.com karsten@rohrbach.de

P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu
schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.

P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.

Enjoy!

@MichaelAtOz

This comment has been minimized.

Copy link
Member

commented Feb 2, 2014

You are not going to get very far with OpenScad if you don't know high school level trig

Well you could use your trig to do everything with polyhedron/polygon, but circle/cylinder/cube etc are easier, this is just another high level language feature to make things easier.

@t-paul

This comment has been minimized.

Copy link
Member

commented Feb 2, 2014

As for the syntax, I'd choose of the listed option
circle(align = <INNER | OUTER | MIDDLE >);
It would be nice to find a way to have them as specific enum values instead of just global constants. Maybe something like circle.INNER when used generally in the code with the option to drop the specifier when directly used inside the circle module?

@GilesBathgate

This comment has been minimized.

Copy link
Contributor

commented Feb 2, 2014

circle(radius=5, center=true, inscribed=true);

Or perhaps we should call it incircle then it will remind us that the conversation about it went in circles ;)

@kintel kintel referenced this pull request Feb 23, 2014

Closed

Offset/Inflate/Deflate Polygon [$5] #483

4 of 4 tasks complete
@brianolson

This comment has been minimized.

Copy link
Author

commented Aug 29, 2014

I wrote this feature in April 2012, it's now August/September 2014. I give up. I wrote a perfectly reasonable feature, implemented, tested, and it was dropped on the floor. I can't maintain it anymore. At some point the build for Mac got too onerous to manage all the dependency hell that gets pulled in. It's no longer feasible for me to develop OpenSCAD or maintain this feature and I have to fall back on binary builds. I'm kinda bitter that I'm going to have to change a bunch of my .scad models to not use this feature anymore.

@MichaelAtOz

This comment has been minimized.

Copy link
Member

commented Aug 29, 2014

Sorry to hear that.
I, for one, think this is an important feature.
If the syntax is locked down*, then it can be changed out to user-space once that is sorted out.

*As stated earlier, I'm for circle(align = <"inner" | "outer" | "middle" >);
(where inner means the polygon is inside the radius)

For now, I just drill out holes...

@kintel

This comment has been minimized.

Copy link
Member

commented Sep 15, 2014

@brianolson Sorry this is taking so long. The discussion brought out a lot of concerns and ideas, and I feel we haven't really reached consensus on this. The cleanest solution thus far seems to be to add an "align" parameter which takes a string parameter, as in @MichaelAtOz's last comment.
TODO: Rework the patch, add support for spheres, add tests, cheat sheet, wikibooks

@eadz

This comment has been minimized.

Copy link

commented Mar 17, 2015

Hi all,

I thought I would give a new user's perspective on this PR. I'm probably a pretty typical new OpenSCAD user: programmer, new to CAD, new to 3d printing, using OpenSCAD for 3d printing.

I printed out my very first object the other day, I designed it myself in OpenSCAD. The process was easy and fun, but the screw hole was too small.

I had no idea what was wrong, I assumed my design was incorrect. I came across this PR by chance ( browsing through the PRs ), and I would like to offer my opinion.

Judging from the gallery page, 3d printing is a very common use for OpenSCAD. I don't think that as someone who wants to make parts fit together, I should have to use extra functions or external libraries.

This feature would be more useful than the center=true/false feature IMHO.

@MichaelAtOz .. yes I just drilled out my holes too!

I would say

  • yes to a global default ( personally I would use middle - accurate volume )
  • yes to a ternary option of ???=INNER|MIDDLE|OUTER

It is a shame that the original maintainer cannot continue. I don't even know what programming language OpenSCAD is written in. I have however updated the wiki to warn users about this issue.

If there is a 'recommended' workaround, and easy examples to achieve INNER/MIDDLE/OUTER that would be fantastic. Does anybody have any suggestions in this regard?

@mrvn

This comment has been minimized.

Copy link

commented Oct 5, 2015

I had the same problem with hole sizes as everyone else and I would very much like to see this natively in openscad. reading through all the comments I have a few of my own:

  1. Having 2 ways to draw a circle (cylinder, sphere) is a bad idea. If you have a circle primitive then fix it. If you have a circle module then remove the primitive. (please do the former).

  2. People stumble across this problems because their holes get too small. Holes are made using difference(). That suggests to me that the difference() function should toggle between inner and outer circle. That way positive spaces will use inner and negative space use outer. That also speaks towards a $ variable I think.

  3. there are several ways you can want something in between inner and outer:
    a) midpoint between inner and outer, gives a good approximation of the circle
    b) same circumference, important for pulley systems where you want to advance the string an exact amount
    c) same area, think about making a measuring cup

@hairykiwi

This comment has been minimized.

Copy link

commented Nov 1, 2015

I'm another relatively new user of OpenSCAD, with a reasonable amount of traditional CAD experience.

In much the same way other mature CAD software enable polygon's to be defined as either inscribed or circumscribed, I like @GilesBathgate's suggestion, albeit in the direct opposite form:
circumscribed = true | false

  • this for example, is effectively how MoI3D implements it.

The only other rationale for my preference being opposite Giles' is the result of playing with the idea of extending the ternary option to be a percentage variable instead - in this scenario, the relative size of the percentage better suggests what happens to the size of the polygon created:

  • circumscribed = false would internally translate to inscribed / 0(%) : the polygon's vertices lay on - or '0% outside' the specified defining diameter,
  • "mid" or "middle" would translate to 50(%),
  • circumscribed = true would translate to 100(%): the polygon's vertices lay 'as much as possible' - or 100% outside the defining diameter, and
  • any intermediate percentage would provide absolute granularity.

Implemented as such, any of the following would be valid inputs:
circumscribed = true | false | mid,
circumscribed = 0,,
circumscribed = 41.93708,
circumscribed = 100.

BTW, special thanks @brianolson for your perseverance with this issue - I really hope something comes of it.

@GilesBathgate

This comment has been minimized.

Copy link
Contributor

commented Nov 1, 2015

Wow, this was a fun discussion from yesteryear. Thanks for bringing it back up @hairykiwi. I like your suggestion, it certainly seems very clean to simply have a single parameter, and a value between 0%-100% to determine whether its the inner circle outer circle, or midcircle.

Although rather than using percentages its traditional to have the value normalised between 0.0 and 1.0, with 0.5 being 50%, I think that would make the true and false syntax easier to implement since true=1, and false=0. There is no simple way to allow the circumscribed = mid syntax you propose though since mid is not currently a valid token in openscad.

@hairykiwi

This comment has been minimized.

Copy link

commented Nov 1, 2015

Ah, normalised values vs percentages; of course - now you're talking Giles!

The normalised values approach is so self-explanatory it makes the very concept of a 'mid' token appear complete and utter excess baggage.

@jakob

This comment has been minimized.

Copy link

commented Nov 14, 2016

As an OpenScad user, can you please add this feature to the core language?

I absolutely don't care what you call it. It doesn't matter.

It's not only useful for radial holes, but also for pockets for hex nuts. I don't use OpenSCAD very often, so every time I want to add a hole, I have to get a piece of paper, start drawing, just to come up with the cos() formula again.

Please just make this a part of OpenSCAD.

@TakeItAndRun

This comment has been minimized.

Copy link

commented Nov 14, 2016

Please have a look at this blogpost.:
http://hydraraptor.blogspot.de/2011/02/polyholes.html

Nophead came up with the module polyholes() to size holes correctly.

2016-11-14 10:34 GMT+01:00 Jakob Egger notifications@github.com:

As an OpenScad user, can you please add this feature to the core language?

I absolutely don't care what you call it. It doesn't matter.

It's not only useful for radial holes, but also for pockets for hex nuts.
I don't use OpenSCAD very often, so every time I want to add a hole, I have
to get a piece of paper, start drawing, just to come up with the cos()
formula again.

Please just make this a part of OpenSCAD.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#599 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB0nDNk3hWUcsnv5W5b08U9ZvBm3uAqBks5q-CsUgaJpZM4BZHvA
.

@GilesBathgate

This comment has been minimized.

Copy link
Contributor

commented Nov 14, 2016

@TakeItAndRun I think pockets for hex nuts is the more appropriate use case. However @jakob there is nothing stopping you from creating a library that translates from in-radius to out-radius dimensions, with a given number of sides.

@jakob

This comment has been minimized.

Copy link

commented Nov 15, 2016

Thanks for your suggestions, but as I said, I really wish this feature was built into OpenSCAD.

I came to this issue by looking at the documentation how to make correctly sized holes with cylinder, only to discover that cylinder() doesn't support it. Then I discovered that there was a patch submitted for this functionality almost two years ago, but it's in limbo due to excessive bikeshedding.

Could someone please resolve this? Either accept the patch, or reject it. If you reject it, just close this issue and update the docs to state that cylinder() always makes polygons that are smaller than the true circle.

Also, further up someone said that you need to multiply the radius with cos(360/$fn) to get the correct size holes. This is not correct. That will make the holes even smaller. So just for the record, this is how I make a hole that has a diameter of at least 20 units:

n = 6;
cylinder(h=5, d=20/cos(180/n), $fn=n);

Maybe that bit could be included in the docs?

@GilesBathgate

This comment has been minimized.

Copy link
Contributor

commented Nov 17, 2016

@jakob The correct formula is a = r * cos( pi / n) but because openscad takes values in degrees not radians this becomes a = r * cos( 180 / n ) The formula above (which were mine) are probably mistakes from translating from c++ code which was using tau instead of pi sorry. I think you should be fine using the formula for diameter in place of radius as you have done. These formula are from here: https://en.wikipedia.org/wiki/Apothem

@smurfix

This comment has been minimized.

Copy link

commented Jul 14, 2018

Can we either close this PR or adapt it to current OpenSCAD?

As to its usefulness, IMHO inner/mid/outer … constants of 1,2,3 … well … I'd rather use 0/0.5/1 as constants that feed directly into the math, that allows me to use 0.9 as "outer circle but needs a snug fit" or whatever.

@Erudition

This comment has been minimized.

Copy link

commented Nov 30, 2018

As to its usefulness, IMHO inner/mid/outer … constants of 1,2,3 … well … I'd rather use 0/0.5/1 as constants that feed directly into the math, that allows me to use 0.9 as "outer circle but needs a snug fit" or whatever.

That's a great solution! A single value on the unit interval [0..1] where 0 is the smaller, and 1 is the larger. You can default to 0 and people can think of it as a boolean, or use a middle value (such as 0.5) to scale it between the two! Good compromise, super useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.