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 random decimal numbers. For example, an origin of 517,1566,311 is reported as:
Origin=516.999999999968,1565.99999999994,311.000000000012 XAxis=1,0,0, YAxis=0,0,1, ZAxis=0,-1,0
Does this mean that Rhino is incapable of delivering perfectly accurate coordinates (such like 516,000000000000 mm instead of 516,999999999968 mm), or such deviation is kind of an internal limitation that does not affect the actual construction accuracy of the program? Technically speaking, a decimal number like 516,999999999968 mm is rounded as 517,0000000 mm in the Command line, but in reality it’s still not a whole number.
Not sure if it’s the same, though. In my example, the inaccurate coordinates happen pretty close to the origin of the scene, as you can see from the picture. The scene itself is not large in size, because this is a car project with less than 5 meters long chassis.
By the way, I just added the missing script in my first post.
recently i somehow got deviation of of 0,003mm in my model and no way i could manually introduce such small deviation myself. i suspect some operations like mirroring or rellying on gumball center position can result in such pretty mess. then i remodelled that staircase again and it was finally accurate to many digits.
When I set my CPlanes, I usually rely on the Grid snap at every millimeter while I manually pick the 3 points with the '_CPlane _3Point command, meaning that the Gumball is not involved during that process.
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.
Well … a precision of about 10e-15 is what you can get using 64 bit floating points.
( You would get a much lower precision, about 10e-7, using 32 bit floating point )
I agree that by simply copying an integer (not too large) we would not get any error, but a simple trasform calculation is enough to turn a real integer into a number very close to it but maybe 10e-15 away.
That calculation may be performed by the code that formats the numbers for output, for example … don’t know …
The error appears to be in the the results of a query which is reported in custom Cplane coordinates. My guess is Rhino stores all geometry and does all internal calculations in World coordinates. Coordinates input in Cplane coordinates are transformed into World coordinates for internal storage and use. For an arbitrary Cplane postion and orientation this transformation will generally not be “exact” even in 64 bit double precision math. When a coordinate is reported in Cplane coordinates the World coordinates are transformed to Cplane coordinates and again the transformation will generally not be exact for an arbitrary Cplane position and orientation.
This deviation from exact is around 1.e-14 in relative terms, which is consistent with a couple of double precision transformations. In absolute terms the deviation is 0.000000001 mm or 0.0001 nanometer, which is less than one millionth of the wavelength of visible light. That should be sufficient accuracy for most purposes.
While 0,01 mm is perfectly fine for real life objects made by CNC-milling or laser cutting, the fact that I use whole numbers and then Rhino shows me decimal numbers confuses me and makes me thing that my work is inaccurate and that I have to fix the model. Those random decimal numbers appear from time to time when I set CPlanes using Grid snap, which is kind of annoying, because the expectation is that the origin of such CPlane will be a whole number. After all, Grid snap exists for that very purpose.
When I build or place an object at a specific location and then mirror it, sometimes I figure out that the distance between both mirrored objects is not a whole number. Instead, it’s a decimal number with some deviation that should not be there. Here is an example (the video is still processed by YouTube, but should appear in a hour):
Oddly enough, I remember making a semi-universal code which I thought nailed the use of the local workplane coordinate systems on both FANUC and Mitsubishi controls.
I spent two days trying to figure out why my differentials from the #5001 positions in the controls didn’t evaluate, and my error catching routine always raised a problem.
Turned out that the Mitsubishi control was taking the #5001 current position and the (compensated) G31 position, and making a tiny evaluation error of about 0.00000019 or something silly, and it threw everything off.
Here is a proposal for a new tool in Rhino: “Snap to nearest coordinate”. How it should work?
Select and object (or a group of objects);
Run either the “Snap to nearest whole number” (LMB) or “Snap to nearest decimal number” (RMB);
Pick the origin point of the object;
Right-click or press Enter to end the command. Lets say that the origin is at 1,89999997 mm;
Rhino moves the selection to the nearest whole number (2,00000000 mm with the RMB) or to the nearest decimal number (1,90000000 mm with the RMB). Voila!
In this second example, the Y-axis coordinate of the circle’s center is 1449,2460000 mm. Running the “Snap to nearest whole number” LMB command would move the circle to 1449,0000000 mm. Running the “Snap to nearest decimal number” RMB command would move the circle to 1449,2000000 mm.
Thank goodness, I’m not the only one. This happens to me too (just happened earlier today when I was mirroring a canopy), and the mirrored geometry will be off by a couple thousandths of a degree.
Rhino produces extremely bad deviation when you try to distribute objects by equal distance via the “Distribure objects” command. I had a lot of problems with that in the past and I simply gave up and stopped using the tool entirely. Here is a quick example where I have a few tubes with 20x20 mm external profile size with 2 mm wall thickness, and 3 mm radius fillets. The tubes were made by extruding perfect squares with 20x20 mm and 16x16 mm, respectively. Once I ran the “Distribute objects” command, it will do its own thing and add an unwanted deviation.
On top of that, the other problem is that the bounding boxes of the tubes also were incorrect. Most likely Rhino calculates those tubes improperly due to the holes they have in certain places. Maybe it’s related to inaccuracy of the Boolean operations? At the beginning of the video I traced a point object along the edges of the tubes (aligned sideways to the X-axis) and, as you can see, the mouse tooltip showed a constant whole number for the Y-axis coordinate (210,00000000 mm).
At the 7:30 minute of the video you will notice that the History prevented the proper distribution of the objects, with no warning in a pop-up window (except that the Command line silently showed “History updated 2 objects”). This may lead to lots of troubles while distributing objects by a much larger distance, where the error is not easily noticeable as in this particular example.
this is unacceptable. recently i found out i cant trust volume command, bounding box, mirroring, … Elementary and fundamental things should work at this stage. I am just frustrated.
This the reason why I set my cursor ToolTips to show the maximum possible decimal numbers in front of my eyes. It’s the only way I can be warned about a potential error with the coordinates and distances caused by Rhino.
One “problem” is that Rhino displays only 8 digits after the decimal comma (dot), whereas the Command line displays 4 more digits, as seen in the screen-shot in my first post.
This is also why the coordinates on my first video above looked “perfectly rounded”, while in reality there was some tiny deviation that led to the 224,99999999 mm distance at the 0:45 minute.
It’s quite close to the world origin, as you can see in the video. The tube on the right side is located at just 130 mm from the center of the scene along the Y-axis. Here is a Rhino file with the same tubes. I forgot to upload it last night:
Do you intend to fix this critical bug for Rhino 7, too? It literally destroys the intent to achieve accurate work. I noticed that transformations such like ! _Orient3Pt also lead to unwanted deviation. It’s not just the bounding box that causes errors. In some cases circles built on CPlanes with non-parallel orientation along the XYZ axis stop being circles and the OSnap no loger can snap to their centers.
