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.
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.
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.
@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?
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.
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…