Never trust Rhino for 90-degree extrusions

[Rhino_Bulgaria (Bobi)]

There is a bug with Rhino which leads to an unwanted loss of accuracy when extruding planar curve profiles on a custom CPlane. The bug is caused by the '_CPlane _Object which fails to maintain true planar coordinates. On the other hand, a Cplane set by the '_CPlane _3Point command properly aligns the coordinates to the planar curves. You can observe the bug in the attached video. I also upload the same 3dm file here (Rhino 7):
Never trust Rhino for 90-degree extrusions.3dm (141.8 KB)

Never trust Rhino for 90 degree extrusions (BUG)

P.S. A similar bug was found when dealing with the ! _Distribute command which uses inaccurate bounding box for each object. That other bug was discussed in this topic:

Why Rhino is not accurate enough with CPlanes?

After I set a custom CPlane while Grid snap is enabled, often times I figure out that the origin coordinate of the former is somewhat inaccurate instead of a whole number. If I build a point or a curve on its origin, Rhino’s Command line reports that it’s a whole number 0, 0, 0 (I use the maximum display precision of 1,0000000 mm and absolute tolerance of 0,001 mm). However, when I run the “Activate CPlane with named object” script (attached below), the Command line reports some coordinates with…

[Tom_P]

Dear @Rhino_Bulgaria

the curve you re using is (only) planar within document tolerance.
but not planar within the maximum distance display accuracy.

_cplane _3Point → Boundingbox … output is:

CPlane coordinates:
min = -46.2801388,-0.0000000,-0.0000000
max = 84.4025544,51.1488310,0.0000603
dimensions = 130.6826932, 51.1488310, 0.0000603 millimeters

check the max Z 0.0000603
with c-plane set to those 3 points:

the problem is, that there is some trading between intuition, easiness of use, tolerance and mathematical correctness with 12 digits …

set the cplane to whatever you like (object or _cplane _3Point) , _projectToCplane to make the curve 100% planar - the issue is gone.
sorry to say but it is not a bug but a limitation of CAD to dealing with tolerances and ease of use.

By the way: looking at your video, you re using Center and Near snap as persistent - did you ever try one shot Osnaps ? click on one of the snap buttons with shift to get a one - shot osnap. I strongly recommend to not use near, center as permanent / persistent osnaps.

kind regards and marry Christmas - hope you’ve eaten less diner then my mother served me today ;-D
Tom

[Rhino_Bulgaria (Bobi)]

The funny thing is that I created a custom CPlane first, then I drew the curves on it, so they are supposed to be flat if Rhino is programmed properly. I even have the whole process captured on a video, but it was made for a customer and the work is private, so I can’t show it to anyone else.

However, as discussed in the other topic I mentioned and a few others, bounding boxes and CPlanes use some rough calculations that leave room for errors caused by Rhino itself. These calculations could be more accurate. As far as I remember, they were made rough (with less digits?) back in the time some 20-25 years ago when CPU’s were quite weak. However, it’s 2024 now (2025 soon) and processors are much more capable, so I think that having more accurate calculations at the cost of a few milliseconds delay is worth the trade.

As for the Osnap options, the ones I use work best for my type of workflow, but I also have some key shortcuts to turn off all snap types except for circle, or turn the circle snap off and leave the rest ones. Depends on the situation.

[Tom_P]

@Rhino_Bulgaria

supposed to be flat

can you provide a workflow, that allows to repeatable create a non-planar curve on a c-plane - at least if we look at the 5th digit.
this point is 0.0000603 of from the others.

[Gijs (Gijs de Zwart)]

@Rhino_Bulgaria I tried to reproduce by drawing a similar polycurve on a cplane most close to the curve you posted. When I run boundingbox on your curve, it is indeed not flat, but when I run boundingbox on the new curve, it is.
I’m curious how you created the curve you posted.

[Rhino_Bulgaria (Bobi)]

That particular straight line next to the round curve pointed out by @Tom_P was created via curve intersection between two planar surfaces. Then that curve was used to trim the excess area of both planar surfaces. The whole assembly includes 3 metal plates (not on the same plane) that touch together in one spot. Maybe the ! _Intersect tool causes some inaccuracy? I work with Absolute tolerance of 0.001 millimeters. Is not it possible to set custom tolerance for certain tools, so that they will work as accurate as possible?

A similar issue was discussed in another topic where the Split and Trim tools both produce inaccuracy in certain situations:

Dual tolerance option in Rhino?

Is there a way to have two separate options for tolerance in Rhino, a custom one for the “Split” and “Trim” tools only, and a default one for the Absilute tolerance used with all the rest commands? For example, the “Split and Trim” tolerance could be 10 or 100 times more accurate than the default one: If “Default tolerance” = 0.01 mm then “Split and Trim tolerance” = 0.0001 mm This also could be applied to the “Project” tool, because projected curves are often used as trimming objects as wel…