When typing coordinates to create a point, there is a difference in behavior between this 5<5<5 and this 5,5<5in regards to how z-elevation is treated.
When both Y & Z are given in this notation, the point is first positioned in X, then rotated on the Cplane to get the Y and then rotated once more to get the Z.
When only Z is given in this notation, the point is first placed on the XY and then lifted perpendicular to the Cplane to intersect the line that has the specified angle to the Cplane and crosses the origin.
Here Entering Numbers | Rhino 3-D modeling it is called “Spherical“ which suggests a transformation that would keep the point on the surface of a sphere.
Both functionalities can be useful but at the moment the behavior is not consistent.
Point goes up in Z by means of linear movement, i.e. elevation mode, until the angle constructed with the point in step 2, the origin, and the final point in step 3 is 20°.
I would expect the 3rd step to be executed in the same fashion as in the first example. That would mean that the point from step 2 -at 20,20,0- will rotate by 20° to maintain contact with the surface of the imaginary sphere whose radius is determined by the given XY coordinates (in this case 20,20).
The “spherical” name applied to x,y<elevation angle form of coordinates can be confusing as “spherical” coordinates are usually associated with a distance and two angles.
The “x,y<elevation” angle form of coordinates is an unusual hybrid of cartesian coordinate and spherical coordinates. A quick online search did not find any other uses of it. Perhaps it could be labeled in Help as “Hybrid” form of coordinate entry.
Way back a choice was made by someone of how to intepret coordinates of (something),{something)<(something). Rhino’s use of that interpretation dates back to at least Rhino 4 (2007) and presumably goes back to when angle coordinates were introduced. I would be extremely surprised, astounded actually, if there is any willingness now to consider changing how Rhino interpretes that form of coordinates. To do so would cause errors for code and methods developed using that form of coordinates before such a fundamental change.
Rhino’s interpretation of x,y<elevation angle may not be consistent with your interpretation, but it is consistent with how it is defined in Help:
Spherical (x,y<elevation angle)
5,6<15
“x,y” are the x and y coordinates of the point. These coordinates are independent of the elevation/height of the point; the same as in an “x,y,z” coordinate entry.
“elevation angle” is the angle with the xy plane of the line from the origin to the point. That is the usual definition of elevation angle.
If we define “elevation angle” as you describe -which I agree it makes sense- then why in the x<y<z case named “radius<rotation angle<z-elevation angle“ it behaves differently? The Z is still named “elevation angle”. I would expect it to be named “radius<Y rotation angle<Z rotation angle” instead.
Anyway, it appears to be one of these legacy things that the overhead cost of changing the code outweighs the pros, if it dates back to Rhino 4 as you say. I just happened to stumble upon it.
