Why # of control points & knots after rebuilding aren't what I specified

Rhino Rhino for Windows
, , ,
1

Sidenote: My end goal is to find a way to compactly represent curves as a fixed-length list of elements. I thought I could do this by rebuilding all curves with a specified control point count and degree, and using the points, weights, and knots, but this seems unviable?

So I’ve read previous posts like this one and also the explanation here which says that

A common misconception is that each knot is paired with a control point, but this is true only for degree 1 NURBS (polylines). For higher degree NURBS, there are groups of 2 x degree knots that correspond to groups of (degree+1) control points.

I understand well enough with polylines (degree 1) that a line with 10 control points will have 10 knot vectors.

However, it’s described here that

the number of knots in the knot vector is always equal to the number of control points plus the order of the curve. E.g., a cubic (order=4) with four control points has eight items in the knot vector.

It’s defined here that

Degree = order + 1

In a script such as this one, I get a bunch of curves, rebuild them specifying the control count and the degree. The curve has 10 control points + degree of 3 + 1, so I expect it to have 14 knots (at most?).

image
image1620×873 109 KB

But you can see in the screenshot, that a few of the curves after rebuilding end up with 13 control points instead of 10, 15 knots instead of 14, etc. Why? How?

Visually speaking, I noticed this happened with closed/circular curves, so I’m wondering if that has something to do with it? Or does it have something to do with the multi-knot stuff?

I attached below the Grasshopper script with some internalized curves, if that helps.
make_crv_attributes.gh (180.8 KB)

2

Closed curves are rebuilt as periodic curves in the RebCrv component. A periodic curve must repeat the first degree-many control points to be valid.

For example, you are asking for a rebuild with 10 control points and degree 3. The seemingly “extra” 3 points you see in the curves that have 13 control points are automatically appended by RebCrv to be valid periodic curves.

Try baking the control points to double-check this. You should see that the first and last 3 control points are the same.

1 Like
3

Thanks for the explanation. I baked the control points and see that now. I just have a few more questions:

  1. (I am aware doing this will change the look of the curve.) But if the issue is that the curve is rebuilt as periodic, then how come running MakeNonPeriodic command after Rebuild still doesn’t result in the expected number of control points? In fact, after using the command, some of the curves that initially had 10 control points now have 13, and 15 knot vectors. (See attached gh file if necessary, I internalized the curves.)
    make_crv_attributes.gh (135.8 KB)

However, I can verify that using the OpenCrv Component prior to rebuilding creates open curves that look very similar to the original ones, and output the expected control points and knots.

  1. Lastly, I noticed that all of the curves in my example have a weight of one. It’s described that

The control points have an associated number called a weight. With a few exceptions, weights are positive numbers. When a curve’s control points all have the same weight (usually 1), the curve is called non-rational. Otherwise, the curve is called rational. The R in NURBS stands for rational and indicates that a NURBS curve has the possibility of being rational. In practice, most NURBS curves are non-rational. A few NURBS curves, circles, and ellipses being notable examples, are always rational.

Is there some way to convert rational to non-rational and/or vice-versa? (I don’t really care which, but if I can make them all the same, then I can discard the weight element in my representation of a curve as a list of elements, and that would be highly convenient.)

(3. Also, would you recommend I use Elmo instead? Is there a Grasshopper component?)

Thanks!