is color an actual operator module ?
I assume that if a message is from Fred then if I Reply it will go to
Fred. Period. The current behavior is sufficiently counter-intuitive
that it has caught quite a few of is. That, by itself, should scream
"fix it" not "pay more attention".
Jon
On 8/13/2025 9:58 AM, Glenn Butcher via Discuss wrote:
Apologies in advance if this seems harsh...
I think this falls into the old 'reply-all' bucket, don't do that. I
don't know of a mail program in use today that doesn't display the
contents of the To:, Cc: and Bcc: lines of a draft email, so pay
attention to what's in there.
Words of wisdom from my mother: "Do you know who you're talking to??"
Regards,
Glenn Butcher
On 8/13/2025 7:02 AM, Rogier Wolff via Discuss wrote:
On Wed, Aug 13, 2025 at 08:52:31AM -0400, John David via Discuss wrote:
Would it help for a group of us to request the change?
My mail program (mutt) asks me if I want to reply tot the reply-to
address when it isn't the same. (It asks a yes-no question and does
not clearly state which will be yes, and what will be "no", so there
is still room for improvement.).
But the "reply-to" the list is generally what is usually preferable.
Otherwise many conversations would silently "go private" by accident.
But yes: I agree that the "a private message accidentally going
public" is a bad situation.
Roger.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
On Wed, Aug 13, 2025 at 01:37:12PM -0400, Jon Bondy wrote:
Since all that I do with the 3D models that I create with OpenSCAD
is print them on a 3D printer, so long as the output looks smooth at
the level of 0.1 mm, I don't care about the other details.
Yes, OpenScad has already reached a level that it is useful for
certain tasks.
The discussion has come about that for certain cases, the possibility
of defining a smooth curve might provide additional usability for
certain users. Maybe not you. We're aware that for 3D printing,
openscad provides quite reasonable performance on the approximated
curves.
True curves also help in that when you offload the actuall
approximation to the lowest level, the machine may know its step size
and when to stop approximating. When someone tells openscad to do
very fine steps, maybe appropriate for the machine he has, then on
other hardware, the lowest level may run into performance issues.
For example, the number of gcode lines that octoprint can send to a
printer is sometimes restricted by the baud rate of the MCU to the
usb-uart. So when a slicer follows the "many" triangles that openscad
may have sent, this might result in "too many" commands and ugly
artefacts in the printed object. Here "true curve" support will help
in that A's very precise high performance machine can decide to
interpolate to very fine line segments, while B's low-performance
machine needs to stop at larger segments.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ Delfgauw, The Netherlands.
** KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space shuttle.
** 'a' for accelleration.
NURBS are a mathematical representation of curves and surfaces. From what
I remember of the OBJ format from what I had to implement in grad school, I
was not aware that it could represent any curves at all, but I would expect
that there is Bezier curves if anything.
As for BambooLabs, etc., Good luck with that. With printer manufacturers
that make close-source packaged deals, the only way they will ever
implement NURBS is if a) their lead designer wants or needs them for some
reason, or b) that there are so many open-source options/implementations
that catch on that it becomes a selling point that they do not have it. I
do not see it. You are probably going to end up having to use open-source
and/or write filters that translate NURBS, or specifiy how smooth you want
the curve to be from straight line evaluations
When you start talking about adding boolean operations on top of geometric
representations, you are in the realm of Computer Aided Geometric Design
(CAGD). Yes, you can perform boolean operations on NURBS curves and
surfaces.
On Wed, Aug 13, 2025 at 12:48 PM Jordan Brown openscad@jordan.maileater.net
wrote:
On 8/13/2025 4:41 PM, John David via Discuss wrote:
Now, a couple of people have used the term "true circle". I am
assuming that you mean "a perfectly round shape defined by a single,
continuous mathematical curve, not a series of short lines".
Yes, that's what I mean by it. No matter what size it is, and no matter
how much you zoom in (well, OK, until you start hitting floating point
limits), you'll see a curve.
William asks about file formats that can represent curves. A quick scan
of the OBJ documentation says that it can.
The problem is really in implementing the boolean operations on them.
Yes, you can perform boolean operations on NURBS curves and surfaces.
I’m sure that it’s theoretically possible. But do we have anybody who has the time and knowledge required to implement it?
On Wed, Aug 13, 2025 at 01:37:12PM -0400, Jon Bondy wrote:
Since all that I do with the 3D models that I create with OpenSCAD is print
them on a 3D printer, so long as the output looks smooth at the level of 0.1
mm, I don't care about the other details.
Your EMail caused me to rethink about this object:
s = 25;
rr = 5;
sr = s+rr;
$fs = .1;
$fa = 2;
module tetratwister ()
{
difference () {
hull () {
translate ([s,s,s]) sphere (rr);
translate ([s,-s,-s]) sphere (rr);
translate ([-s,-s,s]) sphere (rr);
translate ([-s,s,-s]) sphere (rr);
}
translate ([0,0,-sr]) linear_extrude (height=2sr, twist=1801.5, convexity = 10) rotate (45) square ([4*s,.2], center=true);
}
}
tetratwister ();
I've implemented this object in openscad twice before, and both
implementation had the annoying habit of resulting in unprintable or
difficult-to-print objects. Artefacts of the "quantization" that
openscad had to do. Today's implementation is a lot simpler than all
that I've done before and this results in a printable version.
Trust me it's not trivial: I've spent days on the workarounds to get
it to print nicely. Today it was a 5 minute typing excercise.
To print this: load into the slicer, use split-to-objects and
place-on-face. There are "correct" and "wrong" faces to place this on:
some have print-in-the-air parts and others don't. Both halves are the
same.
Once you have printed them. Try to put them together. It's harder than
you think.
Oh! Credit for "inventing" this object/puzzle goes to George Hart. His
implementation / published STLs has/have the openscad artefacts that
make it a nightmare for a 3D printer.
https://www.georgehart.com/puzzles/FIRE.html
https://www.thingiverse.com/thing:186372
Ah! The rounded edges is "added by me".
Roger.
On 8/13/2025 11:41 AM, John David via Discuss wrote:
I just got a half dozen private and small group replies (that do not
overlap each other), so I am just going to post a reply to the group...
I assure those of you who do not know the mathematics behind NURBS, that
they can indeed represent an exact circle (see: https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline#Example:_a_circle
for at least some details, and Gerald Farin's book on NURBS
https://www.farinhansford.com/books/nurbs/ for the math and
practicalities behind it). Now, a couple of people have used the term
"true circle". I am assuming that you mean "a perfectly round shape
defined by a single, continuous mathematical curve, not a series of
short lines". Depending on the degree of the NURBS, you get something
called C* and G* continuity (where * is the degree of the
object/NURBS). So yes, a NURB will exactly define a "true circle".
That said, there are practical implementation details that come into
play. Since you have evoked CNC/G-code, as well as NURB curves and
surfaces, they have to be evaluated as some epsilon. Even a G02
(clockwise arc in g-code), has to evaluate the mathematical expression
of an arc/circle at the precision of a machine's step size. This is
often well below 0.001" (I have machines whose step size are 0.00002").
Both a mathematical circle, as well as a NURBS with appropriate knots
sequences and weights of sqrt(2)/2, will mathematically give you a fully
mathematically continuous and exact circle.
Since you also mentioned wanting these in 3D printing, and CNC, even
LinuxCNC has an experimental implementation, and I know commercial CNC
machines often have NURBS implemented directly in the G-Code
implementation. I am not familiar with any 3D printing software the
supports NURBS, but I have not needed to check. I will say that the way
NURBS are defined is so well-defined, that it is typically easy to write
a translator to go from one representation to another. In addition,
there are enough prototype implementations that a motivated programmer
should be able to port any one of a dozen implementations/libraries to
open-source 3D printing software. If you go for that, hit me up, and I
will dig through my archived class projects -- back in 2001 I took
Gerald Farin's PhD level class on CAGD, as well as others. One of the
other students and I made a game of challenging each other with
different implementations of evaluating the N-Dimentional Bernstein
Polynomials (and you can implement NURBS based on them). Anyway, we
ended up with something that is wicked fast, and if I recall correctly I
set mine up to cache the intermediate results for various efficiency
reasons (like further subdivisions, etc.).
Anyway, this was all very long-winded, BUT I think that NURBS will give
you want and need (it will look very weird at first), but you will have
to either see if there is downstream implementations of NURBS in your 3D
printing and CNC software.
EBo --
On Wed, Aug 13, 2025 at 10:59 AM Rogier Wolff via Discuss
discuss@lists.openscad.org wrote:
On Aug 13, 2025, at 7:20 AM, William F. Adams via Discuss
<discuss@lists.openscad.org> wrote:
It is an interesting mathematical exercise to prove how a Bézier
curve cannot exactly represent a circle --- but I think it would be
even more interesting to show a real-world example where the want of
that ability has resulted in a difficulty making a part --- it's a
close enough approximation for most (or even the vast majority of)
usages.
We'd like to do 3D printing and CNCing with the results from the CAD
process, right?
Well... if I design a round hole for an object and the object that
goes inside, then I expect that object to be able to rotate. Any
deviation from a true circle will cause it to "not be able to rotate".
If you create sufficient tolerances that it does rotate, you'll get
it to fit tighter and less tight along the full rotation.
This design and wanting to CNC that with a low tolerance on a good CNC
isn't all that farfetched. So maybe my "visually a spline is close
enough to a circle" is not quite good enough.
I got educated on "computer graphics" mid 1980s. So back then: "looks
good" was important and "exact fit" maybe not so much. The wikipedia
article mentions late 1980s as the first implementation of NURBs.
Roger.
-- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/
<https://www.BitWizard.nl/> ** +31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ Delfgauw, The Netherlands.
** KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space
shuttle.
** 'a' for accelleration.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ Delfgauw, The Netherlands.
** KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space shuttle.
** 'a' for accelleration.
That's good, and very efficient for designs of that type.
However, it's been years since I designed any models of that type. The
vast majority of my designs (models of existing printed circuit boards)
consists of placing cubes and cylinders at known distances from the
origin. And it's all table-driven. In my workflow, I never place a shape
in reference to an existing shape.
On Wed, Aug 13, 2025 at 11:40 AM Jordan Brown openscad@jordan.maileater.net
wrote:
On 8/13/2025 4:32 AM, Leonard Martin Struttmann via Discuss wrote:
However, I have yet to find a use-case in my projects where attachments
are easier than the native translate()/rotate() OpenSCAD primitives.
Quick: build a cube with a cylinder sticking out of the right side.
include <BOSL2/std.scad>
cube(10) attach(RIGHT) cylinder(h=10, r=3);
Yes, you can do that with rotate and translate. (Or is it translate and
rotate?)
How about if the cylinder is sticking out the corner of the cube?
include <BOSL2/std.scad>
cube(10) attach(RIGHT+FRONT+TOP) cylinder(h=10, r=3);
Now put a sphere at the end of the cylinder, with the sphere barely
touching the cylinder:
include <BOSL2/std.scad>
cube(10)
attach(RIGHT) cylinder(h=10, r=3)
attach(TOP, BOTTOM) sphere(r=3);
Versus:
cubesz = 10;
cylh = 10;
spherer = 3;
cube(cubesz);
translate([cubesz, cubesz/2, cubesz/2]) rotate([0,90,0]) {
cylinder(h=cylh, r=3);
translate([0,0,cylh + spherer])
sphere(r=spherer);
}
Note: I didn't need the variables, but I did if I wanted to avoid
duplicating the numbers.
Since all that I do with the 3D models that I create with OpenSCAD is print
them on a 3D printer, so long as the output looks smooth at the level of
0.1 mm, I don't care about the other details.
I have 3D printed models that can not be generated with curves at even 1 mm
without being insanely slow and burdensome. For example printing a long
thin belt in TPU modeled with the belt width in Z and starting from a
diameter the width of the print bed spiraling inward. If the belt is 1 mm
thick and it spirals in at 1.5 mm per loop one can easily go 50+ loops on a
moderate sized printer.
On Wed, Aug 13, 2025 at 12:37 PM Jon Bondy via Discuss <
discuss@lists.openscad.org> wrote:
Since all that I do with the 3D models that I create with OpenSCAD is
print them on a 3D printer, so long as the output looks smooth at the level
of 0.1 mm, I don't care about the other details.
On 8/13/2025 11:41 AM, John David via Discuss wrote:
I just got a half dozen private and small group replies (that do not
overlap each other), so I am just going to post a reply to the group...
I assure those of you who do not know the mathematics behind NURBS, that
they can indeed represent an exact circle (see:
https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline#Example:_a_circle
for at least some details, and Gerald Farin's book on NURBS
https://www.farinhansford.com/books/nurbs/ for the math and
practicalities behind it). Now, a couple of people have used the term
"true circle". I am assuming that you mean "a perfectly round shape
defined by a single, continuous mathematical curve, not a series of short
lines". Depending on the degree of the NURBS, you get something called C*
and G* continuity (where * is the degree of the object/NURBS). So yes, a
NURB will exactly define a "true circle". That said, there are practical
implementation details that come into play. Since you have
evoked CNC/G-code, as well as NURB curves and surfaces, they have to be
evaluated as some epsilon. Even a G02 (clockwise arc in g-code), has to
evaluate the mathematical expression of an arc/circle at the precision of a
machine's step size. This is often well below 0.001" (I have machines
whose step size are 0.00002"). Both a mathematical circle, as well as a
NURBS with appropriate knots sequences and weights of sqrt(2)/2, will
mathematically give you a fully mathematically continuous and exact circle.
Since you also mentioned wanting these in 3D printing, and CNC, even
LinuxCNC has an experimental implementation, and I know commercial CNC
machines often have NURBS implemented directly in the G-Code
implementation. I am not familiar with any 3D printing software the
supports NURBS, but I have not needed to check. I will say that the way
NURBS are defined is so well-defined, that it is typically easy to write a
translator to go from one representation to another. In addition, there
are enough prototype implementations that a motivated programmer should be
able to port any one of a dozen implementations/libraries to open-source 3D
printing software. If you go for that, hit me up, and I will dig through
my archived class projects -- back in 2001 I took Gerald Farin's PhD level
class on CAGD, as well as others. One of the other students and I made a
game of challenging each other with different implementations of evaluating
the N-Dimentional Bernstein Polynomials (and you can implement NURBS based
on them). Anyway, we ended up with something that is wicked fast, and if I
recall correctly I set mine up to cache the intermediate results for
various efficiency reasons (like further subdivisions, etc.).
Anyway, this was all very long-winded, BUT I think that NURBS will give
you want and need (it will look very weird at first), but you will have to
either see if there is downstream implementations of NURBS in your 3D
printing and CNC software.
EBo --
On Wed, Aug 13, 2025 at 10:59 AM Rogier Wolff via Discuss <
discuss@lists.openscad.org> wrote:
On Aug 13, 2025, at 7:20 AM, William F. Adams via Discuss <
discuss@lists.openscad.org> wrote:
It is an interesting mathematical exercise to prove how a Bézier
curve cannot exactly represent a circle --- but I think it would be
even more interesting to show a real-world example where the want of
that ability has resulted in a difficulty making a part --- it's a
close enough approximation for most (or even the vast majority of)
usages.
We'd like to do 3D printing and CNCing with the results from the CAD
process, right?
Well... if I design a round hole for an object and the object that
goes inside, then I expect that object to be able to rotate. Any
deviation from a true circle will cause it to "not be able to rotate".
If you create sufficient tolerances that it does rotate, you'll get
it to fit tighter and less tight along the full rotation.
This design and wanting to CNC that with a low tolerance on a good CNC
isn't all that farfetched. So maybe my "visually a spline is close
enough to a circle" is not quite good enough.
I got educated on "computer graphics" mid 1980s. So back then: "looks
good" was important and "exact fit" maybe not so much. The wikipedia
article mentions late 1980s as the first implementation of NURBs.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
** Verl. Spiegelmakerstraat 37 2645 LZ Delfgauw, The Netherlands.
** KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space
shuttle.
** 'a' for accelleration.
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
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
Virus-free.www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
<#m_-4516900968302012369_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On Wed, 2025-08-13 at 18:58 +0200, Rogier Wolff wrote:
On Wed, Aug 13, 2025 at 10:48:40AM -0600, larry via Discuss wrote:
On Wed, 2025-08-13 at 18:30 +0200, Torsten Paul via Discuss wrote:
On 13.08.25 18:24, John David via Discuss wrote:
yea... lets set up a poll. That said, if the pole said to change it,
would the admin do so?
It's a hosted service currently, so "the maintainers" (assuming
that means OpenSCAD people) do not have any access to the mailman
configuration other than what the admin GUI provides.
Indeed. The mail client is the place to set up what the default reply
is. If your client doesn't do that, you need a better one.
In my case I have a "reply all" and a "reply privately to author"
choice.
The thing is say: "evelyn@jlcpcb.com" might set the "reply-to:" in her
Emails to "support@jlcpcb.com". So that when I reply-to-autohor, this
ends up in their support group in case she's not at the office. In
this example, the author redirects "private" replies to a
group-known-to-them.
In other cases, say on my secondary seldomly-checked Email
address... I could set the reply-to to my normal address so that I don't
miss replies.
Especially in this last case the reply-to-author needs to honor the
reply-to header.
Just telling me to instruct my mail-client to
just-not-look-at-the-reply-to-field is not a viable solution.
Well, if I just hit "Reply" when reading a mailing list, it asks me if
I want to reply to list or to the sender.
If I hit "Group Reply" I don't get the question, and it will go only to
the list.
I happen to use Evolution as a mail client.
- Did you try the manifold backend?
- For NURBS-based boolean, I think one can just use opencascade, and
things like build123d or cadquery should support it already. That said, one
major benefit of NURBS-based modeling is constraint solving, so it feels
like missing the point if we do not consider that. - It is unlikely that we can have things like stl import or minkowski.
Theoretically it should be possible, but it will probably be too slow.
On Thu, Aug 14, 2025, 04:30 Todd Allen via Discuss <
discuss@lists.openscad.org> wrote:
Since all that I do with the 3D models that I create with OpenSCAD is
print them on a 3D printer, so long as the output looks smooth at the level
of 0.1 mm, I don't care about the other details.
I have 3D printed models that can not be generated with curves at even 1
mm without being insanely slow and burdensome. For example printing a long
thin belt in TPU modeled with the belt width in Z and starting from a
diameter the width of the print bed spiraling inward. If the belt is 1 mm
thick and it spirals in at 1.5 mm per loop one can easily go 50+ loops on a
moderate sized printer.
On Wed, Aug 13, 2025 at 12:37 PM Jon Bondy via Discuss <
discuss@lists.openscad.org> wrote:
Since all that I do with the 3D models that I create with OpenSCAD is
print them on a 3D printer, so long as the output looks smooth at the level
of 0.1 mm, I don't care about the other details.
On 8/13/2025 11:41 AM, John David via Discuss wrote:
I just got a half dozen private and small group replies (that do not
overlap each other), so I am just going to post a reply to the group...
I assure those of you who do not know the mathematics behind NURBS, that
they can indeed represent an exact circle (see:
https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline#Example:_a_circle
for at least some details, and Gerald Farin's book on NURBS
https://www.farinhansford.com/books/nurbs/ for the math and
practicalities behind it). Now, a couple of people have used the term
"true circle". I am assuming that you mean "a perfectly round shape
defined by a single, continuous mathematical curve, not a series of short
lines". Depending on the degree of the NURBS, you get something called C*
and G* continuity (where * is the degree of the object/NURBS). So yes, a
NURB will exactly define a "true circle". That said, there are practical
implementation details that come into play. Since you have
evoked CNC/G-code, as well as NURB curves and surfaces, they have to be
evaluated as some epsilon. Even a G02 (clockwise arc in g-code), has to
evaluate the mathematical expression of an arc/circle at the precision of a
machine's step size. This is often well below 0.001" (I have machines
whose step size are 0.00002"). Both a mathematical circle, as well as a
NURBS with appropriate knots sequences and weights of sqrt(2)/2, will
mathematically give you a fully mathematically continuous and exact circle.
Since you also mentioned wanting these in 3D printing, and CNC, even
LinuxCNC has an experimental implementation, and I know commercial CNC
machines often have NURBS implemented directly in the G-Code
implementation. I am not familiar with any 3D printing software the
supports NURBS, but I have not needed to check. I will say that the way
NURBS are defined is so well-defined, that it is typically easy to write a
translator to go from one representation to another. In addition, there
are enough prototype implementations that a motivated programmer should be
able to port any one of a dozen implementations/libraries to open-source 3D
printing software. If you go for that, hit me up, and I will dig through
my archived class projects -- back in 2001 I took Gerald Farin's PhD level
class on CAGD, as well as others. One of the other students and I made a
game of challenging each other with different implementations of evaluating
the N-Dimentional Bernstein Polynomials (and you can implement NURBS based
on them). Anyway, we ended up with something that is wicked fast, and if I
recall correctly I set mine up to cache the intermediate results for
various efficiency reasons (like further subdivisions, etc.).
Anyway, this was all very long-winded, BUT I think that NURBS will give
you want and need (it will look very weird at first), but you will have to
either see if there is downstream implementations of NURBS in your 3D
printing and CNC software.
EBo --
On Wed, Aug 13, 2025 at 10:59 AM Rogier Wolff via Discuss <
discuss@lists.openscad.org> wrote:
On Aug 13, 2025, at 7:20 AM, William F. Adams via Discuss <
discuss@lists.openscad.org> wrote:
It is an interesting mathematical exercise to prove how a Bézier
curve cannot exactly represent a circle --- but I think it would be
even more interesting to show a real-world example where the want of
that ability has resulted in a difficulty making a part --- it's a
close enough approximation for most (or even the vast majority of)
usages.
We'd like to do 3D printing and CNCing with the results from the CAD
process, right?
Well... if I design a round hole for an object and the object that
goes inside, then I expect that object to be able to rotate. Any
deviation from a true circle will cause it to "not be able to rotate".
If you create sufficient tolerances that it does rotate, you'll get
it to fit tighter and less tight along the full rotation.
This design and wanting to CNC that with a low tolerance on a good CNC
isn't all that farfetched. So maybe my "visually a spline is close
enough to a circle" is not quite good enough.
I got educated on "computer graphics" mid 1980s. So back then: "looks
good" was important and "exact fit" maybe not so much. The wikipedia
article mentions late 1980s as the first implementation of NURBs.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ **
+31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ Delfgauw, The Netherlands.
** KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space
shuttle.
** 'a' for accelleration.
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
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
Virus-free.www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
<#m_1452791907063285202_m_-4516900968302012369_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
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
Maybe if you're purely data driven?
What I like about the attachment model is how you never have to figure out positions. Worst case a shift from a well known position relative to another object. You can get highly complex components and easily change major parts without having to refactor and recalculate a lot. Positions then quickly become complex to calculate when the objects are at angles. I learned that for injection molding everything is slightly angled to allow the release of the mold but it means there are never any easy modulo 90 degree angles. (The rounded_prism() is my hero).
The absolute crown enabled by the attachment model is however, the prism_connector ...

diff()
tube( id=50, h = 10, rounding=1, wall=2)// the ring
let(tube=parent())
attach_part("inside")
prism_connector( // the solid tube on the inside of
circle(d=7), // the ring
parent(), LEFT,
parent(), RIGHT,
fillet=1
)
restore(tube)
tag("remove")
prism_connector( // the inside of the tube with
circle(d=5), // exit on the outside of the ring
parent(), LEFT,
parent(), RIGHT,
fillet=1
)
;
For me the attachment model of BOSL2 is the main reason I did not dive into Python. It is absolute stunning, it is now hard for me to believe you can make complex modular components without them.
Peter Kriens
On 13 Aug 2025, at 20:46, Leonard Martin Struttmann via Discuss discuss@lists.openscad.org wrote:
That's good, and very efficient for designs of that type.
However, it's been years since I designed any models of that type. The vast majority of my designs (models of existing printed circuit boards) consists of placing cubes and cylinders at known distances from the origin. And it's all table-driven. In my workflow, I never place a shape in reference to an existing shape.
On Wed, Aug 13, 2025 at 11:40 AM Jordan Brown <openscad@jordan.maileater.net mailto:openscad@jordan.maileater.net> wrote:
On 8/13/2025 4:32 AM, Leonard Martin Struttmann via Discuss wrote:
However, I have yet to find a use-case in my projects where attachments are easier than the native translate()/rotate() OpenSCAD primitives.
Quick: build a cube with a cylinder sticking out of the right side.
include <BOSL2/std.scad>
cube(10) attach(RIGHT) cylinder(h=10, r=3);
Yes, you can do that with rotate and translate. (Or is it translate and rotate?)
How about if the cylinder is sticking out the corner of the cube?
include <BOSL2/std.scad>
cube(10) attach(RIGHT+FRONT+TOP) cylinder(h=10, r=3);
Now put a sphere at the end of the cylinder, with the sphere barely touching the cylinder:
include <BOSL2/std.scad>
cube(10)
attach(RIGHT) cylinder(h=10, r=3)
attach(TOP, BOTTOM) sphere(r=3);
Versus:
cubesz = 10;
cylh = 10;
spherer = 3;
cube(cubesz);
translate([cubesz, cubesz/2, cubesz/2]) rotate([0,90,0]) {
cylinder(h=cylh, r=3);
translate([0,0,cylh + spherer])
sphere(r=spherer);
}
Note: I didn't need the variables, but I did if I wanted to avoid duplicating the numbers.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
