Why Rhino is not accurate enough with CPlanes?

[3dsynergy]

Hi @Gijs @Rhino_Bulgaria

@Rhino_Bulgaria

There is a bug that happens on rare occasions for no obvious reason. Weirdly enough, when both “Ortho” and “Grid snap” are enabled, sometimes Rhino will not let me extrude a closed polyline with the ! _ExtrudeCrv _Pause _Solid=_Yes _Multipause _SelNone _SelLast command and this is the only indication for issues with the tolerances of a custom CPlane. However, at the moment I turn off “Ortho” or “Grid snap”, the extrusion is possible again, despite that the polyline is not perfectly flat.

I’ve run into this so many times that I stopped using custom cplanes at an angle for real work. The reason being is that I found it introduces many modeling errors not just the tolerance issue discussed here. I always model parts on a standard orthogonal cplane and then use remap to the angled cplane or orient 3 points. I found that once the part is made on the standard cplane the transform is ok. But constructing and modeling are error prone on angled cplanes. So many modeling commands report errors or wont work I gave up using it. For me it went beyond extrusions like surface from planar curves, surf from edge curves, loft all the standard tools I’ve run into problems using slanted cplanes.

RM

[JimCarruthers]

@3dsynergy

I’ve run into this so many times that I stopped using custom cplanes at an angle for real work. The reason being is that I found it introduces many modeling errors not just the tolerance issue discussed here. I always model parts on a standard orthogonal cplane and then use remap to the angled cplane or orient 3 points. I found that once the part is made on the standard cplane the transform is ok. But constructing and modeling are error prone on angled cplanes. So many modeling commands report errors or wont work I gave up using it

Wha…???

[Rhino_Bulgaria (Bobi)]

I noticed that, too, but the bug is still there, even if I set file tolerance of 0,0000001 mm. It gets much bigger when tens or hundreds of objects are involved, because both, the bounding box and the distribute gap grow a tiny bit over the expected numbers.

As far as I understood, this bug will be resolved no earlier than Rhino 10. I can wait for it. I will be in my 50s by then.

[jim]

@3dsynergy

I always model parts on a standard orthogonal cplane and then use remap to the angled cplane or orient 3 points. I found that once the part is made on the standard cplane the transform is ok.

Me too.I haven’t used custom cplanes for more than 20 years. RemapToCPlane is extremely accurate.

I don’t know if errors working with custom cplanes are Rhino’s fault since I don’t use them.
I have done models of aerospace parts from 2d drawings that have dozens of angled views and it would be a nightmare to work with all those as custom cplanes. Much easier and less error prone to model on the xy plane and move a copy of the result into position.

[Rhino_Bulgaria (Bobi)]

@davidcockey

@Rhino_Bulgaria

I suspect that the issue is a result of the 32-bit nature of the coordinates which Rhino uses. It has been proven that some modern 3d games with 64-bit engines (such as “Star Citizen”) are vastly superior and capable to render drastically large worlds while maintain great precision.

Rhino uses 64 bit double floating point math for all geometry calculations and geometry storage. The only exception is the final output for rendering which is 32 bit. My understanding is that is because many GPU’s can’t handle or don’t like 64 bit input.

Perhaps there are a few exceptions and various calculations in Rhino are based on less precise numbers, because there are a few tools and Gumball itself that are less accurate than the expectation.

[wim (Wim Dekeyser)]

Hi Bobi -

@Rhino_Bulgaria

Weirdly enough, when both “Ortho” and “Grid snap” are enabled, sometimes Rhino will not let me extrude a closed polyline with the ! _ExtrudeCrv _Pause _Solid=_Yes _Multipause _SelNone _SelLast command and this is the only indication for issues with the tolerances of a custom CPlane.

Thanks. I’ve put that on the list as RH-92183 ExtrudeCrv: Refuses to Extrude - Sample

@jim

I haven’t used custom cplanes for more than 20 years.

Not attempting to change your ways, just fwiw…
I never used custom CPlanes in the past. I use the current AutoCPlane feature all the time, though.
-wim

[Rhino_Bulgaria (Bobi)]

Thank you for adding this bug to the pile! As a heavy user of custom CPlane’s in Rhino 7 set by the '_CPlane _Object command I experience that particular bug quite often. I figured out that the '_CPlane _3Point command is more reliable for some reason.

Is there a chance that the '_CPlane _Object command uses an invisible rendering mesh bounding box with a course precision for the flat face selected as the target object to create a CPlane?

[Holo]

Just to remind everybody:

19,999999873 really is 20.
Remember that these are floating point numbers and what kind of tolerance do you work with if this does not measure as 20???

If you are working in Meters this translates to 19 meters 99 centimers, 9 millimeters and 999 micrometers… Do you REALLY need that last micrometer to be satisfied? Or is that just OCD

Happy friday.

Oh, and I made you into a meme Bobi

[Juan_Gallo]

no its few millimeters when working far from origin which is not negligible and these errors buildup when each time gumball position is calculated wrong.

[jesterking]

Tools > Options > Advanced Settings search for RhinoCycles.AdaptiveThreshold. In code it is set to 0.01, now see what it is shown as in the GUI.

Here is what the default value is set to:

Settings/DefaultEngineSettings.cs

Some numbers are just unrepresentable regardless of the chosen (finite) precision, the closest possible representation is used. See Floating-point arithmetic - Wikipedia for more info on representable numbers. Check for instance how 0.1 is represented (read: cannot be).

[Rhino_Bulgaria (Bobi)]

While real-World parts are not impacted by such a tiny deviation, the design process in Rhino is heavily impacted! Note that the whole numbers are used primarily for detecting unwanted deviation or unwanted scale or rotation during the design of the parts. For example, when I work with NURBS tubes or other parts that should be a whole number big, seeing something like 19,99957493 is alarming and I’m forced to carefully check everything for accidental moving, scaling or rotation, which ultimately leads to extra time spent for things other than an actual work.

[CADARTZ]

@Holo

Do you REALLY need that last micrometer to be satisfied?

Welcome to the defense industry especially fighter jets

It’s really satisfying tho so totally worth it….

[Holo]

@Rhino_Bulgaria

seeing something like 19,99957493 is alarming and I’m forced to carefully check everything

I know the feeling, and have spent countless hours cleaning stuff like that up my self, but in real life it really doesn’t matter because whole numbers are also just approximations but pretty numbers are as you say clear indications that everything is pristine and fine.

I just had to make some fun about it, also because it is so very relatable