Circle
The knot vector and weights are taken from literature. To represent a full circle with NURBS usually 90 degree arch representation is found at first. This gives a 2nd degree curve with 2D + w control points {{1,0, 1}, {1, 1, sqrt(2)/2}}, {0, 1, 1}}. Then this arch is repeated four times to construct a full circle and these arches are connected with knots {0, 0, 0, ¼, ¼, ½,½, ¾,¾, 1, 1, 1}. Inner knots are repeated for arches to connect at control points.
Circular Arcs and Circles
I couldn’t find literature giving NURBS scheme without double knots, even found someone suggesting that its not possible
NURBS circle without all the double knots?
I think the current Blender “circle” came from the wish to have evenly spaced knots.
This finishes the explanation of the knot vector defined in BKE_create_circle_knots and nu->orderu decreased to 3 ( degree + 1).

Sphere
In editcurve_add.c at line 427 a similar knot vector is created but only for a half circle. Only two 90 degree aches connected so only one double knot. Previously there was the CU_NURB_BEZIER flag and it would, but I wanted to follow logic and keep consistency with a circle(CU_NURB_BEZIER cannot be used for a circle as the flag cannot be used together with CU_NURB_CYCLIC file curve.c line 1270). Afterwards this 180 arch is spinned in 360 with editcurve.c function ed_editnurb_spin. As it needs to create a circular shape and had same weight as for a circle I used the same logic. The weird thing might be 2.0 / M_SQRT2, it is inverted sqrd(2)/2 to make every second weight 1. This is an old function’s structure and mechanics. I just put the right number.

Just find out this patch worsens Nurbs circle in Geometry Nodes

That's probably because spline_from_dna_nurbs doesn't copy the original knot vector. It could do that, or maybe it makes more sense to improve the implementation of the bezier knot mode in the cyclic case. Not sure.

In some sense both options.
Fastest and most reasonable at a time is to support cyclic with bezier in both old and new nurbs code.
But in a future knots should be recalculated only on user action like change of cyclic or endpoint mode. Because tools like "cut"
rely on custom knot vectors. For ex. curve on [0 0 0 1 2 3 3 3] cut at 1.25 gives two curves on [0 0 0 1 1.25 1.25 1.25] and [1.25 1.25 1.25 2 3 3 3].
With this approach copying should happen.

Refactoring of calcknots affects only CU_NURB_BEZIER case output. For output instead of oldU = [0, 0, 0, 0.5, 0.5, 1, 1, 1.5, 1.5, 2, 2, 2] now newU=[0, 0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 4] is returned. Resulting NURBS curve/surface are equivalent only defined on different intervals. It doesn’t affect curve/surface shape or normals as from math point of view knots magnitude is not important, important are ratios of knot spacing and they are preserved, for ex. (oldU[3] - oldU[2]) / (oldU[5] - oldU[2]) = 0.5 / 1 = 0.5 = (newU[3] - newU[2]) / (newU[5] - newU[2]) = 1 / 2.
From code quality side magic numbers like 0.34, 0.6 and ⅓ are removed.
Another difference and benefit that now it supports not only orders 3 and 4, just Blender interface in the main branch restricts other orders.

Does this patch change the meaning of Nurb.orderu, Nurb.orderv, or NURBSpline.order_?

No. Don't know why you suspect that.

I see now CU_NURB_ENDPOINT | CU_NURB_BEZIER are often used in combination.

I'm canceling this one. In Blender Nurbs of CU_NURB_BEZIER type has one leading control point and it looked like a bug. It has no visual effect. Intention was for Bezier (green in screenshot) with handles:

I'm a little surprised to see a change to the "Spin" operator here. How is that related?

It is used to generate "Nurbs Sphere" and "Nurbs Torus". I had versions rewriting Sphere code with a couple constant arrays, but finally was forced to fix spin. More on this in code comment.

What's the reasoning for giving the NURBS circle primitive CU_NURB_BEZIER knots? As a user I wouldn't necessarily expect the default NURBS circle to have a knot vector I thought was used to emulate Bezier curves.

And it does. Circle is expressed as four Bezier arcs connecting into single curve. It is impossible to create accurate circle with uniform knots. In fact for user there should be no such thing as knot vector type,
knot vector should be generated once and left as is for user to modify with tools like "Refine/Insert Control Point" or "Slice/Split" and others.

I'm not sure why, but I'm having trouble applying this patch. It seems to start a bit differently than others here:

Index: source/blender/blenkernel/intern/curve.cc
===================================================================

vs. the regular format:

diff --git a/release/scripts/startup/nodeitems_builtins.py b/release/scripts/startup/nodeitems_builtins.py
--- a/release/scripts/startup/nodeitems_builtins.py
+++ b/release/scripts/startup/nodeitems_builtins.py

Could you try creating the diff with git diff master -U100 > ~/temp.diff?

Hey guys, I want to join your discussion, hopefully you don't mind. I'm going to digest/test this patch for the next couple of days and leave my thoughts here.

@Piotr Makal (pmakal)

Can you provide the references to the papers/books supporting this? One of the big selling points for NURBS is that they can represent arbitrary conic sections (including circles)[1] in opposite to Bezier curves which can only approximate such geometry[2].

In my statement I skipped word Rational before Bezier. The thing is that if you repeat knot degree(order - 1) times each segment of resulting curve is Rational Bezier curve and this
is what Blender does for Bezier(Rational Bezier to be precise) knot generation. Your link [1] as my first link in comments above shows same the knot structure.
You are right about conics as selling point. But to dive more into details circles can be expressed with several separate Rational Bezier curves and NURBS allows to express that structure as single curve.

Why is this a problem?

I don’t see it as a problem. As far as I understood Hans, he didn’t like that for Circle/Sphere primitives you get Bezier checkbox checked.

Is this strictly related to Blender implementation of NURBS?

At some point yes, because Blender implementation doesn’t allow user to edit knot vector(not necessarily directly, through tools also), it constantly regenerates it for a given scheme (Endpoint, Bezier,..).
So it is not possible to create for ex. NURBS Circle with fixed knot like in your [1] without Bezier checked. Knot will be rewritten and lost for ex. after toggling Cyclic couple of times.

Hopefully tomorrow I will wrap up my testing. Just want to point out some smaller things:

• I've noticed that for 4th order, 8-point NURBS curve with Bezier + Cyclic setup, the knot vector is: [0, 0, 1, 1, 1, 2, 2, 2, 3, 3, 4, 4, 4, 5, 5]. Looking at the code it doesn't seem intentional to only double the "3" here?
• Referring to what you wrote previously:

In D11664#365572, @Laurynas Duburas (laurynas) wrote:

Is this strictly related to Blender implementation of NURBS?

At some point yes, because Blender implementation doesn’t allow user to edit knot vector(not necessarily directly, through tools also), it constantly regenerates it for a given scheme (Endpoint, Bezier,..).
So it is not possible to create for ex. NURBS Circle with fixed knot like in your [1] without Bezier checked. Knot will be rewritten and lost for ex. after toggling Cyclic couple of times.

Good point

Looking at the code it doesn't seem intentional to only double the "3" here?

It is intentional because loop starts with first "3" (knot[8] counting from 0). The input is not proper. Last Bezier segment needs one more control point (to end at cp[0])). Now you get situation where 3rd degree Bezier curve has only three control points given.
So function does most of what is possible, creates correct cyclic knot vector.

In my opinion in UI status bar user could be informed that more points are needed to complete Bezier segment. And visually could:

1. stay as it is. Last segment not a Bezier curve (if there is not enough cp's)
2. only show cycle from Bezier's having enough control points. And other control points would float around until all necessary for next Bezier are added or lost on tool change.

But this is out of this patch scope

I've tested the patch on my side and I'm ok with the changes. I understand the reasoning behind it, as the "cyclic" implementation for NURBS in Blender comes with some challenges. Going for Bezier knots interpretation for circular shapes seems a little bit hacky, but then again, it produces better results then previous approach as shown by @Laurynas Duburas (laurynas).
Some final thoughts for consideration:

• I would suggest to investigate the current limitation for Bezier knots mode in NURBS that currently only works for 3rd and 4th order curves. I think that after this change it should be possible to remove this restriction and the value range should be between 2-6 (like for every other curve). While testing the patch I've removed this restriction in BKE_nurb_order_clamp_u function in curve.cc file, but when switching to i.e. 5th order a curve wasn't displaying itself in the viewport although it seem to have proper knot vector (when checked with debugger). Again, this is something to think about.
• If this patch going to be pushed I would split it into two separate commits: (1) change in knot vector calculations in calcknots and NURBSpline::calculate_knots functions and (2) change in ed_editnurb_spin and ed_editnurb_spin functions.
• I would update the description for this patch, clarifying that knot vector in 3rd order NURBS curve with Bezier option turned on (without cyclic) is changed in comparison to previous calculations, although it doesn't change the curve shape itself. For example the knot vector for 3rd order, 8-point NURBS curve before the change was: (0, 0, 0, 1, 1, 2, 2, 3, 3, 3, 3); and after this patch is: (0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5) - again with Bezier flag and without Cyclic flag.

I would suggest to investigate the current limitation for Bezier knots mode in NURBS that currently only works for 3rd and 4th order curves. I think that after this change it should be possible to remove this restriction and the value range should be between 2-6 (like for every other curve).

I'm preparing followup patch removing some restrictions including order on NURBS Bezier, but need to lay down concepts

While testing the patch I've removed this restriction in BKE_nurb_order_clamp_u function in curve.cc file

Would have missed this one.

For the commit I took the relevant parts of the commit message and edited them a bit, I hope that's okay.