So what?? It is still a wrong answer. The analysis tools are supposed to give correct measurements so that users can work with confidence that there work is accurate.
When the user offsets a line and then tries to measure the angle between the original line and the offset line and Rhino returns a bogus number that completely undermines the user’s confidence that Rhino is a serious CAD program. Rhino clearly can not do basic math problems correctly. Either Rhino is messing up the math when it makes the offset line or its making an error when it calculates the angle. It leaves the user wondering to what extent is Rhino’s inability to do basic math correctly going to cause them problems.
That is supposed to be what the Connect command is doing. Its shocking that so many Rhino users just implicitly accept that Rhino developers are incompetent. They just accept that the tools the developers provide are flawed and if the users really want something done correctly they have to do it themselves. Sure the users can extend lines to make sure they intersect but heaven forbid that a developer be expected to do that.
There is a command called Testnumberformat which will get Rhino to report numbers to double-precision floating-point limits. However since Rhino is sometimes incorrectly reporting within the eight decimal point limit adding more decimal places to numbers isn’t going to make the answer any less wrong.
The problem is that some commands, such as ‘connect’ and ‘chamfer’, don’t affect the geometry if the distance is minimal (by not affect i mean they don’t extend and trim the lines to intersection as expected ). Meanwhile, the join command joins two lines that don’t touch each other by averaging the distance of the gap.
The loss of parallelism is an effect of the join operation in lines that do not touch
I’m not sure what you mean by “base angle” but this bug only appears sometimes and I can’t tell what triggers it to appear. Sometimes it correctly reports that the angle is zero.
When Rhino does report that two parallel lines created by the Offset command are not zero you can move the offset line so that it overlaps the original (using end snaps) and the endpoints of the two lines are identical to 15 decimal places.and yet Rhino still reports the same bogus angle between the two essentially identical lines.
@Gijs The primary issue is with the chamfer, fillet, and connect commands, which fail to trim and extend the lines to the intersection when the distance is too small. That’s why the join command runs afterwards, modifies the endpoints, and adjusts the orientation of the lines. Of course, we also need an option in the join command to turn off document tolerance. However, if the other commands work as expected, then the join command wouldn’t affect the orientation of the initial geometry.