It’s quite confusing dealing with grasshopper and rhino and switch in between sometimes, so we have some question as below see if there’s someone can explain more:
What’s the common practice to work with geometry in grasshopper python, use rhinoscriptsyntax? scriptcontext or Rhino Common, or others? is there any strategy for this?
When dealing with rhinoscriptsyntax, the default python component takes input to be guid. If we give a type hint to the input say “Curve”, then it will become a Rhino Geometry object. How do we convert this Geometry back to Guid in order to use rhinoscriptsyntax?
All objects in Rhino are wrapped into a RhinoObject, which contains a unique id for any object. In Grasshopper you usually create the Geometry directly from Rhinocommon and after you computed everything you add them to the Rhino Document ("bake). Only attaching them to the Rhino document creates an RhinoObject with an GUID as a conclusion. You can of course directly get and set objects by id from the RhinoDocument using a GH Python component but thats a bit odd. In order to modify data in Grasshopper I would only use Rhinocommon and do not mess with IDs at all. The problem however is that RhinoScriptSyntax is also a wrapper to Rhinocommon to work with it in a more Python friendly way. And this results in this mess you now encounter. Using Rhinocommon is difficult with Python, it would be easier with C# or VB.
You can convert between rs and rc by using the (rs) coerce… methods. Hope this helps
Thanks for your explanation. Yes i am working with python so normally I just use rhinoscriptsyntax and do encounter such problems. So seems if I use python there’s no easy way to solve this now.
for (rs) coerce… methods I can only make it work converting id to geometry, wonder is there a way to do geometry to id ? - the reason to do this as stated in my post my input is geometry but i want to use rhinoscriptsyntax which takes guid as input.
I’m not sure you will find a common practice as such, but I certainly prefer and advocate to implement RhinoCommon directly (for many reasons, if you search this forum and the old Grasshopper one you’ll find many topics related to this).
Edit: A few of my key preference points for RhinoCommon:
No GUID/coercing business.
No missing functions/methods (i.e. that have not been ported).
Better performance.
Easy porting to C#/VB.
OOP.
That said, I still implement rhinoscriptsynax when interfacing the Rhino document.
You’re literally performing fewer computations by skipping all the GUID stuff (which is generally the bulk of many rhinoscriptsyntax functions), which on large enough cases will be noticeably faster. Sometimes by quite a lot, other times barely noticeable.
Edit: Here’s one example I had open in Sublime Text:
I feel that the important part here is that everyone can program in the way they most prefer, given all the advantages and limitations of each technology and programming language. Generally speaking, RhinoScriptSyntax (RS) is meant to be more introductory, and RhinoCommon (RC) is more advanced. RhinoCommon in C# is then also more suited than Python for some UI-related tasks.
The common practice depends mostly from who is developing and with which intention. For some small scripts and for users with little programming background, I think RhinoScriptSyntax is by far best suited. It’s a procedural library that is easy to follow, but not entirely comprehensive.
To make it more comprehensive, you will find that you might need to use RC here and there. When you see that you use RC a lot, probably it will be the right time to turn to this more-encompassing library. This is an object-oriented library. RS is developed in RC.
For Windows, we also publish a C++ library, OpenNURBS and C++ Rhino headers, that are used to develop RC. With tiny exceptions, all of RC calls into OpenNURBS/Rhino.
You get a Guid when you add an object to the document. This can be done by using
import scriptcontext as sc
id = sc.doc.Objects.Add...(RC_object)
GhPython components in Grasshopper carry their own version of a document in order to be faster and avoiding previews and undo’s, which would account for large time losses.
I hope this helps,
Thanks,
Giulio
–
Giulio Piacentino
for Robert McNeel & Associates giulio@mcneel.com
