…I initially thought the Offset command was the problem. However, thanks to @jeremy5, we discovered that Offset works correctly, but the Chamfer and Connect commands fail when the distance between two lines is very small. I don’t know exactly how small the distance needs to be for the issue to appear.
The critical problem is that when Chamfer or Connect fail to modify the geometry, the Join command (either triggered automatically by these commands or run separately) still works on those lines and ends up changing their orientation. That leads to corrupted or misleading geometry.
I’m attaching two videos that demonstrate these errors clearly.
I was also able to reproduce the same behavior in Rhino 5, so this is not something new.
This is far more serious than a simple command failure; it represents a critical data integrity flaw within the software. The fact that the Join command succeeds and silently corrupts the curve orientation after Chamfer or Connect fails means that our models could contain hidden, misleading geometry. This raises an urgent question: Does the community need to retrospectively check all existing files—especially those with tight tolerances or complex offsets—to determine if they have been compromised by this behavior? This is a severe, long-standing issue that warrants immediate developer attention as it directly undermines the reliability of the core modeling data.
Have you read the post carefully? Have you seen the videos that describe precisely what’s going wrong? The attached file to reproduce the issue? I believe it’s a very critical issue, causing serious inaccuracies in the model in such simple commands.
Yes, I have read the entire thread, plus the previous one. The comment was not on the bug itself, simply the use of AI.
You are free to believe what you want - it’s certainly an issue that needs to be fixed and if you want to go back and check every single one of your previous files for possible microscopic errors as the post suggested, feel free.
My attitude is that this bug has probably existed for a long, long time and since there has not been much (if any) noise about it until now, I expect that the possible inaccuracy has not resulted in major disasters.
Your obviously-AI-generated post is hysterical, nobody is going to pay any attention to it, or sit through 10 minutes of video. I don’t see anything wrong in the attached file. The concept of “corrupt line orientation” is kind of nonsensical.
The 00000000085 angle difference is just noise from the limitations of floating-point math.
What is the actual problem, in your own words please? And post a file that actually shows the problem.
As far as I remember it always worked this way. If I wanted joined these lines without altering their positions I’d use fillet with 0 distance or extend curve.
Note the issue is real - albeit very small, and it does need to be corrected.
Many people don’t understand how Join works and how it has since forever. When Join encounters two curves that do not intersect, but are closer than 2x the file absolute tolerance, it averages the endpoints and moves both curve endpoints to that average point. That is how it has always worked.
The problem is with Connect. If Connect finds two curves that do not intersect but whose endpoints are within 2x the absolute tolerance, it uses Join to connect them instead of extending the curves to meet first - as it does if the curves are distant by 2x or more than the file tolerance.
Here’s an example. The file below has an absolute tolerance of 0.001. If you run Connect (or Join) on the lower (red) set of curves, you will see the displacement of the endpoints. If you run Connect on the upper set (cyan) they will connect normally. Note if you run Connect with Join=No on the lower set, they will simply refuse to connect - this is also a bug IMO. Edit: well, maybe not a bug exactly, as the endpoints are already within file tolerance, so Rhino considers them to be ‘already connected’ so to speak. This is always the problem when working with stuff below file tolerance.
Connect is supposed to do exactly that. It was actually added to Rhino in like Rhino V2 (V3?) because people complained that they had to continually reset their fillet radius (which is sticky) because they were using it with 0 to connect and with other values to make actual fillets.
Edit - note that Fillet 0 on the lower set of curves in my example does exactly the same as Join or Connect…
@Piotr Connect, Chamfer, and Fillet with radius 0 do not affect the geometry when the intersection distance is tiny (by not affect i mean they don’t extend and trim the lines to intersection as expected). @Helvetosaur said this distance is 2× the tolerance, and he is probably right. Trim and Extend, on the other hand, work as expected. But isn’t Connect essentially a combination of Trim and Extend? It’s obviously broken.
I’ve checked this behavior in Rhino 5, and it’s definitely broken there as well, so this may have been happening since that version—maybe even forever. I’ve been using Rhino since version 6 and only noticed it four days ago.
From my perspective, the fact that these commands can affect geometry without being easily noticeable is a huge problem. It forces me to check everything two or three times, which makes using the software inconvenient.
I believe most users haven’t noticed this, but that doesn’t mean it’s not serious.
Please take a look at what this behavior forces me to check manually before I can even connect the lines in the attached file. It becomes a serious issue when I need to verify the geometric ‘equivalent of 1+1=2’ each time.
And what does it mean when the software reports ‘2.000001’ instead of ‘2’?
The value 2 is an exact integer, but 2.000001 is a floating number.
You’re right — I didn’t have the Join command’s behavior in mind. Maybe because I always try to draw clean geometry and avoid commands that rely on the file tolerance.
After seeing this, I think McNeel should add an option to the Join command. In most of my cases, I need correct geometry, not geometry that only appears correct.
I can think of many situations where these minor errors will cause problems in future boolean operations.
You might want to read up on how computers calculate things based on floating point math. There are lots of articles on the subject. Rounding errors with very small values are typical results.
The absolute tolerance value you set on a file is often misunderstood by Rhino users. Grossly oversimplified it means you don’t care about inaccuracies smaller than that. You can certainly set tighter file tolerances, but they will come at an expense of longer calculation times and possibly overly complex geometry on operations like joining surfaces where things need to be approximated within tolerance to create a common edge.
That is not to say that Rhino shouldn’t calculate as exactly as possible those things that are able to be done so… it should.
Regardless of how join works users have the option to use the Connect tool which is supposed to extend the curves and trim them at the intersection point. There is really no excuse for that failing in the example that was posted.
That is the same bug in the Fillet command. Back then the Fillet command used to also get the trimming of tangent arcs wrong so any user who wanted it done right had to do it themselves. The OP now knows that if he wants to be sure this is done correctly he has to do it himself by extending the lines and trimming. Its shameful that people are actually trying to defend the developer. incompetence because this same bug also exists in the Fillet command. When someone uses the Fillet 0 they expect that the curves will be extended to the point where the curves intersect. That is what zero means. It doesn’t mean close enough to zero to be within tolerance.
Tolerance means the user will tolerate some inaccuracy when there is a trade off between between accuracy and something else the user doesn’t want. Tolerance does not mean the user will tolerate any gratuitous and unwarranted inaccuracy.
Operations with first-degree geometry should not be affected by tolerance at all. That’s why most commands that depend on tolerance offer the option to use either the file tolerance or a custom tolerance. This is the simplest type of intersection operation, and it should use full floating-numbers precision.
