You may claim that is true, but the fact is most of the scripts I have seen posted to this forum do not first obtain the Rhino object and then get the geometry. That is because a lot of McNeel example code teaches them to do that. So your claim that it can only be done "by first obtaining the Rhino object " is just plain wrong. It certainly runs contrary to what they are taught by example.
I agree 100 % that given the current way it works scriptwriters should be taught to first obtain the Rhino object and from there get the geometry. The reason they should be taught to do it that way is because if they get the geometry without the Rhino object then they may not have access to the objects other attributes.
But it doesn’t have to be that way. It would be dead simple to provide a property for object geometry to allow users to get the objectID of the object it came from just like the object attribute class has.
I know what is happening behind the scenes. My point is other scriptwriters are entitled to know what is happening behind the scenes. There is no reason to run this like a game of Three Card Monte.
How is your little gem about opennurbs at all useful to programmers who are writing scripts based on RhinoCommon?
I guess what you might be trying to say is that only objects in the document have IDs.
To which I reply So what? So far this discussion has been about the attributes and geometry of objects with UIDs
ObjectAttributes are opennurbs also and yet they can store a copy of the object’s ID (if there is one) from which they came. The logic of what you are saying is inconsistent.
The question I have is that when a script writer creates a variable that is of the type object attributes that came from a Rhino Object that variable provides access to the Object’s ID. Why not do the same for the object geometry?
@dale
thanks for your effort in above explanations.
I think it would be great for beginners to find this information about RhinoObject - Attribute - Geometry - Id - ObjRef in the Rhioncommon guide.
Similar to such great Articles like the one for Display Conduits or Brep Data structure.
@jim
I think Rhinocommon is one of the most powerful and most accessible CAD - API s especially if you look at the value for money.
If beginners start with the right example like Extend Curve I think the relation between ObjRef, Object, Geometry and Attributes are quiet clear.
Yes, That script shows that the sequence of relationships is:
First, the script gets an ObjectRef `
Second it gets the Curve Geometry
Third it modifies the Curve
Fourth it Replaces the original curve using the ID that it gets from ObjectRef
At no point does that script ever call the CurveObject which is the RhinoObject that owns the geometry in this script.
Meanwhile Dale is telling users “There is no other way to obtain the geometry other than by first obtaining the Rhino object and than asking it for it’s geometry.”
None of it helps explain why you are doubling down on making this inaccurate statement:
“There is no other way to obtain the geometry other than by first obtaining the Rhino object and than asking it for it’s geometry.”
Yes that is how it works . And that means the script does not have to first obtain the Rhino object and then ask it for it’s geometry. The ObjRef provides methods that work like a game of GoFish. You ask the ObjRef does it have a curve and if it does it will give you the curve geometry. If its not referencing a CurveObject it will effectively tell you GoFish.
That is not at all the same thing as getting CurveObject first and then asking it for its geometry.
The script did obtain a RhinoObject - it prompt the user to pick a curve. Now the script has a RhnoObject that is referenced by the ObjRef returned by GetObject.