RhinoObject vs ObjRef in ObjectTable Methods

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

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).


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

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

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