Rhino parametric in RhinoCommon 6

rhinocommon

(Sebastiano Del Gobbo) #1

Hi guys!
I’m evaluating the possibility to add some kind of parametric drawing ability to Rhino 6, using RhinoCommon.
More deeply, I would like to save in the document some kind of parent/child relationship and let the user edit both parent or child and apply the same edits to the other, related, object.
For various reasons I can’t create a Grasshopper component.
Do you think this is possible?
If yes… How can it be done?


#2

You can store data/parameters in UserData objects, say in a “parent”, and then apply or propapate any needed parametric changes to the “children” with your own script code. You can use RhinoCommon for this, without using GrassHopper (the idea would be to store your parametric info in a UserData object instead. UserData is a class that exist for all RhinoObjects, in which you can save key/value pairs, etc)

Info about how to make your own plugin (available as a command in Rhino)

// Rolf


(Sebastiano Del Gobbo) #3

Thanks a lot, RIL!
Now the next question is: can i intercept parent/child modifications, to apply parametric changes to all objects involved?


(Menno Deij - van Rijswijk) #4

In principle this is possible, we have developed a system that does this for generation of 3D marine propeller geometry based on 2D curves. One of the features is that whenever a user modifies one of the 2D curves that define the shape of a propeller, that the system re-generates the corresponding 3D shape of the propeller blades, hub, fillets, etc.
The key is to start doing this is the events AddRhinoObject, DeleteRhinoObject and ReplaceRhinoObject that are fired from the document object.

Having a few years of experience building Rhino plug-ins (including the above mentioned one for propellers) as well as Grasshopper components, I would advise you to develop Grasshopper components, mainly because the system of Add/Delete/Replace above is quite complex to get right. Grasshopper handles most of the complexity for you as developer, so you can build more simple modular components. Another upside is that users will start combining these components in ways you cannot imagine, leading to new applications of existing functionality.

Just out of curiosity, what are the various reasons you can’t create a GH component?


(Sebastiano Del Gobbo) #5

Thanks, Menno!
Good news for me! :wink:

I took a look at those events but I can’t figure out how to use them properly.
Let me explain what I need to do…
Given a curve (A) and another curve (B) that is the result of an offset on curve A, I would like to update the offset curve (B) as the original curve (A) is modified.
I think I need to know

  • If a command is executed, does this command take curve A as input? If yes, what are the executing parameters of the command? (i.e. offset amount)
  • Is the original object is modified by dragging, rotating, scaling, ecc…?
  • Is one or more point of the original object dragged, added, deleted, ecc…?
    But maybe my approach is totally wrong! I don’t know.

I agree with you: creating a GH component would be a perfect solution.
But we are developer and it’s easy for us to understand what GH does and how to use it properly.
In other words, we are trying to develop something less flexible but more easy and ready to use.
Thanks again. Menno!


(Menno Deij - van Rijswijk) #6

Whenever curve A is modified by a command, or by dragging, rotation, scaling etc. the three events I mentioned will be fired because the curve will be ‘replaced’ with the new curve. The origin of the changes does not matter, these events are always fired.
Whenever such events fire, you can check if the object that is being replaced, and if it is curve A, you can find curve B (because you know its document GUID), and replace that as well with its newly offset shape.

Note one more complication: whenever the user does an Undo, a fourth event will be fired as well RhinoDoc.UndeleteRhinoObject. Then you need to update curve B again.


(Sebastiano Del Gobbo) #7

Wow, Menno!
This is exactly what I needed to know! Thanks!
Now I am able to propagate the changes to all “linked” objects…
Can I ask you another question?


(Menno Deij - van Rijswijk) #8

Sure, fire away


(Sebastiano Del Gobbo) #9

Thanks! Very kind!
The last question about adding “parametric” capabilities is this: It is possible to intercept objects creation (not editing) with all creation parameters? I wrote something a couple of messages earlier:

Of course i would like to know it because i would like to be able to automatically keep track of objects relationships…


(Menno Deij - van Rijswijk) #10

No, it is generally not known what the command parameters are that are used to modify an object. Only when the curve has been modified, will the events be fired.


(Sebastiano Del Gobbo) #11

Bad news… But thanks again, Menno!