In general that is what Rhino does. For instance, when you run Offset or Intersect on lines the user tolerance plays no role like it does for curvy degree 3 geometry. You get the same result no matter what your tolerance is.
When you add 1+1 you don’t get an answer that is within tolerance of 2.
1 Like
Well, I can imagine that all the commands that fail call the same base code module…
With a logic something like this:
-
Try to find an intersection. If one is found, fine, mutually trim and join. Done.
If no intersection is found: -
Check the distance between the end points. If the distance is greater than 2x (actually from testing seems to be more like 1.5x) the file tolerance, extend by a certain calculated factor (possibly iteratively) then intersect and trim. Done.
-
If the distance between endpoints is less than 2x (1.5x) the file tolerance, Join - that gives us the intersection. Done. This is the wrong assumption.
Someone needs to re-write that last part of the code to always extend and trim, no matter what the distance is.
3 Likes
yes i agree on that
Okay, I spent several hours writing a Python script — with AI assistance, of course — to create a proper Connect command. It works with lines and polylines that contain only straight segments. You can try it. I believe it should be very easy for McNeel to fix the native commands and give them full functionality.
connect_right.py (8.0 KB)
They may do, but there are slight differences in behaviour between different scenarios. Here’s a summary, based on the relevant subset of the OP’s original model:
where the purple line is short of the red offset line by 0.00001427, much smaller than the tolerance of 0.001, at the point indicated.
I have considered the _Trim/_Join combo, _Connect and _Chamfer commands in situations with different gaps between purple and red lines and an overlap. Apart from the miniscule original gap, I’ve looked at 0.5x, 1x, 1.5x, 2x and 2.5x the tolerance.
For each command, I show whether it works at each gap and where the join is placed. This may be at the Intersect point, where extended red and purple lines cross, or midway between the end points (where a red end may be created by a trim at the Intersect).
| Gap length | Trim | Join | Pos | Connect | Pos | Chamfer | Pos | |
|---|---|---|---|---|---|---|---|---|
| -0.0005 | Y | Y | Intersect | Y | Intersect | Y | Intersect | |
| 0.00001427 | Y | Y | Midway | Y | Midway | Y | Midway | |
| 0.0005 | Y | Y | Midway | Y | Midway | Y | Midway | |
| 0.001 | Y | Y | Midway | Y | Intersect | Y | Intersect | |
| 0.0015 | N | Y (if confirm) | Midway | Y | Intersect | Y | Intersect | |
| 0.002 | N | Y (if confirm) | Midway | Y | Intersect | Y | Intersect | |
| 0.0025 | N | Y (if confirm) | Midway | Y | Intersect | Y | Intersect | |
| Tolerance | ||||||||
| 0.001 |
The takeaways here are that:
- _Connect and _Chamfer work OK where lines cross and where the gap is >= tolerance and place the joint at the Intersect. Where 0 < gap < tolerance they use the Midway point and alter the line direction.
- _Trim works OK where the gap is <= tolerance otherwise not, as expected.
- _Join always works but also always uses the Midway point, changing line direction.
Most of the time _Connect and _Chamfer will work fine: avoid leaving lines with sub-tolerance gaps and you will avoid problems (pending a change to the sub-tolerance gap behaviour by McNeel).
This happens a lot if you’re modelling, let’s say, existing walls which are slightly out of axis. That’s why I always used the chamfer command even if I didn’t want to join the lines. To ensure that I have a perfect intersection. Which obviously I have not. I didn’t edit the document I posted to clarify the problem. All the misalignments it contains occurred by just offsetting, trimming, and chamfering.
Any chance you could post the “Before connect” version that you illustrate above? It would be interesting to see how issues evolve whilst using the commands.
Even better if you could annotate it, or the screenshot, to show which lines are offsets, by what distance and from where!
Thanks
Jeremy
This was modeled from a point cloud. Usually, I extracted the best-fit lines from both sides of the walls. Then I try to model the final wall as two parallel lines, keeping the direction of one of the two lines and choosing the one that makes more sense to me each time. It’s not always the interior or exterior side. I will try tomorrow, as it is 1:38 AM here, to see if I can restore an earlier version from OneDrive history. If not, I will try to remodel it while capturing my screen.
Anyway, it seems too easy and too right to me, every command that can use floating number precision to do it, and only if the user chooses something different to override.
Having read a document about Rhino’s precision in the past, I thought that was the default behavior.