circle tessellation and apothems

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

circle tessellation and apothems

Whosawhatsis
I was thinking about the problem of making holes in objects (particularly those for 3d printing), and how to keep tessellation from making a screw not fit into a hole due to the difference between the radius and the apothem of a polygon. This is important when printing items with holes for screws because printing many short segments with an FDM printer can result in blobbing (which constricts the hole) and a polygon with few segments has a large difference between the radius and the apothem, which also effectively constricts the hole.

I was thinking about writing a module to draw a polygon with an arbitrary number of facets (based on $fn, $fs, and $fa variables, like the circle module), but the user provides the apothem rather than the radius. Then I realized that this should ideally be part of the built-in circle module (and cylinder/sphere as well, anything that can take a radius argument). Just add another "apothem=" argument (or "a=", if there's nothing for it to be confused with) to allow the size of the circle to be defined based on the apothem rather than the radius.

I can figure out the math for converting apothem to radius while adjusting for the possibility that the two radii would result in different numbers of facets due to the $fa and $fs settings, but I suspect that there is a simpler and more elegant way to do it that would be easy for someone familiar with the relevant code to figure out.
Reply | Threaded
Open this post in threaded view
|

Re: circle tessellation and apothems

Giles Bathgate-2
On Wed, 2010-12-22 at 11:59 -0800, Whosawhatsis wrote:

> I was thinking about the problem of making holes in objects
> (particularly those for 3d printing), and how to keep tessellation
> from making a screw not fit into a hole due to the difference between
> the radius and the apothem of a polygon. This is important when
> printing items with holes for screws because printing many short
> segments with an FDM printer can result in blobbing (which constricts
> the hole) and a polygon with few segments has a large difference
> between the radius and the apothem, which also effectively constricts
> the hole.
>
>
> I was thinking about writing a module to draw a polygon with an
> arbitrary number of facets (based on $fn, $fs, and $fa variables, like
> the circle module), but the user provides the apothem rather than the
> radius. Then I realized that this should ideally be part of the
> built-in circle module (and cylinder/sphere as well, anything that can
> take a radius argument). Just add another "apothem=" argument (or
> "a=", if there's nothing for it to be confused with) to allow the size
> of the circle to be defined based on the apothem rather than the
> radius.
>
>
> I can figure out the math for converting apothem to radius while
> adjusting for the possibility that the two radii would result in
> different numbers of facets due to the $fa and $fs settings, but I
> suspect that there is a simpler and more elegant way to do it that
> would be easy for someone familiar with the relevant code to figure
> out.

Sounds like a good idea. OpenSCAD doesn't really create circles, it
creates approximations using polygons, so may as well support arguments
to allow such approximations to be controlled more explicitly.



Reply | Threaded
Open this post in threaded view
|

Re: circle tessellation and apothems

kintel
Administrator
In reply to this post by Whosawhatsis
On Dec 22, 2010, at 20:59 PM, Whosawhatsis wrote:

> I was thinking about the problem of making holes in objects (particularly those for 3d printing), and how to keep tessellation from making a screw not fit into a hole due to the difference between the radius and the apothem of a polygon.

Good idea!

I don't like the idea of using the term 'apothem', as I think that will alienate users more than attracting them.
Rather than introducing an extra parameter for the apothem, we could add a boolean parameter which controls how the radius parameter(s) should be interpreted, and name it accordingly.
Alternatively, we could add a special variable which toggles this behavior globally (like $fn, $fa etc.).

What users will perceive is whether the circle approximation is inscribed or circumscribed related to the actual circle (which might be _slightly_ more common terms than apothem ;), so some naming scheme reflecting this would be nice. Ideas?

The math is trivial. I would just replace the radius prior to the calculations like this somewhere in primitives.cc:
double actual_r = r1 / cos(M_PI / fragments);

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: circle tessellation and apothems

Tim Schmidt
On Sat, Dec 25, 2010 at 4:27 PM, Marius Kintel <[hidden email]> wrote:
> Rather than introducing an extra parameter for the apothem, we could add a boolean parameter which controls how the radius parameter(s) should be interpreted, and name it accordingly.

In terms most can easily understand, we're talking about whether the
radius parameter represents the inner diameter (ID) or outer diameter
(OD) of the circle.  Right now, radius represents OD.

Perhaps that helps?

--tim

Reply | Threaded
Open this post in threaded view
|

Re: circle tessellation and apothems

clothbot
In reply to this post by kintel
Hey Marius,

How about calling the parameter "snap" with a range from [0,1]:

snap=0 snaps line segment end-point coordinates to the ideal circle coordinates.
        - least effort to calculate
        - use when circle is maximal bound of polygon approximation

snap=1 snaps line segment midpoint coordinate to the ideal circle coordinates (i.e. line midpoint is tangent to circle)
        - degenerate case where polygon fully contains circle

snap=0.5 snaps line segment quarter-point coordinates to the ideal circle coordinates.
        - trade-off between polygon line segment inside & outside circle.

Andrew.

On 2010-12-25, at 4:27 PM, Marius Kintel wrote:

> On Dec 22, 2010, at 20:59 PM, Whosawhatsis wrote:
>
>> I was thinking about the problem of making holes in objects (particularly those for 3d printing), and how to keep tessellation from making a screw not fit into a hole due to the difference between the radius and the apothem of a polygon.
>
> Good idea!
>
> I don't like the idea of using the term 'apothem', as I think that will alienate users more than attracting them.
> Rather than introducing an extra parameter for the apothem, we could add a boolean parameter which controls how the radius parameter(s) should be interpreted, and name it accordingly.
> Alternatively, we could add a special variable which toggles this behavior globally (like $fn, $fa etc.).
>
> What users will perceive is whether the circle approximation is inscribed or circumscribed related to the actual circle (which might be _slightly_ more common terms than apothem ;), so some naming scheme reflecting this would be nice. Ideas?
>
> The math is trivial. I would just replace the radius prior to the calculations like this somewhere in primitives.cc:
> double actual_r = r1 / cos(M_PI / fragments);
>
> -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad


Reply | Threaded
Open this post in threaded view
|

Re: circle tessellation and apothems

kintel
Administrator
On Dec 26, 2010, at 17:26 PM, Andrew Plumb wrote:

> How about calling the parameter "snap" with a range from [0,1]:
>
I like this approach, although snap sounds a bit "snap to grid" like.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: circle tessellation and apothems

Whosawhatsis
In reply to this post by kintel
I really like the idea of making it a special variable like $fn and $fa. This would probably also make it possible to throw it into a module call and have it apply to everything within that module (which would be useful if, for instance, the module contained a series of holes to be subtracted from an object for 3d printing).

Andrew, I also like your idea of making it a value from 0 to 1, with the possibility of setting the facets to intersect with the ideal circle at different points.

I know that apothem is not a very common term, and to tell the truth, I had to double-check the definition when I was writing my previous message to make sure that I was using the right word. "Inraduis" is another term for the same thing, is more straightforward, and wins the google fight (http://www.googlefight.com/index.php?lang=en_GB&word1=apothem&word2=inradius).

Tim, while ID and OD are more common terms, I think they are technically incorrect in this case. I believe the definition of the diameter of a polygon is the greatest distance between two vertices, which for regular polygons with an even number of sides is the same as the diameter of the circumcircle. Radius is the distance from the center to the furthest point (necessarily a vertex). These definitions get fuzzy with irregular polygons, and even in the case of a regular polygon with an odd number of sides, the radius will be more than half of the diameter. The point is that it is important to explain this using terms that are technically accurate and as well-defined as possible, to minimize confusion. This does mean using some technical and potentially daunting terms, so I like the idea of using something like "snap", which could be both defined technically and demonstrated with pictures in the manual.

On Saturday, December 25, 2010 at 1:27 PM, Marius Kintel wrote:

On Dec 22, 2010, at 20:59 PM, Whosawhatsis wrote:

I was thinking about the problem of making holes in objects (particularly those for 3d printing), and how to keep tessellation from making a screw not fit into a hole due to the difference between the radius and the apothem of a polygon.

Good idea!

I don't like the idea of using the term 'apothem', as I think that will alienate users more than attracting them.
Rather than introducing an extra parameter for the apothem, we could add a boolean parameter which controls how the radius parameter(s) should be interpreted, and name it accordingly.
Alternatively, we could add a special variable which toggles this behavior globally (like $fn, $fa etc.).

What users will perceive is whether the circle approximation is inscribed or circumscribed related to the actual circle (which might be _slightly_ more common terms than apothem ;), so some naming scheme reflecting this would be nice. Ideas?

The math is trivial. I would just replace the radius prior to the calculations like this somewhere in primitives.cc:
double actual_r = r1 / cos(M_PI / fragments);

-Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

Reply | Threaded
Open this post in threaded view
|

Re: circle tessellation and apothems

Steven Dick


On Sun, Dec 26, 2010 at 12:38 PM, Whosawhatsis <[hidden email]> wrote:
I really like the idea of making it a special variable like $fn and $fa.
[...]
Tim, while ID and OD are more common terms, I think they are technically incorrect in this case. I believe the definition of the diameter of a polygon is
[...]

You are thinking in terms of the OpenSCAD implementer, not the user.

The point of using ID/OD is to indicate that the intent for the hole is that it _IS_ the inner diameter or outer diamter.

I.e., if you wanted to make a pipe, you'd give the dimension for the inner hole as ID and it would make the hole no smaller than that.  This might improve tolerances of parts.

Making this option a global variable would not give that option.

However, I do like the idea of specifying diameter as corner, midpoint, or average.  I don't like the idea of calling it "snap" as I think it would be very confusing to reuse this term.
Reply | Threaded
Open this post in threaded view
|

Re: circle tessellation and apothems

Giles Bathgate-2
In reply to this post by kintel
On Sat, 2010-12-25 at 22:27 +0100, Marius Kintel wrote:
> I don't like the idea of using the term 'apothem', as I think that
> will alienate users more than attracting them.

I had no idea what the term 'apothem' meant, so I looked it up on
wikipedia and within about 5 seconds understood what it meant. Whats the
point of 'dumming down' the language terms, in case it might put off
users. It is after all the correct term for suggested feature.

Whatever you call it, somewhere you are going to have to document that
term 'foobar' actually means the 'apothem', you will just confuse users
more and leave them wondering why you didn't just call it like it is.

Regards

Giles