could I get line start/end points without casting it into curve?
I see a file in the link below but that file has broken link
Thank you in advance, Dmitrey
The properties you are looking for are called “From” and “To”…
I tried it in my Python code, it yields message: ‘guid’ object has no attribute ‘From’
Then you deal with the wrong object. If you like to find the endpoints of a line, you obviously need to feed in a line and not a global unique identification number.
If it’s the GUID of an existing line (or curve) in Rhino, you can get the start/end points with
rs.CurveStartPoint(obj_id) and rs.CurveEndPoint(obj_id)…
line=rs.coerceline(obj_id) start=line.From end=line.To
The function coerceline is absent in the Rhino.Python Dash Docset Rhino.Python Dash Docset , that seems to be quite outdated.
The link above I got from the Rhinoceros doc page https://developer.rhino3d.com/guides/rhinopython/ . Will the docset be updated in nearest time?
Yep, the “coerce” functions seem to be “hidden secrets”… They don’t show up here either:
Yep, they sure don’t.
Isn‘t calling it „coerce…“ kind of unlucky? „getObjectFromID“ or something similar would be much more obvious. Or is there a reason for this naming?
Why? You force, pressure a GUID object to be a geometry object.
Yes, there is a reason - the “coerce…” functions actually try to return the desired object geometry from diverse input types, not just one. For example, coerceline will return a RC line object if you input a GUID, a linear curve, or a list of points…
Edit: this does seem to have some roots in computer terminology as well…
I’d like to see that in Grasshopper
The list with a single element I mean.
A few years ago, we tried to improve this situation and make things easier and more understandable by adding CreateX functions to Rhinoscriptsyntax. The problem was especially considerable in GhPython, where often users need points, vectors ect, rather than tuples, guid, etc. @scottd brought this up originally while writing the dev docs.
In general, CreateX functions do what coerceX* function do, but have the goal of being usable with good syntax, have a more coherent naming, and do not have to have the restrictions of being service functions used under the hood.
I worked on implementing a few of them: RH-37985. Most of them are available since Rhino 6 SR0.
The term “coerce” is just quite odd, at least if you type it in a english to german translator…
This is because they were originally only meant to be service functions. They are also counterintuitively cased. This was discussed a couple of years ago, and the decision was to add “good, more consistent” functions to the library. I worked on adding a few that were the most requested.