Bounding Box is one of the most used features in my work and it isnot acceptable for not being 100% accurate.
4 Likes
If all displayed values in Rhino would round down to the document tolerance, this wouldnāt be an issue weād ever see, right?
But yes, setting a generated mesh tolerance globally seems like a good thing in this case, because I still donāt understand if the templates which ship with Rhino use weird settings or why I constantly get ānot accurate enoughā meshes for my tastesā¦
When I canāt get G1 or G2 where I want it, I often zoom in ridiculusly high, and itās funny to see how many meshes (imported or otherwise) have āhugeā gaps in between them which still fall below the document tolerance so Rhino (mostly) doesnāt care. 
1 Like
@Piotr What is your criteria for ā100% accurateā?
Rhino allows zooming in past the accuracy of the render/display system, including the accuracy of single precision meshes.
1 Like
Thatās how ātolerancesā work.
2 Likes
I used to work on a tall buildings, where I set units to meters. I had my precision set to 6 digits after coma and I was observing that mirrored objects did not keep that 00000 unit elegance when reading dimensions.
You may say it is not important in construction stage but it is, at the design stage. Iām here with Bobby, possibly same slight OCD.
2 Likes
within set tolerance
That is reasonable and what I use.
But it may result in āinaccurateā digits past what is needed based on the tolerance.
1 Like
I started another thread about the effect the mesh settings in Document Properties can have on the accuracy of BoundingBox and Align.
Important - the effects of the mesh settings is distinct from the use of single precision meshes.
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.
That deviation happens while I draw directly on a custom CPlane with āProjectā turned on to snap to other objects located in a different level relative to the CPlaneās Z-axis. Looks like Rhino is losing some accuracy during that process and is unable to project the snap coordinates exactly on the CPlane Z=0, because the output polyline is not perfectly flat as intended. If you open the attached file, you will notice that the top line segments are 0,0000018 mm higher than the custom CPlane. I work with scene tolerance of 0,001 mm, if that matters.
Canāt freely extrude this closed polycurve.3dm (106.3 KB)
