Rhino is driving me crazy. I created all the lines in the attached drawing using Offset (they’re all degree-1 curves). When I export to AutoCAD, most of them are detected as parallel, but not all. Something seems wrong.
That’s hard to believe. Many of the lines are not equal to an offset of any other line in your drawing.
The black lines in particular can not be made by offsetting any other line
Well, they could be made by offsetting other lines and then editing the offset ones, by e.g. scaling, moving, connecting and splitting, wherein slightly inaccurate editing destroyed the initial parallelism.
@ar00302, Below I have run offset against many of the lines in your drawing. They are all true offsets indicating that Rhino offsets fine. In half a dozen cases your lines differ. Unfortunately you don’t indicate which lines are original and which should be offsets but if you overlay similar offsets on your own model (use the throughpoint option and pick one end of your errant offset to easily get the position, rather than entering a distance) you will see where your lines are out, and by how much.
HTH
Jeremy
What happened in the lines shown in my video? What am I doing wrong?
Without knowing what steps you went through to produce a line, it isn’t possible to do better than guess. Given that Rhino offsets correctly, it must be in the subsequent steps. You need to think about where you might be slightly imprecise.
For example, when scaling, picking a point that is not quite on a line, perhaps because you are getting an adjacent grid snap, or an intersection or perpendicular snap to another object.
To gain insight into your practices, you could try making your offsets and, before editing the offset lines, copying the offsets to a new layer with a distinctive colour and locking that layer. Then work with the first offsets and, as you edit them, see if a deviation in alignment with the locked copy appears and review what you did in that step to cause it.
HTH
Jeremy
Its difficult to see in your video but I think I can see what you are talking about.
It looks like what you did was first offset a curve and then measure the angle and it reported an angle of .000000085. That’s a bug in the angle command. The correct angle is something close to .000000000000001 degrees.
The second thing you did was use the chamfer command to connect two parallel lines. After that operation the Angle command correctly shows the angle as .00000000 degrees. Eight decimal places is the maximum.
The third thing you did was connect the other end using the chamfer command. After that operation the angle command in your video indicates an angle of .00026919. That is indeed the angle between those two curves in the file you posted. Those two curves are definitely not parallel.
I was not able to reproduce what your video shows in step 3. I have no explanation why the chamfer command (connect command) made the curves no longer parallel. The file you posted does show the curves are not parallel and are at an angle of angle of .00026919.
I was able to repeat the bug in the angle command that your video shows.
Here is a file with just the 3 lines involved. Can you offset the middle line and then connect the side two lines to make the offset line no longer parallel?
offset_parallel.3dm (32.4 KB)
If you can find a repeatable way do what your video shows post again under a new topic with the word Bug in the title with instructions on how to repeat the bug.
Nope , your statement is false. Scaling, moving,extending and splitting a line will never change the angle of a line (unless there is a bug). The OP’s curves are all coplanar, so connecting coplanar lines by extending trimming and joining (chamfer 0,0) should also not change the angle of either line. The deviation is so small you can do any of those operations a million times on a line and still not see a change in angle larger than the display precision that Rhino allows the user to see.
However, it looks like Rhino’s Angle command has a bug that reports phantom angles when the actual angle is much smaller than the .00000000 degrees which is the smallest angle Rhino will show the user.
If you create a line and then offset it and then move it using end snap so that the original and offset overlap you will find that CrvDeviation reports less than 10e-14. That translates to an angle of less than .0000000000001 degrees on a curve 3 units long. .
Actually:
That is not the Scale command.
No, it’s the Scale1D command. It’s used for scaling things in a single direction. As you can see, it can change the direction of a line if not applied along the same initial direction as the line.
@jim I’ve posted before about coordinate error reporting. You’re right: the actual accuracy should correspond to double-precision floating-point limits. What I can’t explain is why Rhino sometimes reports 0.000000085 and other times 0.000000000 for the same kind of geometry. If it’s a reporting bug, it’s inconsistent — which makes it an even bigger problem.
@jeremy5 Wasn’t it clear in my video that all I did was offset a planar degree-1 line and chamfer it with other planar degree-1 lines?
I reproduced it once in a blank file, but I can’t get it to happen consistently. I have no idea what causes it, but it’s clearly a serious issue. If I figure out the cause, I’ll definitely post an update.
@jim I tried something in your file, but I’m unsure if what I’m seeing is caused by a reporting bug.
The original file shown in my first video includes a point cloud. I’m unable to post it publicly, but I can send it privately to any McNeel staff member who is interested.
There are two separate bugs that your video shows,
One is that the angle between the two lines immediately after doing the offset is
.00000085 degrees instead of the correct .00000000 degrees. All results are truncated to eight decimal places. Later in your video after doing the chamfer it correctly shows the angle to be .00000000
The second bug is when you do the second chamfer it shows an angle of .00026919. That angle is the same as the angle in the file you posted. So in that case the angle reporting is correct (to 8 decimal places).
Your video makes it look like the chamfer command changed the angle of the line.
The problem is Rhino developers won’t investigate a bug unless you provide geometry where the bug can be repeated. I have not been able to repeat what is shown in the video.
BTW, You might consider using the Connect command instead of chamfer. The Connect command is intended as the official way to automatically extend, trim and join lines as you are doing. The chamfer command is one of the ways users used to do it before the Connect command was implemented.
Hi, I didn’t have time to study your video initially. However I have taken a look with the benefit of @jim’s helpful summary and I can reproduce the issue. However as I don’t have a copy of your lines before you ran the chamfers you probably should see if you can repeat it as I am making an assumption about the state then.
The first chamfer is fine so let’s get to the second. The line indicated is approx 0.014mm short of the intersection:
If you extend the indicated line so it crosses the baseline then the chamfer will create a correct intersection and not move the baseline.
Note that Connect Curves has the same flaw as the chamfer, so swapping to it won’t help in this case. The workaround is to make sure that lines do not fall microscopically short of the true intersection point before connecting them.
I’m tagging your thread with ‘bug’ because McNeel should look at this.
HTH
Jeremy
@jeremy5 Please try this file — the error is reproducible instantly. Rhino fails to create parallel lines, and I have no workaround. Should I open a new post? This looks like a critical bug. I only discovered it by luck, and I’m worried it might be happening far more often, leading to serious downstream geometry errors.
reproduce_here.3dm (2.7 MB)
This is the same issue I found last night: the right hand blue line stops a microscopic distance short of the offset line and when connecting the two, the intersection is pulled to that end point.
If I extend the blue line so that it reaches the offset line then connecting leaves the intersection in the correct place.
If I draw a 0.001m radius circle centred on the true intersection point and use that to trim the blue line back so the end is one tolerance length from the offset line, then the connection creates the intersection in the correct place.
I don’t know how you are fixing the ends of your blue lines, but assuming the lines were created by offsetting the adjacent orange lines then, rather than shortening them prior to connecting the bottom offset, leave them crossing the bottom offset line and let the Connect Curves command trim then.
That should avoid the problem, assuming it only occurs at microscopic gaps as currently suggested. It did here.
HTH
Jeremy
Thank you for your time. This solves the problem. That’s why I solved the problem in the north wall by extending and trimming. I had the same issue there as well. Now I have to check everything, and I don’t even want to think about how many models might be affected. At least now I know how to fix it.
But we should make another post about a critical Rhino bug: the Connect and Chamfer commands are modifying geometry orientation. Why should such a tiny gap affect Connect or Chamfer?
Also, is it true that 0.00000085 is just a display issue and actually means 0.00000000? And why do I sometimes get one value and sometimes the other?
I’ll open another post about the Chamfer and Connect issue.
After correcting that issue, I can’t find 0.00000085 anywhere in the document anymore. Everywhere it now shows 0.00000000. Is this something we should take into consideration?
FWIW, if you use the blue line to trim the offset line at both ends, the offset line remains true. Then _Join the blue and offset lines, that too will pull the offset off line - one to add to the list of commands adversely affected by micro gaps…
An angle of 0.00000085 degrees is equivalent to an offset of 0.0148mm in a distance of 1km. I believe that the curvature of the earth dwarfs that at 8cm. I’m not going to lose sleep over it.
