I having a real time with relying on the snap function and my drawings are often off by a tiny amount - but all the same it’s a nuisance. Is there some setting I need to control to avoid this sort of thing as shown?
The lines drawn indicated they were snapping to what I needed but apparently not quite.
But it’s even more puzzling as the disconnected curves were created using the polygon tool!!
Check the Distance between those curve ends.
The zoom range in Rhino is almost infinite but at some point the precision of the calculations used by for the screen display becomes the limiting factor. If the geometry appears to jump around when you zoom in closely and change zoom level then the zoom level is exceeding the precision of the graphics.
Hello,
I’ve not changed the default tolerance
I’ll add a zero and see if that does it.
Maybe Grid Snap is on?
Sometimes I forget to disable it and this is what happens.
Use the Distance command and check how far those endpoints are apart.
Zoom in sufficiently and you will still see apparent gaps on the screen due to the limitations of the precision of the calculations for screen display. It is impossible to eliminate those apparent gaps by a tolerance setting. It is important to understand that the underlying geomertry data is stored and calculations are done to a much higher precision than the video display calculations.
As John suggests use the Distance command to see how how large the gap actually is. I expect that the actual gaps in the stored data will be something like 1.e-13 or smaller.
The issue is a nuisance when one goes to perform boolean operations and the minuscule difference leaves an incomplete result like this:
The end of the trapazoid (1) was snapped to the end of a trapezoid (2).
Then the gumball was reset with a macro:
CPlane Object Pause Select Pause GumballRelocate 0 1,0 0,1 CPlane Undo
The second trap was then dragged along the X axis to set up a boolean.
But I end up with this:
So you can see why I’m concerned about the matter. This uses up way too much of my time.
And here again is an example. The same proceedure was used to snap ends to ends and then drag via ortho and - yeah - this nonsense.
WTF?
@JKayten Have you used Distance to measure the size of the gaps your are seeing?
You need to provide a .3dm file with the input geometry and preferably also the output which you believe is flawed.
It looks like you are assuming that the apparent gaps you are seeing when you zoom in very closely represent flaws in the geometry and are the cause of Boolean operations not working as you would like. That is a very plausible assumption but very likely to be incorrect. Rhino does geometry calculations with much greater precision than what is displayed on the screen.
What Boolean operation did you use? What were you expecting? If you are using BooleanDifference or Boolean2Objects with A minus B or B minus A then the results you show are as expected and intended.
you have to be careful with what snaps you have activated, having for instances “near” on all the time may cause you quite some problems.
some also have a stronger pull towards them. for example center snaps, even though you are far from the center it always is more dominant, i believe you can adjust the settings.
maybe also understand and/or deactivate “use apparent intersections” things like that can be helpful, but bitching around about them shows that you have not invested enough time with snaps 
you can also activate object snap highlight to better understand what you are snapping to.
oh and not to forget the osnaps in the cursor tool tips if they are not on. and dont forget the snap radius. go to modelling aids in your preferences and set up accordingly.
Look, if I’d not already looked into the aspects you’re mentioning I wouldn’t have bothered posting. Don’t bother me with your opinion - that I’m ‘bitching’ - it seems to me it’s you that’s looking to put in a little bitching of your own. No one’s asked for you help in particular, so let’s keep it civil eh?
oh wow, ok you definitely got that wrong. nevermind and merry xmas!
Likewise
So I’ve not understood the Boolean function
As I’d shown earlier one cannot actually subtract, split or trim with an edge.
The same process followed of making a duplicate object then using it to boolean subtract leaves two parts. (The screen shot is distorted - both objects are the same)
So then I want to see if the cutting edge would be included in a duplicated edge
Calling up a trim or split function with the edge cuts cleanly. This is what I find confusing.
If the edge resulting from the boolean can make the cut then why not the object that originally created it?
Different decisions made, either explicitly or implicitly, when creating the algorithms for Trim and the Boolean commands. Neither is correct or incorrect, just different.
I see.
I’m wondering what use would the current result would be that make’s it preferrable to the more logically expected result.
In all of the above discussion, I only see images, not a single Rhino file with any geometry to test and analyze. Without that, we’re only answering theoretical questions with no way to know if the answers correspond to the specific problem being discussed…
It’s a very large file. Can I copy and paste some of it into a new document that would be suitable?
Absolutely! Just the parts in question, with a description of what procedures you used and what you think should have happened.
Okay - great. I’ve to leave for a family visit at this point so I’ll get to it this weekend.
Happy Christmas!
