Hi,

Guest

JB

Jordan Brown

Fri, Sep 20, 2024 2:38 AM

Mostly, you want to use $fa and $fs and let OpenSCAD figure out the

number of sides that circles should have.

However, if you are trying to join a circle (or other circular shape) to

a rectangular shape, you probably want the vertices on the circle to

align with the vertices on the rectangle.

Here's a deliberately low-circular-resolution shape to demonstrate the

problem:

```
$fa = 10;
$fs = 5;
size = 10;
translate([size, size/2]) circle(d=size);
square(size);
```

With those parameters, the circle ends up a 7-gon, and doesn't mate well

with the square:

If we assume that nobody depends on $fa/$fs using exactly the current

formula, we could make it round up to a multiple of 4, turning the

circle above into an octagon:

... which mates a lot better. The same principle applies at any size.

If the result is not a multiple of 4, the circle won't mate well with a

rectangle; there will be a slight artifact at the join. Today, if you

want to avoid this artifact you have to set $fn explicitly, perhaps

calculating it from $fa and $fs and rounding.

It's a little hard to see anybody depending on the formula used for

$fa/$fs. If we were to round the result up to a multiple of four, a

bunch of artifacts would just go away without needing explicit

calculation in the model.

No scheme will make them mate well when the rectangular edge is at an

arbitrary angle, but multiple-of-four will make them mate well with

horizontal and vertical lines, and of course it'll stay good if you then

rotate the whole assembly. (Or if you're trying to match a rotated

line, and you rotate the circle the same way.)

Unfortunately, it's not inconceivable that somebody might depend on the

formula - in particular, to predict the shape of a circle and then

adjust geometry to match. (They'd probably be better off calculating

the equivalent $fn and using that explicitly, rather than trying to

match the results of the internal calculation, but...)

I think it's worth the small compatibility hiccup. What do others think?

Mostly, you want to use $fa and $fs and let OpenSCAD figure out the
number of sides that circles should have.
However, if you are trying to join a circle (or other circular shape) to
a rectangular shape, you probably want the vertices on the circle to
align with the vertices on the rectangle.
Here's a deliberately low-circular-resolution shape to demonstrate the
problem:
$fa = 10;
$fs = 5;
size = 10;
translate([size, size/2]) circle(d=size);
square(size);
With those parameters, the circle ends up a 7-gon, and doesn't mate well
with the square:
If we assume that nobody depends on $fa/$fs using exactly the current
formula, we could make it round up to a multiple of 4, turning the
circle above into an octagon:
... which mates a lot better. The same principle applies at any size.
If the result is not a multiple of 4, the circle won't mate well with a
rectangle; there will be a slight artifact at the join. Today, if you
want to avoid this artifact you have to set $fn explicitly, perhaps
calculating it from $fa and $fs and rounding.
It's a little hard to see anybody depending on the formula used for
$fa/$fs. If we were to round the result up to a multiple of four, a
bunch of artifacts would just go away without needing explicit
calculation in the model.
No scheme will make them mate well when the rectangular edge is at an
arbitrary angle, but multiple-of-four will make them mate well with
horizontal and vertical lines, and of course it'll stay good if you then
rotate the whole assembly. (Or if you're trying to match a rotated
line, and you rotate the circle the same way.)
Unfortunately, it's not inconceivable that somebody might depend on the
formula - in particular, to predict the shape of a circle and then
adjust geometry to match. (They'd probably be better off calculating
the equivalent $fn and using that explicitly, rather than trying to
match the results of the internal calculation, but...)
I think it's worth the small compatibility hiccup. What do others think?

AM

Adrian Mariano

Fri, Sep 20, 2024 3:23 AM

It seems reasonable to me. Of course, it would break stuff in BOSL2 where

we want to ensure that we match things that users have made using $fa/$fs.

There's another thing, which is that I think if $fn is a multiple of 4 then

the circle actually reaches its advertised radius on the four axes, which

is also a desirable property.

On Thu, Sep 19, 2024 at 10:39 PM Jordan Brown via Discuss <

discuss@lists.openscad.org> wrote:

Mostly, you want to use $fa and $fs and let OpenSCAD figure out the number

of sides that circles should have.

However, if you are trying to join a circle (or other circular shape) to a

rectangular shape, you probably want the vertices on the circle to align

with the vertices on the rectangle.

Here's a deliberately low-circular-resolution shape to demonstrate the

problem:

$fa = 10;

$fs = 5;

size = 10;

translate([size, size/2]) circle(d=size);

square(size);

With those parameters, the circle ends up a 7-gon, and doesn't mate well

with the square:

If we assume that nobody depends on $fa/$fs using exactly the current

formula, we could make it round up to a multiple of 4, turning the circle

above into an octagon:

... which mates a lot better. The same principle applies at any size. If

the result is not a multiple of 4, the circle won't mate well with a

rectangle; there will be a slight artifact at the join. Today, if you want

to avoid this artifact you have to set $fn explicitly, perhaps calculating

it from $fa and $fs and rounding.

It's a little hard to see anybody depending on the formula used for

$fa/$fs. If we were to round the result up to a multiple of four, a bunch

of artifacts would just go away without needing explicit calculation in the

model.

No scheme will make them mate well when the rectangular edge is at an

arbitrary angle, but multiple-of-four will make them mate well with

horizontal and vertical lines, and of course it'll stay good if you then

rotate the whole assembly. (Or if you're trying to match a rotated line,

and you rotate the circle the same way.)

Unfortunately, it's not inconceivable that somebody might depend on the

formula - in particular, to predict the shape of a circle and then adjust

geometry to match. (They'd probably be better off calculating the

equivalent $fn and using that explicitly, rather than trying to match the

results of the internal calculation, but...)

I think it's worth the small compatibility hiccup. What do others think?

OpenSCAD mailing list

To unsubscribe send an email to discuss-leave@lists.openscad.org

It seems reasonable to me. Of course, it would break stuff in BOSL2 where
we want to ensure that we match things that users have made using $fa/$fs.
There's another thing, which is that I think if $fn is a multiple of 4 then
the circle actually reaches its advertised radius on the four axes, which
is also a desirable property.
On Thu, Sep 19, 2024 at 10:39 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
> Mostly, you want to use $fa and $fs and let OpenSCAD figure out the number
> of sides that circles should have.
>
> However, if you are trying to join a circle (or other circular shape) to a
> rectangular shape, you probably want the vertices on the circle to align
> with the vertices on the rectangle.
>
> Here's a deliberately low-circular-resolution shape to demonstrate the
> problem:
>
> $fa = 10;
> $fs = 5;
> size = 10;
> translate([size, size/2]) circle(d=size);
> square(size);
>
> With those parameters, the circle ends up a 7-gon, and doesn't mate well
> with the square:
>
>
> If we assume that nobody depends on $fa/$fs using exactly the current
> formula, we could make it round up to a multiple of 4, turning the circle
> above into an octagon:
>
>
> ... which mates a lot better. The same principle applies at any size. If
> the result is not a multiple of 4, the circle won't mate well with a
> rectangle; there will be a slight artifact at the join. Today, if you want
> to avoid this artifact you have to set $fn explicitly, perhaps calculating
> it from $fa and $fs and rounding.
>
> It's a little hard to see anybody depending on the formula used for
> $fa/$fs. If we were to round the result up to a multiple of four, a bunch
> of artifacts would just go away without needing explicit calculation in the
> model.
>
> No scheme will make them mate well when the rectangular edge is at an
> arbitrary angle, but multiple-of-four will make them mate well with
> horizontal and vertical lines, and of course it'll stay good if you then
> rotate the whole assembly. (Or if you're trying to match a rotated line,
> and you rotate the circle the same way.)
>
>
> Unfortunately, it's not inconceivable that somebody might depend on the
> formula - in particular, to predict the shape of a circle and then adjust
> geometry to match. (They'd probably be better off calculating the
> equivalent $fn and using that explicitly, rather than trying to match the
> results of the internal calculation, but...)
>
>
> I think it's worth the small compatibility hiccup. What do others think?
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>

T

tjhowse

Fri, Sep 20, 2024 3:38 AM

I'm reasonably sure I've used $fn = 3 to make triangular prisms. I wouldn't

want this to break, directly or indirectly.

As an aside, I've just learned from the docs that the following is possible

to use two different values between previewing and rendering a model:

$fn = $preview ? 32 : 64;

Amazing stuff! Wish I'd learned that ten years ago. :D

On Fri, 20 Sept 2024 at 13:24, Adrian Mariano via Discuss <

discuss@lists.openscad.org> wrote:

It seems reasonable to me. Of course, it would break stuff in BOSL2 where

we want to ensure that we match things that users have made using $fa/$fs.

There's another thing, which is that I think if $fn is a multiple of 4

then the circle actually reaches its advertised radius on the four axes,

which is also a desirable property.

On Thu, Sep 19, 2024 at 10:39 PM Jordan Brown via Discuss <

discuss@lists.openscad.org> wrote:

Mostly, you want to use $fa and $fs and let OpenSCAD figure out the

number of sides that circles should have.

However, if you are trying to join a circle (or other circular shape) to

a rectangular shape, you probably want the vertices on the circle to align

with the vertices on the rectangle.

Here's a deliberately low-circular-resolution shape to demonstrate the

problem:

$fa = 10;

$fs = 5;

size = 10;

translate([size, size/2]) circle(d=size);

square(size);

With those parameters, the circle ends up a 7-gon, and doesn't mate well

with the square:

If we assume that nobody depends on $fa/$fs using exactly the current

formula, we could make it round up to a multiple of 4, turning the circle

above into an octagon:

... which mates a lot better. The same principle applies at any size.

If the result is not a multiple of 4, the circle won't mate well with a

rectangle; there will be a slight artifact at the join. Today, if you want

to avoid this artifact you have to set $fn explicitly, perhaps calculating

it from $fa and $fs and rounding.

It's a little hard to see anybody depending on the formula used for

$fa/$fs. If we were to round the result up to a multiple of four, a bunch

of artifacts would just go away without needing explicit calculation in the

model.

No scheme will make them mate well when the rectangular edge is at an

arbitrary angle, but multiple-of-four will make them mate well with

horizontal and vertical lines, and of course it'll stay good if you then

rotate the whole assembly. (Or if you're trying to match a rotated line,

and you rotate the circle the same way.)

Unfortunately, it's not inconceivable that somebody might depend on the

formula - in particular, to predict the shape of a circle and then adjust

geometry to match. (They'd probably be better off calculating the

equivalent $fn and using that explicitly, rather than trying to match the

results of the internal calculation, but...)

I think it's worth the small compatibility hiccup. What do others think?

OpenSCAD mailing list

To unsubscribe send an email to discuss-leave@lists.openscad.org

OpenSCAD mailing list

To unsubscribe send an email to discuss-leave@lists.openscad.org

I'm reasonably sure I've used $fn = 3 to make triangular prisms. I wouldn't
want this to break, directly or indirectly.
As an aside, I've just learned from the docs that the following is possible
to use two different values between previewing and rendering a model:
$fn = $preview ? 32 : 64;
Amazing stuff! Wish I'd learned that ten years ago. :D
On Fri, 20 Sept 2024 at 13:24, Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
> It seems reasonable to me. Of course, it would break stuff in BOSL2 where
> we want to ensure that we match things that users have made using $fa/$fs.
>
> There's another thing, which is that I think if $fn is a multiple of 4
> then the circle actually reaches its advertised radius on the four axes,
> which is also a desirable property.
>
> On Thu, Sep 19, 2024 at 10:39 PM Jordan Brown via Discuss <
> discuss@lists.openscad.org> wrote:
>
>> Mostly, you want to use $fa and $fs and let OpenSCAD figure out the
>> number of sides that circles should have.
>>
>> However, if you are trying to join a circle (or other circular shape) to
>> a rectangular shape, you probably want the vertices on the circle to align
>> with the vertices on the rectangle.
>>
>> Here's a deliberately low-circular-resolution shape to demonstrate the
>> problem:
>>
>> $fa = 10;
>> $fs = 5;
>> size = 10;
>> translate([size, size/2]) circle(d=size);
>> square(size);
>>
>> With those parameters, the circle ends up a 7-gon, and doesn't mate well
>> with the square:
>>
>>
>> If we assume that nobody depends on $fa/$fs using exactly the current
>> formula, we could make it round up to a multiple of 4, turning the circle
>> above into an octagon:
>>
>>
>> ... which mates a lot better. The same principle applies at any size.
>> If the result is not a multiple of 4, the circle won't mate well with a
>> rectangle; there will be a slight artifact at the join. Today, if you want
>> to avoid this artifact you have to set $fn explicitly, perhaps calculating
>> it from $fa and $fs and rounding.
>>
>> It's a little hard to see anybody depending on the formula used for
>> $fa/$fs. If we were to round the result up to a multiple of four, a bunch
>> of artifacts would just go away without needing explicit calculation in the
>> model.
>>
>> No scheme will make them mate well when the rectangular edge is at an
>> arbitrary angle, but multiple-of-four will make them mate well with
>> horizontal and vertical lines, and of course it'll stay good if you then
>> rotate the whole assembly. (Or if you're trying to match a rotated line,
>> and you rotate the circle the same way.)
>>
>>
>> Unfortunately, it's not inconceivable that somebody might depend on the
>> formula - in particular, to predict the shape of a circle and then adjust
>> geometry to match. (They'd probably be better off calculating the
>> equivalent $fn and using that explicitly, rather than trying to match the
>> results of the internal calculation, but...)
>>
>>
>> I think it's worth the small compatibility hiccup. What do others think?
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>

AM

Adrian Mariano

Fri, Sep 20, 2024 3:41 AM

He's only suggesting changing $fa/$fs behavior, not explicit specification

with $fn where maybe you *want* a heptagon.

On Thu, Sep 19, 2024 at 11:40 PM tjhowse via Discuss <

discuss@lists.openscad.org> wrote:

I'm reasonably sure I've used $fn = 3 to make triangular prisms. I

wouldn't want this to break, directly or indirectly.

As an aside, I've just learned from the docs that the following is

possible to use two different values between previewing and rendering a

model:

$fn = $preview ? 32 : 64;

Amazing stuff! Wish I'd learned that ten years ago. :D

On Fri, 20 Sept 2024 at 13:24, Adrian Mariano via Discuss <

discuss@lists.openscad.org> wrote:

It seems reasonable to me. Of course, it would break stuff in BOSL2

where we want to ensure that we match things that users have made using

$fa/$fs.

There's another thing, which is that I think if $fn is a multiple of 4

then the circle actually reaches its advertised radius on the four axes,

which is also a desirable property.

On Thu, Sep 19, 2024 at 10:39 PM Jordan Brown via Discuss <

discuss@lists.openscad.org> wrote:

number of sides that circles should have.

a rectangular shape, you probably want the vertices on the circle to align

with the vertices on the rectangle.

Here's a deliberately low-circular-resolution shape to demonstrate the

problem:

$fa = 10;

$fs = 5;

size = 10;

translate([size, size/2]) circle(d=size);

square(size);

With those parameters, the circle ends up a 7-gon, and doesn't mate well

with the square:

formula, we could make it round up to a multiple of 4, turning the circle

above into an octagon:

If the result is not a multiple of 4, the circle won't mate well with a

rectangle; there will be a slight artifact at the join. Today, if you want

to avoid this artifact you have to set $fn explicitly, perhaps calculating

it from $fa and $fs and rounding.

$fa/$fs. If we were to round the result up to a multiple of four, a bunch

of artifacts would just go away without needing explicit calculation in the

model.

arbitrary angle, but multiple-of-four will make them mate well with

horizontal and vertical lines, and of course it'll stay good if you then

rotate the whole assembly. (Or if you're trying to match a rotated line,

and you rotate the circle the same way.)

formula - in particular, to predict the shape of a circle and then adjust

geometry to match. (They'd probably be better off calculating the

equivalent $fn and using that explicitly, rather than trying to match the

results of the internal calculation, but...)

I think it's worth the small compatibility hiccup. What do others think?

OpenSCAD mailing list

To unsubscribe send an email to discuss-leave@lists.openscad.org

OpenSCAD mailing list

To unsubscribe send an email to discuss-leave@lists.openscad.org

OpenSCAD mailing list

To unsubscribe send an email to discuss-leave@lists.openscad.org

He's only suggesting changing $fa/$fs behavior, not explicit specification
with $fn where maybe you *want* a heptagon.
On Thu, Sep 19, 2024 at 11:40 PM tjhowse via Discuss <
discuss@lists.openscad.org> wrote:
> I'm reasonably sure I've used $fn = 3 to make triangular prisms. I
> wouldn't want this to break, directly or indirectly.
>
> As an aside, I've just learned from the docs that the following is
> possible to use two different values between previewing and rendering a
> model:
>
> $fn = $preview ? 32 : 64;
>
> Amazing stuff! Wish I'd learned that ten years ago. :D
>
> On Fri, 20 Sept 2024 at 13:24, Adrian Mariano via Discuss <
> discuss@lists.openscad.org> wrote:
>
>> It seems reasonable to me. Of course, it would break stuff in BOSL2
>> where we want to ensure that we match things that users have made using
>> $fa/$fs.
>>
>> There's another thing, which is that I think if $fn is a multiple of 4
>> then the circle actually reaches its advertised radius on the four axes,
>> which is also a desirable property.
>>
>> On Thu, Sep 19, 2024 at 10:39 PM Jordan Brown via Discuss <
>> discuss@lists.openscad.org> wrote:
>>
>>> Mostly, you want to use $fa and $fs and let OpenSCAD figure out the
>>> number of sides that circles should have.
>>>
>>> However, if you are trying to join a circle (or other circular shape) to
>>> a rectangular shape, you probably want the vertices on the circle to align
>>> with the vertices on the rectangle.
>>>
>>> Here's a deliberately low-circular-resolution shape to demonstrate the
>>> problem:
>>>
>>> $fa = 10;
>>> $fs = 5;
>>> size = 10;
>>> translate([size, size/2]) circle(d=size);
>>> square(size);
>>>
>>> With those parameters, the circle ends up a 7-gon, and doesn't mate well
>>> with the square:
>>>
>>>
>>> If we assume that nobody depends on $fa/$fs using exactly the current
>>> formula, we could make it round up to a multiple of 4, turning the circle
>>> above into an octagon:
>>>
>>>
>>> ... which mates a lot better. The same principle applies at any size.
>>> If the result is not a multiple of 4, the circle won't mate well with a
>>> rectangle; there will be a slight artifact at the join. Today, if you want
>>> to avoid this artifact you have to set $fn explicitly, perhaps calculating
>>> it from $fa and $fs and rounding.
>>>
>>> It's a little hard to see anybody depending on the formula used for
>>> $fa/$fs. If we were to round the result up to a multiple of four, a bunch
>>> of artifacts would just go away without needing explicit calculation in the
>>> model.
>>>
>>> No scheme will make them mate well when the rectangular edge is at an
>>> arbitrary angle, but multiple-of-four will make them mate well with
>>> horizontal and vertical lines, and of course it'll stay good if you then
>>> rotate the whole assembly. (Or if you're trying to match a rotated line,
>>> and you rotate the circle the same way.)
>>>
>>>
>>> Unfortunately, it's not inconceivable that somebody might depend on the
>>> formula - in particular, to predict the shape of a circle and then adjust
>>> geometry to match. (They'd probably be better off calculating the
>>> equivalent $fn and using that explicitly, rather than trying to match the
>>> results of the internal calculation, but...)
>>>
>>>
>>> I think it's worth the small compatibility hiccup. What do others think?
>>>
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>

NH

nop head

Fri, Sep 20, 2024 6:00 AM

I just have a circle4n() module in my library and I have redefined sphere()

to use it.

On Fri, 20 Sept 2024 at 04:41, Adrian Mariano via Discuss <

discuss@lists.openscad.org> wrote:

He's only suggesting changing $fa/$fs behavior, not explicit specification

with $fn where maybe you *want* a heptagon.

On Thu, Sep 19, 2024 at 11:40 PM tjhowse via Discuss <

discuss@lists.openscad.org> wrote:

I'm reasonably sure I've used $fn = 3 to make triangular prisms. I

wouldn't want this to break, directly or indirectly.

As an aside, I've just learned from the docs that the following is

possible to use two different values between previewing and rendering a

model:

$fn = $preview ? 32 : 64;

Amazing stuff! Wish I'd learned that ten years ago. :D

On Fri, 20 Sept 2024 at 13:24, Adrian Mariano via Discuss <

discuss@lists.openscad.org> wrote:

where we want to ensure that we match things that users have made using

$fa/$fs.

then the circle actually reaches its advertised radius on the four axes,

which is also a desirable property.

On Thu, Sep 19, 2024 at 10:39 PM Jordan Brown via Discuss <

discuss@lists.openscad.org> wrote:

number of sides that circles should have.

to a rectangular shape, you probably want the vertices on the circle to

align with the vertices on the rectangle.

Here's a deliberately low-circular-resolution shape to demonstrate the

problem:

$fa = 10;

$fs = 5;

size = 10;

translate([size, size/2]) circle(d=size);

square(size);

With those parameters, the circle ends up a 7-gon, and doesn't mate

well with the square:

formula, we could make it round up to a multiple of 4, turning the circle

above into an octagon:

If the result is not a multiple of 4, the circle won't mate well with a

rectangle; there will be a slight artifact at the join. Today, if you want

to avoid this artifact you have to set $fn explicitly, perhaps calculating

it from $fa and $fs and rounding.

$fa/$fs. If we were to round the result up to a multiple of four, a bunch

of artifacts would just go away without needing explicit calculation in the

model.

arbitrary angle, but multiple-of-four will make them mate well with

horizontal and vertical lines, and of course it'll stay good if you then

rotate the whole assembly. (Or if you're trying to match a rotated line,

and you rotate the circle the same way.)

formula - in particular, to predict the shape of a circle and then adjust

geometry to match. (They'd probably be better off calculating the

equivalent $fn and using that explicitly, rather than trying to match the

results of the internal calculation, but...)

I think it's worth the small compatibility hiccup. What do others

think?

OpenSCAD mailing list

To unsubscribe send an email to discuss-leave@lists.openscad.org

OpenSCAD mailing list

To unsubscribe send an email to discuss-leave@lists.openscad.org

OpenSCAD mailing list

To unsubscribe send an email to discuss-leave@lists.openscad.org

OpenSCAD mailing list

To unsubscribe send an email to discuss-leave@lists.openscad.org

I just have a circle4n() module in my library and I have redefined sphere()
to use it.
On Fri, 20 Sept 2024 at 04:41, Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
> He's only suggesting changing $fa/$fs behavior, not explicit specification
> with $fn where maybe you *want* a heptagon.
>
> On Thu, Sep 19, 2024 at 11:40 PM tjhowse via Discuss <
> discuss@lists.openscad.org> wrote:
>
>> I'm reasonably sure I've used $fn = 3 to make triangular prisms. I
>> wouldn't want this to break, directly or indirectly.
>>
>> As an aside, I've just learned from the docs that the following is
>> possible to use two different values between previewing and rendering a
>> model:
>>
>> $fn = $preview ? 32 : 64;
>>
>> Amazing stuff! Wish I'd learned that ten years ago. :D
>>
>> On Fri, 20 Sept 2024 at 13:24, Adrian Mariano via Discuss <
>> discuss@lists.openscad.org> wrote:
>>
>>> It seems reasonable to me. Of course, it would break stuff in BOSL2
>>> where we want to ensure that we match things that users have made using
>>> $fa/$fs.
>>>
>>> There's another thing, which is that I think if $fn is a multiple of 4
>>> then the circle actually reaches its advertised radius on the four axes,
>>> which is also a desirable property.
>>>
>>> On Thu, Sep 19, 2024 at 10:39 PM Jordan Brown via Discuss <
>>> discuss@lists.openscad.org> wrote:
>>>
>>>> Mostly, you want to use $fa and $fs and let OpenSCAD figure out the
>>>> number of sides that circles should have.
>>>>
>>>> However, if you are trying to join a circle (or other circular shape)
>>>> to a rectangular shape, you probably want the vertices on the circle to
>>>> align with the vertices on the rectangle.
>>>>
>>>> Here's a deliberately low-circular-resolution shape to demonstrate the
>>>> problem:
>>>>
>>>> $fa = 10;
>>>> $fs = 5;
>>>> size = 10;
>>>> translate([size, size/2]) circle(d=size);
>>>> square(size);
>>>>
>>>> With those parameters, the circle ends up a 7-gon, and doesn't mate
>>>> well with the square:
>>>>
>>>>
>>>> If we assume that nobody depends on $fa/$fs using exactly the current
>>>> formula, we could make it round up to a multiple of 4, turning the circle
>>>> above into an octagon:
>>>>
>>>>
>>>> ... which mates a lot better. The same principle applies at any size.
>>>> If the result is not a multiple of 4, the circle won't mate well with a
>>>> rectangle; there will be a slight artifact at the join. Today, if you want
>>>> to avoid this artifact you have to set $fn explicitly, perhaps calculating
>>>> it from $fa and $fs and rounding.
>>>>
>>>> It's a little hard to see anybody depending on the formula used for
>>>> $fa/$fs. If we were to round the result up to a multiple of four, a bunch
>>>> of artifacts would just go away without needing explicit calculation in the
>>>> model.
>>>>
>>>> No scheme will make them mate well when the rectangular edge is at an
>>>> arbitrary angle, but multiple-of-four will make them mate well with
>>>> horizontal and vertical lines, and of course it'll stay good if you then
>>>> rotate the whole assembly. (Or if you're trying to match a rotated line,
>>>> and you rotate the circle the same way.)
>>>>
>>>>
>>>> Unfortunately, it's not inconceivable that somebody might depend on the
>>>> formula - in particular, to predict the shape of a circle and then adjust
>>>> geometry to match. (They'd probably be better off calculating the
>>>> equivalent $fn and using that explicitly, rather than trying to match the
>>>> results of the internal calculation, but...)
>>>>
>>>>
>>>> I think it's worth the small compatibility hiccup. What do others
>>>> think?
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>

Replying to:

Empathy v1.0
2024 ©Harmonylists.com