I am experiencing a bug on Rhino 5 and 6 Windows versions. Would it be possible to know if the same one exists on Rhino 7 as well?
I have a closed, planar polyline. The polyline has a “cutout” - a concave like part in the middle.
Here is the how the plane of the polyline looks like (red arrow is the plane normal):
However, if I move the starting point of the polyline to be in the “cutout” area, the plane normal is reversed. This does not correspond to the counterclockwise direction of the polyline, so I would say it is a bug:
Can someone confirm that this second picture looks exactly the same on Rhino 7?
Attached is the polyline. Thank you in advance.
polyline plane normal.gh (4.7 KB)
Hi Djordje -
I can confirm that this behaves the same way in Rhino 8.
It looks like it’s the Planar component that is doing this but I’ll let someone else decide if that’s a bug… - RH-67924
As you can see in this picture, the Offset Surface component creates the offset in the same direction in both cases.
Thank you for the testing and screenshots @wim !
I would say it’s the Curve.TryGetPlane method bug.
We may be able to improve a little upon this, but curves do not have intrinsic planes they carry around with them. If a curve is planar, then that plane can be found, but it’s usually little more than looking at the first N control-points until three non-co-linear ones are found. The normal direction and rotation of the curve plane are just undefined. They’re not just ambiguous, the process is also discontinuous, in that arbitrarily small changes to the curve orientation or shape may result in very large changes to the plane origin and axes. That is a problem which cannot mathematically be solved.
Hi @DavidRutten ,
Thank you for the explanation.
Is this also valid for closed, first degree planar nurbs curves - like the one we have in this topic?
There is a so called Signed area of a polygon, frequently used in computer graphics.
The same equation can also be used to calculate orientation of the polygon (curve): orientation is counter-clockwise if signed area is positive. And orientation of the curve depends on the normal of its plane.
So if we calculate signed area of the curve from this topic we will see that it outputs +130814.296773 value, only when curve orientation is counter-clockwise.
What I am saying is that the starting point of a curve, should not affect the normal of its plane (forget about plane rotation, just plane normal). Plane normal should be the same - regardless of where we put the curve seam.
Hello @djordje counter clockwise or not depends on a plane that YOU define. On xy plane Z and -Z have the same weight. You could choose Z as a reference but it is not 100 % useful as other consider -z as refere. Oientation of curve is worth when you define a reference plane. Clipper uses that to know if it is a hole or the exterior but you need a reference plane.
Exactly. Look the picture from my latest post and you will understand that for the shown XYZ plane - orientation of the curve is always counter-clockwise.
If you want the orientation of that curve to be always clockwise, you have to flip the normal of the XYZ plane.
BUT if you change the seam of the curve, this must not affect the curve orientation! Only the plane normal can affect it.
Thus my conclusion that this is a Curve.TryGetPlane bug.
Yes I understand that. The point of David is that there is no plane associated to the curve, nor history of plane outputted. Plane is calculated each time Curve.TryGetPlane() is used. There is the same problem with Frame, they are not turning “nicely” on the curve.
I think it could be solved if there is a new derived class of Curve which embed a plane.
Short digression. This global problem is like, Captain Haddock has to pass on the left of the chorten because the cosmic way of turning is clockwise. But you have to know that the orientation is given when you look the movement from above !
Each curve contains ordered list of control points.
I don’t know if this can be applied for curve.Degree > 1, but for degree 1, planar, closed nurbs curve (as we have it in this topic) you can always calculate its plane normal, because you know the order of its control points.
And by knowing the plane normal, you know the curve plane (regardless of how rotation of X and Y plane axes around that normal look like).
You are right, Mc Neel could surely implement a more consistent TryGetPlane for the curves you describe. It will be surely more fast if someone make a custom function/script/component.
You have that in Clipper
/// <param name="poly"></param>
public static bool Orientation(Path poly)
return Area(poly) >= 0;
On my own library I use that so you could surely use Rhino ClosedCurveOrientation() to get the orientation of a closed polyline and get the good plane.
public Polyline OrientCounterClockwise(Polyline polyline)
CurveOrientation curveOrientation = polyline.ToPolylineCurve().ClosedCurveOrientation();
Polyline orientedPolyline = polyline.Duplicate();
if (curveOrientation == CurveOrientation.Clockwise)
@dale, can you also take a look at this please? Why does changing the seam of a curve, flips the normal of its plane? And very indicative: the plane normal flips when the seam is moved to a concave part of the curve. Thank you.