Difference between GH python component and python in Rhino

Replies to This Discussion

Permalink Reply by djordje on October 1, 2014 at 10:40am

Hi Tim,

Not all rhinoscriptsyntax functions can be used in ghpython component.
IsSolid being one of them. I will report this to mcneel guys, as making it work with ghpython too is doable.
In the mean time use the edited function in the attached file (you can also use the "GUID" parameters, but in that case you will have to switch between Rhino and grasshopper documents).

Attachments:

• sample2.gh, 9 KB

Permalink Reply by Tim Chen on October 1, 2014 at 10:44am

Hey, thanks a lot! That works great.

Though now I am confused. What's the difference between object_id and GUID?

Permalink Reply by djordje on October 1, 2014 at 10:54am

It's the same. It's just "object_id" is another name for GUID in this case.

So in the above attached function, I could have written: IsObjectSolid2(GUID) as well.

But grasshopper's "Guid" parameter retrieves objects_id (or guids) from Rhino document only.

Permalink Reply by Tim Chen on October 1, 2014 at 10:57am

and the object_id you use in the code you sent me refers to the actual grasshopper component?

Permalink Reply by djordje on October 1, 2014 at 11:31am

object_id is a function parameter. You are actually referring to the "b" argument, right?
Yes, it is a guid from grasshopper document (each time you reference some geometry from Rhino to Grasshopper, by using some grasshopper parameter(Brep, Point, Surface, Curve...) you are actually coping that object from Rhino to grasshopper document).

This is what I meant by "but in that case you will have to switch between Rhino and grasshopper documents" (check the attached file).
But it currently has a bug of not supporting Extrusions.
So it's better to stick with sample2.gh solution for now.

Attachments:

• sample3.gh, 11 KB

Permalink Reply by Anders Holden Deleuran on October 1, 2014 at 12:41pm

You could also pass the geometry as RhinoCommon objects and call the IsSolid (for breps) and IsClosed (for meshes) object properties directly, see attached file. As a rule of thumb I find it less clunky to use RhinoCommon directly when using GHPython. You can avoid operating on guids more or less entirely this way and often the execution speed will be faster as well. Hope Djordje agrees ;)

Attachments:

• 141001_IsSolid_IsClosed.gh, 15 KB

Permalink Reply by djordje on October 1, 2014 at 1:06pm

Yes, djordje agrees :)

Permalink Reply by Tim Chen on October 2, 2014 at 2:40am

Thanks to both!

So when you pass the GH copy of the object as is (like as a brep instead of the id string), the list of methods available to that object is a part of RhinoCommon?

Is there a manual that details the relationship between RhinoCommon (what is it anyway), and the scripting environment? (really dumb question..i know). And how do you decide which to use?

Permalink Reply by Anders Holden Deleuran on October 2, 2014 at 3:07am

Yes, that's correct.

That said. The rhinoscriptsyntax Module is a Python module which wraps around the RhinoCommon SDK. So when you use rhinoscriptsyntax functions you are indirectly using RhinoCommon already. If you want to inspect the rhinoscriptsyntax module to see how functions implement RhinoCommon you can check it out on GitHub or locally on your machine, something like this:

C:\Users\UserName\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\rhinoscript

The problem I described above is that these functions are designed to operate on guids (geometry etc. in the Rhino document) and not RhinoCommon object types. Hence you will have to coerce guids to get their objects etc. This can be quite clunky, it can be slower and it also does not take advantage of the object-orientated architecture of the RhinoCommon SDK. If you search the forum you should see several threads on this subject. Secondarily some functionality has yet to be ported, so you might be missing certain functions.

In general I would recommend to use RhinoCommon whenever you are not dealing directly with the Rhino document (there's a lot of great functionality in rhinoscriptsyntax for getting geometry, looping through layers etc.). The RhinoCommon documentation is available on-line here:

http://4.rhino3d.com/5/rhinocommon/

There's also a nice collection of examples available here:

http://wiki.mcneel.com/developer/pythonandrhinocommon

Hope that helps :)

Permalink Reply by Giulio Piacentino on October 3, 2014 at 5:19am

Hi guys,

I see what is going on.

This function was written for Rhino 4 and now it is buggy. Besides the problem with GhPython, there is something wrong even more in general: try it on a normal extrusion object (like a box) in Rhino and it will return false.

I'll get it fixed ASAP

Thanks

Giulio

--

Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

Permalink Reply by djordje on October 3, 2014 at 5:29am

Hi Giulio, will this fix the issue with Extrusions?

Permalink Reply by Giulio Piacentino on October 3, 2014 at 5:32am

Yes -- but unfortunately it will not fix it for GhPython. Checking against a precise type is not entirely Pythonic anyways. "The most Pythonic way to check the type of an object is... not to check it." more...

Giulio

--

Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com