# Circle Domain

Can somebody explain me the logic behind this ?
I was going crazy to understand why a circle has this behaviour
and Honestly for me its a bug

We are used to a circle domain (0- 2 pi) or (0.0 - 1.0)
The domain on a circle reports correctly (0 -2 pi )
but evaluate at parameter pi is not where you think.
Another strange behaviour, If you scale a circle the point at same parameter moves
to another position.

gd

Ok I have found the logic

A mystery for me , but Ok when You know

gd

The circumferece of a unit circle is

2 * Pi

Evaluate Curve uses the length of the curve so

Alternatively you could also reparametrize the circle and use a domain from 0 to 1.00

Evaluate curve says “Evaluate at parameter”
and and You underlined the parameter domain is 0- 2 pi, and this is what gets printed
when You ask for the domain values.

The Length parameter is another domain where the parameter is the length (s) on the curve, this is not mentioned anywhere, the reason of my post

gd

The discrepancy is in the domain.

The domain of a line is 0 to length while a circle domain is basically just the angle domain in radians …

Why isn’t the circle domain 0 to length?

Good question

Well Yes

Honestly I don’t like the curve domain to be from 0 to L
In a script environment I would prefer to think in terms of unitless parameters
0 - 1.0 (normalized) is the best choice (at least for me).
You never make stupid mistakes

gd

In most situations I’d reparametrize curves for evaluation

What I always do, just for the circle I got crazy since thinking in terms of angles

anyway
good to know for the future

gd

Parameter is not the angle in radians, you get the parameter from Curve closest point or from value in domain 0 to 1 when you reparametrize the curve.

That is true for a circular nurbs curve but not for arcs and circles. The parameter domain for a circular nurbs curve is 0 to L, where L is the length of the curve. The length is, of course the circumference so L = 2 x Pi x r, where r is the radius.

The parameter domain for a circle is 0 to 2*Pi. It does not take account of the radius. Thus the assertion that it is an angle is correct.

This is inconsistent with other curve domains and I would agree that it is technically a bug. The dilemma, of course, is that if this is how it has always been, and not just a recent blip, then “fixing” it will break countless grasshopper applications.

Regards
Jeremy

The logic is described in the RhinoCommon API as:

Circles use trigonometric parameterization: t → center + cos(t) * radius * xaxis + sin(t) * radius * yaxis

Source:

https://developer.rhino3d.com/api/RhinoCommon/html/M_Rhino_Geometry_Circle_PointAt.htm

Sorry I am a bit stupid but cos(t) and sin(t) in that expression
means that the parameter is a angle in radians
but it seems its the arc length and not a angle (at least in the eval components)

gd

Yes I see what you mean. Using the Grasshopper Evaluate component on a non-unit circle doesn’t work as expected (i.e. having a 0.00-2*Pi domain). Calling `Circle.PointAt` or implementing the formula does work as expected though. For a normalised domain, you can always cast to curve and reparameterise it:

210909_CircleDomain_00.gh (8.1 KB)