As we can see in the image and the Grasshopper file, i have attempted to graph a circle using the algebraic expression or a piecewise function of a circle which is x^2 + y^2 = r^2, and connected the points thus graphed using a polyline, The resulting polyline is a geometry which can be classified as a circle as mathematically it satisfies all the criteria for being classified as a circle yet Grasshopper Datatype refuses to recognise it as a Circle which can be understood to be an artefact of written code which seems to be not following fundamental mathematical accord which is why i suggest that we restructure known datatypes or edit basic datatypes to include functionality which may render them to be more precise with regards to fundamental mathematical accord.
In the given image for example the Circle datatype must assess the polyline and recognise it to be a valid circle and so on and so forth for every other datatype which may share such hierarchy wherein every polyline or interpolated curve cannot be a valid circle but a closed polyline or a interpolated curve which is equidistant from a common Locii can be said to be a Circle and hence must be recognised as a Circle.
This is true for all geometric heirachies.Thus improving the interoperability of Datatypes.
I would expect polyline could only be cast to a circle if the length of its segments is small enough. But Curve.TryGetCircle () doesn’t work even with a regular polygon of 100000 segments and radius 1. So it’s a problem of that method in the Rhino SDK.
It is debatable whether or not a PolyArc can be Considered to be CircularArc (Also this throws an exception)but even so, An open Circle graphed using the algebraic method should be considered to be an Arc which is again not being recognised as an CircularArc,
Keeping this in mind when we consider that,none of the below mentioned
ways of constructing a ConicArc is recognised as a circular arc but merely as an arbitary curve and also that we have an exclusive Datatype for a CircularArc,
Now if Ellipse is recognised to be a Circle then an Elliptic Curve constructed using the above methods should also be considered a CircularArc but this is not Mathematically true,So woudnt it be better to accomodate ConicArcs(Parabola,Hyperbola,Ellipses) as a unique new Datatype rather than an arbitary curve as we have an exclusive datatype for CircularArc ?
And recognise all of the above as Circles Ellipses or Conic Sections irrespective of the method they are constructed with their respective parent Datatypes?If Ellipses are Circles and CircularArcs are Curves then ConicArcs should also be recognised as parent datatype Curve.
If you use a discrete representation of a circle then its not a circle but an approximation of it.
The moment you evaluate the expression, the moment its not a circle anymore. You need to provide the parameters to an circle object. Note, a Circle, NurbsCurve or any other geometry expressed by parametric equations can create any point at any parameter at any time. Thats the fundamental advantage of CAD in general and the ultimate reason why technical drafting is not done with polygonal modellers.
Furthermore I don’t like the idea of wild casting. A vector is no line although you can convert them directly in GH.
Discretization argument does not hold true here because the Geometry constructed here is in itself using the equation of a Circle (x^2+y^2=r^2) which means algebraically atleast this is a Circle. If we are to accept the Circle in NurbsCurve type then there is no escaping the fact that mathematically speaking Circle in NurbsCurve type is not mathematically complete and does not encapsulate all circles possible in the Mathematical domain but only a derived subset of it…
I agree wild casting must be eliminated atleast vector to line type.
Yeah but your polyline object does not store this information. You convert a polyline to circle and not the equation to your circle. Of course it could try to fit a circle to a polyline. But this can be done with multiple algorithms. Same as NurbsCurve to Circle. (Furthermore I believe the circle object uses the parametric equation of a circle.)
The Contradiction lies in the Circle type which oddly refuses to accept a geometry constructed using the Mathematical equation for the true Circle itself.
Because it doesn’t store the equation, so it has no parameters anymore. A polyline can be anything. Its a list of points (which renders a line in between). It doesn’t hold any metadata. Without metadata your only option for this operation is fitting. And there is a component for this.
Rhino has a strong technical bias, often prioritizing irrelevant technicalities rather than giving the user the job done. I don’t know if it’s part of their culture or just an impression of me. But I, as a user and developer, would expect their method of trying to convert a curve into a circle to work as long as it can be done below a deviation, not to prevent it for technical reasons that are perfectly avoidable using another of their methods. Or at least, a reference to the other method in the documentation. Two methods with the same usefulness but that work differently and therefore, their areas of use are different, is only carrying irrelevant technicalities to the user/developer and blurs the SDK. I’m not against it being very technical software, but there seems to be a phobia of heuristics.
Well keeping in tune with the assumption that an Ellipse is a Circle in Rhino this is what we get when we plug the Fit Circle component to the equation of an Ellipse.
Issue is to introduce new exclusive Datatypes for Ellipse and Conics or to update existing ones to accomodate Conical geometries in a more mathematically accurate and consistent way.
