(trimmed recipients down to just the list)

On Wednesday, August 13, 2025 at 09:31:16 AM EDT, Todd Allen 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.

An interesting approach to me is to write out a DXF as a part of the modeling process --- this allows capturing arcs/circle segments/circles as such in the DXF format --- and it has been working for me in my current project (search my name on github if curious), and the success of it has me wanting to extend that to Bézier curves  --- writing out SVG files directly is needlessly complex since the coordinate system differs from that of DXFs and OpenSCAD, but it looks promising to re-implement the METAFONT/METAPOST curve format and to write out .mp files.

In the meanwhile, it does work to open up a DXF written out from my library by way of (Open)PythonSCAD in LibreCAD, then export it from that application as an SVG.

Extending all that to also writing out a NURBS file/definition is something which I hope I can expand my knowledge of mathematics to encompass.

William

-- 
Sphinx of black quartz, judge my vow.
https://designinto3d.com/

NURBS are not Bézier curves. (Though Bézier curves can be made with NURBS). As I understand it, while Bézier curves cannot exactly represent a circle, with the right knot values, NURBS can.

-Revar

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.

On Wednesday, August 13, 2025 at 10:30:19 AM EDT, Revar Desmera via Discuss discuss@lists.openscad.org wrote:

Yep turns out adding support for this was an explicit effort:

https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline

Is there a 2D implementation of this suited to CNC?

On Wednesday, August 13, 2025 at 10:59:25 AM EDT, Rogier Wolff via Discuss discuss@lists.openscad.org wrote:

Correct.

Yes, given a difference large enough to matter --- as I noted, showing the inability of such curves to represent a true circle is left as an exercise for the reader as well as showing the exact nature of the deviation.

If you have a CNC  or 3D printer where this difference can be expressed as a physical part so as to cause this issue, please let us know. Curious as to which material and manufacturing process and size it can be made to happen at.

For practical purposes, one equipment which is within the reach of an individual, or even a typical small company, in my experience, it is.

That said, as noted, the tool which I've been working on will express arcs/circle segments/circles in a DXF or in G-code, so if folks find OpenSCAD's inability to actually represent a circle as a circle, well there is one programmatic option.

That said, I would be interested in further informaton on file formats and so forth which can accurately represent curves/circles/segments and the possibility of implementing them either as part of OpenSCAD/(Open)PythonSCAD, or in libraries which can be loaded into it and used by it.

William

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:

It has probably been 10 or 20 years since I looked into this, but I
remember working with a library that took in NURBS, and then approximated
them with arcs and lines that were directly convertible to g-code.  I used
that as a side-step so that I could work with NURBS and run on an
unmodified CNC router (that did not support them).  I have no idea
where that code is.  You might check on github for things like tinynurbs,
... Hmmm... what languages do you want to program in?...

On Wed, Aug 13, 2025 at 11:20 AM William F. Adams via Discuss <
discuss@lists.openscad.org> wrote:

On 8/12/2025 11:26 PM, Steve Lelievre via Discuss wrote:

There is at the low levels only one kind of module.

A module can (but need not):

• Add shapes to the model.
• Accept children and transform them.
• Emit output to the console.

It may do any or all of those.

It is somewhat useful to distinguish between what are sometimes called
"object modules", that only add a shape to the model, and what are
sometimes called "operator" modules, that only modify the shape(s)
passed to them by their children.  But that's only a model for
categorizing modules, not a difference in the module infrastructure per se.

You might distinguish flow-control modules (like "if" and "for"), but
they really fall into the "operator module" category.  (They to have
somewhat magic syntax and/or semantics.)

All of the built-in modules fall into one of those categories. (Well,
almost all: echo() and assert() don't.)

When you write your own module, you are not limited to doing only one of
the things listed above.  You can have a module that adds a shape and
accepts children and transforms them.

Here's a simple example:

module cube_topper(size) {
     cube(size);
     translate([size/2, size/2, size])
         children();
}

This module creates a cube, and puts its children centered on the top of
the cube.  You use it like so:

cube_topper(10) sphere(5);

It's a floor wax and a dessert topping!

Note that it's legal to call children() when there are no children
supplied, so this module can also be used to create a cube without
adding anything to it.

And of course you could stack calls:

cube_topper(10) cube_topper(7) sphere(5);

yea... lets set up a poll.  That said, if the pole said to change it, would
the admin do so?

On Wed, Aug 13, 2025 at 10:40 AM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote: