[BUG] offset(path,...) weird results with fixed $fn

[pipatron]

I realized BOSL2 offset(path,r=…) does not use $fs and $fa the same way as OpenSCAD offset(r=…) CHILDREN; so I tried using $fn with weird results. I don't know if this is a bug exactly, but it's very unexpected and it prevents me to get control over the relative number of faces for rounding — it seems to be mostly all-or-nothing.

I tried to demonstrate the problem with the following code:

include <BOSL2/std.scad>
rainbow([0,1,2,3,4])
  let(fn=3+$item*2)
    for(y=[0:3])
      move([$item,y]*25)
        let(path=offset(regular_ngon(3+y*2,5),r=5,$fn=fn)) {
          stroke(path,width=0.5,joints="dot",closed=true);
          text(str("$fn=",fn),halign="center",valign="center",size=4);
        }

It shows what happens when trying to offset different polygons using different $fn, somewhat arbitrarily chosen to show the problem. Unfortunately I couldn't understand the source code for offset(), it was a lot more code than I expected!

I think that ideally it should work the same or similar to OpenSCAD built-in offset() with more gradual increase of edges, at least in the same ballpark/

• OpenSCAD 2025.08.12.nightly
• BOSL2 e940b69

[adrianVmariano]

Offset is a difficult thing to implement. Looks like the code is using 3 more points than it should for the curves.

[adrianVmariano]

I'm not sure I know how to reliably match the openscad facet count for an incomplete circle.

[pipatron]

The most crazy is the case where $fn is the same as the number of points. What's going on with, say, the pentagon with $fn=5?

The problem is that this also happens in every-day situations by just using $fs and $fa like normal people. Here is a different example with just a pentagon, OpenSCAD offset() and BOSL2 offset() with different $fs settings:

include <BOSL2/std.scad>
$fa = 0.01;
rainbow([1,4,8,50])
  right($idx*25,$fs=$item) {
    p = pentagon(5);
    fwd(0*25) region(p);
    fwd(1*25) offset(r=5) region(p);
    fwd(2*25) stroke(offset(p,r=5),width=0.5,joints="dot",closed=true);
    fwd(2*25) text(str("$fs=",$item),size=3,halign="center",valign="center");
  }

There is obviously a lower limit, but that limit still cause very weird behavior. It's like the points aren't distributed correctly, or some round-off error causes either a bunch of rounding or nothing.

I would consider that to be an actual bug that would cause a model to look ugly or distorted.

[adrianVmariano]

I think requesting $fn equal to the number of polygon sides is kind of questionable. That means you want one facet on each round surface. The computation at present adds 3 to the number of points on the corner, but only if that number of points is at least 2. The computation is a floor that is supposed to yield 2, but it's actually exactly 2, so presumably it lands below 2 sometimes, and you get 1 instead. So due to the adding 3 business you'll either get a corner, or you'll get a 5 point arc. Should it be a round instead of floor? As noted above, I don't know what OpenSCAD actually does. (I do know that it doesn't add 3 though.)

[adrianVmariano]

I have a fix for this issue, which makes the offset() function act like the offset() module. Unfortunately, it breaks many offset_sweep examples. In the old code, if angles were small enough you got zero added points, like happened occasionally in the examples above. That meant that offset sweep, which uses iterated calls to offset, worked fine. But now it's always creating two points at every corner, which means you get exponential doubling, which ultimately causes offset_sweep to fail.

I'm not sure what the solution is to this. I can tell you "don't use rounding, only delta, with offset_sweep" but that seems not ideal. Maybe an option to offset to let it produce corners?

[pipatron]

Thanks! The patch that makes segs() take an angle argument is something I've been missing for a long time but too afraid to suggest.

I have no strong feelings about offset() leaving some corners intact, if the other corners are rounded with only one segment. I'm sure this patch is an improvement to the previous algorithm, and any new problems can be dealt with accordingly.

[adrianVmariano]

Don't be afraid to suggest things. We might say "no" but there's no harm done.

The current version should match the behavior of OpenSCAD, which means with r= you always get at least one facet on any expanding corner. That means you get exponential growth if you iterate offset on an input. I have a private option that decreases the output facet count by 1, which means that when the angle is small enough, you get a corner with no facet. That cuts off the exponential explosion. If there's reason to believe users would want it---and we can think of a name for the option---I could make it into a public option.

I think behavior where you have a bunch of congruent corners and they get treated differently is best considered a bug.