added squircle to shapes2d.scad

[amatulic]

I have used this shape in a couple of projects and thought it would be a useful addition to BOSL2.

A squircle is a shape intermediate between a square/rectangle and a circle/ellipse. Squircles are sometimes used to make dinner plates (more area for the same radius as a circle), keyboard buttons, and smartphone icons. Old CRT television screens also resembled squircles.

The basic shape looks like this:

I have implemented a module and function for a squircle in shapes2d.scad. It takes a parameter for squareness (between 0 and 1, where 0=circle and 1=square), and a size parameter the same as with square() to define the bounding box for the squircle.

Because the curvature can change sharply at the corners, the vertices are distributed uniformly only when the shape is a circle (squareness=0). The vertices concentrate more toward the corners as squareness approaches 1. This results in a fairly smooth shape even with low $fn values.

[adrianVmariano]

Is this shape different than the shape produced by supershape(), e.g. those in example 3? The wikipedia page for "squircle" suggests that the most common "squircle" is the superellipse, and we already have that as a special case of supershape.

[amatulic]

Indeed, supershape example 3 does generate squircles. The difference is in implementation and capability:

• The supershape doesn't respect $fn although it does have a step parameter. The squircle uses $fn instead.
• Because the supershape can produce many different kinds of shapes with curves and cusps, it is impossible to optimize the number and distribution of vertices, instead relying on a tiny step size to resolve sharp curves. The squircle is predictable and the step size decreases toward the corners to produce smooth corners.
• The supershape squareness parameter is unbounded, ranging from 2 to infinity. The squircle squareness parameter ranges from 0 to 1, allowing for better control.
• Squircle parameters are simpler to understand, requiring only a squareness and bounding box size like a square.

The squircle wouldn't be the only thing in BOSL2 in which it's possible to do something multiple different ways. For example, you can use circle() or supershape() to produce an ellipse also, you can use either offset() or the rounding features of BOSL2 to make rounded polygon shapes, and you can approximate any curved shape with Bezier paths.

The ability to have a small number of vertices with optimized spacing also makes it feasible to generate a "sphube" (intermediate between shpere and cube) as a VNF with a reasonable facet count. I was planning to do that in a future PR.

[adrianVmariano]

Ok.

What is the mathematical meaning of the squareness parameter? It seems for example that it might be nice if it was easily convertible to the cut parameter used in rounding.scad, because that would make it easy to swap between rounded shapes with some amount of commonality.

Note, it's not true that an unbounded parameter leads to "inferior control" compared to a parameter on [0,1]. Perhaps more intuitive control, but the same amount of control is available in each case. Are the shapes with exponents between 1 and 2 (the sub-circles) not useful or not different? (Seems possible they are the same shapes, just rotated and differently scaled---I haven't checked.)

Also, why are there anchors floating in space in your pic above?

You might want to join the gitter developer chat for BOSL2 to talk about this kind of thing before going straight to the PR stage. https://app.gitter.im/#/room/#revarbat_BOSL2:gitter.im

[amatulic]

The squareness parameter is a feature of the Fernández-Guasti squircle described in the Wikipedia article, which says it "allows a smooth parametrization of the transition to a square from a circle, without involving infinity." It's also a feature of the periodic form. As far as I can tell, the parameter behaves the same way in both. As you said, it's more intuitive.

However, the squareness doesn't have a linear response. That is, if you set squareness=0.8, you don't get a squircle with corners 80% of the distance between the circle and the corners of the square. This squareness changes mostly in the 0.8-1.0 range. In my latest commit I have made this response approximately linear and included a demo example of this.

The anchors are wrong because I stupidly used the width of the squircle instead of the radius to calculate their positions. I'll fix that in my next commit. Honestly I wasn't sure what I should see, because it's a feature I never used, so I didn't notice it was wrong.

I've been using this function standalone in other projects, and I was more comfortable using it because it appears more straightforward and friendly than supershape, so I felt it was worth a PR, and something simple before I do the pull request for vnf_tri_array() that we've been discussing in #1514. I didn't know about any discussion area, and that link didn't work for me. It generated a bunch of console errors in Chrome.

[adrianVmariano]

Is there some compelling reason to not make the "squareness" parameter exactly linear? That would make it more usable for somone who wants to know where the curve will end up, for example. Wait, did you implement the FG squircle? That's totally different than the superellipse squircle. If that's the case then exact adherence to the FG equation could be an argument for nonlinearity. This might be something to bounce off Revar and Richard in the chat.

We might also want to show some kind of comparison of how this compares to round_corners with different k values or just a circular rounded square.

The 8 anchors should lie on the boundary of the shape if you have it right, with the arrow perpendicular to the shape.

Try https://gitter.im/revarbat/BOSL2 or if that doesn't work, try going to app.gitter.im and then see if you can find the BOSL2 chat somehow.

[amatulic]

I can make it closer to linear. I could also make it nearly exact, but I would need to introduce a curve-fitted polynomial correction with hard-coded coefficients. The correction there now is a simple formula, basically

new_squareness = sqrt(squareness*(2-squareness))

This results in a maximum error when squareness=0.48, in which case the corner of the squircle is 0.55 of the way to the corner of the square. The error approaches zero as squareness approaches 0 or 1. If I use the fourth root instead of the square root, the error is even less, with the maximum error at squareness=0.04, making the "corner" (it's almost exactly a circle at that point) 0.036 away from the corner of the square.

I fixed the anchor problem and pushed a new commit, but the anchors don't account for the squareness correction. It's past midnight here, so I'll revisit this tomorrow.

Update: I just noticed, in the research paper I've been using for this, a linearization of the squareness parameter. It works! If s is squareness and c=2-2*sqrt(2) then

new_squareness = 2*sqrt((1+c)*s*s - c*s) / (1-(1-sqrt(2))*s)^2

This results in errors no larger than 1e-15, effectively zero.

[amatulic]

Ah, that's better. Perfectly linear now! This is the demo using 10 equal intervals of squareness between 0 and 1:

I have pushed the fix. You can test it if you want.

Wait, did you implement the FG squircle? That's totally different than the superellipse squircle. If that's the case then exact adherence to the FG equation could be an argument for nonlinearity.

Yes, I implemented the polar form of the FG squircle, from this paper: https://arxiv.org/pdf/1604.02174v5 - and that paper goes into much detail about linearizing the squareness parameter. I think that justifies linearizing it here too. It's way more convenient to use that way.

I've also updated the Wikipedia article with the information from that paper: https://en.wikipedia.org/wiki/Squircle#Fern%C3%A1ndez-Guasti_squircle

[adrianVmariano]

Ah, I was going to say it's easy to transform it to a linear parameter from the equation----no research paper required. You just identify the desired "corner" coordinate R*[a,a], where a needs to go from 1/sqrt(2) for a circle up to 1 for a square. If b is a linear parameter on [0,1] then we have a=lerp(1/sqrt(2),1,b). Plug that into the FG equation and solve and you get s^2 = (2*a^2-1)/a^4. Note that it's equally simple to transform the exponent of the supershape into a linear parameter on [0,1].

I haven't delved into the literature. The argument for using the FG equation squareness parameter directly would be that the optics folks who invented it know and use it with that original functional form and would be confused to encounter it with a different parameter. I'm not saying that is compelling for our situation.

Another question arises: is the FG squircle the right one to use? Wikipedia says it's the "less common" version. (I've known about the superellipse for years and never heard of the other thing until yesterday.) Between this one and the superellipse, does one have an advantage? Smoother? Looks better? They are definitely different, so I want to know why we picked FG. Or should we support both with a squircle style flag?

[amatulic]

I took out "most common" from the Wikipedia article. An assertion like that needs sources to back it up, and the sources I have found mention both types.

I suspect that it doesn't matter how you arrive at the squircle, I suspect it may be the same shape from either method. I'll have to do some tests on that.

The advantage in OpenSCAD is that it's computationally less expensive to avoid dealing with fractional exponents, but this likely wouldn't make much difference in execution time.

Should I revise this to use superellipse? We could use the style flag if they're different.

[adrianVmariano]

No, it's definitely not the same shape. I mean, that's obvious from the functional form that it can't be, but I plotted a superellipse on an FG and they were visibly different, with the superellipse being more squarish.

You're using trig functions in the computation and worried about some fractional exponents? I expect run time for sin and cos are comparable to pow. Computation time should not be a concern, in any case.

My question above was an honest one. While to me the mathematical formulation of the superellipse is more elegant, I don't know for practical applications, what distinguishes the two shapes or what would make the FG shape better/worse than the superellipse. If you had both available...how would you pick?

It would also be interesting to compare the FG supershape to a continuous curvature rounded rectangle, which because it uses a 4th degree bezier, could actually be the same shape. (But actually not really because the rounded rectangle has a flat section.)

I noticed that the squircle references indicate that the superellipse version is the one specific superellipse with n=4.

Regarding which curve is better known or more used, it seems that the superellipse has got to be the winner there. The superellipse equation was described 100 years before FG wrote their paper. It was used in a font in 1952. But under the specific name "squircle"? That name is clearly a recent coinage, apparently much newer than either the superellipse or the FG shape.

[adrianVmariano]

[amatulic]

You beat me to it. I was just starting on the comparison myself. Thanks for the plot. Yes, there's a subtle difference.

And yes you're correct, I was searching for articles containing the word "squircle", so naturally everything I found mentions the FG squircle as well as the superellipse squircle.

You asked:

If you had both available...how would you pick?

I'd pick FG because it is mathematically well-behaved. While the expression for the superellipse is elegant in its simplicity, it's inelegant mathematically in its behavior. The main disadvantage to the superellipse is that you're dealing with an infinite exponent for squareness=1. Even when you get close to 1, the exponent gets quite large, potentially causing computational instability (although it's unlikely for expected use cases).

As I said near the beginning of this discussion, the FG squircle (quoting Wikipedia) "allows a smooth parametrization of the transition to a square from a circle, without involving infinity." I'd say that would be its main advantage.

[amatulic]

Thinking about it some more, I'll retract my statement about mathematical behavior. The polar form of the FG squircle doesn't behave well either when the angle is multiples of 90° and I deal with that simply by setting the squircle radius to the circle radius in those cases.

For the superellipse exponent going to infinity, the squareness parameter could be clipped at 0.99, corresponding to n=236.3 (I've implemented it here and it blows up past squareness=0.993), resulting in a shape indistinguishable from a square with the same number of vertices as the squircles. Retaining the vertex count would be useful for skinning between two squircle shapes.

How to proceed? It isn't a problem to support both now that I've written the code for both, but my preference is still for the FG squircle.

[adrianVmariano]

I didn't ask you which you'd pick as a programmer. I want to know which one you'd pick as a user who doesn't care how the thing is implemented, and whether it was computationally tricky or not. It's the job of the library author to handle those challenges and do the right thing rather than the easy thing, because we're doing it once and for all.

I'd argue that there's nothing wrong with infinity in math and there's nothing ill behaved about the superellipse. In fact, it's quite neat.

The characteristic you're complaining about is a computational issue, not a mathematical one, and it doesn't appear to be particularly bad. In fact, it seems to be surprisingly robust. It appears that maybe in the case of cartesian coordinates, the roundoff error produces errors that give you the right answer (square), for example. In polar coordinates it may not be so tidy, but I still got a good point with an exponent of 2000. I thought it would fail at a lower value. It appears to me that failure is primarily a result of underflow error.

The mathematical behavior of the curves I'd consider to be things like its derivatives, or the curvature along the curve: the properties of the curve as an ideal mathematical object. Does the superellipse have anything to recommend it over the FG curve in terms of these properties? Why would someone who knows nothing about the mathematics of the curves pick one or the other? Are there mathematical properties that suggest picking one or the other? Can we even distinguish the curves from each other at all if we see them without context in isolation? (Quick, is this a superellipse or an FG?)

One can ask the question, why not just use a circle. When I wrote all the continuous curvature rounding stuff someone had claimed that such rounding was what apple used for their device corners. It seems like the story always changes. But continuous curvatures really does look and feel different. In a 3d printed model you don't see a highlight where the roundover starts and it feels smoother as well. It seems likely that curvature for both FG and superellipse is continuous, though perhaps something odd happens at face centers.

So suppose we implemented everything and now we have to write a rounding tutorial and tell a user how to pick between superellipse, FG, using rect() with circular rounded corners, or using continuous curvature bezier corners. How does a user decide?

[RAMilewski]

As a user concerned primarily with designing objects, (and one who would likely be befuddled trying to work through the underlying math), I would argue for including both forms and using a flag to make the selection. That makes it possible to try both quickly and use the one that provides the best fit for the current model.

[amatulic]

It's curious that you managed a higher exponent; was this in OpenSCAD? I wrote it separately from BOSL2 to test.

Good questions.

The mathematical behavior of the curves I'd consider to be things like its derivatives, or the curvature along the curve: the properties of the curve as an ideal mathematical object. Does the superellipse have anything to recommend it over the FG curve in terms of these properties?

Well, in polar form, the derivative of r with respect to theta is a cleaner-looking expression for the superellipse than for the FG squircle (I tried both in Wolfram Alpha). For both shapes, the curvature is continuous and smoothly changing. For both shapes, nothing odd happens at face centers because the underlying mathematical functions are differentiable and the derivatives have no discontinuities.

Why would someone who knows nothing about the mathematics of the curves pick one or the other?

Someone may want the superellipse to duplicate shapes made with it (like fonts, certain buttons on devices). Aside from those who work in optics who already use the FG curve, someone else may want the FG version because literature on superellipse covers vastly more than the specific case of a squircle, and literature on the FG squircle covers exactly that.

The reason I picked FG years ago was because it was the first thing I found in polar form during a literature search for "interpolate between a circle and a square" (I didn't even know the term "squircle" at the time), and the Wikipedia article back then didn't help me figure out how to implement it in OpenSCAD, especially with all that stuff about gamma functions. I am the person who added the polar form to that article, just yesterday.

Are there mathematical properties that suggest picking one or the other?

I don't know. From my perspective, infinite exponents and overflow errors are undesirable.

Can we even distinguish the curves from each other at all if we see them without context in isolation? (Quick, is this a superellipse or an FG?)

In isolation, they are indistinguishable. Compared overlaid, the superellipse squircle is ever so slightly more rounded than the FG squircle.

One can ask the question, why not just use a circle.

These reasons come to mind:

• Efficiency. For example, a squircle-shaped dinner plate (my family had these when I was a child) holds more food but still takes up the same space on the shelf as a circular plate. For use as a physical button or a smartphone display icon, a squircle can still contain text more easily than a circle. I thought Apple used them, but looking at my wife's iPhone next to my Android phone, both look like they use rounded squares nowadays.
• Aesthetics. There's beauty in smoothly curved objects that have no flat parts. I like designing objects that make smooth transitions between shapes, like propeller blades and ergonomic handles.
• Nostalgia: Before flat-screen displays became commonplace, cathode-ray-tube television screens resembled squircles. A project to design an old-fashioned TV enclosure, in fact, is what led me to discover the FG squircle and start using it, before I even knew about BOSL2.

So suppose we implemented everything and now we have to write a rounding tutorial and tell a user how to pick between superellipse, FG, using rect() with circular rounded corners, or using continuous curvature bezier corners.

Even though I prefer FG, in light of that question, the best approach to avoid confusion would be simply to not offer FG and base the squircle on the superellipse. This maintains consistency with what BOSL2 already offers.

How does a user decide?

Continuous curvature bezier corners would be more difficult to deal with if a designer wants an attractive interpolation that can go all the way from circular to sharp square corners. I use beziers in almost all my projects, but for the recent discussion in #1514 about a basket that transitions from a square to a circle, I would want a squircle for the perimeter, not beziers. I would use beziers to control how the squircle radius changes as a function of z.

As for squircle versus square with rounded corners, this may be more of an aesthetic choice depending on the rounding. The smooth roundover could simulate a squircle with the right combination of the cut and k parameters. Using roundover to make a squircle wouldn't be my choice; I find this a bit fiddly because the two parameters aren't independent (minimum value k that doesn't produce an error depends on the value of cut).

[amatulic]

As a user concerned primarily with designing objects, (and one who would likely be befuddled trying to work through the underlying math), I would argue for including both forms and using a flag to make the selection. That makes it possible to try both quickly and use the one that provides the best fit for the current model.

Well, the thing is, they're both visually indistinguishable unless they're overlaid. Just different approaches to create a shape. Would providing two choices to accomplish effectively the same shape confuse the user?

The problem here is that I unwittingly introduced a new method to produce a squircle, when other methods to do it were already available in BOSL2, just not implemented for this specific shape with the parametric control offered by the squircle() function in this PR.

[RAMilewski]

I would argue that adding the squircle() function would still be useful. It's an issue of discoverability. For a rank beginner finding the existing squircle methods would require scrolling through the examples and stumbling upon a squircle. Nothing in either the topics index or the function index would help guide the casual user to any of the exiting methods.

[amatulic]

@RAMilewski - Oh, I think we all agree it should be there. The question now is what version of squircle() should be implemented given that they are nearly indistinguishable, or whether we should make a choice with a tag as you suggest, even though the user is unlikely to be able to tell the difference.

[adrianVmariano]

I did my numerical testing in MATLAB with r=1. In the polar case, the R value factors out so that's how the implementation works anyways. I also only spot-checked the point at 45 deg for that test so maybe it fails for some other theta at N=2000. I did the full curve in cartesian, again for r=1. It's actually sort of obvious why it works really well in the cartesian case: The equation is x^n+y^n=1, which solves to y=(1-x^n)^(1/n) and when n is too big, x^n->0, but 1^n is always 1 no matter what. So it reduces to 0 to 1/n which will be zero always until n is so big that 1/n underflows to zero, and then 1 always in the second case. Very tidy actually. Substantially less tidy in polar coordinates, unfortunately. The cartesian representation is obviously bad from a point sampling perspective.

Note that by mathematical behavior I don't mean what the expressions look like but what they do. Like what does the graph of curvature look like as a function of theta? Does one of these things have a smaller curvature than the other one, or distribute its curvature in a different way? What is the minimum/maximum curvature as a function of squareness?

I'm not sure what you mean about someone preferring the FG because "literature on superellpse covers vastly more than the specific case of a squircle."

There is no problem with overflow in computing the superellipse, only underflow, and as previously noted, in cartesian coordinates it seems to actually magically handle itself and producing the n=infinity case automatically, which is pretty tidy.

Indistinguishability in isolation is not necessarily an argument that they are completely interchangeable. It's an obvious first question to pose. Maybe a better question is whether a user can tell the difference if they flip the flag that changes the type so they see the curve flip. Heck, maybe we should support both only because nobody does that and it lets someone who is curious easily flip back and forth and see both forms and how different or not they are. Nobody has to use the flag that changes the type if they don't want to.

Note that just because the two things are similar doesn't mean we can't have both. We can make one the default, document that they are "slightly different" and let users choose. Maybe somebody seems them as markedly different, or maybe the exact shape of one interacts with a model in some way that works better for somebody.

I should have been more clear when I posed the question "why not just use a circle". What I meant was a circular rounded rectangle.

You say that continuous curvature bezier corners would be more difficult for going from circular to sharp, which I suppose is true. But since nobody should ever want actual sharp, one can counterargue that for example a rounding with maximum joint value and k going from 0 to 0.92 actually fits the bill quite well. Note that if you're trying to make the maximum width rounding you shouldn't be trying to minimize k but instead should be setting joint to the amount of space you have and then tuning k to control the shape you get.

The above shape:

klist = lerpn(0,.92,15);
p=[ for(k=klist)
      round_corners(square(10), joint=5, k=k, method="smooth")
  ];
skin(p, z=klist*6, slices=0);

It just occurred to me that you should make sure that the corner anchors are doing something reasonable in the case of non-square sizes. I am thinking "reasonable" means they point out at 45 deg and are located at the corners. I wonder if we need "box" and "perim" anchors e.g. like rect() has. Probably the answer there is yes.

[amatulic]

I did my numerical testing in OpenSCAD and couldn't get an exponent working past 236 without an error.

The graph of the curvature as a function of theta can be visualized roughly by plotting the angular difference of each line segment. I didn't do this but since both curves are differentiable (dr/dtheta) I would expect it to be smooth for both superellipse and FG until they approach a square.

I'm not sure what you mean about someone preferring the FG because "literature on superellpse covers vastly more than the specific case of a squircle."

That was my experience. There's so much information about superellipses that the thing I was looking for (interpolation of a circle with a square) landed me on sources discussing squircles, and those included the FG squircle, which seemed more straightforward in the papers I saw than the superellipse, which I noted involved an unbounded exponent.. Now that I know more, I recognize the superellipse is simple to deal with.

Heck, maybe we should support both only because nobody does that and it lets someone who is curious easily flip back and forth and see both forms and how different or not they are. Nobody has to use the flag that changes the type if they don't want to.

I agree.

I should have been more clear when I posed the question "why not just use a circle". What I meant was a circular rounded rectangle.

My answer would still be similar, aesthetics and nostalgia. There is something pleasing about the shape that a rectangle with straight sides and circular rounded corners. I agree with the point of view you expressed that a 3D printed surface without flat regions is attractive.

You say that continuous curvature bezier corners would be more difficult for going from circular to sharp, which I suppose is true. But since nobody should ever want actual sharp, one can counterargue that for example a rounding with maximum joint value and k going from 0 to 0.92 actually fits the bill quite well.

Yes, I expect so. I try not to design things with sharp corners anyway. The corner can't be sharper than the 3D printer's nozzle diameter after all.

It just occurred to me that you should make sure that the corner anchors are doing something reasonable in the case of non-square sizes.

The anchors I set are on the corners and edges of whatever squircle you make.

[adrianVmariano]

Here's my test recoded in OpenSCAD. It fails somewhere above n=2150 in OpenSCAD on my machine.

function shape(n,theta) =
  [for(t=theta)
       let (x=cos(t),
            y=sin(t),
            r=(x^n+y^n)^(1/n)
       )
       [x,y]/r
  ];
theta = lerpn(0,90,181);
path = shape(2150,theta);
stroke(path, width=.003);

Perhaps there's a complication arising in the non-square case. I really haven't thought about that case. It seems like from a computational point of view it should just be a rescale of the unit case. There may be an issue about what the squareness parameter means, though.

Note that your example is not a non-square case for displaying anchor behavior. Wait, actually you have an issue with how anchors are done. We don't want any named anchors, just the basic anchors. I think we need an atype flag and two kinds of anchors, anchors on the notional square the size specifies and anchors actually on the shape like you already have but for the second kind, you need to use the anchor override feature to specify them, not named anchors.

The question about curvature isn't whether it's smooth, which it will be since both functions are C^infinity, it's what its max and min values are. That's one thing that could distinguish the two super shapes from each other, if say the FG has a higher curvature at its point (for same parameter) you could say it's "pointier".

[amatulic]

Hmm. I'm using supershape(). I convert squareness to n for linear interpolation of the corner positions, and it fails when squareness>0.993. The size or aspect ratio have no effect. So I'm clipping it at 0.991, which is still quite sharp; you have to increase the number of points to 256 and zoom way in to see a tiny dulled corner.

As far as being pointier, you can see which one is pointier just by looking at it. Here's one quadrant:

The cyan one on the bottom is the superellipse, and the gold on top is the FG squircle. The FG clearly has a sharper corner. The difference disappears at squareness=0 or 1, of course. It's biggest at middle values.

I added a "type" parameter that can be set to "fg" (FG squircle) or "se" (superellipse) and added the superellipse. The picture above is from the new shapes2d.scad. I haven't pushed it yet.

I fixed the non-square case with anchors. I noticed that earlier today. I used named anchors because that's what reuleaux_polygon() uses. I just copied the code I saw and modified it a bit.

I'm going to bed now. I'll study the anchor documentation tomorrow.

[adrianVmariano]

Yes, if you use the extent=true "hull" type anchoring the anchors will be on the path, not on the mathematical perimeter (which is not available to the code so obviously impossible).

The yellow squircle seems to have a really large facet right around where the anchor is being placed while the rest of the visible perimeter looks smooth. Is that right?

So is this ready to be approved?

[amatulic]

That yellow squircle was made with $fn=40. That's only 10 segments per quadrant, and the segments are made smaller at the corners. So the segment there at the anchor is actually smaller than it normally would be at that $fn value. You can see this with 'show edges' enabled:

I observed that if $fn is divisible by 8, the anchors line up with the superellipse anchors. At least for this case. I may as well change the default $fn anyway.

Not yet ready -- I have to remove all the stuff about anchor overrides, then I'll do a bit more testing, and push another commit.

Hard to believe I spent a couple of days on this only to delete it all, but at least I learned a lot, and I appreciate that.

[adrianVmariano]

I kinda feel a little guilty about having lead you on a run-around on the anchoring business here. Sorry about that. I'll admit that it seems pretty routine that adding some new object is 10% coding the object and 90% coding either the anchors or the parameter error checking and parameter processing, or the docs writing, or some other indirect thing relating to the object rather than the object itself. Someone recently asked for ring() which was in that category, where making a ring is trivial, but doing all the argument checking for all the cases...ug.

Wouldn't the alignment to superellipse anchors depend on the step size used for the superellipse? If you configure them to match then they should line up...otherwise no.

It seems like there's a sharp corner in the example above right where the anchor connects. It's a little easier to see what's happening if you view 2d stuff directly from above (e.g. click on the z+ view). But I'm sure it gets better with higher $fn, so I doubt there's anything worrisome there.

[amatulic]

Yes, that sharper corner is an artifact of low $fn. I agree the alignment with supershape likely depends on step size, but in any case a high value of $fn makes them align quite well. Hmm, I should have it change dynamically like it does with circle(), with more steps for larger shapes.

Don't feel guilty, I appreciate the knowledge, and it was valuable for me to learn about function literals, which in all the years I've been working with OpenSCAD, I never noticed before but often wished for such a capability.

[adrianVmariano]

I'm not sure what you mean about dynamic change "like circle(), with more steps for larger shapes". That is if you use $fa and $fs. With $fn, circle always gives you the specified number of facets.

[adrianVmariano]

BTW, function literals were only added in 2021. But hang out with us library authors and we'll teach you all the OpenSCAD tricks. :)

[amatulic]

I mean if you don't specify $fn, a circle changes the number of segments depending on the size of the circle (at least for small circles), because it uses $fa=12 together with $fs=2 by default. I thought I might increase the resolution of the squircle if $fn isn't set, based on the radius of the circle when squareness=0.

[adrianVmariano]

Your original stated plan was to respect only $fn. It seems reasonable to respect $fa and $fs based on the circle corresponding to the specified size, though it's not entirely obvious how to handle that for ellipses. I looked at ellipse(). It treats the largest semi-axis as the effective radius for calculating the number of segments of the curve.

There is infrastructure in place to do this in BOSL2 with the segs() function.

[amatulic]

I am hopelessly confused now. I'm obviously missing something. Three times now, I've restored the original code and change it a bit at a time, and at some point it stops respecting the atype="perim", and I don't know what I did. Here's the module and function. Does anything jump out at you?

module squircle(squareness=0.5, size=[1,1], style="fg", atype="box", anchor=CENTER, spin=0) {
    check = assert(squareness >= 0 && squareness <= 1);
    anchorchk = assert(in_list(atype, ["box", "perim"]));
    size = is_num(size) ? [size,size] : point2d(size);
    assert(all_positive(size), "All components of size must be positive.");
    path = squircle(squareness, size, style, atype); // pass without anchor or spin
    if (atype == "box") {
        attachable(anchor, spin, two_d=true, size=size, extent=false) {
            polygon(path);
            children();
        }
    } else { // atype=="perim"
        attachable(anchor, spin, two_d=true, size=size, extent=true, path=path) {
            polygon(path);
            children();
        }
    }
}


function squircle(squareness=0.5, size=[1,1], style="fg", atype="box", anchor=CENTER, spin=0) =
    assert(squareness >= 0 && squareness <= 1)
    assert(is_num(size) || is_vector(size,2))
    assert(in_list(atype, ["box", "perim"]))
    let(
        size = is_num(size) ? [size,size] : point2d(size),
        path = style == "fg" ? _squircle_fg(squareness, size)
            : style == "superellipse" ? _squircle_se(squareness, size)
            : assert(false, "Style must be \"fg\" or \"superellipse\""),
    ) reorient(anchor, spin, two_d=true, size=size, p=path, extent=atype=="perim");

[adrianVmariano]

You are giving a size argument to attachable() in the "perim" branch, that case I specifically warned about earlier where the code decides it's going to "do something" instead of failing with an assert when giving conflicting inputs. (Are you convinced yet that this "do something" strategy is a terrible idea?)

Unrelated: I would prefer not to have a default for size. Revar is more a fan of defaults like that. I tend to think they're random and arbitrary and the user should say what they mean. But rect() does have a default so you can choose to follow rect if you prefer.

[amatulic]

Ah, that was it, the size. I wonder why I didn't see it. That fixed the module, but calling the function to use with polygon() still acts like it's using atype="box". If I remove the size perameter from reorient(), it centers the shape but still rotates it.

As for defaults, I did that because OpenSCAD uses a default size for things like square() and circle(). I can remove it, however.

[adrianVmariano]

I notice you didn't say whether your perspective on asserting for conflicting inputs has changed.

I'm not sure what you mean about the function case. If you remove the size parameter to reorient in the atype=="perim" case is something wrong? And if so, what exactly? Are you saying the shape comes out centered regardless of the anchor value? (Of course you need the size parameter for the "box" case.)

I would maybe not pass atype when invoking the function form from the module. It's presumably best to have the simpler anchor case run, though I'm not sure it makes any difference since you just get the center anchor.

I think you can set extent to true unconditionally because it's only used when no size is given. But in the module form I would not set extent in the "box" branch just because it's confusing to pass a parameter that's not used.

[amatulic]

"Perspective for asserting for conflicting inputs". I am asserting for conflicting inputs, rather than falling back to defaults. Regardless of my own way of coding, I want to do whatever is considered best practice by this project.

Yellow is the module, outline is the polygon, both using the same anchor and atype.

[amatulic]

As soon as I submit my last comment, I figure out the problem.

It works with supershape. In reorient(), the supershape function sets two parameters, p and path, to path. It also omits the size. My call to reorient() was left over from the older override anchor code, setting size and p but not path. I did it like supershape, and it all works now.

Correction: now "box" broke with the polygon....

[adrianVmariano]

Are you doing something like size=atype=="perim"?undef:size to pass the size to reorient as undef in the perim case and the actual size in the box case?

I had forgotten you had to pass the path twice. I think it's one time for purposes of anchoring and one time to just be the path that gets processed, so you don't have to use the path as the anchoring method.

[amatulic]

I ended up doing it like this:

reorient(anchor, spin, two_d=true, size=atype=="box"?size:undef, path=_module_call?undef:path, p=path, extent=true);

I had to add a parameter _module_call to the function because if you set both p and path when calling it from the module, the shape is positioned incorrectly. size depends on atype, and extent=true works in all cases.

[amatulic]

All right. I have pushed the latest changes. Have a look. No hurry.
Now I can continue testing vnf_tri_array() and make new examples.

[revarbat]

Of note, circle() and square() have default sizes in raw OpenSCAD, so BOSL2's overrides for those should match that behavior. Whether rect() or other BOSL2 originals should have size defaults is a separate argument.

[revarbat]

I used to be of the opinion that args should have "reasonable" defaults. But that gets nonsensical sometimes, and my idea of reasonable is not necessarily the most usable or sensible for all situations. I'm starting to turn to the dark side of not giving defaults, but giving examples that seem sensible to me.

[amatulic]

I can't say I understand those test results. There's a syntax error being reported in shapes2d.scad, referencing a variable name that was used in an older commit but no longer exists, making me think the tests weren't run on the most recent commit.

[adrianVmariano]

You have a trailing comma on line 2054 in the let statement. That is not allowed in the stable version 2021.01. Since that's the official stable version, everything needs to work there, and the trailing comma thing is one of the big irritations, most definitely.

BTW, you shouldn't need that _module_version or whatever it was flag. Just make sure to pass atype="box" when invoking from the module. Don't pass the actual user-specified atype.

[amatulic]

I just pushed a new commit. And then I pushed another after I remembered I still wasn't using 2021.01 and found another trailing comma. I have both 2021.01 and a more recent version of OpenSCAD installed here, but I've been using a more recent one lately due to a new feature required in other projects. Otherwise, I try to write compatibly with 2021.01 also.

[amatulic]

Hopfully that last commit passes the tests. I was using "Examples" instead of "Example" for a multi-line code example.

[amatulic]

Sigh. Another error in the documentation comments. A bad internal link. OK, I pushed another fix.