RhinoCommon references to objects

I use RhinoCommon to develop plugins with .Net.

It seems that it’s not possible to store references to objects. I always have to store the id of the objects which is not very effective. Also methods like Geometry.UserData.Find() always return a new instance of an object.

Is this a restriction of the .Net wrapper or also of the C++ SDK?

1 Like

What do you mean by “references to objects”?

You can have a variable of type ObjRef, or RhinoObject or GeometryBase (or one if its derived types). However if you want to access an object much later, then storing the Id is probably the best way to go.

Hi David!

I get a UserData object with Geometry.UserData.Find() and store it in a variable (reference to the UserData object). But it seems that UserData.Find() always creates a new object so the reference doesn’t make sense. Also when I move the geometry in Rhino a new instance was created.

The same with geometry objects: I tried to store geometry as RhinoObjects. But when i change the geometry the RhinoObject still stores the old geometry. So I alwas have to use the GUID which seems to be not very effective.

That is correct. All objects in the document are immutable, so when an object is transformed or changed in some other way, the original object is moved into the undo stack and a brand new object (with copies of the attributes and userdata etc) is inserted into the document. Because of this, a reference to an object becomes stale once that object is modified, and as such you should not hang on to references for prolonged periods of time.

Storage and lookup of geometry and userdata is pretty optimized in Rhino. Are you sure that your original statement “I always have to store the id of the objects which is not very effective.” is quantifiable? Or do you just dislike having to take this approach in your code?

In the Rhino SDK we have to strike a balance between giving people the tools they need, but also making sure that no plugin developer can cause serious problems for everyone else by giving them access to sensitive instances. The solution we chose is to bottleneck all interaction with the Rhino document, so we always know when and how something changes.

1 Like

It was just an assumption that the GUID-way is not so effective. But I understand the advantage of immutable objects for the undo/redo functionality and the whole software architecture. I wasn’t sure if this is a result of the .Net port or the general concept of Rhino.

Thank you very much for your explanation!