Arc tan / tan / radius fail

[jogo0664]

Hello Forum,
We have 2 different circles R ~ 450 and 550 mm. we connect these with an arc using tan/tan/radius (R~4000). after trimming, the curves cannot be connected to form a closed curve. The touch/trimming in some places does not fit and fails. In a different place for each copy. The same on different PCs under different Rhino 8 Srs
Does anyone have an explanation for this?
Many thanks in advance
Uploading: Bathtub Trim and Join fail.png…
Uploading: Bathtub Trim and Join fail.3dm…

[Tom_P]

your file upload is not working / finished - please fix the post / upload.
and please also update the category - it s not “news” it s pure rhino windows.

my guess:
the intersection generated by trim is somehow imprecise.
if curves are close tangent and have larger radi the length where they are within tolerance (+/- 0.001) is quite long.

workaround
instead of using _trim or even worth _curveBoolean :
draw the connecting _arc (tangent tangent radius)
now use
_split with option point and proper _endSnap
(top in my screenshot)

or redraw the partial circle with
_arc again with proper snapping _CenterSnap _endSnap _endSnap
(middle in my screenshot)

(bottom - the initial circles and arcs)

tangentArcs_Join.3dm (2.8 MB)

EDIT
to show the precision issue:

Circle with R660
and an invisible 2nd Circle with offest of 0.001 mm
R4000 Arc that is tangent to the 1st circle.

the 2 points are the intersection points - and have a distance from 1.26mm …
and within this 1.26 the curves overlap in terms of the document tolerance… (less then 0.001)

hope this helps - kind regards -tom

[jim]

@jogo0664

We have 2 different circles R ~ 450 and 550 mm. we connect these with an arc using tan/tan/radius (R~4000). after trimming, the curves cannot be connected to form a closed curve.

If you are starting with two true circles ( 450R and 550R ). then it is obviously a bug. The intersection point of any two tangent arcs is on a line defined by the centers of the arcs.
Rhino should have no problem computing the intersection point precisely or with trimming and joining the arcs.

[jeremy5 (Jeremy)]

@jim

it is obviously a bug

Yes it is, and repeatable without knowing the exact positions of the OP’s circles.

But while using the arcs to _trim the circles is inaccurate, using _split is ok: it allows the segments to join into the expected closed curve.

As does using _intersect between circles and arcs to generate points that are then used instead of the arcs for the trim!

Furthermore, using the arcs to trim the circles can work, if the model is in a different position on the canvas. And _trim works if the model’s absolute tolerance is dropped from 0.001 to 0.01.

@jogo0664, I’d recommend adding a “bug” tag to your post.

TrimInaccurateHere.3dm (62.4 KB)

[Tom_P]

there is a similar - nearly identical topic here - did not get much attention though…
_curveBoolean produces similar intersection / overlapping issues.
… and just checked:
reported 2021-03 - still not solved in 2025-02

_curveBoolean Bug

for me this seams like a bug: (mac os x, rhino 7) _curveBoolean adds an unnecessary segment, and that segment is even not tangential: [Screenshot 2021-03-01 at 22.12.08] (top) initial curves with CVs (middle) initial curves and _curveBoolean Result (bottom) result only. curve_boolean_bug2.3dm (67.6 KB) thanks for having a look at it. kind regards. -tom

I still love the idea of dedicating my money for the updates to certain features.
I called pay and vote and posted here
I would love to see those issues being fixed - with much more importance than new fancy icons in V9…

cheers - tom

[nathanletwory (Nathan 'jesterKing' Letwory)]

@Tom_P

with much more importance than new fancy icons in V9

FWIW programmers are not working on those fancy new icons…

[Tom_P]

… sorry… this was not directed against anybody personally.

thanks for digging into this topic.
looking forward to see / read any updates.

best - tom

[jim]

@jeremy5

And _trim works if the model’s absolute tolerance is dropped from 0.001 to 0.01.

The model tolerance shouldn’t make any difference. Rhino should be able to accurately draw a tangent 4000R arc using tan/tan/radius option and trim or split the circles accurately.
This is basic grade school Geometry and its shameful that the developers are flunking simple math.

I used Gcon command to get this readout after trimming the circles with lines:

Edit:
By the way, after trimming the one side with the lines as shown above you can use the fillet command (with trim=yes and join=no) to do the other side. Done that way it will be accurate.

The problem with trimming inaccurately to only within tolerance is that when the arcs are joined at an inaccurate junction the arcs become mangled and inaccurate. That means surfaces created from the inaccurate arcs will also be inaccurate and plagued with the problems that causes.

[nathanletwory (Nathan 'jesterKing' Letwory)]

@jim

This is basic grade school Geometry and its shameful that the developers are flunking simple math.

Please in your Rhino copy run _ScriptEditor or _EditPythonScript, create a new Python script and with all your wisdom run

a = 0.1
b = 0.3
c = a + a + a
if b == c:
    print('jim is awesome, even arithmetic is simple')
else:
    print('jim flunked simple math')

Or if you think I’m stacking against you by using Python in Rhino 8 use _ScriptEditor, start a new C# script and use this code:

using System;

double a = 0.1;
double b = 0.3;
double c = a + a + a;

if(b==c)
    Console.WriteLine("jim is awesome, even arithmetic is simple");
else
    Console.WriteLine("jim flunked simple math");

[EricM (Eric Paul Marvets)]

Floating point shots fired…

One of the earliest helper functions I wrote for my plugin:

let inline notZeroishP (x: float) = 
    abs(x) > docTol

let inline isZeroishP (x: float) = 
    abs(x) < docTol
    
let inline isEqualishP (x: float) (y: float) =
    abs(x - y) < docTol

[jim]

@nathanletwory

Please in your Rhino copy run _ScriptEditor or _EditPythonScript

Your script has nothing to do with the topic being discussed and its appalling that you think it does. Or are you just trying to be a troll?

Finding the point where the circles should be trimmed can be calculated (as I demonstrated) to a precision of less 1/100 of a nanometer if its done correctly. When it turns out that Rhino is incapable to calculate the point to even 1/100 of a mm that is a serious bug. It makes you and the other Rhino programmers look like amateurs.

[jeremy5 (Jeremy)]

Let’s not drown out the report of a bug with a not uncommon lengthy discussion of floating point arithmetic. Please, can the topic be split?

[jim]

@EricM

One of the earliest helper functions I wrote for my plugin:

Your helper function is not helpful. The document tolerance is irrelevant.
The typical user tolerance is at least one billion times larger than the amount of accuracy required.

As I said before if Rhino does not do this correctly then it screws up the downstream geometry that is derived from this geometry.

@jeremy5

Let’s not drown out the report of a bug with a not uncommon lengthy discussion of floating point arithmetic

Absolutely. I’m confident the programmer that will fix this bug understands how to work with floating point arithmetic.

[jim]

@jogo0664

We have 2 different circles R ~ 450 and 550 mm. we connect these with an arc using tan/tan/radius (R~4000). after trimming, the curves cannot be connected to form a closed curve.

Instead of using arc tan/tan/radius try this:
Draw a circle in the middle and trim holes in the two circles (see pic below) after you cut the circles you will be able to use the Fillet command (with trim=yes) to get Rhino to produce an accurate result.

The fillet command can’t trim closed curves so you have to change the circles into open curves to get the trim function in fillet to work.

[Gijs (Gijs de Zwart)]

@sfp fyi

[jogo0664]

I have tried countless variations with different, large radii. Trim fails (the curves cannot be connected). _split, delete, connect always works. There is obviously an error in the trim command.