RhinoObject vs ObjRef in ObjectTable Methods

Rhino Developer
1

I try to grasp why some functions require / return RhinoObjects and some ObjRef.
E.g. ObjectTable.GetSelectedObjects() returns a IEnumerable<RhinoObject>, but then again i need: ObjectTable.Select(ObjRef) to select them back…
Is there a fast way to cast this?

Also all(?) ObjectTable.Find methods return a RhinoObject - where to get the ObjRef? Or is it just used in User picking?

And last question - i read here that ObjRef is lighter than a RhinoObject, but both are just references to the RhinoDoc, as i cannot construct a RhinoObject from code… what makes them (potentially) lighter?

1 Like
2

If you have a RhinoObject instance already, you can select/deselect it using the RhinoObject.Select(boolean) method (or one of the more specialized versions).

http://developer.rhino3d.com/api/RhinoCommonWin/html/Overload_Rhino_DocObjects_RhinoObject_Select.htm

The ObjRef only contains as data the ObjectId, the ComponentIndex and the RuntimeSerialNumber of the object and can therefore be considered “lightweight”; the RhinoObject contains a copy of the entire geometry which takes much more memory (it is not, as you say, a reference to the RhinoDoc!). You can create an ObjRef from the RhinoObject.ObjectId guid.

1 Like
3

Thanks, I think I understand now! That is why ObjRef.Geometry() is a method and updates as the geometry changes, while RhinoObject.Geometry is a property and unrelated to the document, right? If I follow correctly that would also explain why RhinoObject.CommitChanges() is needed - as it says: “Moves changes made to this RhinoObject into the RhinoDoc.”

So does that mean to edit an Object, I always have to get the RhinoObject, make changes and commit back to the Document? So basically a (temporary) copy is made?

1 Like
4

Yep, that is the idea. Or you can replace the geometry using the object ID of the old object, using doc.Objects.Replace(...).

1 Like