In Rhino 8, if I draw a circle, then draw two straight curves straight down from the left and right quadrants of the circle, then use the straight lines to trim the bottom half of the circle, I’m left with something that looks like the image attached:
If I do the same trim operation in Rhino 7, it leaves me with a simple half half circle with just 5 control points. In Rhino 8, the semi circle has 9 control points…
Well, in fact, the thing with 9 control points is not a semicircle. You might want to start over with your full circle and check that it has only 8 control points and then watch closely what happens with the control points as you add the straight lines and then trim. Something is probably not going as you expect during those operations and by checking when it happens hopefully you’ll see what it is. One possibility is that the arc is becoming non-planar for some reason.
Which version of Rhino are you using?
I have: 8 SR8 (8.8.24170.13001, 2024-06-18)
Could it be a tolerance setting?
Cheers
Here’s some system info if it help:
ystem Information report written at: 06/28/24 12:20:02
System Name: LAPTOP-BBOC9SQF
[System Summary]
Item Value
OS Name Microsoft Windows 11 Home
Version 10.0.22631 Build 22631
Other OS Description Not Available
OS Manufacturer Microsoft Corporation
System Name LAPTOP-BBOC9SQF
System Manufacturer Razer
System Model Blade 16 - RZ09-0483
System Type x64-based PC
System SKU RZ09-0483SWH3
Processor 13th Gen Intel(R) Core™ i9-13950HX, 2200 Mhz, 24 Core(s), 32 Logical Processor(s)
BIOS Version/Date Razer 2.02, 19/09/2023
SMBIOS Version 3.5
Embedded Controller Version 1.09
BIOS Mode UEFI
BaseBoard Manufacturer Razer
BaseBoard Product SO690
BaseBoard Version 4
Platform Role Mobile
Secure Boot State On
PCR7 Configuration Elevation Required to View
Windows Directory C:\Windows
System Directory C:\Windows\system32
Boot Device \Device\HarddiskVolume2
Locale United Kingdom
Hardware Abstraction Layer Version = “10.0.22621.2506”
Username LAPTOP-BBOC9SQF\zanda
Time Zone GMT Summer Time
Installed Physical Memory (RAM) 64.0 GB
Total Physical Memory 63.7 GB
Available Physical Memory 48.7 GB
Total Virtual Memory 73.7 GB
Available Virtual Memory 53.7 GB
Page File Space 10.0 GB
Page File C:\pagefile.sys
Kernel DMA Protection On
Virtualisation-based security Running
Virtualisation-based security required security properties
Virtualisation-based security available security properties Base Virtualisation Support, Secure Boot, DMA Protection, UEFI Code Readonly, SMM Security Mitigations 1.0, Mode Based Execution Control, APIC Virtualisation
Virtualisation-based security services configured Hypervisor enforced Code Integrity
Virtualisation-based security services running Hypervisor enforced Code Integrity
Windows Defender Application Control policy Enforced
Windows Defender Application Control user mode policy Off
Device Encryption Support Elevation Required to View
A hypervisor has been detected. Features required for Hyper-V will not be displayed.
I have considered that.
I even tried projecting it all to the C-plane first. Still doesn’t work
And as I said I can copy and paste the exact same lines, in the same position, from Rhino 8 to Rhino 7, and join them successfully in version 7…
Posting pictures doesn’t really provide much info.
What could be happening is the lines aren’t exactly vertical or they don’t have there endpoints exactly at the quadrants of the circle. The reason it won’t join is because the endpoints of the lines and arcs are not within tolerance.
In general trimming arcs (or circles) with tangent lines is an iffy operation in Rhino. If you are meticulous in constructing your lines and arcs it should work but the tiniest deviation from perfect will produce errors like you are seeing.Whatever went wrong Its not something anyone will be able to see from a picture.
Ok, it seems like this behaviour only happens when I’m drawing inside a model that I originally drew in Rhino 7, and that has a lot of existing geometry in it.
If I delete everything in the model and Purge, I can then trim the circle and join to the lines successfully.
Here is the arc and lines that I can’t join, that I created before deleting all the geometry in the model:
If I zoom in I can see that the ends of the arc and straight lines are not coincident
But I drew it in exactly the same way as I did in Rhino 7 or an empty model… for some reason the existence of the old geometry and layers seem to change the trim result?
You have your absolute tolerance set to 0.00001 units. Set it to a more reasonable 0.001 and the join works as expected.
(The left end of the semicircle is 0.0000164 mm from the end of the line. This is a meaningless distance in the real world but outside the tolerance you have set.)
That may be “meaningless” to Jeremy, but to me it means he did something wrong and ended up with a much larger error than it should be. The error is roughly a billion times larger than it would be when one carefully does the construction of the arc (or circle) and lines.
There is more than one way to construct this geometry. What way did you use?
If you draw the circle and then draw the lines by snapping to the Quad points on the circle you should end up with the arc and lines having end points that are more accurately constructed.
The curve you have with 9 control points is not a true arc. It is a NURBS curve. This is one of the possible consequences of inaccurate trimming and joining of tangent lines and arcs. When Rhino joins two curves that have tiny errors it does not fix the errors it distorts the geometry to correct the misalignment. This may have downstream consequences where on future operations that depend on accurate computations such as intersections and offsets.
Thanks for your concern regarding my drawing technique
yes I use snap points, and I snapped to the quadrants of the circle
and as I said in my previous posts, if I draw this in a model without other 3D objects and layers in it, I have no issues
Unless I’m missing something I don’t think it has anything to do with the method I used to draw it (I’d hope so after almost 20 years CAD experience)
Really messes with my OCD that snapping to the quadrant snap points, of the circle, doesn’t make the ends of those curves perfectly coincident
But I’m still curious as to why it should make a difference as to whether there’s other objects/ layers in the model as to the result of this operation.
I can use exactly the same model - delete everything in it - and then it works perfectly, including trimming the circle to a simple arc with 5 control points
I’ll mess around with it a bit more and let you know if I find anything
I just tried something else
If I turn all the layers in my model off, then it works fine
For some reason having a large amount of visible objects in the model seems to cause this problem?
I think you are making the incorrect assumption that the source of the problem was the quad snap and the construction of the two lines. I don’t think the problem lies in your construction of the two vertical lines.
I think the main source of the problem is a bug in the Trim command.
In the enclosed file NEWx.3dm (39.6 KB) I discarded your arc and made a line connecting the endpoints of the two vertical lines. Rhino says the blue line’s length is exactly 50mm. I then made the green circle. When I trim the green circle with the black lines I get the same inaccurate result you were getting. It also results in an arc with 9 points instead of the expected 5 that an 180 degree arc would have.
If instead of using the black lines to trim the circle, I use the blue line as the cutter it will trim accurately so that the ends of the resulting arc and the black lines are precisely the same. Another way to trim the circle accurately is to run the intersect command using the circle and two black lines as input. Then trim with the intersect points. That also produces a precise result.
Change the absolute tolerance to 0.0001 first and the black lines trim your green circle accurately, the arc is a proper arc, end positions coincide and the join works. Interesting that too tight a tolerance breaks the trim rather than causing it to fail.
Why would anyone expect Trim to fail with a tighter tolerance when Trim is quite capable of trimming with an accuracy of a billion times greater than this tolerance?
But you are correct this Trim bug seems to be influenced in some way by the tolerance. A looser tolerance produces a more accurate result might be a clue to fixing the bug.
