Hi all.
Rhino 7, Grasshopper component “Circle Fit” returns inaccurate/wrong results even with perfect input:
Instead, both Rhino command “_Circle _FitPoints” and rhinocommon method “Circle.TryFitCircleToPoints()” return correct results…
Cool. Strange. Sad. Not the kind of answer I expected.
I own Rh8 but still am not able to use it because of the so many regressions, and I’ve sort of gave up explaining how frustrating the whole situation is 
I understand new features pushed to last Rhino version, but this is a bug.
Unaware Rhino 7 users (that don’t visit the forum) and/or who can’t self-help with a script to bypass this problem, hitting upon a bug like this (or similar others) would just think Rhino being a bad software.
Like having a pair of compasses that make uneven circles…
Even worse using the function for lot of time, getting inaccurate results, going production, and lately finding inaccurate products and just thinking Rhino overall did a bad job… (the thing that just happened to me, but then I dig up and found this…)
On one side there is the risk of ruining Rhino reputation, on the other there is dev time spared (over a function that already exist and works good) and the hope users will buy upgrade.
Is it worth?
Sorry for the moralism, you don’t have to answer me.
Thank you for all your work.
I understand your frustration; I think it is a bug they have to correct has it could be done using some other Rhinocommon tool. CircleFit was introduced in SR2 in 2018 surely after Grasshopper component was done. See @dale answer here
“Circle Fit” is using Plane.FitPlaneToPoints then A = Sphere.FitSphereToPoints(P);
https://developer.rhino3d.com/api/rhinocommon/rhino.geometry.sphere/fitspheretopoints
Other bug with this method
Yep, I get this.
Fortunately, you’ve solved the problem in V7 - by using a C# component that calls Circle.TryFitCircleToPoints.
Best,
– Dale
Yes… something similar also here:
… btw, from what you linked:
SR2 … of Rhino 6, 5 years ago.
I’ve had that impression many times. Bugs (that shouldn’t be there with rigorous QA) go unfixed for years 
As if they just don’t care.
This wish was for a method to fit a circle through a list of points, which we added to Rhino 6 SR2 6 years ago.
This issue was about tuning up the method we added 6 years ago. This was fixed just 3 weeks ago.
Hope the timeline helps.
– Dale
what regressions in rhino 8 are holding you back?
is there a reason you can’t cull some of the points that are packed close together?
… sorry I made enough mess in other threads. Most of the problems I mentioned are still there after months. Generally it feels I won’t be able to use 8 at all as most of the problems are already pushed to 9.
This… but I see now it’s marked again as 8.x …
But generally almost everything (yes, everything) about the whole new UI with eto is just worse.
Any problem I or others wrote about the UI/UX or button/macro/toolbars is still there after months.
To make a list I should re-read all my forum posts of last year. I can do it, but is it useful?
What “8.3” means? It still feels like a beta. I’m sorry.
And this is OT. My fault.
Hi @maje90,
Don’t be - the UI complaints are legit. And they are being worked on, hopefully to the satisfaction of users.
– Dale
Back to the main issue.
@dale
This is grasshopper on 8.8.24170.13001, 2024-06-18 :
RH8 circle fit not good.gh (2.5 KB)
Rhino.
Not Grasshopper! Why so?
Even calling Rhino.Geometry.Circle.TryFitCircleToPoints() from a script gives the same result as Rhino. A good result.
But native component “Circle Fit” is still giving bad results!
7 months ago I already told the same things on my first post, Grasshopper on Rhino 7.
From what you said I expected Rhino 8 to already use the proper algorithm.
(but you should really consider to fix broken things on older rhino releases too, to save Rhino face, this is shameful!)
Typical case of “pointed the moon, and they looked at my finger…” Not even a YT was opened or linked. Did we/you just forgot about this?
This was a really really expensive and dangerous mistake for me.
Maybe another view on this. Open-Closed principle. You should not modify a component!Especially if its there for a decade and change how it works. Better would be to add another component on top of it. Why? Maybe because someone uses the default Circle Fit and works with the bad outcome. If you change the internal of this, you might break a lot of definitions. Other than that, I would never patch deprecated major versions unless its really critical. This is maintenance hell and pure evil. I mean you code in C# and you are always better of bypassing the limitations with custom solutions anyway. Other than that, its not a bug in a real sense. Its just a bad approximation algorithm. Changing the algorithm is a new feature.
This specific case is questionable.
Circle Fit is failing actually “simple” cases, where the point collection is describing a shape that do really look like something circular. We are not talking about a generic shapeless point cloud.
It’s a bug, or something of the same level of a bug.
Not a “it works differently”… it’s giving out a bad result! Better is better.
Bugs should be fixed even in past releases if it is something relevant, imho.
Anyway.
I reported in 2023 this case. Rhino 7 fit points was ok. Rhinocommon was ok. GH fail.
Dale told me “V8 does a better job” …
Well, current GH Circle Fit component in Rhino 8 keep creating bad results.
I see it as a big flaw. The better, correct code is known, but the simple implementation is not done.
I’m not asking for backward compatibility, make a new “Circle Fit” component that uses the correct rhinocommon call. I saw even simple multiplication components no longer being backward-compatibile. This is important!
Do we have to wait Rhino 9 or 10 to have this case fixed?
Please tell me also what are all the other GH components that are not taking advantage of Rhinocommon development!
This is crazy.
Yes. Rhino 9 is currently in development. It would make sense to introduce an algorithmic change with a new major version. Or again, you add another Fit Circle component which uses the new algorithm. I think this makes sense. Again if you create a definition, you update a minor version of Rhino, and suddenly your GH definition yields another result, then this is a problem.
Other than that, by all the problems we see in Rhino 8, I would simply take the workaround and create a C# script. How long does it make sense to wait for the devs to fix it? Its a niche problem. If I would wait for all of the bugs to be fixed, I couldn’t hold any of my deadlines.
I think this is stupid.
I fully disagree.
This bug is subtle and who used this function expected the correct function even in past. Noone rely on broken tools. And the positivity of fixing BUGS on older release is greater than the negativity of breaking some script that relied on wrong outputs.
This is a one line of code.
I hope McNeel team will do differently than what you said.
They had plenty of time to fix this case. Not fixing it is only wrong.
At least for 8.
It’s a function than “most” or “sometime” works correctly, but some others it give bad results… this while the same function on Rhino is working correctly.
Please, I’m serious, there are other functions in GH that I should not consider reliable and should stick to c# coding??? (which today, in SR, not SRC, is still a mess, I still jump in and out from 7 only for that)
If I have to code it myself, why buy new versions?
This is a know old bug.
Works on Rhino or Rhinocommon but fails on Grasshopper.
You have “reasons” to voluntarily NOT fix it on Grasshopper? Dumb. But ok, let’s wait next big release!
I reported it from Rhino 7 (and it was known in 6, so it was already old there) a month away after Rhino 8 release. No reason to fear backward compatibility, the release is young!
Dave told me it is fixed, I assumed he meant in GH too. (this thread is tagged “Grasshopper”)
Now 7 month after, I was using it on Rhino 8!!
The error is small, subtle, I had probably thousands of object created depending on that. Mostly were fine (or I weren’t able to see the defect).
Now, out of thousands, a couple of hundred of elements come back after production because the error is big enough that need them to be re-made.
Surprise!
The multiple-time reported, subtle bug, which is easily fixable by the devs (they already have the correct algorithm, since… years?)… is still there!!!
Do we have to keep track of bug ourselves? Store files, test every function for change every release?
W T F
I only want to give you another view on it. I’m not trying to make you mad or something. I only view it from my own experience in releasing software to hundreds of users. Its a common misconception that a user can properly judge effort and comment on release plans. I only wanted to point out that there are other factors to consider, when “bug”-fixing. I can only imagine that its a magnitude harder for McNeel devs.
